Mike Harrold wrote:
: I apologise if this has been asked before.
: Why is:

: int foo(size_t x)
: {
:   int my_array[x];
:
:   // ...
: }
:
: not allowed?
:
: Now, g++ accepts this as being ok, and in other cases I can fudge it by
: using alloca(), ...

Does anybody know which way this will be implemented in the standard?
I found what Mike found, that the Gnu compiler allows it. But I know
MS Visual C++ wants the size of the array to be a constant...

cheers,
bob
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Bob Sullivan wrote:
>
> : int foo(size_t x)
> : {
> :   int my_array[x];
> :
> :   // ...
> : }
> :
> : Now, g++ accepts this as being ok, and in other cases I can fudge it by
> : using alloca(), ...
>
> Does anybody know which way this will be implemented in the standard?
> I found what Mike found, that the Gnu compiler allows it. But I know
> MS Visual C++ wants the size of the array to be a constant...

The C and C++ language definitions have always required a constant
expression of integral or enum type for the array size. That
requirement will not change in the current standard. Some
compilers allow non-constant array sizes as an extension.

--
Steve Clamage, stephen.clamage_nospam@eng.sun.com
( Note: remove "_nospam" when replying )
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Steve Clamage <stephen.clamage_nospam@Eng.Sun.COM> writes:

|>  Bob Sullivan wrote:
|>  >
|>  > : int foo(size_t x)
|>  > : {
|>  > :   int my_array[x];
|>  > :
|>  > :   // ...
|>  > : }
|>  > :
|>  > : Now, g++ accepts this as being ok, and in other cases I can fudge it by
|>  > : using alloca(), ...
|>  >
|>  > Does anybody know which way this will be implemented in the standard?
|>  > I found what Mike found, that the Gnu compiler allows it. But I know
|>  > MS Visual C++ wants the size of the array to be a constant...
|>
|>  The C and C++ language definitions have always required a constant
|>  expression of integral or enum type for the array size. That
|>  requirement will not change in the current standard. Some
|>  compilers allow non-constant array sizes as an extension.

Which current standard:-)?  What Steve Clamage says is perfectly true
for the C++ standard presently under consideration.  There will,
however, be a new version of the C standard, probably before the end of
the decade (C9x), and it is fairly sure that the above code will be
legal in it.  It is also probable that, as soon as it becomes legal C,
C++ implementations will also support it, considering it likely that C++
will follow C in its next revision.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
        I'm looking for a job -- Je recherche du travail
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

brad.daniels@missioncritical.com (Brad Daniels) writes:

>Wasn't this exact kind of problem the reason for allocators?  You can make
>your own stack-style allocator that allocates a big chunk of memory, then
>treats it as a stack.  You end up with code like:
>
>MemoryStack s;
>
>void f(size_t len)
>{
> StackAllocator a(s);
> vector<int,StackAllocator> v(len,0,a);
> ...
>}
>
>Where the StackAllocator ctor saves the current position in MemoryStack and
>the dtor releases all the memory.  The one downside is that you can't grow
>the MemoryStack object easily without having linked lists of stack regions.

There are other downsides.  Allocating from a StackAllocator probably
requires a load or two and a store, whereas alloca() may be just a
single register increment instruction.  Also using alloca() may
result in better locality.

For most code the difference would be insignificant, but there are
some applications where such distinctions are important.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Valentin Bonnard wrote:
>
> Mike Harrold <ao@infinet.com> writes:
>
> > Why is:
> >
> > int foo(size_t x)
> > {
> >   int my_array[x];
> >
> >   // ...
> > }
> >
> > not allowed?
>
> [ same code with my_object - elided ]
>
> > it becomes more difficult as I have to invoke destructors and constructoes
> > manually.
> >
> > Now, I could use 'new' of course, but that invokes large overhead, something
> > that is not acceptable since the object is only being used temporarily.
> >
> > The draft standard says that (paraphrased) "what lies between [ and ] must
> > be a constant".
> >
> > Why?
>
> Because it can be complicated to implement (on some system alloca isn't
> implemented for the same reason).
>
> You can use vector to handle the ctor/dtor (don't call
> new[]/delete[] manually, your code won't be exception safe).
>
> vector<my_object> my_array (x);
> // size is x, elements are default constructed
>
> In general, the solution to question 'something with an array
> doesn't works' is 'use vector', in particular the followings:
> - I can't instantiate a containner with an array
> - I can't use = to assign with an array
> - I can pass a Derived[] if the function wants a Base[]
>   with no warning (it crashes at runtime)
>
> If you don't want the overhead, you can write an STL containner
> using alloca (or new if alloca isn't present); the containner
> will be a fixed dynamic size containner, not a sequence.

And how do you do this?
The alloca call would have to be in a member function of the
container (probably the constructor). But then the memory is
released as soon as you return to the function that wanted to
use that container...
The problem is that alloca allocates memory in the local scope.
I don't know a way to allocate memory in the *callers* scope
(and I guess it would be very difficult to implement a
"caller_alloca" function...)
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

James Kuyper <kuyper@wizard.net> writes:

>Fergus Henderson wrote:
>>
>> Actually there is a freely available implementation of alloca()
>> using malloc() that works on almost all systems.  It doesn't
>> reclaim space as soon as a function returns, instead it reclaims
>> the space at the next call to alloca().
>
>How does it determine which space can safely be reclaimed? I don't know
>of any method for determining whether or not the functions that made
>previous calls to alloca() have returned yet.

Actually I misspoke slightly; it doesn't necessary reallocate at the
very next call to alloca().  To quote the source:

 | The general concept of this implementation is to keep
 | track of all alloca-allocated blocks, and reclaim any
 | that are found to be deeper in the stack than the current
 | invocation.  This heuristic does not reclaim storage as
 | soon as it becomes invalid, but it will do so eventually.
 |
 | As a special case, alloca(0) reclaims storage without
 | allocating any.  It is a good idea to use alloca(0) in
 | your main control loop, etc. to force garbage collection.

It is not standard-conforming code, but it works on almost all systems.
It uses pointer comparisons on local variables (for details, see the source;
it is distributed with many GNU programs, e.g. gcc).  For those rare
systems where the stack is stored as a linked list of frames or segments,
rather than as a single linear address segment, some system-specific
code is needed to walk the list of frames or segments.  The alloca.c source
includes code to do this on Crays, which are the only existing systems
that I know of that fall into this class.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

On 26 Aug 97 06:44:03 GMT, Steve Clamage <stephen.clamage@eng.sun.com>
wrote:

>Mike Harrold wrote:
>>
>> I apologise if this has been asked before.
>>
>> Why is:
>>
>> int foo(size_t x)
>> {
>>   int my_array[x];
>>
>>   // ...
>> }
>>
>> not allowed?
>>
>> Now, g++ accepts this as being ok, and in other cases I can fudge it by
>> using alloca(), ...
>
>Allowing an auto array size which is not an integral constant
>expression means that the runtime system must be able to deal
>with stack frames whose size cannot be known until function
>invocation at run time.
...

Wasn't this exact kind of problem the reason for allocators?  You can make
your own stack-style allocator that allocates a big chunk of memory, then
treats it as a stack.  You end up with code like:

MemoryStack s;

void f(size_t len)
{
 StackAllocator a(s);
 vector<int,StackAllocator> v(len,0,a);
 ...
}

Where the StackAllocator ctor saves the current position in MemoryStack and
the dtor releases all the memory.  The one downside is that you can't grow
the MemoryStack object easily without having linked lists of stack regions.

- Brad
----------------------------------------------------------------------------
Brad Daniels                  |  Was mich nicht umbringt macht mich hungrig.
Mission Critical Software     |   - Otto Nietzche
Standard disclaimers apply    |     (Friedrich's corpulent brother)
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

ao@infinet.com (Mike Harrold) writes:

> The draft standard says that (paraphrased) "what lies between [ and ] must
> be a constant".
>
> Why?

Because the size of local objects must be known at compile time.
Otherwise the compiler cannot decide how big the stack frame needs to
be.


--
______________________________________________________________________
Marcelo Cantos, Research Assistant       __/_  marcelo@mds.rmit.edu.au
Multimedia Database Systems Group, RMIT   /       _ Tel 61-3-9282-2497
L2/723 Swanston St, Carlton VIC 3053, Aus/ralia ><_>Fax 61-3-9282-2490
Acknowledgements: errors - me; wisdom - God; sponsorship - RMIT
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Mike Harrold wrote:
>
> I apologise if this has been asked before.
>
> Why is:
>
> int foo(size_t x)
> {
>   int my_array[x];
>
>   // ...
> }
>
> not allowed?
>
> Now, g++ accepts this as being ok, and in other cases I can fudge it by
> using alloca(), ...

Allowing an auto array size which is not an integral constant
expression means that the runtime system must be able to deal
with stack frames whose size cannot be known until function
invocation at run time.

That problem is difficult to deal with on some systems, and
on some systems violates the ABI (the Application Binary
Interface which defines the runtime layout and protocols of all
programs on the platform).

If code such as your example was standard, implementors would be
forced to choose between following the language standard and
following the platform ABI. While a particular implementation
might choose to violate one or the other for some particular
reason, it would be a poor idea for the standard to make
conforming implementations impossible on popular systems.

For the same reason, alloca is not a standard language feature,
and is not available on all systems.

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Marcelo Cantos <marcelo@janus.mds.rmit.edu.au> writes:

>ao@infinet.com (Mike Harrold) writes:
>
>> The draft standard says that (paraphrased) "what lies between [ and ] must
>> be a constant".
>>
>> Why?
>
>Because the size of local objects must be known at compile time.
>Otherwise the compiler cannot decide how big the stack frame needs to
>be.

The compiler need not decide how big the stack frame needs to be
_at compile time_; it is quite possible to decide this at runtime.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Mike Harrold <ao@infinet.com> writes:

> Why is:
>
> int foo(size_t x)
> {
>   int my_array[x];
>
>   // ...
> }
>
> not allowed?

[ same code with my_object - elided ]

> it becomes more difficult as I have to invoke destructors and constructoes
> manually.
>
> Now, I could use 'new' of course, but that invokes large overhead, something
> that is not acceptable since the object is only being used temporarily.
>
> The draft standard says that (paraphrased) "what lies between [ and ] must
> be a constant".
>
> Why?

Because it can be complicated to implement (on some system alloca isn't
implemented for the same reason).

You can use vector to handle the ctor/dtor (don't call
new[]/delete[] manually, your code won't be exception safe).

vector<my_object> my_array (x);
// size is x, elements are default constructed

In general, the solution to question 'something with an array
doesn't works' is 'use vector', in particular the followings:
- I can't instantiate a containner with an array
- I can't use = to assign with an array
- I can pass a Derived[] if the function wants a Base[]
  with no warning (it crashes at runtime)

If you don't want the overhead, you can write an STL containner
using alloca (or new if alloca isn't present); the containner
will be a fixed dynamic size containner, not a sequence.

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Mike Harrold wrote:
>
> Marcelo Cantos (marcelo@janus.mds.rmit.edu.au) wrote:
> : ao@infinet.com (Mike Harrold) writes:
>
> : > The draft standard says that (paraphrased) "what lies between [ and ] must
> : > be a constant".
> : >
> : > Why?
>
> : Because the size of local objects must be known at compile time.
> : Otherwise the compiler cannot decide how big the stack frame needs to
> : be.
>
> This isn't true. The compiler can extend the stack frame in precisely
> the same way it does with alloca(). ...
>
> Now I will admit this is one particular implementation, but the question
> still stands:  if it's possible to do it using alloca(), then why is it
> not possible to do it via array initialisation?

You have the question backwards. If it is possible to do one, it is
possible to do the other in the same way. But alloca is not standard
C or C++, and is not available on all systems precisely because some
systems need to specify stack frame size at compile time.

Someone pointed out that if alloca can't be implemented by extending
the stack, it can be implemented by allocating heap space. I don't
think that is correct, because the operations are not comparable.

Alloca is cheap and the stack space is reclaimed automatically
on function exit, no matter how the function exits. I don't know
what systems do if alloca cannot get enough space (some systems have
limited stack space), but I assume the result in C is some sort of
ungraceful crash. I suppose a C++ implementation could throw a
"bad_alloc" exception, but I don't know whether any of them do.

Heap allocation is expensive, and to avoid memory leaks the compiler
would have to generate extra code to ensure that the memory
is reclaimed no matter how the function exited. A programmer
expecting cheap allocation would be rightfully suprised at the
performance hit. On the other hand, to get dependable behavior,
you can use "new" and an auto_ptr.

I've always viewed alloca as a low-level hack, not a real language
feature.

Auto arrays with variable size seem like a reasonable request,
but C++ has other dependable mechanisms to get the same effect.
You can use an array class (which is safer than a C-style array),
or allocate the array on the heap yourself (via an auto_ptr).

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Steve Clamage <stephen.clamage@eng.sun.com> writes:

>... alloca is not standard
>C or C++, and is not available on all systems precisely because some
>systems need to specify stack frame size at compile time.

Actually there is a freely available implementation of alloca()
using malloc() that works on almost all systems.  It doesn't
reclaim space as soon as a function returns, instead it reclaims
the space at the next call to alloca().

>Heap allocation is expensive, and to avoid memory leaks the compiler
>would have to generate extra code to ensure that the memory
>is reclaimed no matter how the function exited. A programmer
>expecting cheap allocation would be rightfully suprised at the
>performance hit.

Performance is a quality-of-implementation issue.
(So are memory leaks, for that matter.)

>On the other hand, to get dependable behavior,
>you can use "new" and an auto_ptr.

That's hardly going to give you better performance than alloca()
or variable-length auto arrays.  If the choice is between performance
that is sometimes good and sometimes bad or performance that is
dependably bad, then usually I'll want the former.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

I apologise if this has been asked before.

Why is:

int foo(size_t x)
{
  int my_array[x];

  // ...
}

not allowed?

Now, g++ accepts this as being ok, and in other cases I can fudge it by
using alloca(), but if the code was:

int foo(size_t x)
{
  my_object my_array[x];

  // ...
}

it becomes more difficult as I have to invoke destructors and constructoes
manually.

Now, I could use 'new' of course, but that invokes large overhead, something
that is not acceptable since the object is only being used temporarily.

The draft standard says that (paraphrased) "what lies between [ and ] must
be a constant".

Why?

/Mike

--
+--------------------------------------------------------------------------+
| Take the cheese to sickbay, the Doctor should take a look at it as soon  |
| as possible.  --  B'lanna Torres - Star Trek Voyager - 'Learning Curve'. |
+--------------------------------------------------------------------------+
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Matt Austern (austern@isolde.mti.sgi.com) wrote:
: fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:

: > That's hardly going to give you better performance than alloca()
: > or variable-length auto arrays.  If the choice is between performance
: > that is sometimes good and sometimes bad or performance that is
: > dependably bad, then usually I'll want the former.

: I agree with Fergus that the implementation difficulties aren't
: the real issue.

: On the other hand, there is one tricky point about a variable- sized
: array: if A is a variable-sized array, then, by definition, sizeof(A)
: can't be known at compile time.  This raises a number of issues, since
: the assumption that sizeof is always known at compile time is fairly
: fundamental.

If I wanted sizeof(A), then I wouldn't be trying to do what I'm doing :-)

: As one example: do you allow variable-size arrays as struct members?
: If so, then you've got two different kinds of structs with different
: rules; if not, then you've got a new kind of type that can be declared
: in some contexts but not others.

All I want is a temporary array of objects, be they ints or a full class.
I'm not prepared to take the performance hit of using the heap (malloc &
free, which new/delete eventually reference, combine for close to 500
machine instructions on my system) for something that is only going to
exist for a few nanoseconds, when I can do it using "int my_array[x]" (at
least on my current system with g++).

/Mike

--
+--------------------------------------------------------------------------+
| Take the cheese to sickbay, the Doctor should take a look at it as soon  |
| as possible.  --  B'lanna Torres - Star Trek Voyager - 'Learning Curve'. |
+--------------------------------------------------------------------------+
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Fergus Henderson wrote:
>
> Steve Clamage <stephen.clamage@eng.sun.com> writes:
>
> >... alloca is not standard
> >C or C++, and is not available on all systems precisely because some
> >systems need to specify stack frame size at compile time.
>
> Actually there is a freely available implementation of alloca()
> using malloc() that works on almost all systems.  It doesn't
> reclaim space as soon as a function returns, instead it reclaims
> the space at the next call to alloca().
>

How does it determine which space can safely be reclaimed? I don't know
of any method for determining whether or not the functions that made
previous calls to alloca() have returned yet.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

ao@infinet.com (Mike Harrold) writes:

> : As one example: do you allow variable-size arrays as struct members?
> : If so, then you've got two different kinds of structs with different
> : rules; if not, then you've got a new kind of type that can be declared
> : in some contexts but not others.
>
> All I want is a temporary array of objects, be they ints or a full class.
> I'm not prepared to take the performance hit of using the heap (malloc &
> free, which new/delete eventually reference, combine for close to 500
> machine instructions on my system) for something that is only going to
> exist for a few nanoseconds, when I can do it using "int my_array[x]" (at
> least on my current system with g++).

Speaking as a programmer, that's a fair enough request.  I've
sometimes wanted to do it too.

Speaking as a language lawyer, though (this is a standards newsgroup,
after all): if you put a new feature into a language, you have to
think about how it interacts with every existing feature.  That's
especially true when it's as complicated a language as C++.

C++ has structs.  How would the language have to change once C++ has
both structs and variable-sized arrays?  Either you have to change the
standard so that it defines what happens when you combine those two
features, or else you have to change the standard so that it forbids
combining them.  (And you have to be precise about exactly what's
being forbidden.)

I know that this is possible.  It's not trivial, though.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]