Boost logo

Boost :

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2002-04-19 15:55:16

"Fernando Cacciola" <fcacciola_at_[hidden]> wrote in message
> How would you write the specializations for get_pointer<> for SmartPtr?
> specializations must work with bare pointers and third-party conventional
> smart pointers as well, as it does now.

Like this:

template<typename StoragePolicy,...> inline
get_pointer(smart_ptr<....> const & p) { return p.get(); }

> >
> Yes, but these should be categorized as the unusual cases. I dare to
> that more than 90% of the time pointers are deallocated with delete, FILE*
> with fclose, handles with type-specific API calls, etc...

This is all about unusual cases. Why would we need flexibility in other
case? BTW I do not agree with your numbers. In my expirience I am using
smart_ptr facility rather frequently to handle thouse "special cases"

> It seems to me that you are baseing your argument in the assumption that
> smart pointers are used through a typedef, as in:
> typedef smart_ptr<MyClass,Policy1,Policy2,Policy3> MyClassPtr ;

Almost. Even if there is no explicit typedef,
smart_ptr<MyClass,Policy1,Policy2,Policy3> is a class name with some
interface and behavior.

> But this is not the case in many practices.


> If we had template typedefs, then our whole argument would be wrong... but
> that feature is not available.

I am using type generators for this puposes (It is especially important for
me since my compiler does not support default arguments)
Like this:


Do you feel more comfortable if this type will be in you interface?

> --
> Fernando Cacciola
> Sierra s.r.l.
> fcacciola_at_[hidden]


Boost list run by bdawes at, gregod at, cpdaniel at, john at