Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C/C++ Embedded Files (2013)

4rknova.com

Post reply on HN
Print view View original

41–50 of 57 posts

Re: C/C++ Embedded Files (2013)

#41

Post by germandiago »

david2ndaccount wrote: post #16
rolandhvar wrote: post #7

Earlier quoted context omitted.

The thing that always irks me about c++ is this sort of thing: > Explanation 1) Searches for the resource identified by h-char-sequence in implementation-defined manner. Okay, so now I have to make assumptions that the implementation is reasonable, and won't go and "search" by asking an LLM or accidentally revealing my credit card details to a third party, right? And even if the implementation _is_ reasonable the onl…

If you want to remain portable, write your code in the intersection of the big 3 - GCC, Clang and MSVC - and you’ll be good enough. Other implementations will either be weird enough that many things you’d expect to work won’t or are forced to copy what those 3 do anyway.

This is what I have been doing for years. Works well for me.

Sometimes it is annoying but realistically it is a good strategy.

Re: C/C++ Embedded Files (2013)

#42

Post by array_key_first »

jcalvinowens wrote: post #22
oguz-ismail2 wrote: post #14

Earlier quoted context omitted.

Don't know what you mean, it works fine here. Python is too large and unreliable a dependency for something so trivial (which can be accomplished using standard POSIX utilities if need be).

Python is pretty much mandatory for Linux systems nowadays, unless you're dealing with something really minimalist or trying to be very portable it's safe to rely on.

I know people who wont even write perl and will instead write shell scripts, because perl might not be available. And I don't think I've seen a unix-like system without perl.

Re: C/C++ Embedded Files (2013)

#43

Post by oguz-ismail2 »

array_key_first wrote: post #42
jcalvinowens wrote: post #22

Earlier quoted context omitted.

Python is pretty much mandatory for Linux systems nowadays, unless you're dealing with something really minimalist or trying to be very portable it's safe to rely on.

I know people who wont even write perl and will instead write shell scripts, because perl might not be available. And I don't think I've seen a unix-like system without perl.

> a unix-like system without perl

QNX was one. Don't know if they started to include it in newer versions than 6.5 though

Re: C/C++ Embedded Files (2013)

#44

Post by monegator »

ranger_danger wrote: post #38
monegator wrote: post #19

Earlier quoted context omitted.

let me know when my embedded target's compiler is C23 compliant (i mean, i whish. we may be getting C11 or even C17 some times next year but i'm not holding my breath)

What current embedded target in $this_year doesn't have a C11 compiler? I'll send you $5 if you can name one.

easy: microchip.

Re: C/C++ Embedded Files (2013)

#45

Post by afiori »

CamouflagedKiwi wrote: post #10
rolandhvar wrote: post #7

Earlier quoted context omitted.

The thing that always irks me about c++ is this sort of thing: > Explanation 1) Searches for the resource identified by h-char-sequence in implementation-defined manner. Okay, so now I have to make assumptions that the implementation is reasonable, and won't go and "search" by asking an LLM or accidentally revealing my credit card details to a third party, right? And even if the implementation _is_ reasonable the onl…

This doesn't sound like the kind of portability anyone is really worried about. I get that the docs on the linked site are written in standards-ese and are complicated by macro replacement, but I don't think the outcome of sending your credit card details away is gonna be an outcome. If it was, an uncharitable implementation with access to your card details would be free to do that any time you gave it input invoking…

which makes me consider an interesting distinction, undefined behavior refers to the behavior of the compiler output, does the C standard "allow" compilers to do compile-time code executions with undefined behavior? is the runtime behavior of the compiler even in scope for the standard in general?

Re: C/C++ Embedded Files (2013)

#46

Post by mgaunard »

array_key_first wrote: post #42
jcalvinowens wrote: post #22

Earlier quoted context omitted.

Python is pretty much mandatory for Linux systems nowadays, unless you're dealing with something really minimalist or trying to be very portable it's safe to rely on.

I know people who wont even write perl and will instead write shell scripts, because perl might not be available. And I don't think I've seen a unix-like system without perl.

Perl is obsolete and was replaced by Python for all usages in practice.

Re: C/C++ Embedded Files (2013)

#48

Post by indigoabstract »

gmueckl wrote: post #29
indigoabstract wrote: post #28

Earlier quoted context omitted.

That's good to know, but I've noticed it was added in C++26 and seems to be supported in GCC 15 and Clang 19, but not MSVC. I think in a few (3-4?) years it will be safe to use, but in any case not now. Still, good to know that it exists.

I would assume that this is easy enough to implement that it will likely appear in a minor update to the upcoming Visual Studio version. MS kept updating the compiler since VS 2022, too.

I certainly hope so, but we'll see. To give an example, std::chrono::current_zone (C++20) still doesn't work on Android even to this day.

So as long as #embed isn't supported by all the 3 major compilers, I am sticking with my current embedding setup. I guess that's what I was thinking of.

Re: C/C++ Embedded Files (2013)

#49

Post by TUSF »

monegator wrote: post #19
gavinray wrote: post #2

Outdated, modern solution is baked in now https://en.cppreference.com/w/c/preprocessor/embed

let me know when my embedded target's compiler is C23 compliant (i mean, i whish. we may be getting C11 or even C17 some times next year but i'm not holding my breath)

cake[0] might interest you. Basically transpiles C into C89.

[0]: https://github.com/thradams/cake

Re: C/C++ Embedded Files (2013)

#50

Post by array_key_first »

mgaunard wrote: post #46
array_key_first wrote: post #42

Earlier quoted context omitted.

I know people who wont even write perl and will instead write shell scripts, because perl might not be available. And I don't think I've seen a unix-like system without perl.

Perl is obsolete and was replaced by Python for all usages in practice.

Right... except for the use case I pointed out. That being that perl is available on virtually every unix like operating system, not just Linux, and python isn't.

Also, perl has other uses. Perl is much more competent at awk/sed/grep like tasks than python, and it can also be much faster. More people should be writing perl, imo. There's a ton of programs written in C that should just be perl.

Post reply on HN