🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

3 total messages Started by Brian McCauley Fri, 06 Nov 1992 19:03
Array anachronisms
#641
Author: Brian McCauley
Date: Fri, 06 Nov 1992 19:03
66 lines
2781 bytes
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\\
Re: Array anachronisms
#654
Author: Jim Adcock
Date: Wed, 11 Nov 1992 00:40
23 lines
1230 bytes
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.
Re: Array anachronisms
#659
Author: Brian McCauley
Date: Wed, 11 Nov 1992 18:19
26 lines
1782 bytes
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
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads