Re: [Interest] Warning about QHash keys().toVector()
On Sun, Jun 13, 2021 at 06:20:31PM +0200, Kevin André wrote:
> Hi,
>
> I have the following piece of code:
>
> QVector CompatibilityInterfaceImpl::getActionIds() const
> {
> return _actions.keys().toVector(); // _actions is a QHash
> }
>
> In Qt Creator this generates the following warning:
>allocating an unneeded temporary container [clazy-container-anti-pattern]
>
> How can I avoid the warning in this case?
>
> I am using Qt 5.12, so I return a QVector instead of a QList because
> using the old (Qt 5) QList is discouraged. Unfortunately many Qt API's
> still use QList for nearly everything, so I am faced with a difficult
> choice:
>
> 1) go back to using QList
That would be my advice.
While QList never was the atrocity some people wanted us to believe [1],
you actually have one of the rare cases here were Q(5)Vector really
takes less memory than Q(5)List on 64bit machines, roughly 4 bytes
times the number of items in your _actions container.
But given that your application is apparently fine with using QHash::keys
here it is safe to say that you will not observe any difference.
Andre'
[1]
https://lists.qt-project.org/pipermail/development/attachments/20200425/8b0cca64/attachment.mht
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] QNetwork classes for submitting google forms
On 6/13/2021 1:08 PM, Thiago Macieira wrote: That was a toy example application. Most applications will post in event to something happening, so the event loop has already started. But we weren't discussing "most applications." The OP asked how to handle a network request and presented an MRE. Or are you saying I should have written a full app for them? Are you like this on StackOverflow also? In the particular you need app.exec(). You mean like my second working example? I appreciate your pointing out my mistake (several hours after I corrected it) and the general warning about sleeping, but now the horse is already dead. Don't use processEvents(). That's only slightly less evil than sleep(). Maybe you could expand on that further instead of just making blanket statements? Reference? The reference is the source code. Huh? In the source code somewhere it says "don't use processEvents()?" Seems maybe that belongs in the docs... :) I understand what it means to read the source to see how something works, but I'm not sure how that applies here. QEventLoop calls processEvents for you, but it also reacts to quit() and other event-interruption mechanisms, as well as interrupt-prevention mechanisms. If you call processEvents() on your own, you have to provide your own mechanism. Many an application got stuck calling processEvents() after being asked to exit that loop. If you think you need to exclude UI events, you're wrong. If you think you want to process a limited number of events (especially "just one"), you're wrong. Thanks for elaborating. So the actual answer/advice is to use processEvents() _correctly_ (or QEventLoop which "autmagically" does the "right thing" for you... read its the code to see what that is). Which is certainly a valid point. I will amend any future mention if it with a big *"when used correctly" footnote instead of assuming that someone would already do that in the first place. Is the condescending tone really necessary to get your point across? Regards, -Max ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Warning about QHash keys().toVector()
On Sun, Jun 13, 2021 at 7:22 PM Kevin André wrote: > How can I avoid the warning in this case? > return QVector<..>(_actions.keyBegin(), _actions.keyEnd()); Should work, I believe. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Warning about QHash keys().toVector()
On Sunday, 13 June 2021 09:20:31 PDT Kevin André wrote:
> I have the following piece of code:
>
> QVector CompatibilityInterfaceImpl::getActionIds() const
> {
> return _actions.keys().toVector(); // _actions is a QHash
> }
>
> In Qt Creator this generates the following warning:
>allocating an unneeded temporary container [clazy-container-anti-pattern]
>
> How can I avoid the warning in this case?
Create the QVector container, reserve the proper size, and then iterate over
the actions hashing table inserting the keys.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel DPG Cloud Engineering
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] QNetwork classes for submitting google forms
On Sunday, 13 June 2021 08:23:30 PDT Max Paperno wrote: > > Please do as I said: insert a return and let the event loop handle calling > > your slots. > > Did you even look at the (bad) code in question? There was no event loop > and nothing to return from except main(). That was a toy example application. Most applications will post in event to something happening, so the event loop has already started. In the particular you need app.exec(). > > Don't use processEvents(). That's only slightly less evil than sleep(). > > Maybe you could expand on that further instead of just making blanket > statements? Reference? The reference is the source code. QEventLoop calls processEvents for you, but it also reacts to quit() and other event-interruption mechanisms, as well as interrupt-prevention mechanisms. If you call processEvents() on your own, you have to provide your own mechanism. Many an application got stuck calling processEvents() after being asked to exit that loop. If you think you need to exclude UI events, you're wrong. If you think you want to process a limited number of events (especially "just one"), you're wrong. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Warning about QHash keys().toVector()
Hi,
I have the following piece of code:
QVector CompatibilityInterfaceImpl::getActionIds() const
{
return _actions.keys().toVector(); // _actions is a QHash
}
In Qt Creator this generates the following warning:
allocating an unneeded temporary container [clazy-container-anti-pattern]
How can I avoid the warning in this case?
I am using Qt 5.12, so I return a QVector instead of a QList because
using the old (Qt 5) QList is discouraged. Unfortunately many Qt API's
still use QList for nearly everything, so I am faced with a difficult
choice:
1) go back to using QList
2) deal with warnings and/or write my own conversion functions that
are probably not very efficient
Or is there another (convenient) way to solve this that I am not aware of?
Migrating to Qt 6 is not an option right now.
Thanks,
Kevin
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] More on table problem
>
>>> On Fri, Jun 11, 2021 at 10:05 AM Volker Hilsheimer
>>> wrote:
>>> > On 11 Jun 2021, at 13:52, Turtle Creek Software
>>> > wrote:
>>> >
>>> > Here's more info on the weird QTableWidget problem we're seeing.
>>> >
>>> > One of our data entry fields uses combination of widgets: a QLineEdit
>>> > subclass with a linked QToolButton subclass next to it, and a QListWidget
>>> > subclass that drops down underneath. It acts kinda like a combo box, but
>>> > better for really long lists. The whole assembly works properly in
>>> > regular data entry screens. Clicking on button or list changes values in
>>> > the line edit field.
>>> >
>>> > We use setCellWidget to put the same QLineEdit subclass into a
>>> > QTableWidget cell. The button and list appear properly, but the button
>>> > does not catch mouse clicks. They go to the cell behind the button
>>> > instead.
>>> >
>>> > We use signals/slots to connect the clicked signal, but don't fiddle with
>>> > events otherwise.
>>> >
>>> > Casey McD
>>>
>>>
>>> This works fine:
>>>
>>> #include
>>>
>>> class CellWidget : public QWidget
>>> {
>>> public:
>>> CellWidget()
>>> {
>>> QLineEdit *le = new QLineEdit;
>>> QToolButton *tb = new QToolButton;
>>> QMenu *toolMenu = new QMenu;
>>> toolMenu->addAction(new QAction("Action 1", this));
>>> toolMenu->addAction(new QAction("Action 2", this));
>>> toolMenu->addAction(new QAction("Action 3", this));
>>> tb->setPopupMode(QToolButton::InstantPopup);
>>> tb->setMenu(toolMenu);
>>>
>>> QHBoxLayout *hbox = new QHBoxLayout;
>>> hbox->addWidget(le);
>>> hbox->addWidget(tb);
>>> setContentsMargins(0, 0, 0, 0);
>>> hbox->setContentsMargins(0, 0, 0, 0);
>>>
>>> setLayout(hbox);
>>> }
>>>
>>> QSize minimumSizeHint() const { return QSize(100, 100); }
>>> };
>>>
>>> int main(int argc, char **argv)
>>> {
>>> QApplication app(argc, argv);
>>>
>>> QTableWidget table(10, 10);
>>> table.setCellWidget(5, 5, new CellWidget);
>>>
>>> table.show();
>>>
>>> return app.exec();
>>> }
>>>
>>>
>>> Volker
>>
>> On 11 Jun 2021, at 17:51, Turtle Creek Software
>> wrote:
>>
>> If I understand this code correctly, it's putting the button inside the
>> cell. Unfortunately, there isn't enough room to do that.
>> The table only shows the QLineEdits. When you click in a cell to edit, the
>> button appears next to it, over the neighboring cell(s).
>> However, maybe there is a container we can put the button into, that will
>> act as a click barrier. Something less extreme than a dialog.
>> Casey McD
Make sure you create whatever widget you create for editing cells either via an
item delegate, e.g.
https://doc.qt.io/qt-5/qabstractitemdelegate.html#createEditor
But that’s not the same as using setCellWidget, and indeed, QTableView will
want to fit the editor widget into the cell, and while you can set a minimum
width to make the widget reach beyond the cell, that will not work great on the
edge of the table.
If you do something completely custom, then make sure you create child widgets
as children of the viewport() of QTableWidget, even if they are popups.
> On 11 Jun 2021, at 18:18, Turtle Creek Software
> wrote:
>
> I tried putting the button inside a QFrame, but it has the same problem.
> Casey McD
Feel free to modify my example to show how and when you are setting up those
widgets. Otherwise it’s unlikely that we’ll ever end up with the same
configuration.
Volker
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] QNetwork classes for submitting google forms
On 6/13/2021 11:02 AM, Thiago Macieira wrote: On Friday, 11 June 2021 21:05:08 PDT Max Paperno wrote: Insert a "return" here and let your slot be called when the time is right. Right, too much Python lately... "should" have been `processEvents()` which is when I realized there were no events to process w/out a Qt loop in the first place. Returning from main() wouldn't have solved the issue though. Please do as I said: insert a return and let the event loop handle calling your slots. Did you even look at the (bad) code in question? There was no event loop and nothing to return from except main(). Don't use processEvents(). That's only slightly less evil than sleep(). Maybe you could expand on that further instead of just making blanket statements? Reference? -Max ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QNetwork classes for submitting google forms
On Friday, 11 June 2021 21:05:08 PDT Max Paperno wrote: > > Insert a "return" here and let your slot be called when the time is right. > > Right, too much Python lately... "should" have been `processEvents()` > which is when I realized there were no events to process w/out a Qt loop > in the first place. Returning from main() wouldn't have solved the > issue though. Please do as I said: insert a return and let the event loop handle calling your slots. Nested event loops are an anti-pattern. Don't write code like that unless you really must. And if you do, use QEventLoop. Don't use processEvents(). That's only slightly less evil than sleep(). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
