$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-01-27 12:01:48
"Peter Dimov" <pdimov_at_[hidden]> 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