On 7/5/06, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
I think it's ok to say boost::function is a *not* a very common type. It's one of a kind.
What makes you say that? I've used such behavior before and Dave Abrahams claims he's used it several times. Perhaps in your particular work you don't need such behavior very often, but there is nothing logically wrong with it. In OO programming, it is common to deep-clone a little here and there.
It's not common to do it all the time.
No one is saying you should do it all the time. If you want reference semantics you may use a shared_ptr or similar solution, and if you need value semantics you use a clone_ptr or similar solution. On 7/5/06, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
I can't imagine what kind of generic code you're talking about.
The type of code generic code that I already posted an example of. For instance, you have a template parameterized by type which internally uses value-semantics with said type, perhaps even having a container of a parameterized type in the implementation. Then, in a given situation you wish to use that template in order to work with varying children of a specific polymorphic type. With a clone pointer type, all you have to do is instantiate the template with a clone_ptr of the desired type and everything works fine. Not only that, but it is also efficient at runtime, since even if, for example, an STL container of them is used in the implementation, the respecitve specialization is also automatically used. Without a clone pointer, you pretty much hit a wall, at least in terms of simple solutions. One option is to manually create a type which works with the polymorphic type internally and has value semantics (which is exactly what clone_ptr would do automatically for you), with the down-side being that you don't get optimized container implementations unless you also make those yourself. Another solution may be to add a template parameter which may be used as a way to specify that you wish to work with dynamically allocated instances of the type and have value semantics, which forces an unecessary burden on the coder of the template and is more complex than simply instantiating the template with a clone_ptr type. Finally, even if the user is able to alter the template in order to give it such functionality as was just described, in order to have optimized code you would have to use explicit template metaprogramming in order to take advantage of ptr_containers -- using them only when such dynamic value semantics are required. Even then, due to the differing interface of ptr_containers from regular containers, you need to do quite a bit of specialized internal coding to be sure that everything works consistently between instantiations which use basic containers and those which use ptr_containers. Keep in mind that you'd have to do all of this just to get the same functionality and efficient code that you would get by using a clone_ptr. If you not willing to accept that value-based programming and OO
programming are different disciplines, we will never agree on this one. Period.
Until you understand that object oriented programming is an entirely orthogonal issue from programming with value semantics or reference semantics, we will never agree on this one. There is absolutely nothing about object oriented programming that logically restricts it to reference-based programming, nor has there ever been such a restriction. I'm not sure how you are coming to such a conclusion. -- -Matt Calabrese