size of array is not an integral constant-expression

[johnehein]

#include <vector>
using namespace std;

template <typename Iter>
int
foo(Iter first, Iter last, int nn)
{
const size_t n = last - first;
double buf[n];
return 0;
}

int
main(int argc, char **argv)
{
vector<doublex;
foo(x.begin(), x.end(), argc);
return 0;
}

foo.cc:17: instantiated from here
foo.cc:9: error: size of array is not an integral constant-expression

g++ 4.2.1

Is this error specific to g++ 4.x? g++ 3.6.4 and g++ 2.9.5 have no
problems with it, but that doesn't mean they are right. Is there some
reason to expect this to fail.

There are a few interesting workarounds that point to this being
unexpected behavior... I'll post those next.

[Ian Collins]

jo*******@gmail.com wrote:

#include <vector>
using namespace std;

template <typename Iter>
int
foo(Iter first, Iter last, int nn)
{
const size_t n = last - first;
double buf[n];
return 0;
}

int
main(int argc, char **argv)
{
vector<doublex;
foo(x.begin(), x.end(), argc);
return 0;
}

foo.cc:17: instantiated from here
foo.cc:9: error: size of array is not an integral constant-expression

g++ 4.2.1

Is this error specific to g++ 4.x?

No, n is not a compile time constant, the error specific to any
conforming compiler!

The expression

const size_t n = last - first;

double buf[n];

declares (in C99) a variable length array, something gcc in default mode
has supported for years.

C++ does not have VLAs.

--
Ian Collins.

[Victor Bazarov]

jo*******@gmail.com wrote:

#include <vector>
using namespace std;

template <typename Iter>
int
foo(Iter first, Iter last, int nn)
{
const size_t n = last - first;
double buf[n];
return 0;
}

int
main(int argc, char **argv)
{
vector<doublex;
foo(x.begin(), x.end(), argc);
return 0;
}

foo.cc:17: instantiated from here
foo.cc:9: error: size of array is not an integral constant-expression

g++ 4.2.1

Is this error specific to g++ 4.x?

Not that I can see. 'last - first' is a run-time expression. And when
you use it to initialise a 'const size_t', the variable ('n') also
becomes a run-time expression. It cannot be used to declare an array.

g++ 3.6.4 and g++ 2.9.5 have no
problems with it, but that doesn't mean they are right. Is there some
reason to expect this to fail.

Yes, there is. It goes against the rules of the language. The older
versions of G++ may have had it as an extension. Hell, the new versions
may still have it as an extension, and you're welcome to use it, just
don't claim your program to be C++.

There are a few interesting workarounds that point to this being
unexpected behavior... I'll post those next.

What's so unexpected in actually implementing the rules of the language?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[johnehein]

So, it seems that adding -pedantic gives:
foo.cc:10: error: ISO C++ forbids variable-size array 'buf'
Sorry for the noise. Somewhere along the way I had gotten the
impression that the c++ standard included support for variable length
arrays. Apparently not - just a gcc-ism.

[Ian Collins]

jo*******@gmail.com wrote:

I'm not sure why everyone is giving the big thumbs down to run time
array sizing. C++ doesn't have a problem with the concept in
general. As mentioned by someone, C99 has some support for it, too,
but that's not directly relevant to the issue I've just noticed.

It isn't part of the language.

All the things you have noted are specific gcc behaviour when that
compiler isn't used in compliant mode.

If you use gcc, use

g++ -ansi -pedantic -Wall

--
Ian Collins.

[James Kanze]

On Mar 12, 9:22 pm, "Victor Bazarov" <[e-mail]:

What's so unexpected in actually implementing the rules of the
language?

The fact that almost no compiler does? How many support export,
for example? If I base my expectations on practical experience,
I expect that any given compiler is likely to deviate from the
rules in various places.

It makes writing truely portable code very hard.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Default User]

James Kanze wrote:

On Mar 13, 12:45 am, [e-mail] wrote:

As mentioned by someone, C99 has some support for it, too, but
that's not directly relevant to the issue I've just noticed.

For whatever reasons, the C++ standards committee decided not to
adapt this feature of C99.

They probably felt std::vector was a better solution.

Brian

[Jeff Schwab]

Vidar Hasfjord wrote:

Aside: Many C++ implementations provide a stack allocation feature as
an extension (alloca).

What is the purpose?

[Ian Collins]

Jeff Schwab wrote:

Vidar Hasfjord wrote:

>Aside: Many C++ implementations provide a stack allocation feature as
an extension (alloca).

What is the purpose?

Much the same as VLAs, to save the cost of a dynamic allocation.
alloca shares the biggest drawback of VLAs - lack of failure notification.

--
Ian Collins.