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. A vector of class objects
Forum Updated to NodeBB v4.3 + New Features

A vector of class objects

Scheduled Pinned Locked Moved General and Desktop
16 Posts 6 Posters 9.8k 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.
  • G Offline
    G Offline
    GordonSchumacher
    wrote on last edited by
    #6

    As a curiosity, have you looked into using Boost::Graph? It might be too heavyweight for what you need, but it's an already-written and very, very complete graph structure implementation.

    1 Reply Last reply
    0
    • C Offline
      C Offline
      cazador7907
      wrote on last edited by
      #7

      I'm actually trying to work through the basics of things like graphs, binary search trees etc on my own. I figure that once I know how they work, I'll better understand the inner workings of things like Boost.

      I do have one other question. When I create the actual graph object, I do not create it in the heap. Should it be created there or is the stack fine?

      Laurence -

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

        If you store pointers in your list you must create it on the heap (using new). If you create the object on the stack (using "GraphNode xy;" in your code, without "new"), it will be destroyed once you leave the block where the object was instantiated. Your list then contains a pointer that isn't valid anymore (aka "dangling pointer"). Your program will crash if you access them later.

        If your objects do have an assignment operator and/or a copy constructor you can create them on the stack too, as they will be copied once you put them into the list. If you have a "heavy" amount of data, you could consider using a reference counter and copy-on-write (like the Trolls do with QString, for example). If your graph node contains only what you've provided in your original post, this would not be necessary.

        See the API docs on "Container Classes":http://doc.qt.nokia.com/4.7/containers.html in general, and on "QList":http://doc.qt.nokia.com/4.7/qlist.html for some details.

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

        1 Reply Last reply
        0
        • G Offline
          G Offline
          GordonSchumacher
          wrote on last edited by
          #9

          [quote author="Volker" date="1291851383"]If your objects do have an assignment operator and/or a copy constructor you can create them on the stack too, as they will be copied once you put them into the list. If you have a "heavy" amount of data, you could consider using a reference counter and copy-on-write (like the Trolls do with QString, for example). If your graph node contains only what you've provided in your original post, this would not be necessary.[/quote]

          Bear in mind that QObjects cannot be copied, so they must be created on the heap. Also, if you do the copy-on-write thing, look at QSharedData; it will make your job a lot easier.

          1 Reply Last reply
          0
          • W Offline
            W Offline
            w00t
            wrote on last edited by
            #10

            [quote author="GordonSchumacher" date="1291917913"]Bear in mind that QObjects cannot be copied, so they must be created on the heap. Also, if you do the copy-on-write thing, look at QSharedData; it will make your job a lot easier.[/quote]

            While I understand what you're saying, I'd like to make a slight correction for anyone else who stumbles across this and is confused by it.

            While you can't copy a QObject, at the same time, you don't need to copy anything to use stack allocation:

            @QDialog d;
            d.exec();@

            is a perfectly valid way of doing things.

            What wouldn't be valid would be something like:
            @QDialog d;
            QDialog other_d;
            other_d = d;@

            because (as you correctly point out) all classes inheriting QObject have an inaccessible copy constructor.

            --
            http://rburchell.com

            1 Reply Last reply
            0
            • G Offline
              G Offline
              GordonSchumacher
              wrote on last edited by
              #11

              Sorry, I was not clear; what I meant was that in order to put them in a container (QVector et al) they must be created on the heap - in other words, this will not work:

              @QList<QDialog> dlgList;
              dlgList << QDialog();@

              I believe that even the QList definition will fail, but the second line most certainly will because it will create a QDialog on the stack, then try to copy it into dlgList.

              The C++ "move constructor":http://www.artima.com/cppsource/rvalue.html will presumably make this workable, however...

              1 Reply Last reply
              0
              • F Offline
                F Offline
                Franzk
                wrote on last edited by
                #12

                [quote author="Robin Burchell" date="1292024166"]@QDialog d;
                d.exec();@

                is a perfectly valid way of doing things.[/quote]Ah yes, but that could produce "unpredictable behavior":http://labs.qt.nokia.com/2010/02/23/unpredictable-exec/. Given that information, I'm all for creating the widgets on the heap in literally all circumstances. Objects not necessarily.

                "Horse sense is the thing a horse has which keeps it from betting on people." -- W.C. Fields

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

                1 Reply Last reply
                0
                • B Offline
                  B Offline
                  baysmith
                  wrote on last edited by
                  #13

                  That link is an article about the unpredictable behavior from having multiple event loops (from the d.exec()), not that widget must be on the heap. What they recommend does require the widget to be on the heap but only as a side-effect of avoiding the exec() call.

                  Nokia Certified Qt Specialist.

                  1 Reply Last reply
                  0
                  • F Offline
                    F Offline
                    Franzk
                    wrote on last edited by
                    #14

                    True. The only way to properly avoid the exec() call is to create the widget on the heap and call open() or show(), which was what I implicitly meant.

                    "Horse sense is the thing a horse has which keeps it from betting on people." -- W.C. Fields

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

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

                      That would be subject to a new thread, I'd suggest... nothing really related to a QVector, I suspect.

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

                      1 Reply Last reply
                      0
                      • B Offline
                        B Offline
                        baysmith
                        wrote on last edited by
                        #16

                        It is still related to memory management of Qt classes, which is the real topic of this thread.

                        Nokia Certified Qt Specialist.

                        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