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. QPointer compilation error...
Forum Updated to NodeBB v4.3 + New Features

QPointer compilation error...

Scheduled Pinned Locked Moved General and Desktop
5 Posts 2 Posters 2.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.
  • R Offline
    R Offline
    rickbkis
    wrote on last edited by
    #1

    If I declare a QPointer in a header, like so:
    @
    private:
    QPointer<QWidgetDerived> tp;
    @
    and then in the constructor, I create an instance and try to assign it, like thus:
    @
    SomeOtherClass::function()
    {
    tp = new QWidgetDerived();
    }
    @
    I get the following compilation error:
    @
    passing 'const QPointer<QWidgetDerived>' as 'this' argument of
    'QPointer<T>& QPointer<T>::operator==(T*)
    [with T = QWidgetDerived]' discards qualifiers
    @
    Interestingly enough, if I create a local pointer and assign it, like so:
    @
    SomeOtherClass::function()
    {
    QPointer<QWidgetDerived> op = new QWidgetDerived();
    }
    @
    it works fine, but if I then try to assign that to the member, like so:
    @
    SomeOtherClass::function()
    {
    QPointer<QWidgetDerived> op = new QWidgetDerived();
    tp = op;
    }
    @
    I get the same error.

    If I try:
    @
    SomeOtherClass::function()
    {
    QWidgetDerived *op = new QWidgetDerived();
    tp = op;
    }
    @
    I still get the same error.

    Can someone tell me what's going on? The docs indicate that QPointer is virtually interchangeable with c++ pointers, but I keep running into this compilation issue when I declare a QPointer in a header, and it's driving me crazy. I'm not declaring anything with 'const' qualifiers, but the compiler seems to think a 'const' is specified or implied somewhere....

    This is on Mac with the gnu compiler, BTW.

    Any thoughts appreciated,
    rickb

    1 Reply Last reply
    0
    • G Offline
      G Offline
      goetz
      wrote on last edited by
      #2

      On the first sight, it seems ok. A short test with some of my classes works (also on a Mac). Can you please create a small yet complete test case (including all relevant source files) that demonstrates the error.

      http://www.catb.org/~esr/faqs/smart-questions.html

      1 Reply Last reply
      0
      • R Offline
        R Offline
        rickbkis
        wrote on last edited by
        #3

        Unh.... I think I see the problem...

        The calling routine is declared like this:

        @
        WidgetDerived *OtherClass::gimmeAWidget(const QWidget *parent) const
        {
        }
        @

        The trailing 'const' spec in the call is what's messing me up, I think... I don't have any control over that...

        Boogers.

        [EDIT: code formatting, Volker]

        1 Reply Last reply
        0
        • G Offline
          G Offline
          goetz
          wrote on last edited by
          #4

          Yes, that's the show stopper here. You can do some dirty hack to cast a away the constness:

          @
          WidgetDerived *OtherClass::gimmeAWidget(const QWidget *parent) const
          {
          OtherClass *that = const_cast<OtherClass *>(this);
          that->tp = new QWidgetDerived();
          return tp;
          }
          @

          Another option would be to declare the pointer mutable:

          @
          private:
          mutable QPointer<QWidgetDerived> tp;
          @

          http://www.catb.org/~esr/faqs/smart-questions.html

          1 Reply Last reply
          0
          • R Offline
            R Offline
            rickbkis
            wrote on last edited by
            #5

            Both interesting workarounds. The 'const' construct in all its flavors drives me crazy...

            Grumble.

            Anyway, the way I got around it was to define a couple of more signals and slots and connect them up to the created object, rather than rely on keeping a pointer around. That satisfies the issue of not accessing something if it's deleted (which was the intent of using QPointer in the first place), and 'connect' does not appear to violate the 'const' qualification.

            Thanks for the pointers (ar, ar). Keep them in mind for future necessities.

            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