The "case" and "default" overrides seem kinda dicey.
I defined the same macros but with different names, back when I still coded in C. I still think it's a good idea which tends to get reactions like "Ew! Wash your hands."
22nd Century C
71–80 of 106 posts
Re: 22nd Century C
#72This is so fucking stupid.
Re: 22nd Century C
#73I've spent two decades writing C and C++, but the last 8-9 years in really high-level languages (Ruby, Javascript, Python). From either end of the spectrum, I've never felt the need for such emphasis on fixed-sized numeric types. I've commonly needed access to fixed size numerics, like when sending texture formats to the GPU, defining struct layout in file formats and network protocols, but I have never once thought:…
I'm not very experienced with low-level programming, but doesn't the single-responsibility principle suggest that a purpose-built module should handle packing/unpacking of memory objects even if you are writing this module by hand? I'm sure there are cases where even the overhead of calling and running these procedures is too much, but in many cases no further optimization would be needed.
Re: 22nd Century C
#74Earlier quoted context omitted.
> Memory. Defaulting to 16-bits when an 8-bit variable will do can be incredibly wasteful on an 8-bit µC. I hope it doesn't seem like I'm just moving the goalposts, but the obvious answer here is to use a type which is at least 8-bits wide if you only need 8-bits. Such a type exists, and is called "char" (with the appropriate signedness modifiers). This whole discussion has been about writing portable code. Using a "…
I did not expect you'd say "char", because it's a fixed size numeric type. Isn't that what you have been arguing against so far? Anyway, I'd get yelled at if I checked in code where I do math on char. It has to be on uint8 or int8 (or other widths). Not that I'd ever check in such code, after all, I agree with the company policy there. But "char" is just a part of the problem. We have the same issue with all kinds of…
[deleted]
Re: 22nd Century C
#75It reminds me of libCello
Re: 22nd Century C
#76this is basically an updated version of iso646.h [ https://en.wikipedia.org/wiki/C_alternative_tokens ] ...and no, they're not a good idea, its just a syntactic change. If you want a 'better-C', language-wise, Rust is pretty much best current hope, tho that wont mature for another decade or so.
Really? I haven't had a chance to dig into it and a quick google-based look-see didn't pop up immediately obvious results, but I would have thought that two areas where one would want to use C would include specific bit manipulation and explicit memory management. Both of those violate the high-level principles that I thought Rust was supposed to be about. So, either I was wrong (which happens more and more these day…
> specific bit manipulation
> explicit memory management
Re: 22nd Century C
#77this is basically an updated version of iso646.h [ https://en.wikipedia.org/wiki/C_alternative_tokens ] ...and no, they're not a good idea, its just a syntactic change. If you want a 'better-C', language-wise, Rust is pretty much best current hope, tho that wont mature for another decade or so.
Really? I haven't had a chance to dig into it and a quick google-based look-see didn't pop up immediately obvious results, but I would have thought that two areas where one would want to use C would include specific bit manipulation and explicit memory management. Both of those violate the high-level principles that I thought Rust was supposed to be about. So, either I was wrong (which happens more and more these day…
Sorry, you should do more research... :) Rust has great support for very low level operations. Maybe search for 'bitwise operators' or 'inline assembly'. Memory management is even more explicit and strict than C, since you also have to deal with lifetimes and borrowing.
The best thing is, though, since Rust is such a young language, you can change it! Imagine trying to add a new language feature to C, something like the ? operator currently being evaluated for addition in Rust. It would take years, if not decades, to get those things in C. Even now MSVC is just rolling out support for C99.
I can definitely see Rust taking over C's current place in the market over the next decade or two. Better memory safety, higher-level constructs to improve productivity, more cross-platform compatibility, and modern libraries to deal with things like Unicode are a huge draw.
Re: 22nd Century C
#78I've spent two decades writing C and C++, but the last 8-9 years in really high-level languages (Ruby, Javascript, Python). From either end of the spectrum, I've never felt the need for such emphasis on fixed-sized numeric types. I've commonly needed access to fixed size numerics, like when sending texture formats to the GPU, defining struct layout in file formats and network protocols, but I have never once thought:…
There's one more gotcha: security concerns. Writing code that expects long to be 64 bit might be dangerous as it could overflow and create a security bug on a 32 bit machine.
I find that I do want to know the sizes of things fairly often.
Re: 22nd Century C
#79Earlier quoted context omitted.
Really? I haven't had a chance to dig into it and a quick google-based look-see didn't pop up immediately obvious results, but I would have thought that two areas where one would want to use C would include specific bit manipulation and explicit memory management. Both of those violate the high-level principles that I thought Rust was supposed to be about. So, either I was wrong (which happens more and more these day…
> specific bit manipulation Rust absolutely lets you work at the bit level, you can shift and mask just like in C. > explicit memory management It depends on what you mean by "explicit" here. Most Rust code has scope-based memory management, but you can also call malloc/free within an unsafe block.
> but you can also call malloc/free within an unsafe block.
Very cool. I was afraid I would be forced into an FFI type scenario (which Rust apparently has good support for anyway).
Thanks!
Re: 22nd Century C
#80Earlier quoted context omitted.
Really? I haven't had a chance to dig into it and a quick google-based look-see didn't pop up immediately obvious results, but I would have thought that two areas where one would want to use C would include specific bit manipulation and explicit memory management. Both of those violate the high-level principles that I thought Rust was supposed to be about. So, either I was wrong (which happens more and more these day…
Sorry, you should do more research... :) Rust has great support for very low level operations. Maybe search for 'bitwise operators' or 'inline assembly'. Memory management is even more explicit and strict than C, since you also have to deal with lifetimes and borrowing. The best thing is, though, since Rust is such a young language, you can change it! Imagine trying to add a new language feature to C, something like…
Sounds like I should!
Thanks!