🚀 go-pugleaf

clamage@Eng.Sun.COM (Steve Clamage) writes:

>Joe Walker <walkerjj@ecid.cig.mot.com> writes:
>>Has allowing the following been considered?
>>
>>  int  length = strlen (some_string);
>>  char buffer [ length ];
>>
>>I.E. allowing non const array sizing.
>
>It is not supported by the C++ draft standard for the same reason it
>is not supported by the C standard.

The good news is that there is a quite significant chance that the next
C standard may include support for variable length arrays; if this happens,
the change is likely to propagate into C++ implementations.

>It would mean in particular for auto
>arrays that the size of the stack frame could not be known until a function
>was entered, and could be different at each invocation. On some platforms
>that is not a problem. On others it is difficult to implement, or forces
>function calls to be much more expensive, or violates the ABI.

But as you suggest below, on platforms for which stack allocation is
difficult, the compiler could simply allocate such arrays on the heap.
In any case, there is a very large variety of prior art in terms of
language implementations that support variable length arrays on a variety
of platforms.  For example, all Ada implementations support this.
So does GNU C.

>For static arrays, some object formats require the array size to be
>specified at link time and not deferred until run time.

Again, this problem could be easily solved by allocating such arrays
on the heap at program startup.

>The standard could say that an implemention is allowed to simulate
>variable-sized stack or static arrays by using the heap and automatically
>deallocating the storage.

I don't think the standard would need to say that.  An implementation
is already allowed to allocate whole stack frames on the heap if it
wants.  The standard should only specify the observable effects;
how various language constructs are implemented should be up to
the implementation.

>IMHO that is not acceptable because in
>portable code you would not know whether a declaration like
>	char buffer[length];
>could fail.

But that is *already* the case.  If you write a declaration like

	char buffer[50000];

it may fail, either at compile time or at run time.  Furthermore,
there is basically no way portable code can recover from such failures.

>It also could turn what looks like a simple declaration into
>a heavy-weight operation.

But that is already the case in C++.  A simple declaration may
invoke a constructor which can be a very heavy-weight operation.

>You can get the effect you want by using an auto_ptr and heap allocation,

You can't use an auto_ptr to point to an array.  You would have to write
an auto_array_ptr class.

>or by using an array class instead of a C-style array.

Both of those alternatives are less convenient and less efficient than
variable-length arrays would be.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]