[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: To all german speaking 'steppers: article in german C'tmagazine <Vir
Re: To all german speaking 'steppers: article in german C'tmagazine <VirusChecked>
21 May 2003 21:50:25 +0200
On Wed, 2003-05-21 at 17:33, Marko Riedel wrote:
> Hello there,
> let me start by saying that I am not at all familiar with C++. I
> looked around on the web to find out what templates are and it seems
> that they could be used e.g. to implement an array class that can
> stock different types of different sizes (no mixing), e.g. like an
> array of char pointers or of long integers.
> I'm going to be quite honest here: that seems like a really good idea
> when we compare it to the ObjC way of wrapping C types with NSValues
> and numbers with NSNumbers, which BTW can be a real performance hit.
And to me it doesn't seem to be a good idea. One can argue about this
from the performance point of view. This boils down to the general
question of performance of C++ vs. Objective-C. In this group it is
understood that Objective-C may need some hand tuning when performance
is really critical. If, however, a clean design is implemented C++ will
perform equal or worse to Objective-C. Also there are floating around
class implementations to hold arrays of c-structs (My personal class is
NSDataArray), which are even quicker than a C++-template.
The deeper reason for templates is, that C++ used to be crippled before
templates were introduces. How would one implement an array of ints? Go
ahead and write your addInt(), intAtIndex(),... methods. Now, what to do
with floats? Do another class. This generalizes to Templates where the
class is another argument.
C++ has termendous difficulties to handle container classes (classes
holding other classes). This led to the enormous complexity of the STL
(standard templates libraries; http://www.sgi.com/tech/stl) which
implements virtually hundrets of classes to perform what NSArray,
NSDictionary, NSSet, NSEnumerator do.
The deeper reason seems to be that C++ wants to able to treat any simple
data type as an object and to compile down any method call to a single
assembly instruction whenever possible. For example you could wrap an
int into a class, overload several operators and have in theory a single
assembly instruction resulting from say o++ (where o is the object).
This, however, is pure theory. It forced C++ to introduce multiple
inheritance, operator overloading, templates, special exception handling
and more. Compilers were slow to implement C++. Gcc used to implement
templates years after their specification and was buggy for a long time.
Since basic data types (int,...) and objects are syntactically
interchangable you write something like this:
ClassA a = ClassA(1,2,3);
This would lead to the creation of several temporary objects and would
be an orders of magnitude slower than an equivalent Objective-C
fragment. Of course C++ can be used more efficiently. E.g.
ClassA *a = new ClassA(1,2,3);
But this is the Objective-C way of doing it. When I reworked my C++ code
I found myself changing C++ to "Objective-C"-like fragments, i.e. create
objects explicitly with new, avoid templates and design a proper class
hierarchy to hold objects of one class only (from which all Classes have
to inherit if they are to be placed in the container) and use multiple
inheritance in a protocol sense.
Certainly I'm biased towords Objective-C, but also the proof to the
contrary that C++ constructs like templates do any good in proper
application design is missing.
> Just my two cents worth,
My ones as well.