EE Times EDN DataSheets.com Design News EBN Test & Measurement World Embedded.com TechOnline Planet Analog
Events ▼
UBM Electronics

Contact Us • Subscribe to Newsletters

Dan_Saks

's profile
image
Dan Saks is president of Saks & Associates, a C/C++ training and consulting company. For more information about Dan Saks, visit his website at www.dansaks.com. Dan also welcomes your feedback: e-mail him at dan@dansaks.com.

Dan_Saks

's contributions
Articles
Comments
Discussions

    • Implementing pure virtual functions as null pointers is simple but probably not robust enough for most applications.

    • Pure virtual functions provide a way to avoid defining base class member functions that have no meaningful implementation.

    • Each class in a hierarchy of polymorphic objects should have a function that initializes its vptr properly.

    • Virtual function calls work properly only if the vptrs and vtbls are initialized properly. C++ does this automatically, while C makes you do it manually.

    • Once more unto the breach, Dan tries to dispel the notion that C++ is a purely object-oriented language in which all classes must use virtual functions.

    • Although C doesn’t provide native support for virtual functions, you can emulate virtual functions in C if you attend to all the details.

    • Adding at least one virtual function to a class alters the storage layout for all objects of that class type.

    • Although over two thirds of embedded systems developers are programming 32- and 64-bit processors, C is surprisingly still more commonly used than C++.

    • Dan Saks crunches over 12 years of data on programming-language preferences from reader studies and finds some surprises about C/C++.

    • Class derivation and virtual functions let you define a common interface for related classes with similar, yet distinct, behaviors.

    • In reply to items (1) and (2): It's not only possible, but in fact often preferable, to address your concerns by layering polymorphic types over non-polymorphic types. I'm planning to show this in a future column. In reply to the last paragraph: As I explained in a comment last November, Bjarne Stroustrup designed C++ as a multi-paradigm language. One of those paradigms is indeed OO. But C++ also supports procedural, object-based, and generic programming, among others. Perhaps you view multi-paradigm techniques as "not instructive or good advice" because they don't hew to your notion that C++ should be used only as an OO language in which all classes are polymorphic. Yet you recognized earlier that implementing classes for memory-mapped devices as polymorphic types causes them to fail. I don't think you can't have it both ways: you can't insist on using C++ in limited ways that don't work and then blame C++ for failing, especially since C++ offers ways that do work.

    • willc2010: "The basic problem here is that C++ (and OO in general) confuses reuse with polymorphism." It's one thing to admit you're confused and ask for clarification. It's quite another to assert that C++ and OO are causing the confusion, when not everyone is confused. C++ supports several different approaches to reuse. Reuse via run-time polymorphism (virtual functions) is one. Reuse via genericity (templates) is another. This is probably a good topic for a future column.

    • cdhmanning: "This is exactly the point I was raising with the proper use of abstraction in previous articles. A C++ interface to a timer or UART or whatever should always be through an abstract base class." I presume you're referring to the comments you posted regarding my article entitled "Using member new to map devices" http://www.eetimes.com/discussion/4230743 . I'm usually reluctant to use words such as "right" and "wrong" when discussing judgments about programming style and idioms. But in this case, you're advocating an extremely rigid rule that's so unhelpful in so many situations, it's a reasonable engineering approximation to simply call it "wrong". I'll explain in detail in a future column. In the meantime, I refer you to Bjarne Stroustrup's C++ Style and Technique FAQ, http://www2.research.att.com/~bs/bs_faq2.html , specifically "Why are member functions not virtual by default?" and "Why are destructors not virtual by default?"

    • Ateocinico: I'd very much appreciate seeing specific code snippets that compile under 4.6.3 but not under 4.7.0. This request is probably off-topic for this thread, so you can write to me directly at dan@dansaks.com.

    • Thanks for the positive feedback. The shape class should indeed be an abstract base class. I'm planning to cover such additional details in a future column.

    • That 0x12 should have been just 12. Thanks for catching the typo.

    • Except that it's difficult to do exactly the same thing in C and C++. A C version that's just as abstract as the corresponding C++ will rarely be as efficient as C++, and likely be less efficient. A C version that's just as efficient as C++ will likely be less abstract.

    • I agree that it's better to stick with standard language features if you can. I usually point that out, but forgot to this time. Thanks for the reminder.

    • How is what you are proposing different from the class I showed?

    • A class like my timer_type simply adds an abstraction layer around what you call the "CSR area". I don't see any problem combining my approach with yours. I'm planning to show this sometime in the future.