Hi folks, It's over 2 years since this post: http://boost.2283326.n4.nabble.com/New-powerful-way-to-use-enable-if-in-C-0x... The macro looks sweet and I wonder if we have this macro in Boost in case that I missed it. Thanks.
On 18/08/13 08:30, TONGARI J wrote:
Hi folks,
It's over 2 years since this post: http://boost.2283326.n4.nabble.com/New-powerful-way-to-use-enable-if-in-C-0x...
The macro looks sweet and I wonder if we have this macro in Boost in case that I missed it.
What's the practical reason of having a macro? The approaches suggested in the thread all have limitations. For example they require you to put some unique non-ambiguous type in all your overloads of a said function. The classical approach recommended for enable_if is still the best way to use SFINAE for a boolean meta-function or a boolean constant expression. For this one, you're better off just knowing what you're doing than to rely on macro magic.
2013/8/18 Mathias Gaunard <mathias.gaunard@ens-lyon.org>
On 18/08/13 08:30, TONGARI J wrote:
Hi folks,
It's over 2 years since this post: http://boost.2283326.n4.**nabble.com/New-powerful-way-** to-use-enable-if-in-C-0x-**td3442723.html<http://boost.2283326.n4.nabble.com/New-powerful-way-to-use-enable-if-in-C-0x-td3442723.html>
The macro looks sweet and I wonder if we have this macro in Boost in case that I missed it.
What's the practical reason of having a macro?
The approaches suggested in the thread all have limitations. For example they require you to put some unique non-ambiguous type in all your overloads of a said function.
The classical approach recommended for enable_if is still the best way to use SFINAE for a boolean meta-function or a boolean constant expression.
For this one, you're better off just knowing what you're doing than to rely on macro magic.
I should refer to this: http://lists.boost.org/Archives/boost/2011/08/184468.php Of course it's for C++11 only...
On 18/08/13 18:48, TONGARI J wrote:
I should refer to this:
http://lists.boost.org/Archives/boost/2011/08/184468.php
Of course it's for C++11 only...
Yes I've seen this. It's limited in somewhat unexpected ways, requires a lot of C++11 features to be correctly implemented, and also is unnecessarily inefficient at compile-time. I see no compelling advantage to using it instead of less obscure, more flexible, more portable and more efficient solutions.
There is a more up-to-date version of the ENABLE_IF family of macros in the boost sandbox (the enable_if directory). There is some brief (poor) quickbook-generated documentation that I wrote up that is also in the sandbox in the same directory, though I don't have it uploaded anywhere right now. In addition to the traditional enable_if functionality, there are also macros for expression-validity testing. Mathias, do you have any reason for the assertion that it's "unnecessarily inefficient" at compile time? Please post a comparison of compile-times and I'll optimize if necessary. Otherwise, for now I'd say just use the macros when you can and use std::enable_if or boost::enable_if if you have to. I've pretty much just used the macros for the past year or so. - Matt Calabrese On Sun, Aug 18, 2013 at 1:53 PM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
On 18/08/13 18:48, TONGARI J wrote:
I should refer to this:
Of course it's for C++11 only...
Yes I've seen this. It's limited in somewhat unexpected ways, requires a lot of C++11 features to be correctly implemented, and also is unnecessarily inefficient at compile-time.
I see no compelling advantage to using it instead of less obscure, more flexible, more portable and more efficient solutions.
______________________________**_________________ Unsubscribe & other changes: http://lists.boost.org/** mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>
-- -Matt Calabrese
On Sun, Aug 18, 2013 at 3:41 PM, Matt Calabrese <rivorus@gmail.com> wrote:
There is a more up-to-date version of the ENABLE_IF family of macros in the boost sandbox (the enable_if directory). There is some brief (poor) quickbook-generated documentation that I wrote up that is also in the sandbox in the same directory, though I don't have it uploaded anywhere right now. In addition to the traditional enable_if functionality, there are also macros for expression-validity testing.
Mathias, do you have any reason for the assertion that it's "unnecessarily inefficient" at compile time? Please post a comparison of compile-times and I'll optimize if necessary. Otherwise, for now I'd say just use the macros when you can and use std::enable_if or boost::enable_if if you have to. I've pretty much just used the macros for the past year or so.
Woops, sorry for bottom-quoting in that reply. I notice I have some local changes to the macros, I'll update the code and docs in the next few days and also upload the docs somewhere.
On 18/08/13 21:41, Matt Calabrese wrote:
Mathias, do you have any reason for the assertion that it's "unnecessarily inefficient" at compile time?
- It instantiates more templates (at least 4 instead of 1, and much worse if going through the function_traits path) - It increases symbol size. - It requires an additional name resolution and overload resolution step.
Please post a comparison of compile-times and I'll optimize if necessary. Otherwise, for now I'd say just use the macros when you can and use std::enable_if or boost::enable_if if you have to. I've pretty much just used the macros for the past year or so.
You just can't beat the efficiency of a single instantiation of a trivial class template like enable_if_c. Really I don't see how all that cost and portability concerns make it worthwhile to write template<class T, BOOST_ENABLE_IF(is_same<T, float>)) int f(T const&) { return 0; } instead of template<class T> typename enable_if< is_same<T, float> , int >::type f(T const&) { return 0; }
On Mon, Aug 19, 2013 at 10:38 AM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
On 18/08/13 21:41, Matt Calabrese wrote:
Mathias, do you have any reason for the assertion that it's "unnecessarily
inefficient" at compile time?
- It instantiates more templates (at least 4 instead of 1, and much worse if going through the function_traits path) - It increases symbol size. - It requires an additional name resolution and overload resolution step.
The first point is only true in the old implementation -- the one in the sandbox ditches the function type trick entirely and just directly instantiates an enable_if-style template. Right now, the template used inherits from boost::enable_if, but that inheritance can be eliminated if the additional instantiation implied by the base offends you. That would make the amount of instantiations exactly the same as a traditional enable_if approach Can you elaborate on your third point? What additional step are you talking about and show that it actually impacts compile-time. It's certainly possible that this approach has a compile-time impact over directly using enable_if, though I've used it extensively for over a year and haven't noticed. I haven't made a big, brute-force test for compile-time performance, but from the looks of it neither have you. Really I don't see how all that cost and portability concerns make it
worthwhile to write
template<class T, BOOST_ENABLE_IF(is_same<T, float>)) int f(T const&) { return 0; }
instead of
template<class T> typename enable_if< is_same<T, float> , int >::type f(T const&) { return 0;
}
The former doesn't hide the return type and is also able to be used in more places. In the case of the traditional enable_if approach you have a few considerations. When working with constructors, you can only use the parameter form. When dealing with most operator overloads you can only use the return type form. You can't use the return type nor the parameter form at all in some places (variadic constructors, conversion operators, etc.). You also can't use traditional enable_if if your condition doesn't depend on a template parameter. On the other hand, every single one of the aforementioned cases works perfectly fine with the template argument list form (I.E. the macro approach). It's one tool that fits all and it clutters neither the return type nor the function parameter list, making the declaration easy to read and to write. Further, the "lazy" forms in the macro approach are more capable than the boost::lazy_enable_if family of templates, since the macro allows you to introduce multiple, named, evaluated lazy types, which can be each easily be referenced in multiple parts of the function declaration or function body. As for portability concerns, you could argue the same about any library that uses C++11. It's already 2 years since C++11, with C++1y likely coming next year. GCC also supported the features required for this macro before the standard was ratified. If you don't have a compiler capable of using the macro or if your code needs to be portable to 03 compilers, or if you are afraid it will noticeably impact compile-times (without actually testing it), there's nothing stopping you from using boost::enable_if instead. I do not propose removing boost::enable_if or std::enable_if. -- -Matt Calabrese
On Mon, Aug 19, 2013 at 11:40 AM, Matt Calabrese <rivorus@gmail.com> wrote:
The first point is only true in the old implementation -- the one in the sandbox ditches the function type trick entirely and just directly instantiates an enable_if-style template. Right now, the template used inherits from boost::enable_if, but that inheritance can be eliminated if the additional instantiation implied by the base offends you. That would make the amount of instantiations exactly the same as a traditional enable_if approach Can you elaborate on your third point? What additional step are you talking about and show that it actually impacts compile-time. It's certainly possible that this approach has a compile-time impact over directly using enable_if, though I've used it extensively for over a year and haven't noticed. I haven't made a big, brute-force test for compile-time performance, but from the looks of it neither have you.
I've just eliminated the additional instantiations and committed the changes. If you want to test compile-time performance, do it based on that. Instantiations should be minimal now unless I missed something. -- -Matt Calabrese
From: TONGARI J Hi folks,
It's over 2 years since this post: http://boost.2283326.n4.nabble.com/New-powerful-way-to-use-enable-if-in-C-0x...
The macro looks sweet and I wonder if we have this macro in Boost in case that I missed it.
This is nice for C++11 and conversion operators, I was not aware of this trick. However, it would be nice if boost provided requires macros to make it easier to specify traits for enable_if. See here for an implementation: https://github.com/pfultz2/Zen/blob/master/zen/requires.h So functions can be defined like this: template<class T, class U> ZEN_FUNCTION_REQUIRES(is_arithmetic<T>, is_arithmetic<U>) (T) max(T x, U y) { return x > y : x ? y; } All the traits our inclusive by default, but the `exclude` keyword can be used to exclude the trait, like this: template<class T, class U> ZEN_FUNCTION_REQUIRES ( is_arithmetic<T>, is_arithmetic<U>, exclude is_same<T, bool>, exclude is_same<U, bool> ) (T) max(T x, U y) { return x > y : x ? y; } It can be used in classes like this: template<class T, ZEN_REQUIRES(is_integral<T>)> class A { ... }; Or this: template <class T, class Enable = void> class A { ... }; template <class T> class A<T, ZEN_CLASS_REQUIRES(is_integral<T>)> { ... }; template <class T> class A<T, ZEN_CLASS_REQUIRES(is_float<T>)> { ... }; This will all work on C++03 compilers as well. It could also be extended fairly easily to support the trick from Matt Calabrese. Plus, the `FUNCTION_REQUIRES` seems like it could be easily converted to use the `requires` and concept overloading when it gets added to the language as well. What do you think? Thanks, Paul Fultz II
On Sun, Aug 18, 2013 at 4:16 PM, paul Fultz <pfultz2@yahoo.com> wrote:
From: TONGARI J Hi folks,
It's over 2 years since this post:
http://boost.2283326.n4.nabble.com/New-powerful-way-to-use-enable-if-in-C-0x...
The macro looks sweet and I wonder if we have this macro in Boost in case that I missed it.
This is nice for C++11 and conversion operators, I was not aware of this trick. However, it would be nice if boost provided requires macros to make it easier to specify traits for enable_if. See here for an implementation:
https://github.com/pfultz2/Zen/blob/master/zen/requires.h
So functions can be defined like this:
template<class T, class U> ZEN_FUNCTION_REQUIRES(is_arithmetic<T>, is_arithmetic<U>) (T) max(T x, U y) { return x > y : x ? y; }
How is this different from: template< class T, class U , BOOST_ENABLE_IF( and_< is_arithmetic< T >, is_arithmetic< U > > ) > T max( T x, U y ) { /**/ } If you want to group requirements into a simple name, you can also use a typedef. As for the emulation stuff you are talking about, there's the "generic" directory in the sandbox, which is a library for concept emulation, though it's sort of in limbo. -- -Matt Calabrese
On 19/08/13 01:54, Matt Calabrese wrote:
On Sun, Aug 18, 2013 at 4:16 PM, paul Fultz <pfultz2@yahoo.com> wrote:
So functions can be defined like this:
template<class T, class U> ZEN_FUNCTION_REQUIRES(is_arithmetic<T>, is_arithmetic<U>) (T) max(T x, U y) { return x > y : x ? y; }
How is this different from:
template< class T, class U , BOOST_ENABLE_IF( and_< is_arithmetic< T >, is_arithmetic< U > > ) > T max( T x, U y ) { /**/ }
(T) here is passed to a macro name returned by ZEN_FUNCTION_REQUIRES. This allows to generate normal enable_if code.
From: Matt Calabrese <rivorus@gmail.com>
How is this different from:
template< class T, class U , BOOST_ENABLE_IF( and_< is_arithmetic< T >, is_arithmetic< U > > ) > T max( T x, U y ) { /**/ }
Besides being slightly more verbose, this only works in C++11.
If you want to group requirements into a simple name, you can also use a typedef.
Grouping requirements is extremely common. Using a typedef is the equivalent of creating a function object vs using a lambda. However, many times multiple requirements are created because there are multiple parameters, or to avoid ambiguities. Requirements need to be included and excluded in order to work around ambiguities. For example, to define an equals function that work recursively over ranges, and pairs, could be declared like this: template<class T, class U> ZEN_FUNCTION_REQUIRES(exclude is_pair<T>, exclude is_pair<U>, exclude is_range<T>, exclude is_range<U>) (bool) equals(const T& x, const U& y); template<class Range1, class Range2> ZEN_FUNCTION_REQUIRES(is_range<Range1>, is_range<Range2>) (bool) equals(const Range1& r1, const Range2& r2); template<class Pair1, class Pair2> ZEN_FUNCTION_REQUIRES(is_pair<Pair1>, is_pair<Pair2>, exclude is_range<Pair1>, exclude is_range<Pair2>) (bool) equals(const Pair1& p1, const Pair2& p2); The exclusion traits are necessary, since a pair of iterators is a range as well.(Of course, a better way to avoid ambiguities is to use `zen::conditional_adaptor`).
As for the emulation stuff you are talking about, there's the "generic" directory in the sandbox, which is a library for concept emulation, though it's sort of in limbo.
I was referring to the ConceptsLite proposal. Instead of `ZEN_FUNCTION_REQUIRES` using `enable_if` underneath, it could use the requires clause instead(for compilers that support it). Somethng like this(its just a rough idea): template<class Cond> constexpr bool has_traits() { return Cond::value; } #define ZEN_ERROR_PARENTHESIS_MUST_BE_PLACED_AROUND_THE_RETURN_TYPE(...) __VA_ARGS__ #define ZEN_FUNCTION_REQUIRES(...) \ requires has_traits<ZEN_DETAIL_REQUIRES_CLAUSE(__VA_ARGS__)>() ZEN_ERROR_PARENTHESIS_MUST_BE_PLACED_AROUND_THE_RETURN_TYPE It could be defined better as well to improve overloading. Paul Fultz II
On Mon, Aug 19, 2013 at 1:34 PM, paul Fultz <pfultz2@yahoo.com> wrote:
Besides being slightly more verbose, this only works in C++11.
Your example is also C++11, since it uses variadic macros.
If you want to group requirements into a simple name, you can also use a typedef.
Grouping requirements is extremely common. Using a typedef is the equivalent of creating a function object vs using a lambda. However, many times multiple requirements are created because there are multiple parameters, or to avoid ambiguities.
I understand that, but there is already a way to group them at the usage-site: you use and_. The macro can be changed to just automatically wrap everything in and_ and it will get the functionality you are looking for, I just don't think it's necessary, and as I'm sure Mathias would point out, it adds an extra instantiation if there is only one condition (as is frequently the case). Requirements need to be included and excluded in order to work
around ambiguities. For example, to define an equals function that work recursively over ranges, and pairs, could be declared like this:
template<class T, class U> ZEN_FUNCTION_REQUIRES(exclude is_pair<T>, exclude is_pair<U>, exclude is_range<T>, exclude is_range<U>) (bool) equals(const T& x, const U& y);
template<class Range1, class Range2> ZEN_FUNCTION_REQUIRES(is_range<Range1>, is_range<Range2>) (bool) equals(const Range1& r1, const Range2& r2);
template<class Pair1, class Pair2> ZEN_FUNCTION_REQUIRES(is_pair<Pair1>, is_pair<Pair2>, exclude is_range<Pair1>, exclude is_range<Pair2>) (bool) equals(const Pair1& p1, const Pair2& p2);
Again, you can already do all of this via and_ and not_. I'm probably the last person to be afraid of preprocessor metaprogramming, but making a little preprocessor EDSL just for "and" and "not" seems like overkill to me, especially for something like enable_if. Your macro also is more complicated than that, since you now need to account for commas in individual conditions as well.
As for the emulation stuff you are talking about, there's the "generic" directory in the sandbox, which is a library for concept emulation, though it's sort of in limbo.
I was referring to the ConceptsLite proposal.
I'm not going to open up this can of worms in this thread, but I am not a fan of that proposal in the least. -- -Matt Calabrese
I was referring to the ConceptsLite proposal.
I'm not going to open up this can of worms in this thread, but I am not a fan of that proposal in the least.
Is that because the proposal doesn't include concept maps? My understanding is that the proposal leaves the door open for concept maps in the future (just like it leaves the door open for checking of template definitions in the future) - they just didn't want to add everything as once because that proved to be too much in C++0x. Are you aware of the std-proposals discussion group? [1] Have you considered voicing your concerns with ConceptsLite there? Regards, Nate [1] https://groups.google.com/a/isocpp.org/forum/#!forum/std-proposals
Besides being slightly more verbose, this only works in C++11.
Your example is also C++11, since it uses variadic macros.
Although C++11 includes variadic macros, C++11 is not required to use variadic macros. Any compiler in the last 8 to 10 years supports some form of variadic macros.
The macro can be changed to just automatically wrap everything in and_ and it will get the functionality you are looking for, I just don't think it's necessary, and as I'm sure Mathias would point out, it adds an extra instantiation if there is only one condition (as is frequently the case).
Yes it does add quite bit of extra instantiations, since it relies on folding over an mpl sequence. In C++11, I could do the fold over a variadic template. This should reduce it down to 1 or 2 extra instantiations, for just a single trait.
Again, you can already do all of this via and_ and not_. I'm probably the last person to be afraid of preprocessor metaprogramming, but making a little preprocessor EDSL just for "and" and "not" seems like overkill to me, especially for something like enable_if.
It isn't just a EDSL for 'and' and 'not'. It helps improves the clutter caused by enable_if, especially for function declarations.
Your macro also is more complicated than that, since you now need to account for commas in individual conditions as well.
The macro isn't that complicated, its under 200 lines of code for all three variants of the macro.
I was referring to the ConceptsLite proposal.
I'm not going to open up this can of worms in this thread, but I am not a fan of that proposal in the least.
The proposal seems to be just native support of enable_if. Which lets the compiler do better overload matching, and error reporting. It really has nothing to do with concepts. Paul Fultz II
On Mon, Aug 19, 2013 at 9:11 PM, paul Fultz <pfultz2@yahoo.com> wrote:
I was referring to the ConceptsLite proposal.
I'm not going to open up this can of worms in this thread, but I am not a fan of that proposal in the least.
The proposal seems to be just native support of enable_if. Which lets the compiler do better overload matching, and error reporting. It really has nothing to do with concepts.
Exactly. The C++0x concept proposal, on the other hand, had a lot more than just concept maps going for it -- it had automatically deduced associated types, an actual working way to check template definitions, and pseudo-signatures provide a much more clear and direct correspondence to archetypes, which is how definition checking was performed in the 0x proposal and is likely how it will be done in any working concept implementation with definition checking. IMO concept maps are the way to go for all of the reasons that have been talked about for the past 8 years or however long it's been, but at this point I don't care if we start out with everything implicit. Concept maps are almost a non-issue at this point. Pseudo-signatures and proper associated type support are what really need to be brought back if we are to have something more than just a glorified, native enable_if. The big problem is that a proper concepts language feature would require fundamental changes to what ConceptsLite proposes, so it's not simply a matter of getting ConceptsLite in and then improving it in the future. If ConceptsLite gets in, I find it hard to believe that C++ will ever get proper concept support. -- -Matt Calabrese
The big problem is that a proper concepts language feature would require fundamental changes to what ConceptsLite proposes, so it's not simply a matter of getting ConceptsLite in and then improving it in the future. If ConceptsLite gets in, I find it hard to believe that C++ will ever get proper concept support.
I would strongly suggest that you bring this up on std-proposals. As it stands, ConceptsLite appears to have fairly broad support within the Committee, and if issues like this are not brought up, it might be passed without such issues being considered carefully enough. Regards, Nate
On 20/08/13 05:29, Nathan Ridge wrote:
The big problem is that a proper concepts language feature would require fundamental changes to what ConceptsLite proposes, so it's not simply a matter of getting ConceptsLite in and then improving it in the future. If ConceptsLite gets in, I find it hard to believe that C++ will ever get proper concept support.
I would strongly suggest that you bring this up on std-proposals. As it stands, ConceptsLite appears to have fairly broad support within the Committee, and if issues like this are not brought up, it might be passed without such issues being considered carefully enough.
His argument is that the definition of concepts and their association with types is not rigid and formal anymore. It's just any constant boolean expression. It's not a bug, it's a feature.
On Tue, Aug 20, 2013 at 6:11 AM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
His argument is that the definition of concepts and their association with types is not rigid and formal anymore. It's just any constant boolean expression. It's not a bug, it's a feature.
It's not a "bug" or "feature," it's a design choice that makes it difficult or impossible to add proper template definition checking in the future and it also makes writing template definitions that use the concept more difficult than the 0x approach. In ConceptsLite, rather than dealing with a direct list of associated functions (including their parameter list and explicit return type) and associated types, you instead have to deduce everything from usage requirements if you are to actually check a template definition or write any code that slightly deviates from the precisely written usage specification. Programmers are used to writing functions where their parameter types correspond to a type specification and 0x concepts was extremely similar to that. You look at a concept definition much like you would a type definition, see its functions and types, and you are set. In terms of the compiler, it also means a direct route for doing template definition checking since an archetype can be easily created from a C++0x concept definition and checking a template definition is a matter of the compiler just instantiating that template with the archetype. ConceptsLite, on the other hand, deals with usage requirements in the manner that we were forced to with SFINAE (simple expression validity and direct compile-time constant expression checking). You now have to deduce accepted use from the validity of various expressions. You also no longer have automatically deduced associated types. Archetype generation also becomes non-trivial making it no surprise that template definition checking isn't tackled by ConceptsLite. Keep in mind that C++0x concepts had this "informal" way to add concept requirements, too. Again, that it existed wasn't a bug just like the ConceptsLite approach isn't a "bug," but its usage is limited and you wouldn't want to base all concepts around it, especially if you expect to have properly checked template definitions. You use it when your concept has a requirement other than an associated function or associated type that is able to be checked at compile-time. In C++0x concepts it was the std::True concept and took a bool as a parameter (as opposed to a type, which is what most programmers are more familiar with regarding concepts). When the bool is true, the concept is modeled. When the bool is false, the concept is not modeled. This allows you to have any compile-time constant expression as a concept requirement (just put a requires True< your_constexpr_or_metafunction_check_here >; in a concept's definition). In other words, if you really wanted to, you could exploit this functionality to do complete ConceptsLite-style usage requirements by just taking advantage of template overloads and specializations that utilize SFINAE and referencing them in a std::True requirement. Would anyone recommend that? No. The problem is that this very general functionality acts pretty much as an opaque barrier when it comes to proper archetype generation, and in turn, makes it difficult to properly check template definitions. In ConceptsLite, that barrier is less opaque, but still suffers from problems already talked about both here and elsewhere. ConceptsLite "puts off" the possibility of checking concept definitions to some time in the future, but if people thought that the checking of definitions was too complicated in 0x, then I find it extremely hard to believe that anything will come out of ConceptsLite template definition checking, which is a more complicated problem. C++0x concepts was a complex feature, however it was extremely well thought out and even had a working model for template definition checking. The rational course of action once C++0x concepts was removed, given that it was even in the working paper and had a working model, would have been to simply scale things back. Rather than doing that, though, ConceptsLite essentially throws everything out the window using the excuse of C++0x concepts being too complicated as a means to push an entirely different design, while certain others involved in C++0x concepts moved on to other things. For a much more sensible course of action than ConceptsLite, see Doug's paper from earlier this year, which just scales back C++0x concepts without sacrificing its most important parts: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3629.pdf -- -Matt Calabrese
On 20/08/13 19:27, Matt Calabrese wrote:
On Tue, Aug 20, 2013 at 6:11 AM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
His argument is that the definition of concepts and their association with types is not rigid and formal anymore. It's just any constant boolean expression. It's not a bug, it's a feature.
It's not a "bug" or "feature," it's a design choice that makes it difficult or impossible to add proper template definition checking in the future and it also makes writing template definitions that use the concept more difficult than the 0x approach. In ConceptsLite, rather than dealing with a direct list of associated functions (including their parameter list and explicit return type) and associated types, you instead have to deduce everything from usage requirements if you are to actually check a template definition or write any code that slightly deviates from the precisely written usage specification. Programmers are used to writing functions where their parameter types correspond to a type specification and 0x concepts was extremely similar to that. You look at a concept definition much like you would a type definition, see its functions and types, and you are set.
All existing C++ concepts have requirements specified as a list of valid expressions with the right properties, not with a class-like function list. The new approach is more fitting to concepts as they've been used in C++.
On Tue, Aug 20, 2013 at 2:03 PM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
All existing C++ concepts have requirements specified as a list of valid expressions with the right properties, not with a class-like function list.
The new approach is more fitting to concepts as they've been used in C++.
That has already been discussed many times, and years ago at that, which is why C++0x concepts managed to make it to the working paper to begin with. It has not been a strong point of contention for those advocating ConceptsLite. Needless to say, the standard concepts could have been less ambiguous with a pseudo-signature style approach. That the 98 standard introduced the specification of the standard's concepts via usage requirements should not hold back adoption of proper pseudo-signatures in a concepts language feature, nor should it prevent the specification of the standard concepts from being improved in future standards. We have learned since then and shouldn't have the original, entirely external specification of standard concepts hamper progress with respect to a concepts language feature, especially given that most programmers probably do not reference the concept specifications in the standard when writing code anyway (while I'd like to think that the boost community is representative of the C++ community in general, that is far from the case). Rather, that change mostly impacts generic library developers, who also happen to be able to benefit most from the change. Compatible language-level concepts were introduced in the 0x proposal and a transition to that approach would only cause problems in already-suspicious code that probably shouldn't have be acceptable anyway had the original concepts been more precise. -- -Matt Calabrese
On 20/08/13 04:00, Matt Calabrese wrote:
On Mon, Aug 19, 2013 at 9:11 PM, paul Fultz <pfultz2@yahoo.com> wrote:
I was referring to the ConceptsLite proposal.
I'm not going to open up this can of worms in this thread, but I am not a fan of that proposal in the least.
The proposal seems to be just native support of enable_if. Which lets the compiler do better overload matching, and error reporting. It really has nothing to do with concepts.
Exactly. The C++0x concept proposal, on the other hand, had a lot more than just concept maps going for it -- it had automatically deduced associated types, an actual working way to check template definitions, and pseudo-signatures provide a much more clear and direct correspondence to archetypes, which is how definition checking was performed in the 0x proposal and is likely how it will be done in any working concept implementation with definition checking. IMO concept maps are the way to go for all of the reasons that have been talked about for the past 8 years or however long it's been, but at this point I don't care if we start out with everything implicit. Concept maps are almost a non-issue at this point. Pseudo-signatures and proper associated type support are what really need to be brought back if we are to have something more than just a glorified, native enable_if. The big problem is that a proper concepts language feature would require fundamental changes to what ConceptsLite proposes, so it's not simply a matter of getting ConceptsLite in and then improving it in the future. If ConceptsLite gets in, I find it hard to believe that C++ will ever get proper concept support.
If you're going to explicitly make some types conforming to a concept, then you might as well use SFINAE like so: template<class T, class Enable = void> struct my_class; template<class T> struct my_class<T, typename T::my_concept_tag> { // T fulfills my concept };
On 18/08/13 22:16, paul Fultz wrote:
From: TONGARI J Hi folks,
It's over 2 years since this post: http://boost.2283326.n4.nabble.com/New-powerful-way-to-use-enable-if-in-C-0x...
The macro looks sweet and I wonder if we have this macro in Boost in case that I missed it.
This is nice for C++11 and conversion operators
AFAIK this is indeed the only way to constrain template conversion operators with SFINAE. This is the real use of that trick. But why not just use that trick explicitly in that context?
2013/8/19 Mathias Gaunard <mathias.gaunard@ens-lyon.org>
On 18/08/13 22:16, paul Fultz wrote:
From: TONGARI J
Hi folks,
It's over 2 years since this post: http://boost.2283326.n4.**nabble.com/New-powerful-way-** to-use-enable-if-in-C-0x-**td3442723.html<http://boost.2283326.n4.nabble.com/New-powerful-way-to-use-enable-if-in-C-0x-td3442723.html>
The macro looks sweet and I wonder if we have this macro in Boost in case that I missed it.
This is nice for C++11 and conversion operators
AFAIK this is indeed the only way to constrain template conversion operators with SFINAE. This is the real use of that trick. But why not just use that trick explicitly in that context?
If we have a general way to do it, why would we bother ourselves writing specific code in different contexts? I think the power of abstraction is to let us forget the details, and everything has trade off, put it on the scales, the writability weighs more to me.
On Mon, Aug 19, 2013 at 10:40 AM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
AFAIK this is indeed the only way to constrain template conversion operators with SFINAE. This is the real use of that trick. But why not just use that trick explicitly in that context?
If you have one approach that works all of the time, such as this macro, you don't need to learn multiple tricks at all. -- -Matt Calabrese
On 19/08/13 17:41, Matt Calabrese wrote:
On Mon, Aug 19, 2013 at 10:40 AM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
AFAIK this is indeed the only way to constrain template conversion operators with SFINAE. This is the real use of that trick. But why not just use that trick explicitly in that context?
If you have one approach that works all of the time, such as this macro, you don't need to learn multiple tricks at all.
Those tricks are fairly basic usages of the language, I think you should be comfortable enough with such things if you're writing something as dangerous as a template conversion operator.
participants (5)
-
Mathias Gaunard -
Matt Calabrese -
Nathan Ridge -
paul Fultz -
TONGARI J