Hacker News Reader

Comment by openasocket | Hacker News Reader

This seems to just seems to be replicating the functionality of C++ in C. The only reason he gives for not using C++ is lack of C++ compilers for embedded CPUs. I think a better approach for the long term would be to use a C++ -> C transpiler (as much as I hate that word).

View on HN

I'm saddened by the author going to this trouble. Embedded cpu selection doesn't happen in isolation - or at least, it shouldn't. The available tools are a large part of why you would pick chip A over chip B. If you don't have a C++ compiler, and you end up having to re-invent C++ in C, then maybe you should have picked the chip with decent tools.

If this project really did require re-inventing C++ in C, it must be justified by being fairly large. In which case, a low-end ARM (Cortex M based) microcontroller would have been entirely suitable. All ARMs have multiple C++ toolchains which support them.

If this is a microcontroller you end up lumbered with, and didn't choose, then fair enough, but this effort should be labeled for the hack that it is. This is not best or even good practice.

> If you don't have a C++ compiler, and you end up having to re-invent C++ in C, then maybe you should have picked the chip with decent tools.

So the software engineers are the only ones on the project who get a say as to what chips get used?

No (and that isn't what he said), but surely they should get a say, right?

pslam basically did in his next paragraph:

> If this project really did require re-inventing C++ in C, it must be justified by being fairly large. In which case, a low-end ARM (Cortex M based) microcontroller would have been entirely suitable. All ARMs have multiple C++ toolchains which support them.

ARM is not entirely suitable for any application just because you have complex (for some definition of complex) software.

No, but the software impact of choosing a particular piece of hardware should absolutely be part of the system design process. If it is not, then you are part of a project with bad leadership, or very, very old-fashioned architects.

It's not just ARM - there's plenty of other CPU architectures with modern Clang, GCC, or other toolchains with C++ support. Given that this is a large code base (justifying this amount of work), this cannot be a "tiny" microcontroller, as in 8 bit, and needing to run on microamps. I cannot believe that there were not C++-capable microcontrollers available which would have done the job, without breaking the bank.

Doing it at lowest cost is the point. Because even if you don't lower your cost, your competitors will.

Those low end cortex M's tend to have C++2003.

I am kinda-sorta happy to have C++ at all.

I think.

Embedded world is weird. Changing hardware design is difficult and costly by itself and manufacture process is limited by real world constraints, therefore the largest "part of why you would pick chip A over chip B" is availability, both long-term and short-term: will I be able to source the chip in 5 years? how easy it would be to change delivery schedule if my manufacture schedule changes?. Oh, and ARM looks like a solution until you have to battery operate it.

Cost of the software in embedded systems is quite often low compared to hardware costs. I ballpark lower limit for part cost at $10. I ballpark software development cost at $100k/y or $50/h. Let's say it is reasonable to get software done in a man-year. At 1M units of projected sales, software cost is at 1% of hardware cost (not project cost). At such ballpark estimate software engineers' opinion is only treated as a humble request.

Of course this varies from project to project. Increasing portion of embedded systems are mostly software. Portion of projects have hard-realtime requirements. Here software engineers are benevolent dictators. But that is by no means a general case.

I work mainly on embedded systems and i would much rather work with a different CPU but stuck with the hardware we have.

The compiler I use does have an embedded c++ option but it's limited and has some issues working with the RTOS that's supplied with the compiler. Also with a total of 6K of ram available it's usually easier just to stick to writing plain C.

> use a C++ -> C transpiler (as much as I hate that word)

Why not just use the word "compiler"?

I've encountered this here recently as well, the belief that a 'compiler' has to target machine code. When really a compiler is just a translator from one program language to another.

and even if compilers were those that generate machine code (and they're not), what's wrong with (source-to-source) translator?

Too many people that are locked into the JS mental institution all the time?

Honestly, creating an object-oriented version of C that's not C++ would likely result in a language better than C++. C++ is not a particularly good language.

Reply on news.ycombinator.com