C++ for embedded: how to learn it in 2021?

[westfw]

arguments for and against

Heh.  In C, you can do powerful but dangerous things because the language is "lightweight"and doesn't stop you.
In C++, they keep complexifying the language to allow similar things to be done.

I don't know for sure which is better.

[magic]

1. While the language standards stipulates that conceptually default constructors is called for every new object created, the C++ language also mandates that compilers should generate code with zero cost abstraction. What this means, default constructors will have no run-time cost if they don't need to do work (see code examples below). Furthermore, if you delete default constructors (as per your suggestion), then you disable your ability to create objects, which doesn't make sense at all.

Yes, it does, because you can define your own constructors.
(That being said, I don't understand what the original issue with implicit constructors allocating memory was supposed to be, I suspect an XY problem).

And when covid prevents you from going to work, create a valid C++ program that never finishes compiling - because the compiler spits out the sequence of prime numbers during compilation. The C++ language design committee refused to believe that was possible, until Erwin Unruh rubbed the committee's nose in it!

It's not possible.
Compilers won't let you get past about 1000

[tggzzz]

And when covid prevents you from going to work, create a valid C++ program that never finishes compiling - because the compiler spits out the sequence of prime numbers during compilation. The C++ language design committee refused to believe that was possible, until Erwin Unruh rubbed the committee's nose in it!

It's not possible.
Compilers won't let you get past about 1000

I've read that is correct.

That magic number would have been added to compilers after their "capability" was demonstrated. ISTR that exceeding the magic number is defined to turn an otherwise valid C++ program into an invalid one.

Does anybody think that is anything other than ridiculous? Yes, it is amusing and demonstrates the "power" of the language, but that can be achieved using brainfuck!

[DiTBho]

At the moment, I need the language to help me with polymorphic things.

[SiliconWizard]

arguments for and against

Heh.  In C, you can do powerful but dangerous things because the language is "lightweight"and doesn't stop you.
In C++, they keep complexifying the language to allow similar things to be done.

I don't know for sure which is better.

I have an idea about this.

[SiliconWizard]

At the moment, I need the language to help me with polymorphic things.

Could you give examples of what you'd like to achieve?

[Nominal Animal]

At the moment, I need the language to help me with polymorphic things.

Could you give examples of what you'd like to achieve?

DiTBho already mentioned a practical one in #2: a B*tree for three different types of keys: unsigned 32-bit integers, strings, and points (or axis-aligned rectangles).  Each tree only has one type of key, of course; so basically three "different" B*trees needed.

As emece pointed out, I should have included constexpr in my list.

[SiliconWizard]

At the moment, I need the language to help me with polymorphic things.

Could you give examples of what you'd like to achieve?

DiTBho already mentioned a practical one in #2: a B*tree for three different types of keys: unsigned 32-bit integers, strings, and points (or axis-aligned rectangles).  Each tree only has one type of key, of course; so basically three "different" B*trees needed.

There's a number of ways to do this in C, just like there's a number of ways to do it in C++.

In C, the typical approach would be to use pointers to "keys". The keys could be objects defined as structures holding either directly the information needed for the key, or a pointer to it, and then one or more functions acting on the key.

This might look like a pretty "manual" way of doing OO, but in practice, when done properly, it's not that much different nor even that many more lines of code. I see practically no difference in the number of lines of code needed for either approach. The C one even possibly takes fewer. The assumption that using C++ would take "orders of magnitude" less effort is not just exaggerated, it's not even backed by reality.

Of course, one benefit of C++ is that it will do more typechecking - sure polymorphic stuff in C is not without risks - and will be potentially more efficient at run time, but even that remains to be checked in practice.

Another approach is to use the preprocessor. Oh yeah, that's so bad, I know.
One thing that would make it easier IMO with the preprocessor is if we could write multi-line macros without having to put a backslash at the end of every line. That's pretty annoying and looks terrible. A simple addition to the preprocessor would allow this. (That could be an opening "[[" and closing "]]", which is used in other languages for writing multi-line strings, for instance...)

But yeah, better generic programming is a good feature. I'm not sure C++ templates and/or a mess of inherited objects is really what we could call good generic programming though. But that's of course a discussion that could last for years.

[magic]

Start with figuring out the requirements because there are many ways to skin the cat.
Speed?
Code size?
Structure size?

Dumb OO approach a'la Java or "C with classes": equip each key object with a pointer to a list of pointers to functions implementing overloaded operators for that key type. Automatic in OO languages, or you could code this in vanilla C if you feel masochistic.

A smarter approach to the above: recognize that it's the same pointer for each key and store it only once in the root of the tree. You can code this in C with little effort: pass the key operators pointer as an argument to internal tree traversal functions, API entry points read the pointer from the root.
BONUS:
Type safety in vanilla C. Don't store the pointer in the root. Take it as an argument to tree_insert(), tree_lookup(), etc and hide those functions from users. For API entry points, create wrappers:

Code: [Select]

struct {some_function_pointer; other_function_pointer;} int_key_ops;
struct int_tree {struct tree tree;};
xxx int_tree_insert(struct int_tree *it, yyy) {return tree_insert(int_key_ops, it.tree, yyy);}
Speed/size tradeoff: separate version of code for each key type, possibly inlined comparison operators. Easily and cleanly solved with C++ templates, maybe doable in C if you compile the same .c file to different .o files with different #defines set by command line.

[AntiProtonBoy]

1. While the language standards stipulates that conceptually default constructors is called for every new object created, the C++ language also mandates that compilers should generate code with zero cost abstraction. What this means, default constructors will have no run-time cost if they don't need to do work (see code examples below). Furthermore, if you delete default constructors (as per your suggestion), then you disable your ability to create objects, which doesn't make sense at all.

Yes, it does, because you can define your own constructors.

Sure, if you want to make your own custom constructors, that's another issue all together. But deleting default constructors on its own doesn't make sense.

[DiTBho]

In C, the typical approach would be to use pointers to "keys". The keys could be objects defined as structures holding either directly the information needed for the key, or a pointer to it, and then one or more functions acting on the key.

This might look like a pretty "manual" way of doing OO, but in practice, when done properly, it's not that much different nor even that many more lines of code. I see practically no difference in the number of lines of code needed for either approach.

I did it in C for production and it works very well, but its backstage was a pretty masochistic experience, I am somehow proud of my code because it also looks shiny and nice, but not so happy because it took me 3 months from the draft to the official commit.

[DiTBho]

pass the key operators pointer as an argument to internal tree traversal functions, API entry points read the pointer from the root.

yes, I did something similar.
Not tricky to design, not difficult to implement, but it requires a lot of effort and it's a bit tricky to test.

[tggzzz]

pass the key operators pointer as an argument to internal tree traversal functions, API entry points read the pointer from the root.

yes, I did something similar.
Not tricky to design, not difficult to implement, but it requires a lot of effort and it's a bit tricky to test.

Do you think it will be easier in C++? If so, why?

[DiTBho]

axis-aligned rectangles

yup! precisely.

planned for the new firmware, also complex numbers in Euler form (r, theta) --> r * e^ (i * theta)

[DiTBho]

Do you think it will be easier in C++? If so, why?

you don't have to care about inner details to make things working OO.
Also, you can overload operators, therefore you have less functions to test, and less testcases.

[brucehoult]

And when covid prevents you from going to work, create a valid C++ program that never finishes compiling - because the compiler spits out the sequence of prime numbers during compilation. The C++ language design committee refused to believe that was possible, until Erwin Unruh rubbed the committee's nose in it!

It's not possible.
Compilers won't let you get past about 1000

I've read that is correct.

That magic number would have been added to compilers after their "capability" was demonstrated. ISTR that exceeding the magic number is defined to turn an otherwise valid C++ program into an invalid one.

Does anybody think that is anything other than ridiculous? Yes, it is amusing and demonstrates the "power" of the language, but that can be achieved using brainfuck!

I have no objections to a language enabling you to compute prime numbers at compile-time -- in fact I desire it highly.

I do, however, want it to be as easy to express and to run as quickly as if I wrote a small stand-alone program to do that, and this program was compiled and run as part of the build process.

[magic]

Do you think it will be easier in C++? If so, why?

you don't have to care about inner details to make things working OO.
Also, you can overload operators, therefore you have less functions to test, and less testcases.

I'm with tggzzz here; I can't see how this solution written in C++ could be anything other than exactly the same code as in C.
Only the duplicated type safety wrappers could be easier (templates).

You can't use overloads in generic code unless they are virtual methods/operators, in which case you are doing the "dumb OO" solution and might as well go for J*va - "compile once, hog memory everywhere". And if you use templates, you are duplicating this code, which is again not the same thing anymore. Maybe you don't care, fair enough.

Not sure how testing with a bunch of different overloads is simpler than with a bunch of ordinary functions. It's basically same thing

[tggzzz]

And when covid prevents you from going to work, create a valid C++ program that never finishes compiling - because the compiler spits out the sequence of prime numbers during compilation. The C++ language design committee refused to believe that was possible, until Erwin Unruh rubbed the committee's nose in it!

It's not possible.
Compilers won't let you get past about 1000

I've read that is correct.

That magic number would have been added to compilers after their "capability" was demonstrated. ISTR that exceeding the magic number is defined to turn an otherwise valid C++ program into an invalid one.

Does anybody think that is anything other than ridiculous? Yes, it is amusing and demonstrates the "power" of the language, but that can be achieved using brainfuck!

I have no objections to a language enabling you to compute prime numbers at compile-time -- in fact I desire it highly.

I do, however, want it to be as easy to express and to run as quickly as if I wrote a small stand-alone program to do that, and this program was compiled and run as part of the build process.

Why is it so valuable?
Isn't there a simpler alternative to achieve the same ends?
Why is there a magic number in the compiler; how can you be sure your application won't exceed it sometime in the future?

Note that the language designers initially denied it was possible, only conceding the point when Erwin Unruh demonstrated it. The template language unexpectedly turned out to be Turing complete.

If the language is so complex the designers don't understand what they have created, what chance do ordinary developers stand?

[magic]

Why is it so valuable?
Isn't there a simpler alternative to achieve the same ends?

Is there?
Like it or not, C++ is the only language which makes generating and using duplicated code that easy.
Templates are perhaps its most appealing aspect - everybody has some "objects" stuff nowadays.

Why is there a magic number in the compiler; how can you be sure your application won't exceed it sometime in the future?

The minimum number specified by C++11 is greater than 640 so it should be enough for everyone.
A sane application probably won't need more than 100 and you know how much it is when writing the code.
GCC has a command line switch if you need more, but they warn that it may run out of stack (perhaps ulimit could help).

If the language is so complex the designers don't understand what they have created, what chance do ordinary developers stand?

Could say the same about almost anything.
Just consider the amount of security bugs everywhere.

[tggzzz]

Why is it so valuable?
Isn't there a simpler alternative to achieve the same ends?

Is there?
Like it or not, C++ is the only language which makes generating and using duplicated code that easy.

Complete nonsense. Many languages have that capability; the first of many was designed in the 1950s!

Templates are perhaps its most appealing aspect - everybody has some "objects" stuff nowadays.

Yes, C++ is a "little bit of this" and a "little bit of that" - none done well. I prefer things that do one thing well, not many things poorly.

If you need objects, use a decent OOP, not a language with them bolted on as an afterthought.

[tggzzz]

If the language is so complex the designers don't understand what they have created, what chance do ordinary developers stand?

Could say the same about almost anything.
Just consider the amount of security bugs everywhere.

Don't confuse language mis-design with poorly designed things written in the language. Don't build castles on sand.

People are moving away from C++ for reasons of security, amongst things. Even the Linux kernel will soon have Rust in it for those and other reasons.

[magic]

Complete nonsense. Many languages have that capability; the first of many was designed in the 1950s!

Fine, the only low level one.
Lisp or whatever other brainfsck don't count

People are moving away from C++ for reasons of security, amongst things. Even the Linux kernel will soon have Rust in it for those and other reasons.

If you can move off of C++ you probably didn't need it in the first place.

Regarding it being a mess, no disagreement.

[DiTBho]

People are moving away from C++ for reasons of security, amongst things. Even the Linux kernel will soon have Rust in it for those and other reasons.

So, are you suggesting learning Rust instead of C++?

Do you think it will be reasonable to try to design an implementation of the next sewing machine firmware in Rust (at least as a "real" learning exercise)?

[brucehoult]

And when covid prevents you from going to work, create a valid C++ program that never finishes compiling - because the compiler spits out the sequence of prime numbers during compilation. The C++ language design committee refused to believe that was possible, until Erwin Unruh rubbed the committee's nose in it!

It's not possible.
Compilers won't let you get past about 1000

I've read that is correct.

That magic number would have been added to compilers after their "capability" was demonstrated. ISTR that exceeding the magic number is defined to turn an otherwise valid C++ program into an invalid one.

Does anybody think that is anything other than ridiculous? Yes, it is amusing and demonstrates the "power" of the language, but that can be achieved using brainfuck!

I have no objections to a language enabling you to compute prime numbers at compile-time -- in fact I desire it highly.

I do, however, want it to be as easy to express and to run as quickly as if I wrote a small stand-alone program to do that, and this program was compiled and run as part of the build process.

Why is it so valuable?
Isn't there a simpler alternative to achieve the same ends?
Why is there a magic number in the compiler; how can you be sure your application won't exceed it sometime in the future?

Note that the language designers initially denied it was possible, only conceding the point when Erwin Unruh demonstrated it. The template language unexpectedly turned out to be Turing complete.

If the language is so complex the designers don't understand what they have created, what chance do ordinary developers stand?

You apparently are talking about C++. I am not.

C++ doesn't make compile time computation as easy to express as runtime computation.

C++ doesn't execute compile time computation as efficiently as runtime computation -- it is orders of magnitude slower. And it has stupidly low arbitrary limits on it.

I want something much much better than C++. And it has existed for many decades in the form, for example, of Common Lisp. FORTH also has similar abilities.

[magic]

So, are you suggesting learning Rust instead of C++?

It's tggzzz, not me. And has indeed already done exactly that yesterday.

I'm not familiar with Rust but what I can say is that I haven't seen them produce a decent migration guide for C/C++ developers and trying to learn the language from their "tutorials" is pain because they are written with little explanation of how the various constructs are implemented and how they relate to established languages.