Recurring C++ and Qt anti-patterns
-
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.
@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".
-
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_wrapperbecause 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"? -
@Chris-Kawa said in Recurring C++ and Qt anti-patterns:
pointers where they make sense
That is the point (hehe) its an extremist group.
-
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!"
-
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_wrapperbecause 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"?@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 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.
-
-
or
If if THEN thenThere 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.
-
One example is using exceptions for control flow or as simply another way to return a value from a function.
@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....
-
@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....
@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::optionalwith if-ery everywhere to handle an error deep in the code. As everything, though, one should apply the very old and tested "common sense" ...Read and abide by the Qt Code of Conduct
-
or
If if THEN thenThere 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.
@Kent-Dorfman I still have C64 (my first computer bought in 1988) and I still use Basic for the fun of it :)
-
@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::optionalwith if-ery everywhere to handle an error deep in the code. As everything, though, one should apply the very old and tested "common sense" ...@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 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....
@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.
Read and abide by the Qt Code of Conduct
-
@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.
@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
dictexception 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.
-
@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
dictexception 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.
@JonB said in Recurring C++ and Qt anti-patterns:
Want to test for a divisor being 0? Don't test it, divide and catch the exception.
oh my goodness, that's like exploding the first atomic bomb without doing the math to check if it would ignite the atmosphere!
(yes, those calculations where done, no matter how silly the idea seems now🙈) -
@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
dictexception 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.
@JonB said in Recurring C++ and Qt anti-patterns:
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.Returning from a function causes stack unwinding; exiting a block causes stack unwinding. So while I see why it may be costly to throw (for example a heavy destructor running), it's hardly costlier than to just return (the little coming from the compiler generating the appropriate exception handling code). So while the quoted argument may seem reasonable to you, even creating an object in Python is already costly, probably more so than the whole throw machinery of C++, so take "expensive" and "cheap" as real relative terms, just like in real life.
Read and abide by the Qt Code of Conduct
-
@JonB said in Recurring C++ and Qt anti-patterns:
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.Returning from a function causes stack unwinding; exiting a block causes stack unwinding. So while I see why it may be costly to throw (for example a heavy destructor running), it's hardly costlier than to just return (the little coming from the compiler generating the appropriate exception handling code). So while the quoted argument may seem reasonable to you, even creating an object in Python is already costly, probably more so than the whole throw machinery of C++, so take "expensive" and "cheap" as real relative terms, just like in real life.
-
@kshegunov
I like this: your claim/view is that Python is so slow in the first place that it can't get much worse with exceptions :)@JonB said in Recurring C++ and Qt anti-patterns:
I like this: your claim/view is that Python is so slow in the first place that it can't get much worse with exceptions :)
No, not exactly. I claim that you should compare things that are comparable to begin with. Python runs in a VM, while C++ runs on metal. It is context that defines the term, and "costly" in C++ terms isn't applicable, or justifiable in python. Think of it like this,
fopencalls into the kernel, do you consider this costly? It can be, if you do it all the time, like opening a file reading a couple of bytes and closing it. But the point is, is this costly? "Well, it depends" is the correct answer. Or, as I mentioned already, islongjmpcostly?What I'm trying to convey is that in python you don't even consider this stuff, because the almighty VM shields you from it, and you can say your exceptions are cheap, which I don't know, they might very well be. But you still pay for the VM, exceptions or no exceptions. On the other hand I can choose to use exceptions where they make sense and pay the handling code price, or I may choose not to in some places and declare things with
noexcept, or I can do what Qt does and disable them altogether.But even when you're talking only C++ it's not absolute. As I stated, and I do stand by it, throwing isn't that much different than unwinding stack frame by stack frame, until you meet the handler. And in C/C++ the stack is king, it's god and spirit and the holy mother, and all that; and it's very fast, and it is hardware supported for a reason. I would hardly believe anyone claiming
pushandpopare coincidences, a technical curiosity if you will. So yeah, unwinding the stack "is as inevitable as the demise of capitalism", but it's done all the time for all reasons, some of which were mentioned, and it is by far a bad reasoning, rotten logic if I may, to say it makes throwing "costly".PS.
That's one of my better missives, if I may be so bold to say so myself. ;P
