Re: [boost] [Review] GGL review starts today, November 5th

Subject: Re: [boost] [Review] GGL review starts today, November 5th
From: Barend Gehrels (barend_at_[hidden])
Date: 2009-11-08 12:22:27

Hi,

> If there is a clear justification that SFINAE and BCCL do not matches, his should be added in the rationale. But don't we use SFINAE to support concepts? I don't see the need to combine them. Remember that there was a Concept Traits library that was intendedd to replace the BCCL. The library was abandoned because C++0x should include concepts and because some concepts couldn't be managed by traits. Maybe this library should be relaunched as Concepts are not part of C++0x now.
>   
I agree that it is very good to consider it to be relaunched.  But I 
don't know the details of that library.

However, we currently have to use (or at least, I was encouraged to use) 
BCCL. I don't state that there is no way to combine it with SFINAE-based 
code. I explained that the BOOST_CONCEPT_REQUIRES is not working with 
SFINAE overloads.
It can be added in the rationale.

That BCCL is using SFINAE internally (I didn't know) is no problem for 
me, it is a different subject.

>>>   
>>>       
>> The messages you get depend on the type or error, in both cases.
>>
>> When I try to use a function based on sfinae, when there is no match, 
>> is: the message I get
>> - from MSVC is: Failed to specialize function template..., for all 
>> overloads.
>> - from gcc is: no matching function for call to.... (one)
>>
>> On tag dispatching you'll get:
>> MSVC: 'type' : is not a member of 'tag<T>' with [T=banana]
>> gcc, similar
>>
>> or (if the banana-tag is implemented)
>>
>> MSVC: 'apply' : is not a member of 'dispatch<T>' with [T=tag<banana>::type]
>> gcc:  'apply' is not a member of 'dispatch<banana_tag>'
>>     
>
> This message could be clear to you, but what the user is intendeed to do to correct the error?
>   
Messages originating from template code are often difficult, I agree, 
and if you know the library it is easier to solve them, I agree.

Let me try to state it differently.

With SFINAE the real error is hidden behind the phrase "Failed to 
specialize". The compiler discards all overloads, because of an error 
somewhere, and you get this error with no clue how to go on. What you 
get is the error that it is just failing. All overloads are gone, the 
compiler is not wrong, there is an error somewhere, but the only visible 
error message which makes sense for the compiler to give is something 
like "failed to specialize" or "no matching function call".

With tag dispatching you get the real error message. That can also be 
difficult, but the message(s), sometimes a whole list, give at least a 
clue of what's wrong. In this case: add the banana-tag or add an 
implementation for banana. The usage of concepts should reduce the 
length of the list and give a clearer error message.

So the essence is: /compiler errors in code based on tag dispatching are 
easier to find than compiler errors in code based on SFINAE, because the 
SFINAE-case is based on discarding overloads and *meaningful error 
messages are discarded as well*./

>  
>  
>   
>> I can rephrase this. What I mean is that a function
>>
>> template <typename T>
>> void eat(T const& fruit)
>> {
>>    // tag dispatch on apple-tag
>> }
>>
>> looks better than:
>>
>> template <typename T>
>> void eat(T const& fruit
>> #ifdef DOXYGEN_SHOULD_SKIP_THIS
>>    , typename boost::enable_if<typename is_apple<T>::type>::type* = NULL
>> #endif
>>    )
>> {
>>    // (call) apple implementation
>> }
>>     
>
> Why the user can not define eat on the namespace the apple class is defined
>
> namespace apple_ns {
>     void eat(apple const& fruit)
>     {
>         // do apple implementation
>     }
> }
>  
> Do you see a problem with this approach?
>   
No, but I don't see the relation to tag dispatching vs. sfinae.

Regards, Barend