Re: [boost] [config] RFC PR 82

Subject: Re: [boost] [config] RFC PR 82
From: Joel FALCOU (joel.falcou_at_[hidden])
Date: 2015-11-20 04:19:37

For informations:

https://github.com/boostorg/config/pull/81

is the RESTRICT macro I extracted from Boost.SIMD.

On 17/11/2015 01:54, Andrey Semashev wrote:
> 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.
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>