Re: [boost] [1.75 release] Merging 'develop' to 'master' for Embarcadero fix

On 10/28/2020 3:29 PM, Vinnie Falco via Boost wrote:

On Wed, Oct 28, 2020 at 11:11 AM Edward Diener via Boost wrote:

...

A number of libraries have my PR to enable Embarcadero C++ clang-based compilers for Boost in their 'develop' branch

What about new libraries, such as Boost.JSON?

I should have explained the issue with Boost and Embarcadero although I thought I did so in the past. Here is the issue. The test for Borland/Codegear/Embarcadero workarounds in code should not solely rely on a test for the preprocessor symbol __BORLANDC__ and.or __CODEGEARC__. Instead the test must be done in either of two ways: 1) If config.hpp has already been include in the TU, any test for __BORLANDC__ should be the same test using BOOST_BORLANDC instead and any test for __CODEGEARC__ should be the same test using BOOST_CODEGEARC instead. 2) If config.hpp has not already been included in a TU, any test for __BORLANDC__ should be a test for !defined(__clang__) && __BORLANDC__ and any test for __CODEGEARC__ should be a test for !defined(__clang__) && __CODEGEARC__ . The reason for this is that the Embarcadero C++ clang-based compilers also define both __BORLANDC__ and __CODEGEARC__ but almost never need the manifold workarounds that the old bcc32 compiler, which also defines those preprocessor symbols, need, since the clang-based compilers are much more compliant to the C++ standard than the old bcc32 compiler is. To test for the Embarcadero C++ clang-based compilers, in case a specific workaround is needed for those compilers you can either simply test for BOOST_EMBTC if config.hpp has already been included, or test for defined(__clang__) and __BORLANDC__ or defined(__clang__) and __CODEGEARC__ if config.hpp has not been included. I can not be expected to endlessly go through a new library's code correcting __BORLANDC__ or __CODEGEARC__ workarounds to their correct equivalents, so please if you have such workarounds in your new code make the changes as explained above. Better yet, if you have such __BORLANDC__ or __CODEGEARC__ workarounds for new library code as an attempt to build/use your library with the old bcc32 compiler, I would strongly recommend to just get rid of them entirely. There is almost a 0% chance that the bcc32 compiler can use your new library in any way.