Possible bug in 8.0 for linux: non-POD based

Possible bug in 8.0 for linux: non-POD based

Here is a snipet of a code that produces a non-POD error:
#include "Complex.h"
//Complex is a perfectly good class that I've used several times over.
//it serves merely as an example class.

void GimmeAnError{
int n=100;
Complex x[n];
return;
}

int main(){
GimmeAnError();
return;
}

When compiled, this code produces an error:
unsupported underlying vla type (non-POD)
x[n];

However, if I declare n explicitly, it compiles and runs just fine. This function is:

void NoError{
Complex x[100];
}

What's up with this? It seems to be a pretty crippling bug in the compiler.

Joel

4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Joel,

It looks like you are mixing C++ and variable length arrays (consider vla either a gcc feature or a C99 feature). I believe the error we produce is by design because getting construction and destruction correct when using vlas is very difficult to do. Why didn't you just use a vector constructor for your array of complex type?

Max

Max,

Thanks for the response. I am not sure if I understand your comment exactly, but the reason that I don't use a vector class constructor is that I'm writing intensive numerical code where speed and efficiency are of the essence. I choose an array of complex over a vector class for a few reasons. The first is that an array puts all of the classes in one area of the cpu. There is no guarantee that a vector class will do the same, though I have written one that I believe does. The second is that to access elements of the vector class, one has to go call an overloaded [] operator as opposed to the direct array access []. In an inner loop, this can really slow you down even if you are careful and declare the operator[] as an inline function.

In any case, I'm not sure I see what the problem is. The compiler should have no problem with Complex *x = new Complex [n] (an array on the heap and in fact what a reasonable vector class should do upon instantiation) any more than it should have it with Complex [n];. In gcc the class calls the default constructor for each element in the array as it should. Regardless, the fact that if you declare n explicitly and input the numerical value instead of the variable name (int n=100) indicates to me that it is not a design but rather a bug. Am I missing something?

Thanks,

Joel

Having put this message into the Intel compiler myself I can assure
you that it was intentional. Variable length arrays are a feature of
C99, not standard C++. Gnu has chosen to support them in C++,
but there are many bugs in their implementation (when it comes
to destroying themcorrectlyduring exception handling, for example).

Since it is a major chore to get them to work correctly with C++
the Intel compiler chose to only implement them with types that
aretypes that you would find in C, i.e. plain old data types.

The C++ committee has not considered adding them to the language
since using the standard library vector class is the preferred method.

Judy

Login to leave a comment.