There is an smart and safe pointer to a QString object?
-
@Christian-Ehrlicher QTs have very interesting and useful mechanisms, which are applied automatically in many objects, implicit sharing, copy-on-write, shallow copies, etc. .
This obviously (or not obviously, probably depends on how much time you spent debugging strange behaviors due to anomalous use of the QT) makes the type of use I would like to do more complicated.
If you want help then please describe your usecase properly - so noone can help you.
A QString on the heap is not really a good idea nor needed in most of the use cases so ... -
If you want help then please describe your usecase properly - so noone can help you.
A QString on the heap is not really a good idea nor needed in most of the use cases so ...@Christian-Ehrlicher
For the moment I'm mainly trying to understand the QT environment (doing an update of a program from QT3 to QT4), it's the first time I using a system where smart pointers are so intensely and widely used.Sometimes some triks can save days of work, and I'm trying to figure out what I can and shouldn't do using QTs, even crashing into them.
From what I understand this my anomalous use of the QString is to be avoided, too many problems that cannot be managed decently.
-
@Christian-Ehrlicher
For the moment I'm mainly trying to understand the QT environment (doing an update of a program from QT3 to QT4), it's the first time I using a system where smart pointers are so intensely and widely used.Sometimes some triks can save days of work, and I'm trying to figure out what I can and shouldn't do using QTs, even crashing into them.
From what I understand this my anomalous use of the QString is to be avoided, too many problems that cannot be managed decently.
@giusdbg said in There is an smart and safe pointer to a QString object?:
From what I understand this my anomalous use of the QString is to be avoided, too many problems that cannot be managed decently.
No, there are no problems with that - it's simply not needed and useless to wrap a QString into a (smart)pointer.
-
@giusdbg said in There is an smart and safe pointer to a QString object?:
From what I understand this my anomalous use of the QString is to be avoided, too many problems that cannot be managed decently.
No, there are no problems with that - it's simply not needed and useless to wrap a QString into a (smart)pointer.
-
G giusdbg has marked this topic as solved on
-
@Christian-Ehrlicher smart pointer is a good indirect suggestion.
QPointer<QString> is a great option for various cases.
P.S. WRONG, QPointer work only with QObject based object.@giusdbg said in There is an smart and safe pointer to a QString object?:
QPointer<QString> is a great option for various cases.
No, for sure not...
-
@giusdbg said in There is an smart and safe pointer to a QString object?:
QPointer<QString> is a great option for various cases.
No, for sure not...
@Christian-Ehrlicher True, QPointer work only with QObject based object, interesting solution but not for my case.
Case closed in any case (dead end).
-
@Christian-Ehrlicher
For the moment I'm mainly trying to understand the QT environment (doing an update of a program from QT3 to QT4), it's the first time I using a system where smart pointers are so intensely and widely used.Sometimes some triks can save days of work, and I'm trying to figure out what I can and shouldn't do using QTs, even crashing into them.
From what I understand this my anomalous use of the QString is to be avoided, too many problems that cannot be managed decently.
@giusdbg said in There is an smart and safe pointer to a QString object?:
For the moment I'm mainly trying to understand the QT environment (doing an update of a program from QT3 to QT4), it's the first time I using a system where smart pointers are so intensely and widely used.
It's a bit confusing what about Qt you are trying to understand here. It seems like there is some sort of "XY problem" underlying your question. https://xyproblem.info/
Everything you are asking about would be the same with an int or any other data type in C++. If you keep a raw pointer to something that might be destroyed elsewhere, you'll have problems. If you want to change the state of an object, you should use the public interface of that object to do it, and not try to poke directly at pointers to members of that object. Normally, you would just call some setText() function or something like that.
If you explain what you are actually trying to accomplish, people might be able to suggest some approach, but it won't be this.
-
@giusdbg said in There is an smart and safe pointer to a QString object?:
For the moment I'm mainly trying to understand the QT environment (doing an update of a program from QT3 to QT4), it's the first time I using a system where smart pointers are so intensely and widely used.
It's a bit confusing what about Qt you are trying to understand here. It seems like there is some sort of "XY problem" underlying your question. https://xyproblem.info/
Everything you are asking about would be the same with an int or any other data type in C++. If you keep a raw pointer to something that might be destroyed elsewhere, you'll have problems. If you want to change the state of an object, you should use the public interface of that object to do it, and not try to poke directly at pointers to members of that object. Normally, you would just call some setText() function or something like that.
If you explain what you are actually trying to accomplish, people might be able to suggest some approach, but it won't be this.
@wrosecrans Yes, thanks for your reply.
The code that I had to fix taking a few days of work, in QT3 worked perfectly, in QT4 it caused access to destroyed objects, use of uninitialized variables, etc., without crashing the program, just writing junk to a config file.
It's not the QT's fault, it was just caused by the way they functioned and being used beyond their limit.
I tried to explain that I'm not looking for a solution to a problem, but only to analyze, to extremes, a particular case that I had to face and see if there was some programming technique, a trick, that I'm not able to see, to explore the limits of QT and above all the limits of my knowledge.
From my point of view the correct answer to my question is
- It cannot be done, it will always remain a dangerous use.
- There would be QPointer which would solve the problem, but it only works with QObject based objects.
-
@wrosecrans Yes, thanks for your reply.
The code that I had to fix taking a few days of work, in QT3 worked perfectly, in QT4 it caused access to destroyed objects, use of uninitialized variables, etc., without crashing the program, just writing junk to a config file.
It's not the QT's fault, it was just caused by the way they functioned and being used beyond their limit.
I tried to explain that I'm not looking for a solution to a problem, but only to analyze, to extremes, a particular case that I had to face and see if there was some programming technique, a trick, that I'm not able to see, to explore the limits of QT and above all the limits of my knowledge.
From my point of view the correct answer to my question is
- It cannot be done, it will always remain a dangerous use.
- There would be QPointer which would solve the problem, but it only works with QObject based objects.
@giusdbg said in There is an smart and safe pointer to a QString object?:
There would be QPointer which would solve the problem, but it only works with QObject based objects.
I think this is the key to what you were looking for (whatever the existing code behind might be doing).
QPointerdoes just what (I think) you want, but it only works forQObjects, and the very base Qt classes (likeQStringorQList) are "lightweight" and notQObjects. Indeed, the ability ofQPointerto work as it does relies on howQObjects/QMetaObjects work.By the way, did you see/for your interest Qt also has QScopedPointer Class? For the record that would have worked with, say,
QString *, it's not aQObjectthing. But I suspect (a) it doesn't do enough of what you want, it's a very specific scope thing and (b) would mean changing other code, don't think you want to do that. -
@wrosecrans Yes, thanks for your reply.
The code that I had to fix taking a few days of work, in QT3 worked perfectly, in QT4 it caused access to destroyed objects, use of uninitialized variables, etc., without crashing the program, just writing junk to a config file.
It's not the QT's fault, it was just caused by the way they functioned and being used beyond their limit.
I tried to explain that I'm not looking for a solution to a problem, but only to analyze, to extremes, a particular case that I had to face and see if there was some programming technique, a trick, that I'm not able to see, to explore the limits of QT and above all the limits of my knowledge.
From my point of view the correct answer to my question is
- It cannot be done, it will always remain a dangerous use.
- There would be QPointer which would solve the problem, but it only works with QObject based objects.
@giusdbg said in There is an smart and safe pointer to a QString object?:
@wrosecrans Yes, thanks for your reply.
The code that I had to fix taking a few days of work, in QT3 worked perfectly, in QT4 it caused access to destroyed objects, use of uninitialized variables, etc., without crashing the program, just writing junk to a config file.
It's not the QT's fault, it was just caused by the way they functioned and being used beyond their limit.
I tried to explain that I'm not looking for a solution to a problem, but only to analyze, to extremes, a particular case that I had to face and see if there was some programming technique, a trick, that I'm not able to see, to explore the limits of QT and above all the limits of my knowledge.
From my point of view the correct answer to my question is
- It cannot be done, it will always remain a dangerous use.
- There would be QPointer which would solve the problem, but it only works with QObject based objects.
Third option: it needs cleanup or porting or both.
You may have discovered issues that were hidden. A proper fix will be way better than any workaround.
-
@giusdbg said in There is an smart and safe pointer to a QString object?:
There would be QPointer which would solve the problem, but it only works with QObject based objects.
I think this is the key to what you were looking for (whatever the existing code behind might be doing).
QPointerdoes just what (I think) you want, but it only works forQObjects, and the very base Qt classes (likeQStringorQList) are "lightweight" and notQObjects. Indeed, the ability ofQPointerto work as it does relies on howQObjects/QMetaObjects work.By the way, did you see/for your interest Qt also has QScopedPointer Class? For the record that would have worked with, say,
QString *, it's not aQObjectthing. But I suspect (a) it doesn't do enough of what you want, it's a very specific scope thing and (b) would mean changing other code, don't think you want to do that.@JonB Yes, your answer is a rather complete analysis of the situation, both the concrete one of the problem, and the attempt to investigate alternative programming techniques and tricks.
In the end I decided that if I have to spend days of work, I prefer to remove, improve and adapt the code to the QT (e.g. removes all non-strictly local uses of char * , .toAscii() , .data(), etc.) rather than adding other possible layers of complexity and probable malfunction.
P.S. Personally, I found all the replies and discussions on Qt Forum useful, at least they pushed me to see beyond my knowledge limits, and to try new things, which were useful to me shortly after (or as soon as my knowledge was sufficient to use them).
Thanks for the various help.
This is the currently bug free (touch wood 🙃) program
-
@giusdbg said in There is an smart and safe pointer to a QString object?:
@wrosecrans Yes, thanks for your reply.
The code that I had to fix taking a few days of work, in QT3 worked perfectly, in QT4 it caused access to destroyed objects, use of uninitialized variables, etc., without crashing the program, just writing junk to a config file.
It's not the QT's fault, it was just caused by the way they functioned and being used beyond their limit.
I tried to explain that I'm not looking for a solution to a problem, but only to analyze, to extremes, a particular case that I had to face and see if there was some programming technique, a trick, that I'm not able to see, to explore the limits of QT and above all the limits of my knowledge.
From my point of view the correct answer to my question is
- It cannot be done, it will always remain a dangerous use.
- There would be QPointer which would solve the problem, but it only works with QObject based objects.
Third option: it needs cleanup or porting or both.
You may have discovered issues that were hidden. A proper fix will be way better than any workaround.
@SGaist Yes, this is also true, various problems were due to code that should not be written even in QT 3.
The cleanup and reorganization of the code has been done where it would have been thoughtless not to do it, and in preparation for the jump to QT 5/6 .
But there are so many problems to deal with, tons of things to learn almost from scratch, so I analyze the situation of the various things, and assign the priority at what and how to deal with them.
And so for me it is very useful to try to learn new techniques, tricks, to cut edges, so that I can deal with problems based on their importance, usefulness and current knowledge, and postpone the rest.
-
@SGaist Yes, this is also true, various problems were due to code that should not be written even in QT 3.
The cleanup and reorganization of the code has been done where it would have been thoughtless not to do it, and in preparation for the jump to QT 5/6 .
But there are so many problems to deal with, tons of things to learn almost from scratch, so I analyze the situation of the various things, and assign the priority at what and how to deal with them.
And so for me it is very useful to try to learn new techniques, tricks, to cut edges, so that I can deal with problems based on their importance, usefulness and current knowledge, and postpone the rest.
-
Sometimes you need to throw out the baby with the bath water.
