C++?

Posted on May 17, 2011 at 12:24

I have used c++ in an embedded environment on ARMs for years. It has been on ones with external SDRAM.

I considered using C++ on a small application for the NXP LPC2103.

I did not in the end just for the sort of reasons you are getting in to. I used C++ like structures in a similar way to how I would have done it in C++.

The code that GCC made was very good and gave me confidence that some elements of C++ would work well even on very small applications.

If you get it working I would look at using C++ again. If and when ST bring out parts with more memory then C++ on those chips will be pretty common. A lot of common coding practices used on C++ will not work well on chips with very small amounts of RAM.

Good Luck, and keep posting!

Posted on May 17, 2011 at 12:24

I'm an electronics engineer too, I totally get where you're coming from. I've got this friend (also an EE) that makes access control products. He works entirely on 8051 assembler, and he does pretty complex things, considering. I don't know how he does it, but he does. There's really no getting through to him. He says learning C involves time he doesn't got. He says he doesn't really need the complexity of C, and that's evidenced by his making of adequate products without it. He says assembler is just simpler, but you and I know it's not.

Think of the cost: the ugliness of the job, the unnecessary hours, the difficulty in adding a feature later, the overall inferior quality of the result, etc. He incurs all these costs because he thinks assembler is simpler than C. In the same sense that that's not true, your statement:

Quote:

C is much simpler and easier to learn for non software experts like me.

is also false, IMHO. In the words of Bjarne Stroustrup, C++ creator, C++ is first and foremost ''a better C''. As many rough corners of C as possible were smoothed out without breaking compatibility, and many new features were introduced. You don't have to know them all, you can learn as you go, as C++ was designed with this principle: what you don't know won't hurt you.

Think of how these features can improve your C programming in a flash, without you having to know anything about OO:

-const modifier (retrofitted into C): cleaner, safer and faster code

-inline functions (retrofitted into C): cleaner, safer and faster code

-definition of locals anywhere in code (retrofitted into C): a little bit of sanity added to C! helps the optimizer

(I believe typedef also comes from C++)

-references: automatic pointers without the cumbersome * and -> operators

-exceptions: handling of errors at the right abstraction level (no more checking errors after every call), higher non-error performance

-templates: turns those ugly macros into safe and efficient code

-template libs: safe high performance containers without casts

-operator new/delete: safer malloc without casts

-operator overloading: safer smaller and faster printf and scanf, syntatic sugar everywhere on libraries

-class libs: a language with more types, such as efficient complex numbers, that you can use like they were built-ins (no need to know anything about OO), easier/auto resource management via constructors and destructors

forced initialization (under some circumstances): safer code

These come out of the top of my head now, I'm sure there are many others. The best advice that I can give you is to read The C++ Programming Language by Stroustrup ASAP. The book, from a literary standpoint, is the best written technical book I had the pleasure of reading. So clear and sharp, it sure is a reflection of the author's mind. Also, C++ itself is beautiful and I'm sure you'll get hooked.

I read this book at the beach in the early 90's. I didn't know C at the time (it's not necessary), and this was many months before I had my first compiler. I couldn't put it down.

Posted on May 17, 2011 at 12:24

Quote:

I believe there's not a single reason to prefer c over c++.

Well C is much simpler and easier to learn for non software experts like me. But you are probably well versed in C++ so it doesn't matter to you. As an electrical engineer and not a software developer, C is much more practical for me.

I tried C++, but getting it to create efficient small programs was like... well like you programming in assembler and C, a horrible experience. I constantly had to jump through hoops and monitor the generated code to keep it under control. C++ was great on a PC with gigs of memory and no hard time contraints, but for me on an embedded project it was like using a 10 horse power table saw to cut balsa wood for a model airplane kit, way too much tool for the need :)

Posted on May 17, 2011 at 12:24

I spent a week or so trying C++ just to get:

1) overloadable functions (e.g. buffer.append(char c), buffer.append(short s))

2) more rigorous type checking for enum's

3) ''namespaces via classes'' to make my code more readable.

I got efficient compiled code, and it worked!, using Rowley crossworks and Ride7, but neither would reliably show me data during debug sessions. Rowley's startup clearly runs constructors for static data, however all mine ended up being inlined so I didn't actually watch any execute during startup. I didn't see any evidence that ride7 supported static construction.

I ended up with C as I spend more time debugging than crafting code. I still use eclipse when I am creating large amounts of new code, however I could never get eclipse+yagarto to compile more than once without doing a 'make clean', and I could never get it to run the debugger.

I ended up buying Rowley as Ride7 very frequently crashed during debug, and also crashed at the end of compilation, when there are significant syntax errors.

Posted on May 17, 2011 at 12:24

I'm in agreement, with ''they all have their uses''. c++ is easier to write oo code in to start off with, but i don't find its really any more complex in c when you get used to it - its just not as intuitive to start off with.

I've recently finished a really tight (with regards processor time) project on an str710 which i don't think c++ would have compiled to fast enough for. In theory you don't need dynamic memory in c++ but as soon as you start using classes its very _difficult not to and almost defeats the point and beauty of c++, likewise yes in theory they should compile to the same code though i don't find they do always (sometimes yes but not always:( ).

Thanks for the disabling exeptions tip i'll bear that one in mind:)

Posted on May 17, 2011 at 12:24

the book I frequently use is Object-Oriented Software Construction by Meyer, it's more a generic book on OOD, which I like

anyway, I believe assembly, C and C++ (and more advanced graphical programming tools Simulink for that matter) all have their uses, like a carpenter uses a hand saw, power saw and table saw on the same project, you have to pick the right tool for the job, and maybe some jobs a combination of all three

for a small micro like the STM32, I prefer assembler and C, I simply don't want the level of abstraction C++ allows you, hiding details in an embedded environment can be a total disaster, I want them in my face all the time reminding me of the consequences of doing this or that.

In addition, for micros I've seldom been able to blindly use someone elses objects (including ones that I have written a long time ago!), classes also fell apart when I try to extend them to new and different processors, I couldn't correctly predict the future when I created them, so they lack in some feature and have to be rewritten (or if I use inheritance they become too cumbersome and too complex that they become simply untestable or very time consuming to test). I agree it will work for REALLY basic things like complex numbers as you indicated.

The construction of the software is far more important to me then the language used so I really don't dwell on it too much. :p