Re: Suggestion: auto_ary

From: Daryle Walker (darylew_at_[hidden])
Date: 2001-01-08 17:34:56

on 1/7/01 2:38 PM, Howard Hinnant at hinnant_at_[hidden] wrote:

> Daryle Walker wrote on 1/7/2001 1:15 PM
>> The main difference is that I provide a totally separate class; the
>> recent posts on the other thread describe problems coming from forcing the
>> array idea within the "std::auto_ptr" framework.  The semantics are
>> different.  (An array should not have "->" or "*" or conversions; a single
>> object should not have "[]" or pointer decay.)
> 
> Perhaps an array should not have "->" or "*", or perhaps it should.

Why should an array support "->" or "*" (independently of the element type
supporting it)?  What would it mean?  An array is not a pointer.  Do actual
arrays support these operators?  (I guess any support of these operators by
arrays could be from the pointer-decay "anti-feature" arrays get in C/C++.)

> Either way I don't see that as a strong argument one way or the other.
> The interface of the T[] specialization (or of auto_ary) is technically
> independent of std::auto_ptr.  It is whatever the class designer decides
> it should be.

[In another post, Howard mentioned that "T[]" is an incomplete type that is
independent of any other type, including "T*" and "T[N]" (for any N).]

If you are going to use a specialization, its interface should be compatible
with other versions of the template.  Remember that std::auto_ptr is a
standard class; it's improper for us to make a noticeably different
specialization.  (The standard does it to itself with the specialization for
std::allocator<void>, but it can break its own rules, we can't.)  In fact,
this specialization may not be allowed, depending on how section 17.4.3.1
(paragraph 1) is supposed to be interpreted.  (Can "T[]" count as depending
on an user-defined name [of external linkage]?  What if "T" is something
like "float," would it ruin the idea?)

Other difficulties:

1.  The technique requires partial specialization, which not all of the
compilers we talk about support.
2.  The technique uses an obscure set of types to act as a subtle switch of
semantics.  Besides the risk of compiler writers forgetting to handle
partial specialization of this edge case, it seems kind-of hackish.  (How
would we justify the syntax to a newbie?)  A separate class template shows
clearer intent and more-justifiable leeway to change the interface.

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com