Discussion:
To all german speaking 'steppers: article in german C't magazine <VirusChecked>
(too old to reply)
Lars Sonchocky-Helldorf
2003-05-20 17:44:31 UTC
Permalink
Hi,

In the current C't magazine (11/2003) there is an article concerning
generic programming in C++, Java and C on page 214. The article is written
in a tone that the reader could get the impression that generics are a
"really cool" feature that everyone would like to have.

So how about a letter to the editor concerning this from an experienced
*step programmer, who can explain why generics (e.g. templates in C++) are
a bad/ugly hack that _real_ object oriented languages (like ObjC and for
instance Smalltalk are) won't need.

NO, I don't want you to spam Heise, but I think one well funded letter
could maybe "awake" some readers from the "dream" that C++ and everything
C't writes are the ultima ratio. I would do it on my own but I am still a
beginner and my arguments would probably fail.

greetings, Lars
Helge Hess
2003-05-21 12:17:49 UTC
Permalink
Post by Lars Sonchocky-Helldorf
So how about a letter to the editor concerning this from an experienced
*step programmer, who can explain why generics (e.g. templates in C++) are
a bad/ugly hack that _real_ object oriented languages (like ObjC and for
instance Smalltalk are) won't need.
Generics/Templates are not a bad/ugly hack but are a rather clean
implementation of a different kind of programming style / OO approach.

Both, the "full OO" and the template approach have their advantages and
disadvantages which are discussed in length everywhere around in the
web/mailing-lists and it probably makes little sense to spam c't about that.

regards,
Helge
Marko Riedel
2003-05-21 15:33:15 UTC
Permalink
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.

Just my two cents worth,
--
+------------------------------------------------------------+
| Marko Riedel, EDV Neue Arbeit gGmbH, ***@neuearbeit.de |
| http://www.geocities.com/markoriedelde/index.html |
+------------------------------------------------------------+
Stefan Böhringer
2003-05-21 19:50:25 UTC
Permalink
Post by Marko Riedel
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);
a->~ClassA();
}

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.
Post by Marko Riedel
Just my two cents worth,
My ones as well.

Stefan
Philippe C.D. Robert
2003-05-21 22:27:43 UTC
Permalink
Hi,

I agree with Helge on this, I do not think it make much sense to write
such a letter... but on the other hand, if it is a well written
addition to this article and not a flame against C++ then it won't
cause any harm either :-)
Post by Stefan Böhringer
Post by Marko Riedel
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.
Why should a clean C++ design be slower than a clean ObjC design? And C
structs can perfectly be used in C++ as well, of course, this is not an
argument for or against templates...
Post by Stefan Böhringer
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.
C++ has absolutely no difficulties in handling container classes nor
does STL implement hundreds of container classes. On the other hand,
NSArray et al. are often implemented as class clusters and thus there
are more implementations than you generally see. But then, of course is
the FoundationKit easier to use, this is IMHO no question :-)

But of course does the different nature of C++ result in different
approaches and design solutions. And although it is much more difficult
to write good C++ code, this does not mean that you cannot do it!

-Phil
--
Philippe C.D. Robert
http://www.nice.ch/~phip
Chris B. Vetter
2003-05-28 15:34:18 UTC
Permalink
On 21 May 2003 21:50:25 +0200
Stefan Böhringer <stefan.boehringer+***@uni-bochum.de> wrote:
[...]
Post by Stefan Böhringer
The deeper reason for templates is, that C++ used to be crippled
before templates were introduces. How would one implement an array of
[...]

You might want to take a look at

http://www.osnews.com/story.php?news_id=3658

and

http://www.kuro5hin.org/story/2003/5/26/22429/7674

respectively.
--
Chris
Tima Vaisburd
2003-05-30 05:16:37 UTC
Permalink
Hello everyone,

After some hesitation I send this. I apologize it went too long.
All the claims are striclty imho.
Post by Chris B. Vetter
On 21 May 2003 21:50:25 +0200
Post by Stefan Böhringer
The deeper reason for templates is, that C++ used to be crippled
before templates were introduces. How would one implement an array of
You might want to take a look at
http://www.kuro5hin.org/story/2003/5/26/22429/7674
This is a very interesting article, but it criticizes C++ from somewhat
different angle. It says that generics can be done better, smarter that C++
templates, while Stephan's point is we do not need that kind of things at
all.

With mandatory type checking and no garbage collectiontemplates become a smart
solution, but that only suggests that mandatory type checking is an
artificial constraint. And still, imho, generic (template) programming that
C++ promotes is less convenient and more restrictive than Objective C way for
most practical situations.

Examples:
-- it's awkward to create a good interfaces (e.g iterators not exposing
underlining data structures, like NSEnumerator) that can be used as
a library interfaces or between processes. Things like
template <class It> void insert(It first, It last);
are only good within a dll or executable;

-- it's sometimes hard to localize the piece you're going to make a template,
especially if template parameter has to be a key in a map, say.
Then one template pulls another, making half of your classes templatized, this
leads to code bloat;

-- C++ has, like C, pointers to functions, but does not have good pointers
to methods. In C++ a pointer to method is a triple - method address,
object address and the method's _class_, which makes it hard to store and
yes, requires templates to manipulate (see e.g. Rich Hickey's callback library
http://www.tutok.sk/fastgl/callback.html, code at
http://www.function-pointer.org/zip/callback.zip).
In Objective C it's just a pair selector - receiver, both normal variables.


There is another, less techical consideration. The article at kuro5hin.org
compares C++ to ML and Scheme, both quite away from mainstream.
That makes its criticism very much theoretic, for noone is really proposing a
switch. In contrast, a swtich to Objective C is real.

That's why I support the idea of an article that would stress the power
of Objective C versus C++. Objective C promotion can help to make it
as widespread as should be.


Thank you,
Tima.
Pascal Bourguignon
2003-05-30 13:07:19 UTC
Permalink
Post by Tima Vaisburd
There is another, less techical consideration. The article at
kuro5hin.org compares C++ to ML and Scheme, both quite away from
mainstream. That makes its criticism very much theoretic, for noone
is really proposing a switch. In contrast, a swtich to Objective C
is real.
That's why I support the idea of an article that would stress the
power of Objective C versus C++. Objective C promotion can help to
make it as widespread as should be.
I think the difference is between dynamic and static languages. Lisp
Objective-C or Smalltalk are dynamic, the type of the value is known
at run-time (stored along with the value). C++ can be used, and is
most often used for fallacious performance reasons, as purely static,
with the type only known at compilation-time. Hence the need for
template. But personally, I've never used template in C++, because I
only use virtual methods, and all my objects are used by reference,
like it is in Objective-C, and invisibly in Smalltalk and Lisp. Then
the type (the class) of my values are known at run-time, and I can
have a single BpList class holding BpObject instances. Of course,
it's still slightly less dynamic than Objetive-C, and I have to type
cast the elements of my list before being able to send them a message,
but that's not too big a problem. At least, it does not seems to be
as problematic than templates... So, with the implementation of a
couple of methods in a root class, and the addition of a 'class'
class, you can almost get an Objective-C in C++. (Greenspun's tenth).


CONSTRUCTOR(BpObject)
DESTRUCTOR(BpObject)
METHOD(BpObject,makeBrother,(void),BpObject*)
METHOD(BpObject,runtimeClass,(void),BpClass*)
METHOD(BpObject,superClass,(void),BpClass*)
METHOD(BpObject,className,(void),const char*)
METHOD(BpObject,isKindOf,(const BpClass* aClass),BOOLEAN)
METHOD(BpObject,isKindOfClassNamed,(const char* aClassName),BOOLEAN)
METHOD(BpObject,isMemberOf,(const BpClass* aClass),BOOLEAN)
METHOD(BpObject,isMemberOfClassNamed,(const char* aClassName),BOOLEAN)
METHOD(BpObject,retain,(void),BpObject*)
METHOD(BpObject,release,(void),BpObject*)
METHOD(BpObject,retainCount,(void),INT32)
CLASSMETHOD(BpObject,processDeletePool,(void),void)
METHOD(BpObject,dependantCount,(void),CARD32)
METHOD(BpObject,dependantAt,(CARD32 index),BpObject*)
METHOD(BpObject,dependantAdd,(BpObject* nDependant),void)
METHOD(BpObject,dependantRemove,(BpObject* nDependant),void)
METHOD(BpObject,dependantRemoveAt,(CARD32 index),BpObject*)
METHOD(BpObject,selfChanged,(INT32 cause),void)
METHOD(BpObject,dependeeChanged,(BpObject* dependee,INT32 cause),void)


C is the assembly language of procedural languages. C++ is the
assembly language of object oriented language. When you compile a
high level language into assembly, you don't use all the
micro-processor instructions just for the thrill of it. You just use
the micro-instructions you need to implement cleanly your high level
constructs. So when you program in C++, don't use every feature C++
has!
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.
Loading...