[ptr_container] new_clone overload
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've noticed that ptr_container/clone_allocator.hpp contains an undocumented overload of new_clone that accepts a pointer-to-const: template< class T > inline T* new_clone( const T* r ); It is annoying because it doesn't support a pointer-to-non-const argument, resulting in a compile error if you try. Any chance one of the following could be done? 1) remove it 2) add a pointer-to-non-const overload 3) change it to template< class T > T* new_clone( T* r ); 4) or if you care about always returning a pointer-to-non-const change it to template< class T > typename remove_const<T>::type * new_clone( T* r ); -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpxsyoACgkQ5vihyNWuA4WnCACgwzxlNxG8z8NAln6Ra8+fNHsn Yr8AoL5a8Bdvkoya1p99GcS1W8N2WSjk =rSZQ -----END PGP SIGNATURE-----
Frank Mori Hess skrev:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I've noticed that ptr_container/clone_allocator.hpp contains an undocumented overload of new_clone that accepts a pointer-to-const:
template< class T > inline T* new_clone( const T* r );
It is annoying because it doesn't support a pointer-to-non-const argument, resulting in a compile error if you try. Any chance one of the following could be done?
1) remove it
2) add a pointer-to-non-const overload
3) change it to template< class T > T* new_clone( T* r );
4) or if you care about always returning a pointer-to-non-const change it to template< class T > typename remove_const<T>::type * new_clone( T* r );
I really don't see the problem, but removing it entirely is certainly an option. Why do you get a compile error? Cloning is not supposed to require a mutable object. Is your problem with legacy code? -Thorsten
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 04 August 2009, Thorsten Ottosen wrote:
Frank Mori Hess skrev:
I've noticed that ptr_container/clone_allocator.hpp contains an undocumented overload of new_clone that accepts a pointer-to-const:
template< class T > inline T* new_clone( const T* r );
I really don't see the problem, but removing it entirely is certainly an option.
Why do you get a compile error? Cloning is not supposed to require a mutable object. Is your problem with legacy code?
Because a pointer-to-nonconst argument binds to the new_clone overload that accepts a const reference (T is deduced to be a pointer type): template< class T > inline T* new_clone( const T& r ); This came up, because in implementing generic_ptr::cloning I wanted to make any wrapping pointer-like types available to the new_clone function, so I call it by passing a generic pointer-like object (sometimes an actual pointer) to new_clone (and provide suitable new_clone overloads) instead of passing a reference directly. This, for example, lets me lock any generic_ptr::monitor objects before their pointed-to object is cloned. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkp4LoUACgkQ5vihyNWuA4V2GgCfTfABLQOx27lZZgqQrVUCNLdn TNwAn1VVEfDy8XzjU2igdlF4pZRqL1ni =wDAd -----END PGP SIGNATURE-----
Frank Mori Hess skrev:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I've noticed that ptr_container/clone_allocator.hpp contains an undocumented overload of new_clone that accepts a pointer-to-const:
template< class T > inline T* new_clone( const T* r );
It is annoying because it doesn't support a pointer-to-non-const argument, resulting in a compile error if you try. Any chance one of the following could be done?
Yes, which do you prefer?
1) remove it
2) add a pointer-to-non-const overload
3) change it to template< class T > T* new_clone( T* r );
4) or if you care about always returning a pointer-to-non-const change it to template< class T > typename remove_const<T>::type * new_clone( T* r );
-Thorsten
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 20 August 2009, Thorsten Ottosen wrote:
Frank Mori Hess skrev:
I've noticed that ptr_container/clone_allocator.hpp contains an undocumented overload of new_clone that accepts a pointer-to-const:
template< class T > inline T* new_clone( const T* r );
It is annoying because it doesn't support a pointer-to-non-const argument, resulting in a compile error if you try. Any chance one of the following could be done?
Yes, which do you prefer?
1,2, or 4 are all equally fine to me. Actually, I'm currently in the process of moving away from new_clone to a "placement" version of it for generic_ptr::cloning (a cloning smart pointer class). That will let me avoid having to do two allocations for every copy of generic_ptr::cloning, by using a boost::aligned_storage inside the clone allocator. Also, my versions of new_clone and CloneAllocator will have to be generalized slightly to support generic pointer-like objects in addition to plain old pointers.
1) remove it
2) add a pointer-to-non-const overload
3) change it to template< class T > T* new_clone( T* r );
4) or if you care about always returning a pointer-to-non-const change it to template< class T > typename remove_const<T>::type * new_clone( T* r ); -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkqNX3sACgkQ5vihyNWuA4WFWQCgiF3PL2ZHlGNRh2ikzzgG01UA VlMAnj77HCwpGUpfHtBa6DGFGOfPo+EU =s1M0 -----END PGP SIGNATURE-----
Frank Mori Hess skrev:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday 20 August 2009, Thorsten Ottosen wrote:
Frank Mori Hess skrev:
I've noticed that ptr_container/clone_allocator.hpp contains an undocumented overload of new_clone that accepts a pointer-to-const:
template< class T > inline T* new_clone( const T* r );
It is annoying because it doesn't support a pointer-to-non-const argument, resulting in a compile error if you try. Any chance one of the following could be done? Yes, which do you prefer?
1,2, or 4 are all equally fine to me. Actually, I'm currently in the process of moving away from new_clone to a "placement" version of it for generic_ptr::cloning (a cloning smart pointer class). That will let me avoid having to do two allocations for every copy of generic_ptr::cloning, by using a boost::aligned_storage inside the clone allocator. Also, my versions of new_clone and CloneAllocator will have to be generalized slightly to support generic pointer-like objects in addition to plain old pointers.
1) remove it
Seems like 1 is the simplest then. -Thorsten
participants (2)
-
Frank Mori Hess -
Thorsten Ottosen