Returning C++ references from more programming interfaces?
-
wrote on 24 Oct 2018, 13:03 last edited by VRonin
m_value = md;
So what's the advantage of using a reference if you still call the assignment operator (that would trigger a copy)? and what's the difference between your
modifyand mysetValue? -
m_value = md;
So what's the advantage of using a reference if you still call the assignment operator (that would trigger a copy)? and what's the difference between your
modifyand mysetValue?wrote on 24 Oct 2018, 14:42 last edited by… and what's the difference between your
modifyand mysetValue?I omitted an equality check in my example.
But I guess that this implementation detail distracts from the original issue of my feature request here.Would you like to adjust programming interfaces around container class variants any further?
-
To put it into prospective, let's assume we have something like this and let's assume
intis not super cheap to copy, just for argument sake:class Example : public QObject{ Q_OBJECT public: explicit Example(QObject* parent = nullptr) : QObject(parent), m_value(0) {} const int& value() const {return m_value;} void setValue(const int& val){ if(m_value==val) return; m_value=val; valueChanged(m_value); } signals: void valueChanged(int val); private: int m_value; };How would you structure something like
int& value() {return m_value;}that assures you the signalvalueChangedis emitted in case the reference is changed?wrote on 24 Oct 2018, 15:09 last edited byYou didn't answer
@VRonin said in Returning C++ references from more programming interfaces?:
How would you structure something like int& value() {return m_value;} that assures you the signal valueChanged is emitted in case the reference is changed?
-
You didn't answer
@VRonin said in Returning C++ references from more programming interfaces?:
How would you structure something like int& value() {return m_value;} that assures you the signal valueChanged is emitted in case the reference is changed?
wrote on 24 Oct 2018, 16:11 last edited byYou didn't answer
I suggest to distinguish the update scope and the actor which should trigger the desired change notification (by a specific function call).
Another software design option would be the use of a corresponding class, wouldn't it?Example demo1; struct notifier { Example& ex; notifier(Example& target, int input) : ex(target) { ex[0] = input; } ~notifier() { ex.valueChanged(); } } demo2(demo1, 123); -
You didn't answer
I suggest to distinguish the update scope and the actor which should trigger the desired change notification (by a specific function call).
Another software design option would be the use of a corresponding class, wouldn't it?Example demo1; struct notifier { Example& ex; notifier(Example& target, int input) : ex(target) { ex[0] = input; } ~notifier() { ex.valueChanged(); } } demo2(demo1, 123);@elfring, so you want programmers to replace Code 1 with Code 2; have I understood you correctly?
//====== // Code 1 //====== Example demo1; demo1.setData(123); // Automatically emits valueChanged() immediately //====== // Code 2 //====== Example demo1; notifier demo2(demo1, 123); // valueChanged() is emitted when demo2 is destroyedI must say that Code 1 is a much more elegant and intuitive than Code 2.
-
@elfring, so you want programmers to replace Code 1 with Code 2; have I understood you correctly?
//====== // Code 1 //====== Example demo1; demo1.setData(123); // Automatically emits valueChanged() immediately //====== // Code 2 //====== Example demo1; notifier demo2(demo1, 123); // valueChanged() is emitted when demo2 is destroyedI must say that Code 1 is a much more elegant and intuitive than Code 2.
wrote on 25 Oct 2018, 05:20 last edited byso you want programmers to replace Code 1 with Code 2; …
Not really. - I suggest to choose between available software design options.
The standard behaviour of the function “QStandardItem::setData” is generally fine.
The software situaton might look different if more reference-returning functions from a container class like QVector will be taken into account.
A need can evolve to call the function “valueChanged” (or “dataChanged”) in a C++ destructor, can't it? -
@elfring said in Returning C++ references from more programming interfaces?:
so you want programmers to replace Code 1 with Code 2; …
Not really. - I suggest to choose between available software design options.
OK.
The standard behaviour of the function “QStandardItem::setData” is generally fine.
I'm glad you think it's generally fine.
The software situaton might look different if more reference-returning functions from a container class like QVector will be taken into account.
I already explained above why QStandardItem must not provide a reference to is internal data. Do you understand that explanation?
A need can evolve to call the function “valueChanged” (or “dataChanged”) in a C++ destructor, can't it?
No, it can't. The signal should be emitted immediately when the data is changed. It should not wait for the destructor of another struct/object.
-
@elfring said in Returning C++ references from more programming interfaces?:
so you want programmers to replace Code 1 with Code 2; …
Not really. - I suggest to choose between available software design options.
OK.
The standard behaviour of the function “QStandardItem::setData” is generally fine.
I'm glad you think it's generally fine.
The software situaton might look different if more reference-returning functions from a container class like QVector will be taken into account.
I already explained above why QStandardItem must not provide a reference to is internal data. Do you understand that explanation?
A need can evolve to call the function “valueChanged” (or “dataChanged”) in a C++ destructor, can't it?
No, it can't. The signal should be emitted immediately when the data is changed. It should not wait for the destructor of another struct/object.
wrote on 25 Oct 2018, 08:32 last edited byDo you understand that explanation?
I can follow software development concerns (which were expressed here) to some degree.
The signal should be emitted immediately when the data is changed.
This expectation is also generally fine.
It should not wait for the destructor of another struct/object.
The available programming interfaces support to call desired functions in C++ destructors. You can choose under which circumstances such a software design approach will be appropriate.
-
Do you understand that explanation?
I can follow software development concerns (which were expressed here) to some degree.
The signal should be emitted immediately when the data is changed.
This expectation is also generally fine.
It should not wait for the destructor of another struct/object.
The available programming interfaces support to call desired functions in C++ destructors. You can choose under which circumstances such a software design approach will be appropriate.
@elfring said in Returning C++ references from more programming interfaces?:
I can follow software development concerns (which were expressed here) to some degree.
That's good. So please address those concerns. For example, why should Qt provide extensions that break encapsulation and increase the risk of errors?
The signal should be emitted immediately when the data is changed.
This expectation is also generally fine.
Good.
It should not wait for the destructor of another struct/object.
The available programming interfaces support to call desired functions in C++ destructors. You can choose under which circumstances such a software design approach will be appropriate.
I cannot see any circumstance where such a software design approach will be appropriate.
-
@elfring said in Returning C++ references from more programming interfaces?:
I can follow software development concerns (which were expressed here) to some degree.
That's good. So please address those concerns. For example, why should Qt provide extensions that break encapsulation and increase the risk of errors?
The signal should be emitted immediately when the data is changed.
This expectation is also generally fine.
Good.
It should not wait for the destructor of another struct/object.
The available programming interfaces support to call desired functions in C++ destructors. You can choose under which circumstances such a software design approach will be appropriate.
I cannot see any circumstance where such a software design approach will be appropriate.
wrote on 26 Oct 2018, 09:11 last edited byFor example, why should Qt provide extensions that break encapsulation and increase the risk of errors?
I suggest to use algorithms which can work together with container classes at more source code places.
-
For example, why should Qt provide extensions that break encapsulation and increase the risk of errors?
I suggest to use algorithms which can work together with container classes at more source code places.
@elfring said in Returning C++ references from more programming interfaces?:
For example, why should Qt provide extensions that break encapsulation and increase the risk of errors?
I suggest to use algorithms which can work together with container classes at more source code places.
You did not address any of the concerns. You only added suggestions.
That is not acceptable. You must only submit ideas/proposals that don't break encapsulation.
26/27