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.