Re: [boost] [config] RFC PR 82

Subject: Re: [boost] [config] RFC PR 82
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-11-16 19:54:37

On 2015-11-17 02:17, Domagoj Saric wrote:
>
> Hi everyone, I am finally getting back to (trying to) contributing some
> of my personal projects to Boost.
> For two of those, Err (https://github.com/psiha/err) and especially
> Functonoid (a C++11 generalization and rewrite of my previous
> Boost.Function related work) I need some lower level codegen and/or
> optimiser control functionality (i.e. portable macros wrapping toolset
> specific attributes and pragmas) that I've added to my personal fork of
> Boost.Config and which I've now submitted in the subject PR
> (https://github.com/boostorg/config/pull/82).
>
> I don't expect this PR to be accepted as is/'just like that' so I'm
> opening this thread where we can discuss which of those changes/macros
> are welcome, which need more work and which, for some reason, should not
> be part of Boost.Config (and which, in turn then, I have to move to some
> 'internal implementation headers' in libraries that will need them).

Personally, I'm in favor of adding these: BOOST_OVERRIDE, BOOST_FINAL. 
Although their implementation should be similar to other C++11 macros - 
they should be based on BOOST_NO_CXX11_FINAL and BOOST_NO_CXX11_OVERRIDE.

I would like to have BOOST_ASSUME (implemented without an assert, i.e. 
equivalent to your BOOST_ASSUME_UNCHECKED), BOOST_UNREACHABLE (again, 
without an assert, i.e. equivalent to your BOOST_UNREACHABLE_UNCHECKED). 
The reason for no asserts is that (a) Boost.Config should not depend on 
Boost.Assert and (b) I fear that having additional expressions before 
the intrinsic could inhibit the optimization. You can always add 
*_CHECKED versions of the macros locally, or just use asserts beside the 
macros. BOOST_ASSUME_ALIGNED might also be useful (hints the compiler 
that a pointer has at least the specified alignment).

I would have liked BOOST_HAS_CXX_RESTRICT to indicate that the compiler 
has support for the C99 keyword 'restrict' (or an equivalent) in C++ 
(the CXX in the macro name emphasizes that the feature is available in 
C++, not C). The BOOST_RESTRICT macro would be defined to that keyword 
or empty if there is no support. I don't see much point in the 
additional _PTR, _REF and _THIS macros.

I'm somewhat in favor of adding BOOST_NOVTABLE, although I doubt it will 
have much use in Boost libraries.

BOOST_MAY_ALIAS is probably a good addition. I have seen it 
reimplemented in multiple Boost libraries now.

The reason I'm in favor of all the above macros is that I had to 
implement and use most of them in Boost or other projects (some of them 
you will find in Boost.Log). I would have found a portable alternative 
useful.

BOOST_THREAD_LOCAL_POD is kind of controversial. I do use compiler-based 
TLS in my projects, including Boost.Log, so it would be a useful macro. 
But it's not an optimization - when you use it, the compiler support is 
required. There has to be a way to test if the support exists. I'm not 
sure Boost.Config is the right place for this. (BTW, you could use 
thread_local from C++11, when none of the lighter weight keywords are 
not available.)

I don't see much use in BOOST_ATTRIBUTES and related macros - you can 
achieve the same results with feature specific-macros (e.g. by using 
BOOST_NORETURN instead of BOOST_ATTRIBUTES(BOOST_DOES_NOT_RETURN)).

I don't see the benefit of BOOST_NOTHROW_LITE. Ditto 
BOOST_HAS_UNION_TYPE_PUNNING_TRICK (doesn't any compiler support this?).

I don't think BOOST_OVERRIDABLE_SYMBOL is a good idea, given that the 
same effect can be achieved in pure C++. Also, some compilers offer this 
functionality only as a pragma. Also, the naming is confusing.

Calling conventions macros are probably too specialized to functional 
libraries, I don't think there's much use for these. I would rather not 
have them in Boost.Config to avoid spreading their use to other Boost 
libraries.

Function optimization macros are probably too compiler and 
case-specific. Your choice of what is considered fast, small code, 
acceptable math optimizations may not fit others. Also, things like 
these should have a very limited use, as the user has to have the 
ultimate control over the build options.

If I missed anything then I probably didn't see it useful or didn't 
understand what it does.

> ps. I'll be on the (off) road for the next three weeks so I don't know
> when I'll be able to respond until I get back...

Then you probably chose an inconvenient moment to start this discussion.