Repository navigation
[FEA] Variadic ctor parameters #207
Description
Part of #110 (Refactor of open address data structures)
Development branch: NVIDIA/cuCollections/refactor
Synopsis
To make it convenient to construct a static_set or other data structures with a variety of configuration parameters, we want to use a variadic constructor pattern.
TODOs
- Implement prototype:
https://godbolt.org/z/T4oP1nsoWhttps://godbolt.org/z/Kj763Teonhttps://godbolt.org/z/5Ghac54E6 - To make this more generic, instead of the
get_or_default<T>function looking for a concrete typeT, it could look for the first type that satisfies a given concept C, e.g.,get_or_default<C>. If necessary, use unique member tags to disambiguate a concept. - Optional: Ctors that only take a variadic parameter pack (helpful to cuco::bloom_filter #101). For this, we need a mechanism to detect if all mandatory parameters are present, e.g.,
get_or_error<T>. - refine prototype and fix nvcc build errors: https://godbolt.org/z/5Ghac54E6
Activity
[-][FEA] [REFACTOR] Variadic ctor parameters[/-][+][FEA] Variadic ctor parameters[/+]sleeepyjack commentedon Aug 25, 2022
Initial prototype: https://godbolt.org/z/Kj763Teon
This approach still needs some refinement but enables us to use fully variadic ctors if we opt for strong types for all parameters.
We could also use this in member functions to pass optional parameters,e.g., pass an optional CUDA stream to one of the bulk functions.
Build on gcc works but nvcc fails to understand the deduction guide. Investigating...
sleeepyjack commentedon Aug 26, 2022
New version: tested on gcc, nvcc 11.0-11.7 and has better diagnostics: https://godbolt.org/z/5Ghac54E6