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. QLabel on heap vs QLabel on stack
Forum Updated to NodeBB v4.3 + New Features

QLabel on heap vs QLabel on stack

Scheduled Pinned Locked Moved General and Desktop
6 Posts 4 Posters 3.6k Views 1 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.
  • B Offline
    B Offline
    Boxx
    wrote on last edited by
    #1

    Hello,
    Why does the complier allow this:
    @QLabel *label = new QLabel("Hello World");@

    and not this:
    @QLabel label = QLabel("Hello World");@

    I get the error:
    @C:\Users\Blah\Blah - Basic Application and HTML Aware Widgets\Minimal\Main.cpp:10: error: C2248: 'QLabel::QLabel' : cannot access private member declared in class 'QLabel'@

    I know this might be more of a C++ question than a Qt question but I'm just wondering.
    Thanks

    1 Reply Last reply
    0
    • F Offline
      F Offline
      Fabien_fr
      wrote on last edited by
      #2

      Well as you say, this is raw C++.

      The proper syntax for building objects on the stack would be
      QLabel label("Hello World");

      I suspect that there could be a syntactic ambiguity with a function call pattern...
      And I agree that the error message (VS, it seems) is really useless.

      Cheers,

      1 Reply Last reply
      0
      • Chris KawaC Offline
        Chris KawaC Offline
        Chris Kawa
        Lifetime Qt Champion
        wrote on last edited by
        #3

        No, it is not useless. You just need to understand what is going on and then you'll see it tells you exactly what is wrong.

        The second syntax creates a temporary, unnamed QLabel instance and then tries to construct the "label" variable through its copy constructor ( QLabel::QLabel(const Qlabel&) ).

        Now, most widgets, including QLabel use Q_DISABLE_COPY() macro, which declares a private copy constructor and assignment operator. This is to disable copying widgets by value, which makes little sense when you think about layouts.

        So, to conclude - the compiler is saying exactly what is going on - you are trying to use a private member (the private copy constructor QLabel::QLabel) of the class QLabel. Don't do that.

        1 Reply Last reply
        0
        • U Offline
          U Offline
          utcenter
          wrote on last edited by
          #4

          It nos not just widgets, QObject and derived classes must not be copied, that is why the copy constructor and assignment operator for library classes are declared as private for C++98 compilers. In C++11 a more elegant approach is being used, instead of making the method private, it is marked as = delete.

          On a side note, you can declare class members as stack values and use the initializer list if you for some reason want to avoid dynamic memory allocating, which is the preferred way in Qt. Instead of using pointers and calling new in the constructor you can put UI sub-elements on the stack and save a tiny amount of resources. But since the API is written to accept pointers (precisely because QOBject derived do not have copy constructors and assignment operators), you must make extensive use of the & operator to get addresses instead of the instance.

          1 Reply Last reply
          0
          • B Offline
            B Offline
            Boxx
            wrote on last edited by
            #5

            Hello,
            Total brain fart I saw that:
            @QLabel ( const QString & text, QWidget * parent = 0, Qt::WindowFlags f = 0 )@

            and couldn't find a copy constructor on the QLabel Class Reference and assumed it was implicitly called. Thanks I'm just so used to never using dynamic memory where I have to remember to explicitly delete each instead of using a destructor, which I guess Qt does for you anyways.

            1 Reply Last reply
            0
            • U Offline
              U Offline
              utcenter
              wrote on last edited by
              #6

              QObject derived classes (should always) have their constructors declared explicit, precisely to avoid the otherwise numerous possible implicit conversions and potential problems.

              I myself think C++ is way too implicit and rarely rely on implicit conversions, just to make sure it is clear to anyone (including me) what actually happens.

              1 Reply Last reply
              0

              • Login

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