boostorg / any Goto Github PK

The reference links on

https://www.boost.org/doc/libs/1_83_0/doc/html/any.html

go to

https://www.boost.org/doc/libs/1_83_0/doc/html/reference_section.html

which is the reference for PFR, not Any.

Please implement the below

template <typename ValueType>
constexpr operator ValueType() const {return boost::any_cast<ValueType>(*this);}

As it makes the code look nicer

std::string foo = "Hello World!\n";
boost::any value = foo;
std::cout << (std::string)value;

Add a templated parameter to the basic_any class which, if true, results of a compile-time error if the basic_any is assigned a too large object.

Example
struct Small{int x;};
struct Big{int x, y, z, w;};
auto a = boost::small_any<4, 4, true>{};
a = Small{};
a = Big{}; // static_assert(sizeof(T) <= OptimizeForSize) breaks the compilation

Complete list of warnings when Boost 1.72 is built with GCC 7.5 with -Wsuggest-override added to cxxflags. Duplicated warnings from same location are omitted::

./boost/any.hpp:190:56: warning: ‘const type_info& boost::any::holder::type() const [with ValueType = bool; boost::typeindex::type_info = std::type_info]’ can be marked override [-Wsuggest-override]
./boost/any.hpp:195:35: warning: ‘boost::any::placeholder* boost::any::holder::clone() const [with ValueType = bool]’ can be marked override [-Wsuggest-override]
./boost/any.hpp:241:30: warning: ‘virtual const char* boost::bad_any_cast::what() const’ can be marked override [-Wsuggest-override]

BOOST_OVERRIDE was introduced in boostorg/config@ffe4e0f.

Add a variant of boost::any which accepts move-only object such as std::unique_ptr (and therefore, the boost::any is move-only itself)

This is from the mailing list, with an excellent summary from @pdimov :

Chris Rorvick wrote:

I am seeing my GCC ubsan builds littered with "downcast of address
xxxxxxxx which does not point to an object of type 'holder'" errors [3]
coming from Boost.Program_options (Boost 1.69). The issue has been
documented in various places [1][2] but I do not see anything on the
mailing list in recent months; apologies if I have missed something.

A workaround is proposed on the StackOverflow post [1]. Does anyone have
any thoughts on this?

Many thanks!

Chris

[1]
https://stackoverflow.com/questions/38987728/why-does-boostany-exhibit-undefined-behaviour-in-boostprogram-options
[2] boostorg/program_options#76
[3]
.../boost/boost/any.hpp:249:17: runtime error: downcast of address
0x602000053610 which does not point to an object of type 'holder'
0x602000053610: note: object is of type 'boost::any::holderstd::string'
6f 00 80 67 d0 91 ec 88 fe 7f 00 00 68 33 09 00 40 60 00 00 00 00
00 00 00 00 00 00 00 00 00 00
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'boost::any::holderstd::string'
...

This doesn't seem to be the same issue as in the SO link. The cv qualifiers
are now being stripped by the constructor at

https://github.com/boostorg/any/blob/develop/include/boost/any.hpp#L49

twice (once by decay and once by remove_cv for added safety) and in your
message the held object is non-const:

note: object is of type 'boost::any::holderstd::string'

My guess is that holder needs BOOST_SYMBOL_VISIBLE. That is,

template<typename ValueType>
class holder : public placeholder

at
https://github.com/boostorg/any/blob/develop/include/boost/any.hpp#L168-L169
needs to be

template<typename ValueType>
class BOOST_SYMBOL_VISIBLE holder : public placeholder

Right now it is possible to use Boost.Any with types that require special alignment (sse intrinsics, Eigen3 data types, ...) by overriding the global operators new and delete. This solution is far from optimal, since it results in everything in the whole program being overaligned.

I'm opening this Request For Comments to discuss a possibly better solution to this problem.

The gist of the idea is for Boost.Any to store a polymorphic allocator (of possibly zero size), such that the user can provide an allocator when initializing/assigning/copying an any object.

This increases the API of Boost.Any (changes proposed below). It also decreases its performance, since allocating/deallocating memory would incur an extra virtual function call. It might also increase the size of the any object. One has, however, to consider the impact of the current workarounds in larger programs. Over-aligning all allocations might have a larger impact on performance and memory footprint than the proposed changes.

I think the following interface should be enough:

    any(polymorphic_allocator allocator = default_allocator()); 

    any(const any &, polymorphic_allocator allocator = default_allocator()); 

    any(any &&, polymorphic_allocator allocator = default_allocator()); 

    template<typename ValueType> any(const ValueType &, polymorphic_allocator allocator = default_allocator()); 

    template<typename ValueType> any(ValueType &&, polymorphic_allocator allocator = default_allocator()); 

Issue imported from https://svn.boost.org/trac10/ticket/11045
Reported by: gonzalobg88@…