On Tue, 17 Nov 2015 06:24:37 +0530, Andrey Semashev
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 agree, but what if you don't have final but do have sealed (with a less recent MSVC)?
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.
The additional expressions are assert macros which resolve to nothing in release builds (and thus have no effect on optimisations...checked;) Dependency on Boost.Assert is technically only there if you use the 'checked' macros...I agree that it is still 'ugly' (and the user would have to separately/explicitly include boost/assert.hpp to avoid a circular dependency) but so is, to me, the idea of having to manually duplicate/prefix all assumes with asserts (since I like all my assumes verified and this would add so much extra verbosity)...
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.
Sure I can add the detection macro but for which 'feature set' (already for minimal - only pointers, or only for full - pointers, refs and this)?
I don't see much point in the additional _PTR, _REF and _THIS macros.
These are unfortunately required because of sloppiness on the part of MSVC devs: initially they added __restrict only for pointers, then after nagging in 2015 they finally added it for references but seems more nagging is required to get restricted this :/
I'm somewhat in favor of adding BOOST_NOVTABLE, although I doubt it will have much use in Boost libraries.
It's about paving a way for a standard(ised) class attribute ;)
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. out 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.)
That one is not about optimisation rather about lack of C++11 thread_local, for a foreseeable future, on OSX as a good enough solution for PODs. As for the test macro, you are right it should be added...
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)).
Yes, I may change those...I was however 'forward thinking' WRT attributes standardization (so that the BOOST_ATTRIBUTES(BOOST_DOES_NOT_RETURN) macros look like 'one day' [[noreturn]]) and 'backward thinking' i.e. compatibility - since some compilers want attributes at the end and some at the front - in which case BOOST_ATTRIBUTES would need to be further changed expanded into a function declaration macro (BOOST_F_DECL( return_type, calling_convention, parameters, attributes ))...
I don't see the benefit of BOOST_NOTHROW_LITE.
It's a nothrow attribute that does not insert runtime checks to call std::terminate...and it is unfortunately not offered by Boost.Config...
Ditto BOOST_HAS_UNION_TYPE_PUNNING_TRICK (doesn't any compiler support this?).
'I'm all with you on this one' but since 'it is not in the standard' language purists will probably complain if it is used unconditionally... (I need this and the *ALIAS* macros for a rewrite/expansion of Boost.Cast, that includes 'bitwise_cast', a sort of generic, safe&optimal reinterpret_cast)...
I don't think BOOST_OVERRIDABLE_SYMBOL is a good idea, given that the same effect can be achieved in pure C++.
You mean creating a class template with a single dummy template argument and a static data member just so that you can define a global variable in a header w/o linker errors?
Also, some compilers offer this functionality only as a pragma.
You mean in a way that would require a _BEGIN and _END macro pair?
Also, the naming is confusing.
I expected it to 'create some friction' - basically I want(ed) a portable __declspec( selectany )... (although selectany also has 'discardable symbol' semantics - since the MSVC linker will not by default discard unused global data)...
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.
That's kind of self-contradicting, if there is a 'danger' of them being used in other libraries that would imply there is a 'danger' from them being useful... In any case, I agree that most of those would mostly be used only in functional libraries but for HPC and math libraries especially, the *REG*/'fastcall' conventions are useful when they cannot (e.g. on ABI boundaries) or do not want to rely on the compiler (IPO, LTCG etc.) to automatically choose the optimal/custom calling convention...Admittedly this is mostly useful on targets with 'bad default' conventions, like 32bit x86 and MS x64, but these are still widely used ABIs :/
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.
If the indisputable goal (definition of 'good codegen') is to have fast and small code/binaries then 'I have to disagree'. For example a library dev can certainly know that certain code will never be part of a hot block (assuming correct usage of the library), for example initialisation, cleanup or error/failure related code and should thus be optimised for size (because that is actually optimising for real world speed - reducing unnecessary bloat - IO and CPU cache thrashing). Further more, you can even know that some code will/should always be in a cold path (and should be decorated with the cold rather than just minsize attribute), e.g. noreturn functions...etc... Ditto for 'fastmath&co': e.g. for FFT you know that float arithmetic operations can safely be reordered (and also need every last bit of speed) while for Kahan sum one must not allow associative floating point arithmetic - if you explicitly set those for the affected code you also leave the user the freedom to choose the 'fastmath' setting for the rest of the code... A HPC library dev is actually supposed to know which functions/loops are hot/crucial and should thus mark those as hot - this actually gives _more_ options to the user (if the lib is header only) as one can freely choose a global optimise-for-size switch (e.g. if one is mostly writing a GUI wrapper around the HPC lib) w/o hurting the performance/optimisation of the hot paths... @too compiler specific - even if you find such a case - 'ain't that what boost is for - standardising things?'
Also, things like these should have a very limited use, as the user has to have the ultimate control over the build options.
I'm 'more than all for ultimate control' - as explained above this can actually give more control to the user (+ Boost Build was already a major pain when it came to user control over changing compiler optimisation options in preexisting variants)...
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.
Yes of course, and no - as after so many 'delays' I finally 'had' to do it this way... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman --- Ova e-pošta je provjerena na viruse Avast protuvirusnim programom. https://www.avast.com/antivirus