Recurring C++ and Qt anti-patterns
-
Imagine clearing some sort of array:
for(type* ptr = some_array; something ; ++ptr) { delete ptr; }Now imagine delete would zero that pointer. Do you see the problem? You would have to make another, temporary, pointer just so you zero the copy and your original doesn't get changed. In other words you're paying for what you don't use or even want. There's also problem of const pointers or pointers that you got from external APIs that do their own bookkeeping and might actually need that pointer value even after delete. It would create more problems than it solves.
-
@fcarney said in Recurring C++ and Qt anti-patterns:
int 🥩=1; int 🧀=1; int 🥬=1; int 🍞=1; int 🍅=1; int 🥪=🥩+🥬+🍅+🧀+🥩; cout << 🥪 << endl;Fails to compile in C++17...
What's this "int" stuff? Doesn't the 17 standard deduce the type based on the rvalue? Not that I think that is necessarily a good thing though.
-
@fcarney said in Recurring C++ and Qt anti-patterns:
int 🥩=1; int 🧀=1; int 🥬=1; int 🍞=1; int 🍅=1; int 🥪=🥩+🥬+🍅+🧀+🥩; cout << 🥪 << endl;Fails to compile in C++17...
What's this "int" stuff? Doesn't the 17 standard deduce the type based on the rvalue? Not that I think that is necessarily a good thing though.
@kent-dorfman said in Recurring C++ and Qt anti-patterns:
🍞
The real problem is this variable is unused.
-
@fcarney said in Recurring C++ and Qt anti-patterns:
The real problem is this variable is unused.
So in 17 unused variables are errors instead of warnings?
-
@kent-dorfman said in Recurring C++ and Qt anti-patterns:
So in 17 unused variables are errors instead of warnings?
No, its just a bug in the code for a samich.
-
@fcarney said in Recurring C++ and Qt anti-patterns:
No, its just a bug in the code for a samich.
Samich... Are you a yinzer?
-
@kent-dorfman said in Recurring C++ and Qt anti-patterns:
Are you a yinzer?
Had to look it up. Based on what I read, no. Not sure where I heard sandwich being called samich though. I am in western USA.
-
Being an a-hole as a recruiter:
What does
o()mean?
What doeso.omean?
What doeso->omean?
What doeso-->omean?
What doeso()--<=>--o()mean? Fun fact - crashes MSVC (yes, the compiler, not the compiled program)
What does[](){;o()++<=>++o();}()mean? -
I had to dig through this thing once, only the real code was like a hundred times longer and more convoluted.
// Library.h statically linked to and included in DLL and EXE struct SomeType { int typeId(); }; Q_DECLARE_METATYPE(SomeType); // Library.cpp int SomeType::typeId() { return qMetaTypeId<SomeType>(); } // main app SomeType& var1 = getItFromDLL(); SomeType& var2 = getItFromEXE(); bool same = var1.typeId() == var2.typeId(); // nopePretty ugly thing to debug, especially since once in blue moon it actually works :/
@chris-kawa said in Recurring C++ and Qt anti-patterns:
I had to dig through this thing once, only the real code was like a hundred times longer and more convoluted.
[Snip]
Pretty ugly thing to debug, especially since once in blue moon it actually works :/Indeed. Although, this is windows specific. It works correctly on Linux as the symbol resolution happens at run time.
-
Being an a-hole as a recruiter:
What does
o()mean?
What doeso.omean?
What doeso->omean?
What doeso-->omean?
What doeso()--<=>--o()mean? Fun fact - crashes MSVC (yes, the compiler, not the compiled program)
What does[](){;o()++<=>++o();}()mean?@chris-kawa wow, some of those you don't encounter every day...
-
Yeah, it was a bit out of topic. Here's one anti-pattern I encounter something like 9/10 code reviews:
auto widget = new SomeWidget(some_widget); auto layout = new SomeLayout(some_other_widget); layout->addWidget(widget);It's not a correctness bug. It's a subtle performance one. Compare this with:
auto widget = new SomeWidget(); auto layout = new SomeLayout(); layout->addWidget(widget); some_other_widget->setLayout(layout);If you don't see it - count how many times parents need to be changed and imagine there's not one but, say, 50 widgets and layouts.
For extra sweetness do the same when the parent widget is visible - how many times layouts need to be recalculated? -
Yeah, it was a bit out of topic. Here's one anti-pattern I encounter something like 9/10 code reviews:
auto widget = new SomeWidget(some_widget); auto layout = new SomeLayout(some_other_widget); layout->addWidget(widget);It's not a correctness bug. It's a subtle performance one. Compare this with:
auto widget = new SomeWidget(); auto layout = new SomeLayout(); layout->addWidget(widget); some_other_widget->setLayout(layout);If you don't see it - count how many times parents need to be changed and imagine there's not one but, say, 50 widgets and layouts.
For extra sweetness do the same when the parent widget is visible - how many times layouts need to be recalculated?@chris-kawa said in Recurring C++ and Qt anti-patterns:
auto widget = new SomeWidget(widget);
I hope this is a typo :-)
-
@chris-kawa said in Recurring C++ and Qt anti-patterns:
auto widget = new SomeWidget(widget);
I hope this is a typo :-)
@jsulm Sure, sorry, fixed :)
-
@chris-kawa said in Recurring C++ and Qt anti-patterns:
It's not a correctness bug. It's a subtle performance one. Compare this with:
It took me a few minutes but ok, I'm convinced... LOL
-
Just created this pattern today:
if(condition == somevalue) somestatement.append(whatever);I forgot the indentation so it didn't look like and if statement.
I I know this is really simple and not an error/bad practice. It is more a readability issue.Going to be more rigorous in the future:
if(condition == somevalue){ somestatement.append(whatever); } -
Well, that one made a big security hole in Apple's authentication code but it was the other way around, several lines under the if without curly brackets.
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
