Boost logo

Boost :

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


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

Like this:

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

> >
> Yes, but these should be categorized as the unusual cases. I dare to
state
> 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.
>

Like?

> 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:

auto_ptr_generator<T>::type

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

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

Gennadiy


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk