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. Checking the API status for the variable “Private d” of the QVariant class
Forum Updated to NodeBB v4.3 + New Features

Checking the API status for the variable “Private d” of the QVariant class

Scheduled Pinned Locked Moved Unsolved General and Desktop
apiqvariantprivatedocumentationevolution
31 Posts 5 Posters 9.5k Views 2 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.
  • Christian EhrlicherC Offline
    Christian EhrlicherC Offline
    Christian Ehrlicher
    Lifetime Qt Champion
    wrote on last edited by
    #3

    d does not belong to the public interface so you don't have to worry

    Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
    Visit the Qt Academy at https://academy.qt.io/catalog

    sierdzioS 1 Reply Last reply
    3
    • Christian EhrlicherC Christian Ehrlicher

      d does not belong to the public interface so you don't have to worry

      sierdzioS Offline
      sierdzioS Offline
      sierdzio
      Moderators
      wrote on last edited by
      #4

      @Christian-Ehrlicher said in Checking the API status for the variable “Private d” of the QVariant class:

      d does not belong to the public interface so you don't have to worry

      Guys but take a look at the code - this is not the d pointer, it's and instance of Private struct, called d. Looks like it is indeed part of the public interface here.

      (Z(:^

      E 1 Reply Last reply
      1
      • sierdzioS sierdzio

        @Christian-Ehrlicher said in Checking the API status for the variable “Private d” of the QVariant class:

        d does not belong to the public interface so you don't have to worry

        Guys but take a look at the code - this is not the d pointer, it's and instance of Private struct, called d. Looks like it is indeed part of the public interface here.

        E Offline
        E Offline
        elfring
        wrote on last edited by
        #5

        Looks like it is indeed part of the public interface here.

        Conditional compilation can eventually make this variable “protected”, can't it?

        sierdzioS 1 Reply Last reply
        0
        • E elfring

          Looks like it is indeed part of the public interface here.

          Conditional compilation can eventually make this variable “protected”, can't it?

          sierdzioS Offline
          sierdzioS Offline
          sierdzio
          Moderators
          wrote on last edited by
          #6

          @elfring said in Checking the API status for the variable “Private d” of the QVariant class:

          Looks like it is indeed part of the public interface here.

          Conditional compilation can eventually make this variable “protected”, can't it?

          Yes, but since it's not a pointer, it can affect memory layout => damage binary compatibility. Even if it is private. Some more info: https://stackoverflow.com/questions/7699259/how-does-adding-a-private-member-variable-break-c-abi-compatibility

          (Z(:^

          1 Reply Last reply
          1
          • VRoninV Offline
            VRoninV Offline
            VRonin
            wrote on last edited by
            #7

            Q_NO_TEMPLATE_FRIENDS is only defined in old or unusual compilers, if you trust the comment (i.e. the Q_CC_MSVC only exist for binary compatibility but it should be removed) I'd say the base case is for d to be protected

            "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
            ~Napoleon Bonaparte

            On a crusade to banish setIndexWidget() from the holy land of Qt

            E 1 Reply Last reply
            3
            • Christian EhrlicherC Offline
              Christian EhrlicherC Offline
              Christian Ehrlicher
              Lifetime Qt Champion
              wrote on last edited by
              #8

              And you can be sure this will not change inbetween a Qt X release cycle. It's a 32+64 bit struct which was adjusted to match the requirements. Noone will ever touch this in a form that the size will change.

              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
              1
              • VRoninV VRonin

                Q_NO_TEMPLATE_FRIENDS is only defined in old or unusual compilers, if you trust the comment (i.e. the Q_CC_MSVC only exist for binary compatibility but it should be removed) I'd say the base case is for d to be protected

                E Offline
                E Offline
                elfring
                wrote on last edited by
                #9

                I'd say the base case is for d to be protected

                Would you like to encapsulate accesses for the member variable “d” (of the class “QVariant”) by any other function?

                VRoninV 1 Reply Last reply
                0
                • Christian EhrlicherC Offline
                  Christian EhrlicherC Offline
                  Christian Ehrlicher
                  Lifetime Qt Champion
                  wrote on last edited by
                  #10

                  d is protected so no other function will get access to this variable and there is also no need for it. What do you want to achieve?

                  Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
                  Visit the Qt Academy at https://academy.qt.io/catalog

                  E 1 Reply Last reply
                  1
                  • E elfring

                    I'd say the base case is for d to be protected

                    Would you like to encapsulate accesses for the member variable “d” (of the class “QVariant”) by any other function?

                    VRoninV Offline
                    VRoninV Offline
                    VRonin
                    wrote on last edited by VRonin
                    #11

                    @elfring said in Checking the API status for the variable “Private d” of the QVariant class:

                    Would you like to encapsulate accesses for the member variable “d” (of the class “QVariant”) by any other function?

                    it is already [kind of]* exposed by data() but as you see it's explicitly set to return a const void*.

                    *if you don't save basic types in the variant then it is exposed

                    "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
                    ~Napoleon Bonaparte

                    On a crusade to banish setIndexWidget() from the holy land of Qt

                    1 Reply Last reply
                    0
                    • Christian EhrlicherC Christian Ehrlicher

                      d is protected so no other function will get access to this variable and there is also no need for it. What do you want to achieve?

                      E Offline
                      E Offline
                      elfring
                      wrote on last edited by
                      #12

                      What do you want to achieve?

                      The mentioned access specifiers will influence possible software extensions around classes like “QVariant”.

                      • I would like to get safe access to the members in the data structure “QVariant::Private”.
                      • Would you like to support in-place modification for referenced objects then?
                      1 Reply Last reply
                      0
                      • Christian EhrlicherC Offline
                        Christian EhrlicherC Offline
                        Christian Ehrlicher
                        Lifetime Qt Champion
                        wrote on last edited by Christian Ehrlicher
                        #13

                        You will never get any safe access to QVariant::Private - it's a private class and therefore can change any time. And no I don't need in-place modifications (this was discussed on the mailing list some weeks ago).

                        https://lists.qt-project.org/pipermail/interest/2018-June/030216.html

                        If you want in-place modifications then store a pointer in QVariant so you can modify the data without accessing the QVariant.

                        Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
                        Visit the Qt Academy at https://academy.qt.io/catalog

                        E 2 Replies Last reply
                        3
                        • Christian EhrlicherC Christian Ehrlicher

                          You will never get any safe access to QVariant::Private - it's a private class and therefore can change any time. And no I don't need in-place modifications (this was discussed on the mailing list some weeks ago).

                          https://lists.qt-project.org/pipermail/interest/2018-June/030216.html

                          If you want in-place modifications then store a pointer in QVariant so you can modify the data without accessing the QVariant.

                          E Offline
                          E Offline
                          elfring
                          wrote on last edited by
                          #14

                          it's a private class

                          • Please take another look.
                          • The class declaration is using the access specifier “public” for this data structure so far, doesn't it?

                          this was discussed on the mailing list some weeks ago

                          Thanks for your link of the discussion topic “Why no T& QVariant::value()?”.

                          If you want in-place modifications then store a pointer in QVariant …

                          I became interested once more to perform some data processing for contents (which could be provided over variables like “QObject *o” and “PrivateShared *shared”) without extra copies.

                          1 Reply Last reply
                          0
                          • VRoninV Offline
                            VRoninV Offline
                            VRonin
                            wrote on last edited by
                            #15

                            You are looking for an unnecessary hack to solve a very simple problem.
                            If all the classes you have stored in a QVariant are implicitly shared* and the members of those classes are also all implicitly shared* and so on down the object tree, then your get-modify-set is already as efficient as you can get short of memcpy. If you want I can explain in detail why if it's not clear.

                            ' * or fundamental types

                            "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
                            ~Napoleon Bonaparte

                            On a crusade to banish setIndexWidget() from the holy land of Qt

                            E 1 Reply Last reply
                            2
                            • Christian EhrlicherC Christian Ehrlicher

                              You will never get any safe access to QVariant::Private - it's a private class and therefore can change any time. And no I don't need in-place modifications (this was discussed on the mailing list some weeks ago).

                              https://lists.qt-project.org/pipermail/interest/2018-June/030216.html

                              If you want in-place modifications then store a pointer in QVariant so you can modify the data without accessing the QVariant.

                              E Offline
                              E Offline
                              elfring
                              wrote on last edited by
                              #16

                              You will never get any safe access to QVariant::Private -

                              I suggest to reconsider this information. - I guess that we got different expectations for the “safety” of such data structures.

                              it's a private class

                              The privacy concerns can vary also if you would like to implement possibly useful functionality for this class.

                              and therefore can change any time.

                              This aspect is reasonable for software evolution in general. I am curious on how change acceptance (or resistance?) will evolve here.

                              And no I don't need in-place modifications

                              Do other Qt users and software developers would like to apply this technique?

                              If you want in-place modifications then store a pointer in QVariant so you can modify the data without accessing the QVariant.

                              • This is another useful software design approach. But these pointers should refer to valid data.
                              • This class can be treated as a container for a single item (with a varying internal data type). You would occasionally prefer direct write access to the contained element.
                                I guess that I am looking again for Qt support of an operation which became standardised as “std::get”.
                              VRoninV 1 Reply Last reply
                              0
                              • VRoninV VRonin

                                You are looking for an unnecessary hack to solve a very simple problem.
                                If all the classes you have stored in a QVariant are implicitly shared* and the members of those classes are also all implicitly shared* and so on down the object tree, then your get-modify-set is already as efficient as you can get short of memcpy. If you want I can explain in detail why if it's not clear.

                                ' * or fundamental types

                                E Offline
                                E Offline
                                elfring
                                wrote on last edited by
                                #17

                                You are looking for an unnecessary hack to solve a very simple problem.

                                It can take a while to get acceptance for another useful programming interface, can't it?

                                1 Reply Last reply
                                0
                                • E elfring

                                  You will never get any safe access to QVariant::Private -

                                  I suggest to reconsider this information. - I guess that we got different expectations for the “safety” of such data structures.

                                  it's a private class

                                  The privacy concerns can vary also if you would like to implement possibly useful functionality for this class.

                                  and therefore can change any time.

                                  This aspect is reasonable for software evolution in general. I am curious on how change acceptance (or resistance?) will evolve here.

                                  And no I don't need in-place modifications

                                  Do other Qt users and software developers would like to apply this technique?

                                  If you want in-place modifications then store a pointer in QVariant so you can modify the data without accessing the QVariant.

                                  • This is another useful software design approach. But these pointers should refer to valid data.
                                  • This class can be treated as a container for a single item (with a varying internal data type). You would occasionally prefer direct write access to the contained element.
                                    I guess that I am looking again for Qt support of an operation which became standardised as “std::get”.
                                  VRoninV Offline
                                  VRoninV Offline
                                  VRonin
                                  wrote on last edited by
                                  #18

                                  @elfring said in Checking the API status for the variable “Private d” of the QVariant class:

                                  You would occasionally prefer direct write access to the contained element.

                                  My point is exactly that implicit sharing removes this need

                                  It can take a while to get acceptance for another useful programming interface, can't it?

                                  And it can take even longer if it's not necessary. Move constructor/assignments are another great example of a feature introduced in the standard that is basically useless when dealing with implicitly shared classes as they do it better and seamlessly.

                                  "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
                                  ~Napoleon Bonaparte

                                  On a crusade to banish setIndexWidget() from the holy land of Qt

                                  E 1 Reply Last reply
                                  1
                                  • VRoninV VRonin

                                    @elfring said in Checking the API status for the variable “Private d” of the QVariant class:

                                    You would occasionally prefer direct write access to the contained element.

                                    My point is exactly that implicit sharing removes this need

                                    It can take a while to get acceptance for another useful programming interface, can't it?

                                    And it can take even longer if it's not necessary. Move constructor/assignments are another great example of a feature introduced in the standard that is basically useless when dealing with implicitly shared classes as they do it better and seamlessly.

                                    E Offline
                                    E Offline
                                    elfring
                                    wrote on last edited by
                                    #19

                                    My point is exactly that implicit sharing removes this need

                                    This technique depends on the management of object reference counters which can be useful functionality and can trigger related software development challenges.

                                    And it can take even longer if it's not necessary.

                                    Do you care for improvements around generic data processing algorithms?

                                    VRoninV 1 Reply Last reply
                                    0
                                    • E elfring

                                      My point is exactly that implicit sharing removes this need

                                      This technique depends on the management of object reference counters which can be useful functionality and can trigger related software development challenges.

                                      And it can take even longer if it's not necessary.

                                      Do you care for improvements around generic data processing algorithms?

                                      VRoninV Offline
                                      VRoninV Offline
                                      VRonin
                                      wrote on last edited by
                                      #20

                                      @elfring said in Checking the API status for the variable “Private d” of the QVariant class:

                                      This technique depends on the management of object reference counters

                                      Are we complaining about loss of performance due to an additional integer increment and decrement?

                                      Do you care for improvements around generic data processing algorithms?

                                      Not if they interfere heavily with my objects functionality isolation.


                                      Can I ask, really, what is causing your aversion to how QVariant works? The only scenario I'd imagine is if you are developing microsecond-critical applications (like automatic stock trading) but you mention you are using QStandardItemModel and the inefficiencies inside that model implementation dwarf any moot point about optimising the editing of a QVariant

                                      "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
                                      ~Napoleon Bonaparte

                                      On a crusade to banish setIndexWidget() from the holy land of Qt

                                      E 1 Reply Last reply
                                      4
                                      • VRoninV VRonin

                                        @elfring said in Checking the API status for the variable “Private d” of the QVariant class:

                                        This technique depends on the management of object reference counters

                                        Are we complaining about loss of performance due to an additional integer increment and decrement?

                                        Do you care for improvements around generic data processing algorithms?

                                        Not if they interfere heavily with my objects functionality isolation.


                                        Can I ask, really, what is causing your aversion to how QVariant works? The only scenario I'd imagine is if you are developing microsecond-critical applications (like automatic stock trading) but you mention you are using QStandardItemModel and the inefficiencies inside that model implementation dwarf any moot point about optimising the editing of a QVariant

                                        E Offline
                                        E Offline
                                        elfring
                                        wrote on last edited by
                                        #21

                                        Are we complaining about loss of performance due to an additional integer increment and decrement?

                                        This can occasionally happen, can't it?

                                        …, what is causing your aversion to how QVariant works?

                                        I got special software development opinions. The QVariant class is useful. I am just looking for a few extensions there.

                                        … but you mention you are using QStandardItemModel …

                                        This is Qt standard software which provides known functionality. I would like to apply it as it would mostly be usual.

                                        VRoninV 1 Reply Last reply
                                        0
                                        • E elfring

                                          Are we complaining about loss of performance due to an additional integer increment and decrement?

                                          This can occasionally happen, can't it?

                                          …, what is causing your aversion to how QVariant works?

                                          I got special software development opinions. The QVariant class is useful. I am just looking for a few extensions there.

                                          … but you mention you are using QStandardItemModel …

                                          This is Qt standard software which provides known functionality. I would like to apply it as it would mostly be usual.

                                          VRoninV Offline
                                          VRoninV Offline
                                          VRonin
                                          wrote on last edited by VRonin
                                          #22

                                          @elfring said in Checking the API status for the variable “Private d” of the QVariant class:

                                          This can occasionally happen, can't it?

                                          Can, should and will.

                                          I got special software development opinions.

                                          Forcing your opinion on the framework is possible but don't expect it to be easy.
                                          Forcing the framework to adopt those opinions is a titanic endeavour.

                                          This is Qt standard software which provides known functionality.

                                          True and I always suggest to use it as it's super convenient but it must be clear that it's very far from being an implementation of a model optimised for performance

                                          "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
                                          ~Napoleon Bonaparte

                                          On a crusade to banish setIndexWidget() from the holy land of Qt

                                          E 1 Reply Last reply
                                          2

                                          • Login

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