
2010/9/27 vicente.botet <vicente.botet@wanadoo.fr>:
----- Original Message ----- From: "Henning Basold" <h.basold@googlemail.com> To: <boost@lists.boost.org> Sent: Monday, September 27, 2010 3:26 PM Subject: Re: [boost] Interest in specialized types
Am 24.09.2010 12:31, schrieb vicente.botet:
Before refactoring the Opaque implementation, I wanted to know if you have worked on your proposal.
Hi,
I am sorry to say but I haven't. I'm in the middle of writing my bachelor thesis so I don't have a lot of time right now. But my brains works despite the body has no time :) So I have some ideas for use cases but no time to write them down.
I see you have already integrated the idea into Opaque. So the basics are already there. Are you satisfied with it and is there anything to do in this area. Else I would use my time (if I should have some ;)) on extending the idea.
Yes, I have integrated your ideas into Opaque after posting this message. Your approach allows to define opaque types fpr underlying UDT :) I hope both approaches are now well integrated.
I have reached to implement a transitive conversion, either implicit for public opaque type or explicit for private opaque types. I gues these kind of transitive conversion could also be used for new_types that are more restrictive than opaque types.
Sounds good. Hopefully you can propose it soon for inclusion so I can use it in production code :)
PS: The concept could for example be used to implement a generalized type erasure which could be used in a type safe manner.
I don't understand completly. Could you explain a little more?
The idea is very similar to Boost.Function. That is you have a fixed interface that one can use on arbitrary types. The concret type is then hidden after construction. The only difference to Boost.Function is that you can specify an arbitrary interface and not just function calls. The interace specification is done analogously to new_type. So one could use Boost.Any without having to know the concret type which is stored inside (as long as the object itself isn't needed). My only problem so far is that I haven't found a way that objects do no grow in size or the dispatching in time with the number of possible methods.
Thanks, Vicente _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Regards, Henning