Throwing a C++ exception instead of returning a default-constructed object by QVariant::value()
-
The following information is provided for the function “QVariant::value”.
“…
If the value cannot be converted, a default-constructed value will be returned.
…”I would find it useful if a corresponding function variant will throw a C++ exception after a data type conversion failure so that the mentioned default object construction can not happen by such a programming interface.
How do you think about another software extension here? -
Qt does not throw exceptions. If you want to avoid the cost of default constructed object then you can check beforehand if the conversion is possible using QVariant::canConvert() i.e.
if (v.canConvert<SomeType>()) doSomethingWith(v.value<SomeType>()); else doWhatYouWouldDoInACatchClauseIfItThrewAnException(); -
Qt does not throw exceptions. If you want to avoid the cost of default constructed object then you can check beforehand if the conversion is possible using QVariant::canConvert() i.e.
if (v.canConvert<SomeType>()) doSomethingWith(v.value<SomeType>()); else doWhatYouWouldDoInACatchClauseIfItThrewAnException();If you want to avoid the cost of default constructed object …
I know the possibility of the check by the function “QVariant::canConvert”.
- But I became concerned that this can not be as efficient as using a variant of the function “QVariant::value” because a QVariant object needs to be created just for this function call.
- I imagine that the desired data type conversion can become a bit safer by the other way.
-
If you want to avoid the cost of default constructed object …
I know the possibility of the check by the function “QVariant::canConvert”.
- But I became concerned that this can not be as efficient as using a variant of the function “QVariant::value” because a QVariant object needs to be created just for this function call.
- I imagine that the desired data type conversion can become a bit safer by the other way.
I became concerned that this can not be as efficient as using a variant of the function “QVariant::value” because a QVariant object needs to be created just for this function call.
Sorry, I don't understand what you mean. You call
value()on an object so you already have an object. How is callingcanConvert()on the same object first not as efficient? Can you maybe give a code snippet example of what you mean?I imagine that the desired data type conversion can become a bit safer by the other way.
How so? Can you give an example of such case?
-
I became concerned that this can not be as efficient as using a variant of the function “QVariant::value” because a QVariant object needs to be created just for this function call.
Sorry, I don't understand what you mean. You call
value()on an object so you already have an object. How is callingcanConvert()on the same object first not as efficient? Can you maybe give a code snippet example of what you mean?I imagine that the desired data type conversion can become a bit safer by the other way.
How so? Can you give an example of such case?
-
I became concerned that this can not be as efficient as using a variant of the function “QVariant::value” because a QVariant object needs to be created just for this function call.
Sorry, I don't understand what you mean. You call
value()on an object so you already have an object. How is callingcanConvert()on the same object first not as efficient? Can you maybe give a code snippet example of what you mean?I imagine that the desired data type conversion can become a bit safer by the other way.
How so? Can you give an example of such case?
Can you give an example of such case?
Are further software development considerations relevant for data synchronisation around mentioned source code places?
-
How is calling
canConvert()on the same object first not as efficient?I would repeat a data type check which can be performed by the Qt software library already.
I would repeat a data type check which can be performed by the Qt software library already.
Yes, but those are nano-optimizations that are not usually relevant. Have you measured that it has a real negative impact on performance of your app?
Do you consider throwing an exception and related stack unwinding a cheaper operation than comparing types (which sometimes optimizes to comparing two ints)? Have you measured that one is significantly faster than another on your target architecture?Are further software development considerations relevant for data synchronisation around mentioned source code places?
I'm not sure what you're asking. Do you mean is QVariant thread-safe? It's not. You need to do thread synchronization on your side.
-
I would repeat a data type check which can be performed by the Qt software library already.
Yes, but those are nano-optimizations that are not usually relevant. Have you measured that it has a real negative impact on performance of your app?
Do you consider throwing an exception and related stack unwinding a cheaper operation than comparing types (which sometimes optimizes to comparing two ints)? Have you measured that one is significantly faster than another on your target architecture?Are further software development considerations relevant for data synchronisation around mentioned source code places?
I'm not sure what you're asking. Do you mean is QVariant thread-safe? It's not. You need to do thread synchronization on your side.
Yes, but those are nano-optimizations that are not usually relevant.
I try to avoid questionable checks a bit more.
Do you consider throwing an exception and related stack unwinding a cheaper operation than comparing types …?
I have got other software development preferences here. I would like to use the C++ exception handling system in the way it was designed.
I became curious if a statement like “throw data_type_conversion_failure();” can be used instead of “return T();”.You need to do thread synchronization on your side.
Will this eventually be provided by a companion class template library?
-
I would like to use the C++ exception handling system in the way it was designed.
That's fine. Qt mostly doesn't use that programming style so if it's important to you you should look for alternatives e.g. std::variant. There are dozens other variant implementations out there or you can roll your own if none of them behave exactly like you want. I'm pretty sure Qt is not gonna change how it handles errors. It's decades too late for that.
Qt was born in times when exception handling was either unavailable or not equally featured on all supported platforms so not using them was an obvious choice for a cross-platform library design. Today there would be no benefit in converting such a huge library to another programming paradigm just for the sake of it. There are also real world considerations, like a notable library size increase when turning exceptions on (as mentioned here).
Will this eventually be provided by a companion class template library?
I'm again not sure what you're asking. A thread safe access to QObject? I don't see how that could be buit-in in a generic enough way as to not incur a big size and performance hit. It's more of a case by case thing and I doubt Qt will provide anything like that. It's easy enough to create a thread-safe wrappers around your QObjects tailored to your own needs. Qt does provide the necessary primitives like QMutex or QReadWriteLock for that.
But it's an open project so if someone submits a library for inclusion then who knows, maybe. I'm not aware of any such work being done or planned though.
-
I would like to use the C++ exception handling system in the way it was designed.
That's fine. Qt mostly doesn't use that programming style so if it's important to you you should look for alternatives e.g. std::variant. There are dozens other variant implementations out there or you can roll your own if none of them behave exactly like you want. I'm pretty sure Qt is not gonna change how it handles errors. It's decades too late for that.
Qt was born in times when exception handling was either unavailable or not equally featured on all supported platforms so not using them was an obvious choice for a cross-platform library design. Today there would be no benefit in converting such a huge library to another programming paradigm just for the sake of it. There are also real world considerations, like a notable library size increase when turning exceptions on (as mentioned here).
Will this eventually be provided by a companion class template library?
I'm again not sure what you're asking. A thread safe access to QObject? I don't see how that could be buit-in in a generic enough way as to not incur a big size and performance hit. It's more of a case by case thing and I doubt Qt will provide anything like that. It's easy enough to create a thread-safe wrappers around your QObjects tailored to your own needs. Qt does provide the necessary primitives like QMutex or QReadWriteLock for that.
But it's an open project so if someone submits a library for inclusion then who knows, maybe. I'm not aware of any such work being done or planned though.
A thread safe access to QObject?
A few programming interfaces are thread-safe at the moment.
I don't see how that could be buit-in in a generic enough way as to not incur a big size and performance hit.
How do yout think about the introduction of additional class/function template parameters?
-
A thread safe access to QObject?
A few programming interfaces are thread-safe at the moment.
I don't see how that could be buit-in in a generic enough way as to not incur a big size and performance hit.
How do yout think about the introduction of additional class/function template parameters?
A few programming interfaces are thread-safe at the moment.
Well yeah, the ones related to threading obviously. But those are few out of thousands in the Qt library. Making everything in the library thread-safe has an inherent cost to it and it would fix one case and break thousands.
How do you think about the introduction of additional class/function template parameters?
Personally I don't need it and am not interested in it. But like I said - I'm just one user and it's an open project.
In any case Qt has very strict source and binary compatibility promises and this would be a fundamental change to the core classes so I doubt it will happen. -
A few programming interfaces are thread-safe at the moment.
Well yeah, the ones related to threading obviously. But those are few out of thousands in the Qt library. Making everything in the library thread-safe has an inherent cost to it and it would fix one case and break thousands.
How do you think about the introduction of additional class/function template parameters?
Personally I don't need it and am not interested in it. But like I said - I'm just one user and it's an open project.
In any case Qt has very strict source and binary compatibility promises and this would be a fundamental change to the core classes so I doubt it will happen.I'm just one user and it's an open project.
I am curious if other contributors would like to express more support for the mentioned software areas.
… so I doubt it will happen.
Some class and template libraries (including Qt software) were developed through the years.
-
You won't get an exception as 'return' value for invalid parameters in Qt in the near (and imo even far) future. Maybe Qt7 ...
-
You won't get an exception as 'return' value for invalid parameters in Qt in the near (and imo even far) future. Maybe Qt7 ...
Maybe Qt7 ...
I can eventually try also to add an implementation variant for the function “QVariantValueHelper::metaType” (on my own).
