Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Warning 'Variable lenght arrays in C++ are a Clang extension'
Forum Updated to NodeBB v4.3 + New Features

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

Scheduled Pinned Locked Moved Solved General and Desktop
17 Posts 5 Posters 6.3k Views 3 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • MortyMarsM Offline
    MortyMarsM Offline
    MortyMars
    wrote on last edited by
    #1

    Hi everyone,

    I have a compiler warning about the length of an array which cannot be a variable.
    My problem is that this length depends on the number of lines in a file, which I don't know in advance.
    I thought that reassigning this variable to a constant would solve the warning problem, but this isn't the case.

    Capture d’écran 2024-10-23 à 21.45.03.jpg

    Would you have a solution, other than using a vector, as this option - which I've already explored - doesn't suit me, and I'd like to keep using an array.

    Thanks in advance!

    The code for the methods concerned :

    /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
    // Création d'un Tableau 2D pour les 'Fixes' du fichier '_user_nav.dat'
    void ApprochWindow::createTableauFixes() {
    
        // Création -si elle n'existe pas déjà- de l'arborescence des fichiers utilisés et créés par Procedures4XP
        QDir().mkpath(QDir::homePath() + "/Documents/Procedures4XP/source files");
        QString fichier = QDir::homePath() + "/Documents/Procedures4XP/source files/_user_fix.dat";
        QFile file(fichier); // Appel du constructeur de la classe QFile
    
        if (!file.open(QIODevice::ReadOnly | QIODevice::Text))
        {
            QMessageBox::information(
                this,
                tr("Fichier '_user_fix.dat' non trouvé"),
                QString(tr("Le fichier 'user_fix.dat' définissant les Waypoint personnalisés \n "
                           "n'a pas été trouvé ! \n"
                           " Certaines fonctionnalités ne seront donc pas actives.")),
                QMessageBox::Ok );
    
            return; // sortie de la MÉTHODE
        }
        
        
        // Comptage des lignes du fichier
        // CODE 1
        QString ligne;
        int nbrLignes = 0;
        while (!file.atEnd()) {
            ligne = file.readLine();
            nbrLignes ++;
        }
        qDebug() << "Le fichier _user_fix.dat comporte " << nbrLignes << " lignes";
        
        const int NBLINES = nbrLignes;  // NBLINES ne sera pas considérée comme une constante :-(
        
        
        // CODE 2, inefficace également pour créer une constante
        //const int NBLINES = compterLignes(&file);
        
        // Définition du tableau qui recevra les données de 'user_fix.dat'
        QString tabFix[NBLINES][7];
    
        QTextStream Flux_lu(&file);
        QString Mot_lu = "";
    
        // Retour au début du fichier, après comptage du nombre de lignes
        file.seek(0);
    
        // Pour les 'NBLINES' lignes du formulaire, d'indice 0 à NBLINES-1 ...
        for (int l = 0; l < NBLINES ; l++) {
            // ... et les 7 colonnes d'indice 0 à 6
            for (int c = 0; c < 7 ; c++) {
    
                // Un mot est lu à chaque boucle, et est placé en variable Mot_lu
                Flux_lu >> Mot_lu;
    
                // Remplissage du tableau 2D
                tabFix[l][c].insert(0,Mot_lu);
    
                // Sortie de la boucle en fin de fichier
                if (Flux_lu.atEnd()) break;
            }
        }
        file.close();
    }
    
    
    /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
    // Comptage du nombre de ligne
    int ApprochWindow::compterLignes(QFile* fichier) {
    
        QString ligne;
        int nombreLignes = 0;
        while (!fichier->atEnd()) {
            ligne = fichier->readLine();
            nombreLignes ++;
        }
        qDebug() << " Via 'compterLignes()', le fichier '_user_fix.dat' comporte " << nombreLignes << " lignes";
    
        const int NBL = nombreLignes;
        return NBL;
    }
    
    
    Pl45m4P 1 Reply Last reply
    0
    • MortyMarsM MortyMars

      Hi everyone,

      I have a compiler warning about the length of an array which cannot be a variable.
      My problem is that this length depends on the number of lines in a file, which I don't know in advance.
      I thought that reassigning this variable to a constant would solve the warning problem, but this isn't the case.

      Capture d’écran 2024-10-23 à 21.45.03.jpg

      Would you have a solution, other than using a vector, as this option - which I've already explored - doesn't suit me, and I'd like to keep using an array.

      Thanks in advance!

      The code for the methods concerned :

      /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
      // Création d'un Tableau 2D pour les 'Fixes' du fichier '_user_nav.dat'
      void ApprochWindow::createTableauFixes() {
      
          // Création -si elle n'existe pas déjà- de l'arborescence des fichiers utilisés et créés par Procedures4XP
          QDir().mkpath(QDir::homePath() + "/Documents/Procedures4XP/source files");
          QString fichier = QDir::homePath() + "/Documents/Procedures4XP/source files/_user_fix.dat";
          QFile file(fichier); // Appel du constructeur de la classe QFile
      
          if (!file.open(QIODevice::ReadOnly | QIODevice::Text))
          {
              QMessageBox::information(
                  this,
                  tr("Fichier '_user_fix.dat' non trouvé"),
                  QString(tr("Le fichier 'user_fix.dat' définissant les Waypoint personnalisés \n "
                             "n'a pas été trouvé ! \n"
                             " Certaines fonctionnalités ne seront donc pas actives.")),
                  QMessageBox::Ok );
      
              return; // sortie de la MÉTHODE
          }
          
          
          // Comptage des lignes du fichier
          // CODE 1
          QString ligne;
          int nbrLignes = 0;
          while (!file.atEnd()) {
              ligne = file.readLine();
              nbrLignes ++;
          }
          qDebug() << "Le fichier _user_fix.dat comporte " << nbrLignes << " lignes";
          
          const int NBLINES = nbrLignes;  // NBLINES ne sera pas considérée comme une constante :-(
          
          
          // CODE 2, inefficace également pour créer une constante
          //const int NBLINES = compterLignes(&file);
          
          // Définition du tableau qui recevra les données de 'user_fix.dat'
          QString tabFix[NBLINES][7];
      
          QTextStream Flux_lu(&file);
          QString Mot_lu = "";
      
          // Retour au début du fichier, après comptage du nombre de lignes
          file.seek(0);
      
          // Pour les 'NBLINES' lignes du formulaire, d'indice 0 à NBLINES-1 ...
          for (int l = 0; l < NBLINES ; l++) {
              // ... et les 7 colonnes d'indice 0 à 6
              for (int c = 0; c < 7 ; c++) {
      
                  // Un mot est lu à chaque boucle, et est placé en variable Mot_lu
                  Flux_lu >> Mot_lu;
      
                  // Remplissage du tableau 2D
                  tabFix[l][c].insert(0,Mot_lu);
      
                  // Sortie de la boucle en fin de fichier
                  if (Flux_lu.atEnd()) break;
              }
          }
          file.close();
      }
      
      
      /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
      // Comptage du nombre de ligne
      int ApprochWindow::compterLignes(QFile* fichier) {
      
          QString ligne;
          int nombreLignes = 0;
          while (!fichier->atEnd()) {
              ligne = fichier->readLine();
              nombreLignes ++;
          }
          qDebug() << " Via 'compterLignes()', le fichier '_user_fix.dat' comporte " << nombreLignes << " lignes";
      
          const int NBL = nombreLignes;
          return NBL;
      }
      
      
      Pl45m4P Offline
      Pl45m4P Offline
      Pl45m4
      wrote on last edited by Pl45m4
      #2

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

      I have a compiler warning about the length of an array which cannot be a variable.

      Yes, that's the issue or better "warning"... VLA's are not standard C++ language (anymore, or never were?!... anyway it's plain C style).

      My problem is that this length depends on the number of lines in a file, which I don't know in advance.

      Then keep it dynamic?!

      I thought that reassigning this variable to a constant would solve the warning problem, but this isn't the case.

      The code you show above doesn't change anything, because the same old variable - which is unknown at compile time - is assigned to your const int. Same problem.

      Better use QList<QString> or QVector<QString> and reserve the memory + resize your container

      this option - which I've already explored - doesn't suit me, and I'd like to keep using an array.

      For what reason a C array suits your use case more than the Qt container classes?!

      Edit:

      Just discovered that you are even using a 2D array...
      There are such things as structs, for example :))
      You could store one dimension in there and then use a 1-dim container with your struct.


      If debugging is the process of removing software bugs, then programming must be the process of putting them in.

      ~E. W. Dijkstra

      Christian EhrlicherC 1 Reply Last reply
      2
      • Pl45m4P Pl45m4

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

        I have a compiler warning about the length of an array which cannot be a variable.

        Yes, that's the issue or better "warning"... VLA's are not standard C++ language (anymore, or never were?!... anyway it's plain C style).

        My problem is that this length depends on the number of lines in a file, which I don't know in advance.

        Then keep it dynamic?!

        I thought that reassigning this variable to a constant would solve the warning problem, but this isn't the case.

        The code you show above doesn't change anything, because the same old variable - which is unknown at compile time - is assigned to your const int. Same problem.

        Better use QList<QString> or QVector<QString> and reserve the memory + resize your container

        this option - which I've already explored - doesn't suit me, and I'd like to keep using an array.

        For what reason a C array suits your use case more than the Qt container classes?!

        Edit:

        Just discovered that you are even using a 2D array...
        There are such things as structs, for example :))
        You could store one dimension in there and then use a 1-dim container with your struct.

        Christian EhrlicherC Offline
        Christian EhrlicherC Offline
        Christian Ehrlicher
        Lifetime Qt Champion
        wrote on last edited by Christian Ehrlicher
        #3

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

        anyway it's plain C style).

        no, vla's are not C - it's a clang/gcc extension.

        change const int NBLINES to constexpr int NBLINES so it's a normal array or even better - use a proper container (std::array).

        Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
        Visit the Qt Academy at https://academy.qt.io/catalog

        1 Reply Last reply
        4
        • MortyMarsM Offline
          MortyMarsM Offline
          MortyMars
          wrote on last edited by
          #4

          Thank you both @Pl45m4 and @Christian-Ehrlicher for your help ;-)

          There is therefore no mechanism for defining a CONST by giving it the value of a variable (at some point in its life) :-(

          Is there a way of telling the compiler to ignore this warning?

          Christian EhrlicherC I 2 Replies Last reply
          0
          • MortyMarsM MortyMars

            Thank you both @Pl45m4 and @Christian-Ehrlicher for your help ;-)

            There is therefore no mechanism for defining a CONST by giving it the value of a variable (at some point in its life) :-(

            Is there a way of telling the compiler to ignore this warning?

            Christian EhrlicherC Offline
            Christian EhrlicherC Offline
            Christian Ehrlicher
            Lifetime Qt Champion
            wrote on last edited by
            #5

            @MortyMars I wrote what you have to change.

            Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
            Visit the Qt Academy at https://academy.qt.io/catalog

            MortyMarsM 1 Reply Last reply
            2
            • MortyMarsM MortyMars

              Thank you both @Pl45m4 and @Christian-Ehrlicher for your help ;-)

              There is therefore no mechanism for defining a CONST by giving it the value of a variable (at some point in its life) :-(

              Is there a way of telling the compiler to ignore this warning?

              I Offline
              I Offline
              IgKh
              wrote on last edited by
              #6

              @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.

              JonBJ MortyMarsM 2 Replies Last reply
              2
              • I 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.

                JonBJ Online
                JonBJ Online
                JonB
                wrote on last edited by JonB
                #7

                @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?

                I 1 Reply Last reply
                1
                • JonBJ 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?

                  I Offline
                  I Offline
                  IgKh
                  wrote on last edited by IgKh
                  #8

                  @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.

                  JonBJ 1 Reply Last reply
                  2
                  • I 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.

                    JonBJ Online
                    JonBJ Online
                    JonB
                    wrote on last edited by JonB
                    #9

                    @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.

                    MortyMarsM 1 Reply Last reply
                    1
                    • Christian EhrlicherC Christian Ehrlicher

                      @MortyMars I wrote what you have to change.

                      MortyMarsM Offline
                      MortyMarsM Offline
                      MortyMars
                      wrote on last edited by
                      #10

                      @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.

                      Capture d’écran 2024-10-24 à 15.44.24.jpg

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

                      JonBJ 1 Reply Last reply
                      0
                      • MortyMarsM 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.

                        Capture d’écran 2024-10-24 à 15.44.24.jpg

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

                        JonBJ Online
                        JonBJ Online
                        JonB
                        wrote on last edited by
                        #11

                        @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.

                        1 Reply Last reply
                        2
                        • I 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.

                          MortyMarsM Offline
                          MortyMarsM Offline
                          MortyMars
                          wrote on last edited by
                          #12

                          @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...

                          JonBJ I 2 Replies Last reply
                          0
                          • JonBJ 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.

                            MortyMarsM Offline
                            MortyMarsM Offline
                            MortyMars
                            wrote on last edited by
                            #13

                            @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... :-(

                            1 Reply Last reply
                            0
                            • MortyMarsM 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...

                              JonBJ Online
                              JonBJ Online
                              JonB
                              wrote on last edited by JonB
                              #14

                              @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.

                              MortyMarsM 1 Reply Last reply
                              3
                              • MortyMarsM 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...

                                I Offline
                                I Offline
                                IgKh
                                wrote on last edited by
                                #15

                                @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.

                                MortyMarsM 1 Reply Last reply
                                1
                                • JonBJ 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.

                                  MortyMarsM Offline
                                  MortyMarsM Offline
                                  MortyMars
                                  wrote on last edited by
                                  #16

                                  @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.

                                  1 Reply Last reply
                                  0
                                  • I 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.

                                    MortyMarsM Offline
                                    MortyMarsM Offline
                                    MortyMars
                                    wrote on last edited by
                                    #17

                                    @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).

                                    1 Reply Last reply
                                    1
                                    • MortyMarsM MortyMars has marked this topic as solved on

                                    • Login

                                    • Login or register to search.
                                    • First post
                                      Last post
                                    0
                                    • Categories
                                    • Recent
                                    • Tags
                                    • Popular
                                    • Users
                                    • Groups
                                    • Search
                                    • Get Qt Extensions
                                    • Unsolved