Re: Existence Based Polymorphism

Sylvain Vignaud wrote:
> 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.
Indeed - also known as "std::string, we're looking at you...". On the 
off-chance you haven't seen this Scott Meyers article already, you might 
find it interesting:

http://ddj.com/184401197
> 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.
Personally I wouldn't argue that it's not OOP any more, because I don't 
think that OOP is ultimately a matter of syntax. Fundamentally, the 
difference between x.f(args) and f(x, args) is pretty minor. OOP is 
about logically grouping together data and the functions that operate on 
it, not whether or not they're physically grouped using some particular 
language syntax.

Cheers,
Stu
> 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

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