Space: Next slide
Shift+Space: Previous slide
←/→: Previous/next chapter
Esc: Overview F11: Full screen
Shift+Space: Previous slide
←/→: Previous/next chapter
Esc: Overview F11: Full screen
Outline
Development tools
Compilers
- Linux
- GCC (
sudo apt install g++) (ppa:ubuntu-toolchain-r/test) - Clang (
sudo apt install clang) (apt.llvm.org)
- GCC (
- macOS
- Apple Clang (developer.apple.com/xcode)
- Clang (
brew install llvm) - GCC (
brew install gcc)
- Windows
- MSVC (visualstudio.microsoft.com)
MinGW(not recommended)
Compilers
- Intel
- Intel oneAPI DPC++/C++ Compiler
(www.intel.com/content/www/us/en/developer/tools/oneapi/dpc-compiler.html)
- Intel oneAPI DPC++/C++ Compiler
- AMD
- AMD Optimizing C++ Compiler
(www.amd.com/en/developer/aocc.html)
- AMD Optimizing C++ Compiler
Integrated development environments (IDEs)
- Visual Studio (Windows only)
- Xcode (macOS only)
- Clion (€12/month, free student license)
- Visual Studio Code
- C/C++ extension
- Clangd extension
- CMake Tools extension
- Other editors
- Clangd language server
Integrated development environments (IDEs): Go to definition
Integrated development environments (IDEs): Refactoring
Integrated development environments (IDEs): Warnings and static analysis
Integrated development environments (IDEs): Debugging
Build system generators
- Locate compiler and other tools
- Detect compiler features
- Allow configuration of project options
- Locate dependencies
- Propagate compiler and linker flags
- Drive the build process
- Install resulting binaries
- Package resulting binaries
- Drive test runners
Build system generators: example
Build system generators: example
Build system generators
- CMake (
CMakeLists.txt)- De facto standard
- Huge ecosystem, loads of online resources
- Compatible with all major IDEs and toolchains
- Fast
- Flexible
- Interoperability with package managers
- Supports testing and packaging
- Easy to use for users of your project
- Awkward syntax
- Lots of poorly written legacy CMake code
- If you are going to learn one build system, learn CMake
Build system generators
- Meson (
meson.build)- Declarative syntax
- Intuitive command line interface
- Fast
- Gaining popularity
- Not turing complete
- Not turing complete
- Smaller community compared to CMake
- Requires Python
Build system generators
- Bazel (
BUILD)- Scalable to very large projects
- Remote building, caching and testing
- Arguably simpler syntax compared to CMake
- Developed by Google for Google
- Poor Windows support
- Painful dependency management
- Requires Java
Build system generators
- SCons (
SConstruct)- Extensible
- Reproducible
- Very slow
- No package detection
- Very poor/nonexistent cross-compilation support
- Low-level, no transitive options
- Lots of manual plumbing
- Requires creating a custom, one-off build system
- Requires Python
Build system generators
- Xmake (
xmake.lua)- Many features and many supported backends
- Built-in package manager compatible with external repositories
- Quite new
- Mostly a single-developer effort
- Most of the discussions and issues are in Chinese
- “Everything but the kitchen sink”
Build system generators
- GNU Autotools (
autogen.sh,configure.sh)- Many older GNU/Linux projects use it
- Outdated
- Primitive and fragile dependency detection (manual or
pkg-config) - Poor macOS and Windows compatibility
- Very slow
- Hard to understand, debug or patch
Build system generators
- Make (
Makefile)- Many older Linux projects use it
- Available as CMake or Autotools backend
- Very low-level build rules
- Not a build system generator (no dependency or compiler detection etc.)
- Cryptic syntax
- Static recipes
- Does not allow spaces in paths
- Primitive timestamp-based checks
- Manual dependency generation
- Poor Windows compatibility
- Not portable
Build system generators
- Ninja (
build.ninja)- A more modern Make alternative
- Fast, easy multi-threading
- Light-weight stand-alone binary
- Support for C++ and Fortran modules
- Excellent backend for CMake
- Intended for code generation by a higher-level tool like CMake
- Ideal CMake backend on Linux and macOS (use VS on Windows)
Building an example project
Example project
poly
├── src -- library source code
│ ├── include -- public API header files
│ │ └── poly
│ │ ├── interpolate.hpp
│ │ └── poly.hpp
│ ├── src -- implementation files
│ │ └── interpolate.cpp
│ └── CMakeLists.txt -- library build script
├── test -- unit tests
│ ├── CMakeLists.txt -- testing framework build script
│ └── test-interpolate.cpp
└── CMakeLists.txt -- user-facing build scriptExample project
poly
├── src
│ ├── include
│ │ └── poly
│ │ ├── interpolate.hpp
│ │ └── poly.hpp
│ ├── src
│ │ └── interpolate.cpp
│ └── CMakeLists.txt
├── test
│ ├── CMakeLists.txt
│ └── test-interpolate.cpp
└── CMakeLists.txtExample project
poly
├── src
│ ├── include
│ │ └── poly
│ │ ├── interpolate.hpp
│ │ └── poly.hpp
│ ├── src
│ │ └── interpolate.cpp
│ └── CMakeLists.txt
├── test
│ ├── CMakeLists.txt
│ └── test-interpolate.cpp
└── CMakeLists.txtExample project
poly
├── src
│ ├── include
│ │ └── poly
│ │ ├── interpolate.hpp
│ │ └── poly.hpp
│ ├── src
│ │ └── interpolate.cpp
│ └── CMakeLists.txt
├── test
│ ├── CMakeLists.txt
│ └── test-interpolate.cpp
└── CMakeLists.txtExample project
poly
├── src
│ ├── include
│ │ └── poly
│ │ ├── interpolate.hpp
│ │ └── poly.hpp
│ ├── src
│ │ └── interpolate.cpp
│ └── CMakeLists.txt
├── test
│ ├── CMakeLists.txt
│ └── test-interpolate.cpp
└── CMakeLists.txtExample project
poly
├── src
│ ├── include
│ │ └── poly
│ │ ├── interpolate.hpp
│ │ └── poly.hpp
│ ├── src
│ │ └── interpolate.cpp
│ └── CMakeLists.txt
├── test
│ ├── CMakeLists.txt
│ └── test-interpolate.cpp
└── CMakeLists.txtExample project
poly
├── src
│ ├── include
│ │ └── poly
│ │ ├── interpolate.hpp
│ │ └── poly.hpp
│ ├── src
│ │ └── interpolate.cpp
│ └── CMakeLists.txt
├── test
│ ├── CMakeLists.txt
│ └── test-interpolate.cpp
└── CMakeLists.txtExample project
poly
├── src
│ ├── include
│ │ └── poly
│ │ ├── interpolate.hpp
│ │ └── poly.hpp
│ ├── src
│ │ └── interpolate.cpp
│ └── CMakeLists.txt
├── test
│ ├── CMakeLists.txt
│ └── test-interpolate.cpp
└── CMakeLists.txtExample project: build commands
- Use Bash or Zsh shell on Linux/macOS, or in “Visual Studio Developer PowerShell” on Windows
# Configure
cmake -S . -B build -G "Ninja Multi-Config" -D POLY_INIT_NAN=On
# Build
cmake --build build --config Debug -j
# Run tests
cmake --build build --config Debug --target testExample project: build commands
# Configure
cmake -S . -B build -G "Ninja Multi-Config" -D POLY_INIT_NAN=On
-- The CXX compiler identification is GNU 11.4.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found GTest: /usr/lib/x86_64-linux-gnu/cmake/GTest/GTestConfig.cmake (found version "1.11.0")
-- Configuring done (0.5s)
-- Generating done (0.0s)
-- Build files have been written to: /home/pieter/GitHub/Cpp-Presentation/code/poly/build
# Build
cmake --build build --config Debug -j
[1/4] Building CXX object test/CMakeFiles/tests.dir/Debug/test-interpolate.cpp.o
[2/4] Building CXX object src/CMakeFiles/poly.dir/Debug/src/interpolate.cpp.o
[3/4] Linking CXX static library src/Debug/libpoly.a
[4/4] Linking CXX executable test/Debug/tests
# Run tests
cmake --build build --config Debug --target test
[0/1] Running tests...
Test project /home/pieter/GitHub/Cpp-Presentation/code/poly/build
Start 1: poly.interpolateCheby
1/1 Test #1: poly.interpolateCheby ............ Passed 0.00 sec
100% tests passed, 0 tests failed out of 1
Total Test time (real) = 0.00 secExample project: Visual Studio Code
Example project: Visual Studio Code
CMake concepts
CMake concepts
- Import and define targets
find_package(name)add_library(target sources...)add_executable(target sources...)add_custom_target(target command args...)
- Set target properties and usage
requirements
target_compile_features(target SCOPE features...)target_compile_definitions(target SCOPE definitions...)target_compile_options(target SCOPE options...)target_include_directories(target SCOPE directories...)target_link_options(target SCOPE options...)set_target_properties(targets PROPERTIES property value)
- Express dependencies between targets
target_link_libraries(target SCOPE dependency)
- Use targets and properties, do not set global flags
CMake concepts: scope and usage requirements
PUBLIC- Applies to current target and dependents (transitive)
PRIVATE- Applies to current target only
INTERFACE- Applies to dependents only (transitive)
PUBLIC |
PRIVATE |
INTERFACE |
|
|---|---|---|---|
liba |
-flag |
-flag |
|
libb |
-flag |
-flag |
CMake concepts: scope and usage requirements
- Reconsider the
polyexample from earlier:
CMake concepts: scope and usage requirements
- Which scope to use for compiler warnings?
- Want to apply them to our own code ...
- ... but not impose them on our users!
PRIVATE
# Interface libraries have no source files, only compiler flags etc.
add_library(warnings INTERFACE)
# Add compiler warnings for GCC
if (CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
target_compile_options(warnings INTERFACE "-Wall" "-Wextra" "-pedantic")
endif()
# Create an actual library target
add_library(poly "src/interpolate.cpp" ...)
# Apply warnings only when building poly, not when building dependents
target_link_libraries(poly PRIVATE warnings)
# This could be a user program that uses the poly library
add_executable(user_program "main.cpp")
# Compiled without warnings, thanks to private link between poly and warnings
target_link_libraries(user_program PRIVATE poly)CMake: further reading
- Variable scope and cache variables
(cmake.org/cmake/help/book/mastering-cmake/chapter/CMake Cache.html) - Find modules and package configuration files
(cmake.org/cmake/help/book/mastering-cmake/chapter/Finding Packages.html) - Variables, strings, lists
(cmake.org/cmake/help/latest/manual/cmake-language.7.html) - Export headers for shared libraries
(cmake.org/cmake/help/latest/module/GenerateExportHeader.html) - Installation of files and targets
(cmake.org/cmake/help/latest/command/install.html) - Packaging
(cmake.org/cmake/help/latest/manual/cpack.1.html) - An Introduction to Modern CMake
(cliutils.gitlab.io/modern-cmake)
Package management
Package management: where to get dependencies
- System package manager (APT, Homebrew, winget)
- Easy
- Requires admin privileges
- No control over package version
- Build from source (manually using shell scripts)
- Precise control over version and options
- No admin privileges required
- Does not scale well for large dependency trees
- Slow
- Include as Git submodule and CMake subdirectory (using
add_subdirectory)- Dependencies are automatically built while building our own package
- Similar drawbacks as above
- C++ package manager (Vcpkg, Conan, Spack)
- Simple declaration of required dependencies, features and versions
- Good integration with CMake
- Fast (binaries are often available)
- Custom recipes, channels, repositories
- Not all packages are available
Package management: Conan
- List dependencies in
conanfile.txtorconanfile.pyfile - Specify the
CMakeDepsgenerator to make packages available usingfind_package - Specify the
CMakeToolchaingenerator to pass options to CMake using a toolchain file - Choose the CMake layout for the build directories
poly
├── src
│ ├── include
│ │ └── poly
│ │ ├── interpolate.hpp
│ │ └── poly.hpp
│ ├── src
│ │ └── interpolate.cpp
│ └── CMakeLists.txt
├── test
│ ├── CMakeLists.txt
│ └── test-interpolate.cpp
├── conanfile.txt
└── CMakeLists.txt
[requires]
eigen/3.4.0
[test_requires]
gtest/1.12.1
[generators]
CMakeDeps
CMakeToolchain
[layout]
cmake_layoutPackage management: Conan
- Let Conan detect your system properties (only needed once)
conan profile detect --force - Install dependencies of the
polyprojectconan install . # Default generator and default build type conan install . \ -c tools.cmake.cmaketoolchain:generator="Ninja" \ -s build_type=Debug \ --build=missing - Generate, build and test the project using CMake
cmake --preset conan-debug # Configure cmake --build --preset conan-debug # Build ctest --preset conan-debug # Run tests
Package management: Conan
cmake --preset conan-debug # Configure
Preset CMake variables:
CMAKE_BUILD_TYPE="Debug"
CMAKE_POLICY_DEFAULT_CMP0091="NEW"
CMAKE_TOOLCHAIN_FILE:FILEPATH="~/poly/build/Debug/generators/conan_toolchain.cmake"
-- Using Conan toolchain: ~/poly/build/Debug/generators/conan_toolchain.cmake
-- Conan toolchain: C++ Standard 17 with extensions ON
-- The CXX compiler identification is GNU 11.4.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Conan: Component target declared 'Eigen3::Eigen'
-- Conan: Component target declared 'GTest::gtest'
-- Conan: Component target declared 'GTest::gtest_main'
-- Conan: Component target declared 'GTest::gmock'
-- Conan: Component target declared 'GTest::gmock_main'
-- Conan: Target declared 'gtest::gtest'
-- Configuring done (0.3s)
-- Generating done (0.0s)
-- Build files have been written to: ~/poly/build/Debug
cmake --build --preset conan-debug # Build
[1/4] Building CXX object test/CMakeFiles/tests.dir/Debug/test-interpolate.cpp.o
[2/4] Building CXX object src/CMakeFiles/poly.dir/Debug/src/interpolate.cpp.o
[3/4] Linking CXX static library src/Debug/libpoly.a
[4/4] Linking CXX executable test/Debug/tests
ctest --preset conan-debug # Run tests
[0/1] Running tests...
Test project ~/poly/build
Start 1: poly.interpolateCheby
1/1 Test #1: poly.interpolateCheby ............ Passed 0.00 sec
100% tests passed, 0 tests failed out of 1
Total Test time (real) = 0.00 secPackage management: alternatives
- Conan (conan.io)
- Cross-platform C/C++ package manager
- Supports many different build systems (CMake, Meson, Visual Studio/MSBuild, Autotools ...)
- Declarative
conanfile.txt, flexible and extensible using Python scripting inconanfile.py - MIT license
- Vcpkg (vcpkg.io)
- Cross-platform C/C++ package manager
- Supports CMake and MSBuild
- Good integration with other Microsoft products like Visual Studio
- Declarative
vcpkg.jsonmanifest file, CMake scripting inportfile.cmake - MIT license, opt-out telemetry
- Spack (spack.io)
- Linux and macOS package manager (no Windows support yet)
- Aimed towards high-performance computing and supercomputing
- Targets specific microarchitectures for optimal performance, many supported scientific languages, module support for managed HPC environments
- MIT or Apache-2.0 license
Catching bugs early
Catching bugs early: compiler warnings
- GCC, Clang
-Wall -Wextra -Wpedantic -pedantic-errorsabsolute minimum- Many other useful warnings and diagnostics available
(gcc.gnu.org/onlinedocs/gcc/Warning-Options.html)
(clang.llvm.org/docs/DiagnosticsReference.html)
- MSVC
/W3absolute minimum, preferably/W4
(learn.microsoft.com/en-us/cpp/build/reference/compiler-option-warning-level)
Catching bugs early: compiler warnings
- Start project with high warning level
- Enable warnings as errors for development builds
- GCC, Clang:
-Werror - MSVC:
/WX
- GCC, Clang:
- Enforce zero warning policy in continuous integration
Catching bugs early: compiler warnings
-
Suppress unavoidable warnings locally using pragmas
- GCC, Clang:
(gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html)
(clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-via-pragmas)#pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wxxx" /* code that would otherwise raise warning xxx */ #pragma GCC diagnostic pop - MSVC:
(learn.microsoft.com/en-us/cpp/preprocessor/warning)#pragma warning(push) #pragma warning(disable:xxxx) /* code that would otherwise raise warning xxxx */ #pragma warning(pop)
- GCC, Clang:
- Disable specific warnings if they raise too many false positives
- GCC, Clang:
-Wno-error=xxxsuppresses errors for warning-Wxxx,-Wno-xxxdisables warning entirely
Use-fdiagnostics-show-optionto include the warning name in the message - MSVC:
/wdxxxxdisables warning with codexxxx
- GCC, Clang:
Catching bugs early: linting and static analysis
-
Clang-Tidy: Clang-based C++ “linter” tool (clang.llvm.org/extra/clang-tidy)
- Diagnosing and fixing typical programming errors
- Style violations
- Static analysis
-
IDE integration (recommended during development)
- Warning squiggles in editor
- Automatic quick fixes
-
CMake integration (recommended for continuous integration)
- Use
-D CMAKE_CXX_CLANG_TIDY='clang-tidy;--warnings-as-errors=*'(cmake.org/cmake/help/latest/variable/CMAKE_LANG_CLANG_TIDY.html)
- Use
Catching bugs early: linting and static analysis
-
Clang-Tidy: configuration file
- Like warnings, enable the majority of checks in the beginning
- Remove checks for stylistic rules you don't follow (using minus sign)
- Suppress false positives locally using
NOLINT(name-of-check)comments - Disable checks that generate too many false positives
- Don't forget
HeaderFilterRegexso it also checks your header files!
poly
├── src
│ ├── include
│ │ └── poly
│ │ ├── interpolate.hpp
│ │ └── poly.hpp
│ ├── src
│ │ └── interpolate.cpp
│ └── CMakeLists.txt
├── test
│ ├── CMakeLists.txt
│ └── test-interpolate.cpp
├── .clang-tidy
├── conanfile.txt
└── CMakeLists.txt
---
WarningsAsErrors: ''
HeaderFilterRegex: '(include/poly)'
FormatStyle: file
Checks: |
*,
-abseil*,-altera*,-android*,-fuchsia*,-google*,-llvm*,-zircon*,
-modernize-use-trailing-return-type,
-*-magic-numbers,
google-build-using-namespace,
CheckOptions:
- key: readability-implicit-bool-conversion.AllowPointerConditions
value: trueCatching bugs early: linting and static analysis
- Other tools:
- GCC’s built-in
-fanalyzeroption
(gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html) - Cppcheck
(github.com/danmar/cppcheck)
- GCC’s built-in
Catching bugs early: Undefined Behavior
- What is the result of compiling and running the following code?
- Compilation error
- Program runs but does not terminate
- Program runs but corrupts the hard drive
- Program runs and terminates immediately after printing Launching the nukes ...
- Any of the above! (B. using GCC, D. using Clang)
Catching bugs early: Undefined Behavior
-
Undefined Behavior (UB) is a violation of language rules and compiler’s preconditions
- No guarantees about the output of the compiler!
- Runtime crash (e.g. segmentation fault) (best outcome)
- Bug lies dormant, program appears to do what you expected (can change at any time!)
- Program runs without crashing, silently generates incorrect results or has security vulnerability(worst outcome)
- Many different sources:
- Uninitialized variables
- Array out of bounds
- Signed integer overflow
- Pointer casts
- Data races
- Null pointer dereference
- Use after free
- ...
Catching bugs early: preventing Undefined Behavior
- How to prevent and detect Undefined Behavior?
- Awareness: know the rules of the language (en.cppreference.com)
- Follow good coding practices (isocpp.github.io/CppCoreGuidelines)
- Compiler warnings, linters and static analysis (previous slides)
- Run-time instrumentation and sanitizers (following slides)
- Run in specialized virtual machine like Valgrind (valgrind.org)
Catching bugs early: preventing Undefined Behavior
- Address Sanitizer (
-fsanitize=address)- Checks for memory errors (use after free, array out of bounds, dangling pointers)
- Undefined Behavior Sanitizer (
-fsanitize=undefined)- Checks for things like integer overflow, null pointer dereference, division by zero, pointer misalignment, invalid vpointers
- Thread Sanitizer (
-fsanitize=thread)- Checks for data races
- Sanitizers do not catch 100% of errors!
Catching bugs early a bit later: debugging
- Debuggers are extremely powerful tools
- Many different front-ends and display modes (e.g
GDB TUIlayout) - Python scripting and pretty-printing (GDB Python API)
- Conditional break-points
- Hardware watchpoints to break when a memory location is accessed (GDB watch)
- Remote debugging over SSH
- Post-mortem analysis and reverse stepping (rr-project.org)
- Instruction-level debugging and disassembly
- ...
Best practices
Best practices: C++ Core Guidelines
- C++ Core Guidelines (isocpp.github.io/CppCoreGuidelines)
Best practices: version control
- Use Git for version control
- KU Leuven has a GitLab instance (gitlab.kuleuven.be)
- GitHub offers free Pro subscriptions for students (github.com)
- Commit often
- Pull and rebase often
- Use meaningful commit messages
- Ignore large files, caches, temporary build files etc. using
.gitignore
Best practices: formatting
-
Clang-Format: automatic code formatter
- Built-in IDE support
- Always format before committing
- Minimizes uninteresting changes in Git diffs
poly
├── src
│ ├── include
│ │ └── poly
│ │ ├── interpolate.hpp
│ │ └── poly.hpp
│ ├── src
│ │ └── interpolate.cpp
│ └── CMakeLists.txt
├── test
│ ├── CMakeLists.txt
│ └── test-interpolate.cpp
├── .clang-format
├── .clang-tidy
├── conanfile.txt
└── CMakeLists.txtBest practices: documentation
- Use a documentation generation tool
- Doxygen (www.doxygen.nl)
- Sphinx (www.sphinx-doc.org, breathe.readthedocs.io)
- Document functions and variables using Doxygen-style docstrings (www.doxygen.nl/manual/docblocks.html)
- Use comments to explain why a piece of code is necessary and how it
achieves its task,
do not simply repeat what the code does - Docstrings and API references are insufficient
- Include high-level documentation that explains core concepts and overall architecture
- Include examples
Best practices: continuous integration
- Continuous integration: Run checks and tests every time you push code
- GitHub Actions (docs.github.com/en/actions)
- GitLab CI/CD (docs.gitlab.com/ee/ci)
-
Useful for:
- Running automated tests
- Checking formatting, running static analysis, checking warnings
- Generating code coverage reports
- Generating and deploying documentation
- Building, packaging and releasing software
- ...
- Matrix builds: build and test different combinations of settings and environments (docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs)
- Docker: reproducible builds (docs.docker.com)
Optimization
Optimization
- “Premature optimization is the root of all evil”
- Measure!
Optimization
- Profiling and performance tools
- gprof and gprofng (application profile analysis, sourceware.org/binutils/docs/gprofng.html)
- Linux perf (profiler with performance counters and trace points, including system calls, perf.wiki.kernel.org)
- gperftools (heap and CPU profiler, github.com/gperftools/gperftools)
- Valgrind callgrind (CPU and cache profiler, valgrind.org/docs/manual/cl-manual.html)
- Valgrind massif (memory profiler, valgrind.org/docs/manual/ms-manual.html)
- KCachegrind (profile visualization, github.com/KDE/kcachegrind)
-
FlameScope (interactive flame graphs of
perfprofiles, github.com/Netflix/flamescope) - Intel VTune (commercial profiler, intel.com/content/www/us/en/docs/vtune-profiler/get-started-guide)
- Google Benchmark (micro-benchmarking framework, github.com/google/benchmark )
- QuickBench (online version of Google Benchmark, quick-bench.com)
- Compiler Explorer (shows generated assembly side by side with source code, godbolt.org)
Optimization: performance tips
- Build in
Releasemode (with optimizations enabled) - Compile for a modern CPU, e.g.
-march=native, to get SSE/AVX support - Enable link-time optimization (LTO) (
CMAKE_INTERPROCEDURAL_OPTIMIZATION=On) - Use profile-guided optimization (PGO)
- Use vendor-optimized libraries for math, linear algebra, FFT, MPI, threading ...
- If
Debugmode is slow, use-Oginstead of-O0 - Beware of hidden costs (e.g. allocation) in tight loops
- Design with cache locality and arithmetic intensity in mind
- Eigen expression templates are faster than naive loops
- Don't guess, measure!
Interoperability with Python
Interoperability with Python
pybind11(github.com/pybind/pybind11)nanobind(github.com/wjakob/nanobind)- Call fast C++ algorithms from Python
- Call handy Python functions from C++
- Expose C++ functions and classes to Python
- Automatic conversions between NumPy arrays and Eigen matrices/vectors
- For example:
- Load or generate data using
pandasorscikit-learn - Call fast C++ function that implements the main algorithm
- Process the results and plot using
matplotlib
- Load or generate data using
- Create a Python package out of a CMake project using
py-build-cmake(github.com/tttapa/py-build-cmake)
Interoperability with Python
Useful resources
Useful resources
- C++ tutorial: www.learncpp.com
- Language and standard library reference for C and C++: en.cppreference.com
- C++ Core Guidelines: an extensive set of guidelines for using C++ well
- C++ 23 Standard (draft): draft of the official C++ standard, as a big PDF
- CppCon Back to Basics: excellent conference talks about specific subjects (2021) (2020)
- Various interesting conference talks: CppCon, C++Now, CppOnSea, CppNorth
- C++ Weekly with Jason Turner: www.youtube.com/@cppweekly
- An Introduction to Modern CMake
- Scientific Python Library Development Guide
Recap
Recap
- Use a build system generator and package manager to make installation as frictionless as possible (e.g. CMake + Conan)
- Beware of Undefined Behavior
- Keep up with best practices (e.g. C++ Core Guidelines, conference talks)
- Enable compiler warnings and static analysis (e.g. Clang-Tidy)
- Use continuous integration for running tests (with sanitizers and Valgrind)
- Include good documentation and examples
- Don't get lost in micro-optimizations, measure real-world performance