6 ms·
Tangentially... I'm grateful that these new batches of systems languages have chosen to use the u8, i32, etc, style integer types. Rather than the uint8_t and i
by travisgriggs 3y ago
Tangentially... I'm grateful that these new batches of systems languages have chosen to use the u8, i32, etc, style integer types. Rather than the uint8_t and int32_t style. First thing I do in any of my low level embedded C projects is put in the various uNN/iNN types.
- pavlov 3y agoThe C standard effectively can’t add new types without the “_t” suffix, so they’re stuck with limitations that a brand new language won’t have.
- pitaj 3y agoCan't they add a new header file?
- flohofwoe 3y agoWhat if a library API needs to include this new header because it wants to use the new typedefs in its API declarations but your own code (which needs to include the library header) also has its own 'u8' typedefs? (PS: it's probably ok because C compilers seem to accept redundant typedefs)
- sieabahlpark 3y agoIt sounds like you got some refactoring to use since you didn't namespace your own core types?
- flohofwoe 3y agoC doesn't have namespaces. The only sane way to deal with name collisions is either to use C stdlib types in library APIs (e.g. uint8_t), or use a library specific prefix (e.g. mylib_u8) - which is of course even more awkward than just using the standard uint8_t.
- naasking 3y agoA prefix and a namespace aren't really that different in practice.
- staunton 3y agoThey are different. Namespaces are syntactically enforced and you can opt-in or out to names. To have syntactically validated qualified access. Naming might go well and have the same utility, but you never know what evil things are going on in all those headers, redefining each other's symbols and yours.
- naasking 3y agoYou seem to be focusing on specific problems with C/C++. I don't really care about that, all I'm saying is that prefixing names are equivalent to placing them within a namespace, in practice, and theoretically come to think of it. You can easily define a bijection between namespaced symbols and prefixed symbols. Requiring the full prefixes are simply a tad more verbose, essentially equivalent to using a fully qualified name for symbol.
- sieabahlpark 3y ago[dead]
- stephc_int13 3y agoI think that "namespacing" basic types such as u32 is completely unecessary. In what world would an u32_MYLIB would be different than an u32_SOMELIB? Basic types are common enough.
- pavlov 3y agoThe preprocessor doesn’t know that u32 defined in foo.h is the same type as u32 defined in bar.h. So you’ll get an error when importing both.
- pornel 3y agoIf C made this change, it could also make it legal to redefine u32 etc as appropriate integer types any number of times without erring.
- saagarjha 3y agofoo.h defines i64 as “long” and bar.h defines it as “long long”. Now what?
- kevin_thibedeau 3y agoThis would break legacy code. I had one employer with a bool type that was a 32-bit integer because of obscure alignment issues. This is why _Bool exists and the bool typedef has to be brought in explicitly with stdbool. You can't just go and usurp popular short type names. The standard reserved *_t and _[A-Z].+ for this purpose. People have been writing portable code with the expectation that future standards aren't going violate that promise and break things.
- alexvoda 3y agoThis is just one of the reasons that new languages that dispense with outdated assumptions and insted make assumptions more suitable to our times are a good thing. C and C++ are really old and some things can not be fixed with libraries.
- pjmlp 3y agoSame reasoning applies to new keywords.
- pjmlp 3y agoThey added new keywords just fine, even if it needs a trasition phase to go through them.
- jjtheblunt 3y agodo you mean just to save the _t and int substrings, over and over? (if so, i agree)
- WalterBright 3y agoD uses byte, short, int, long for i8, i16, i32, i64, and ubyte, ushort, uint, and ulong for the unsigned versions. After 5 minutes with the language there is no longer any point to emphasizing the number of bits. Besides, they're just easier to touch type.
- tialaramex 3y agoI think that trade off made more sense twenty years ago than it does today. So it's understandable that D did this, but doesn't make it a good choice for Zig. Zig programmers don't need to keep talking about types, so the type (and thus in this case its size) is getting mentioned mostly when that matters, e.g. API boundaries.
- eps 3y agoNot sure if I parse your argument right, but there's lot of cases when one would care how wide specific integer type is. Especially in the code that works with data in bulk (as in millions/billions of data objects), where not wasting bits really pays off.
- saagarjha 3y agoSure there is: when I’m parsing or serializing something it’s pretty important I know what size something is.
- WalterBright 3y agoThe size of `byte` is fixed at 8, `short` 16, `int` 32, `long` 64. There is no ambiguity or uncertainty about it.
- vore 3y agoAt that point, why not just call them i/u8/16/32/64? If the sizes are fixed anyway, why come up with different names for them, especially when almost all of the times you would want to select a different integer type is specifically because of how many bits wide it is? (otherwise, surely you would just use the machine word size?)
- andikleen2 3y agoHaving spent a lot of time porting 32bit system code to 64bit, I developed a dislike for these explicit types. It's a slippery slope to hard code your bitness with people making assumptions where size_t or pointers fit. Now maybe if you're already 64bit that's fine (it's unlikely that we'll ever need 128bit, and code is unlikely to grow down), but for anything starting smaller it's a pain.
- dralley 3y agoJust because your code compiles on a new platform doesn't mean the prior assumptions of the prior behavior of the types remains valid.
- duped 3y agoBut it should, and that's what stricter typing can help with.
- diarrhea 3y agoPeople are already working on a 128bit Linux kernel.
- staunton 3y agoThe sizes of floating point are growing "apart" in the AI space. Who's to say what might happen with sizes of types. Maybe it's great to use mostly u8 if you're controlling a worldwide asynchronous networked megacomputer.
- tialaramex 3y agoHuh? Zig, like Rust, has two kinds of "primitive" numeric types, the kind which are an explicit size in bits (u8, i16, f64 and so on) and then the word size ones (isize, usize), which are whatever size is suitable for your target machine. C gets this all muddled because it has named primitive numeric types but their meaning is imprecise, and then it uses a typedef to assign one of these (but you don't know which one) as the native word size. So maybe long is the same as your size_t, and C will just assume you know what you're doing when you write a long where you need a size_t - thus making your code non-portable.
- Cloudef 3y agoWhat I'm really waiting for is zig support for custom range ints https://github.com/ziglang/zig/issues/3806 https://github.com/ziglang/zig/issues/3806 Also minor nitpick I have is that the interval/range syntax in zig is pretty confusing as it can be both inclusive and exclusive depending on context. Swift does it imo better by ... being inclusive and ..< exclusive
- earthboundkid 3y agoI was surprised they didn’t copy Swift on this. It seems just obviously better than two dots.
- brabel 3y agoGroovy has had that syntax for much longer than Swift has existed... Groovy normally copies features from Ruby/Python/SmallTalk so I would think one of those are the source for this syntax.
- camel-cdr 3y agoMost of the time you want to use something like size_t anyways.
- up2isomorphism 3y agoIt is couple of lines of typedef, what’s the big deal.