Stop porting C code to C++ (was: Re: Howto dipslay a textwith SDL?)

SDL Development
1

Neil Bradley wrote:

There is of
course the issue of rapid application developement and readability,
but those things aside, i think C inherantly makes faster running
programs than C++.
Only if you’re a poor C++ programmer and a good C programmer.

And I’ve seen an ungodly amount of poor C++ programmers. In the right
hands it’s a powerful tool. In the wrong hands it’s a dangerous
weapon.

On the other hand, C is a dangerous weapon in almost any hands due to
the lack of fundamental data types for things like strings, lists, and
so on. But if people want to program that way, that’s fine. The point I
was making is that C++ is -not- slower than C. This kind of mistruth is
spread by C programmers who try to do something in C++, misuse the new
features available to them (eg. using endl when they should use ‘\n’),
and then blame the language for the performance loss. When choosing
between C and C++, you do it on the grounds of familiarity and
compatibility, not on performance. Both languages are suitable for
multimedia applications such as those created using SDL.–
Kylotan
http://pages.eidosnet.co.uk/kylotan

2

At 08:04 PM 8/16/02 +0100, you wrote:

On the other hand, C is a dangerous weapon in almost any hands due to
the lack of fundamental data types for things like strings, lists, and
so on. But if people want to program that way, that’s fine. The point

I’m going to be sorry for continuing this, but "strings, lists, and so on"
aren’t fundamental data types! They cannot be natively manipulated by
the hardware, so any operation done on them ends up generating calls to
whatever library provides them. Integers are fundamental data types (up to
the limit supported by the particular architecture). Chars are fundamental
data types. Pointers are fundamental data types. Strings are not. Lists
are not. Arrays technically aren’t, although hardware [x86, I don’t know
about other archs] makes them relatively easy to use (and I’d argue for its
inclusion in a language because of its simplicity). I’ll call any language
that doesn’t support fundamental data types braindead – built-in compound
data types is another matter entirely.

The largest efficiency concern with object oriented language (or really any
language that provides many built-in types and/or operations) derives from
"black box" syndrome – the programmer has little to no knowledge of the
underlying system (and that’s even claimed as one of the advantages of
OOP). This means that the programmer has no idea how much time even a
seemingly simple operation on two objects will take. Admittedly, the C++
STL is pretty good at avoiding it, but the issue is always lurking in the
background whenever you’re dealing with highly stratified code (which OO
code generally is).–
“It startled him even more when just after he was awarded the Galactic
Institute’s Prize for Extreme Cleverness he got lynched by a rampaging mob
of respectable physicists who had finally realized that the one thing they
really couldn’t stand was a smart-ass.”
– Hitchhiker’s Guide to the Galaxy

3

Christopher Subich wrote:

At 08:04 PM 8/16/02 +0100, you wrote:

On the other hand, C is a dangerous weapon in almost any hands due to
the lack of fundamental data types for things like strings, lists,
and so on. But if people want to program that way, that’s fine. The
point

I’m going to be sorry for continuing this, but “strings, lists, and
so on” aren’t fundamental data types! They cannot be natively
manipulated by the hardware, so any operation done on them ends up
generating calls to whatever library provides them.

Fundamental means “basic” and/or “essential”. I think you are focusing
on the “basic” part whereas I am focusing on the “essential” part. I’ve
never come across a project that didn’t need a string or a list.
Hardware support is not the issue.–
Kylotan
http://pages.eidosnet.co.uk/kylotan

4

At 09:56 PM 8/16/02 +0100, you wrote:

Christopher Subich wrote:

I’m going to be sorry for continuing this, but “strings, lists, and
so on” aren’t fundamental data types! They cannot be natively
manipulated by the hardware, so any operation done on them ends up
generating calls to whatever library provides them.

Fundamental means “basic” and/or “essential”. I think you are focusing
on the “basic” part whereas I am focusing on the “essential” part. I’ve
never come across a project that didn’t need a string or a list.
Hardware support is not the issue.

Ah, but what happens if you need a string that behaves slightly differently
than the one that the language gives you?

The range and operation of the primitive data types are very well-defined
– I know of no language that doesn’t support addition on integers. On the
other hand, what operations should we support on strings? Concatenation,
case-change, encoding change, substring, subsequence,
replacement? Building too much into a non-primitive data type bloats the
code (because it has to contain methods that aren’t executed), building in
too little makes use of the datatype more difficult (because of homebuilt
wrappers) than building one of your own with exactly the operations you need.

Things like ‘strings’ and ‘lists’ are relatively abstract concepts, anyway
– they define certain things, but many properties (such as min/max length)
and required operations are undefined. You’re right in that the vast
majority of typical projects require either or both, but they’ll each have
slightly different requirements on the types, which may change the most
optimal implementation. A language that implements a string as a datatype
and says “This is the String you will be using” takes it upon itself to
meet everyone’s requirements of the string, possibly turning it into ‘Jack
of all trades, master of none’ – not optimal for any particular use but
usable in all.

On a side note, at what point do you draw the line of a type being
’essential’, and thus fundamental? Stacks/queues are common enough to be
essential for many projects – but then again so are hash tables, B-trees,
etc. For the people on this list, SDLSurfaces are essential data types –
at what point do we stop building things into the language?

Just my thoughts, anyway.

5

is it so hard to code strings and lists that you think it should be an
integral part of the language? I know ive coded them so many times i can
whip up insert, delete and free list functions in about 15 seconds apeice.
The problem i see with STL is that it is coded for general purpose ADT’s.
In most cases, when you code something for the general case, you have to
write your code for the lowest common denominator. For instance if you were
to make a general case tree structure, you may have each node have a linked
list of children so that the user of this Tree ADT could have as many
children per node as they see fit. This is actualy slower than if i just
wanted a binary tree so have 2 node pointers left and right. Also the STL
varies from system to system and when speed matters, one build of your
program could be considerably slower than another. When your working with
SDL especialy, you have the potential for many different builds on many
different systems. Also as Christopher Subich was writing and i hinted at
earlier, when people use OOP, STL and other abstracting tools, it brings the
programmer mentaly away from the core of what the computer is doing, making
them more liable to make poor decisions in efficiency because they plain and
simple just dont know whats going on below the sheets. Also with each
"level" of abstraction you go up, you gain a level of function calls, memory
indexing etc, causing everything to take a varying level of a preformance
hit, depending on the “thickness” of the layer.> ----- Original Message -----

From: kylotan@kylotan.eidosnet.co.uk (Kylotan)
To:
Sent: Friday, August 16, 2002 1:56 PM
Subject: Re: Stop porting C code to C++ (was: Re: [SDL] Howto dipslay a
textwith SDL?)

Christopher Subich wrote:

At 08:04 PM 8/16/02 +0100, you wrote:

On the other hand, C is a dangerous weapon in almost any hands due to
the lack of fundamental data types for things like strings, lists,
and so on. But if people want to program that way, that’s fine. The
point

I’m going to be sorry for continuing this, but “strings, lists, and
so on” aren’t fundamental data types! They cannot be natively
manipulated by the hardware, so any operation done on them ends up
generating calls to whatever library provides them.

Fundamental means “basic” and/or “essential”. I think you are focusing
on the “basic” part whereas I am focusing on the “essential” part. I’ve
never come across a project that didn’t need a string or a list.
Hardware support is not the issue.

–
Kylotan
http://pages.eidosnet.co.uk/kylotan

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

6

Can we please treat this whole thread as a troll and STOP?

It does NOT belong on the SDL list.

Thanks.