OOP and OOD for senior C-style embedded software engineers

We have a few embedded software engineers who had worked on embedded application for many years with C. Now we decide to switch to C++ and adopt OOP and OOD in our next generation firmware. Although most of us have some kind of knowledge toward C++/OOP/OOD, none of us was formally trained before. Are there any good books or online tutorials that you can introduce to us? Free downloadable materials are highly appreciated, however, we are OK to buy some books as well.

Thank you!

Reply to
like2learn
Loading thread data ...

The difficulty with self-training here is that you are all reading the same materials and likely will make the same mistakes. There is some distance between "read about OOP" and "experienced OO developer".

The usual approach is to send one or two people for formal training where they can get feedback on their efforts from actual knowledgeable people. Then they come back to the office and spread their knowledge. Otherwise it is the blind leading the blind...

Reply to
larwe

That feels rather a lot like you're about to bite off more than you can chew. Introducing a switch of language _and_ of design paradigm in a single, large step is a whole lot of change at once.

You may be better off splitting this in two independent moves. E.g. you could replace the language now, but stick with conventional design paradigm, for the time being. Introduce OOD later, slowly. Among other things, that'll give you time to, like Lewin outlined, build up knowledge by formally training some key players.

Reply to
Hans-Bernhard Bröker

Normally I'd disagree with you, but C++ is practically C with extensions to ease OO programming. So if you try to do OO development with C instead of C++ you'll get frustrated at bending over backwards to use a procedural language to do OO when there's C++ just waiting to be used. Conversely, using C++ without using those OO extensions isn't going to be much different than changing your .c files to .cpp and cleaning up any compiler incompatibilities.

I can only agree with introducing OOD slowly. I was at a company that transitioned from traditional C methods to C++, and it was done in a more or less slow and controlled manner*. So we started with a board that had a whole bunch of C code that had a well-defined and isolated set of functionality done in C++, then one board in a system that was done using C++, then finally we started using C++ throughout the system.

One hiccup that we discovered was that after I and the other engineer had done the "all C++" board and done well with it, a new project manager let a new engineering team jump on the C++ bandwagon. The team went on to demonstrate conclusively that C++ code that's written in too much of a hurry could be just as much of a millstone around a company's neck as C code written under the same circumstances.

  • Excepting the fact that I was the one that did the first "all C++" program in the joint, and it didn't occur to me to tell my manager that's what I was doing -- ah, youth. Given that most of it was just an existing set of C files with their extensions renamed, and only the functionality that I was adding was what was actually changed, I got away with it. After that, I made sure that management had been informed and signed on -- however reluctantly -- before I proceeded.
--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

Book: "Accelerated C++: Practical Programming by Example" by Andrew Koenig and Barbara E. Moo.

Leo Havmøller.

Reply to
Leo Havmøller

Other suggestions you've had here about courses and more formal training are good ideas - this is just an extra comment.

A lot of "C++" books talk about "C/C++" as though they were basically the same language, and teach on the basis of C first, then adding classes and OOP as a sort of C++ extra. This is, IMHO, completely the wrong way to go about it.

Bjarne Stroustrup's own "The C++ Programming Language" is an example of the correct way to handle it - it teaches C++ and OOP from the start, with C-level coding as just an implementation detail.

So if you are looking at books, I'd throw out anything that uses the phrase C/C++ at the start, and then throw out anything that doesn't deal with classes in the first chapter.

Reply to
David Brown

(sigh) This is probably a (big?) mistake. It would be like setting out to write your first *novel* and opting to do it in a language that you don't yet know. :-/

Learn the object paradigm, first. Even if it is with some *other* language. Note that you need not master things like inheritance, etc. but thinking about something in an object-oriented manner instead of procedurally is an essential first step (IMO).

Once you have a feel for what it is like to think about objects (and, how to *design* objects), you'll be better equipped to tackle C++'s approach to objects.

Note that the reverse approach is, IMO, useless (i.e., learning C++ and *then* learning OO) -- unless you don't already know C. It's too small of a "step" to be worth the effort. And, having the OO background behind you will give you a better appreciation for some of the syntax issues, etc.

*After* all of that, _The Design and Evolution of C++_ (Stroustrup) is a wood read -- but, only *afterwards* so you can fully appreciate the issues discussed (and, so you can recognize the errors/typos in the text :-/ ).

If you are intent on your original plan of action, be prepared for some big-time consequences (huge project delays, lots of bugs, etc.) -- of a severity that *someone* will lose their job (or "standing")!

Reply to
D Yuniskis

s/wo/go/

as above. Hey, it's too early in the morning for proper spelling! :-/

Reply to
D Yuniskis

It is strange to hear that kind of thing from someone who calls himself a 'senior' programmer. You got it from entirely wrong prospective. Using a different programming language is no more then writing using a pen of a different color. It doesn't matter at all as long as you know how to write and what has to be written. C++/OOP is just a small matter of convenience, and it is in no way replacement for brains and common sense.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

A different programming language is a lot more than just a pen of a different color, because each language has its programming style idioms: E.g. a Lisp programmer, who wants to program in C++ like writing Lisp programs are written, and vice versa, won't be happy.

And C++ is a huge language. Even experiences programmers need some time to learn all the syntax quirks and pitfalls :-)

--
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss
Reply to
Frank Buss

My experience is that syntax differences are easy to overcome, but switching to a new paradigm is a lot harder. For me the switch from Pascal to C was easy, switching for C to C++ i.c.w. OO style programming was a lot harder. After that switching to Java and C# was easy as those languages didn't really introduce new concepts too me, but switching to a Lisp like programming language again took a while to get used to.

Reply to
Dombo

Well, C++ is two languages if you include the template language which comes with it. C++ itself isn't too bad, although it has many gotchas, but the templates make an excellent foot-gun, and an excellent way to create blated slow code if you don't watch your steps.

Reply to
PFC

Or, as some unsung hero put it: "People complain that C makes it too easy to shoot yourself in the foot. C++ does make it harder, but if you do manage to, it _will_ blow off the whole leg"

Reply to
Hans-Bernhard Bröker

Yep. "A Real Programmer[TM] can write FORTRAN in _any_ language!"

So start slowly. Forbid certain constructs by way of coding rules until you're confident everybody _really_ knows how to use them. For starters forbid everything in C++ that Java removed, too: no templates, no multiple inheritance, no pointer voodo.

And make the "Design Patterns" book required reading for everyone before they're allowed near any OOA/OOD tasks.

Reply to
Hans-Bernhard Bröker

You are right, if you don't do advanced stuff, e.g. member function pointers or template metaprogramming, which can be really indecipherable, if you are not Scott Meyers :-)

Yes, Java is mostly a simplified C++ with an additional GC, except for some tricky differences like "this" pointer usage in constructors etc. C# (and VB.NET) has some nice features, which are not available in other languages I know, e.g. properties.

--
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss
Reply to
Frank Buss

Templates can also be a good way to write fast, compact and safe code if you get it right.

C++ gives you a lot of power to write very nice code - but it's easy to get things very badly wrong. I've seen C++ code that seems to consist entirely of classes that do nothing except construct each other - even though the program worked, it was totally meaningless. And a single typo could lead to hundreds or thousands of compiler errors, making it further development and debugging impossible.

Reply to
David Brown

You will want to start with a somewhat simplified C++ subset, and strict rules about what is used. For example, avoid all multiple inheritance - there is never a need for it, and it is only in rare cases that it is the best way to design the classes. It is also often a good idea to avoid exceptions and RTTI - these can have very large overheads (especially on small processors), and often make it harder to follow the flow of the code. You have to be very structured in your design and coding before exceptions really improve the code.

Reply to
David Brown

Different languages are arguably just different colours of pen - switching between C and Pascal, for example, should not be a big issue. But different language paradigms is a bit bigger step - swapping your pen-and-paper for a typewriter (with all its advantages and disadvantages).

But you can get a long way using C++ in a fairly simple way, using classes mainly for encapsulation and modularisation, as well as to improve the type safety of the code. You don't have to jump in and design huge hierarchies of classes on day one.

Reply to
David Brown

The books of Scott Meyers, though somewhat dated, contain a lot of good advise and are easy to read.

If you really want to see how far one can go with C++ templates take a look at "Modern C++ Design" from Andrei Alexandrescu; this books takes metaprogramming in C++ to whole different level using the template mechanism as a sort of functional program language to generate code. As ingenious as the template techniques presented in this book are, they are (IMO) too hard to understand even for experienced C++ programmers. When this book came out the same applied also to most C++ compilers of the day; since then the Loki library presented in this book is used as a benchmark for C++ compilers.

That depends on whether we are talking about implementation inheritance or interface inheritance. With implementation inheritance one can run in quite nasty issues, whereas with interface inheritance there is usually little to worry about. Even the Java language (which tends to stay on the safe side) allows one class to implement multiple interfaces.

Exceptions are not necessarily bad, but exceptions do require a different coding style; if one is not familiar with the RAII idiom one better is better off avoiding the use of exceptions in C++ program.

Especially on platforms with limited resources a downside of C++ is that the compiler can generate a lot more code behind the scenes than is immediately apparent when looking at the source code. C++ wouldn't be my first choice when the target is a 8-bit uC with 1K program memory.

C++ is powerful programming language, which can be wonderful in the hands of a skilled C++ programmer and a disaster waiting to happen when used by an inexperienced C++ programmer without proper supervision.

Reply to
Dombo

The guy has his own personal warning flag in gcc - it seems a lot of people agree with his advice.

"Effective C++" is a book I've been planning to get for a while - this thread has prompted me to actually order it. The third edition is from

2005, so it's presumably been updated a bit. Is "More Effective C++" also any good? It doesn't look like it has been updated since 1995.

Would that be " Modern C++ Design, Applied Generic and Design Patterns" by Scott Meyers - John M. Vlissides - Andrei Alexandrescu - Alexandrescu, Andrei ? I hope so, because I've just ordered it!

I can't claim to be a very experienced C++ programmer - I've used enough to know there is a lot to like, and a lot to dislike in the language. And I've seen enough of other people's C++ code to know there is a huge amount of badly written C++ code out there, but that it's also possible to write very nice code.

Template programming appeals to me - there's a lot that can be done with it. I've heard many people talk about how template programming leads to code bloat, and it's a terrible thing for embedded programming (where code space is often at a premium). I think that when done well, it can lead to much smaller code as well as neater and clearer source. In particular, templates let the compiler do more work at compile time, and save the target from work at run time. So a book on advanced template programming is definitely of interest to me.

One of the things that has kept me back from doing more C++ programming is the state of compilers and standards. Compiler features such as link-time optimisation (or whole-program IPA, or whatever a particular toolset likes to call it) mean that code can be structured in completely different ways. You no longer need to define all the little getter/setter style functions for a class in its header file - even if they are in a cpp file, LTO means they can be inlined properly. And "auto" type inference means that you no longer have to write immensely ugly type names when using templates (the syntax is still ugly in the definitions of the templates, but at least that's hidden in the implementation part).

You can use RAII even without exceptions, but obviously you have to handle your errors explicitly. Otherwise I agree with you - exceptions /can/ be a good thing, but they can also be a bad thing. If you are going to use exceptions, you have to consider them throughout your entire program. The worst thing is when a function throws an exception deep within the program, and the programmer had not considered that possibility - the exception propagates and may cause far more harm than if the function had simply returned an invalid result.

Consider, for example, a function that displays a value on a screen with three digits. A typical C implementation would either ignore the possibility of the value being over 999 (perhaps that's a valid assumption in that program), or display either 999 or something like ###. If your C++ version decides to throw an exception in that case, it could lead to better error handling. But if the code that uses that function does not take account of the possibility of the exception, then an overflow that would otherwise result in a slightly strange display will instead probably lead to a total program failure.

Exceptions are also expensive - they can be very code space, run time and data/stack space costly, especially on small processors. They also enforce limitations on the compiler's ability to re-arrange code since functions can have extra side effects, and this will hobble the optimiser.

All in all, exceptions are something you should only use (particularly in embedded systems) if you have thought through the consequences and decided that implementing them throughout the program is a good thing overall.

It depends on how you use it. C++ certainly makes it easier to hide large amounts of code behind seemingly minor statements. But it can go the other way too. I've done some tests with C++ on the avr, and it can go both ways. Sometimes the use of classes means the compiler can't recognise certain patterns, and it produces poorer code than if plain data types were used. But other times it does better - wrapping an eight bit variable in a class will stop the compiler from doing 8-bit to

16-bit integer promotion, and can give smaller code.

But it's important to know your processor, and know your compiler - check the generated assembly to see what the code is like when you are working on a small device.

Absolutely true.

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.