"Joel de Guzman" <joel@boost-consulting.com> wrote
I like the idea behind the Interfaces Library: http://www.kangaroologic.com/interfaces/
I need one now. I dislike the macro-based Interface Definition Language, however. I find it utterly ugly especially because interfaces should be immediately readable. IMO, the macro-based IDL is not.
"Ugly macros", here we go again ;-)
Here's another take (prototype) at a macro less implementation of the interfaces (see attached). Tested on VC7.1, g++ and Comeau. The biggest advantage is that the same C++ member function interface syntax is retained. This makes it very easy to understand and even allows documentation extraction tools like Doxygen to work as usual. A disadvantage is that there is some unavoidable redundancy-- a lesser price to pay, IMO.
So why a solution that clearly involves repeating things multiple times is less ugly than a macro-based approach, that allows to avoid duplication?
Here's a client side example:
struct foo : member_function<int(int)> {}; struct bar : member_function<int(char const*)> {};
// a baz "interface" class baz : interface<foo, bar> { public:
template <class T> baz(T& x) : construct(x) {}
int foo(int x) { return this->call< ::foo>(x); }
And, in a little bit more involved case: int foo(int x, string y, double z, char* psz1, char* psz2) { return this->call< ::foo>(x, y, z, psz2, psz1); } // Oops, unintended behavior!
...
IMHO, the fact that interfaces are currently built with code generators (IDL) speaks for using yet another code generator, which is a macro mechanism. And, even though I havn't really looked at the Interfaces Library close enough, I totally support the general idea of using macros for interfaces. Regards, Arkadiy