The Zig Saga...
-
It's the little things like this that's practically forcing me to learn to Zig. I mean... C should be getting some of this stuff so it stops falling so far behind. I mean, why leave systems languages in the dust? Such as being able to use underscores to increase readability in long numbers. I mean C# has had it for a while now. What gives?
const jenny: u32 = 867_5309 // don't lose my numberJeremy Falcon
-
Never heard of that in C#. Seems pointless, so I guess they probably added it.
C# binary literals:
const uint bitmask = 0b0010_0000_0000_1100_0000_0001_0000_1111;
The underscores are useful, no?
Software Zen:
delete this; -
C# binary literals:
const uint bitmask = 0b0010_0000_0000_1100_0000_0001_0000_1111;
The underscores are useful, no?
Software Zen:
delete this;I'd use hex.
-
Wait, what? Why the heck would you add commas for large numbers? It's a number. First, if you are entering large numbers like this in your code in the middle of processing, you need to have your code reviewed. This falls under a magic number. A very long time ago, and I'm being sarcastic, we'd do this: #define _A_VERY_LARGE_NUMBER 12345678901234 Better yet, we'd so something like: // Folks, we use metric in this code. If you introduce english units, I will haunt you from the grave. #define SPEED_OF_LIGHT_METERS_PER_SEC 299792458
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
Extracting magic numbers as named constants is usually a good idea, but orthogonal to the question of whether an underscore separator is helpful or not. It absolutely is helpful if you're dealing with number with mure than 7 or 8 digits. There's a reason we use commas (or periods in continental Europe) to break numbers into groups of 3 digits: it makes it much more obvious when a digit is missing (or erroneously present).
-
I'd use hex.
The binary literals are handy for hardware register bits. This is especially true when the documentation is written by a hardware engineer who documents things by bit numbers rather than masks. Defining this sort of thing with hex is okay, but it takes more time when reading.
Software Zen:
delete this; -
The binary literals are handy for hardware register bits. This is especially true when the documentation is written by a hardware engineer who documents things by bit numbers rather than masks. Defining this sort of thing with hex is okay, but it takes more time when reading.
Software Zen:
delete this;VB has datetime literals, I'd find them more useful in my work.
-
C won't ever get up-to-date as C proponents don't want anything modern. It's not like system languages get left in the dust though, Rust is having some exciting evolution.
Yeah, and what makes it worse is that C is use everywhere. So now there are huge committees involved, so things (even if they did happen) will take a while to get ratified and accepted.
Jeremy Falcon
-
Extracting magic numbers as named constants is usually a good idea, but orthogonal to the question of whether an underscore separator is helpful or not. It absolutely is helpful if you're dealing with number with mure than 7 or 8 digits. There's a reason we use commas (or periods in continental Europe) to break numbers into groups of 3 digits: it makes it much more obvious when a digit is missing (or erroneously present).
fair enough. So: #define SPEED_OF_LIGHT_M_PER_SEC 299,792,458 :) I understand your point, but I abhor magic numbers in code even if I know what they mean. I hate magic functions, and don't get me started on hideously complex macros that cannot be debugged. Hex constants are okay as well, since I can transpose the bits in my head while reading - but I can see the benefit of breaking up long hex strings when you are masking say a 64 bit value. The ultimate goal is to avoid errors.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
C won't ever get up-to-date as C proponents don't want anything modern. It's not like system languages get left in the dust though, Rust is having some exciting evolution.
-
fair enough. So: #define SPEED_OF_LIGHT_M_PER_SEC 299,792,458 :) I understand your point, but I abhor magic numbers in code even if I know what they mean. I hate magic functions, and don't get me started on hideously complex macros that cannot be debugged. Hex constants are okay as well, since I can transpose the bits in my head while reading - but I can see the benefit of breaking up long hex strings when you are masking say a 64 bit value. The ultimate goal is to avoid errors.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
charlieg wrote:
The ultimate goal is to avoid errors.
Yep! And I agree with you that magic numbers run counter to that, since there's no visible, verifiable logic within them - you just have to somehow know that it's correct. When I was learning 68000 assembly in the 1990s, I'd read freely-available source code and see moves to and from arbitrary memory addresses for device I/O etc, and wonder how often people accidentally used the wrong address (or one that may only be valid if your machine has exactly 512kb RAM). Where possible I'll try to push back on the inscrutability a bit, like defining
SECONDS_PER_DAY
as
60*60*24
instead of
86400
.
-
Yeah, and what makes it worse is that C is use everywhere. So now there are huge committees involved, so things (even if they did happen) will take a while to get ratified and accepted.
Jeremy Falcon
It's not (only) that. C++ is driven by a commitee and those guys managed to create a (mostly) modern, pleasant programming language. Rust is driven by a commitee. It's less about commitees and more about specifically C, it attracts a certain kind of people and that certain kind of people keep C the way it is.
-
It's the little things like this that's practically forcing me to learn to Zig. I mean... C should be getting some of this stuff so it stops falling so far behind. I mean, why leave systems languages in the dust? Such as being able to use underscores to increase readability in long numbers. I mean C# has had it for a while now. What gives?
const jenny: u32 = 867_5309 // don't lose my numberJeremy Falcon
So, curious question... even if you are trafficking in .c files, why aren't you using a C++ compiler to compile your C code? Even in embedded environments, C++ is preferred to C. If you must strictly conform to C++ only as better C, and avoid polymorphism, exception handling and RTTI, you are still left with one very powerful tool at your disposal - templates! Using stupid template tricks, you can easily strip your number of the thousands separator, or indeed, any delimiter such as the '-' (dash) in sweet Jenny's phone number. It might look something like this:
#include <iostream>
#include <string>
#include <algorithm> // For std::remove_if// Function to remove thousands separators from a formatted number
std::string removeThousandsSeparators(const std::string& formattedNumber)
{
std::string result = formattedNumber;// Remove any non-digit characters (e.g., commas) result.erase(std::remove\_if(result.begin(), result.end(), { return !std::isdigit(c); }), result.end()); return result;}
Here is an example of how it might be used:
int main()
{
// Example usage
std::string formattedInput = "1,234,567"; // Input with thousands separators
std::string strippedNumber = removeThousandsSeparators(formattedInput);std::cout << "Formatted input: " << formattedInput << std::endl; std::cout << "Stripped input: " << strippedInput << std::endl; return 0;}
If you dislike the idea of having to quote your value, you can also add a pre-processor macro to handle that as well:
// Macro to stringify an argument
#define STRINGIZE(x) #xYou can then use it like so:
auto strippedNumber = removeThousandsSeparators(STRINGIZE(1,234,567));
Keep in mind, all of this is done at compile time, so there is no performance penalty. When there's a will, there's a relative. :-D :laugh:
-
So, curious question... even if you are trafficking in .c files, why aren't you using a C++ compiler to compile your C code? Even in embedded environments, C++ is preferred to C. If you must strictly conform to C++ only as better C, and avoid polymorphism, exception handling and RTTI, you are still left with one very powerful tool at your disposal - templates! Using stupid template tricks, you can easily strip your number of the thousands separator, or indeed, any delimiter such as the '-' (dash) in sweet Jenny's phone number. It might look something like this:
#include <iostream>
#include <string>
#include <algorithm> // For std::remove_if// Function to remove thousands separators from a formatted number
std::string removeThousandsSeparators(const std::string& formattedNumber)
{
std::string result = formattedNumber;// Remove any non-digit characters (e.g., commas) result.erase(std::remove\_if(result.begin(), result.end(), { return !std::isdigit(c); }), result.end()); return result;}
Here is an example of how it might be used:
int main()
{
// Example usage
std::string formattedInput = "1,234,567"; // Input with thousands separators
std::string strippedNumber = removeThousandsSeparators(formattedInput);std::cout << "Formatted input: " << formattedInput << std::endl; std::cout << "Stripped input: " << strippedInput << std::endl; return 0;}
If you dislike the idea of having to quote your value, you can also add a pre-processor macro to handle that as well:
// Macro to stringify an argument
#define STRINGIZE(x) #xYou can then use it like so:
auto strippedNumber = removeThousandsSeparators(STRINGIZE(1,234,567));
Keep in mind, all of this is done at compile time, so there is no performance penalty. When there's a will, there's a relative. :-D :laugh:
Stacy Dudovitz wrote:
So, curious question... even if you are trafficking in .c files, why aren't you using a C++ compiler to compile your C code?
To be honest, habit. :laugh: Back in the day I adopted the when in Rome mantra, as in if I'm gonna do C just use a C compiler to help make sure I don't do anything "non-C" in it. That's the only reason. Now I've just done it so long it's just what I do. :-O
Stacy Dudovitz wrote:
Here is an example of how it might be used:
Per my understanding, if I used the C++ standard libs I'd have to link to the C++ library as well, in conjunction with the C libs. So, I would incur a penalty when it came to runtime requirements if I did that.
Stacy Dudovitz wrote:
Keep in mind, all of this is done at compile time, so there is no performance penalty.
The out of the box thinking is awesome. Great post.
Stacy Dudovitz wrote:
When there's a will, there's a relative. :-D :laugh:
:-D
Jeremy Falcon
-
It's not (only) that. C++ is driven by a commitee and those guys managed to create a (mostly) modern, pleasant programming language. Rust is driven by a commitee. It's less about commitees and more about specifically C, it attracts a certain kind of people and that certain kind of people keep C the way it is.
Ruffnik wrote:
it attracts a certain kind of people and that certain kind of people keep C the way it is.
Gotta agree with you there, buddy. :laugh:
Jeremy Falcon
-
Stacy Dudovitz wrote:
So, curious question... even if you are trafficking in .c files, why aren't you using a C++ compiler to compile your C code?
To be honest, habit. :laugh: Back in the day I adopted the when in Rome mantra, as in if I'm gonna do C just use a C compiler to help make sure I don't do anything "non-C" in it. That's the only reason. Now I've just done it so long it's just what I do. :-O
Stacy Dudovitz wrote:
Here is an example of how it might be used:
Per my understanding, if I used the C++ standard libs I'd have to link to the C++ library as well, in conjunction with the C libs. So, I would incur a penalty when it came to runtime requirements if I did that.
Stacy Dudovitz wrote:
Keep in mind, all of this is done at compile time, so there is no performance penalty.
The out of the box thinking is awesome. Great post.
Stacy Dudovitz wrote:
When there's a will, there's a relative. :-D :laugh:
:-D
Jeremy Falcon
"Per my understanding, if I used the C++ standard libs I'd have to link to the C++ library as well, in conjunction with the C libs." The only time I now use C/C++ is in embedded work. That generally means running on some kind of RTOS, and more to the point, limited flash RAM. I mention this because, at least in the embedded world using a complier like Eclipse (or similar), I can and often need to fine tune which libraries I link with. As a general rule in embedded development in C++, we typically eschew the standard library in favor of speed and size. That means grabbing specific code from the Standard Library for code like the example I gave above. In fact, it is much more common to grab the source for specific calls and just include the source code file, rather than linking to a whole library. Example: I have my own collection of open source implementations of function calls like
itoa,printf,strcat, etc. In the Windows/Mac/Linux world, I don't think there is really any appreciable difference even if you bring in other libraries. Note: It's a good thing to keep in mind that if you require the entire library to deploy, the compiler doesn't link to the whole library, but rather only links to the necessary code it references. What that means practically, is depending on what library calls you make/link to, the performance hit is often negligible if you choose to use the Standard Library from the compiler as opposed to bringing in your own source as needed. Equally important to remember is that when you use the STL part of the standard library, no such limitation exists. Everything required is generated at compile time, and there is no linking to any external code. So to summarize, if you use the C++ compiler just as a better C compiler, AND you don't make calls into the library that are not implemented as templates, you get the best of all worlds. :)