Re: Abstract classes and methods
Re: Abstract classes and methods
- Subject: Re: Abstract classes and methods
- From: "Erik M. Buck" <email@hidden>
- Date: Wed, 29 Aug 2001 13:55:28 -0500
>
The old ObjC hands will tell you that ObjC is a simple extension to C but
>
they lie. ObjC is full of conventions that aren't enforced by the
compiler,
>
extra-linguistic conventions?, but that "everybody knows" and that are
>
really necessary to make the language useful. The complexity of ObjC +
ObjC
>
extra-linguistic conventions approaches the complexity of C++ + C++
>
extra-linguistic conventions.
The hell it does! All of Objective-C and all of the language conventions
and all of the existing frameworks combined are less complex than the rules
for template instantiation with automatic type promotion in C++. Get real!
The Design patterns book is relevant to both C++ and Objective-C. Design
patterns are certainly extra-linguistic conventions. The difference is that
half of the common patterns are unnecessary in Objective-C and the other
half are trivial to implement in Objective-C (sometimes with one line of
code).
I am a C++ expert and have been using C++ since 1991. There are aspects to
C++ (the language itself) that stump me (and Bjarn Stroustrup) to this day.
(Someone has an archive of many of Bjarn's internet postings in which he
gave the wrong answers to C++ questions). Add in STL and all of its
subtleties and template meta-programming and the mysteries of invalid
reference variables (supposedly impossible but actually quite common), and
type conversion rules (and the lack thereof), and bizarre operator
overloading in the standard libraries, and the convention of smart pointers,
and the conventions of mixins, and RTTI, and name spaces, and exceptions...
My personal favorite C++ operator overloading snafu is that -> can be
overloaded but . can not. It is obviously necessary that the language have
one operator that it can trust so that it can be used to implement other
operators. It just bugs me that myClassPtr->Foo() and (*myClassPtr).Foo()
can not be implemented to do the same thing if -> is overloaded!
The "Design and Evolution of C++" is nothing but a half hearted apology.