-
Notifications
You must be signed in to change notification settings - Fork 282
Cpp Coding Guidelines
Elias Stehle edited this page Aug 4, 2025
·
17 revisions
- Always use entities from
cuda::std::overstd::. They work in host and device code, work with NVRTC, and help testing our implementation. - Use CCCL internal macros over compiler/vendor-specific keywords. E.g., use
_CCCL_HOST_DEVICEinstead of__host__ __device_. This excludes examples and documentation. - Fully qualify any reference to a libcu++ entity. Prefer
::cuda::std::, or_CUDA_VSTD::, over justcuda::std. This avoids ambiguities when users define their namespaces calledcuda. - Doxygen comments should start with
//! - Macros for function attributes, like
_CCCL_HOST_DEVICE, should be ordered before declaration specifiers likeconstexprorstatic - Don't include libcu++ detail headers (starting with
__) in downstream projects (like CUB, Thrust, etc.). Always prefer the public headers.
TBD
-
Namespace Qualification: Do not use the global namespace qualification (
::cuda::xyzor::cuda::std::xyz). Instead, usecuda::xyzandcuda::std::xyz. -
Internal Macros: Do not use internal macros like
_CCCL_HOST_DEVICE.
- Always use the corresponding namespace macro to refer to a libcu++ entity over qualifying with a libcu++ namespace. E.g., use
_CUDA_VSTD::enable_ifovercuda::std::enable_if. - Always fully qualify function calls, even to functions in the same namespace.
- Defaulted constructors should be marked with
_CCCL_HIDE_FROM_ABI - libcu++ headers like
<cuda/foo>are strict supersets of<cuda/std/foo>and thus always include the corresponding<cuda/std/...>header.
CCCL uses a mix of different licenses for historical reasons.
- Any net new file should be licsensed under Apache-2.0 WITH LLVM-exception.
- For files with license headers, strongly prefer a 2-line SPDX header like:
// SPDX-FileCopyrightText: Copyright (c) 2025, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception