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!

 

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...

 

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.

 

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

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.

 

(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")!

 

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

 

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 schreef:

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.

 

And C++ is a huge language. Even experiences programmers need some time

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.

 

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"

 

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.

 

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.

 

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.

 

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.

 

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.

 

David Brown schreef:
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.

 

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

<http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-Weffc_002b_002b-176>

"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.

 

David Brown schreef:

Yes, "More Effective C++" is definitely worthwhile.

You may also want to take a look here: http://www.gotw.ca/gotw/index.htm

Apparently so, though in the book I have Scott Meyers & John M.
Vlissides on wrote the foreword.

This book was an eyeopener to me that C++ templates could be used for
much, much more than generic containers of type T and generic functions.
However I haven't found much use for the techniques presented in this
book simply because they are way beyond the knowledge of the average C++
programmer, and frankly at times also beyond my understanding of C++
(which I was taught in 1992, and I have used it for the majority of
projects I have done since 1995 so I do consider my knowledge of C++ a
bit above average). Since the code I'm responsible for needs to be
maintained by people that are not necessarily C++ gurus, the
'understandability' of code is an important concern for me.

The skill of the programmer is very important with C++, more so than
with simpler programming languages (such as C) or a more restrictive
programming languages (such as Java).

Templates can be great for generic libraries (e.g. the boost library),
and do not necessarily create code bloat (though easily can when one is
not careful). However writing a good and efficient templated C++ library
requires a lot of skill and know-how. It helps a lot if one has a mental
picture how the compiler works. My experience is that this can be
expected only from a very few C++ programmers.

Advances in compiler technology means that some advise with respect to
efficiency that was good a decade ago is poor advise today. I still
regularly have to demonstrate to people that ugly hacks that they think
are more efficient than well written (straightforward) code actually
aren't more efficient with modern compilers and at times even less
efficient.

On the other hand with return values it is all to easy to ignore return
codes that indicate an error. Also propagating an error from the point
where it is detected to the point where it handled involves typically a
lot of code that really doesn't improve the overall clarity. It is
tempting for many programmer just 'forget' to handle that unlikely
failure scenario.

It is unfortunate that the C++ exception specification is worse than
useless and is best avoided. In Java exception specifications are
mandatory and enforced at compile time, so it is instantly obvious for
the caller what kind of exceptions to expect. It would be nice to have
something similar in C++, rather than the current runtime check of the
exception specification.

On the other hand just muddling along with invalid data can have
disastrous consequences as well. I have worked on systems where the
software is actually deliberately stopped as soon as a pre- or
postcondition violation is detected, just to prevent from failures go
unnoticed and causing more costly (and difficult to analyze) problems
later.

It depends very much on the kind of application which behavior is more
desirable.

Exceptions can be implemented by the compiler in various ways, with some
implementations the runtime overhead is zero as long as no exceptions
are thrown, at the expense of more runtime overhead when exceptions are
thrown. However when every byte counts exceptions are not a good choice.

True, but this applies to most features in C++. Are exceptions good or
bad? As with most things it is a trade-off and the only right answer is:
"it depends".

Agreed.

 

That's a dangerous site! (I could spend /far/ too long reading the
articles...)

Understandability is certainly critical in programming. But sometimes
it's okay for one person to write code that is tough to understand, but
others can use - after all, how many programmers could read the source
of their compiler's libraries and understand it? And there are many
more users of boost than wizards who can read and write such code.

I don't yet have a lot of practical experience with C++ projects, but I
have a better understanding of how compilers work than most programmers.
I write my C code with a very firm idea of how the compiler will
interpret the code, and what sort of object code it will produce. I do
the same with the C++ code I have worked with, especially when trying
out different formulations - I like to understand the detailed meaning
of the source code according to the standards, as well as reading the
assembly code in practice.

Yes, been there and done that. I also cringe when re-reading some of my
old code, with things like local pointer variables for stepping through
arrays. It used to be the case that this sort of "source level
optimisation" made smaller and faster code - now the opposite is true.

Programmers can always find ways to "simplify" their code.

Use of lint-type programs, or at least compilers with lots of warnings,
can help. For example, with gcc you can give a function an
"warn_unused_result" attribute. If the programmer ignores the return
code, it gives a compiler warning. Of course, the programmer can still
ignore the warning...

Yes - I think functions should by default be "throw()" so they cannot
propagate exceptions unless explicitly allowed. And of course,
exception specifications should work like people think they work, not as
they /do/ work. In other words, they should be checked and enforced at
compile time (not run time), and they should allow the compiler to
optimise on the assumption that functions behave according to their
declared exception specification.

Most compilers probably do try to figure out if exception specifications
are held or violated at compile time, but they can't do that across
compilation units (at least, not without some sort of link-time
optimisation). And compilers vary as to whether they actually enforce
the specifications at run time (as the standard says they should).
Apparently MS VC++ does not (or did not) enforce them, and gcc has a
flag to tell it not to check them at run-time.

That's certainly true.