Re: [boost] [config] RFC PR 82

Subject: Re: [boost] [config] RFC PR 82
From: Domagoj Šarić (dsaritz_at_[hidden])
Date: 2015-11-24 11:29:07

On Tue, 17 Nov 2015 06:24:37 +0530, Andrey Semashev
<andrey.semashev_at_[hidden]> wrote:
> 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