cristalink
Tue Feb 15 15:12:15 CST 2005
> Inheritance is evil in vast majority of cases. Imagine class B, and its
> derived
> D1, D2 and D3. Now imagine you have a bug looking like in D1. You do a
> bugfixing, and the bug appears to be - in B. OK, you fix B. This suddenly
> breaks D2 and D3 :)
This is a perfect example of how C++ code should NOT be written. You would
hardly encounter such a problem in properly designed C++ code.
> The thing is that the derived classes were relying on undocumented and
> un-described implementation details of the base class.
I wonder what would happen if your C driver relied on undocumented and
un-described kernel API. Of course any code should use a well defined and
documented base.
--
http://www.firestreamer.com - NTBackup to DVD and DV
"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:%234PmUR2EFHA.3636@TK2MSFTNGP09.phx.gbl...
>> Only advantage? Syntax is just one way objects in C++ are better.
>
> No. The code is lesser readable. Just imagine:
>
> // some header
> class MyClass
> {
> void get(....);
> };
>
> // some CPP file.
>
> MyClass myObj;
>
> // some second CPP file.
>
> myObj.get();
>
> Now go and guess what "get" is called here. First, you will need to find
> "myObj" declaration, and then the declaration of its class. Two steps. Now
> the
> OO-less style:
>
> MyClassGet(&myObj);
>
> - and then just "Find In Files" (or GNU grep) for "MyClassGet".
>
> The OO syntax of method calls is justified for polymorphyc method calls
> only.
>
>> Scoping
>
> Scoping is evil. See the above sample.
>
> Having 10 "get" calls from 10 namespaces decreases readability. Having
> explicit
> lexical prefixes like MyObjectGet(), MyThingGet() etc - increases it.
> Reading
> the code becomes the more usable task.
>
>>and inheritence help developers make more
>
> Inheritance is evil in vast majority of cases. Imagine class B, and its
> derived
> D1, D2 and D3. Now imagine you have a bug looking like in D1. You do a
> bugfixing, and the bug appears to be - in B. OK, you fix B. This suddenly
> breaks D2 and D3 :)
>
> The thing is that the derived classes were relying on undocumented and
> un-described implementation details of the base class. Sorry, but code
> copy/paste would be better in this case :)
>
> More so, the modern OO theoretical paradigm makes some new (and more sane)
> suggestions. They introduce the notion of "links" between modules, and the
> notion of "weaking links" or "hardening" them. The goal is - to weaken
> links,
> since this really means more robust, more elegant and more readable and
> maintainable code. "Divide and conquer" :) Decomposition.
>
> For instance, the classic encapsulation is now treated as "weaking
> links" -
> weaking by making them described, documented, predictable and narrowing
> their
> possible set.
>
> Then our "beloved" implementation inheritance. It is the _most hard kind
> of
> links between the 2 modules you can have_, for instance, you are now
> dependent
> on lots of undocumented implementation details of the base class. Links of
> such
> hardness are nearly impossible to do in C.
>
> So, this is just plain evil in majority of cases, unless you will spend a
> lot
> of brain time inventing the whole inheritance tree, and for many tasks
> this
> inheritance tree will only spoil and not help.
>
> Implementation inheritance is not decomposition - it creates a very hard
> kind
> of link and not weakens the links (which decomposition must do). It is
> nothing
> more then a code reuse for lazies, and in many cases copy/paste is more
> robust
> (yes, I know the drawback of copy/paste).
>
> For now, modern OO suggests only _interface inheritance_ (and polymorphyc
> use
> of interfaces) which is for sure good.
>
> Looks like the OO theory is going right way. C++ is surely not. It is just
> overloaded with unstructured mix (pile?) of all kinds of features, often
> from
> contradicting programming styles (like RTTI, which is evil due to
> suggesting
> non-polymorphic programming styles).
>
>>robust and elegant
>
> Robust? See the above samples, on how C++ use decreases robustness.
>
>> code. You also miss many clever syntax gains
>
> Yes, it's a well-known fact, but why is it good? Lesser typing? with
> harder
> comprehending? we're moving to "write-only languages" like Perl, who has
> lots
> of syntax sugar, too lot for even the author to comprehend the own code in
> several months.
>
>> The way we must do this in C: InterlockedIncrement(&x);
>> In C++ you could do it like this too: ++x;
>
> I feel real aversion to such ideas. Really. Implementing such a routine
> will
> make it impossible to distinguish interlocked increment from
> non-interlocked
> one, and will - with a good change - make all increments interlocked.
> Goodbye
> performance.
>
> Smaller amount of characters in the statement does NOT mean good
> readability.
>
>> It seems a common misconception to equate C++ with objects. C++ is C
>> language with new additional language features at your service.
>
> Surely. C++ does not implement proper OO in pure OO style, BTW :). C++ has
> features which decrease readability and maintainability. C++ has features
> like
> RTTI which just breaks the OO idea.
>
>> code if you want. There are bountiful new capabilities besides objects
>> like default parameters,
>
> Why this is good? This is overloading (automatically). You have 2 entities
> with
> the same name of get(). How is it good? Lesser typing? Sorry, but typing
> is
> around 0.1% of development cost.
>
>>reference pointers
>
> They are evil. Imagine:
>
> void MyFunc(int& c);
>
> and later
>
> MyFunc(i);
>
> The programmer will be VERY much annoyed that the value of "i" was changed
> by
> MyFunc call. Very much. Now the C style:
>
> void MyFunc(int* C);
>
> MyFunc(&i);
>
> You see - the "&" char explicitly tells the reader - "note! this is passed
> by
> reference!".
>
> C++ references have only one valid use - parameters for copy constructors
> and
> overloaded operators. In any other case, just replace them with C-style
> pointers, and you will have a major gain in code readability without any
> losses
> (references are pointers at machine level anyway).
>
>>, and function overloading.
>
> OK, let's overload the bitwise shift as file output. The most stupid thing
> in
> whole C++ maybe.
>
> Then let's add overloaded operators like "+" to our classes without
> providing
> their natural semantics, for instance, let's add "+" which will change the
> internal state of one of the terms. :) Easy :).
>
> And very, very much annoying when reading and maintaing the code. With C,
> you
> would have the speaking meaningful names instead.
>
> Well, "operator +" is not this evil. At least it requires "+" token to
> appear
> in code to be called under the hood. "operator T" is not such. It requires
> _no
> code at all_ to be called under the hood.
>
> With C, if you see the assignment, you're sure that the types are the
> same.
> With C++, you need to understand the exact type (which can be a complex
> class
> or - worse - template) of the right side, and then go to appropriate
> header and
> find "operator T" for the left side in it.
>
>> Again, all optional and up to you on if/how to use them.
>
> Yes. C++ is usable, if you will ban a lot of features from it by
> administrative
> order in the team :) Some features are evil, some are evil in all cases
> except
> 1 special one, and so on.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
>
http://www.storagecraft.com
>
>
