|
Boost : |
Subject: Re: [boost] ATTENTION: Library requirements..
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-01-09 22:10:35
On 1/9/2016 5:01 PM, Soul Studios wrote:
> I would also like to see guidelines for the use of small custom macros
> in boost libraries.
>
> I don't mean the use of already-defined compiler-feature macros like
> BOOST_NOEXCEPT etc, I mean defining small macros for the sole purposes
> of a single library.
By far the best solution regarding macros in a Boost library is that
every macro for library 'xxx' start with the prefix of BOOST_'XXX'_ etc.
Both the Boost PP and Boost VMD macro libraries use this technique and I
see no reason why it can't be extended to all other Boost libraries. I
understand many developers like the brevity of shorter macro names but
the chance for macro clashes with other code, as well as the chance for
macro clashes with specifically other Boost library code, increases
drastically when this technique is not used.
I do understand that Boost.config macros do not use the above technique
but Boost.confifg being such a special case and so central to all other
Boost libraries, it can be forgiven for its BOOST_'XXX' brevity.
>
> I have a number of situations in a prospective library where small macro
> #defines (#undef'ing at the end of the header) which change their
> definition based on the availability of specific compiler features
> (allocator traits, for example), are the most elegant solution- for
> various reasons but largely because the alternatives are either a lot of
> "#ifdef COMPILER_FEATURE"-type code replication,
> or single-line template-based inline functions which will
> (a) slow compilation time,
> (b) not be correctly optimised or inlined by most microsoft compilers, and
> (c) make for ugly code (subjective, but there it is).
>
> I can't find anything in your documentation, so I just thought I'd ask
> if there are any definitive guidelines around the use of small macros in
> boost libraries.
> If so can they be included-
> Cheers,
> Matt
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk