11–20 of 31 posts
I.e., use a double parameter that specifies seconds, instead of an uint32_t that specifies milliseconds. This can have surprising and sometimes unpleasant consequences; see https://0.30000000000000004.com
Except for: "OMG-API-3: Unsigned integers are preferred over signed".. I feel they're on the wrong side of history with this one.
"Prefer unsigned" only works if you can do 99% of your codebase this way, which, besides LLVM, probably doesn't work for anyone. Having a codebase that is 99% signed is much more feasible. The worst is a codebase with plenty of both, which will be guaranteed endless subtle bugs and/or a ton of casts. That's what they'll end up with.
Apparently the C++ committee agrees that size_t being unsigned was a huge mistake (reference needed), and I would agree. Related discussion: https://github.com/ericniebler/stl2/issues/182 https://github.com/fish-shell/fish-shell/issues/3493 https://wesmckinney.com/blog/avoid-unsigned-integers/
Even LLVM has all this comical code dealing with negative values stored in unsigneds.
The idea that you should use unsigned to indicate that a value can't be negative is also pretty arbitrary. Your integer type doesn't represent the valid range of values in almost all cases, enforcing it is an unrelated concern.
the layout and typesetting on this looks good in Firefox 70! view-source: https://ourmachinery.com/files/guidebook.md.html - markdown - -">
Objects as structs with function pointers? 1990 is calling. I'm not a huge C++ fan, but trying to emulate C++ concepts in C is kind of lame at this late date.
Objects as structs with function pointers? 1990 is calling. I'm not a huge C++ fan, but trying to emulate C++ concepts in C is kind of lame at this late date.
Just goes to show C++ failed the zero overhead principle.
I.e., use a double parameter that specifies seconds, instead of an uint32_t that specifies milliseconds. This can have surprising and sometimes unpleasant consequences; see https://0.30000000000000004.com
What practical problems do you think this could cause in specifying or measuring time?
http://www-users.math.umn.edu/~arnold//disasters/patriot.htm...
Objects as structs with function pointers? 1990 is calling. I'm not a huge C++ fan, but trying to emulate C++ concepts in C is kind of lame at this late date.
Quick typo under OMG-CODEORG-2: #pragma once #ifdef __cpluspus // Can't say I'm a fan of OMG-CODEORG-3, however, it sounds like compilation time is a key metric for them.. I prefer a John Lakos style "physical components" set up which emulates a type-as-module inclusion style. At least OMG-CODEORG-3 clearly states that include order becomes important as a result.
Agree, CODEORG-3 adds a bunch of pain. There's a reason other languages don't have headers but since C programmers have to live with them can't I just include the single relevant header and move on with writing my code. Yes there is a shared cost to that (compile time) but '#pragma once' is well supported and futzing with header order is a non trivial time-sink too. On the same lines the template 'cute tricks' are wh…
On large projects bad header hygiene can cause significant compilation overhead.
Generally a wonderful set of minimalistic rules, much could carry over beyond C. Except for: "OMG-API-3: Unsigned integers are preferred over signed".. I feel they're on the wrong side of history with this one. "Prefer unsigned" only works if you can do 99% of your codebase this way, which, besides LLVM, probably doesn't work for anyone. Having a codebase that is 99% signed is much more feasible. The worst is a codeb…