Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Special Interest Groups
  3. C++ Gurus
  4. QList need to know all modifications
Forum Updated to NodeBB v4.3 + New Features

QList need to know all modifications

Scheduled Pinned Locked Moved Unsolved C++ Gurus
18 Posts 6 Posters 1.6k Views 4 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.
  • J Offline
    J Offline
    JonB
    wrote on 30 Oct 2024, 10:04 last edited by
    #9

    Thank you all for your various posts.

    September was a long time ago now so I have moved on from this (without resolution, but that's OK now) :)

    I do realise that in practice encapsulation is probably the best approach. It's just that I didn't want to do that, I wanted existing variables which are QList to remain as QList rather than having to call a method to access the list and/or having to write loads of methods on the encapsulator to access the QList member's methods. But, not surprisingly, nothing quite

    It sounds like C++ 2129 might have features I need ;-)

    Just musing here. C++ inheritance and virtual methods are great. But I am always disappointed at how many methods are not virtual when I wish they were. Here, for example, if all the base modification QList (and other classes') methods like append() etc. were protected virtual I could do what I want easily. I guess implementation-wise there IS some overhead in the code generated for a virtual method over a fixed one? Or not?

    In my last days of using C# they introduced extension methods, whereby you can add your own new methods to existing base classes to extend them with extra functionality. If I use Python, or JavaScript, I can do that naughty "monkey patching" where I can effectively go QList.append = myNewImplementation, changing the actual method used for QList.append() to my own code which does whatever and calls the original base implementation. Naughty/dangerous but nice! But not from C++.

    S 1 Reply Last reply 31 Oct 2024, 07:51
    0
    • J Offline
      J Offline
      J.Hilk
      Moderators
      wrote on 30 Oct 2024, 12:19 last edited by
      #10

      Ok, I'm late to the party, buuuuut :D

      You know, QList a very small class, as it is a template class, in fact I think you'll only need to hook into the the cpp file and the even viewer function implementations of QListData (the infamous d-pointer) as that is the actual part that is modifying the data.

      once you decide to switch to release, you just link against/ship the original QList impl


      Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


      Q: What's that?
      A: It's blue light.
      Q: What does it do?
      A: It turns blue.

      1 Reply Last reply
      0
      • J JonB
        19 Sept 2024, 09:03

        Hmm :) I have a class for a QList of (pointers to) elements of a particular class of mine, like

        class MyClassList: public QList<const MyClass *>
        

        (I don't think the const in the pointer is important, would be same if it were QList<MyClass *>.)

        For internal reasons/debugging/my requirements I need that list-class to know whenever the list is modified (insert(), remove(), clear(), list[i] = ... etc.) --- I will be doing a bit of extra internal work (after calling base QList method to modify) on every alteration. On the other hand, I do not need to know about any read accesses, I want all of them to be passed straight through to underlying QList implementation.

        As we know, QList does not provide any signals and does not supply any virtual methods to override. How best to go about this? I am open to any suggestions. It would be nice if it were fairly generic, but (especially for simplicity) I would consider an approach where I must only call a certain set of methods in the subclass to do modifications even if that is not all the ways the list can be altered.

        My initial thoughts:

        Approach #1:

        • Derive from public QList (as shown above). Define new methods with same name/parameters as the modification methods, and have them call the base QList implementation
        void MyClassList::append(const MyClass *t)
        {
            QList::append(t);
            myExtraCode();
        }
        

        To be "complete" and "safe" I would need to define a new method for every existing modifying method.

        Approach #2:

        • Derive from private QList (or maybe protected). Same code as above for new definitions of modifying methods. But now I don't have to worry about redefining every write-method as only the ones I have defined are publicly available.

        • In this case I would want all read-methods to be publicly available somehow. (I regard redefining every read method as too onerous.) Is there perhaps a C++ way of having a const method of MyClassList which returns something like a const &QList<const MyClass *> , something like

        const QList<const MyClass *t> &MyClassList::list() const
        {
            return *this;
        }
        

        This (I hope) gives access to the QList as a const reference so I should be able to call all const/read methods on the QList. In this case I would not want to have to write e.g. myListLinstance.list().at(i) where I used to write just myListLinstance.at(i), so would there then be a way of telling C++ that every time I write myListInstance.someMethod() where someMethod() is const it should "auto-convert" to the list() const method whenever I try to call a method on MyClassList which does not have an explicit, public declaration for the method (which my modification methods but not my read methods would have)?

        Or any other way!? But please note I am not prepared to write reams of code for this, e.g. QList has 50+ methods, I am not going to write a new definition for all of these....

        J Offline
        J Offline
        jeremy_k
        wrote on 30 Oct 2024, 19:05 last edited by jeremy_k
        #11

        @JonB said in QList need to know all modifications:

        Or any other way!? But please note I am not prepared to write reams of code for this, e.g. QList has 50+ methods, I am not going to write a new definition for all of these....

        Have you considered using with private inheritance instead new definitions?

        ie

        template<typename T> class List: private QList<T> {
        public:
            using QList<T>::append; // pass-thru
            T operator[](qsizetype index) {
                qDebug() << "calling []";
                return QList<T>::operator[](index);
            }
        };
        

        Asking a question about code? http://eel.is/iso-c++/testcase/

        1 Reply Last reply
        0
        • J JonB
          30 Oct 2024, 10:04

          Thank you all for your various posts.

          September was a long time ago now so I have moved on from this (without resolution, but that's OK now) :)

          I do realise that in practice encapsulation is probably the best approach. It's just that I didn't want to do that, I wanted existing variables which are QList to remain as QList rather than having to call a method to access the list and/or having to write loads of methods on the encapsulator to access the QList member's methods. But, not surprisingly, nothing quite

          It sounds like C++ 2129 might have features I need ;-)

          Just musing here. C++ inheritance and virtual methods are great. But I am always disappointed at how many methods are not virtual when I wish they were. Here, for example, if all the base modification QList (and other classes') methods like append() etc. were protected virtual I could do what I want easily. I guess implementation-wise there IS some overhead in the code generated for a virtual method over a fixed one? Or not?

          In my last days of using C# they introduced extension methods, whereby you can add your own new methods to existing base classes to extend them with extra functionality. If I use Python, or JavaScript, I can do that naughty "monkey patching" where I can effectively go QList.append = myNewImplementation, changing the actual method used for QList.append() to my own code which does whatever and calls the original base implementation. Naughty/dangerous but nice! But not from C++.

          S Offline
          S Offline
          SimonSchroeder
          wrote on 31 Oct 2024, 07:51 last edited by
          #12

          @JonB said in QList need to know all modifications:

          I guess implementation-wise there IS some overhead in the code generated for a virtual method over a fixed one? Or not?

          Well, most of the time those functions in QList will be inlined. This opens up the possibility for a lot more optimizations. I would claim that good performance is important for something like QList. With the use of virtual methods in many cases the compiler cannot devirtualize the methodes. Sure, if you declare the variable and call functions within the same scope, nothing is lost. I would guess, however, that it is very common to hand a QList as a parameter to a function as a reference. This called function would have to keep the virtual function call and thus slow down the common case.

          @JonB said in QList need to know all modifications:

          If I use Python, or JavaScript, I can do that naughty "monkey patching"

          Sounds if you would be a little happier with Objective-C (or Objective-C++) instead of C++. Method calls are just strings with a really fast lookup of the correct function. This makes it easy to override a method (you can even replace class implementations system-wide at runtime). I don't know if this is used for containers, though. In the end, it is still a lot like virtual functions and thus has the same drawbacks.

          J 1 Reply Last reply 31 Oct 2024, 08:26
          0
          • S SimonSchroeder
            31 Oct 2024, 07:51

            @JonB said in QList need to know all modifications:

            I guess implementation-wise there IS some overhead in the code generated for a virtual method over a fixed one? Or not?

            Well, most of the time those functions in QList will be inlined. This opens up the possibility for a lot more optimizations. I would claim that good performance is important for something like QList. With the use of virtual methods in many cases the compiler cannot devirtualize the methodes. Sure, if you declare the variable and call functions within the same scope, nothing is lost. I would guess, however, that it is very common to hand a QList as a parameter to a function as a reference. This called function would have to keep the virtual function call and thus slow down the common case.

            @JonB said in QList need to know all modifications:

            If I use Python, or JavaScript, I can do that naughty "monkey patching"

            Sounds if you would be a little happier with Objective-C (or Objective-C++) instead of C++. Method calls are just strings with a really fast lookup of the correct function. This makes it easy to override a method (you can even replace class implementations system-wide at runtime). I don't know if this is used for containers, though. In the end, it is still a lot like virtual functions and thus has the same drawbacks.

            J Offline
            J Offline
            JonB
            wrote on 31 Oct 2024, 08:26 last edited by
            #13

            @SimonSchroeder said in QList need to know all modifications:

            Method calls are just strings with a really fast lookup of the correct function.

            Now hang on! Is that really true? That sounds more like an interpreter. I don't care how fast you claim a lookup might be, this must be orders of magnitude slower than compiling the address of the actual function --- and as I understand it C++ figures the actual correct one to call at compile time, following the inheritance chain at that time not at runtime. So not even one level of indirection. Unless that maybe applies to non-virtual methods only, but I thought it resolves virtual ones too.

            J 1 Reply Last reply 31 Oct 2024, 10:50
            0
            • J JonB
              31 Oct 2024, 08:26

              @SimonSchroeder said in QList need to know all modifications:

              Method calls are just strings with a really fast lookup of the correct function.

              Now hang on! Is that really true? That sounds more like an interpreter. I don't care how fast you claim a lookup might be, this must be orders of magnitude slower than compiling the address of the actual function --- and as I understand it C++ figures the actual correct one to call at compile time, following the inheritance chain at that time not at runtime. So not even one level of indirection. Unless that maybe applies to non-virtual methods only, but I thought it resolves virtual ones too.

              J Offline
              J Offline
              jsulm
              Lifetime Qt Champion
              wrote on 31 Oct 2024, 10:50 last edited by
              #14

              @JonB said in QList need to know all modifications:

              So not even one level of indirection

              There is for virtual methods. See vtable https://pabloariasal.github.io/2017/06/10/understanding-virtual-tables/
              But it is not based on strings :-)

              https://forum.qt.io/topic/113070/qt-code-of-conduct

              J 1 Reply Last reply 31 Oct 2024, 11:54
              0
              • J jsulm
                31 Oct 2024, 10:50

                @JonB said in QList need to know all modifications:

                So not even one level of indirection

                There is for virtual methods. See vtable https://pabloariasal.github.io/2017/06/10/understanding-virtual-tables/
                But it is not based on strings :-)

                J Offline
                J Offline
                JonB
                wrote on 31 Oct 2024, 11:54 last edited by
                #15

                @jsulm
                Yes, that's why I suspected indirection would be required in virtual case.

                However, for a summary that article still did not make clear (to me) whether this is always a single level of indirection or as many multiple indirections as the inherited class hierarchy have their own overrides of a virtual method? I know what happens when class B overrides class A's virtual method and you write instanceAsA->virtualMethod() --- one indirection.

                But what when you have 10 levels of inheritance, A -> B -> C -> D -> ..., each of which override the virtual method.? Does the runtime implementation of instanceAsA->virtualMethod() require 10 vtable/vpointer indirections, via each intermediate class, or does it go straight from A->virtualMethod() to J->virtualMethod()? That is a huge difference in practice when one has a deep class hierarchy?

                J 1 Reply Last reply 31 Oct 2024, 13:55
                0
                • J JonB
                  31 Oct 2024, 11:54

                  @jsulm
                  Yes, that's why I suspected indirection would be required in virtual case.

                  However, for a summary that article still did not make clear (to me) whether this is always a single level of indirection or as many multiple indirections as the inherited class hierarchy have their own overrides of a virtual method? I know what happens when class B overrides class A's virtual method and you write instanceAsA->virtualMethod() --- one indirection.

                  But what when you have 10 levels of inheritance, A -> B -> C -> D -> ..., each of which override the virtual method.? Does the runtime implementation of instanceAsA->virtualMethod() require 10 vtable/vpointer indirections, via each intermediate class, or does it go straight from A->virtualMethod() to J->virtualMethod()? That is a huge difference in practice when one has a deep class hierarchy?

                  J Offline
                  J Offline
                  jsulm
                  Lifetime Qt Champion
                  wrote on 31 Oct 2024, 13:55 last edited by
                  #16

                  @JonB This is a good question. I'm not sure. But there is a way in gdb to inspect the vtable:

                  info vtbl b
                  

                  b being an object. This way you could check the pointers in all the vtables and see how those were set up. If I find time I will also do this.
                  But it looks like the compiler puts the pointer to the "most derived function" in the vtable, so there is always one indirection. Search for "most derived function" in this thread: https://www.learncpp.com/cpp-tutorial/the-virtual-table/

                  https://forum.qt.io/topic/113070/qt-code-of-conduct

                  J 1 Reply Last reply 31 Oct 2024, 14:01
                  0
                  • J jsulm
                    31 Oct 2024, 13:55

                    @JonB This is a good question. I'm not sure. But there is a way in gdb to inspect the vtable:

                    info vtbl b
                    

                    b being an object. This way you could check the pointers in all the vtables and see how those were set up. If I find time I will also do this.
                    But it looks like the compiler puts the pointer to the "most derived function" in the vtable, so there is always one indirection. Search for "most derived function" in this thread: https://www.learncpp.com/cpp-tutorial/the-virtual-table/

                    J Offline
                    J Offline
                    JonB
                    wrote on 31 Oct 2024, 14:01 last edited by
                    #17

                    @jsulm said in QList need to know all modifications:

                    the compiler puts the pointer to the "most derived function" in the vtable, so there is always one indirection.

                    That is what I thought, but did not know. There is a hell of a difference between a single indirection in machine code and a potentially iterative number of indirections for a deeply-nested inheritance...!

                    1 Reply Last reply
                    0
                    • S Offline
                      S Offline
                      SimonSchroeder
                      wrote on 4 Nov 2024, 10:00 last edited by
                      #18

                      Each class has its own vtable (it is not per object). Each object then has a pointer to the vtable. When you have a pointer to a base class pointing to an object of a derived class, it just uses the pointer to the vtable and calls the appropriate function. Like mentioned before, this is only one indirection. (It gets more complicated with multiple inheritance.)

                      Concerning Objective-C: Most strings for message are compile-time known strings. This means that "string comparison" in reality is most of the time just comparison of pointers. The runtime also uses a little cache to speed up the most recent function calls.

                      BTW: Since we are always talking about performance here. There is a CppCon talk on Youtube "Optimizing Away C++ Virtual Functions May be Pointless" https://youtu.be/i5MAXAxp_Tw?si=ieyiW3G31UMmANV-

                      1 Reply Last reply
                      0

                      18/18

                      4 Nov 2024, 10:00

                      • Login

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