In article <08bb50913040f49CPIMSSMTPU07@email.msn.com>,
  "superdude" <don't.even.think.about.it@EU.net> wrote:
> I'm surprised to hear this. People use compile time assertions using
> sizeof().

But this isn't standard C++, and doesn't compile everywhere.

----
Allan_W@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Siemel Naran <sbnaran@localhost.localdomain> wrote in message
news:slrn7hcar0.a7u.sbnaran@localhost.localdomain...
[...]
> >std::vector is good at meeting the goal of being a relatively safe,
> >variable-sized array.   However, it does not meet the goal initially
> >presented for this thread, which is to be inexpensive.
>
> What do you mean by "inexpensive".
>
> I've found that std::vector<double>(n) is about 0.1% slower than
> double[n].  Of course, this result is with -O2 optimization.  At -O1
> or no optimization, the fixed say array method is still faster.

In your test is n a constant?  Without current support for variable-sized
arrays, I don't see how you can compare a variable-sized array using syntax
like double[n].  Using a constant n doesn't provide a meaningful test
because the compiler can apply significant optimizations to
vector<double>(n) that it can't do if n is unknown at compile time.

The real issue is with the expense (i.e. speed) of stack allocation versus
heap allocation.  Generally heap allocation requires significant work
whereas stack allocation involved simply teaking a stack pointer.

To compare the two, you need a way to do variable-size stack allocation
using current compilers.  For example, a comparison could look something
like this:

void stack_fn(unsigned n)
{
    int* p = static_cast<int*>(_alloca(n));
    // Do something useful with p to ensure that it does not get optimized
out.
}

void vector_fn(unsigned n)
{
    std::vector<int> v(n);
    // Do something useful with v to ensure that it does not get optimized
out.
}

Note that the _alloca above is a Visual C++ extension to provide
variable-sized arrays.  It is not actually a function; the compiler converts
it to the proper assembly code directly.  Other compilers have their own
renditions of the feature.

> To me it seems that variable sized arrays are std::valarray in
> disguise.

Valarray is very different semantics than a simple variable-sized array, so
I wouldn't say that one is disguised as the other.  The question is whether
valarray is a worthy substitute for a variable-sized array.  Since a
valarray lives on the heap instead of the stack, it suffers from the same
performance problem as vector, and therefore fails to meet the efficiency
goal of a variable-sized array.
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

superdude wrote:
>
[I wrote, re: C9X]
> > sizeof(vla) is no longer a compile-time constant, which is a
> > large part of headaches the ISO C committee has had with the idea.
> I'm surprised to hear this. People use compile time assertions using
> sizeof(). Damage from modifying behavior of sizeof is greater than dubious
> advantages of variable-size arrays. I hope the committe has enough wisdom
> not to do that.

They haven't abandoned the idea so far, though it has been
controversial. VLA's will only appear in new code, and can't be parts of
structures, which minimizes (but does not remove) the likelihood of
existing sizeof()'s being impacted. Anyone who writes code using a VLA
will have to be careful about that, and a lot of other things as well.
I'm looking forward to using the technique; primarily in function
arguments. However, in C++ code I would use vector<> for the same
purpose, even though it's a somewhat 'heavier' construct.
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

superdude <me@web1.ucar.edu> wrote in message
news:08bb50913040f49CPIMSSMTPU07@email.msn.com...
> sizeof(vla) is no longer a compile-time constant, which is a
> > large part of headaches the ISO C committee has had with the idea.
> I'm surprised to hear this. People use compile time assertions using
> sizeof(). Damage from modifying behavior of sizeof is greater than dubious
> advantages of variable-size arrays. I hope the committe has enough wisdom
> not to do that.

The semantics of sizeof() only need to change when taking the size of a
variable-sized array.  So all current legal uses of sizeof() will continue
to work and sizeof() will continue to work as before (e.g. for compile time
assertions) for users who choose not to use the new variable-sized array
feature.

Complete backward compatibility and a nice new feature - what more could you
ask for?
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 15 Apr 99 13:29:32 GMT, Ed Brey <brey@afd.mke.etn.com> wrote:
>Fergus Henderson <fjh@cs.mu.OZ.AU> wrote in message

>> The C++ standard library includes a template class `vector' which you
>> can use for this purpose:

>std::vector is good at meeting the goal of being a relatively safe,
>variable-sized array.   However, it does not meet the goal initially
>presented for this thread, which is to be inexpensive.

What do you mean by "inexpensive".

I've found that std::vector<double>(n) is about 0.1% slower than
double[n].  Of course, this result is with -O2 optimization.  At -O1
or no optimization, the fixed say array method is still faster.

Also, std::vector<double>(n) has a greater total sizeof.  There is
space for n doubles, 1 double * pointer, 1 size_t capacity, 1
size_t size.  In reality, we only need 1 double * pointer, 1 size_t
size.  If saving sizeof(size_t) bytes is very important, use
std::valarray<double>.

To me it seems that variable sized arrays are std::valarray in
disguise.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I believe this is a very old question, but why isn't this legal:

    int n;
    // ...
    char buffer[n];

I was amazed to see that egcs would let me do it, and do it right.  So, if
variable-sized arrays on the local stack are possible, why didn't they make
it into the standard?  They are lots cheaper than using the heap.

    Philip
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Philip Koester" <kozmik@okay.net> writes:

>I believe this is a very old question, but why isn't this legal:
>
>    int n;
>    // ...
>    char buffer[n];

I don't know why Bjarne Stroustrup never included this in C++.

But the reason that the C++ committee never added support for it
was, I believe, that this sort of thing was seen as a C issue,
rather than a C++ issue, since it applies to the C subset of the
language.  Although Bjarne did a lot of innovation to make C++ a
better C, the C++ committee was much less keen on improving things
in the C subset, preferring to leave such innovations to the C committee.

However, you will be pleased to learn that the draft C9X standard,
which is the forthcoming new version of the ISO C standard, does include
support for variable-length arrays.  So it is very likely that this
will be supported by many C++ compilers in the not too distant future.
It is also very likely that support for variable-length arrays will
be included in the next revision of the C++ standard, although that
will not occur for quite some time.

--
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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Philip Koester wrote:
>
> I believe this is a very old question, but why isn't this legal:
>
>     int n;
>     // ...
>     char buffer[n];
>
> I was amazed to see that egcs would let me do it, and do it right.  So, if
> variable-sized arrays on the local stack are possible, why didn't they make
> it into the standard?  They are lots cheaper than using the heap.

They'll be in C9X; that means that they might find there way into the
next release of the C++ standard, many years from now. The C9X committee
has found lots of problems requiring very careful consideration with
defining them. I wouldn't be surprised to find even more problems trying
to move them into C++.
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Fergus Henderson <fjh@cs.mu.OZ.AU> wrote in message
news:7evvlt$hnv$1@mulga.cs.mu.OZ.AU...
>
> I just remembered another reason why this sort of thing isn't in C++:
> the idea in C++ was that C-style arrays are pretty error-prone and
> low-level anyway, and that if you wanted arrays which had more advanced
> features such as being variable-sized, having array bounds checking, etc.,
> you should use an array class.  See ARM ("The C++ Annotated Reference
> Manual"), page 137.
>
> The C++ standard library includes a template class `vector' which you
> can use for this purpose:
>
>       int n;
>       // ...
>       vector<char> buffer(n);

std::vector is good at meeting the goal of being a relatively safe,
variable-sized array.   However, it does not meet the goal initially
presented for this thread, which is to be inexpensive.

On the other hand, optimizations sometimes go beyond what is expected.  How
likely is it that heap allocation will become close to as cheap as stack
allocation?  Or how likely is it that a compiler can detect that an vector
lives only within a stack scope and intrinsically create it on the stack?

IMHO, the second seems more feasible.  Compilers have long replace ANSI C
functions such as memcpy with intrinsic optimizations.  Replacing classes
like vector, when appropriate, seems a logical next step.
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sizeof(vla) is no longer a compile-time constant, which is a
> large part of headaches the ISO C committee has had with the idea.
I'm surprised to hear this. People use compile time assertions using
sizeof(). Damage from modifying behavior of sizeof is greater than dubious
advantages of variable-size arrays. I hope the committe has enough wisdom
not to do that.
G.B.
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7etetl$7ei$1@newsreader.ipf.de>,
  "Philip Koester" <kozmik@okay.net> wrote:
> I believe this is a very old question, but why isn't this legal:
>
>     int n;
>     // ...
>     char buffer[n];
>
> I was amazed to see that egcs would let me do it, and do it right.  So, if
> variable-sized arrays on the local stack are possible, why didn't they make
> it into the standard?

Principally, I suspect, because it is a C question, and not a C++ one.
In this area, the general concensus is that C++ should remain C
compatible, and that any inovation should originate in C.

The current draft of C9x allows this, and I would expect to gradually
see it making itself into C++ compilers (other than g++/egcs) on the
grounds that it will be in the next version of C++ as well.

--
James Kanze                         mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                        Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany  Tel. +49 (069) 63 19 86 27

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 13 Apr 99 05:40:13 GMT, Philip Koester <kozmik@okay.net> wrote:

>I believe this is a very old question, but why isn't this legal:
>
>    int n;
>    // ...
>    char buffer[n];
>
>I was amazed to see that egcs would let me do it, and do it right.  So, if
>variable-sized arrays on the local stack are possible, why didn't they make
>it into the standard?  They are lots cheaper than using the heap.

In "char buffer[n]" or "Array<char,n> buffer", the variable 'n' must be an
integral constant -- ie, a constant whose value is known at compile time.
For the case of templates, this is necessary because it tells the compiler
which classes it must instantiate.  For the case of fixed size arrays, the
restriction doesn't do much.  At least it gives a slightly more efficient
implementation as sizeof(buffer) is known at compile time, so the compiler
knows how much stack space to allocate.

To get egcs to turn off its extensions to the C++ language, compile with
the "--pedantic" option.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Philip Koester" <kozmik@okay.net> wrote:
> I believe this is a very old question, but why isn't this legal:
>
>     int n;
>     // ...
>     char buffer[n];

I just remembered another reason why this sort of thing isn't in C++:
the idea in C++ was that C-style arrays are pretty error-prone and
low-level anyway, and that if you wanted arrays which had more advanced
features such as being variable-sized, having array bounds checking, etc.,
you should use an array class.  See ARM ("The C++ Annotated Reference
Manual"), page 137.

The C++ standard library includes a template class `vector' which you
can use for this purpose:

      int n;
      // ...
      vector<char> buffer(n);

--
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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I believe it's a bad idea. Though compiler can determine how much stack to
allocate for local array, it cannot determine sizeof(buffer) at compile
time. If you change the behavior of sizeof it would break a perfectly good
ANSI C++ code, so I doubt this feature will ever be a part of ANSI C++.
Neither there is a real need for it.
G.B.

Philip Koester <kozmik@okay.net> wrote in message
news:7etetl$7ei$1@newsreader.ipf.de...
> I believe this is a very old question, but why isn't this legal:
>
>     int n;
>     // ...
>     char buffer[n];
>
> I was amazed to see that egcs would let me do it, and do it right.  So, if
> variable-sized arrays on the local stack are possible, why didn't they make
> it into the standard?  They are lots cheaper than using the heap.
>
>     Philip
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

superdude wrote:
>
> I believe it's a bad idea. Though compiler can determine how much stack to
> allocate for local array, it cannot determine sizeof(buffer) at compile
> time. If you change the behavior of sizeof it would break a perfectly good
> ANSI C++ code, so I doubt this feature will ever be a part of ANSI C++.
> Neither there is a real need for it.
> G.B.

It almost certainly will be changed. Variable Length Arrays (VLA's) are
going to be part of C9X. The behavior of sizeof() does get complicated
with VLA's. sizeof(vla) is no longer a compile-time constant, which is a
large part of headaches the ISO C committee has had with the idea.

Expect VLA's to be part of the next C++ standard, and to be supported as
an extension by existing C++ compilers long before then.
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>To get egcs to turn off its extensions to the C++ language, compile with
>the "--pedantic" option.

I always have the pedantic option turned on, and I'll leave it on. I like
those warning messages remind me I'm doing something `illegal', and
otherwise enjoy this egcs feature =)  In fact, these are the first warning
messages I can cope with.

    Philip
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]