- Table of Content
This project is a collection of solutions to LeetCode problems provided by SHIEH YUEH-CHANG written in C++20. The purpose of the project is to practice:
- Classical data structures and algorithms and Developing proficiency with modern C++20 features.
- Building a C++ project with CMake for multiple platforms
- Version-controlling using Git
- Design program options with Boost.Program_options
- Unit-tests using Google Test
- Generating documentation from annotated C++ sources using Doxygen
- and maybe we can try to use in combination with sphinx (breathe bridge plugin) -> reference
- Gain proficiency with your preferred IDE and its associated extensions.
- For example, when using Visual Studio Code, the C/C++ Extension Pack provides essential features. In particular, ensure familiarity with language server support (IntelliSense) and integrated debugging capabilities.
- Nice to have: Todo Tree, Code Spell Checker, Markdown All in One
- Use chrome and Clip LeetCode for easy documentation of each solution implementation
- C++20 Compiler:
- macOS: AppleClang (Xcode Command Line Tools)
- Linux: GCC ≥ 10 or Clang ≥ 11
- Windows: Visual Studio 2022 with C++ tools, MinGW-w64, or Clang
- CMake (≥ 3.25): Build system generator
- Python (≥ 3.7): Required for the unified build script and development tools
- Boost (≥ 1.85.0): Program options library
- Component:
program_options
- Component:
- Google Test (1.14.0): Unit testing framework
- Automatically fetched via CMake FetchContent if not found
- nlohmann/json (master): JSON library for modern C++
- Git submodule:
external/nlohmann/json
- Git submodule:
All development tools are automatically installed in .venv/ when running the Python build script:
- pre-commit (≥ 4.3.0): Git hooks framework for code quality checks
- clang-format (≥ 21.1.2): Code formatter
- clang-tidy (≥ 21.1.1): Static analyzer and linter
The Python build script (python3 build.py) automatically creates the virtual environment and installs these tools on first run.
- Doxygen (≥ 1.9.0): Documentation generator (optional)
- Required only if generating documentation
The build system automatically creates a compile_commands.json symlink for IntelliSense support that points to the most recent build. VS Code configurations are provided for each platform (macOS, Linux, Windows).
The project supports unified cross-platform builds on macOS, Linux, and Windows using the new Python build script.
Use the unified Python build script for all platforms:
# Simple release build
python3 build.py
# Clean debug build with tests
python3 build.py -c -t Debug -r
# Build with verbose output
python3 build.py -v
# Build and open documentation
python3 build.py --open-docs
# Build and install to custom location
python3 build.py -i /usr/local # Unix/macOS
python3 build.py -i C:\local # Windows
# Build without tests
python3 build.py --no-tests
# Get help and see all options
python3 build.py --helpNote: The script uses the system Python3 interpreter and creates a virtual environment for development tools.
Before first use, the Python script will automatically:
- Check for required dependencies (CMake, C++ compiler, Python)
- Detect your platform (Darwin/Linux/Windows) and CPU count
- Warn if Doxygen is not found (for documentation builds)
- Create a Python virtual environment (
.venv/) - Install development tools (pre-commit, clang-format, clang-tidy)
- Set up pre-commit hooks for code quality
- Create IDE support files (
compile_commands.json)
OPTIONS:
-h, --help Show this help message and exit
-c, --clean Clean build (remove build directory first)
-t {Debug,Release,RelWithDebInfo,MinSizeRel}, --type TYPE
Build type (default: Release)
-d BUILD_DIR, --build-dir BUILD_DIR
Build directory (default: <source>/out/build/<type>)
-j JOBS, --jobs JOBS Number of parallel jobs (default: auto-detected CPU cores)
--no-tests Don't build tests
-r, --run-tests Run tests after building (overridden by --no-tests)
-i INSTALL, --install INSTALL
Install to PREFIX directory (default: <source>/out/install/<type>)
--docs Build documentation (requires Doxygen)
--open-docs Build and open documentation in browser (implies --docs)
-v, --verbose Verbose build output
The Python script automatically detects and handles platform differences:
- macOS (Darwin): Uses
sysctlfor CPU detection,openfor documentation viewing - Linux: Uses
os.cpu_count()for CPU detection,xdg-openfor documentation viewing - Windows: Uses
NUMBER_OF_PROCESSORSenvironment variable,startfor documentation viewing
All Platforms (Same Commands):
# Development workflow - clean debug build with tests
python3 build.py -c -t Debug -r
# Release build with documentation
python3 build.py -t Release --open-docs
# Build without tests for faster builds
python3 build.py --no-tests
# Production build and install (Unix/macOS)
python3 build.py -c -t Release -i /usr/local
# Production build and install (Windows)
python3 build.py -c -t Release -i "C:\Program Files\MyApp"
# Parallel build with all features
python3 build.py -c -t Debug -j 12 -r --docs -v
# Check what the script detects about your platform
python3 platform_test.pyNote: The script creates a virtual environment (.venv/) for development tools, ensuring consistent versions across different systems.
After building, you can run specific tests using ctest:
macOS/Linux:
# Using --test-dir to specify build directory (CMake 3.20+)
% ctest --test-dir out/build/Debug -R "fib.example1" --output-on-failure
# List all available tests
% ctest --test-dir out/build/Debug -N
# Run a specific test with verbose output
% ctest --test-dir out/build/Debug -R "fib.example1" --output-on-failure -V
# Run all tests matching a pattern (e.g., all fib tests)
% ctest --test-dir out/build/Debug -R "fib\." --output-on-failure
# Run all tests
% ctest --test-dir out/build/Debug --output-on-failure
# Alternative: Navigate to build directory first
% cd out/build/Debug
% ctest -R "fib.example1" --output-on-failureWindows:
REM Using --test-dir to specify build directory (CMake 3.20+)
ctest --test-dir out\build\Debug -R "fib.example1" --output-on-failure -C Debug
REM List all available tests
ctest --test-dir out\build\Debug -N -C Debug
REM Run a specific test with verbose output
ctest --test-dir out\build\Debug -R "fib.example1" --output-on-failure -V -C Debug
REM Run all tests matching a pattern (e.g., all fib tests)
ctest --test-dir out\build\Debug -R "fib\." --output-on-failure -C Debug
REM Run all tests
ctest --test-dir out\build\Debug --output-on-failure -C Debug
REM Alternative: Navigate to build directory first
cd out\build\Debug
ctest -R "fib.example1" --output-on-failure -C DebugYou can also debug tests directly:
macOS/Linux with lldb:
# Debug with lldb
% lldb -- out/build/Debug/tests/solution/tests_solution "--gtest_filter=fib.example1" "--gtest_also_run_disabled_tests"Windows with Visual Studio Debugger:
REM Open the test executable in Visual Studio or use the debugger from VS Code
REM You can also run tests with the --gtest_filter flag:
out\build\Debug\tests\solution\Debug\tests_solution.exe --gtest_filter=fib.example1 --gtest_also_run_disabled_testsImportant: The project uses clang-format and clang-tidy from the virtual environment. Make sure to activate it first:
# Activate the virtual environment (created by build.sh)
% source .venv/bin/activateFormat your code automatically:
# Activate virtual environment first
% source .venv/bin/activate
# Format a specific file
% clang-format -i -style=file src/solution/array/merge.cpp
# Format all C++ files in the project
% find . \( -name "*.cpp" -o -name "*.hpp" \) -not -path "./external/*" -not -path "./out/*" | xargs clang-format -i -style=file
# Check formatting without modifying files (useful for CI)
% clang-format --dry-run --Werror -style=file src/solution/array/merge.cpp
# Format all files using the task (doesn't require virtual environment)
% ./build.sh -t Debug # Ensure build directory exists
% cmake --build out/build/x64-Darwin-Debug --target format-allThe .clang-format file in the project root defines the formatting style.
Run static analysis on your code:
# Activate virtual environment first
% source .venv/bin/activate
# Run clang-tidy on a specific file (requires compile_commands.json)
% clang-tidy -p out/build/x64-Darwin-Debug src/solution/array/merge.cpp
# Run with automatic fixes
% clang-tidy -p out/build/x64-Darwin-Debug --fix src/solution/array/merge.cpp
# Run on all source files
% find src -name "*.cpp" | xargs clang-tidy -p out/build/x64-Darwin-Debug
# Run with specific checks
% clang-tidy -p out/build/x64-Darwin-Debug --checks='-*,modernize-*' src/solution/array/merge.cppThe .clang-tidy file in the project root defines the analysis rules. The -p option points to the build directory containing compile_commands.json.
The project uses pre-commit hooks to automatically run these tools:
# Activate the virtual environment (created by build.sh)
% source .venv/bin/activate
# Run pre-commit on all files
% pre-commit run --all-files
# Run pre-commit on staged files only
% pre-commit run
# Run specific hook
% pre-commit run clang-format --all-files
% pre-commit run clang-tidy --all-filesPre-commit hooks are automatically installed when you run build.sh for the first time.
leetcode_cpp/
├── bin/ # Executable applications
│ └── solution/ # Main solution runner with CLI
├── src/ # Source code libraries
│ ├── solution/ # LeetCode problem implementations
│ └── design_pattern/ # Design pattern examples
├── tests/ # Unit tests (Google Test)
│ ├── solution/ # Tests for LeetCode solutions
│ └── design_pattern/ # Tests for design patterns
├── include/ # Public header files
│ └── solution.hpp # Main solution class and data structures
├── docs/ # Documentation
│ ├── README.md # This file
│ └── Doxyfile # Doxygen configuration
├── cmake/ # CMake modules and utilities
│ ├── FindDependency.cmake # Dependency management
│ ├── ClangCxxDevTools.cmake # Clang tooling setup
│ └── RequireOutOfSourceBuilds.cmake
├── .vscode/ # VS Code workspace settings
├── CMakeLists.txt # Root CMake configuration
└── CMakePresets.json # CMake workflow presets
The project uses modern CMake (3.25+) with the following design principles:
-
Modular Structure: Each directory has its own
CMakeLists.txt, creating distinct library targetssrc_solution: Shared library containing all LeetCode solutionssrc_design_pattern: Shared library for design pattern implementationsbin_solution: Executable CLI tool linking to solution librariestests_solution&tests_design_pattern: Test executables
-
Interface Library Pattern: The
compiler_flagsinterface library propagates C++20 requirements and compiler warnings to all targets -
Dependency Management:
- Boost: For program options in CLI tool
- Google Test: Either system-installed or fetched automatically via
FetchContent - Doxygen: Optional, for documentation generation
-
Cross-Platform Support:
- Unix Makefiles for macOS/Linux (single-configuration)
- Visual Studio generators for Windows (multi-configuration)
- CMake presets for standardized workflows (
x64-Darwin-Debug,x64-Darwin-Release)
Each LeetCode problem follows a consistent pattern:
- Implementation:
src/solution/problemName.cpp- Contains the solution method(s) - Test:
tests/solution/problemName.cpp- Contains Google Test cases - Declaration:
include/solution.hpp- Public interface viaSolutionclass
All solutions are methods of a single Solution class, making them easy to discover and test individually.
Common data structures (ListNode, TreeNode, Node, etc.) are defined in solution.hpp and shared across all solutions.
- use more c++ tool, like sanitizer? Standard C++ Toolset - Anastasia Kazakova - C++ on Sea 2023