Re: Existence Based Polymorphism

On 03/06/10 09:08, Stuart Golodetz wrote:
> Richard Fabian wrote:
>> 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.
> If you're forced to write C++ in an object-oriented style, that's not 
> down to the language itself. Nothing technical is preventing you from 
> writing procedural code in C++.
>> 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. Many old APIs were built like this. Does anyone need to 
>> worry about anything when the OS changes the way FILE* is implemented?
> I hope I'm not oversimplifying your point, but are you essentially 
> criticising the need to put a class's private members in the header 
> file you supply to users (assuming you don't use the pimpl idiom)? If 
> so, then I agree that it's annoying. That's more a C++ problem than an 
> OO problem though.

Actually very often people put too many stuff inside a class definition. 
A function using a class should not be a member of the class. Often one 
could achieve the same code quality hiding a class definition, and 
showing only a prototype "/class MyClass;/" and public functions.
Header:
     class Object;
     bool DoesCollide( const Object&, const blabla stuff... );
is often enough. One might argue this is not OOP anymore, but actually 
there's no reason why DoesCollide should be part of a class in my example.

If more information about the class is required (public accessors / 
modificators), PIMP is a solution. Be it implemented through virtual 
methods, or casting "/this/" in PimpClass::Foo() from /PimpClass*/ to 
/ActualClassDefinition*/ or whatever trick one wants. Another solution 
is to have two headers, one being a C-like prototype + functions, the 
second one being the actual class definition for the few cases requiring 
the full definition.



Another grief one may have against C++ is actually the number of global 
symbols: every not-inlined method ends up being a global symbol. This 
can significantly slow down linking time in big projects.

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