Recurring C++ and Qt anti-patterns
-
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 :-)
-
@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.
-
OMG
QString CharToString(char *str) { QString result = ""; int lengthOfString = strlen(str); QString s; for(int i = 0; i < lengthOfString; i++) { s = QString("%1").arg(str[i], 0, 16); if(s.length() == 1) result.append("0"); result.append(s); } return result; }
There are multiple anti-patterns in that function (who finds all?!), but basically the solution is to use:
QString s = QByteArray::toHex(str);
-
What I meant was the following example:
which is already an improvement on poorly formatted code.
Regards
-
Hmmm... I have just found some icky syntax that makes me think it is an anti-pattern just cause its icky:
#include <vector> template <class T> class IteratorClass { public: std::vector<int>::iterator end(); // neat syntax std::vector<T>::iterator end2(); // error, needs typename typename std::vector<T>::iterator begin(); // really? this is getting ugly using retIterator = typename std::vector<T>::iterator; // ugly typedef typename std::vector<T>::iterator retIterator; // fugly private: std::vector<T> m_data; };
Got stuck on this last night and just couldn't figure out why the simplest syntax would not work with templates. My IDE even told me I needed "typename" and I kept trying "typedef" (💩). Yeah, it was not a good time to be coding, so I went to bed. 😀
-
@fcarney said in Recurring C++ and Qt anti-patterns:
std::vector<T>::iterator end2(); // error, needs typename
Yeah, this being an error (inside a template definition) really bugs me as well.
I'm sure there is a perfectly good brainiac reason it barfs, but I could really see myself wanting to do something like this, as "end2" instead of end2()
-
@Kent-Dorfman
Apparently its a "dependent name":
https://en.cppreference.com/w/cpp/language/dependent_nameI have not taken time to understand it, but there is the "reason".
-
I think I may need to stop coding in the evening. I ran into a weird bug that I cannot duplicate today:
#include <vector> template<class T> class SomeObject { using Storage = std::vector<T>; public: SomeObject(size_t len){ m_data.resize(len); } size_t getSize(){ return m_data.size(); } private: Storage m_data; }; class UsesSomeObject { public: UsesSomeObject() : m_someval(0) , m_somedata(128) // if not initialized the whole object was spitting out weird data { } private: int m_someval; SomeObject<int> m_somedata; };
I don't know if this had anything to do with templates or not. I was working with one at the time. There is a comment in the above code about not initializing m_somedata. I didn't have a default constructor or maybe it created one for me (not sure). Accessing the vector internal to the class had all sorts of "interesting" behavior. Then when I realized my error everything started working fine. It was just a very sneaky issues. However, on my compiler at work it is not letting me compile this. So I am not sure of the situation where it would let me compile this. Maybe if it creates its own default constructor. The lesson is make sure everything is getting initialized before using them!
I will check tonight to see if I can simplify the actual condition that caused this. It was quite interesting and the errors didn't match the source of the problem.
-
Not an antipattern, just disappointing. I cannot do this:
std::vector<float&> frefs;
I know why. I know you can use std::reference_wrapper, but it is kinda messy to me.
-
I guess I don't have a problem with it because in the cases where I might ever consider such an abomination there are always pointers...yes, always pointers.