Re: Non virtual base interface?
"Patrik Kahari" <patrik.kahari@googlemail.com> wrote in
news:1172669833.428062.111680@a75g2000cwd.googlegroups.com:
Hello,
I'd like to separate my public interface declaration from my private.
I want to do this in order to document the public interface to clients
in an uncluttered header file. I can do this with ABI. But doing so
means my interface becomes virtual. I'd rather not pay the price of
virtualness when my interface is not meant to be used polymorfically.
I'm unsure if a compiler could optimize away the v-table if no ABI
pointers or references are used. Could it?
No, it won't.
There's a pattern called Non-Virtual Interface. The interface is
defined in an abstract base class. All public functions are
non-virtual. All implementation functions are pure-virtual. However,
it gives a virtual table.
With this uncertainty in mind I tried to make sure I'm not paying for
things I don't use. So I removed the virtualness from my base class
method declarations. I also made the base class constructor and
destructor protected.
You have two basic choices with polymorphism: runtime or compile-time.
If you don't want to pay for runtime polymorphism, i.e., virtual
function overhead, then you neeed to use a compile-time mechanism.
One approach is CRTP (Curiously Recurring Template Pattern).
Your base class would be a template class on T that calls T's
methods. T would be a class you write that is derived from the
specialization of the base. For example:
template <class T>
class CRTPInterface
{
public:
void do() { static_cast<T*>(this)->doit(); }
};
class MyImp: public CRTPInterface<MyImp>
{
private:
friend class CRTPInterface<MyImp>;
void doit() { cout << "it!" << endl; }
};
// I'm away from a compiler and can't verify this right this second...
One example of this is in Boost.Iterator. The iterator interface
defines functions like operator->() and operator++(). The derived
class must implement domain-specific functions that it expects.
The flipside of not paying for stuff you don't use is to avoid
premature optimization. If you can't determine at compile-time what
behavior you want polymorphically, you must use some level of
indirection. If you find that that the virtual function is killing
you (how many ns of fat must you remove?), then redesign.
Now it works much like the ABI would only I have no virtual functions.
If I forget to define a method in the derived class which is declared
in the base class I will get a link error when the user tries to call
it. (If I had used ABI instead I would have gotten a compile error
when the client tried to create the derived class.)
If clients used a base pointer to try and delete the derived object it
would result in a compile error because of the protected base
destructor. If a base pointer was used to try and call any function a
link error would result because of the missing base definitions.
Is there some issues with this approach?
Does this work? It doesn't look like it would compile.
<CODE>
struct InterfaceABI {
publicFunction () = 0;
~InterfaceABI();
};
struct concrete1: public InterfaceABI {
publicFunction() {}
private:
//lots of private methods and data
};
//vs
struct InterfaceAB {
publicFunction();
protected:
InterfaceAB(){}
~InterfaceAB(){}
};
struct concrete2: public InterfaceAB {
publicFunction() {}
private:
//lots of private methods and data
};
[snip]
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]