Recurring C++ and Qt anti-patterns

fcarney

@Kent-Dorfman
Apparently its a "dependent name":
https://en.cppreference.com/w/cpp/language/dependent_name

I have not taken time to understand it, but there is the "reason".

fcarney

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.

fcarney

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.

Kent-Dorfman

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.

fcarney

@Kent-Dorfman said in Recurring C++ and Qt anti-patterns:

always pointers

We should start an anti-safe coding movement (I say this with disdain for idea of safety, there is nothing safe about systems level coding IMO, or coding in general) . The slogan would be "Always Pointers".

Chris Kawa

I hate to break this to you guys but pointers and references are the same thing. References are just syntax constraint, something like const, so disappointment in this case would be like disappointment that you can't assign to a const value. IMO using std::reference_wrapper because you don't like those naked stars is just silly.
As for "Always Pointers" - why so extreme? How about more mellow party like "pointers where they make sense"?

fcarney

@Chris-Kawa said in Recurring C++ and Qt anti-patterns:

pointers where they make sense

That is the point (hehe) its an extremist group.

Kent-Dorfman

I tend to think of myself as a "moderate extremist": on the surface all agile, type-safe, and scope limiting...but in private I do stuff like macro-ize bitshift operations to save typing. My infatuation with pointers goes toward edumacating the noobs when they try to do large matrix processing using array indexes. It's like "hold my beer while I whack this kid"...and then I say "don't do that!"

kshegunov

@Chris-Kawa said in Recurring C++ and Qt anti-patterns:

IMO using std::reference_wrapper because you don't like those naked stars is just silly.

While I agree with you, it's rather funny (and somewhat ironic) such a class does exist.
The chant "pointers are bad", and even the more extreme "naked pointers are even badder" seems to have crept so ubiquitously into the way code's written (even moved past a fad I'd say) that we need a wrapper object to make assignable something which was designed into the language not to be, instead of simply passing by address ... strange world we live in ...

Bur8rus

One example is using exceptions for control flow or as simply another way to return a value from a function.

Kent-Dorfman

@Bur8rus but...the C++ God himself himself wrote in the sacred texts that exceptions should be looked at as just another flow control route, and to not make any judgements other than that.

While in principle I agree with you, I'm glad my hands are not tied to keep me from committing an abomination like generic flow using exceptions.

fcarney

Heh, bad flow control discussions made me think of one phrase:
goto hell ;-)

Chris Kawa

@fcarney said:

goto hell ;-)

I guess this calls for a classic:

int up;
throw up;

Kent-Dorfman

or

If if THEN then

There once was this home computer language called BASIC, done as a ROM interpretor, that was supported on meager 4KB RAM 8-bit machines. If you wanted to do something quickly then you stuffed your machine code into a preallocated string variable, and then you did a function call like rv=SYS(code$) to execute the machine code directly.

JonB

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

One example is using exceptions for control flow or as simply another way to return a value from a function.

Depressingly, for those of us forced to use Python (with Qt) we are encouraged to use exceptions for flow handling etc. Under the mantra that Python exceptions are different from/more lightweight than C++ exceptions....

kshegunov

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

Depressingly, for those of us forced to use Python (with Qt) we are encouraged to use exceptions for flow handling etc. Under the mantra that Python exceptions are different from/more lightweight than C++ exceptions....

They're not, obviously. However in all fairness exceptions have their place, just not in the way they're abused. I use them for quick escape through the stack in numerical code, where it'd be borderline stupid to sprinkle std::optional with if-ery everywhere to handle an error deep in the code. As everything, though, one should apply the very old and tested "common sense" ...

artwaw

@Kent-Dorfman I still have C64 (my first computer bought in 1988) and I still use Basic for the fun of it :)

JonB

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

They're not, obviously.

I take it that is against my "Python exceptions are different from/more lightweight than C++ exceptions"(?) Well, apparently, this is true. I could (if required) give several references. I guess we cannot assume that a Python exception maps to a C++/OS/native exception....

kshegunov

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

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

They're not, obviously.

I take it that is against my "Python exceptions are different from/more lightweight than C++ exceptions"(?)

Yes, that's correct. More so I was referring to the "lightweight"-ness, not so much about them being different. I could agree if you can show a VM's exception to be lighter than a hardware's stack unwinding, but that's rather dubious. Basically that'd be like saying that Python's exceptions are faster than a C longjmp, arguable at best.

Well, apparently, this is true. I could (if required) give several references.

Eh, fine, amaze me.

I guess we cannot assume that a Python exception maps to a C++/OS/native exception....

Nor had I done that. The underlying tech is different to jump to such a conclusion.

JonB

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

Eh, fine, amaze me.

Well, of course now that you want them I can't find as many clear statements as I have come across in the past :) But we could start with this accepted answer on SO:

In the Python world, using exceptions for flow control is common and normal.

The Python cultural norm is somewhat different. In many cases, you must use exceptions for control-flow. Also, the use of exceptions in Python does not slow the surrounding code and calling code as it does in some compiled languages

In other words, your understanding that "exceptions are for the exceptional" is a rule that makes sense in some other languages, but not for Python.

Or https://stackoverflow.com/a/3743528/489865

If you are using the exception as part of the standard control flow - which is the Pythonic "ask forgiveness, not permission" way

For the "efficiency" question, although this may not be the post I had in mind I find in https://softwareengineering.stackexchange.com/a/351121

The general consensus “don't use exceptions!” mostly comes from other languages and even there is sometimes outdated.
In C++, throwing an exception is very costly due to “stack unwinding”.
So in those languages exceptions are “too expensive” to be used as control flow. In Python this is less of an issue and exceptions are a lot cheaper.

In Python, if I want to know if a key is in a dictionary the "Pythonic" way is

try:
    abc = dict["key"]
except:
    ...

utilizing dict exception throwing on non-existent key rather than testing for existence....

Want to test for a divisor being 0? Don't test it, divide and catch the exception.

Am I good Python citizen? Am I, heck no! If nothing else, it gets in the way of having the choice to break on any exception in a debugger.