Recurring C++ and Qt anti-patterns

Kent-Dorfman

@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?

fcarney

@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.

Chris Kawa

Being an a-hole as a recruiter:

What does o() mean?
What does o.o mean?
What does o->o mean?
What does o-->o mean?
What does o()--<=>--o() mean? Fun fact - crashes MSVC (yes, the compiler, not the compiled program)
What does [](){;o()++<=>++o();}() mean?

kshegunov

@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.

J.Hilk

@chris-kawa wow, some of those you don't encounter every day...

Chris Kawa

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?

jsulm

@chris-kawa said in Recurring C++ and Qt anti-patterns:

auto widget = new SomeWidget(widget);

I hope this is a typo :-)

Chris Kawa

@jsulm Sure, sorry, fixed :)

Kent-Dorfman

@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

fcarney

mtime.toString(tr("M/d/yyyy hh:mm AP"));

aha_1980

Hi @fcarney,

mtime.toString(tr("M/d/yyyy hh:mm AP"));

OMG. Yeah, that's a good (bad) one :)

fcarney

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);
}

SGaist

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.

fcarney

Wow, okay, I take it back. Bad pattern!

aha_1980

@SGaist I've seen GCC 7.3 warning about exactly this problem ("thif if clause ... does not guard ...").

So hopefully such problems will go away sooner than later.

Regards

kshegunov

Nope. It warns if it doesn't actually guard (as if you had put incidentally ; at the end of the if):

if (something)
something else;
something else else; //< Can't warn about that

aha_1980

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);

aha_1980

@kshegunov

What I meant was the following example:

which is already an improvement on poorly formatted code.

Regards

fcarney

Including the wrong header that doesn't match cpp file definition... This is really confusing.

fcarney

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. 😀