-
From my pov QVector::value() should be deprecated - it's a really weird function which returns a copy just for the reason that the caller does not do the bounds checking.
I don't see a difference in the asm output in a single testcase. -
Thank you for the explanation - indeed, I saw in docs that value() is const but since it worked for the QString I just... assumed it works anyway. Silly of me.
So, to make it work as intended I should use [index] notation, like @hskoglund said (I am somehow opposed to using it in the favour of methods).
Since I already got everyones involved attention - the QVector (in this case) is supposed to hold less than 20 of items, set once and not being manipulated further. Is the choice of QVector over other container types a valid one? I read about container classes and differences between them and after that I rather tend to avoid QList.
For more information please re-read.
Kind Regards,
Artur -
Thank you for the explanation - indeed, I saw in docs that value() is const but since it worked for the QString I just... assumed it works anyway. Silly of me.
So, to make it work as intended I should use [index] notation, like @hskoglund said (I am somehow opposed to using it in the favour of methods).
Since I already got everyones involved attention - the QVector (in this case) is supposed to hold less than 20 of items, set once and not being manipulated further. Is the choice of QVector over other container types a valid one? I read about container classes and differences between them and after that I rather tend to avoid QList.
@artwaw said in Trouble assigning value to boolean in the struct:
after that I rather tend to avoid QList.
👍 very good.
If you want to stay in Qt - World, than there are not many other options available.
A simple c/c++ array could be enough for your case?
Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct
Q: What's that?
A: It's blue light.
Q: What does it do?
A: It turns blue. -
@artwaw said in Trouble assigning value to boolean in the struct:
after that I rather tend to avoid QList.
👍 very good.
If you want to stay in Qt - World, than there are not many other options available.
A simple c/c++ array could be enough for your case? -
Now that the OP appears to be happy he is solved, I'd like to say that I am not! :) And would ask for further explanation.
I wrote earlier:
@artwaw said in Trouble assigning value to boolean in the struct:
If const is the cause of the error (and I don't doubt it is) forcurrent.fields.value(ui->editSectionNum->currentIndex()).permanent=(state>0);`why is there no error for
current.fields.value(ui->editSectionNum->currentIndex()).pattern=ui->sectionEdit->text();? That was the OP's query. That's what I don't see, it should produce the same error.
@hskoglund replied
I suspect it's because the
constis only 1 layer deep, i.e. it protects integers and booleans in that struct from being reassigned, but since QStrings are pointers, that const only protects reassignment of the pointer, not what the pointer points to, i.e. QStrings data().I know the
const"is only one level deep". And I don't understand how he comes up with that "the pointer value will be retained but what it points to will be changed".And @Christian-Ehrlicher wrote
In theory it's a temporary so it should compile.
I don't understand either of these. The OP's
structhasQString pattern; bool permanent;I have yet to understand why the
boolcan be altered but not theQString. (Yes, I knowQStrings are stored shared, so what?) They are both members of thestruct. Ifcurrent.fields.value()returns aconstthen neither of them should be alterable, and if it does not both should be alterable.Would somebody care to enlighten me on what exactly is the difference?
-
Now that the OP appears to be happy he is solved, I'd like to say that I am not! :) And would ask for further explanation.
I wrote earlier:
@artwaw said in Trouble assigning value to boolean in the struct:
If const is the cause of the error (and I don't doubt it is) forcurrent.fields.value(ui->editSectionNum->currentIndex()).permanent=(state>0);`why is there no error for
current.fields.value(ui->editSectionNum->currentIndex()).pattern=ui->sectionEdit->text();? That was the OP's query. That's what I don't see, it should produce the same error.
@hskoglund replied
I suspect it's because the
constis only 1 layer deep, i.e. it protects integers and booleans in that struct from being reassigned, but since QStrings are pointers, that const only protects reassignment of the pointer, not what the pointer points to, i.e. QStrings data().I know the
const"is only one level deep". And I don't understand how he comes up with that "the pointer value will be retained but what it points to will be changed".And @Christian-Ehrlicher wrote
In theory it's a temporary so it should compile.
I don't understand either of these. The OP's
structhasQString pattern; bool permanent;I have yet to understand why the
boolcan be altered but not theQString. (Yes, I knowQStrings are stored shared, so what?) They are both members of thestruct. Ifcurrent.fields.value()returns aconstthen neither of them should be alterable, and if it does not both should be alterable.Would somebody care to enlighten me on what exactly is the difference?
-
Now that the OP appears to be happy he is solved, I'd like to say that I am not! :) And would ask for further explanation.
I wrote earlier:
@artwaw said in Trouble assigning value to boolean in the struct:
If const is the cause of the error (and I don't doubt it is) forcurrent.fields.value(ui->editSectionNum->currentIndex()).permanent=(state>0);`why is there no error for
current.fields.value(ui->editSectionNum->currentIndex()).pattern=ui->sectionEdit->text();? That was the OP's query. That's what I don't see, it should produce the same error.
@hskoglund replied
I suspect it's because the
constis only 1 layer deep, i.e. it protects integers and booleans in that struct from being reassigned, but since QStrings are pointers, that const only protects reassignment of the pointer, not what the pointer points to, i.e. QStrings data().I know the
const"is only one level deep". And I don't understand how he comes up with that "the pointer value will be retained but what it points to will be changed".And @Christian-Ehrlicher wrote
In theory it's a temporary so it should compile.
I don't understand either of these. The OP's
structhasQString pattern; bool permanent;I have yet to understand why the
boolcan be altered but not theQString. (Yes, I knowQStrings are stored shared, so what?) They are both members of thestruct. Ifcurrent.fields.value()returns aconstthen neither of them should be alterable, and if it does not both should be alterable.Would somebody care to enlighten me on what exactly is the difference?
@JonB said in Trouble assigning value to boolean in the struct:
If current.fields.value() returns a const then neither of them should be alterable, and if it does not both should be alterable.
Look carefully at what I wrote to Henry. The struct's instance returned by
QVector::valueis not const. It's a temporary (probably the compiler does it as an rvalue), so it's valid to write its members. However the compiler deduces that assigning to the boolean of said temporary is meaningless, thus as @Christian-Ehrlicher eloquently put it - it prevents you from shooting yourself in the foot. When it comes to classes and structs it's more complicated, which we discussed briefly with Christian upstairs.Read and abide by the Qt Code of Conduct
-
@JonB said in Trouble assigning value to boolean in the struct:
If current.fields.value() returns a const then neither of them should be alterable, and if it does not both should be alterable.
Look carefully at what I wrote to Henry. The struct's instance returned by
QVector::valueis not const. It's a temporary (probably the compiler does it as an rvalue), so it's valid to write its members. However the compiler deduces that assigning to the boolean of said temporary is meaningless, thus as @Christian-Ehrlicher eloquently put it - it prevents you from shooting yourself in the foot. When it comes to classes and structs it's more complicated, which we discussed briefly with Christian upstairs.@kshegunov said in Trouble assigning value to boolean in the struct:
instance returned by QVector::value is not const. It's a temporary
Good, got that (was always dubious about whether it was
constanyway).However the compiler deduces that assigning to the boolean of said temporary is meaningless
Ah ha!! Got it! Sooooooooo... what you are saying is: on the one hand we now have a compiler which gets involved in the meaning of life/teleological purpose, yet on the other hand chooses to blurt out "Expression not assignable" as the diagnostic message when it's non-such. "Meaningless assignment", "Assignment with no side-effect" would have been much better, "non-assignable" means e.g. it's
constto me, hence my confusion (and perhaps that of @artwaw).What happened to the days when I wrote code and the compiler knew its place, minded its business and just shut up and compiled?
-
@kshegunov said in Trouble assigning value to boolean in the struct:
instance returned by QVector::value is not const. It's a temporary
Good, got that (was always dubious about whether it was
constanyway).However the compiler deduces that assigning to the boolean of said temporary is meaningless
Ah ha!! Got it! Sooooooooo... what you are saying is: on the one hand we now have a compiler which gets involved in the meaning of life/teleological purpose, yet on the other hand chooses to blurt out "Expression not assignable" as the diagnostic message when it's non-such. "Meaningless assignment", "Assignment with no side-effect" would have been much better, "non-assignable" means e.g. it's
constto me, hence my confusion (and perhaps that of @artwaw).What happened to the days when I wrote code and the compiler knew its place, minded its business and just shut up and compiled?
@JonB said in Trouble assigning value to boolean in the struct:
What happened to the days when I wrote code and the compiler knew its place, minded its business and just shut up and compiled?
They've passed some time ago. The compilers've become smarter than us (developers) so we only can bite the bullet on that one, sorry. I expect soon compilers to be writing compilers, Terminator 2-style ...
-
@kshegunov @Christian-Ehrlicher I have another question: since value() returns const but copy of QString occurs (re my very unfortunate construction with assignment to QString) - will the value assigned to that QString remain in the QVector? My understanding is that not, after terminating the method copy would be discarded and new value lost. Do I understand correctly?
For more information please re-read.
Kind Regards,
Artur -
@kshegunov @Christian-Ehrlicher I have another question: since value() returns const but copy of QString occurs (re my very unfortunate construction with assignment to QString) - will the value assigned to that QString remain in the QVector? My understanding is that not, after terminating the method copy would be discarded and new value lost. Do I understand correctly?
@artwaw said in Trouble assigning value to boolean in the struct:
since value() returns const
It does not return const. It's a non-mutating method, meaning that the vector's contents aren't going to be modified. It returns a copy of the element.
but copy of QString occurs (re my very unfortunate construction with assignment to QString) - will the value assigned to that QString remain in the QVector?
No. You're assigning to a temporary, which is going to be destroyed and assignment will have no observable effect (if the destructor of the class doesn't have side effects, which in this case it doesn't)
My understanding is that not, after terminating the method copy would be discarded and new value lost. Do I understand correctly?
That's correct.
Read and abide by the Qt Code of Conduct
-
@artwaw said in Trouble assigning value to boolean in the struct:
since value() returns const
It does not return const. It's a non-mutating method, meaning that the vector's contents aren't going to be modified. It returns a copy of the element.
but copy of QString occurs (re my very unfortunate construction with assignment to QString) - will the value assigned to that QString remain in the QVector?
No. You're assigning to a temporary, which is going to be destroyed and assignment will have no observable effect (if the destructor of the class doesn't have side effects, which in this case it doesn't)
My understanding is that not, after terminating the method copy would be discarded and new value lost. Do I understand correctly?
That's correct.
@kshegunov Thank you, will remember that.
