|
Boost : |
Subject: Re: [boost] Futures Review - inheriting from futures
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2009-01-06 20:03:36
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk