Latest 1.92.0.beta1 1.91.0 1.90.0 1.89.0 1.88.0 1.87.0 1.86.0 1.85.0 1.84.0 1.83.0 1.82.0 1.81.0 1.80.0 1.79.0 1.78.0 1.77.0 1.76.0 1.75.0 1.74.0 1.73.0 1.72.0 1.71.0 1.70.0 1.69.0 1.68.0 1.67.0 1.66.0 1.65.1 1.65.0 1.64.0 1.63.0 1.62.0 1.61.0 1.60.0 1.59.0 1.58.0 1.57.0 1.56.0 1.55.0 1.54.0 1.53.0 1.52.0 1.51.0 1.50.0 1.49.0 1.48.0 1.47.0 1.46.1 1.46.0 1.45.0 1.44.0 1.43.0 1.42.0 1.41.0 1.40.0 1.39.0 1.38.0 1.37.0 1.36.0 1.35.0 1.34.1 1.34.0 1.33.1 1.33.0 1.32.0 1.31.0 1.30.2 1.30.1 1.30.0 1.29.0 1.28.0 1.27.0 1.26.0 1.25.1-bgl 1.25.1 1.25.0 1.24.0 1.23.0 1.22.0 1.21.2 1.21.1 1.21.0 1.20.2 1.20.1 1.20.0 1.19.0 1.18.3 1.18.2 1.18.0 1.17.0 1.16.1
Log In
Latest 1.92.0.beta1 1.91.0 1.90.0 1.89.0 1.88.0 1.87.0 1.86.0 1.85.0 1.84.0 1.83.0 1.82.0 1.81.0 1.80.0 1.79.0 1.78.0 1.77.0 1.76.0 1.75.0 1.74.0 1.73.0 1.72.0 1.71.0 1.70.0 1.69.0 1.68.0 1.67.0 1.66.0 1.65.1 1.65.0 1.64.0 1.63.0 1.62.0 1.61.0 1.60.0 1.59.0 1.58.0 1.57.0 1.56.0 1.55.0 1.54.0 1.53.0 1.52.0 1.51.0 1.50.0 1.49.0 1.48.0 1.47.0 1.46.1 1.46.0 1.45.0 1.44.0 1.43.0 1.42.0 1.41.0 1.40.0 1.39.0 1.38.0 1.37.0 1.36.0 1.35.0 1.34.1 1.34.0 1.33.1 1.33.0 1.32.0 1.31.0 1.30.2 1.30.1 1.30.0 1.29.0 1.28.0 1.27.0 1.26.0 1.25.1-bgl 1.25.1 1.25.0 1.24.0 1.23.0 1.22.0 1.21.2 1.21.1 1.21.0 1.20.2 1.20.1 1.20.0 1.19.0 1.18.3 1.18.2 1.18.0 1.17.0 1.16.1
Log In

Posts

Stay up to date with Boost and the C++ ecosystem with the latest news, videos, resources, and user-created content.

Filter

All

Latest Posts

  • No Tag- Backwards Compatibility
    Backwards compatibility in Boost libraries is addressed through a set of guidelines that classify changes by their impact. Non‑breaking modifications may be introduced without restriction. Small breaking changes are permitted provided advance notice is given several releases before publication. Large breaking changes that include a migration path require the new API to be placed in a separate directory or namespace, with users notified and afforded several releases to transition before the old API is removed. When no migration path exists, the new API must also reside in a distinct directory or namespace, while the legacy API is retained indefinitely, and removal is treated as a library deprecation requiring an extended period. Redesigns or rewrites equivalent to large breaking changes are to be considered new libraries and should undergo a formal or mini review.
    Blog
  • Testing Algorithm lib
    The Pure Virtual C++ 2026 conference was concluded with acknowledgments to hosts, speakers, and moderators. Recordings of all live and on‑demand talks were released for immediate viewing via a YouTube playlist. The featured sessions were presented in a specific order, covering topics such as C++ semantic awareness in the CLI, interoperability between C++ and Rust, AI‑driven development tools for Visual Studio, strategies for reducing build times, and the use of C++/WinRT with C++20 modules. Each session was linked to its corresponding video. The content was made freely accessible to the community. Viewers were encouraged to watch the full playlist for a comprehensive overview. The event highlighted recent advances and practical techniques for modern C++ development.
    News #Container
  • Rotation revisited: Cycle decomposition in clang’s libcxx
    The implementation of array rotation in clang’s libcxx is discussed, emphasizing that the minimal number of element swaps, roughly half the total size, is achieved. A permutation view of the rotation is employed, and the algorithm is described as traversing each cycle of that permutation. The number of cycles is indicated to be the greatest common divisor of the two segment lengths, denoted a and b. Each k‑th cycle is started at the element offset k from the beginning and proceeds by advancing a positions with wrap‑around until the start is reached again. An example with segment lengths 4 and 6 is provided, illustrating the sequence of positions visited within a single cycle. It is highlighted that this cycle‑based method attains the optimal swap count. The approach is contrasted with simpler but less efficient techniques.
    News #Bimap
  • Safe C++
    The lack of memory safety in C++ is identified as creating exploitable vulnerabilities, and the Safe C++ proposal for memory‑safe operations has been placed on indefinite hiatus. Established safe practices are recommended for Boost contributors, unsafe dependencies are to be avoided, and ongoing safety discussions are to be followed. The proposal’s goals are praised in feedback while integration complexity, performance impact, and competition from Rust and Swift are cited as concerns. Recommended reading includes Herb Sutter’s safety‑in‑context blog post and papers on core safety profiles. Boost libraries such as SmartPtr, Pool, StaticAssert, TypeTraits, Filesystem, ScopeExit, Interprocess, Thread, Asio, Atomic, Optional, Variant2, and Coroutine2 are cited as demonstrations of memory, type, resource, and thread safety.
    Blog #Compressed Pair
  • Design Best Practices
    Guidelines are presented as recommendations drawn from prior experience with Boost library submissions. Emphasis is placed on clarity and correctness before optimization, while adherence to ISO Standard C++ and use of the Standard Library are encouraged. Source files are required to begin with descriptive comments, licensing information, and a reference to the library’s Boost webpage, and to follow conservative formatting such as fixed‑width fonts, spaces instead of tabs, and an 80‑character line limit. Naming conventions mirror those of the C++ Standard Library, using lowercase words separated by underscores, uppercase macro prefixes, and descriptive identifiers. Consistency is advocated through matching library names, directory structures, header locations, and namespaces, with singular nouns preferred and the library name capitalized within the Boost namespace.
    Blog #Container
  • Development Best Practices
    Guidance is provided for accelerating library development while maintaining quality and openness. Beneficial Boost dependencies such as Config, Core, Assert, ThrowException and Mp11 are identified for evaluation to simplify compliance and extend functionality. A disciplined GitHub workflow is advocated, requiring all changes to be submitted via pull requests and avoiding direct edits on the website. Linear history is emphasized through the exclusive use of rebasing instead of merging, configuring pulls to rebase, and performing interactive rebase squashes before integration. Fast‑forward‑only merges are recommended and can be enforced via repository settings. Commit discipline is enforced by limiting commits to meaningful changes and refining them with amend or staged additions.
    Blog
  • Post for Waigtal
    Header files act as the interface between a library and user code and must be well‑behaved. Boost guidelines prescribe that header filenames use a lowercase .hpp extension. Include guards are required unless multiple inclusion is intended, using uppercase namespace‑prefixed identifiers separated by underscores. All declarations are placed inside a namespace, preferably boost, to avoid global namespace pollution. Headers must compile as standalone units and be placed in sub‑directories added to the include path, avoiding relative includes. Member ordering is advised as public, protected, then private, and boost/config.hpp is included when compiler or platform configuration is required. Examples illustrate nested guard naming for libraries such as Boost.Beast, showing progressive prefixes for subfolders and implementations.
    Blog #Align
  • JS Disabled blog
    Boost library submission rules are listed. Licenses must follow Boost policy; GPL/LGPL are excluded. Copyright ownership must be clearly stated. Libraries must be useful and portable. Organization guidelines and design best practices are encouraged.
    Blog #CallableTraits

Create an account

Advance your career, learn from experts, and help shape the future of Boost and C++.

Sign Up Now