Boost logo

Boost :

From: Edward Diener (eldiener_at_[hidden])
Date: 2020-10-28 23:30:00


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
> <boost_at_[hidden]> 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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk