I like C more than I thought I would
-
I'd argue that C++ is valid anywhere C is. It's just - you have to know what you're doing to get it to generate the equivalent machine code you would with C. For example Anywhere in C you take a handle of any sort, that handle becomes the this pointer of a class's instance methods. Inline constructors**, and don't initialize things unless they need to be, etc. Pretty soon you have a C++ rendition of your C code. Same machine code. ** don't actually use the inline keyword, because the compiler doesn't care about it except for linking purposes. I just really mean avoid heavy constructors.
To err is human. Fortune favors the monsters.
I thought the major concern with C++ rather than C was more memory for C++, not more CPU time. That, at least, was what Embedded C++ addressed. C++ allows almost all of C, so it's just a question of when you need C++ things.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
I thought the major concern with C++ rather than C was more memory for C++, not more CPU time. That, at least, was what Embedded C++ addressed. C++ allows almost all of C, so it's just a question of when you need C++ things.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.I think that's only true if you're using the STL. Exceptions also cause hidden overhead, but those things are optional.
To err is human. Fortune favors the monsters.
-
I've always been a C++ nerd. I came at C++ self taught, but I came at it fresh, without "graduating" from writing C code. I've never regarded C++ as OOP, but rather GP oriented, although in truth it's a chameleon, and can do pretty much anything. However, I make heavy use of template based programming. So I didn't think I'd enjoy C. I figured I'd miss templates. I still do. There is some real ugly in terms of things you have to do with C that are elegant in C++. That being said, I don't miss them as much as I thought I would. Also, using the preprocessor freely is kind of liberating. In C++ I use it only as a last resort. In C it's more first class for me. Anyway, I like C. I do wish it had templates! And it's kind of verbose, which is hard on the fingers (everything has a handle) but also it wasn't a huge transition for me, since I do a lot of IoT coding I don't use things like exceptions, nor do I make heavy use of the STL, so C wasn't so bad. :)
To err is human. Fortune favors the monsters.
First time I saw C I immediately liked it. The syntax made sense at a gut level. I had Fortran and Basic under my belt at that time, so not a lot of exposure to other languages, but it was non-case locked, and arbitrary length variable names were a godsend. But I still dislike two items about it. First is the
typedefs that surround allstructs in the MS headers. I still don't understand why that was done, although I never delved into it very much. The second is that everything has to be casted on both sides of the '='. That got old quick. I still like the language, though. C++ is far betterer! And when I finally understood true OOP in C++ I was in heaven!Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
-
First time I saw C I immediately liked it. The syntax made sense at a gut level. I had Fortran and Basic under my belt at that time, so not a lot of exposure to other languages, but it was non-case locked, and arbitrary length variable names were a godsend. But I still dislike two items about it. First is the
typedefs that surround allstructs in the MS headers. I still don't understand why that was done, although I never delved into it very much. The second is that everything has to be casted on both sides of the '='. That got old quick. I still like the language, though. C++ is far betterer! And when I finally understood true OOP in C++ I was in heaven!Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
My path was PL/I, Fortran, C. Never did get into C++. The C++ coding I saw from other programmers was inscrutable. In fact, the problem was they all did their own thing when creating objects. I just didn't want to learn to crawl around in their individual sand boxes of objects and classes. True one can get crazy with C but it's twice as crazy in C++.
"A little time, a little trouble, your better day" Badfinger
-
My path was PL/I, Fortran, C. Never did get into C++. The C++ coding I saw from other programmers was inscrutable. In fact, the problem was they all did their own thing when creating objects. I just didn't want to learn to crawl around in their individual sand boxes of objects and classes. True one can get crazy with C but it's twice as crazy in C++.
"A little time, a little trouble, your better day" Badfinger
Check out the C++ Object Oriented Programming tutorial in my sig. It may be clear enough to understand some of the additional power that C++ gives you with respect to C (without taking templates into account). If you have suggestions for improvement, holler!
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
-
Check out the C++ Object Oriented Programming tutorial in my sig. It may be clear enough to understand some of the additional power that C++ gives you with respect to C (without taking templates into account). If you have suggestions for improvement, holler!
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
Thank you, so much for your response, David. My critique was probably more about the programmers use of C++ than the language. I did a quick look at your article and found it well organized. Good Job. I made a PDF copy of your article to read offline. BTW your complaints about C are also some of mine.
"A little time, a little trouble, your better day" Badfinger
-
Thank you, so much for your response, David. My critique was probably more about the programmers use of C++ than the language. I did a quick look at your article and found it well organized. Good Job. I made a PDF copy of your article to read offline. BTW your complaints about C are also some of mine.
"A little time, a little trouble, your better day" Badfinger
I hope it shines a light on some new stuff for you! Best wishes!
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
-
I hope it shines a light on some new stuff for you! Best wishes!
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
BTW I use Codeblocks for my development environment. It has both a C and C++ environment and works for me. I also have visual studio 2022 installed but not my choice yet. Thanks again. "Light" is the appropriate term as lighting simulations was my line of work for many years.
"A little time, a little trouble, your better day" Badfinger
-
I'd guess that the mantra "C is for embedded" is mostly because of legacy systems. There was also Embedded C++, which removed templates, exceptions, and RTTI. Memory is now so cheap that C is only justified in small systems. I wouldn't sign onto a C project unless the team was small and disciplined. The risk of dealing with hacked-together code is simply too great. "Embedded" is a broad spectrum. At the toaster end, C is fine, but it quickly becomes unjustified as one moves away from that.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Embedded has multiple layers. A tv remote has a microcontroller in it, definitely won't support a C++ program.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
First time I saw C I immediately liked it. The syntax made sense at a gut level. I had Fortran and Basic under my belt at that time, so not a lot of exposure to other languages, but it was non-case locked, and arbitrary length variable names were a godsend. But I still dislike two items about it. First is the
typedefs that surround allstructs in the MS headers. I still don't understand why that was done, although I never delved into it very much. The second is that everything has to be casted on both sides of the '='. That got old quick. I still like the language, though. C++ is far betterer! And when I finally understood true OOP in C++ I was in heaven!Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
David O'Neil wrote:
First is the typedefs that surround all structs in the MS headers. I still don't understand why that was done,
Quirkiness of old C standard: when using struct the type is actually
struct typeand nottype. With ANSI C you would have to declare every variable of typetypeasstruct type variable;
rather than the most sensible
type variable;
A way to get around that is using typedef.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
David O'Neil wrote:
First is the typedefs that surround all structs in the MS headers. I still don't understand why that was done,
Quirkiness of old C standard: when using struct the type is actually
struct typeand nottype. With ANSI C you would have to declare every variable of typetypeasstruct type variable;
rather than the most sensible
type variable;
A way to get around that is using typedef.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
Thank you. That makes sense. I hate it!
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
-
Thank you. That makes sense. I hate it!
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
I hate it so much. And I like VisualStudio because at lerast since 2008, maybe before but after VisualStudio 6, it allowed mixing C++ syntax in C source so we could do without a lot of old C absurdities. Also C99 fixed a lot of these inconsistencies, but MS headers were written long before it.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
I've always been a C++ nerd. I came at C++ self taught, but I came at it fresh, without "graduating" from writing C code. I've never regarded C++ as OOP, but rather GP oriented, although in truth it's a chameleon, and can do pretty much anything. However, I make heavy use of template based programming. So I didn't think I'd enjoy C. I figured I'd miss templates. I still do. There is some real ugly in terms of things you have to do with C that are elegant in C++. That being said, I don't miss them as much as I thought I would. Also, using the preprocessor freely is kind of liberating. In C++ I use it only as a last resort. In C it's more first class for me. Anyway, I like C. I do wish it had templates! And it's kind of verbose, which is hard on the fingers (everything has a handle) but also it wasn't a huge transition for me, since I do a lot of IoT coding I don't use things like exceptions, nor do I make heavy use of the STL, so C wasn't so bad. :)
To err is human. Fortune favors the monsters.
I too is the same, started in C language in 1992 and in a few years, I graduated to C++ and I loved it. However, my last project included over 400,000 lines of MFC/C++ code and a lot of memory. So much memory (CStrings!) it would crash in 2 weeks for no reason. I finally figured out that the CStrings were eating up memory. I changed most of the CStrings with common C language variables (static arrays [], chars etc). More work but running smoothly.
-
I've always been a C++ nerd. I came at C++ self taught, but I came at it fresh, without "graduating" from writing C code. I've never regarded C++ as OOP, but rather GP oriented, although in truth it's a chameleon, and can do pretty much anything. However, I make heavy use of template based programming. So I didn't think I'd enjoy C. I figured I'd miss templates. I still do. There is some real ugly in terms of things you have to do with C that are elegant in C++. That being said, I don't miss them as much as I thought I would. Also, using the preprocessor freely is kind of liberating. In C++ I use it only as a last resort. In C it's more first class for me. Anyway, I like C. I do wish it had templates! And it's kind of verbose, which is hard on the fingers (everything has a handle) but also it wasn't a huge transition for me, since I do a lot of IoT coding I don't use things like exceptions, nor do I make heavy use of the STL, so C wasn't so bad. :)
To err is human. Fortune favors the monsters.
Another good argument for using C++ templates is its capability to "inject" code into algorithms. I mean that C is forced to use callbacks to expand the functionality of the algorithms: with C++ you can pass the "portion" of the algorithm that extends the functionality of the base algorithm as a template argument to a template parameter. Functors (or lambdas, they are the same beast) which has code declared inline, it is generally injected into the template of the base algorithm. For example, the classic C library qsort algorithm, ignoring the fact that it forces you to play dangerously with casts to connect arguments to the callback function parameters, produces a function call for each comparison. If the algorithm (which is never a pure qsort but is a modified version, e.g. introsort) has to do with many elements and the compare function is inexpensive, it turns out that the biggest waste of time is in the invocation of the callback. In fact, especially when dealing with processors without caches or sophisticated branch prediction mechanisms, which is almost always the case with small MCUs, a function call can cost a lot. This means that, apart from code bloating (which with modern MCUs is no longer a big problem since they have a lot of Flash), C++ is often faster than C, unless a C programmer writes everything by hand and doesn't use any library facility. This gives the possibility to use the just-ready STL or Boost algorithms that do not need exceptions or dynamic allocation, customizing them efficiently. I want to remind all of you that usually the above code is written better than we could do and, in general, it is already debugged. And yes, using custom allocators and the placement-new operator, C++ can do what C does and many times it does even better: that is, C++, with a little care, can be happily used on small embedded systems. Cheers
-
Another good argument for using C++ templates is its capability to "inject" code into algorithms. I mean that C is forced to use callbacks to expand the functionality of the algorithms: with C++ you can pass the "portion" of the algorithm that extends the functionality of the base algorithm as a template argument to a template parameter. Functors (or lambdas, they are the same beast) which has code declared inline, it is generally injected into the template of the base algorithm. For example, the classic C library qsort algorithm, ignoring the fact that it forces you to play dangerously with casts to connect arguments to the callback function parameters, produces a function call for each comparison. If the algorithm (which is never a pure qsort but is a modified version, e.g. introsort) has to do with many elements and the compare function is inexpensive, it turns out that the biggest waste of time is in the invocation of the callback. In fact, especially when dealing with processors without caches or sophisticated branch prediction mechanisms, which is almost always the case with small MCUs, a function call can cost a lot. This means that, apart from code bloating (which with modern MCUs is no longer a big problem since they have a lot of Flash), C++ is often faster than C, unless a C programmer writes everything by hand and doesn't use any library facility. This gives the possibility to use the just-ready STL or Boost algorithms that do not need exceptions or dynamic allocation, customizing them efficiently. I want to remind all of you that usually the above code is written better than we could do and, in general, it is already debugged. And yes, using custom allocators and the placement-new operator, C++ can do what C does and many times it does even better: that is, C++, with a little care, can be happily used on small embedded systems. Cheers
Absolutely, although I would not use STL and and Boost on most IoT class MCUs, and the reason his heap fragmentation. When you're dealing with say 360KB of usable SRAM (the amount available for use on an ESP32) or less, the struggle is real. STL just takes a big steamer all over your heap.
To err is human. Fortune favors the monsters.
-
I too is the same, started in C language in 1992 and in a few years, I graduated to C++ and I loved it. However, my last project included over 400,000 lines of MFC/C++ code and a lot of memory. So much memory (CStrings!) it would crash in 2 weeks for no reason. I finally figured out that the CStrings were eating up memory. I changed most of the CStrings with common C language variables (static arrays [], chars etc). More work but running smoothly.
Well, to be clear, I started with C++, not C, but yeah. =) CString, std::string and the like are a mess.
To err is human. Fortune favors the monsters.
-
Absolutely, although I would not use STL and and Boost on most IoT class MCUs, and the reason his heap fragmentation. When you're dealing with say 360KB of usable SRAM (the amount available for use on an ESP32) or less, the struggle is real. STL just takes a big steamer all over your heap.
To err is human. Fortune favors the monsters.
honey the codewitch wrote:
Absolutely, although I would not use STL and and Boost on most IoT class MCUs, and the reason his heap fragmentation.
I understand, but I wasn't talking about STL containers: I was talking about "algorithms". Many ready-to-use algorithms only work on data in place. However, you can use STL algorithms on standard C arrays (basically pointers are "random access iterators", intended as the category, aren't they?). If you like templates can always use std::array which has zero overhead with respect C array.
honey the codewitch wrote:
When you're dealing with say 360KB of usable SRAM (the amount available for use on an ESP32) or less, the struggle is real. STL just takes a big steamer all over your heap.
I started programming MCUs like 6805 in pure assembly up to MC68000 in "pure C". So I know well what are you talking about. :) Regards.
-
honey the codewitch wrote:
Absolutely, although I would not use STL and and Boost on most IoT class MCUs, and the reason his heap fragmentation.
I understand, but I wasn't talking about STL containers: I was talking about "algorithms". Many ready-to-use algorithms only work on data in place. However, you can use STL algorithms on standard C arrays (basically pointers are "random access iterators", intended as the category, aren't they?). If you like templates can always use std::array which has zero overhead with respect C array.
honey the codewitch wrote:
When you're dealing with say 360KB of usable SRAM (the amount available for use on an ESP32) or less, the struggle is real. STL just takes a big steamer all over your heap.
I started programming MCUs like 6805 in pure assembly up to MC68000 in "pure C". So I know well what are you talking about. :) Regards.
Fair enough. When you said algorithms I thought you were including things like hashtables.
To err is human. Fortune favors the monsters.
-
I'd guess that the mantra "C is for embedded" is mostly because of legacy systems. There was also Embedded C++, which removed templates, exceptions, and RTTI. Memory is now so cheap that C is only justified in small systems. I wouldn't sign onto a C project unless the team was small and disciplined. The risk of dealing with hacked-together code is simply too great. "Embedded" is a broad spectrum. At the toaster end, C is fine, but it quickly becomes unjustified as one moves away from that.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Quote:
I'd guess that the mantra "C is for embedded" is mostly because of legacy systems. There was also Embedded C++, which removed templates, exceptions, and RTTI. Memory is now so cheap that C is only justified in small systems.
I tend to enforce it on my teams the other way around: provide a real justification for using C++ over C. It becomes very hard to justify using C++ over C for embedded projects that cannot use exceptions, as at that point you're into real implementation-defined behaviour which changes with the compiler being used, or even the flags passed to it. When C is not suitable for some problem space, I don't find myself reaching for C++ because there are much nicer languages. C++ is in this weird position - for very small embedded systems, C is better, for very large embedded systems (SBCs, for example), any other high-level language can be used. For uncrippled C++, the target needs to be larger than atmega level and smaller than Raspberry Pi level. Not a lot of need in that particular niche.
Quote:
I wouldn't sign onto a C project unless the team was small and disciplined. The risk of dealing with hacked-together code is simply too great.
I would. C is one of the easier languages to unf***k. A C++ project that was hacked together can be very difficult to reason about (OTOH, A Lisp project that was hacked together may as well be thrown away)
-
I do like overloading and increased type safety, but those are things you can find in other languages. And sure C# has generics but it's just not the same. I can make the C++ compiler dance the tango in a way I just can't with any other language, and it's not me - it's the compiler. Metaprogramming, for example. There's nothing else that really compares to it, at least not in common use. So that's why I miss them, and why they stand out to me. You can't do it in other languages. It sets C++ apart.
To err is human. Fortune favors the monsters.
Quote:
You can't do it in other languages. It sets C++ apart.
You could do more metaprogramming stuff in Lisp in the 80s than you can do, right now, with C++ templates. I used to use Lisp quite often (SBCL, sometimes gcl/ecl), and find C++ templates a poor substitute for AST manipulation.
