468,512 Members | 1,390 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,512 developers. It's quick & easy.

size of array is not an integral constant-expression

#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.
Mar 12 '08 #1
8 6700
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.
Mar 12 '08 #2
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
Mar 12 '08 #3
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.
Mar 13 '08 #4
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.
Mar 13 '08 #5
On Mar 12, 9:22 pm, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
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, +33 (0)1 30 23 00 34
Mar 13 '08 #6
James Kanze wrote:
On Mar 13, 12:45 am, johneh...@gmail.com 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
Mar 13 '08 #7
Vidar Hasfjord wrote:
Aside: Many C++ implementations provide a stack allocation feature as
an extension (alloca).
What is the purpose?
Mar 18 '08 #8
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.
Mar 18 '08 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

14 posts views Thread by Gianni Mariani | last post: by
7 posts views Thread by news.hku.hk | last post: by
22 posts views Thread by Wynand Winterbach | last post: by
4 posts views Thread by Bilgehan.Balban | last post: by
78 posts views Thread by Frederick Gotham | last post: by
6 posts views Thread by lazy | last post: by
33 posts views Thread by Adam Chapman | last post: by
1 post views Thread by fmendoza | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.