Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OMG: Our Machinery Guidebook

ourmachinery.com

Post reply on HN
Print view View original

21–30 of 31 posts

Re: OMG: Our Machinery Guidebook

#21

Post by flohofwoe »

United857 wrote: post #6
mwcremer wrote: post #4

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

Better yet, use std::chrono. Yes, it's C++. But this is an example of how properly applied bits from C++ can make things easier to reason about and type-safe, rather than "let's avoid C++ as much as possible". No ambiguity for the programmer as to what the underlying units are, and no unnecessary int/float conversions. All the book-keeping and conversions are taken care of by the compiler with zero run-time size or p…

std::chrono is a terribly overengineered API even for the STL, and many game companies have banned parts or all of the STL for good reasons (usually not std::chrono related though).

Using an uint64_t (instead of uint32_t or double) to carry "opaque ticks", and a handful conversion function to convert to real-world time units is fine and just a few lines of code.

Re: OMG: Our Machinery Guidebook

#22

Post by chrisseaton »

bobdobbs666 wrote: post #17
chrisseaton wrote: post #10

Earlier quoted context omitted.

What practical problems do you think this could cause in specifying or measuring time?

The patriot missile system tended to miss due to numerical error accumulated due to using floats to count time. http://www-users.math.umn.edu/~arnold//disasters/patriot.htm...

> due to using floats

No they weren't using floats. The article you've linked to says this really clearly.

> This calculation was performed using a 24 bit fixed point register

Re: OMG: Our Machinery Guidebook

#24

Post by Aardappel »

flohofwoe wrote: post #20
Aardappel wrote: post #12

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…

I can see where they're coming from, signed integers come with all sorts of caveats in C and C++ from overflow being undefined behaviour (yet modulo-math often makes sense when integers are used as array indices) to bit twiddling surprises. "Almost always unsigned" sounds like a good rule to me to avoid such pitfalls, especially when 'common math stuff' is usually done with floats or special fixed-point formats.

Overflow being UB is not something you run into easily with typical math, index and size uses (not as often as your run into unsigned issues, in my experience). Yes, bit-twiddling should be unsigned, but it is very easy to make this code isolated, and convert from signed values storing these bits, if necessary.

But I am going to defer to authority here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p142...

Re: OMG: Our Machinery Guidebook

#25

Post by bobdobbs666 »

chrisseaton wrote: post #22
bobdobbs666 wrote: post #17

Earlier quoted context omitted.

The patriot missile system tended to miss due to numerical error accumulated due to using floats to count time. http://www-users.math.umn.edu/~arnold//disasters/patriot.htm...

> due to using floats No they weren't using floats. The article you've linked to says this really clearly. > This calculation was performed using a 24 bit fixed point register

http://www.cs.unc.edu/~smp/COMP205/LECTURES/ERROR/lec23/node...

They meant fixed precision not fixed point math.

Re: OMG: Our Machinery Guidebook

#26

Post by niklasgray »

vietjtnguyen wrote: post #7

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.

Thank you for noticing the typo.

I wasn't sure about OMG-CODEORG-3 in the beginning either, but after using it for over a year and a half now, I'm strongly in favor.

The only situation where inclusion order matters is when there's (pseudo-) inheritance, and we don't use that a lot, so in practice it is not a big issue.

Actually, I've had MORE problems with inclusion order in previous projects that didn't use this rule. What would happen is that some header (included from some other header, included from some other header) would include . Then some other header (from some other header, etc) would include something that conflicts with the (many) #defines in .

Trying to sort out this mess was always a PITA. First you have to figure out where the include is coming from. Then you have to figure out how to fiddle with the include order and the defines to fix it. When using OMG-CODEORG-3, this is pretty simple, because all the includes happen in the .c file, so it is easy to rearrange them to fix include order problems. Not so easy when the includes are scattered all over multiple .h files.

Another big win with OMG-CODEORG-3 is that you see exactly what other pieces of code the .c file is dependent on, you don't need to follow multiple header chains to figure it out. You also only depend on the things you really need which is nice. In projects with liberal header inclusion, dependencies can grow as O(n^2) which increases complexity.

Re: OMG: Our Machinery Guidebook

#27

Post by niklasgray »

Aardappel wrote: post #12

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…

We actually had a debate about this. I was initially in favor of "signed as default", but I acquiesced.

In retrospect, I think I was wrong and that "unsigned as default" works better.

I think the domain is important here. We're building a game engine, so there's actually plenty of bit fiddling. We also make use of the "overflow wraparound" of unsigneds in a lot of places.

I think in our case having 99 % unsigned is more feasible than having 99 % signed. There are actually not many things that we would need to use a signed integer for.

FYI, in our codebase right now we have

10038 uint32_t 123 int32_t 7843 uint64_t 58 int64_t

So at the moment we're actually 98.998 % unsigned.

I know it's not 99 %, but it's pretty close :)

Re: OMG: Our Machinery Guidebook

#28

Post by niklasgray »

flohofwoe wrote: post #21
United857 wrote: post #6

Earlier quoted context omitted.

Better yet, use std::chrono. Yes, it's C++. But this is an example of how properly applied bits from C++ can make things easier to reason about and type-safe, rather than "let's avoid C++ as much as possible". No ambiguity for the programmer as to what the underlying units are, and no unnecessary int/float conversions. All the book-keeping and conversions are taken care of by the compiler with zero run-time size or p…

std::chrono is a terribly overengineered API even for the STL, and many game companies have banned parts or all of the STL for good reasons (usually not std::chrono related though). Using an uint64_t (instead of uint32_t or double) to carry "opaque ticks", and a handful conversion function to convert to real-world time units is fine and just a few lines of code.

This is exactly what we do.

Re: OMG: Our Machinery Guidebook

#29

Post by Aardappel »

niklasgray wrote: post #27
Aardappel wrote: post #12

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…

We actually had a debate about this. I was initially in favor of "signed as default", but I acquiesced. In retrospect, I think I was wrong and that "unsigned as default" works better. I think the domain is important here. We're building a game engine, so there's actually plenty of bit fiddling. We also make use of the "overflow wraparound" of unsigneds in a lot of places. I think in our case having 99 % unsigned is m…

Well, you have the facts to back it up, so indeed it can work for you. I'd say it requires quite some commitment to push it that far though, and I still would think it's not the right default for almost all teams. Impressive you made it work :)

Re: OMG: Our Machinery Guidebook

#30

Post by gumby »

Aardappel wrote: post #12

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…

I actually like the distinction between std::size_t/std::ptrdiff_t (and even better std::vector's ::size_type and difference_type ). It makes the intent very clear.

It helps that I get to compile all my code -Wconversion.

Post reply on HN