Re: [boost] Proposal: Polymorphic Value Objects

From: Edd Dawson (lists_at_[hidden])
Date: 2007-09-06 14:47:33

Mathias Gaunard wrote:
> Edd Dawson wrote:
> 
>> I'm confused. Surely the whole point of shared_ptr is to relieve the programmer 
>> of the burden of worrying when its still used.
> 
> The problem is that with large programs you're not able to tell easily
> where it is being used. (also, you may create cycles by oversight, but
> that could be fixed eventually)
> The fact that it is automatically destructed when not used doesn't not
> mean that it can't be still used at wrong places, especially after code
> refactoring and modifications.
> 
> 
>> And what side effects do you 
>> speak of?
> 
> http://en.wikipedia.org/wiki/Side_effect_%28computer_science%29

Perhaps I should have said "*which* side effects do you speak of"! I'm aware of 
the definition of the term as is pertinient to this discussion, but I'm unsure 
of the particular side effects exhibited by the use of shared_ptr that are 
deemed undesirable and supposedly avoided by the use of poly_obj.

>> How are programs made more deterministic?
> 
> Because ownership is fixed to a scope. You thus perfectly know when the
> object will be constructed and destructed.
> With shared ownership, ownership is fully dynamic, and thus not determined.

It's deterministic in that it will be destructed at the point where it is no 
longer used. Often that's all the determinism you need. I agree with you that 
shared_ptr is often over used or at least used rather flippantly, but when used 
properly it is exactly deterministic enough.

Perhaps I'm agreeing with you, here? Hard to tell :)

>> Actually, if you have the static type at the point of construction, you're set.
>> Here's one I just threw together: http://rafb.net/p/bIQgtl24.html
> 
> I looked at your code and I am not sure throwing an exception is the
> right thing to do if the static and dynamic types aren't the same.

I'm not 100% convinced either. But there's a tradeoff (more on this in a sec). 
It does however ensure (not at compile-time, unfortunately) that the user is 
passing in the object in a state where slicing can be avoided.

> The stuff should "just work".

That's certainly desirable, yes. My code wasn't meant to be a full solution 
(only a mockup of an alternative).

I just don't like having to change existing code; it's fine deriving from 
virtual_ctors<> when creating new classes, but it won't work with the stuff I 
already have (or have I missed something?). One could imagine modifying my code 
to check for a specialisation of clonable_object<> or something similar, which 
defines how a clone may be created without changing existing code.

> In your code also you used 'new' directly. It is obvious that people may
> want to use their custom allocator.

Sure. I haven't thought about allowing custom allocation. To be honest I'm not 
at all well read on allocators. If you consider my "design" any further, I'll 
leave you to consider how an allocator interface would be incorporated :) My 
naive gut feeling is that it shoulnd't be too difficult.

> Plus, if you think about it, a virtual constructor should only be
> responsible for constructing, not allocating the memory for the object.

I guess. But I was thinking about it at the "polymorhic value object" level, 
more than implementing a "virtual constructor".

Again, my vote would be to go with anything that provides a non-intrusive solution.

Edd