131–140 of 148 posts
Earlier quoted context omitted.
Probably best to disclose you're pitching your own baby to us. What do you feel this content adds in context of the article? I can't tell.
I thought "glouw" in the username here and in the username in the link was pretty obvious myself.
Earlier quoted context omitted.
I think writing your own portable C functions is something every programmer wants to own at some point in their young career. Then you grow up and realize there are entire organizations that have spend tens of thousands of man-hours providing the same code, but done correctly and with intent (and consistent philosophy). GObject is that philosophy, but lots of people never hear about it until someone says "Why not use…
This is completely anecdotal, but when I was looking for something like this ~10 years ago (and was just beginning to learn about the wider Linux ecosystem outside of libc), I stumbled upon GObject and completely ignored it because of its association with GNOME. My initial thoughts was that GObject was only really useful if you were building things for the GNOME ecosystem and wrote it off completely. I also did the s…
Earlier quoted context omitted.
Yeah, checking return codes is a thing you NEVER have to do in C... The "exceptions are evil, but without exceptions you can't fail a constructor!" is a really irritating canard when it comes to C++. First off all, the terribleness of exceptions is way overhyped, but even if you do want to avoid them, this is not a problem: just use a factory function instead of a constructor and return a `std::optional` (or a defaul…
> the terribleness of exceptions is way overhyped It's not that exceptions are terrible. I have nothing against them. The thing is that most of the time they are not affordable, especially in embedded. Some compilers don't even support them (some 8-bit IIRC). Most (including mine) embedded C++ programs have exceptions disabled. > return a `std::optional` The same goes for std . I don't know the overhead of possibly d…
> This is practical with an efficient heap allocator (which I might not have). What happens if I want a scoped (on stack) instance of a class?
There is absolutely no reason to do a heap allocation for a factory function in modern C++ (or even relatively ancient C++, in fact). The fact that you would think so indicates you simply don't know C++ at all.
Tell me, where in these six lines do you see a heap allocation? Where in the total of 6 instructions this compiles down to do you see anything that couldn't run in any embedded environment? Tell me how these six instructions wouldn't fit inside your 64kb of flash:
https://godbolt.org/z/rErWPbbbx
And again, EVEN IF you're so religiously and irrationally opposed to using std::optional, you can just return a default-constructed object and an extra bool indicating successful construction. I don't know why you would considering you could just return an optional, but whatever, you can do it that way if that's what you prefer.
You're just wrong about this stuff, and it's this kind of lazy, uniformed criticism of C++ that really rubs me the wrong way. If you wanna use C, use C! Nobody's stopping you, it's a fine language. Just leave the C++ discussions to the people who actually know what the language is.
Earlier quoted context omitted.
>C exists to write fast programs, not to write programs fast. What if you want to write fast programs fast? Also, while not useful for command line tools or for small run once programs, if the software is running continuously or its size is past a certain threshold, it might pay off to use .NET or Java since the speed is not that far of from C. https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://b…
Most programs are not benchmarks.
Earlier quoted context omitted.
>Go and Rust are similar in that aspect. I think this poses a subtle security risk about namespacing. Who authorizes these packages? Who audits these repositories? When you use a C/C++ library, there is obvious accountability. You know who maintains the repository (usually your distribution) or you explicitly copy someone elses code as a subrepository.
If you trust the compiler, why wouldn't you trust the standard library? They're usually made by the same people.
Earlier quoted context omitted.
Keeping it simple to write a compiler is not a serious use case these days. People aren't bootstrapping new platforms from scratch. GCC and Clang are anything but simple.
> Keeping it simple to write a compiler is not a serious use case these days. The implication is that if it is simple to write a parser for a language, then the language is simple to read.
Linking this makes me nostalgic for 2010 :)
Okay, I love C so of course I had to take a look. The buzzwords are impressive, with all the testing and CI and so on, really nice, modern and ambitious. I dove into the code, literally looking at the first true part of the implementation in array/sc_array.h. Two observations, from probably less than tree minutes of reading: 1. The nomenclature with "sc_array_term()" as the destructor (the opposite of sc_array_init()…
Earlier quoted context omitted.
> the terribleness of exceptions is way overhyped It's not that exceptions are terrible. I have nothing against them. The thing is that most of the time they are not affordable, especially in embedded. Some compilers don't even support them (some 8-bit IIRC). Most (including mine) embedded C++ programs have exceptions disabled. > return a `std::optional` The same goes for std . I don't know the overhead of possibly d…
It's that amount of lines UNCOMPILED. Of course uncompiled code wouldn't fit in 64kb of flash (the compiler wouldn't fit either, you know). Compiled, std::optional takes up essentially no overhead, basically the same as if you're returning a single bool along with your object. > This is practical with an efficient heap allocator (which I might not have). What happens if I want a scoped (on stack) instance of a class?…
30KB was a ballpark about exceptions plus std in general, by including things you expect to use when using std (like std::string).
The patterns I knew and saw with std::optional usually returned "new something", but yeah, you can return a copy too if the class fits in the stack.
And I am not religiously and irrationally opposed to anything.
> really rubs me the wrong way
Relax, my friend. Life is short.
Earlier quoted context omitted.
When working on some platforms (e.g. BeagleBoneBlack), the compilation time of C++ is a huge turnoff. Sure, you can cross-compile, but that feels like even more friction.
Wait you ssh into a BeagleBoneBlack and compile C on the device? I’ve seen some janky envs in my life but this is pretty high up. Do you never enable LTO when linking deps? These devices are literally 1000x slower than a typical 8 core desktop.
Exactly how am I supposed to access the hardware that only exists on the Beaglebone Black itself, otherwise?
You can cross-compile all day, but, in the end, I need to code to be running over there to toggle those GPIOs. I need the debugging to be over there. I need VSCode to be running over there.
Not all programming is web programming.
Earlier quoted context omitted.
Wait you ssh into a BeagleBoneBlack and compile C on the device? I’ve seen some janky envs in my life but this is pretty high up. Do you never enable LTO when linking deps? These devices are literally 1000x slower than a typical 8 core desktop.
> Wait you ssh into a BeagleBoneBlack and compile C on the device? Exactly how am I supposed to access the hardware that only exists on the Beaglebone Black itself, otherwise? You can cross-compile all day, but, in the end, I need to code to be running over there to toggle those GPIOs. I need the debugging to be over there . I need VSCode to be running over there . Not all programming is web programming.