[config] Rethinking feature macros?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[config] Rethinking feature macros?

Boost - Dev mailing list
Now that there are standard feature-testing macros
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0096r5.html) that
are being implemented by at least g++ and clang++, would it perhaps make
sense for us to reevaluate our decision to provide negative macros in
Boost.Config and start defining the standard feature macros instead on the
compilers that don't support them?

This would seem to require less maintenance, and the feature macro can be
used without waiting for Boost.Config to add it.

For a concrete example, let's take noexcept in function types. This is
__cpp_noexcept_function_type, and is implemented by g++ 7, clang 4, clang 5
(in C++17 mode), and apparently in the latest VS2017 preview.

noexcept function pointers break Boost.Bind, and to fix it, I need to add
overloads for them, but only if they are implemented, otherwise the
overloads would be an error.

With the feature macro, I can just #ifdef __cpp_noexcept_function_type and
it will immediately work on g++ and clang++ and all compilers that don't
support noexcept function types will still work. Only msvc would need to be
fixed in some way.

With our traditional approach, I would need to request the addition of
BOOST_NO_CXX17_NOEXCEPT_FUNCTION_TYPE, wait for it to be added and to be
present on every compiler except the latest ones (which requires changes
throughout Boost.Config), and only then be able to use #ifndef
BOOST_NO_CXX17_NOEXCEPT_FUNCTION_TYPE. (Then wait for it to be merged to
master before merging my changes to master.)


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Rethinking feature macros?

Boost - Dev mailing list
AMDG

On 11/05/2017 06:15 PM, Peter Dimov via Boost wrote:
> Now that there are standard feature-testing macros
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0096r5.html)
> that are being implemented by at least g++ and clang++, would it perhaps
> make sense for us to reevaluate our decision to provide negative macros
> in Boost.Config and start defining the standard feature macros instead
> on the compilers that don't support them?
>

I think it's probably a bad idea for Boost.Config
to try to define the standard feature macros.
- #defining third-party macros in library code is a recipe for
  ODR violations.
- It's easy for those using compilers with support for these
  macros to forget to #include <boost/config.hpp>.  There's
  also a good chance that the automated tests will pass for
  compilers without such support in this case, as it's quite
  common for the fallback implementation to work even if the
  feature is actually present.  (Or the corresponding tests
  might just end up being disabled as well.)

> This would seem to require less maintenance, and the feature macro can
> be used without waiting for Boost.Config to add it.
>
> For a concrete example, let's take noexcept in function types. This is
> __cpp_noexcept_function_type, and is implemented by g++ 7, clang 4,
> clang 5 (in C++17 mode), and apparently in the latest VS2017 preview.
>
> noexcept function pointers break Boost.Bind, and to fix it, I need to
> add overloads for them, but only if they are implemented, otherwise the
> overloads would be an error.
>
> With the feature macro, I can just #ifdef __cpp_noexcept_function_type
> and it will immediately work on g++ and clang++ and all compilers that
> don't support noexcept function types will still work. Only msvc would
> need to be fixed in some way.
>
> With our traditional approach, I would need to request the addition of
> BOOST_NO_CXX17_NOEXCEPT_FUNCTION_TYPE, wait for it to be added and to be
> present on every compiler except the latest ones (which requires changes
> throughout Boost.Config), and only then be able to use #ifndef
> BOOST_NO_CXX17_NOEXCEPT_FUNCTION_TYPE. (Then wait for it to be merged to
> master before merging my changes to master.)
>

In Christ,
Steven Watanabe


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Rethinking feature macros?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 11/5/2017 8:15 PM, Peter Dimov via Boost wrote:

> Now that there are standard feature-testing macros
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0096r5.html)
> that are being implemented by at least g++ and clang++, would it perhaps
> make sense for us to reevaluate our decision to provide negative macros
> in Boost.Config and start defining the standard feature macros instead
> on the compilers that don't support them?
>
> This would seem to require less maintenance, and the feature macro can
> be used without waiting for Boost.Config to add it.
>
> For a concrete example, let's take noexcept in function types. This is
> __cpp_noexcept_function_type, and is implemented by g++ 7, clang 4,
> clang 5 (in C++17 mode), and apparently in the latest VS2017 preview.
>
> noexcept function pointers break Boost.Bind, and to fix it, I need to
> add overloads for them, but only if they are implemented, otherwise the
> overloads would be an error.
>
> With the feature macro, I can just #ifdef __cpp_noexcept_function_type
> and it will immediately work on g++ and clang++ and all compilers that
> don't support noexcept function types will still work. Only msvc would
> need to be fixed in some way.
>
> With our traditional approach, I would need to request the addition of
> BOOST_NO_CXX17_NOEXCEPT_FUNCTION_TYPE, wait for it to be added and to be
> present on every compiler except the latest ones (which requires changes
> throughout Boost.Config), and only then be able to use #ifndef
> BOOST_NO_CXX17_NOEXCEPT_FUNCTION_TYPE. (Then wait for it to be merged to
> master before merging my changes to master.)

I brought up SD-6 for Boost Config some time ago, but the original
objection was that a great deal of the standard c++ header files would
have to be included by Boost Config to use most of SD-6. While I see in
your link that a number of the __cpp_... macros are predefined, like
your example __cpp_noexcept, a number of other __cpp_... macros require
header files to be included. So maybe Boost config can use macros which
are predefined without incurring the header file inclusion overhead of
those which require a header file to be included to determine if the
feature is present or not.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Rethinking feature macros?

Boost - Dev mailing list
Edward Diener wrote:

> I brought up SD-6 for Boost Config some time ago, but the original
> objection was that a great deal of the standard c++ header files would
> have to be included by Boost Config to use most of SD-6.

Config already uses the SD-6 macros when possible, but what I'm suggesting
is for it not to use it, but to define it when the implementation does not
support them, so that libraries can use them.

For correct use, the library would need to include both the standard header
defining the __cpp_lib_... macro and boost/config.hpp, as the macro could be
defined by either.

This is admittedly a bit more fragile than the present arrangement. Compiler
macros don't need a header to be included though, so for them, just
boost/config.hpp would be needed.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Rethinking feature macros?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 06/11/2017 01:15, Peter Dimov via Boost wrote:
> Now that there are standard feature-testing macros
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0096r5.html)
> that are being implemented by at least g++ and clang++,

VS2017 also supports them. It actually has a really high quality
implementation without the spelling mistakes certain other compilers have :)

> would it perhaps
> make sense for us to reevaluate our decision to provide negative macros
> in Boost.Config and start defining the standard feature macros instead
> on the compilers that don't support them?

The answer is no. The SD6 feature test macros in the latest proposal
paper are a tiny subset of those offered by Boost.Config. With latest
SD6, one ends up testing for some feature which you know is usually
associated with the one that you actually want due to the paucity of
feature macros.

I personally think the stripping of all the macros which used to be in
the proposal down to the current minimum viable set is a mistake. But
the argument is that these macros are for a future C++ standard, not the
current standard. You may have heard that the WG21 convenor got annoyed
at how much dependence on those macros was already appearing in the C++
ecosystem when the proposed set wasn't close to entering the standard
yet. This led to the stripping to discourage usage until they enter a
future standard. And thus, very recent compilers actually have removed
feature test macros, thus breaking my code which then thinks such and
such a feature is not implemented. Which is quite annoying.

Boost.Config, in comparison, will not break your code on new compilers,
usually.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Rethinking feature macros?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Steven Watanabe wrote:

> I think it's probably a bad idea for Boost.Config to try to define the
> standard feature macros.
>
> - #defining third-party macros in library code is a recipe for ODR
> violations.

There is no difference between defining __cpp_foo and BOOST_NO_CXX17_FOO as
far as ODR violations are concerned. In both cases, before the inclusion of
boost/config.hpp the macro isn't set, and after the inclusion, it may be.

> - It's easy for those using compilers with support for these macros to
> forget to #include <boost/config.hpp>.  There's also a good chance that
> the automated tests will pass for compilers without such support in this
> case, as it's quite common for the fallback implementation to work even if
> the feature is actually present.  (Or the corresponding tests might just
> end up being disabled as well.)

This is unfortunately a good point, and this new approach is indeed more
fragile than the old one WRT forgetting to include boost/config.hpp. But on
the other hand, the old one suffers from the problems I outlined.

Ideally, MSFT would be persuaded to implement the macros, but until then...


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Rethinking feature macros?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Niall Douglas wrote:
> On 06/11/2017 01:15, Peter Dimov via Boost wrote:
> > Now that there are standard feature-testing macros
> > (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0096r5.html)
> > that are being implemented by at least g++ and clang++,
>
> VS2017 also supports them.

It does? Which macros does VS2017 define?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Rethinking feature macros?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Niall Douglas wrote:

> And thus, very recent compilers actually have removed feature test macros,
> thus breaking my code which then thinks such and such a feature is not
> implemented. Which is quite annoying.

Do you have specific examples of macros being removed?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Rethinking feature macros?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
AMDG

On 11/05/2017 07:30 PM, Peter Dimov via Boost wrote:

> Steven Watanabe wrote:
>
>> I think it's probably a bad idea for Boost.Config to try to define the
>> standard feature macros.
>>
>> - #defining third-party macros in library code is a recipe for ODR
>> violations.
>
> There is no difference between defining __cpp_foo and BOOST_NO_CXX17_FOO
> as far as ODR violations are concerned. In both cases, before the
> inclusion of boost/config.hpp the macro isn't set, and after the
> inclusion, it may be.
>

This is only true assuming that
a) The only uses of these macros are inside Boost or
   by Boost users who explicitly #include Boost.Config
   to get them and,
b) No other (unrelated to Boost) library chooses to
   implement the same idea OR such a library is
   never used in the same translation unit as Boost.Config
   OR the definitions are exactly identical to Boost.Config
   (If the implementation of a feature is incomplete or buggy,
   different people may make different choices about whether
   to #define the feature macro).

In Christ,
Steven Watanabe


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Rethinking feature macros?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
>> VS2017 also supports them.
>
> It does? Which macros does VS2017 define?

The ones in the latest SD-6 proposal. And only those, not the ones which
used to be in there.

> Do you have specific examples of macros being removed?
You will see a raft of macros in:

https://github.com/ned14/quickcpplib/blob/master/include/cpp_feature.h

... which have been commented out with four ////. Those are vanishing
from compilers like clang trunk, so I thought it best to purge the
purged macros from my code.

That file is probably out of date, they probably have purged some more
SG-6 feature test macros by now. I can see them removing all the C++ 11
and C++ 14 feature tests before it goes for standardisation, though I
daresay standard library implementers will howl about it. But I guess it
stops people jumping that SG proposal into a fait accompli
standardisation before it's ready.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Rethinking feature macros?

Boost - Dev mailing list
Niall Douglas wrote:
> >> VS2017 also supports them.
> >
> > It does? Which macros does VS2017 define?
>
> The ones in the latest SD-6 proposal. And only those, not the ones which
> used to be in there.

That's not what I'm seeing here. VS2017 supports structured bindings but
__cpp_structured_bindings is not defined.

#include <iostream>

struct X
{
    int a, b;
};

int main()
{
    X x{ 1, 2 };
    auto [a, b] = x;

#ifdef __cpp_structured_bindings

    std::cout << "__cpp_structured_bindings: " << __cpp_structured_bindings
<< std::endl;

#else

    std::cout << "__cpp_structured_bindings: not defined" << std::endl;

#endif
}


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Rethinking feature macros?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 11/06/17 04:15, Peter Dimov via Boost wrote:
> Now that there are standard feature-testing macros
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0096r5.html)
> that are being implemented by at least g++ and clang++, would it perhaps
> make sense for us to reevaluate our decision to provide negative macros
> in Boost.Config and start defining the standard feature macros instead
> on the compilers that don't support them?

I think this is a bad idea. Boost.Config macros do not necessarilly
correspond to what the compiler defines. Compilers lie sometimes by
defining a macro while the corresponding feature is broken. Besides, I
believe this is not Boost's prerogative to define compiler and standard
library-specific macros.

Also, on the std-proposals list (IIRC) there was a discussion about SD-6
macros, and there were even initiatives to entirely drop the whole idea.
The future of SD-6 is not quite clear, IMHO. At least, library-specific
macros have very limited use and are prime candidates for changes or
plain removal.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Rethinking feature macros?

Boost - Dev mailing list
Andrey Semashev wrote:

> Besides, I believe this is not Boost's prerogative to define compiler and
> standard library-specific macros.

Steven made the same good point - we should not define these macros because
someone else may decide to do it too.

> Boost.Config macros do not necessarilly correspond to what the compiler
> defines. Compilers lie sometimes by defining a macro while the
> corresponding feature is broken.

That's true in principle but I've found this practice questionable and can't
help but note that in my specific example of __cpp_noexcept_function_type,
if Config doesn't define the macro my code will break, regardless of whether
the feature is broken. I want to know if the feature is present, not whether
someone arbitrarily considers it broken. But that's really a side issue.

> Also, on the std-proposals list (IIRC) there was a discussion about SD-6
> macros, and there were even initiatives to entirely drop the whole idea.

I don't remember a time when this wasn't the case.

The objections to the specific idea of defining SD-6 macros in Config are
solid, but nobody has said anything about the inefficiencies in our current
approach that are caused by us defining negative macros instead of positive
ones. We can avoid the problem of not being allowed to define "foreign"
macros by having our own names for them and defining them automatically when
the standard macro is defined.

#ifdef __cpp_noexcept_function_type
# define BOOST_CPP_NOEXCEPT_FUNCTION_TYPE
#endif

Positive macros suffer from the problem of one forgetting to include
config.hpp a bit more than negative macros do, but using our names avoids
the other problem Steven brings up, that things would silently work in this
case on g++/clang++.

(Of course the above doesn't work for library macros because we don't want
to include the whole STL but we still can use positive macros there, we just
need to define them ourselves appropriately.)


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Rethinking feature macros?

Boost - Dev mailing list
On 11/6/2017 7:45 AM, Peter Dimov via Boost wrote:

> Andrey Semashev wrote:
>
>> Besides, I believe this is not Boost's prerogative to define compiler
>> and standard library-specific macros.
>
> Steven made the same good point - we should not define these macros
> because someone else may decide to do it too.
>
>> Boost.Config macros do not necessarilly correspond to what the
>> compiler defines. Compilers lie sometimes by defining a macro while
>> the corresponding feature is broken.
>
> That's true in principle but I've found this practice questionable and
> can't help but note that in my specific example of
> __cpp_noexcept_function_type, if Config doesn't define the macro my code
> will break, regardless of whether the feature is broken. I want to know
> if the feature is present, not whether someone arbitrarily considers it
> broken. But that's really a side issue.
>
>> Also, on the std-proposals list (IIRC) there was a discussion about
>> SD-6 macros, and there were even initiatives to entirely drop the
>> whole idea.
>
> I don't remember a time when this wasn't the case.
>
> The objections to the specific idea of defining SD-6 macros in Config
> are solid, but nobody has said anything about the inefficiencies in our
> current approach that are caused by us defining negative macros instead
> of positive ones. We can avoid the problem of not being allowed to
> define "foreign" macros by having our own names for them and defining
> them automatically when the standard macro is defined.
>
> #ifdef __cpp_noexcept_function_type
> # define BOOST_CPP_NOEXCEPT_FUNCTION_TYPE
> #endif

This is a better idea, if only to align Boost Config macro names with
the SD-6 macros.

>
> Positive macros suffer from the problem of one forgetting to include
> config.hpp a bit more than negative macros do, but using our names
> avoids the other problem Steven brings up, that things would silently
> work in this case on g++/clang++.
>
> (Of course the above doesn't work for library macros because we don't
> want to include the whole STL but we still can use positive macros
> there, we just need to define them ourselves appropriately.)

Theoretically a good idea, but we then end up with defining Boost
equivalent SD-6 macros, where the compiler macros are based on SD-6 and
the library macros are based on Boost Config logic.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Rethinking feature macros?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 11/06/17 15:45, Peter Dimov via Boost wrote:

> Andrey Semashev wrote:
>
>> Boost.Config macros do not necessarilly correspond to what the
>> compiler defines. Compilers lie sometimes by defining a macro while
>> the corresponding feature is broken.
>
> That's true in principle but I've found this practice questionable and
> can't help but note that in my specific example of
> __cpp_noexcept_function_type, if Config doesn't define the macro my code
> will break, regardless of whether the feature is broken. I want to know
> if the feature is present, not whether someone arbitrarily considers it
> broken. But that's really a side issue.

I think we had multiple occasions when we disabled a feature that was
advertised as implemented in a compiler. Having Boost.Config declaring
the feature as available in such cases would not be helpful because the
actual code would still not work.

You need a macro that indicates that noexcept is part of the function
type. I'm not sure how any compiler that supports the feature can
support it incompletely/incorrectly, but until we have an actual case we
can't tell if that level of support is suitable for you. I'd say add
BOOST_NO_CXX17_NOEXCEPT_FUNCTION_TYPES and use it in Boost.Bind the way
we always did. When there appears a compiler that doesn't fit, we'll see
what is best. It is always possible to add compiler-specific exceptions
in Boost.Bind or define a special macro in Boost.Bind.

> The objections to the specific idea of defining SD-6 macros in Config
> are solid, but nobody has said anything about the inefficiencies in our
> current approach that are caused by us defining negative macros instead
> of positive ones.

I don't see much of a problem with the negative form. The idea is that
the macros indicate compiler defects wrt. the latest standard (plus the
positive form macros for non-standard features), which I think makes
sense. This way the number of defined macros tend to be always low on
good compilers, which is probably better than having them continuously
grow over time.

Anyway, I'm not particularly tied to either negative or positive form.
The process of adding a new macro seems to be the same in either case,
so I don't see much difference from the maintenance/submission cost
perspective. What I do prefer though is that we have *one* naming
approach, consistent across Boost and C++ versions. That significantly
reduces the cost of using the macros. We currently use the negative form
and I'm guessing we're not going to remove the current macros straight
away because of breaking tons of code. So I guess that's a point in
favor of the negative form.

> We can avoid the problem of not being allowed to
> define "foreign" macros by having our own names for them and defining
> them automatically when the standard macro is defined.
>
> #ifdef __cpp_noexcept_function_type
> # define BOOST_CPP_NOEXCEPT_FUNCTION_TYPE
> #endif
>
> Positive macros suffer from the problem of one forgetting to include
> config.hpp a bit more than negative macros do, but using our names
> avoids the other problem Steven brings up, that things would silently
> work in this case on g++/clang++.

I'm not sure "forgetting to include config.hpp" is a valid argument.
You're obviously using Boost.Config (that follows from the macro name),
so you should include its header. This would be less so obvious if we
decided to define __cpp_noexcept_function_type ourselves, which is
another point against that approach.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Rethinking feature macros?

Boost - Dev mailing list
Andrey Semashev wrote:

> I don't see much of a problem with the negative form. The idea is that the
> macros indicate compiler defects wrt. the latest standard (plus the
> positive form macros for non-standard features), which I think makes
> sense. This way the number of defined macros tend to be always low on good
> compilers, which is probably better than having them continuously grow
> over time.

This was the case ten years ago but not now. You can no longer derive any
quality metric by what a compiler supports. gcc 6 is not a non-good
compiler, it just defaults to C++14. VS 2017 15.3 is not a non-good
compiler, it's just not 15.5 yet. Given the new pace of the standard, there
will never be any longer a point at which a good compiler will be
macro-free, as there will always be things left to implement because they
were added after the compiler shipped.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Rethinking feature macros?

Boost - Dev mailing list
On 11/06/17 17:41, Peter Dimov via Boost wrote:

> Andrey Semashev wrote:
>
>> I don't see much of a problem with the negative form. The idea is that
>> the macros indicate compiler defects wrt. the latest standard (plus
>> the positive form macros for non-standard features), which I think
>> makes sense. This way the number of defined macros tend to be always
>> low on good compilers, which is probably better than having them
>> continuously grow over time.
>
> This was the case ten years ago but not now. You can no longer derive
> any quality metric by what a compiler supports. gcc 6 is not a non-good
> compiler, it just defaults to C++14. VS 2017 15.3 is not a non-good
> compiler, it's just not 15.5 yet. Given the new pace of the standard,
> there will never be any longer a point at which a good compiler will be
> macro-free, as there will always be things left to implement because
> they were added after the compiler shipped.

I'm not saying any given compiler is good or not, and that there is (or
should be) a macro-free compiler. I'm saying that having ~10 macros
defined for g++-7 -std=c++17 is probably better than ~100 macros. And
having ~10 (other) macros defined for g++-15 -std=c++22 is yet better
than ~200.

Also, another minor point. In the user's code, the #ifdef checks can be
viewed as workarounds for compilers not supporting a particular language
feature. Potentially, you could strip some of the conditionally compiled
code over time to raise the minimum bar of supported C++, thus reducing
the maintenance cost. This could even be done with a preprocessor. Of
course, that is not always as simple as that, but at least partially
this can be made to work. This can be done with positive form as well,
but I think it would be more complicated since you'd have to keep the
code instead of removing it.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Rethinking feature macros?

Boost - Dev mailing list
Andrey Semashev wrote:

> I'm saying that having ~10 macros defined for g++-7 -std=c++17 is probably
> better than ~100 macros. And
having ~10 (other) macros defined for g++-15 -std=c++22 is yet better than
~200.

You're refuting your own argument, because if g++-15 would need 200 positive
macros compared to g++-7's 100, g++-7 would need 100 negative macros.

There is no point in time at which both can do with 10.

The good thing about positive macros is that an old compiler never needs
maintenance. With negative macros you have to keep adding them to it.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Rethinking feature macros?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 11/06/17 05:15, Peter Dimov via Boost wrote:
> For a concrete example, let's take noexcept in function types. This is
> __cpp_noexcept_function_type, and is implemented by g++ 7, clang 4,
> clang 5 (in C++17 mode), and apparently in the latest VS2017 preview.
>
> noexcept function pointers break Boost.Bind, and to fix it, I need to
> add overloads for them, but only if they are implemented, otherwise
> the overloads would be an error.
>

Not really addressing the main question, but just out of curiosity, what
would be the downside of not relying on any macro but detecting the
feature automatically? For example, something like this could be done:

void n() noexcept {}
void e() {}

constexpr bool noexcept_function_type = !std::is_same< decltype( n ),
decltype( e ) >::value;

Now we can use this to SFINAE out the noexcept overloads when they'd be
problematic:

template < typename R >
R invoke0( R (*f)() )
{
     std::cout << "main overload" << std::endl;
     return f();
}

template < typename R >
std::enable_if_t< noexcept_function_type, R >
invoke0( R (*f)() noexcept )
{
     std::cout << "noexcept overload" << std::endl;
     return f();
}

void f1()
{
     std::cout << "f1" << std::endl;
}

void f2() noexcept
{
     std::cout << "f2" << std::endl;
}

int main()
{
     invoke0( f1 );
     invoke0( f2 );
}

Clang gives a warning for the noexcept overload in C++14 mode: "mangled
name of 'invoke0' will
       change in C++17 due to non-throwing exception specification in
function
       signature [-Wc++17-compat-mangling]", but that can be silenced by
surrounding that overload with

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wc++17-compat-mangling"

...

#pragma clang diagnostic pop

Didn't try with other compilers.

Thanks,
Gevorg

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Rethinking feature macros?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 11/06/17 18:32, Peter Dimov via Boost wrote:

> Andrey Semashev wrote:
>
>> I'm saying that having ~10 macros defined for g++-7 -std=c++17 is
>> probably better than ~100 macros. And
> having ~10 (other) macros defined for g++-15 -std=c++22 is yet better
> than ~200.
>
> You're refuting your own argument, because if g++-15 would need 200
> positive macros compared to g++-7's 100, g++-7 would need 100 negative
> macros.

g++-7 will be out of wide use by then, so it doesn't matter.

> The good thing about positive macros is that an old compiler never needs
> maintenance. With negative macros you have to keep adding them to it.

That is not more maintenance than adding positive macros for newer
compilers.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12