On Tue, Mar 23, 2010 at 7:57 PM, Stefan Seefeld <seefeld@sympatico.ca> wrote:
On 03/23/2010 10:45 PM, Emil Dotchevski wrote:
On Tue, Mar 23, 2010 at 6:56 PM, Stefan Seefeld<seefeld@sympatico.ca> wrote:
which you can not gain back "in the implementation". So what meta-programming tricks are there left to play ? Pointers to incomplete types are type-safe but yes, in general, I'm talking about balancing compile-time type safety and physical coupling. The "proper" way to do this in C++ is to use abstract base classes; Sorry, no. An "abstract base class" is something specifically tied to the Object Oriented Programming paradigm, and thus, runtime binding. Meta-programming, on the other hand, is all about compile-time binding, which you can't get with abstract base classes.
Compile-time binding is invaluable tool indeed, I'm not saying that you can replace it with something else. My point is that losing some physical coupling (and sometimes, compile-time type safety) is an option that should be considered when designing any interface.
except that an interface defined in terms of C-style functions is more abstract than a C++ abstract base class because calling a C-style function doesn't necessarily result in a virtual function call (yet it *can* call a virtual function internally, if that makes sense.) You are comparing apples and oranges. If you want the kind of abstraction that abstract base classes give you, i.e. (runtime) polymorphism, you surely want to operate with some form of function pointers. And these are very similar to virtual functions.
Yes, you do need to arrive at something like a function pointer if you want to call a function dynamically. No, the virtual function dispatch defined by C++ is not the only way to do that. Secondly, in a C-style interface you don't know if a particular function is dispatched dynamically or not. This is true for virtual function interfaces too, except that if you want to change a function to non-virtual or vice versa you'll force the user code to recompile. You could use pimpl but what's the point? Just so you can write x.foo() instead of foo(x)? :)
I can't believe we are having this discussion on this list...
Yes, the discussion is sort of pointless, because it won't lead to anything useful. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode