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