Peter Dimov
Peter Dimov
Regardless of whether this is applied, develop needs to be merged to master. > (Until then I'm fine with GCC 4 users not having asserts) That's fine in principle, but...
This comes up periodically; the problem is that as_uint64 returns a reference to uint64_t, and when the active field is of type int64_t, even if the numeric value is unsigned,...
as_double can't give you a reference to double if the stored number is int64/uint64, though.
As I already said the number of times, the present behavior is technically correct, but this will continue to serve as a trap for unsuspecting users and we can compromise...
Changing the discriminant, yes.
> BTW, judging by the comments in this issue, the main source of confusion is not that value::as_uint64 throws when the value stores an int64_t, but that the parser stores...
See also https://github.com/boostorg/json/issues/845 and https://github.com/boostorg/json/issues/917.
No, sorry. The project name is significant and changing it just to rename the .sln file is not the right fix. You should ask in [the CMake discourse](https://discourse.cmake.org/) whether there's...
"Boost" is the name of the superproject. The libraries have their own project names ("boost_lib").
``` target_include_directories(boost_pfr INTERFACE $ $) ``` is wrong for at least two reasons. First, `$` means `${CMAKE_INSTALL_PREFIX}/include`, which is not correct when CMAKE_INSTALL_INCLUDEDIR is not set to the default `include`....