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.

On Sun, Aug 18, 2013 at 3:41 PM, Matt Calabrese 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 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)) int f(T const&) { return 0; }

instead of

template<class T> typename enable_if< is_same , 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 19/08/13 01:54, Matt Calabrese wrote:

On Sun, Aug 18, 2013 at 4:16 PM, paul Fultz wrote:

...

So functions can be defined like this:

template 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.

On Mon, Aug 19, 2013 at 1:34 PM, paul Fultz 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 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 ZEN_FUNCTION_REQUIRES(is_range<Range1>, is_range<Range2>) (bool) equals(const Range1& r1, const Range2& r2);

template 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

...

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

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 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 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 03:11, paul Fultz wrote:

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.

Concept-based overloading is very different from SFINAE.

2013/8/19 Mathias Gaunard

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.htmlhttp://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?

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 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.