1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

OOP and OOD for senior C-style embedded software engineers

Discussion in 'Embedded' started by like2learn, Oct 4, 2010.

  1. like2learn

    like2learn Guest

    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!
     
    like2learn, Oct 4, 2010
    #1
    1. Advertisements

  2. like2learn

    larwe Guest

    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...
     
    larwe, Oct 4, 2010
    #2
    1. Advertisements

  3. 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.
     
    Hans-Bernhard Bröker, Oct 4, 2010
    #3
  4. Book: "Accelerated C++: Practical Programming by Example" by Andrew Koenig
    and Barbara E. Moo.

    Leo Havmøller.
     
    Leo Havmøller, Oct 5, 2010
    #4
  5. like2learn

    David Brown Guest

    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.
     
    David Brown, Oct 5, 2010
    #5
  6. like2learn

    D Yuniskis Guest

    (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")!
     
    D Yuniskis, Oct 5, 2010
    #6
  7. like2learn

    D Yuniskis Guest

    <SEG> as above. Hey, it's too early in the morning for
    proper spelling! :-/
     
    D Yuniskis, Oct 5, 2010
    #7
  8. like2learn

    Frank Buss Guest

    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, Oct 5, 2010
    #8
  9. like2learn

    Dombo Guest

    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.
     
    Dombo, Oct 5, 2010
    #9
  10. like2learn

    PFC Guest

    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.
     
    PFC, Oct 5, 2010
    #10
  11. 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"
     
    Hans-Bernhard Bröker, Oct 5, 2010
    #11
  12. 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.
     
    Hans-Bernhard Bröker, Oct 5, 2010
    #12
  13. like2learn

    Frank Buss Guest

    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, Oct 6, 2010
    #13
  14. like2learn

    David Brown Guest

    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.
     
    David Brown, Oct 6, 2010
    #14
  15. like2learn

    David Brown Guest

    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.
     
    David Brown, Oct 6, 2010
    #15
  16. like2learn

    David Brown Guest

    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, Oct 6, 2010
    #16
  17. like2learn

    Dombo Guest

    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.
     
    Dombo, Oct 6, 2010
    #17
  18. like2learn

    David Brown Guest

    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, Oct 7, 2010
    #18
  19. like2learn

    Dombo Guest

    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.
     
    Dombo, Oct 7, 2010
    #19
  20. like2learn

    David Brown Guest

    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.
     
    David Brown, Oct 8, 2010
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.