Re: Futures Review - inheriting from futures

AMDG

vicente.botet wrote:
>>>>> In order to be able to inherit from futures, shouldn't the constructor(detail::future_object) or
constructor(detail::future_impl) be protected?
>>>>>   
>>>>>       
>>>>>           
>>>> Why do you want to be able to inherit from futures?
>>>>     
>>>>         
>>> To extend their functionality.
>>>   
>>>       
>> I'm afraid that the above statement is absolutely zero use to me.
>> future is not a polymorphic class, so you don't have anything
>> to override.  
>>     
> We can inherit from a class that it is not polymorphic, of course we cannot use it polimorphicaly.

Of course we can.

> There are a lot of clases that inherits from non polymorphic class in Boost.
>   

Sure, but most public classes in Boost are not intended to be inherited 
from.
I still don't see the need to inherit from an ordinary value type like 
future.

> I can overrride any function in the class of course not polymorphycaly.
>   

Technically, it's hiding not overriding...

> I can also take the future as a member
>   

So, why do you want inheritance?

>> Do you a specific use that cannot (easily) be implemented
>> with the current interface?
>>     
>
> I would like to have a minimal future class that do not have callbacks, and on top of this define a
callback_future. I don't not want to pay for wat I dont use. Inheritance is a mechanism to achieve it.
>   

Okay, but this requires a lot more than simply making a constructor public.
Also, if you use inheritance, will it behave sensibly in the face of 
upcasting

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost