Do array dimensions have to be constant???

I have heard and read a LOT about how array dimensions should be either const or macros, but I almost NEVER do it that way. For example:
1
2
3
4
5
6
7
8
9
10
#include <iostream>

using namespace std;

int main()
{
    int n;
    cin>>n
    int array[n];
}

It works perfectly and the compiler gives no warnings. Is that realy OK, or is there something wrong with my compiler?
In C++ they must be a constant. Some compilers (like yours) use a C backend and allow this type of behavior (which is allowed in C99). You shouldn't rely on it though.
It works perfectly and the compiler gives no warnings.
The compiler does generate warnings if instructed to. There's a discussion of the matter here: http://www.cplusplus.com/forum/unices/56833/#msg306366
The correctapproach is to use new operator:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#include <iostream>

using namespace std;

int main()
{
    int n;
    cin>>n
    int *array = new int[n];


    // use array here ...


    delete [] array;
    return 0;             // return statement
}
Putting arrays on the stack is asking for trouble, whether the compiler supports it or not.
Even putting static arrays on the stack is asking for trouble, unless you know what you are doing.
Last edited on
Are you saying that every time I need an array wose size is know only at run-time, I should use vector? That's silly!!! I used variable-sized arrays ever since the first day I learned c++, and I never got one error! That simply ridiculous! Why would the have to be constants when my compiler is proof that it can be done in a much easier way?! WHAT SENSE DOES THAT MAKE!?!?!?!?!?!!??!!?!?!?!?!?!?!?!?!?!?!?!??!!?!?!?!
I used variable-sized arrays ever since the first day I learned c++, and I never got one error!

You would if you used a C++ compiler. You must be using something that looks a lot like a C++ compiler, but actually isn't.

Why would the have to be constants when my compiler is proof that it can be done in a much easier way?! WHAT SENSE DOES THAT MAKE!?!?!?!?!?!!??!!?!?!?!?!?!?!?!?!?!?!?!??!!?!?!?!

IT MAKES LOTS OF SENSE BECAUSE LOCAL ARRAYS GET PUT ON THE STACK AND IF YOU DON'T KNOW HOW MUCH SPACE YOU'RE GOING TO NEED AT COMPILE TIME ON THE STACK THINGS GET A LOT MORE COMPLICATED SO WHY WOULD YOU DO THAT IN C++ WHEN YOU COULD JUST USE THE ALREADY EXISTING HEAP MEMORY OR A CONTAINER LIKE VECTOR. IF YOU WANT A PROGRAMMING LANGUAGE DESIGNED TO BE EASY FOR YOU INSTEAD OF SENSIBLE, YOU'VE PICKED THE WRONG LANGUAGE.

I don't even know why this is a feature in C99, but then again C and C++ really have gone their separate ways. I always imagined we don't allow non-constant arrays in C++ even though we could have them is for, well, exactly the reason Moschops just gave... the stack's not the best place for dynamically sized arrays!
Are you saying that every time I need an array wose size is know only at run-time, I should use vector?
Pretty much, yes; unless you have reason to do otherwise.

That's silly!!!
Not really, you have no idea how large the stack is or where you are on the call stack. The default stack on the Microsoft C compilers/linkers on MS-DOS is 2K. You can't get careless with stacks that small.

I used variable-sized arrays ever since the first day I learned c++, and I never got one error! That simply ridiculous
Hopefully by now you should realise that was an error.

Why would the have to be constants when my compiler is proof that it can be done in a much easier way?! WHAT SENSE DOES THAT MAKE!?!?!?!?!?!!??!!?!?!?!?!?!?!?!?!?!?!?!??!!?!?!?!
The point is C++ doesn't just provide support for large systems, but small systems too; for systems that grow the stack automatically, and ones that don't.

C++ is a system programming language, a language for doing specific deterministic things to the environment. Automatic facilities at the low level inhibit that goal.
Moschops wrote:
You would if you used a C++ compiler. You must be using something that looks a lot like a C++ compiler, but actually isn't.

So, MinGW 3.4.2 with gcc-c++ isn't a c++ compiler?

Veltas wrote:
the stack's not the best place for dynamically sized arrays!

Are you saying stuff can be put elsewhere, not just on the call stack?
Last edited on
So, MinGW 3.4.2 with gcc-c++ isn't a c++ compiler?

Obviously not, if it compiles something that isn't C++. How else do you explain it?

If you get a version of gcc from this decade, you can make it a C++ compiler with the right command switches.

Are you saying stuff can be put elsewhere, not just on the call stack?

The heap. That's where stuff goes when you use new, for example.
Last edited on
Moschops wrote:
Obviously not, if it compiles something that isn't C++. How else do you explain it?

Shouldn't it be the other way around? If it can't compile something that is C++, then it can't be a C++ compiler. That would disqualify all compilers, I know.

ยง1.4/8
A conforming implementation may have extensions (including additional library functions), provided they do not alter the behavior of any well-formed program. Implementations are required to diagnose programs that use such extensions that are ill-formed according to this International Standard. Having done so, however, they can compile and execute such programs.


Moschops wrote:
If you get a version of gcc from this decade, you can make it a C++ compiler with the right command switches.

actualy I did, but on my other comp. I copied it to this comp, but then I realised something was wrong with it, I fixed it in my other comp, but I forgot how to fix it on this comp. And yes, it compiles variable-sized arrays there perfectly too! The new compiler is MinGW with GCC 4.7.0, new enough for you?
Last edited on
The new compiler is MinGW with GCC 4.7.0, new enough for you?


Yes. You can turn it into a C++ compiler (which will not compile things that are not C++, such as variable-sized arrays) with the appropriate command line switches.
Add the compiler flags -pedantic (or -pedantic-errors) and -std=c++03 (or -std=c++11) and you will be told that variable-sized arrays are not valid C++.
Topic archived. No new replies allowed.