You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Until now, the header names follow a simple convention. There are essentially three different types of extensions:
.h: Header files that can be used in both CUDA (.cu) and C++ (.cpp) code.
.cuh: Header files that can be used exclusively in CUDA (.cu) code.
no extension: Forward declaration files.
With the recent addition of an OpenMP backend, this scheme no longer fits as the device code is now also compiled in .cpp files. Furthermore, forward declarations follow a different convention which is also not obvious. This will also be the case for future backends. Thus, the current scheme is confusing and should be changed. Essentially, we have the following options:
thrust-like scheme: Use .h for all files including forward declaration files. This has the advantage of being a simple and uniform solution, but makes above inclusion limitations less obvious.
C++ STL-like scheme: Use no extension for all files. This would make the relation to the C++ standard library more obvious and is again a uniform solution. However, as most editors deduce the language from the file extension, we should think of a solution to keep syntax highlighting working.
Since the involving changes would lead to an API break, this will only be included in version 2.0.0.
The text was updated successfully, but these errors were encountered:
Until now, the header names follow a simple convention. There are essentially three different types of extensions:
.h
: Header files that can be used in both CUDA (.cu
) and C++ (.cpp
) code..cuh
: Header files that can be used exclusively in CUDA (.cu
) code.With the recent addition of an OpenMP backend, this scheme no longer fits as the device code is now also compiled in
.cpp
files. Furthermore, forward declarations follow a different convention which is also not obvious. This will also be the case for future backends. Thus, the current scheme is confusing and should be changed. Essentially, we have the following options:.h
for all files including forward declaration files. This has the advantage of being a simple and uniform solution, but makes above inclusion limitations less obvious.Since the involving changes would lead to an API break, this will only be included in version 2.0.0.
The text was updated successfully, but these errors were encountered: