boostorg / array Goto Github PK

Defining overloads in namespace std is undefined behavior, so I'm wondering why we're adding overloads of std::get for boost::array. Since we aren't specializing std::tuple_size or std::tuple_element, these overloads would never be used anyway, even if they were legal.

Hello, there is an off-by-one error in the range check for at(). The function at() doesn't throw an exception if the index is the size of the array.
The following program doesn't throw the expected exception.

#include <boost/array.hpp>
#include <iostream>

int main()
{
       boost::array<int,1> a;
       try {
                a.at(1) = 12;
        } catch (const std::out_of_range& e) {
                std::cerr << e.what() << std::endl;
        }
        return 0;
}

The cause of this error is a wrong comparison in rangecheck(), which can be fixed with following patch:

diff --git a/include/boost/array.hpp b/include/boost/array.hpp
index 210c072..99dc2c6 100644
--- a/include/boost/array.hpp
+++ b/include/boost/array.hpp
@@ -183,7 +183,7 @@ namespace boost {
 
         // check range (may be private because it is static)
         static BOOST_CONSTEXPR bool rangecheck (size_type i) {
-            return i > size() ? boost::throw_exception(std::out_of_range ("array<>: index out of range")), true : true;
+            return i >= size() ? boost::throw_exception(std::out_of_range ("array<>: index out of range")), true : true;
         }
 
     };

I'm seeing a warning being emitted by this library when I'm using Xcode 10.3:

Possible misuse of comma operator here

Initially I thought of making a PR to address it, but I don't really understand the expression at that line. Why is boost::throw_exception followed by , true ?

Is this note up to date?

CMakeLists.txt have been added across many if not most libraries now, and Boost.Array seems to be missing the following

1. project(boost_array VERSION "${BOOST_SUPERPROJECT_VERSION}" LANGUAGES CXX)

2. Install

# boost_install requires PROJECT_VERSION
# Without the superproject, we don't have any, so skip installation
if(BOOST_SUPERPROJECT_VERSION)
  include(BoostInstall)
  boost_install(TARGETS boost_assert HEADER_DIRECTORY include/)
endif()

3. Tests

# BUILD_TESTING is the standard CTest variable that enables testing
if(BUILD_TESTING)
  add_subdirectory(test)
endif()

Question is if these are applicable or perhaps Boost.Array has a different plan.

We are in the process of making B2 build changes to all of the B2 build files
to support "modular" consumption of the Boost Libraries by users. See this list
post for some details: https://lists.boost.org/Archives/boost/2024/01/255704.php

The process requires making a variety of changes to make each Boost library
independent of the super-project structure. But the changes do not remove the
super-project structure or the comprehensive Boost release. The changes make
solely make it possible, optionally, for users, like package manages, to easily
consume libraries individually.

Generally the changes include:

• Adding a libroot/build.jam.
• Porting any functionality from libroot/jamfile to libroot/build.jam.
• Moving boost-install declaration from libroot/build/jamfile is applicable.
• Adjusting other B2 build files in the library, like test/jamfile, as needed.
• Possible changes to C++ source files to remove includes relative to the
  super-project boostroot location.

Some examples of such changes:

• boostorg/interval#38
• boostorg/ublas#189
• boostorg/local_function#10
• boostorg/preprocessor#57
• boostorg/callable_traits#194
• boostorg/compatibility#4
• boostorg/hof#228
• boostorg/preprocessor#56

We are asking how you would like us to handle the changes. We would prefer if
you allow the owners of the Boost.org GitHub project to make changes to B2
build files, as needed, to accomplish the changes. But understand
that you may want to manage the proposed changes yourself.

We previously sent emails to all known maintainers to fill out a form with their
preference. We are contacting you in this issue as we have not gotten a response
to that email. You can see the ongoing responses for that form and the responses
to these issues here https://github.com/users/grafikrobot/projects/1/views/6

We are now asking if you can reply directly to this issue to indicate your
preference of handling the changes. Please supply a response to this question
and close the issue (so that we can verify you are a maintainer).

How would you like the build changes to be processed?

1. Pull request, reviewed and merged by a BOOSTORG OWNER.
2. Pull request, reviewed and merged by YOU.
3. Other. (please specify details in the reply)

Also please indicate any special instructions you want us to consider. Or other
information you want us to be aware of.

Thanks you, René