Re: [boost] Re: Review request: enable_if
David Abrahams wrote: > "Peter Dimov" <[EMAIL PROTECTED]> writes: > >> David Abrahams wrote: >>> Jaakko Jarvi <[EMAIL PROTECTED]> writes: >>> Where we've used enable_if, it has been very common that the condition is not just a single traits lookup, but rather a logical expression, e.g.: template typename enable_if::value && is_vector::value,...>::type operator*(const T& t, const U& u); So definitely, this version of enable_if is needed. >>> >>> really? >>> >>> template >>> typename enable_if, is_vector >>> >,...>::type operator*(const T& t, const U& u); >>> >>> looks better to me. >> >> Sorry, no. If you deny me a non-broken enable_if > > Calling the version I want "broken" is quite extreme, and I ask you > to justify it. I didn't say "the version you want is broken." What I said roughly translates to: "an enable_if facility that only includes the version you want may be perceived as broken by certain audiences which I decided to represent in this discussion 'cause I felt like it." >> I'll just write one myself. I am not going to uglify my expressions > > Clearly the ugliness is a matter of opinion. Precisely. > I think the usage with mpl::and_ is much prettier. Sure, in a way. Some might say Python is prettier than C++. Others may find Lisp prettier than both. The point is that in C++, the C++ expression syntax wins beauty contests by default. >> for no good reason. > > That aside, there are good reasons to do it my way: > > * Almost always terser OK. > * Works with more compilers The compilers that can do SFINAE well enough for enable_if should be able to handle && in integral constant expressions, no? > * Results in fewer template instantiations (mpl::and_<...> does > short-circuit instantiation) Interesting point. I didn't think of it. > * enable_if<_1, _2> is a valid lambda expression Doesn't matter, unless I'm missing something. I'm not saying that an mpl friendly enable_if should not be included. I'm saying that forcing mpl on people is not necessarily a good idea. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Review request: enable_if
David Abrahams wrote: > Jaakko Jarvi <[EMAIL PROTECTED]> writes: > >> Where we've used enable_if, it has been very common that the >> condition is not just a single traits lookup, but rather a logical >> expression, e.g.: >> >> template >> typename enable_if::value && >> is_vector::value,...>::type operator*(const T& t, const U& u); >> >> So definitely, this version of enable_if is needed. > > really? > > template > typename enable_if, is_vector > >,...>::type operator*(const T& t, const U& u); > > looks better to me. Sorry, no. If you deny me a non-broken enable_if, I'll just write one myself. I am not going to uglify my expressions for no good reason. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Review request: enable_if
In our last exciting episode Thomas Witt wrote: > User-Agent: KMail/1.5 > On Wednesday 09 July 2003 21:09, Jaakko Jarvi wrote: > > Where we've used enable_if, it has been very common that the condition > > is not just a single traits lookup, but rather a logical expression, > > e.g.: > > > > template > > typename enable_if::value && is_vector::value,...>::type > > operator*(const T& t, const U& u); > Ok I can see the problem, but what about > template > typename enable_if< mpl::and, is_vector >,...>::type > operator*(const T& t, const U& u); Would work. Requires some knowledge of mpl and a tiny file to be included, though. Our view is still that at least the enable_if version is needed. The mpl-aware enable_if would be good to have too. Jaakko & Jeremiah ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Review request: enable_if
On Wednesday 09 July 2003 21:09, Jaakko Jarvi wrote: > Where we've used enable_if, it has been very common that the condition > is not just a single traits lookup, but rather a logical expression, > e.g.: > > template > typename enable_if::value && is_vector::value,...>::type > operator*(const T& t, const U& u); Ok I can see the problem, but what about template typename enable_if< mpl::and, is_vector >,...>::type operator*(const T& t, const U& u); ? Thomas -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Review request: enable_if
Where we've used enable_if, it has been very common that the condition is not just a single traits lookup, but rather a logical expression, e.g.: template typename enable_if::value && is_vector::value,...>::type operator*(const T& t, const U& u); So definitely, this version of enable_if is needed. Jaakko & Jeremiah In our last exciting episode Thomas Witt wrote: > User-Agent: KMail/1.5 > I doubt that the _c version are needed frequently enough to warrant the extra > types. > Thomas > -- > Dipl.-Ing. Thomas Witt > Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover > voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 > http://www.ive.uni-hannover.de > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Review request: enable_if
On Wednesday 09 July 2003 19:43, David Abrahams wrote:
> I strongly prefer this interface:
Me too.
>
> // enable_if operates on types with a nested ::value
> template
> typename enable_if, void>::type foo(T t) {
> std::cout << "An arithmetic type\n";
> }
>
> template
> typename disable_if, void>::type foo(T t) {
> std::cout << "Not an arithmetic type\n";
> }
>
> // and enable_if_c operates on integral constants:
I doubt that the _c version are needed frequently enough to warrant the extra
types.
Thomas
--
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001
http://www.ive.uni-hannover.de
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
