341–350 of 466 posts
Earlier quoted context omitted.
Long type name?? uint32_t is literally 8 characters long. There's not much to cut here.
if you like typing _, go ahead, but it's not 1 key press and shouldn't be treated as a keystroke like the letter a...
Earlier quoted context omitted.
The builtin itself is fine. It works exactly as it's intended. It says "I've double and tripple checked this. Trust me compiler. Just go fast". But you should not use it to construct an assert.
Eh. I absolutely get what you're saying. And this is for sure flying very close to the knife's edge. But if your assertion checks don't run in release mode, and due to some bug, those invariants don't hold, well, your program is already going to exhibit undefined behaviour. Why not let the compiler know about the undefined behaviour so it can optimize better? The nice thing about this approach is that the assertion p…
Usually in release mode you want to log the core dump and then fix the bug.
Earlier quoted context omitted.
The 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…
C is also used on embedded. It's even there the default language.
Earlier quoted context omitted.
if you like typing _, go ahead, but it's not 1 key press and shouldn't be treated as a keystroke like the letter a...
On my keyboard layout it's one keypress. And since code is read about 100 times as much it's written, I don't particularly care about reaching 250 WPM while writing code. The difficulty of writing code is thinking about it, not actually physically writing it.
Earlier quoted context omitted.
I actually have the opposite feeling. I like the non-sized type names like float extended as float4 or float4x4. My brain wants to read f32x4 as a 32 by 4 matrix of floats. (That being said I'd definitely be interested in trying your convention in the context of something like Rust.)
float4 is nice, but in video games, especially graphics, the vast majority of our floats are 32 bits but we also use 16 bits floats quite extensively, and in this case it is quite practical to follow the same convention. f32 -> f16 f32x4 -> f16x4 And when working on some heavily optimized SIMD code on the CPU side, I tend to use the default types even less.
IMO including the number of bits in all primitive types is usually an overcorrection from trauma caused by C/C++'s historic loose definitions of primitive type sizes. However I don't write much CPU SIMD code and can definitely see how you'd develop your preference from that context.
Earlier quoted context omitted.
Smart pointers alone make the switch worth it. Why wouldn't you want that?
Smart pointers for what? I don't use any dynamically allocated memory in my firmware projects. I do sometimes use statically allocated pools for things like packet buffers and allocate chunks out of them, but their lifetimes are not scope based, so automatic call of constructors/destructors would not be of any help.
I'm also wondering if you've heard about std::span, given your use case. I would be surprised if you weren't rebuilding much of that functionality.
Earlier quoted context omitted.
inttypes.h was added to C99. A quarter of a century ago.
Many C codebases predate that. And Visual Studio for a long time didn’t support anything newer than C89.
I work on a born-1995 codebase. We started requiring an ISO C11 plus GNU extensions¹ several years ago and are actively removing "compatibility" checks and kludges that are outdated.
[¹ to be fair - not needing to support Windows is a godsend for any C project.]
Earlier quoted context omitted.
I want to both be polite to the OP but also agree. Writing correct C is hard, so I’m not going to knock anyone who found stuff that helps them. But pound defining shit to things you know via your Hungarian notion? Write some elisp. My Haskell programs don’t actually have Unicode lambda in them. Pascal strings? Yeah, that’s probably the better call, but why not use C++ or Rust or something where a bunch of geniuses go…
>Pascal strings? Yeah, that’s probably the better call, but why not use C++ or Rust or something where a bunch of geniuses got it right already? I'll be diving into C fairly heavy for the first time ever next year. I intend to skip right past pascal strings and implement/use free pascal's AnsiString or UnicodeString, both of which are reference counted, have a length (with no limit) and are guaranteed null terminated…
I guess you're going to implement your from scratch, or is there some prior art you're likely to use?
Earlier quoted context omitted.
Funny enough, the take on const in the only thing I agree with in the whole post…
I"m even not agreeing with the const part. The standard did define const API"s, so why shouldn"t we follow? I know that C const are only half of C++ consts, but still. Still catching const errors somewhere because I do use const in APIs. I only agree with "Declare all functions static except for entry points". s8(s) is only for literal strings, it should be called s8_c instead and keep s8 for the default ctor. The st…