231–240 of 466 posts
I wrote and still maintain an open source C project for 20+ years. Once a year I get a new guy coming in and telling me I am doing it wrong: you should typedef all data types, you should stop using const, and so on. It stopped being funny after the first couple times.
Earlier quoted context omitted.
I 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.
> 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.
Earlier quoted context omitted.
I'm not a C developer, so I have to ask: why in the world would you not use const?
It's more work. Not only to put all the annotations correctly, but only because it causes some real headaches. It's easy (implicit) to transition from non-const to const 1 pointer level deep. But the other way around -- it's really awkward to "remove" a const. The strstr() signature is probably the shortest example / explanation why. To implement strstr(), you have to hack the const away to create the return value. A…
Ever seen a ROM?
And the C library‘s hacks around not being able to overload functions (which is the only reason for strstr et al‘s weird signature) wouldn‘t stop me from using const. It can be really useful both for documentation and for correctness. Think memcpy, not strstr.
Earlier quoted context omitted.
I'm not a C developer, so I have to ask: why in the world would you not use const?
It's more work. Not only to put all the annotations correctly, but only because it causes some real headaches. It's easy (implicit) to transition from non-const to const 1 pointer level deep. But the other way around -- it's really awkward to "remove" a const. The strstr() signature is probably the shortest example / explanation why. To implement strstr(), you have to hack the const away to create the return value. A…
It seems to me the "hacking" is exactly the side-effect that is wanted. It's like the requirement in Rust to do certain kinds of things in an `unsafe { }` block (or using the `unsafe` package in Go): not that you want the compiler to prevent you from doing things completely, but that you want the compiler to prevent you from doing things by accident.
> One man's const data is another man's mutable data.
Yes; and the point of `const` for function parameters is to make sure that data isn't mutated unexpectedly.
Earlier quoted context omitted.
> Yes, it lets you shoot yourself in the foot, but what language doesn't? Good lord.
Well ... Name a language is which you categorically cannot "shoot yourself in the foot"!
Earlier quoted context omitted.
I 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.
Speaking 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.
> While I still prefer ALL_CAPS for constants, I’ve adopted lowercase for function-like macros because it’s nicer to read. "ALL_CAPS" in C was not for constants, but for preprocessor macros. It's shouting in all-caps, because it means "Look out! There's a cpp macro expansion here!" Related, please stop using "ALL_CAPS" for constants in other languages. Not only does shouting constants as the most prominent syntax in…
do_thing(foo); // foo is variable
do_thing(FOO); // FOO is constant (i.e this call should always do the same thing)
foo = FOO; // I wanna name a variable the same as a constantIMO, 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…
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…
> While I still prefer ALL_CAPS for constants, I’ve adopted lowercase for function-like macros because it’s nicer to read. "ALL_CAPS" in C was not for constants, but for preprocessor macros. It's shouting in all-caps, because it means "Look out! There's a cpp macro expansion here!" Related, please stop using "ALL_CAPS" for constants in other languages. Not only does shouting constants as the most prominent syntax in…
I do it mainly as a form of namespacing and aid in readability. do_thing(foo); // foo is variable do_thing(FOO); // FOO is constant (i.e this call should always do the same thing) foo = FOO; // I wanna name a variable the same as a constant
do_thing(Constants.foo)