[boost] Re: smart_ptr implementation descussion topics

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2002-05-06 14:20:16

"David B. Held" <dheld_at_[hidden]> wrote in message
news:ab5vv9$cf0

> be reasonable.  One problem I had with this approach: the Ownership
> policy only gets StoragePolicy::pointer_type (I think).  Whereas, some of
> the policies might also want StoragePolicy::stored_type.  I'm not entirely
> sure.  I need to review the code again.

Ownership policy interface expect *stored_type* as an argument.

> > [...]
> > Most wide usage if it is to prevent leaks at compile time using static
> assert.
>
> Hmm.  While I can see how that *might* be useful, I would be more greatly
> persuaded if anyone actually had a *need* for this capability in a real
> application.  After all, there are uncountable features we could provide,
> but
> that would make for a very fat smart pointer. ;)

I meant usage for leak_reference interface for Ownership policy. And we
already need this capeability for all (but auto_ptr) standard pointers to
prevent usage of release/leak method. In any case it was just an example to
illustrate that leak reference management could be stand alone task for
Ownership policy. What is mosat importante is that does not affect 'fatness'
of smart_ptr at all. release/leak method is present in any case.

> > Topic 4. smart_ptr pointer type constructor
> > I argue that it should be pointer_type, but stored_type. Stored type
could
> > be heavyweight (like another smart_pointer ), while what we really want
is
> > plain pointer [...]
>
> Maybe we should have both c'tors?  And how do you know that you won't
> ever want to construct from stored_type?

In most cases they are the same. You can't provide to constructors. In
general it is still open issue hoe to provide an ability to construct
smart_ptr using some custom type.

> > To separate const/non-const access we need to expand storage policy
> > interface to const version of get_pointer, get reference function
> returning
> > const_pointer_type and const_reference type respectively. [...]
>
> I believe my implementation already does this.

I did not see it in vault area version.

> > 0. I am not using BOOST_NO_MEMBER_TEMPLATES switch since I
> > am using member templates extensively and rely on it. I believe it's
accep
> table
> > requirement.
>

> probably a major concern for a smart pointer, given its wide usage.
Failing
> to
> support compilers with every reasonable effort doesn't seem like a way to
> win friends in this game.

I think you are bitting dead horse here. Look into boost config. Also note
that 2 compilers that does define NO_MEMBER_TETMPLATE flag really support
them, but with some bug. For example on MSVC I was able to make everything
(other than templaet constructors) to work.
BTW, does anybody know how to make MSVC to compile this example, or at least
a workaround to simulate the same functionality:

template<typename T>
class A {
public:
    A()                     {}
    A( A const& a )         {}
    template <typename U>
    A( A<U> const& u )      {}
};

int main()
{
    A<int> a;
}

> Yes, I considered this as well.  Some people don't like a lot of
#includes,
We will use combining headers for this.

> > 10. Once again: I believe that we should be touch issues related to
> > multithreading support for now.
>
> Umm...I'm sorry, but are you saying we *should* or *should not* be
> concerned with multithreading?

should NOT of course, sorry.

> > [...]
> > 15. Once again: compare our checking policies implementation  243 vs. 6
> > predefined policies plus my version provide easy support  for custom
ones.
>
> I guess I'm just worried about overgeneralization.

What do you mean as overgeneralization? Is it inconvinient or to complex?
I argue that is is not.

> For convenience, maybe you should move your folder into the smart_pointers
> folder that Beman created.  That way, people can see all the different
> implementations in one, easy-to-reach location.

Ok.

>
> Dave
>