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.