Since array of objects requiring constructors can exit it follows that any
C++ complier must contain the requisite logic for automatically inserting
loops to handle arrays.

Why must be live with the anachonistic restictions on the use of array
variables?

typedef T TA[5];
TA a; //this correctly calls T::T() five times
TA b=a; // should call T::T(const T&) five times
TA b(a); // same as above
a=b; // should call T::operator=(const T&) five times

One can of course say...
T b[5] = {a[0], a[1], a[2], a[3], a[4]};
...but this is ugly and its unlikely that the optimizer will spot that it's
a loop. Also this won't work if the size of the array is not determined until
compile time (for example as a macro passed in from the makefile).

BTW I realise that that it may be possible to create a class TA with all these
properties but I don't think that should be necessary.

More controversially why can't we pass by arrays by value?

typedef T TA[5];
void foo(TA a); // should pass by value (and optionally give a warning)
void foo(TA& a); // if I'd meant this I'd have said it
void foo(T* const a); // if I'd meant this I'd have said it

void foo(T a[]); // should do what is always has but give:-
  // "Warning: obsolete argument declaration syntax"

There is some question as to how the complier should handle
void foo(T a[5]);
 ...like `void foo(TA a)' a lot of old programs would fail
 ...like `void foo(T a[])' uglier but pragmatically better

You may well ask, "How can...
 typedef T TA[5];
 void foo(TA a);
...and...
 void foo(T a[5]);
...mean something different?"

OK I agree is ugly, but there is a precedent in the new operator.

typedef T TA[5];
TA* p1=new TA; // valid
T* p2=new T[5]; // valid
T* p3=new TA; // invalid

I realise some old code would fail to compile correctly even with this
distiction but this is a reasonable price to pay for removing the language's
most unsightly wart.

Note that none of what I've proposed inteferes in any way with the use of an
array in a pointer context.

If this question has been flogged to death in the past, I'm sorry.

    \\   ( )  NO BULLSHIT! from BAM (Brian McCauley)
 .  _\\__[oo  ============
.__/  \\ /\@
.  l___\\     E-mail: B.A.McCauley@bham.ac.uk
 # ll  l\\
###LL  LL\\

In article <1992Nov6.190320.1@vax1.bham.ac.uk> mccauleyba@vax1.bham.ac.uk (Brian McCauley) writes:
>Why must be live with the anachonistic restictions on the use of array
>variables?

I agree with your arguments, but some of the counterarguments are:

1) Its very confusing to have an array mean an array in one context,
and have an array mean a ptr in another context [note however, that
C++ *already* makes this distinction when passing an array by reference
to array]

2) What you ask is already achievable with a slight change of syntax
using templates:

 doBlah(array<int,5>)
 {
  ....
 }

Since non-C-braindead-flavors of arrays can easily be implemented using
templates, why invent a new slightly-less-braindead implementation of
arrays built-in to C++?  Instead, lobby the C++ libraries committee to
put the arrays features you like into their proposed array class template.

In article <1992Nov11.004038.17772@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:
> In article <1992Nov6.190320.1@vax1.bham.ac.uk> mccauleyba@vax1.bham.ac.uk (Brian McCauley) writes:
>>Why must be live with the anachonistic restictions on the use of array
>>variables?
>
> I agree with your arguments, but some of the counterarguments are:
>
> [2 very valid points]
>
> Since non-C-braindead-flavors of arrays can easily be implemented using
> templates, why invent a new slightly-less-braindead implementation of
> arrays built-in to C++?  Instead, lobby the C++ libraries committee to
> put the arrays features you like into their proposed array class template.

OK C++ libraries committee - did you hear that.

BTW my objection to the handling of arrays was not that it would be useful
to allow array type to behave like any other type but that it was just plain
ugly to have a different set of rules for a subset of types.
--
    \\   ( )  NO BULLSHIT! from BAM (Brian McCauley)
 .  _\\__[oo
.__/  \\ /\@  E-mail: B.A.McCauley@bham.ac.uk
.  l___\\        Fax: +44 21 625 2175
 # ll  l\\     Snail: 197 Harborne Lane, Birmingham, B29 6SS, UK
###LL  LL\\     ICBM: 52.5N 1.9W

> From: jimad@microsoft.com (Jim Adcock)
> Subject: Re: Array anachronisms
> Message-ID: <1992Nov11.004038.17772@microsoft.com>
> Date: 11 Nov 92 00:40:38 GMT
> Since non-C-braindead-flavors of arrays can easily be implemented using
> templates, why invent a new slightly-less-braindead implementation of
> arrays built-in to C++?  Instead, lobby the C++ libraries committee to
> put the arrays features you like into their proposed array class
template.

Sounds reasonable.  I look forward to seeing a proposal and/or suggested
improvement to the current proposal (X3J16/92-0005R1, WG21/N0084).
--
Mike Vilot,   ObjectCraft Inc.,   Nashua NH  USA
mjv@objects.mv.com
X3J16 Library WG

In article 9211121744013030@mv.com, mjv@mv.com () writes:
>
>> From: jimad@microsoft.com (Jim Adcock)
>> Subject: Re: Array anachronisms
>> Message-ID: <1992Nov11.004038.17772@microsoft.com>
>> Date: 11 Nov 92 00:40:38 GMT
>> Since non-C-braindead-flavors of arrays can easily be implemented using
>> templates, why invent a new slightly-less-braindead implementation of
>> arrays built-in to C++?  Instead, lobby the C++ libraries committee to
>> put the arrays features you like into their proposed array class
>template.
>
>Sounds reasonable.  I look forward to seeing a proposal and/or suggested
>improvement to the current proposal (X3J16/92-0005R1, WG21/N0084).
>--
>Mike Vilot,   ObjectCraft Inc.,   Nashua NH  USA
>mjv@objects.mv.com
>X3J16 Library WG


You mention current proposals ... can we get these via anonymous ftp / mail
server ?

Ameesh

---
______________________________     o__
| _   /|     Ameesh Desai     \    ,>/_
| \`O.o'     LSI Logic Corp.   \__(_)`(_)_              email: ameesh@lsil.com
| =(_|_)=    MS E192, 1501 McCarthy Blvd. \             fax  : (408) 433-6802
|____U_______Milpitas, CA 95035____________\____________voice: (408) 433-4097