Checking the API status for the variable “Private d” of the QVariant class
-
I have noticed the following source code.
… // ### Qt6: FIXME: Remove the special Q_CC_MSVC handling, it was introduced to maintain BC for QTBUG-41810 . #if !defined(Q_NO_TEMPLATE_FRIENDS) && !defined(Q_CC_MSVC) template<typename T> friend inline T qvariant_cast(const QVariant &); template<typename T> friend struct QtPrivate::QVariantValueHelper; protected: #else public: #endif Private d; …I have noticed also that the member variable “d” is not mentioned in the Qt documentation so far. So I get doubts if it can really belong to the public programming interface by this class.
How will this software evolve further?@elfring
the d-pointer is the private implementation of Qt classes and guarantee binary compatibility over Qt minor versions.
I don't know whenQ_NO_TEMPLATE_FRIENDSwill really be defined so that the d-pointer becomes public.But anyway d-pointers are not meant to be accessed.
-
d does not belong to the public interface so you don't have to worry
-
d does not belong to the public interface so you don't have to worry
@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
dpointer, it's and instance ofPrivatestruct, calledd. Looks like it is indeed part of the public interface here. -
@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
dpointer, it's and instance ofPrivatestruct, calledd. Looks like it is indeed part of the public interface here.wrote on 3 Oct 2018, 13:27 last edited byLooks like it is indeed part of the public interface here.
Conditional compilation can eventually make this variable “protected”, can't it?
-
Looks like it is indeed part of the public interface here.
Conditional compilation can eventually make this variable “protected”, can't it?
@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
-
wrote on 3 Oct 2018, 13:32 last edited by
Q_NO_TEMPLATE_FRIENDSis only defined in old or unusual compilers, if you trust the comment (i.e. theQ_CC_MSVConly exist for binary compatibility but it should be removed) I'd say the base case is fordto beprotected -
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.
-
Q_NO_TEMPLATE_FRIENDSis only defined in old or unusual compilers, if you trust the comment (i.e. theQ_CC_MSVConly exist for binary compatibility but it should be removed) I'd say the base case is fordto beprotectedwrote on 3 Oct 2018, 13:47 last edited byI'd say the base case is for
dto beprotectedWould you like to encapsulate accesses for the member variable “d” (of the class “QVariant”) by any other function?
-
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?
-
I'd say the base case is for
dto beprotectedWould you like to encapsulate accesses for the member variable “d” (of the class “QVariant”) by any other function?
wrote on 3 Oct 2018, 13:55 last edited by VRonin 10 Mar 2018, 14:01@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 aconst void*.*if you don't save basic types in the variant then it is exposed
-
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?
wrote on 3 Oct 2018, 14:26 last edited byWhat 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?
-
Lifetime Qt Championwrote on 3 Oct 2018, 14:30 last edited by Christian Ehrlicher 10 Mar 2018, 14:34
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.
-
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.
wrote on 3 Oct 2018, 15:02 last edited byit'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.
-
wrote on 4 Oct 2018, 07:42 last edited by
You are looking for an unnecessary hack to solve a very simple problem.
If all the classes you have stored in aQVariantare 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 ofmemcpy. If you want I can explain in detail why if it's not clear.' * or fundamental types
-
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.
wrote on 4 Oct 2018, 08:05 last edited byYou 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”.
-
You are looking for an unnecessary hack to solve a very simple problem.
If all the classes you have stored in aQVariantare 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 ofmemcpy. If you want I can explain in detail why if it's not clear.' * or fundamental types
wrote on 4 Oct 2018, 08:20 last edited byYou 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?
-
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”.
wrote on 4 Oct 2018, 08:49 last edited by@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.
-
@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.
wrote on 4 Oct 2018, 09:11 last edited byMy 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?
-
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?
wrote on 4 Oct 2018, 09:39 last edited by@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
QVariantworks? The only scenario I'd imagine is if you are developing microsecond-critical applications (like automatic stock trading) but you mention you are usingQStandardItemModeland the inefficiencies inside that model implementation dwarf any moot point about optimising the editing of aQVariant -
@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
QVariantworks? The only scenario I'd imagine is if you are developing microsecond-critical applications (like automatic stock trading) but you mention you are usingQStandardItemModeland the inefficiencies inside that model implementation dwarf any moot point about optimising the editing of aQVariantwrote on 4 Oct 2018, 09:55 last edited byAre 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.
11/31