Re: [boost] [review] Fast track formal review of Forward library begins today

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2007-12-09 04:54:41

Stjepan Rajko wrote:
> On Dec 7, 2007 2:51 AM, Tobias Schwinger <tschwinger_at_[hidden]> wrote:
>> Stjepan Rajko wrote:

>>>>      * What is your evaluation of the implementation?
>>> I agree with Dave on the EBO suggestion (and thanks for the
>>> compressed_pair lesson)
>>>
>>  From my personal feeling inheriting from 'forward<F>' might be too rare
>> of a use case to optimize for. However, with two reviewers asking for
>> it I'll probably end up drowning my possibly premature assumptions on
>> what the user will or will not do in a sea of genericity :-)...
> 
> I tend to be inheritance-happy :-)  

:-). Nothing wrong with inheriting from it, I guess.

I can imagine inheriting from it to improve error messages, for instance.

However, for EBCO to pay off we have to both inherit from it and add 
more data members. It currently isn't really designed to have additional 
responsibilities added in subclasses, as a protected member function to 
access the decorated function object seems missing too in this context.

Now with such a member (I think I'll add it), additional data needed in 
the derived class can probably put into the decorated function object - 
if not it becomes questionable whether the subclass' interface belongs 
into the same class as the base's.

> Are there any arguments against
> implementing forward<F> using inheritance of (compressed_pair of) F?

If it ends up being never used we're adding unnecessary dependencies.

If someone presents me a convincing use case I'll add it. Maybe I'll add 
it anyway, but I'd feel much better about it if someone did...

>>>>      * What is your evaluation of the potential usefulness of the library?
>>> Very useful.  Although, I seem to run into cases where I want to have
>>> a forwarding function (not function object), or a forwarding operator.
>>>  But maybe I'm wrong in preferring an actual function...
>> Something like 'make_forward_adapter'?
>>
> 
> You mean like 'make_fused', etc...?  No, I meant instead of ending up
> with a function object that does perfect forwarding, ending up with an
> actual function that does perfect forwarding.  But the only way I can
> see of facilitating that would be factoring out the preprocessing code
> to make it easier for someone to implement one without code
> duplication.

So we're talking about an overloaded function (not a function pointer)?

Interesting. I doubt it's a good idea to promote duplication of 2**N 
overloads, except for very low N. Further, factoring our the 
preprocessing code seems like something I wouldn't want to do :-).

Regards,
Tobias