- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Oh, how I love my PLC's. You have to explicitly convert between integers and floats. If you don't, it doesn't crash, the float just has a wildly different value than what you would expect.
Always fun to point out to the younger generation that 4 and 4.0 are completely different beasts.
Admin
I used to have a coworker who learned to program in VB, and so apparently got in the habit of wanting everything to be a string. Dates, numbers, everything gets turned into a string. He also got so in the habit of needing to call toString on everything that he would even do it on things that are already strings.
Admin
I "grew up" on VB then VB.net then C# and I never felt such urges. I feelit might be more a WebDev thin,/habit, because everything has(had) to be serialized/deserialized?
Admin
I have a feeling the web would be 1000x faster if every function call didn't marshal data into/out of JSON twelve times.
Admin
Try that in Ada and she'll bind you and whip you.
Admin
It's not a habit of VB programmers so much as a habit of bad programmers. At least yuio CAN force types, unlike some client-side scripting I could name....
Admin
Errors for narrowing conversions are silly. Almost everything which isn't just copying narrows. For example, if a, b, and c are of the same data type, a = b + c narrows. If they are 8 bit signed numbers, the range of b + c is -256 to 254 which does not fit into -128 to 127. In contrast, some operations are harmless when narrowed. For example, a = b & 0x7f is guaranteed to not lose any bits of value if a is 8 bits regardless of how wide b is.
Admin
The second half is correct, but in C and C++ (exception: C++20/23, where 2-s complement is required), if the calculated value is signed and strays outside the stated range of a signed integer of its width, the result is undefined behaviour. Conclusion: if they are the same signed type,
a = b+cdoes not narrow.And it doesn't narrow anyway even for unsigned values, because the type under which the calculation is made is the same as
bandc, so there is simply an overflow.Admin
Actually in C/C++, it's a little more nuanced then that.
Due to the usual arithmetic conversions, both of the values
bandcin a binary operator expression likeb + care promoted tointif they're smaller than anintbefore performing the addition. So ifais also a byte, then the assignment ina = b + cperforms a narrowing conversion fromintback down to the smaller type.If you're using larger types to start with and you overflow the 32-bit (or larger) type, then you're absolutely correct that the signed integer overflow is UB.
Admin
It may not narrow in the sense that narrowing is a specific technical term for C and C++, but this is in the context of a compiler warning about narrowing, which is presumably motivated by the inability of narrowing to preserve all possible values. So it narrows in the sense that the full result cannot be represented - only fewer bits. The exact rules for what happens when the result cannot be respresented are irrelevant because the language already defines narrowing conversions, so the warning must be operating outside the language and seeking to add some additional restriction.
Admin
I've used the VB/C# Roslyn converter to translate between dot Net and dot Net for something like 100, 000 lines of code. (And my eyes bled whilst I scrolled through them).
There are multiple horrible problems, from stringification to "accidental" implicit re-typing to the utter horror of the original VB4 Collection being a heterogeneous pseudo-dictionary thing to ... ugh, my eyes are bleeding again.
For them that wants it, I recommend https://github.com/icsharpcode/CodeConverter
Admin
For our Fortran code base we have the rule to always explicitly write double precision literals
instead of either integer or single precision
due to precision bugs caused by use of single precision literals. Though it has become a bit of cargo culty, since this will be an issue for 0.1, but should never be an issue for integers.
Then again, I guess some compiler might interprete things weirdly... As I understand the Fortran standard doesn't even require short circuit evaluation of boolean expressions...
Admin
Re the comment in the article about "sane" defaults, the problem is that it doesn't enable Option Strict by default. The code in the WTF wouldn't compile under Option Strict due to the implicit conversions between Integer and String.
I make a habit of turning on Option Strict in anything new, but code written without it (even working code) can be a real pain to bring into compliance.
Admin
Exactly so. Sensible VB programmers instead developed the habit of typing Option Strict and Option Explicit at the beginning of every module, because they wanted the computer to help find any errors of logic or typing that they made.