[boost] Re: Inheritance alternatives for policy-based smart_ptr

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2002-04-30 00:19:36

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

> 2a. There doesn't appear to be any config macros for say,
> BOOST_NO_TEMPLATE_TEMPLATE_PARAMETERS.
> Does this mean that Boost in general does not seek to support
> compilers that lack template template support?  If so, then
> it doesn't seem worthwhile to me to drop the template template
> parameters, unless there are more compelling reasons.

No. this mean that Boost libraries are not using template template
parameters yet ( am I right?)
More over, after some recent work with smart_ptr implementation I found that
template template  parameters even though they have some syntax elegance
could be very limiting in flexibility since.
When you explicitly defile template parameter like this:
template <typename> class SomePolicy it means that your *required to follow
this specification. You can't use non-template classes as policy even though
you may not need any template parameters (more over you may have some policy
class implemented offline that you do not  want to make inline). Another
side of the story that you may have policy that has it's own policy. So now
you need additional class and PC to pass it as parameter to you smart_ptr.
  We could provide some generators that would support template template
parameters interface, though it is optional.

>
> 5. Andrei waffled on this one, so I'm not sure whether a change
> is warranted or not.
>
> 8. No clarification here.  Not sure what the suggestion was.
I already explained this. See history.

>
> 10b.  Didn't change release() to release_reference() because
> A) Loki called it release(), B) boost::counted_base() calls it
> release(), and C) std::auto_ptr calls it release()!

You did not get it. I was proposing to name *Ownership policy* method
release_reference(). The method release() I now following Andrei suggestion
name leak().

> 12. Andrei says there is a bug in his implementation of release()
> where he did not reinitialize the Ownership policy.  If I knew how
> this should be fixed, I'd do it.  Andrei, could you clarify?

Look into my implementation of release/leak function. I did not mention it
originally but I think that Loki::SmartPtr has another incorrect behavior
here: it clear storage, while what really should happen is just release of
the ownership (the same auto_ptr is doing). For this purposed I introduced
leak_reference method into Ownership policy.

>
> 13. This is related to member vs. non/member get(), but points
> out the lack of inter-policy communication in the MI approach.

No. This is not true for my approximation. Loki::SmartPtr incorrectly trying
to implement this in StoragePolicy, while this is natural part of the
framework.

> 21. Gennadiy's Checking policies look big and complicated.
> They scared me. ;)  Also, I would like to see more commentary
> before switching to them.

Looking in your code:
Checking policies implementation occupies 269 line
Defines 6(six) different policies.

Looking in my code:
Checking policies implementation occupy 130 line (and I still going to cut
it in halt with use of generators instead of inheritance )
Defines 3^5=243 different checking policies

It used rather simple idiom of named template parameters (that really
deserve separate library).

>
> 22. Same as 21.

Could you clarify here?

I general it would be great if you would be able to comment my
approximation. Many of comments to you original submission are still valid.
but I keep looking on what you doing and probably give more comments later.

Regards,

Gennadiy.