9 ms·
IMO, defining your own types is one step too far. Now everyone who is already familiar with C types has to learn your own quirky system to understand one progra
by Uptrenda 3y ago
IMO, defining your own types is one step too far. Now everyone who is already familiar with C types has to learn your own quirky system to understand one program. I think it does probably make sense to be specific about the sizes though e.g. using uint32_t over just uint (and expecting to receive some architecture-dependent size you might not get with uint.) These types should be defined in the right header (I think it depends on compiler?) It's been a while since I wrote any amount of C so my apologizes if this isn't correct.
- voxl 3y agothey're not quirky types in the least...
- guidoism 3y agoI agree. A lot of languages have settled on those same names or something similar. We don’t live in a world with a single word size anymore so carrying bit length in the name is critical, and so is keeping identifier names short. His trade off is exactly the one I would make.
- WalterBright 3y ago> carrying bit length in the name is critical I beg to disagree. In D: byte - 8 bits short - 16 bits int - 32 bits long - 64 bits absolutely nobody is confused about this.
- iforgotpassword 3y agoBecause we've used those names since forever, but that's archaic random crap really. Nothing apart from maybe "byte" makes sense here, the rest is completely arbitrary historic cruft. Could as well have called the rest timmy, britney and hulk.
- runiq 3y ago> Nothing apart from maybe "byte" makes sense here Lest we forget: https://web.archive.org/web/20170403130829/http://www.bobbemer.com/BYTE.HTM https://web.archive.org/web/20170403130829/http://www.bobbem...
- layer8 3y agoJava uses exactly the same, and has a huge developer mindshare. While rooted in historic accidents, it's well-established.
- another2another 3y agoIn that case D should probably start to have an internal conversation about what they're going to call 128 bits then, 'cause its going to become a thing sooner or later. stdint already has that covered though: (u)int128_t
- gallier2 3y agoit has defined the type for very long: it's cent and ucent. It hasn't implemented it completely though, but named and defined it is already forever.
- fps_doug 3y agoSo will the 256bit one be dollar or euro?
- WalterBright 3y agoWe'll think of something. Perhaps `bright`?
- another2another 3y agoThat's really interesting, and for me a totally unexpected name, having never seen that nomenclature before - would be interesting to see how consensus around that was arrived at - but hey, we gotta call it something! (But not DoubleQuadWord please ... )
- gallier2 3y agoand ubyte - 8 bits ushort - 16 bits uint - 32 bits ulong - 64 bits ucent - 128 bits float - 32 bits double - 64 bits real - maximum precision hardware allows (80 bits on x87).
- eviks 3y agoOf course plenty of people are confused, the overhead of "short/long" just makes no sense, but yet another bad design from the past carefully preserved
- WalterBright 3y agoHaven't run into a confused one yet, and D has been around 20 years.
- eviks 3y agoThat's just an indication of who you run into if you've missed people noticing/getting confused by this pretty obvious flaw
- seanw444 3y agoWhen we move into the 128-bit CPU era, will we call 128-bit integers "super long"? Maybe "elongated". Maybe "huge"? Or, you know, we could just name them all by bit length and completely future-proof this system.
- richard_todd 3y agoWe used to call 16-bytes a paragraph, so the nostalgic geek in me would love to see ‘para’ catch on. I never thought I’d be slinging around whole paragraphs of memory in registers!
- ogogmad 3y agoWhy would we ever need 128-bit CPUs? I remember the PS2 had something like that (with details and caveats I don't understand), but subsequent games consoles went back to a more usual register size: https://en.wikipedia.org/wiki/128-bit_computing https://en.wikipedia.org/wiki/128-bit_computing
- seanw444 3y agoAll I know is we keep having this issue with saying "nah, this is it. Nobody will ever need more than this." And then inevitably the time comes when we need more.
- WalterBright 3y agoBack in the 80s, 16 bit programmers knew that 32 bit code was coming, so they carefully crafted the code to be portable to 32 bits. Of course, none of it worked on 32 bit machines because the programmers had never written 32 bit code before and did the portability measures all wrong.
- WalterBright 3y agoWe call them "cent" and "ucent" in D :-)
- guidoism 3y agoWait, isn't long 32 bits, long long is 64 bits.
- outsomnia 3y agoIn isolation, they're not crazy. But much C code is bringing in library headers which contain their author's own pet choices for these, which inevitably are not the same and the result is extremely confusing when you have that in play as well as the stdint.h ones. The kernel contains a mixture of "pet" types like u32 and stdint ones, it's already confusing. He also does make a "crazy" choice later to call his string class "s8" which clashes with his nomenclature here.
- lelanthran 3y ago> they're not quirky types in the least... But they are buggy (correct code cannot depend on the sign of `char`), which is usually the result of typedefing primitive types to save typing 3 characters on each use.
- colejhudson 3y agoI mean, being a bit glib here, but a lot of programming is dealing with someone else's type system. Moreover, for those of us who write C fairly often, the mnemonics here are familiar. Actually, as custom type systems go, this one is pretty elegant. Reminds me of Rust.
- kristopolous 3y agoSpeaking of type systems, I read glib as g-lib a few times and tried to understand how you were talking about the GNU lib in that sentence.
- zombot 3y agoWouldn't that have to be `glibc`?
- slondr 3y agohttps://en.wikipedia.org/wiki/GLib?wprov=sfti1 https://en.wikipedia.org/wiki/GLib?wprov=sfti1
- zombot 3y agoI see. Thanks for that link!
- wyldfire 3y agoIt is unfortunate that the two have such similar names because there's a lot of room for confusion. It doesn't help that they have somewhat adjacent functionality almost.
- userbinator 3y agoI did too. Humans use context to resolve ambiguities in language, and in this case the context was very much statistically favouring the library; if you're using it, glib is literally "someone else's type system".
- 3y ago
- petabytes 3y agoIt's pretty much the same types you see in Rust or Zig, and I think Linux even uses some of the same types.
- oaiey 3y agoYeah, and C/C++ has these since three times the age of Rust. I also find them beautiful but not consistent.
- pwdisswordfishc 3y agoWith slightly different semantics; as I recall, the Linux uXX and iXX types have natural alignment (equal to size), while stdint.h types are not required to.
- rkagerer 3y agoThe author did qualify it with personal coding style. Frankly the standard types are too verbose and I wish this guy's elegant and clear list had been the one that was adopted way back when.
- lelanthran 3y ago> The author did qualify it with personal coding style. Frankly the standard types are too verbose and I wish this guy's elegant and clear list had been the one that was adopted way back when. They didn't adopt it for the same reason that it is a bad idea now - too many programs already contained at least one variable named after his types. If the standard had adopted his convention, too many programs will break, which is why his convention is currently unsuitable for any existing project.
- otikik 3y agoWouldn’t existing programs just continue working? What the author did was adding new types, not modifying or removing existing ones.
- iforgotpassword 3y agoBecause those existing programs surely don't use the same identifiers for other stuff? Certainly there is no code out there using s8 for "signed char" instead of "utf8 string"? :-)
- lelanthran 3y ago> Wouldn’t existing programs just continue working? Only ones which don't have variables named `i8` or `b32` (which is common, but not for booleans). I've seen many projects which used the pattern [a-z][1-9]+ as variables. Those programs with a variable called `i8` won't compile if the standard made a type called `i8`. In particular, the standard reserves entire patterns to itself, so it cannot reserve the pattern of [a-z][0-9]+. They could, and did, reserve the pattern *int*_t for themselves.
- WalterBright 3y agoThe reality is that C `int` is 32 bits in size. Sure, that's not true for 16 bit targets. But are you really going to port a 5Mb program to 16 bits? It's not worth worrying about. Your code is highly unlikely to be portable to 16 bits anyway. The problem is with `long`, which is 32 bits on some machines and 64 bits on others. This is just madness. Fortunately, `long long` is always 64 bits, so it makes sense to just abandon `long`. So there it is: char - 8 bits short - 16 bits int - 32 bits long long - 64 bits Done! (Sheesh, all the endless hours wasted on the size of an `int` in C.)
- deleted 3y ago[deleted]
- consp 3y agoWhich are minima, but in practice they represent the width.
- Findecanor 3y agoYet another issue is that `char` is signed on some platforms but unsigned on others. It is signed on x86 but unsigned on RISC-V. On ARM it could be either (ARM standard is unsigned, Apple does signed). I therefore use typedefs called `byte` and `ubyte` wherever the data is 8-bit but not character data. I also use the aliases `ushort`, `uint` and `ulong` to cut down on typing. On the other hand, the types in <stdint.h> are often recognised by syntax colouring in editors where user-defined types aren't.
- hasmanean 3y agoDefault signed/unsigned is not a platform convention but a compiler one. You can change it with a compiler switch, in the makefile.
- chmod775 3y agoThen you're better off using custom types - that way people will immediate know your type is non-default - as opposed to hiding your customization away in a makefile, pranking people who expect built-ins to behave a certain way.
- Nursie 3y ago> These types should be defined in the right header stdint.h It's always been amazing to me how many different projects I've worked on (not that I've been in professional C for about 7 years now)) that include their own painstaking recreation of this file. Reusing them and effectively translating them just to your own name is just annoying to the reader IMHO. I am reminded of a C++ project I worked on, where I questioned the extensive use of typedefs around collections of things, various forms of references and compound objects etc. I was informed by one of the more experienced C++ folks that it made the code easier to comprehend. Later I saw the typedef cheat-sheet sellotaped to the side of his monitor...
- gallier2 3y agoFor bool it's even worse.
- cesarb 3y ago> It's always been amazing to me how many different projects I've worked on (not that I've been in professional C for about 7 years now)) that include their own painstaking recreation of this file. How many of them started before stdint.h existed? AFAIK, it's a somewhat recent addition to the C language, and IIRC, for a long time even after it became part of the C standard, some popular C compilers still didn't have it.
- deleted 3y ago[deleted]
- Nursie 3y agoAs recently as eight years ago, on projects started within the previous handful of years. It’s more to do with a lot of C programmers being stuck in a sort of stasis IMHO. (I’m sure I was too in many ways). And yes, Microsoft were the outlier and absolutely dragged their heels on stdint, but you could always grab a compliant implementation from one of the FOSS projects that produced one.
- uxp8u61q 3y agointtypes.h was added to C99. A quarter of a century ago.
- the_mitsuhiko 3y agoThe big issue with custom integer types is that while they are awesome in the implementation files, they are problematic for libraries in headers. And if you want to avoid a divergence between header and implementation files you're kinda stuck with the inttypes.h ones in practice.
- pwdisswordfishc 3y agoIMO, defining your own aliases for stdint.h types is innocent enough, but manually defining prototypes for Win32 calls instead of including standard headers is one step too far. You don’t own the ABI here: things like HANDLE and WPARAM have already changed sizes once, who’s to say ULONG_PTR will stay the same as uintptr_t for all future architectures? There is a good reason why doing the same on Unix is discouraged.
- Lockal 3y agoJust a note: defining own integer types has sense for resource-limited platforms. Most common type I see is something like "dim_t", which is 32-bit or 64-bit depending on use-case. 32-bit integers are often used even on 64-bit platforms in pointer compression schemes (for example, allocate your own heap and only store 32-bit offsets). This not only gives 2x improvement on memory usage for <4GB workloads, but it also improves performance due to better cache locality.
- kazinator 3y agoThe u32/i64/... naming system is pretty common. Assuming you can trust those types to be what they look like, the code is readable. I've worked with C for well over 30 years; custom typedefs are par for the course. Work with OpenMAX libs? You have OMX_U32. On Windows? You have DWORD. Using Glib? guint32 ...
- mattpallissard 3y ago> Now everyone who is already familiar with C types has to learn your own quirky system Oh I dunno. On one hand yeah learning a quirky system is an annoyance at times. On the other hand when you're coming from a language with a real type system dealing with custom types is standard operating procedure. I've had to patch a lot of C over the years. I can't say I've ever been bothered by types. It's always the usual suspects; hard coded offsets peppered throughout the codebase, stack smashing, baby's first callback implementation, "parsing" that omits lexing/tokenizing, archaic business logic that may-or-may not have ever been correct.
- AlchemistCamp 3y agoYou can just #include <stdint.h> to get those types, at least in the environments I’ve worked in.