Checking the API status for the variable “Private d” of the QVariant class
-
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.
-
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.
wrote on 4 Oct 2018, 10:11 last edited by VRonin 10 Apr 2018, 10:12@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
-
@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
-
… 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
Will such information trigger any further software evolution?
@elfring said in Checking the API status for the variable “Private d” of the QVariant class:
… 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
Will such information trigger any further software evolution?
That's unlikely.
If you want performance, you have more abstract classes at your disposal, where more coding is necessary (less convenient) but more fine control over details is possible.
-
@elfring said in Checking the API status for the variable “Private d” of the QVariant class:
… 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
Will such information trigger any further software evolution?
That's unlikely.
If you want performance, you have more abstract classes at your disposal, where more coding is necessary (less convenient) but more fine control over details is possible.
wrote on 16 Oct 2018, 08:55 last edited byIf you want performance, you have more abstract classes at your disposal,
How can they really help here?
where more coding is necessary (less convenient) but more fine control over details is possible.
Can it eventually help more to improve (or extend) also the implementation of the class “QVariant”?
-
If you want performance, you have more abstract classes at your disposal,
How can they really help here?
where more coding is necessary (less convenient) but more fine control over details is possible.
Can it eventually help more to improve (or extend) also the implementation of the class “QVariant”?
@elfring said in Checking the API status for the variable “Private d” of the QVariant class:
If you want performance, you have more abstract classes at your disposal,
How can they really help here?
where more coding is necessary (less convenient) but more fine control over details is possible.
Can it eventually help more to improve (or extend) also the implementation of the class “QVariant”?
Feel free to improve QVariant, if you have the means. Qt is an open project, if your contribution is judged beneficial, it will be included upstream.
-
@elfring said in Checking the API status for the variable “Private d” of the QVariant class:
If you want performance, you have more abstract classes at your disposal,
How can they really help here?
where more coding is necessary (less convenient) but more fine control over details is possible.
Can it eventually help more to improve (or extend) also the implementation of the class “QVariant”?
Feel free to improve QVariant, if you have the means. Qt is an open project, if your contribution is judged beneficial, it will be included upstream.
-
Feel free to improve QVariant, if you have the means.
How do you think about to support the addition of a member function like “(std::)get”?
@elfring said in Checking the API status for the variable “Private d” of the QVariant class:
Feel free to improve QVariant, if you have the means.
How do you think about to support the addition of a member function like “(std::)get”?
I'm not a Qt developer. I'm not sure if STD is allowed in public Qt API. And lastly, I don't care about std::get ;-) But I may be alone in this.
-
@elfring said in Checking the API status for the variable “Private d” of the QVariant class:
Feel free to improve QVariant, if you have the means.
How do you think about to support the addition of a member function like “(std::)get”?
I'm not a Qt developer. I'm not sure if STD is allowed in public Qt API. And lastly, I don't care about std::get ;-) But I may be alone in this.
wrote on 16 Oct 2018, 09:30 last edited byAnd lastly, I don't care about std::get
Will you care more for recent software extensions from the standard “ISO/IEC 14882” in the near future?
-
And lastly, I don't care about std::get
Will you care more for recent software extensions from the standard “ISO/IEC 14882” in the near future?
@elfring said in Checking the API status for the variable “Private d” of the QVariant class:
And lastly, I don't care about std::get
Will you care more for recent software extensions from the standard “ISO/IEC 14882” in the near future?
What does that have to do with this topic? Are you interviewing me for a job now or something? :-)
Sorry mate but I see no point in continuing this conversation.
-
@elfring said in Checking the API status for the variable “Private d” of the QVariant class:
And lastly, I don't care about std::get
Will you care more for recent software extensions from the standard “ISO/IEC 14882” in the near future?
What does that have to do with this topic? Are you interviewing me for a job now or something? :-)
Sorry mate but I see no point in continuing this conversation.
wrote on 16 Oct 2018, 09:49 last edited bySorry mate but I see no point in continuing this conversation.
Some software developers agreed that they need the class “variant” for working with type-safe unions. They chose another useful programming interface. These software design decisions might influence other class libraries, don't they?
The Qt software library is using also a variant class for the support of the meta-object protocol, isn't it?
