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.2k 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.
  • M Offline
    M Offline
    MortyMars
    wrote on 23 Oct 2024, 22:43 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;
    }
    
    
    P 1 Reply Last reply 24 Oct 2024, 02:26
    0
    • M MortyMars
      23 Oct 2024, 22:43

      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;
      }
      
      
      P Offline
      P Offline
      Pl45m4
      wrote on 24 Oct 2024, 02:26 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 24 Oct 2024, 04:12
      2
      • P Pl45m4
        24 Oct 2024, 02:26

        @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 24 Oct 2024, 04:12 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
        • M Offline
          M Offline
          MortyMars
          wrote on 24 Oct 2024, 09:05 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 24 Oct 2024, 09:08
          0
          • M MortyMars
            24 Oct 2024, 09:05

            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 24 Oct 2024, 09:08 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

            M 1 Reply Last reply 24 Oct 2024, 13:49
            2
            • M MortyMars
              24 Oct 2024, 09:05

              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 24 Oct 2024, 13:04 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 M 2 Replies Last reply 24 Oct 2024, 13:09
              2
              • I IgKh
                24 Oct 2024, 13:04

                @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 Offline
                JonBJ Offline
                JonB
                wrote on 24 Oct 2024, 13:09 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 24 Oct 2024, 13:21
                1
                • JonBJ JonB
                  24 Oct 2024, 13:09

                  @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 24 Oct 2024, 13:21 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 24 Oct 2024, 13:29
                  2
                  • I IgKh
                    24 Oct 2024, 13:21

                    @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 Offline
                    JonBJ Offline
                    JonB
                    wrote on 24 Oct 2024, 13:29 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.

                    M 1 Reply Last reply 24 Oct 2024, 14:13
                    1
                    • Christian EhrlicherC Christian Ehrlicher
                      24 Oct 2024, 09:08

                      @MortyMars I wrote what you have to change.

                      M Offline
                      M Offline
                      MortyMars
                      wrote on 24 Oct 2024, 13:49 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 24 Oct 2024, 13:59
                      0
                      • M MortyMars
                        24 Oct 2024, 13:49

                        @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 Offline
                        JonBJ Offline
                        JonB
                        wrote on 24 Oct 2024, 13:59 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
                          24 Oct 2024, 13:04

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

                          M Offline
                          M Offline
                          MortyMars
                          wrote on 24 Oct 2024, 14:04 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 24 Oct 2024, 14:13
                          0
                          • JonBJ JonB
                            24 Oct 2024, 13:29

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

                            M Offline
                            M Offline
                            MortyMars
                            wrote on 24 Oct 2024, 14:13 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
                            • M MortyMars
                              24 Oct 2024, 14:04

                              @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 Offline
                              JonBJ Offline
                              JonB
                              wrote on 24 Oct 2024, 14:13 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.

                              M 1 Reply Last reply 24 Oct 2024, 14:19
                              3
                              • M MortyMars
                                24 Oct 2024, 14:04

                                @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 24 Oct 2024, 14:17 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.

                                M 1 Reply Last reply 24 Oct 2024, 14:32
                                1
                                • JonBJ JonB
                                  24 Oct 2024, 14:13

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

                                  M Offline
                                  M Offline
                                  MortyMars
                                  wrote on 24 Oct 2024, 14:19 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
                                    24 Oct 2024, 14:17

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

                                    M Offline
                                    M Offline
                                    MortyMars
                                    wrote on 24 Oct 2024, 14:32 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
                                    • M MortyMars has marked this topic as solved on 24 Oct 2024, 14:36

                                    1/17

                                    23 Oct 2024, 22:43

                                    • Login

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