this post was submitted on 03 Nov 2025
113 points (96.7% liked)
Programming
23348 readers
240 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
If you're directly interacting with any sort of binary protocol, i.e. file formats, network protocols etc., you definitely want your variable types to be unambiguous. For future-proofing, yes, but also because because I don't want to go confirm whether I remember correctly that
longis the same size asint.There's also clarity of meaning;
unsigned long longis a noisy monstrosity,uint64_tconveys what it is much more cleanly.charis great if it's representing text characters, but if you have a byte array of binary data, using a type alias helps convey that.And then there are type aliases that are useful because they have different sizes on different platforms like
size_t.I'd say that generally speaking, if it's not an
intor achar, that probably means the exact size of the type is important, in which case it makes sense to convey that using a type alias. It conveys your intentions more clearly and tersely (in a good way), it makes your code more robust when compiled for different platforms, and it's not actually more work; that extra#include <cstdint>you may need to add pays for itself pretty quickly.So we should not have #defines in the way, right?
Like INT32, instead of "int". I mean if you don't know the size you probably won't do network protocols or reading binary stuff anyways.
uint64_t is good IMO, a bit long (why the _t?) maybe, but it's not one of the atrocities I'm talking about where every project had its own defines.
"int" can be different widths on different platforms. If all the compilers you must compile with have standard definitions for specific widths then great use em. That hasn't always been the case, in which case you must roll your own. I'm sure some projects did it where it was unneeded, but when you have to do it you have to do it
So show me two compatible systems where the int has different sizes.
This is folklore IMO, or incompatible anyways.
Incompatible? It is for cross platform code. Wtf are you even talking about
Okay, then give me an example where this matters. If an int hasn't the same size, like on a Nintendo DS and Windows (wildly incompatible), I struggle to find a use case where it would help you out.
You can write code that is dependent on using a specific width of data type. You can compile code for different platforms. I have no idea what you're thinking when you say "wildly incompatible", but I guarantee you there is code that runs on both Nintendo DS and Windows.
Well cite me one then. I mean there are super niche stuff that could theoretically need that, but 99.99% of software didn't, and now don't even more. IMO.
Have you never heard of the concept of serialization? It's weird for you to bring up the Nintendo DS and not be familiar with that, as it's a very important topic in game development. Outside of game development, it's used a lot in network code. Even javascript has ArrayBuffer.
I've personally built small homebrew projects that run on both Nintendo DS and Windows/Linux. Is that really so hard to imagine? As long as you design proper abstractions, it's pretty straightforward.
Generally speaking, the best way to write optimal code is to understand your data first. You can't do that if you don't even know what format your data is in!
What on earth did you run on a DS and windows? I'm curious! BTW we used hard coded in memory structures, not serialising stuff, you'd have a hard time doing that perfectly well on the DS IMO.
Still only a small homebrew project so IMO my point still stands.
As for understanding your data, you need to know the size of the int on your system to set up the infamous INT32 to begin with!
A homebrew game, of course! Well, more like a game engine demo. Making game engines is more fun than making games.
I'm not sure why you find it so hard to believe, as it's pretty straight-forward to build a game on top of APIs like
Then implement them differently on each target platform.
You mean embedded binary data? That's still serialization, except you're using the compiler as your serializer. Modern serialization frameworks usually have a DSL that mimics C struct declarations, and it's not a coincidence. Look up any zero-copy serialization tool and you'll find that they're all basically trying to accomplish the same thing: load a binary blob directly into a native C struct, but do it portably (which embedded binary data is not)
Nah, that's what
int32_tis for. The people who built the toolchain did that for me.Yeah that's how we did it, loading a "blob" into packed structs :-)
I'm with you with the int32_t, that's totally the way to go IMO, I guess my rant about #define INT32 got lost somewhere :-)
Actually got myself a job coding DS&Wii back in the day with my DS streaming tile engine (it is funnier to make engines), "use 64k tiles with the native 256 tile engine". I had a little demo where you wandered around and slayed skeletons Diablo 2 like, backpack and items included. Built with the unofficial retroengineered dev kit. Got my hands on the official docs after that!
Fun times.
Damn that's sick. Landing a real job from homebrew work is the coolest backstory for a game developer. I've got a couple of hb projects I'm proud of, but in the world of Unity and Unreal I don't see it as being a particularly in-demand skill set.
...not that I'd want to work for a game dev company in 2025 lol
I did have a couple of years of gamedev under the belt, but only j2me java mobile games, so laying my hands on a nintendo dev kit was one of those one in a lifetime highs for me. Still get a tingle when I think about it ☺️.
You're right about todays landscape though 😑, between abusing A to AAA companies, dark patterns and microtransactions 🤢. Such a shame. I should get into indie games more but they all feel like they were made for unity/UE, so they all feel a bit the same (where are syrategy games, spinoffs off Worms, lemmings, ...). But maybe I'm missing out, there is so much rubbish to sift through.
Cheers!
I'm done spending time on this. If you are so insistent on being confidently incorrect then have at it.
Lol
The standard type aliases like
uint64_tweren't in the C standard library until C99 and in C++ until C++11, so there are plenty of older code bases that would have had to define their own.The use of
#defineto make type aliases never made sense to me. The earliest versions of C didn't havetypedef, I guess, but that's like, the 1970s. Anyway, you wouldn't do it that way in modern C/C++.I've seen several codebases that have a typedef or using keyword to map uint64_t to uint64 along with the others, but _t seems to be the convention for built-in std type names.
Iirc, _t is to denote a reserved standard type names.