Add Doxygen docs to gcd() and improve vector example comments #329
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Documentation Enhancements
The stored_size option is powerful but easy to misinterpret as being limited to unsigned char.
A short note helps users understand that they can choose a larger integral type when they need more capacity while still reducing overhead compared to size_t.
The gcd() function already had informal comments; converting them to structured Doxygen makes the intent, preconditions, and complexity clearer and consistent with the rest of the codebase.
Both changes are documentation-only and do not affect runtime behavior.
Summary
This PR makes two small documentation improvements in Boost.Container:
1.Clarifies the stored_size option in doc_custom_vector.cpp by explicitly mentioning alternative integral types (unsigned short, unsigned int) and the memory–capacity tradeoff they provide.
2.Adds Doxygen-style documentation to the internal gcd() utility in math_functions.hpp, improving readability and generated reference docs without changing behavior.
Additional note
I’m interested to spend more time contributing to Boost.Container and would be glad to focus on specific areas, documentation gaps, or small fixes that maintainers consider useful or high priority.