[boost] RE: whatever ptr / whatever answer

From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2002-08-29 17:28:26

Rozental, Gennadiy wrote:

[...]

> provide implementation for you set of requirements, *even* if it will be
> portable, *even* if it will be reasonably convenient to use I still fail
> to see why the problem your are trying to solve is important and widely

I keep hearing inconsistencies everywhere.  shared_ptr<> is quite 
complicated IMO when you start using counted_base... this could lead to 
ambiguous strutures or slow virtual inheritances easily.  Not to mention 
add_ref.

[...]

Now I hear:
- even, even, even, even, ...;
- my set of requirement is rare...:
        - simplicity is rare?!?
                - If you are able to properly overload add_ref, inherit counted_base I 
don't see why you shouldn't be able to add '(rc)' between 'new' and your 
type;
                - the only thing you need to do is to specialize tree_traits for 
non-polymorphic type.
        - 4 times faster reconstruction negligeable?!?

> space and performance. On the other you want to use smart pointer idiom
> that usually bring some overhead in a size and/or performance. Maybe you
> just better of with plain pointer?

        - Yes, but the size of the memory map in benchmark.cpp is ridiculous also. 
 At some point...

>   Also I wanted to remark that your set of requirements is a bit
>   internally
> controversial. On one side one side you are extremely concerned about

        - Don't we deviate the fact that if you know how it works, you'll know 
that copying it to another ptr<> is the only case that will 'slow down' 
things.  I'm sure you will be able to prevent this if you are programming 
some fast 3D engine.

> is good enough for a lot of people. IMO boost community may decide that it
> does not cover enough cases for resource/memory management, so an
> alternative (IMO policy-based) solution could be considered. But it should
> be at least as usable and flexible as current one.

        - "usable" & "flexible" are very large words.  Do your policies include 
some placement operator alternatives?

-- 
Philippe A. Bouchard