Recurring C++ and Qt anti-patterns
-
@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:
try:
abc = dict["key"]
except:Isn't pythonic way
if "key" in dict: ...?!
-
@JonB said in Recurring C++ and Qt anti-patterns:
try:
abc = dict["key"]
except:Isn't pythonic way
if "key" in dict: ...?!
@jsulm
No, the whole point is that the "Pythonic" way is precisely to gotry ... exceptinstead of checking viain, that's my point! Same with division by 0, and other cases. This is Python's "Ask for forgiveness, not for permission" philosophy. Note that personally I wroteAm 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.
:)
-
@jsulm
No, the whole point is that the "Pythonic" way is precisely to gotry ... exceptinstead of checking viain, that's my point! Same with division by 0, and other cases. This is Python's "Ask for forgiveness, not for permission" philosophy. Note that personally I wroteAm 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:
Same with division by 0, and other cases.
Out of curiosity: How does python handle that, because as far as I know (I don't really know that much, but bear with me for a second) there's no (strong) typing and while dividing by int(0) is invalid, division by double(0) is valid?
Read and abide by the Qt Code of Conduct
-
@JonB said in Recurring C++ and Qt anti-patterns:
Same with division by 0, and other cases.
Out of curiosity: How does python handle that, because as far as I know (I don't really know that much, but bear with me for a second) there's no (strong) typing and while dividing by int(0) is invalid, division by double(0) is valid?
@kshegunov
I am just reporting that the "Pythonic" way to do division, where the divisor might be zero, is to do the divide unconditionally and catch the exception. As soon as I see "Pythonic" I tend to ignore it, and do what I'd do in C++ instead, but that's just me :)What I can show you is the following output:
>>> z = 1 / 0 Traceback (most recent call last): File "<stdin>", line 1, in <module> ZeroDivisionError: division by zero >>> z = 1.5 / 0.0 Traceback (most recent call last): File "<stdin>", line 1, in <module> ZeroDivisionError: float division by zero >>>So you get a
ZeroDivisionErroreither way (which you could catch in atry ... except ZeroDivisionError), though by the look of it the error message distinguishes between plaindivision by zeroversusfloat division by zero:) -
@kshegunov
I am just reporting that the "Pythonic" way to do division, where the divisor might be zero, is to do the divide unconditionally and catch the exception. As soon as I see "Pythonic" I tend to ignore it, and do what I'd do in C++ instead, but that's just me :)What I can show you is the following output:
>>> z = 1 / 0 Traceback (most recent call last): File "<stdin>", line 1, in <module> ZeroDivisionError: division by zero >>> z = 1.5 / 0.0 Traceback (most recent call last): File "<stdin>", line 1, in <module> ZeroDivisionError: float division by zero >>>So you get a
ZeroDivisionErroreither way (which you could catch in atry ... except ZeroDivisionError), though by the look of it the error message distinguishes between plaindivision by zeroversusfloat division by zero:)@JonB said in Recurring C++ and Qt anti-patterns:
As soon as I see "Pythonic" I tend to ignore it, and do what I'd do in C++ instead, but that's just me
You're a wise man ... ;)
What I can show you is the following output
Thanks, curiosity satisfied. So python just raises an exception even if dividing by a double(0) is a valid operation. Fair enough.
Read and abide by the Qt Code of Conduct
-
@JonB said in Recurring C++ and Qt anti-patterns:
As soon as I see "Pythonic" I tend to ignore it, and do what I'd do in C++ instead, but that's just me
You're a wise man ... ;)
What I can show you is the following output
Thanks, curiosity satisfied. So python just raises an exception even if dividing by a double(0) is a valid operation. Fair enough.
@kshegunov
I don't want to get into a debate (I know what you're like :) ), and I do know about floating point numbers being approximate representations (though zero/0.0does have an exact representation), but (IMHO!) it is only in your physics/quantum mechanics area that "dividing by a double(0) is a valid operation" (the area where you can magic-away infinities and so on!). In a program it is not. (What have I let myself in for...!) -
@kshegunov
I don't want to get into a debate (I know what you're like :) ), and I do know about floating point numbers being approximate representations (though zero/0.0does have an exact representation), but (IMHO!) it is only in your physics/quantum mechanics area that "dividing by a double(0) is a valid operation" (the area where you can magic-away infinities and so on!). In a program it is not. (What have I let myself in for...!)@JonB said in Recurring C++ and Qt anti-patterns:
I know what you're like
Hey! Words can hurt, you know! ;)
though zero/0.0 does have an exact representation
Yes, actually two representations, as with the actual zero. You have +0.0 and -0.0.
it is only in your physics/quantum mechanics area that "dividing by a double(0) is a valid operation"
Eh, I didn't write the IEEE standard. Take your beef with prof. Kahan.
In a program it is not
Actually if you look through the
math.himplementations you're going to see a lot of handling for such cases. For example the people who wrote them had the decency to actually handle these special cases likelog(0)returning-inf. While I agree it's not often useful to divide by zero it sometimes can be, so that's the reason to handle it like that, I assume.Read and abide by the Qt Code of Conduct
-
@JonB said in Recurring C++ and Qt anti-patterns:
I know what you're like
Hey! Words can hurt, you know! ;)
though zero/0.0 does have an exact representation
Yes, actually two representations, as with the actual zero. You have +0.0 and -0.0.
it is only in your physics/quantum mechanics area that "dividing by a double(0) is a valid operation"
Eh, I didn't write the IEEE standard. Take your beef with prof. Kahan.
In a program it is not
Actually if you look through the
math.himplementations you're going to see a lot of handling for such cases. For example the people who wrote them had the decency to actually handle these special cases likelog(0)returning-inf. While I agree it's not often useful to divide by zero it sometimes can be, so that's the reason to handle it like that, I assume.@kshegunov said in Recurring C++ and Qt anti-patterns:
You have +0.0 and -0.0
The next time someone asks how much money I have in my pocket I will remember to give this answer.
I have $123.45 to give away. I want to hand each person $0.00. How many people do I need to meet to get rid of all my cash? :)
-
@kshegunov said in Recurring C++ and Qt anti-patterns:
You have +0.0 and -0.0
The next time someone asks how much money I have in my pocket I will remember to give this answer.
I have $123.45 to give away. I want to hand each person $0.00. How many people do I need to meet to get rid of all my cash? :)
Here: https://en.wikipedia.org/wiki/Riemann_series_theorem
Knock yourself out ... ;P -
Be careful with not doing things the pythonic way in python. A lot of the time doing it the pythonic way leverages the internals of the language. In other words it pushes the execution from the interpreter to the built in methods that are written in C. So it can have an effect on performance. I don't think the exception example does this though. There may be other reasons I am not aware of.
-
wait a cotton pickin minute! there is no explicit cast to double in python so the x/double(0) argument is invalid on that basis alone...and x/float(0) behaves as expected.
-
@fcarney said in Recurring C++ and Qt anti-patterns:
Uncomfortable admission:
I wrote windows specfic code today...We feel for you :D
-
Here is a nice QML anti-pattern:
Column { Rectangle { height: parent.height } }This one was "fun". Yeah, it doesn't necessarily detect the loop and it locks up the desktop (Gnome). So you have to kill the process manually from a terminal outside of the desktop (ctrl-alt-f4).
C++ is a perfectly valid school of magic.
-
Here is a nice QML anti-pattern:
Column { Rectangle { height: parent.height } }This one was "fun". Yeah, it doesn't necessarily detect the loop and it locks up the desktop (Gnome). So you have to kill the process manually from a terminal outside of the desktop (ctrl-alt-f4).
-
From https://forum.qt.io/topic/113223/check-whether-a-script-exists-by-script-name/14
QProcess process; process.setStandardOutputFile(QProcess::nullDevice()); if (!process.startDetached(progName, args)) ...Would anyone care to comment on why C++ allows calling a static method off an instance without (seemingly) offering the option of a warning message for it? :) (C# doesn't let me write this.)
-
AFAIK, there's nothing wrong with that. It's just that in the case you are showing, the static method has a specific behaviour that makes it unsuitable to be called like that.
-
From https://forum.qt.io/topic/113223/check-whether-a-script-exists-by-script-name/14
QProcess process; process.setStandardOutputFile(QProcess::nullDevice()); if (!process.startDetached(progName, args)) ...Would anyone care to comment on why C++ allows calling a static method off an instance without (seemingly) offering the option of a warning message for it? :) (C# doesn't let me write this.)
@JonB said in Recurring C++ and Qt anti-patterns:
Would anyone care to comment on why C++ allows calling a static method off an instance without (seemingly) offering the option of a warning message for it? :) (C# doesn't let me write this.)
Because the class is known and that's all that matters. Whether you call it through an object or with its qualified name makes no difference. Actually, there's one widespread use of that in the Qt documentation:
int main(int argc, char *argv[]) { QApplication app(argc, argv); return app.exec(); // QCoreApplication::exec is static }Read and abide by the Qt Code of Conduct
-
@JonB said in Recurring C++ and Qt anti-patterns:
Would anyone care to comment on why C++ allows calling a static method off an instance without (seemingly) offering the option of a warning message for it? :) (C# doesn't let me write this.)
Because the class is known and that's all that matters. Whether you call it through an object or with its qualified name makes no difference. Actually, there's one widespread use of that in the Qt documentation:
int main(int argc, char *argv[]) { QApplication app(argc, argv); return app.exec(); // QCoreApplication::exec is static }@kshegunov
But that is not my point/question. Which is: this piece of code is not the first (or the last) where someone has mistakenly written this. If C++ wants it this way, would it not be a good idea by now for compilers to offer a warning option? There is reason that e.g. C# does not allow it.
