lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] libstdc++ concept checks vs std::regex


From: Vadim Zeitlin
Subject: Re: [lmi] libstdc++ concept checks vs std::regex
Date: Tue, 17 May 2016 17:22:17 +0200

On Tue, 17 May 2016 13:08:05 +0000 Greg Chicares <address@hidden> wrote:

GC> Apparently we can either abandon libstdc++'s concept checks (which
GC> do have some value),

 Sorry, I hadn't even realized that we were using them until today, so I'm
not really qualified to judge how much value do they have. Out of
curiosity, have they ever helped you to find any problems so far?

GC> or not use some set of C++11 features that I
GC> cannot today enumerate beyond demonstrating that it includes <regex>.

 Looking at the errors, it seems that libstdc++ concepts is just
fundamentally incompatible with move-only types, as it complains about the
lack of assignment operator even when a move assignment operator exists and
can be used. If this is correct, it makes libstdc++ concepts incompatible
with huge chunks of C++11 standard library and we just can't continue using
them.

GC> https://gcc.gnu.org/onlinedocs/libstdc++/manual/concept_checking.html
GC> | Please note that the checks are based on the requirements in the
GC> | original C++ standard, many of which were relaxed in the C++11
GC> | standard and so valid C++11 code may be incorrectly rejected by
GC> | the concept checks. Additionally, some correct C++03 code might be
GC> | rejected ... There are no plans to address these shortcomings.
GC>                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
GC> 
GC> Does this mean it has gone the way of '-fcheck-memory-usage'?

 I definitely think so. GCC 6 includes an implementation of concepts such
as were proposed for inclusion in (but finally rejected) C++17 (see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4377.pdf) with the
new -fconcepts flag. I'm far from sure that this is the final form of
concepts in C++, but I'm quite certain that any future work will happen in
this direction and not at libstdc++ level.

GC>   https://gcc.gnu.org/ml/gcc/2002-02/msg00666.html
GC> | Basically, it just didn't work any more, and it was decided to take it
GC> | out to not create false expectations.
GC> Is an alternative tool available to perform concept checking?

 FWIW I've just rebuilt lmi using g++-6 with -fconcepts without any
problems.

GC> Or should we even consider defining the concept-checking macros
GC> only for code that doesn't use any of this as-yet-unknown set of
GC> modern C++ features?

 I don't think this is feasible nor desirable.


 As I wrote in the beginning of this email, it's hard to me to judge the
cost of abandoning the use of libstdc++ concepts as I've never seen any
benefit of using them in the first place, but I seriously doubt it's
anywhere near the cost of not fully using C++11 standard library, so I'd
just remove _GLIBCXX_CONCEPT_CHECKS from workhorse.make unless there is
some benefit to keeping it that I'm completely missing.

 Regards,
VZ


reply via email to

[Prev in Thread] Current Thread [Next in Thread]