|
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