πŸš€ Kick-start your C++! A template for modern C++ projects using CMake, CI, code coverage, clang-format, reproducible dependency management and much more.

Overview

Actions Status Actions Status Actions Status Actions Status Actions Status codecov

ModernCppStarter

Setting up a new C++ project usually requires a significant amount of preparation and boilerplate code, even more so for modern C++ projects with tests, executables and continuous integration. This template is the result of learnings from many previous projects and should help reduce the work required to setup up a modern C++ project.

Features

Usage

Adjust the template to your needs

  • Use this repo as a template.
  • Replace all occurrences of "Greeter" in the relevant CMakeLists.txt with the name of your project
    • Capitalization matters here: Greeter means the name of the project, while greeter is used in file names.
    • Remember to rename the include/greeter directory to use your project's lowercase name and update all relevant #includes accordingly.
  • Replace the source files with your own
  • For header-only libraries: see the comments in CMakeLists.txt
  • Add your project's codecov token to your project's github secrets under CODECOV_TOKEN
  • Happy coding!

Eventually, you can remove any unused files, such as the standalone directory or irrelevant github workflows for your project. Feel free to replace the License with one suited for your project.

To cleanly separate the library and subproject code, the outer CMakeList.txt only defines the library itself while the tests and other subprojects are self-contained in their own directories. During development it is usually convenient to build all subprojects at once.

Build and run the standalone target

Use the following command to build and run the executable target.

cmake -Hstandalone -Bbuild/standalone
cmake --build build/standalone
./build/standalone/Greeter --help

Build and run test suite

Use the following commands from the project's root directory to run the test suite.

cmake -Htest -Bbuild/test
cmake --build build/test
CTEST_OUTPUT_ON_FAILURE=1 cmake --build build/test --target test

# or simply call the executable: 
./build/test/GreeterTests

To collect code coverage information, run CMake with the -DENABLE_TEST_COVERAGE=1 option.

Run clang-format

Use the following commands from the project's root directory to check and fix C++ and CMake source style. This requires clang-format, cmake-format and pyyaml to be installed on the current system.

cmake -Htest -Bbuild/test

# view changes
cmake --build build/test --target format

# apply changes
cmake --build build/test --target fix-format

See Format.cmake for details.

Build the documentation

The documentation is automatically built and published whenever a GitHub Release is created. To manually build documentation, call the following command.

cmake -Hdocumentation -Bbuild/doc
cmake --build build/doc --target GenerateDocs
# view the docs
open build/doc/doxygen/html/index.html

To build the documentation locally, you will need Doxygen, jinja2 and Pygments on installed your system.

Build everything at once

The project also includes an all directory that allows building all targets at the same time. This is useful during development, as it exposes all subprojects to your IDE and avoids redundant builds of the library.

cmake -Hall -Bbuild
cmake --build build

# run tests
./build/test/GreeterTests
# format code
cmake --build build --target fix-format
# run standalone
./build/standalone/Greeter --help
# build docs
cmake --build build --target GenerateDocs

Additional tools

The test and standalone subprojects include the tools.cmake file which is used to import additional tools on-demand through CMake configuration arguments. The following are currently supported.

Sanitizers

Sanitizers can be enabled by configuring CMake with -DUSE_SANITIZER=<Address | Memory | MemoryWithOrigins | Undefined | Thread | Leak | 'Address;Undefined'>.

Static Analyzers

Static Analyzers can be enabled by setting -DUSE_STATIC_ANALYZER=<clang-tidy | iwyu | cppcheck>, or a combination of those in quotation marks, separated by semicolons. By default, analyzers will automatically find configuration files such as .clang-format. Additional arguments can be passed to the analyzers by setting the CLANG_TIDY_ARGS, IWYU_ARGS or CPPCHECK_ARGS variables.

Ccache

Ccache can be enabled by configuring with -DUSE_CCACHE=<ON | OFF>.

FAQ

Can I use this for header-only libraries?

Yes, however you will need to change the library type to an INTERFACE library as documented in the CMakeLists.txt. See here for an example header-only library based on the template.

I don't need a standalone target / documentation. How can I get rid of it?

Simply remove the standalone / documentation directory and according github workflow file.

Can I build the standalone and tests at the same time? / How can I tell my IDE about all subprojects?

To keep the template modular, all subprojects derived from the library have been separated into their own CMake modules. This approach makes it trivial for third-party projects to re-use the projects library code. To allow IDEs to see the full scope of the project, the template includes the all directory that will create a single build for all subprojects. Use this as the main directory for best IDE support.

I see you are using GLOB to add source files in CMakeLists.txt. Isn't that evil?

Glob is considered bad because any changes to the source file structure might not be automatically caught by CMake's builders and you will need to manually invoke CMake on changes. I personally prefer the GLOB solution for its simplicity, but feel free to change it to explicitly listing sources.

I want create additional targets that depend on my library. Should I modify the main CMakeLists to include them?

Avoid including derived projects from the libraries CMakeLists (even though it is a common sight in the C++ world), as this effectively inverts the dependency tree and makes the build system hard to reason about. Instead, create a new directory or project with a CMakeLists that adds the library as a dependency (e.g. like the standalone directory). Depending type it might make sense move these components into a separate repositories and reference a specific commit or version of the library. This has the advantage that individual libraries and components can be improved and updated independently.

You recommend to add external dependencies using CPM.cmake. Will this force users of my library to use CPM as well?

CPM.cmake should be invisible to library users as it's a self-contained CMake Script. If problems do arise, users can always opt-out by defining CPM_USE_LOCAL_PACKAGES, which will override all calls to CPMAddPackage with find_package. Alternatively, you could use CPMFindPackage instead of CPMAddPackage, which will try to use find_package before calling CPMAddPackage as a fallback. Both approaches should be compatible with common C++ package managers without modifications, however come with the cost of reproducible builds.

Can I configure and build my project offline?

Using CPM, all missing dependencies are downloaded at configure time. To avoid redundant downloads, it's recommended to set a CPM cache directory, e.g.: export CPM_SOURCE_CACHE=$HOME/.cache/CPM. This will also allow offline configurations if all dependencies are present. No internet connection is required for building.

Can I use CPack to create a package installer for my project?

As there are a lot of possible options and configurations, this is not (yet) in the scope of this template. See the CPack documentation for more information on setting up CPack installers.

This is too much, I just want to play with C++ code and test some libraries.

Perhaps the MiniCppStarter is something for you!

Coming soon

  • Script to automatically adjust the template for new projects
Issues
  • Compile options and warnings for standalone?

    Compile options and warnings for standalone?

    Similar to how it's done in this other starter attempt, I feel like those options and warnings could be beneficial.

    I would like to get some input on how the IPO (LTO) optimization should be done before making a PR.
    In that other project it seems to be a global option whether LTO is on or off. Is that right?

    opened by friendlyanon 15
  • Adding 3rd party libs to target_include_directories

    Adding 3rd party libs to target_include_directories

    How to properly add other local third-party libraries inside the main package? the main package is not a single header libarary.

    issue_project
    β”œβ”€β”€ include
    β”‚Β Β  β”œβ”€β”€ main_lib1
    β”‚Β Β  β”‚Β Β  └── mainlib.h
    β”‚Β Β  β”œβ”€β”€ main_lib2
    β”‚Β Β  β”‚Β Β  └── mainlib2.h
    β”‚Β Β  └── main_project.h
    └── thirdparty
        β”œβ”€β”€ lib1
        β”‚Β Β  └── lib1.h
        └── lib2
            └── lib2.h
    

    I tried this

    target_include_directories(
      Greeter PUBLIC "$<BUILD_INTERFACE:${PROJECT_SOURCE_DIR}/include;${THIRD_PARTY_LIBRARY}">
                     $<INSTALL_INTERFACE:include/${PROJECT_NAME}-${PROJECT_VERSION}>
    )
    

    But with an error that the header file not found. However, if I tried to put "include_directories(${THIRD_PARTY_LIBRARY})" it will build the main Cmake but the test's Cmake will fail due to the following error:

    #include <xx/x.h> No such file or directory
    

    If I was not clear enough, I will create a simplified project to reproduce the issue.

    Thanks,

    opened by mr-eyes 10
  • DOCTEST_CONFIG_USE_STD_HEADERS in MSVC++

    DOCTEST_CONFIG_USE_STD_HEADERS in MSVC++

    It seems there's no need to include whole <sstream> header. Just <ostream> is enough.

    opened by Cvelth 9
  • add a package for a interface(or not executable) library

    add a package for a interface(or not executable) library

    I noticed the CMakeList.txt file at the top level of your project, the line 55

    # Link dependencies
    target_link_libraries(Greeter PRIVATE fmt::fmt)
    

    Use target_link_libraries to link an external library which add by

    CPMAddPackage(
      NAME fmt
      GIT_TAG 7.1.3
      GITHUB_REPOSITORY fmtlib/fmt
      OPTIONS "FMT_INSTALL YES" # create an installable target
    )
    

    I am puzzled why this can be done, as far as I know, this will remind me of an error on my IDE (CLion).

    Cannot specify link libraries for target "PROJECT_NAME" which is not built by this project.

    This is the structure of my project:

    cmake |--- CPM.cmake

    exec |--- main.cpp |--- CMakeList.txt

    include |--- *.hpp

    src |--- *.cpp

    CMakeList.txt

    The content of CMakeList.txt in top level:

    cmake_minimum_required(VERSION 2.8.12...3.17)
    project(
    		foo
    		VERSION 0.0.1
    		LANGUAGES CXX
    )
    
    include(cmake/CPM.cmake)
    CPMAddPackage("gh:TheLartians/PackageProject.cmake#master")
    
    file(GLOB_RECURSE fooHeader CONFIGURE_DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/include/*.hpp")
    file(GLOB_RECURSE fooSource CONFIGURE_DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/src/*.cpp")
    
    add_library(
    		${PROJECT_NAME}
    		${fooHeader}
    		${fooSource}
    )
    
    set_target_properties(
    		${PROJECT_NAME} PROPERTIES
    		LINKER_LANGUAGE CXX
    		CXX_STANDARD 17
    )
    
    # being a cross-platform target, we enforce standards conformance on MSVC
    target_compile_options(${PROJECT_NAME} PUBLIC "$<$<BOOL:${MSVC}>:/permissive->")
    
    # MARK1
    # CPMAddPackage("gh:jarro2783/cxxopts#master")
    # set(CXXOPTS_BUILD_EXAMPLES off)
    # set(CXXOPTS_BUILD_TESTS off)
    # target_link_libraries(${PROJECT_NAME} cxxopts)
    
    target_include_directories(
    		${PROJECT_NAME}
    		PUBLIC
    		$<BUILD_INTERFACE:${PROJECT_SOURCE_DIR}/include>
    		$<INSTALL_INTERFACE:include/${PROJECT_NAME}-${PROJECT_VERSION}>
    )
    
    string(TOLOWER ${PROJECT_NAME}/version.h VERSION_HEADER_LOCATION)
    
    packageProject(
    		NAME ${PROJECT_NAME}
    		VERSION ${PROJECT_VERSION}
    		NAMESPACE ${PROJECT_NAME}
    		BINARY_DIR ${PROJECT_BINARY_DIR}
    		INCLUDE_DIR ${PROJECT_SOURCE_DIR}/include
    		INCLUDE_DESTINATION include/${PROJECT_NAME}-${PROJECT_VERSION}
    		VERSION_HEADER "${VERSION_HEADER_LOCATION}"
    		DEPENDENCIES "foo"
    )
    

    The content of CMakeList.txt in exec:

    cmake_minimum_required(VERSION 2.8.12...3.17)
    
    project(
    		fooExec
    		LANGUAGES CXX
    )
    
    include(../cmake/CPM.cmake)
    
    CPMAddPackage(
    		NAME foo
    		SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/..
    )
    
    add_executable(
    		${PROJECT_NAME}
    		main.cpp
    )
    
    set_target_properties(
    		${PROJECT_NAME}
    		PROPERTIES CXX_STANDARD 17
    		OUTPUT_NAME "fooExec"
    )
    
    # MARK2
    CPMAddPackage("gh:jarro2783/cxxopts#master")
    set(CXXOPTS_BUILD_EXAMPLES off)
    set(CXXOPTS_BUILD_TESTS off)
    target_link_libraries(
    		${PROJECT_NAME}
    		PRIVATE
    		foo::foo
    )
    

    You may have noticed that I have a mark in each of the two files.

    At the beginning, I wrote the code that needs cxxopts in the exec folder (the same directory as main.cpp) and the exec folder's structure is similar to the top level (also has include and src folders), I use

    target_link_libraries(
    		${PROJECT_NAME}
    		PRIVATE
    		foo::foo
    		cxxopts
    )
    

    everything work well

    // and if I write
    #include <cxx
    
    // It immediately reminds me whether to write
    #include <cxxopts.hpp>
    
    // Yes, IDE knows that there is a file called cxxopts.hpp
    

    But soon I discovered that there are some problems with the design of this structure. I need to move the code that uses cxxopts to the include and src folders at the top level. So I tried to delete the cxxopts at MARK2 to

    target_link_libraries(
    		${PROJECT_NAME}
    		PRIVATE
    		foo::foo
    )
    

    And added the code at MARK1 (they didn't exist at the beginning).

    CPMAddPackage("gh:jarro2783/cxxopts#master")
    set(CXXOPTS_BUILD_EXAMPLES off)
    set(CXXOPTS_BUILD_TESTS off)
    
    # the code below is also not exist now
    # target_link_libraries(${PROJECT_NAME} cxxopts)
    

    then

    ```c++
    // and if I write
    #include <cxx
    
    // It reminds me nothing
    #include <cxxopts.hpp>
    
    // Yes, IDE does not knows that there is a file called cxxopts.hpp and it tells me file not found
    

    After this, I came back here, I use target_link_libraries like you

    CPMAddPackage("gh:jarro2783/cxxopts#master")
    set(CXXOPTS_BUILD_EXAMPLES off)
    set(CXXOPTS_BUILD_TESTS off)
    target_link_libraries(${PROJECT_NAME} cxxopts)
    

    What I didn’t expect was that the error this time was not

    Cannot specify link libraries for target "PROJECT_NAME" which is not built by this project.

    It output

    CMake Error: install(EXPORT "fooTargets" ...) includes target "foo" which requires target "cxxopts" that is not in any export set.

    What I didn't expect again is

    // and if I write
    #include <cxx
    
    // It immediately reminds me whether to write
    #include <cxxopts.hpp>
    
    // Yes, IDE knows that there is a file called cxxopts.hpp again!!!
    

    I don't know what to do.

    help desk 
    opened by Life4gal 9
  • Use m.css for generating doxygen docs

    Use m.css for generating doxygen docs

    Here is the output: http://moderncppstarter-mcss-docs.surge.sh/index.html

    Addresses https://github.com/TheLartians/ModernCppStarter/issues/47 (although a bit indirectly).

    Also, note that right now, these are pending:

    • [x] The Pages and Files tabs have empty content, as m.css does not include undocumented entities by default in the output. We need to fix this by adding related documentation.
    • [x] Previously Doxygen was filled using env variables, ex: @[email protected], but now they have to be hardcoded. Maybe this can be improved.
    opened by chaitan94 9
  • How to Debug configuration with GreeterStandalone in CLion

    How to Debug configuration with GreeterStandalone in CLion

    As I opened starter with CLion, I can't find binary in configuration. CLion Settings: CMake: CMake options: -Hall -Bbuild Build directory: build.

    Only Greeter and fmt shows in Debug configuration, How to configure to debug the binary module?

    opened by navono 8
  • Distinguish

    Distinguish "Greeter" as the name of the CMake project and as the name of files/directories/classes

    Hi TheLartians

    First of all thanks for this great project; it really simplifies things quite a bit.

    One thing might be confusing for beginners though: the name "Greeter" is used both as the name of the CMake project and as the name of several files/directories/classes. Although you can technically distinguish these two by the capitalization of the first letter it still opens possibilities for mistakes.

    One side effect in renaming the project name is also missing from the README: one needs to change #include <greeter/version.h> to #include <NewProjName/version.h> in .cpp files as well.

    Do you think changing the project name to something like "YourProject" is better? I can make the PR.

    opened by nerrons 8
  • Starter with CLion

    Starter with CLion

    I would like to use this starter with Clion (from jetbrains).

    I can't find out how to setup all. In FAQ you said that is possible to make folder for example 'All' with single build (standalone/tests). Can you make a little sample?

    opened by benys 7
  • Why is style check done locally, but not in github actions?

    Why is style check done locally, but not in github actions?

    https://github.com/MBkkt/cppformlang/runs/1081779937

    opened by MBkkt 7
  • CMake Error: install(EXPORT

    CMake Error: install(EXPORT "GreeterTargets" ...) includes target "Greeter" which requires target "fmt-header-only" that is not in any export set.

    after adding a new build dependency I get this error:

    Claus-iMac:ModernCppStarter clausklein$ !rm
    rm -rf build/
    Claus-iMac:ModernCppStarter clausklein$ cmake -G Ninja -B build -S standalone/
    -- The CXX compiler identification is AppleClang 12.0.0.12000032
    -- Detecting CXX compiler ABI info
    -- Detecting CXX compiler ABI info - done
    -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped
    -- Detecting CXX compile features
    -- Detecting CXX compile features - done
    -- Downloading CPM.cmake to /Users/clausklein/Workspace/cpp/ModernCppStarter/build/cmake/CPM_0.28.2.cmake
    -- CPM: adding package [email protected] (v1.2.2)
    -- Using ccache: /usr/local/bin/ccache
    -- CPM: adding package [email protected] (v2.2.0)
    -- cxxopts version 2.2.0
    -- The C compiler identification is AppleClang 12.0.0.12000032
    -- Detecting C compiler ABI info
    -- Detecting C compiler ABI info - done
    -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - skipped
    -- Detecting C compile features
    -- Detecting C compile features - done
    -- CPM: adding package [email protected] (/Users/clausklein/Workspace/cpp/ModernCppStarter/standalone/..)
    -- CPM: Greeter: adding package [email protected] (v1.4)
    -- CPM: Greeter: adding package [email protected] (7.1.3)
    -- Version: 7.1.3
    -- Build type: 
    -- CXX_STANDARD: 17
    -- Performing Test has_std_17_flag
    -- Performing Test has_std_17_flag - Success
    -- Performing Test has_std_1z_flag
    -- Performing Test has_std_1z_flag - Success
    -- Performing Test SUPPORTS_USER_DEFINED_LITERALS
    -- Performing Test SUPPORTS_USER_DEFINED_LITERALS - Success
    -- Performing Test FMT_HAS_VARIANT
    -- Performing Test FMT_HAS_VARIANT - Success
    -- Required features: cxx_variadic_templates
    -- Performing Test HAS_NULLPTR_WARNING
    -- Performing Test HAS_NULLPTR_WARNING - Success
    -- Looking for strtod_l
    -- Looking for strtod_l - found
    -- Configuring done
    CMake Error: install(EXPORT "GreeterTargets" ...) includes target "Greeter" which requires target "fmt-header-only" that is not in any export set.
    -- Generating done
    CMake Generate step failed.  Build files cannot be regenerated correctly.
    Claus-iMac:ModernCppStarter clausklein$ 
    
    opened by ClausKlein 7
  • Use ${PROJECT_NAME} instead of writing projectname multiple times

    Use ${PROJECT_NAME} instead of writing projectname multiple times

    Is there a reason ${PROJECT_NAME} is not used? I thought this is the recommended way to go about it? Also it makes it easier to do the initial setup with your template.

    Example: Instead of:

    project(
      Greeter
      VERSION 1.0
      LANGUAGES CXX
    )
    
    add_library(Greeter ${headers} ${sources})
    
    set_target_properties(Greeter PROPERTIES CXX_STANDARD 17)
    
    target_compile_options(Greeter PUBLIC "$<$<COMPILE_LANG_AND_ID:CXX,MSVC>:/permissive->")
    
    target_link_libraries(Greeter PRIVATE fmt::fmt)
    

    use :

    project(
      Greeter
      VERSION 1.0
      LANGUAGES CXX
    )
    
    add_library(${PROJECT_NAME}${headers} ${sources})
    
    set_target_properties(${PROJECT_NAME}PROPERTIES CXX_STANDARD 17)
    
    target_compile_options(${PROJECT_NAME}PUBLIC "$<$<COMPILE_LANG_AND_ID:CXX,MSVC>:/permissive->")
    
    target_link_libraries(${PROJECT_NAME}PRIVATE fmt::fmt)
    
    opened by DominicD 7
  • Add cross-platform builder in github action

    Add cross-platform builder in github action

    Cross-platform builder in github action:

    • Dockcross : https://github.com/dockcross/dockcross
    • Support over 10 CPU architectures (x86, x86_64, ARMv5, ARMv6, ARMv7, ARMv8, RISCV32, RISCV64...)
    • Support 4 compilers (Clang, GCC and TinyCC, Emscripten...)
    • Support 3 OS (Linux, Android, Windows) and WebAssembly
    • Add dockcross + CMake (and Ninja) scripts
    • Complete support C++17 and partial C++20 (GCC 11 and LLVG/Clang 12)
    • CMake 3.21
    opened by bensuperpc 0
  • Update `PackageProject.cmake` to 1.7.0

    Update `PackageProject.cmake` to 1.7.0

    Export headers are nice.

    good first issue 
    opened by mscofield0 0
  • `cmake --build build/docs --target GenerateDocs` not working

    `cmake --build build/docs --target GenerateDocs` not working

    Happens on both Ubuntu WSL and Windows:

    cmake --build build/docs --target GenerateDocs
    [0/2] Re-checking globbed directories...
    [1/1] cd /mnt/c/Users/u26i76/Projects/ModernCppStarterOrig...26i76/Projects/ModernCppStarterOriginal/build/docs/doxygen
    FAILED: CMakeFiles/GenerateDocs
    cd .../build/docs && /usr/bin/cmake -E make_directory .../build/docs/doxygen && .../.cache/CPM/m.css/ce3daea984872362c3a8ed1c3d8956adbc400a88/documentation/doxygen.py .../build/docs/conf.py && echo Docs\ written\ to:\ .../build/docs/doxygen
    Warning: libgs not found
    Traceback (most recent call last):
      File ".../.cache/CPM/m.css/ce3daea984872362c3a8ed1c3d8956adbc400a88/documentation/doxygen.py", line 3857, in <module>
        subprocess.run(["doxygen", doxyfile], cwd=os.path.dirname(doxyfile), check=True)
      File "/usr/lib/python3.8/subprocess.py", line 489, in run
        with Popen(*popenargs, **kwargs) as process:
      File "/usr/lib/python3.8/subprocess.py", line 854, in __init__
        self._execute_child(args, executable, preexec_fn, close_fds,
      File "/usr/lib/python3.8/subprocess.py", line 1702, in _execute_child
        raise child_exception_type(errno_num, err_msg, err_filename)
    FileNotFoundError: [Errno 2] No such file or directory: 'doxygen'
    ninja: build stopped: subcommand failed.
    
    opened by mscofield0 3
  • Use `code-coverage.cmake` from `cmake-scripts`

    Use `code-coverage.cmake` from `cmake-scripts`

    Currently, the template just applies -fprofile-arcs -ftest-coverage to the Greeter target from test. As far as I could tell, it doesn't really generate the code coverage data locally, and I think it'd be useful to be able to do that.

    The code-coverage.cmake script exposes targets that we can run if we want to generate the data locally too. It also does checks that the current ModernCppStarter solution doesn't.

    opened by mscofield0 4
  • Standalone doc is not correct for CLion

    Standalone doc is not correct for CLion

    The build directory in CLion is 'cmake-build-debug', not 'build'.

    Or you can right-click Standalone's CMakeLists.txt file and select 'Load CMake Project'. Then Standalone becomes available to Run or Debug.

    documentation 
    opened by david-29 1
  • `cmake --build build/test --target format` not working

    `cmake --build build/test --target format` not working

    I've installed all that the documentation said is required:

    $ pip list
    Package      Version
    ------------ -------
    cmake-format 0.6.13
    cmakelang    0.6.13
    pip          21.0.1
    PyYAML       5.4.1
    setuptools   49.2.1
    six          1.15.0
    
    $ clang-format.exe --version
    clang-format version 11.0.1
    

    However, cmake --build build/standalone --target format works.

    help wanted 
    opened by mscofield0 9
  • Make include order follow Google/LLVM/Lakos guidelines

    Make include order follow Google/LLVM/Lakos guidelines

    @TheLartians Feel free to take this or leave it. LLVM, Google, and John Lakos recommend this order: https://llvm.org/docs/CodingStandards.html#include-style https://google.github.io/styleguide/cppguide.html#Names_and_Order_of_Includes

    However, you may prefer to instead use "" instead of <>, as recommend by Cpp Core Guidelines: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#sf12-prefer-the-quoted-form-of-include-for-files-relative-to-the-including-file-and-the-angle-bracket-form-everywhere-else

    If you use "" instead of <>, you could keep IncludeBlocks: Regroup but with the <> it seems clang-format wants to re-order.

    Some places prefer/recommend <> exclusively, so YMMV.

    opened by hazelnusse 6
  • General question - C++20

    General question - C++20

    Will this project be updated with C++20 or will there be a fork? C++20 it very different in how it works (typically modules and imports), I was curious on how you plan to continue

    https://www.youtube.com/watch?v=szHV6RdQdg8&ab_channel=CppCon

    enhancement 
    opened by dbonattoj 1
Releases(v0.17.3)
Owner
Lars Melchior
I'm a physicist, founder and full stack developer based in Berlin. Let's change the world together!
Lars Melchior
A template CMake project to get you started with C++ and tooling

cpp_starter_project Getting Started Use the Github template First, click the green Use this template button near the top of this page. This will take

Jason Turner 1.4k Sep 13, 2021
Type-safe zero-boilerplate interfaces for pure C99, implemented as a single-header library.

Interface99 Type-safe zero-boilerplate interfaces for pure C99, implemented as a single-header library. [ examples/state.c ] #include <interface99.h>

null 77 Sep 11, 2021
Starter project for cross platform WebGPU development in C++

A starter code for cross-platform (i.e., web & native) C++ WebGPU projects.

Will Usher 25 Sep 8, 2021
Pitchfork is a Set of C++ Project Conventions

Pitchfork Pitchfork is a set of conventions for native C and C++ projects. The most prominent being the project layout conventions. The layout specifi

null 550 Sep 12, 2021