"Peter Dimov" <pdimov@mmltd.net> wrote in messag:
Howard Hinnant wrote:
<snip> And I submit that: S<T[], my_deleter> is more elegant syntax than: S_array<T, my_deleter>
<snip>
Need to be? No. But I still like it. <shrug> I was convinced because that's how a newbie expected it to work.
I'm starting to not like it. :-) The problem is:
template<class X> void f(S_ptr<X> px);
where f doesn't support arrays. A reasonably common occurence. S_array<> doesn't match, but S_ptr<T[]> does. The author of f would need to learn about enable_if to prevent array pointers from being passed to f. This is not good, although the exact degree of not-goodness is somewhat debatable.
I'm not sure I see the problem. (Maybe because I already implemented this feature :-) If pointers to objects and pointers to arrays need different treatment, one can use: template<class X> void f(S_ptr<X> px); template<class X> void f(S_ptr<X[]> px); If one only wants to support pointers to objects, but forgets that the array case is subsumed by template<class X> void f(S_ptr<X> px); I think there will almost certianly be a compiler error if somepone tries to pass an array pointer, since the dereferencing operations are not supported. In my implementation, the user would likely be directed to something like: element_type* operator->() const { BOOST_STATIC_ASSERT(!is_array); return ptr(); } If f declares a variable of type X or X& and tries to assign to it, there will also be an error. (On VC7.1 I get the message 'array initializer needs curly braces', or 'reference to a zero-sized array is illegal') Can you think of an example where a compiler error would be undesirable, or where no error will occur until runtime? Regards, Jonathan