Re: Existence Based Polymorphism

Richard Fabian wrote:

> Stuart Golodetz wrote:
>
>>> Encapsulation is better handled by C. This can be seen in how you cannot
>>> actually hide all the implementation details in C++ without using techniques
>>> such as pImpl or virtual base classes. Each of which actually impacts
>>> performance in some way.
>>
>> See Tom Plunket's reply :)
>
> I saw it and didn't know if it was a joke or not... just because C is a
> subset of C++ doesn't mean you get to use it. You can't add methods to a
> class behind the scenes in C++, which would have allowed for a better data
> hiding opportunity.

Well come on, in C you can't add methods to a class behind the scenes
either, because there is no such thing as a class in C.  However, in
both languages you're free to write all of the functions that you
want, unattached to data structures.

I suppose the important part of the question is, what aspects in C
allow better data hiding than C++, and why can't those techniques be
used in C++?

> One of the biggest problems I have with OO C++ right now is that to do it
> well, you have to use too many tricks. I want a programming paradigm where
> there are no tricks, but you still have all the benefits.

As someone who's done extensive "OO" coding in C, my experience is
that it's not remarkably better, it's just different.

> If you're doing OO in C++, you can't hide your implementation as easily as
> you still have to provide classes for your users, at which point you're
> talking to them through your implementation.

You can't hide your implementation as easily as what?  I've certainly
provided "opaque classes" to clients before, who know nothing beyond
the name of the thing they're getting from the API.  That API must
consist of free functions, though, since (unless you want to go down
the "interface" route) clearly the clients then don't know anything
about the "internals" of the object (which naturally includes its
member functions at that point).  This isn't necessarily better or
worse than exposing yourself for the world to see, it's just a
different strategy for a different set of requirements.

> I'm not too bothered about encapsulation from a data hiding point of view
> any more, but there's still the issue of changes to implementation affecting
> a lot more than just the code that provided an interface. In C style
> development, if the implementation changes, the user need never know
> anything about it at all. They were never privy to the implementation
> details at any point, and never assumed they would.

That's actually not the case at all.  If anyone needed access to any
internals of a structure, they needed complete knowledge of that
structure.  As that structure's definition was part of the API, it was
also bundled with the functions that operated on it, so any part of
the implementation changing would trigger a recompile of all
dependents.  You can't malloc(sizeof(opaque_struct)) any easier than
you can new opaque_class.

However, if a bit of code did not depend on the internal structure of
a "thing," then like in C++ you just forward declare it and you're
done.

> Many old APIs were built like this. Does anyone need to worry about anything
> when the OS changes the way FILE* is implemented?
> I realise this is becoming a bit far off topic now...

Well yeah, if you want opaque types, you don't need to expose anything
to the client.  I'm not sure why this appears more difficult (or
impossible?) to do in C++.

Finally- it may well be that most people equate "C++ class" to "OOP,"
but that doesn't need to be the case.  One can develop in an
object-oriented style without using classes just as much as many wrap
procedural code in classes.  That's sort of the "killer app" of the
multi-paradigm programming language.

-tom!

--
_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com