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 email@example.com.
- Problems with inheritance by composition
Using inheritance by composition in C works okay for shallow class hierarchies but is cumbersome for deep hierarchies.
- Reflections on virtual functions in C
Understanding how to implement virtual functions in C is useful for a variety of reasons, one of which is to see why you should be using C++ instead of C.
- Alternative idioms for inheritance in C
C doesn't really support inheritance, but it offers alternative ways to mimic inheritance.
- Implementing a derived class vtbl in C
There's more than one way to implement a derived class vtbl in C. Dan looks at two alternatives.
- Implementing pure virtual functions
Implementing pure virtual functions as null pointers is simple but probably not robust enough for most applications.
- Pure virtual functions
Pure virtual functions provide a way to avoid defining base class member functions that have no meaningful implementation.
- Initializing derived polymorphic objects
Each class in a hierarchy of polymorphic objects should have a function that initializes its vptr properly.
- Initializing polymorphic objects
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.
- Impure thoughts
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.
- Virtual functions in C
Although C doesn’t provide native support for virtual functions, you can emulate virtual functions in C if you attend to all the details.
- Storage layout for polymorphic objects
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.
- It's not the processor
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 firstname.lastname@example.org.
- Virtual functions in C++
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.
- Judgment calls
That 0x12 should have been just 12. Thanks for catching the typo.
- Using member new to map devices
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.