Warning 'Variable lenght arrays in C++ are a Clang extension'

[Christian Ehrlicher]

@MortyMars I wrote what you have to change.

[IgKh]

@MortyMars

As far as the standards go, the size of everything that is allocated on the stack must be known at compile time. Various vendor extensions (and the C99 revision of the C standard, which has since deprecated it) allow breaking this rule for local arrays. This is generally perceived to be a bad idea, and should avoided, because:

1. Stack space is typically more limited relative to the heap, allocating large arrays on the stack will increase chance of a stack overflow.
2. It makes it harder for the compiler to verify that all reads and writes of local variables happen within the current stack frame. Writing outside of the frame (especially when it is guided by user input) is an extremely serious security vulnerability, and often a component in privilege escalation exploits.

So yes - you really should allocate anything that you don't know the size of ahead of time on the heap, and ideally in a managed container. I'm not sure why a vector won't do for you - wanting a 2D array isn't an excuse, you can do a vector of vectors, a vector of structs, or allocate sufficient space and treat the one vector's data pointer as a row-by-row 2D array.

[JonB]

@IgKh said in Warning 'Variable lenght arrays in C++ are a Clang extension':

size of everything that is allocated on the stack must be known at compile time

Just for the record, I don't see any evidence that the OP's code is inside any function or allocated on the stack. It might be, but it might just as well not be. If it is "global" scope (or for that matter class variables where no instance is ever stack-allocated) you still need to use constexpr (or equivalent) and not just const, because it needs to be a constant and not a variable, right?

[IgKh]

@JonB In OP's provided source code, they have in their ApprochWindow::createTableauFixes method:

// Définition du tableau qui recevra les données de 'user_fix.dat'
QString tabFix[NBLINES][7];

This is definitely a stack allocation. But you are probably right - I don't believe that even globals and statics are allowed to be unsized in C++, if only for the technical reason that the linker needs to know how big the data segment is at link time at the very latest.

[JonB]

@IgKh
I only looked at the 2-line screenshot :)

And I don't think it's just a linker issue, it's a compiler one too. If you have, say in a class or for that matter on the stack,

int array[non_constexpr_size];
int next_variable;

I don't think the compiler can even generate code since it does not know the offset of next_variable at compile-time. Or perhaps they figure a way because it's an optional "extension", but I can see the problem.

I don't mean to be on your case! What you said is good. It's just that there are lots of/complex reasons why "vanilla" C/C++ has this restriction.

[MortyMars]

@Christian-Ehrlicher said in Warning 'Variable lenght arrays in C++ are a Clang extension':

I wrote what you have to change.

Hi @Christian-Ehrlicher

I obviously paid attention to your message and immediately tried out the suggested code.
Unfortunately I don't get a ‘warning’ any more, but an ‘error’ preventing me from going any further.

Unless there's something else behind your answer, which I didn't understand... ?!

[JonB]

@MortyMars
Like it says, a constexpr must be assigned/set to a constant value, like 10. Assuming your nbrLignes is some variable it is not acceptable. It does not matter which way up you look at it/try to do it, you cannot declare an array with a size which is ultimately a variable, as per previous discussions.

In a word, if nbrLignes or NBLINES or anything else is not a constant you cannot use it for the size of a plain array, because they require a fixed, constant size. You could new an array with a variable size, or you could use some non-fixed-size container such as std:array or QList/QVector if you want variability, but not a plain C-type like array[SIZE] as a local or global variable.

[MortyMars]

@IgKh said in Warning 'Variable lenght arrays in C++ are a Clang extension':

you can do a vector of vectors, a vector of structs, or allocate sufficient space and treat the one vector's data pointer as a row-by-row 2D arrayThank you ... for your help.

Thank you @IgKh for your help

As I said, I tried the vector of vectors solution, but I wasn't able to manage the matrix created, both in writing and reading the data, without running into access errors that prevented compilation.

Furthermore, as I see it, a 2D array seems (wrongly, it seems) to be more appropriate.

But I'm not definitively rejecting the idea of returning to vectors...

[MortyMars]

@JonB said in Warning 'Variable lenght arrays in C++ are a Clang extension':

I don't mean to be on your case! What you said is good. It's just that there are lots of/complex reasons why "vanilla" C/C++ has this restriction

Thank you @JonB for these very clear explanations, even if I'm beginning to realiseund that I'm going to have to reconsider my choice of a 2D array... :-(

[JonB]

@MortyMars said in Warning 'Variable lenght arrays in C++ are a Clang extension':

As I said, I tried the vector of vectors solution, but I wasn't able to manage the matrix created, both in writing and reading the data, without running into access errors that prevented compilation.

Then you need to correct that. Code using vector-of-vector can be addressed just as much/in same way as array-of-array.

Vector-of-vector seems just as suitable as array-of-array for a two-dimensional array/container. (Assuming you are "in charge" of the data structure, not trying to make your structure correspond to something received from the outside world in a particular layout format.)

You can use an array-of-array, effectively, if that is what you want. You just cannot declare it as array[variable][variable]. You can do it e.g. with news and/or making it more like QString **array per the old C way. But I think people would recommend e.g. a std::array of std::array.

[IgKh]

@MortyMars I see how one can struggle with a vector of vectors, since you have to resize every element of the outer array prior to use.

But, since one dimension is dynamically size, and one isn't, you can mix and match to improve ergonomics.

Consider declaring tabFix as:

std::vector<std::array<QString, 7>> tabFix;
tabFix.resize(nbrLignes);

This pre-allocates 7 empty QStrings for each line at runtime, so you access it just like a 2D array.

[MortyMars]

@JonB said in Warning 'Variable lenght arrays in C++ are a Clang extension':

Vector-of-vector seems just as suitable as array-of-array for a two-dimensional array/container. (Assuming you are "in charge" of the data structure, not trying to make your structure correspond to something received from the outside world in a particular layout format.

So I'm going to try my luck again with the vector-to-vector solution that I'd abandoned.
And I'll take the liberty of asking you again to correct my code as I go along... ;-)

Thanks again to everyone in the meantime.

[MortyMars]

@IgKh said in Warning 'Variable lenght arrays in C++ are a Clang extension':

Consider declaring tabFix as:

std::vector<std::array<QString, 7>> tabFix;
tabFix.resize(nbrLignes);
This pre-allocates 7 empty QStrings for each line at runtime, so you access it just like a 2D array

A huge thank you @IgKh

Your solution, which is a good compromise between what the community plebiscites and my personal stubbornness, works perfectly!!!!

No more error messages and even fewer errors, while still accessing my data naturally (IMHO).