Isn't this undefined behavior?
Unfortunely many keep needing education on such matters.
> You can store a null pointer in any lvalue whose data type is a pointer type. [0]
Though, I would expect a complaint from clang, and clang-tidy.
[0] https://www.gnu.org/software/c-intro-and-ref/manual/html_nod...
Overall, it is still far more portable than C++ or any other new language.
Heck I learned to program in C++, back when DR-DOS 5 was the latest version, and all I had available was 640 KB to play around, leaving aside MEMMAX.
Nowadays the only reason many embedded developers keep using C is religous.
I think you're making some extraordinary claims. I'd love to see some receipts. :-)
Still using tcc, or stuck in GCC 5 ?
There are quite a few besides various PICs AFAIK, how modern they are is subjective I guess, and it IS mostly the weaker chips. Keil, Renesas, NXP, STMicro (STM8 MCUs used to be C only, not sure today) all sell parts where C++ is unsupported.
> Nowadays the only reason many embedded developers keep using C is religous.
I don’t completely agree, but I see where you are coming from.
The simplest tool that gets the job done is often the best IMO.
In my experience, it is much more difficult to learn C++ well enough to code safely, compared to C.
Many embedded developers are more EE than CS, so simpler software is often preferred.
I know you don’t have to use all the C++ features, all at once, but still :)
Horses for courses. I prefer C for anything embedded.
The speed at which you can write great C code often far outstrips other languages which are applicable to the problem domain.
All languages are a compromise, there are no silver bullets.
It could work if "maybe(T)" is completely opaque to the user; both checking and accessing its payload must happen through helper macros; the checking macro ticks an invisible flag if ok; the accessing macro returns the payload only if the invisible flag is ticked, otherwise it triggers a runtime error/exception.
Not impossible. However, you would need to replace all "p.ok" with "maybe_check(p)", which is not unreasonable, and all "p.value" with "maybe_value(p)", which might be too much for the final user...
nly•10h ago
https://gcc.godbolt.org/z/vfzK9Toz4
uecker•9h ago
JonChesterfield•8h ago
uecker•7h ago
pjmlp•8h ago
uecker•6h ago
pjmlp•6h ago
uecker•6h ago
pjmlp•3h ago
At least that is something we can agree on, C and C++ are both languages where developers could write robust code, and the large majority seldom does it.
uecker•2h ago
wahern•9h ago
pwdisswordfishz•9h ago
pjmlp•8h ago
https://gcc.godbolt.org/z/31o75W5xx
https://gcc.godbolt.org/z/av6a43WeY
uecker•6h ago
But what matters is run-time behavior for any input. And sorry, C++'s complexity still has the effect that the code is terrible: https://godbolt.org/z/vWfjjf8rP
In C, the compiler can remove all error paths: https://godbolt.org/z/GGMcc6bxv
account42•7h ago
It's still a damned shame. Same for not being able to pass optional/unique_ptr/etc in a register.
We really need a trivially_relocatable attribute.