C or C++ do you prefer to program?

C or C++ do you prefer to program?

Post by Peter Ammo » Sun, 13 Jul 2003 11:33:20



I actually like const, in particular when applied to a method (though
C++'s "mutable" is just bizarre. gcc already lets you declare functions
via attributes so const that you shouldn't even change mutable variables
with them. When will they come out with something so mutable that
anything can change it? When will it end?). The semantics of const
strike me as a bit weird, though, because there's no guarantee that the
value of a const variable won't change, only that you won't change it.


Dynamic cast (or an equivalent) is something every object oriented
language needs. The other miscellaneous casts don't do much for me, and
the necessity to cast void* is just a headache.


C++ is C's guinea pig :)


Unfortunately, C seems to be moving in the same direction. What refuge
will the minimalists have?

-Peter
 
 
 

C or C++ do you prefer to program?

Post by Peter Ammo » Sun, 13 Jul 2003 11:41:19

lewelly wrote:


Yup, that's what we concluded.


Both of us were aware of those rules. It just took a while to realize
that that was what was going on.


I'm torn :)


Well, at least now I know why my sstream stuff wasn't working on gcc
2.95! But I enlisted his help in analyzing the above code, not creating
a replacement for what it was supposed to do.


Of course I was aware that the STL string class has to allocate memory.
I chose it because it seemed like the right thing to do, not because of
efficiency considerations.


:D

What, you don't think we're entrenched enough yet?


Actually, I did that to increase the perceived performance, not the
actual performance as measured by /usr/bin/time. I would be surprised
if it improved real performance, as my qsort() is pretty inferior to the
one provided by my C library. But you may be right, and it would be
worth trying out.


And I'm equally sure they won't! :)

If I ever get around to trying it, I suppose I'll report back. Thanks
for your thoughts.

-Peter


 
 
 

C or C++ do you prefer to program?

Post by Randy Howa » Sun, 13 Jul 2003 11:45:11

In article <bejgj5$osm$ XXXX@XXXXX.COM >, XXXX@XXXXX.COM says...

That sure explains the Linux kernel. :-)

--
Randy Howard
remove the obvious bits from my address to reply.
 
 
 

C or C++ do you prefer to program?

Post by Peter Ammo » Sun, 13 Jul 2003 11:46:51


[...]

I believe it, but it hasn't happened for me in my own programs.


I use reference counted libraries in C all the time, but they are
admittedly nonstandard. (On the flip side, there's no guarantee that
std::string is reference counted).


It wasn't supposed to be definitive. See the title of the page.


You're right, I should have documented that.


This strikes me as bad advice. clock() cannot take into account
overhead by other processes, but I believe that /usr/bin/time does.


3 was enough for me :)


Hmm? Do you really think that cout << "hello" is going to be
significantly slower than cout.write("hello", 5); ?

[...]

-Peter
 
 
 

C or C++ do you prefer to program?

Post by Peter Ammo » Sun, 13 Jul 2003 11:50:15


"Object oriented programming" is worth the name "object oriented
programming?"

Uhm, ok.

-Peter
 
 
 

C or C++ do you prefer to program?

Post by Erik Max F » Sun, 13 Jul 2003 12:04:36


The lack of a standard ABI for C++ is what makes C far more preferable
for system-level programming.

--
Erik Max Francis && XXXX@XXXXX.COM && http://www.yqcomputer.com/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ Humor is emotional chaos remembered in tranquility.
\__/ James Thurber
 
 
 

C or C++ do you prefer to program?

Post by Erik Max F » Sun, 13 Jul 2003 12:09:58


It actually makes very good sense. It's for distinguishing between
logical constness and physical constness. The classic example is a
cache; if you have a const object that contains a cache that's addressed
when you do lookups. Doing the lookups doesn't change the logical
constness of the caching class, but the cache still needs to be updated.
It's a case where the non-constness is an implementation detail, totally
hidden from the external interface. So instead of making all instance
of the class non-const, simply make the cache member mutable.


The confusion probably arises because const has subtly different
meanings in different contexts. Declaring an object const means that
you can't change the object. But accepting a const reference or pointer
to an object just means that the function (loosely) promises not to
change the object; the underlying object itself may or may not be
constant (in the first sense). (In fact, it's completely legitimate to
cast away constness and manipulate an object provided that it really
wasn't constant in the first place, although obviously doing this more
than exceptionally rarely indicates a design flaw.)


static_cast is essential in any language, since it simply invokes a
conversion. If you want to turn an int into a float, you need a
static_cast. There are other ways of writing it (such as via
construction), but the underlying concept -- explicitly invoking a
well-defined conversion -- is essential in any programming language.

The difference between C and C++ and all these casts is simply that
they're all written the same way in C. They're written differently in
C++ so that we can tell the intent of the programmer.

--
Erik Max Francis && XXXX@XXXXX.COM && http://www.yqcomputer.com/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ Humor is emotional chaos remembered in tranquility.
\__/ James Thurber
 
 
 

C or C++ do you prefer to program?

Post by Sean Frale » Sun, 13 Jul 2003 18:59:02


I definite;y prefer C++. I/O, memort allocation, and error handling are
much more pleasant, even if for some reason you aren't doing OOP.
 
 
 

C or C++ do you prefer to program?

Post by llewell » Mon, 14 Jul 2003 10:17:48

Peter Ammon < XXXX@XXXXX.COM > writes:
[snip]
[snip]

I took at try at your scrabble benchmark. I wrote a c++ entry, and it
is much faster than either of your existing c++ entries. It is too
long, too big, and abuses STL and templates all over the place (I
even used a vector< vector< vector< char > :: iterator> > :-), and
it still has too many dynamic allocations, so it would be a joke
to call it 'optimized', but it is faster than either of the 2
existing c++ entries. Perhaps more importantly, it handles the -x
option as required by the spec on your web page, which niether of
the existing c++ entries do. :-)

I made no attempt to optimize for image size or memory
footprint. (Worse, I compiled with -static, which results in a
whopping increase in image size, especially for c++ :-) I
note however that my version has smaller image size than either of
the two existing c++ entries. However, it is much larger than the
C entry.

Timings: (The first field is user time, which is the most important.)

My C++ entry:

g++-3.3 -static -O3 ssearch_cxx_mine.cc -o \
ssearch_cxx_mine

time ./ssearch_cxx_mine hello

(Best 3 of 10)

0.475u 0.054s 0:00.59 88.1%
0.476u 0.053s 0:00.58 89.6%
0.482u 0.048s 0:00.57 91.2%

C++ redux entry:

g++ -static -O3 ssearch_cxx_redux.cc -o ssearch_cxx_redux

time ./ssearch_cxx_redux hello

(Best 3 of 10)

0.544u 0.069s 0:00.64 93.7%
0.558u 0.055s 0:00.63 95.2%
0.559u 0.055s 0:00.63 95.2%

Original C++ entry:

g++ -static -O3 ssearch_cxx_original.cc -o ssearch_cxx_original

time ./ssearch_cxx_original hello

(Best 3 of 10)

6.149u 0.093s 0:06.42 97.0%
6.162u 0.078s 0:06.40 97.3%
6.186u 0.054s 0:06.38 97.6%

C entry:

gcc-3.3 -static -O3 ssearch_c.c carray.c -o ssearch_c

time ./ssearch_c hello

(Best 3 of 10)

0.519u 0.038s 0:00.57 94.7%
0.527u 0.030s 0:00.58 94.8%
0.527u 0.030s 0:00.57 96.4%

I used:

$ gcc -v
Reading specs from
/usr/local/gcc-3.3/lib/gcc-lib/i386-unknown-freebsd5.0/3.3/specs
Configured with: ../gcc-3.3/configure --prefix=/usr/local/gcc-3.3
--enable-shared --enable-threads --enable-debug --enable-c99
Thread model: posix
gcc version 3.3

On:

$ uname -a
FreeBSD Zorthluthik.local.bar 5.0-RELEASE FreeBSD 5.0-RELEASE #0:
Thu Jan 16 22:16:53 GMT 2003
XXXX@XXXXX.COM :/usr/obj/usr/src/sys/GENERIC i386

which is a 500 Mhz moblile pentium III laptop with 256 MB of
ordinary SDRAM.

I noticed you used -O4, I tried that and found it made no measurable
improvement over -O3. I note current gcc docs do not mention -O4
(only -O[0-3s]) . I recall asking about this on gcc at gcc dot gnu
dot org some years back, and being told -O4 - -O9 were all
equivalent to -O3, but I cannot find the message now. I looked at

I also tried -static, to make gcc link staticly instead of
dynamicly. That made all 4 programs faster, and had the added
benefit of making the timings a touch more consistent between
runs. -static improved the C version more than an
 
 
 

C or C++ do you prefer to program?

Post by Jordan Bet » Mon, 14 Jul 2003 12:11:29

Gianni Mariani < XXXX@XXXXX.COM > writes:


Templates are crap. And totally unnecessary in a properly designed
language. The problem is that C++ is strongly typed and statically
bound for no apparent reason. Templates are duct-tape to try to patch
that obvious flaw in the language.

You're right that you can do "cool stuff" with templates though. In
fact without them you can't do OO programming in C++ (unless it's
really simple stuff). That's probably the reason why Alan Kay (inventor
of smalltalk) said "I coined the phrase 'Object Oriented' and I didn't
have C++ in mind."


C is a "portable assembly language," that's what it was designed to be
and it's very good being one. If you need a high level language, there
are literally thousands of languages you can choose. The problem with
C is that it's being used for more than for which it was
designed. People should learn that knowing and using one language
isn't enough, a programmer should be


I like these quotes:

I absolutely fail to see how we can keep our growing programs firmly
within our intellectual grip when by its sheer baroqueness the
programming language -our basic tool, mind you!- already escapes our
intellectual control.
-- Edsger W. Dijkstra

Another lesson we should have learned from the recent past is that the
development of "richer" or "more powerful" programming languages was a
mistake in the sense that these baroque monstrosities, these
conglomerations of idiosyncrasies, are really unmanageable, both
mechanically and mentally.
-- Edsger W. Dijkstra

They're from his paper "The Humble Programmer." Perhaps if Stroustrup
had read it computer programmers could have avoided a lot of wasted
effort.


Learn a real object orientated language to see how it should be done.

--
Jordan Bettis < http://www.yqcomputer.com/ ~jordanb>
Systems have sub-systems and sub-systems have sub- systems and so on ad
infinitum - which is why we're always starting over.
-- Alan J Perlis: Epigrams in Programming, ACM SIGPLAN 1982
 
 
 

C or C++ do you prefer to program?

Post by Sean Frale » Mon, 14 Jul 2003 13:20:34


No offense, but what the hell does all of this matter in the context of this
thread? Just answer the question, C or C++, and then state why.
 
 
 

C or C++ do you prefer to program?

Post by Jordan Bet » Mon, 14 Jul 2003 13:27:03

Sean Fraley < XXXX@XXXXX.COM > writes:


The question is flawed. C when you need a portable assembly language,
something else otherwise. C++ is not a portable assembly language and
thus is not a replacement for C at all.

--
Jordan Bettis < http://www.yqcomputer.com/ ~jordanb>
Our national flower is the concrete cloverleaf interchange.
-- Lewis Mumford
 
 
 

C or C++ do you prefer to program?

Post by llewell » Mon, 14 Jul 2003 16:27:23

eter Ammon < XXXX@XXXXX.COM > writes:


In order to achieve those kinds of results, one must measure, one must
know when the STL does copies, when it does allocations, and what
a compiler is likely to optimize. For someone who has a rough idea
of how creatures such as vector<> are implemented, it's fairly
straightforward, but optimization (of significant programs) never
happens by accident.


As it turns out, for your benchmark, reference counted strings are
*not* helpful. Much the opposite. Reference counting makes copying
strings that aren't going to be modified much faster. It makes
every other string operation slower. In your benchmark, there's as
far as I can see, no need to copy a string and then choose not to
modify the copy (or the original). (You might ask what reference
counted strings are good for. Well, they are not a performance
optimization. They are a resource allocation / de-allocation
policy; they exist so that programs which create strings
dynamicly, but seldom operate on strings can prevent memory leaks
automagicly. )

[snip]

/usr/bin/time is better than clock(), but other process may cause all
sorts of variable overhead that /usr/bin/time does not account
for: cache pollution, TLB pollution, vm system pollution, etc. The
only overhead /usr/bin/time accounts for is cpu time consumed by
other processes.


I found that with your benchmark, it took at least 10 iterations to
get numbers that varied by less than 10%. Since your benchmark is
intended to be fun and not serious, this is ok, but for genuine
optimization effort, even 10 is not enough; in the real world,
I've had to rely on successive applications of optimizations whose
individual results were improvements of 1% - 5%, but whose total
improvements were 50% - 100% . This requires better than 1%
accuracy. (Of course, I didn't usually have to do it on machine
where other processes were running; a game console only runs one
game at time. :-)


Just as fputs is consistently faster than fprintf,
cout.write("hello", 5) is consistently faster than cout << "hello"
. And the reason is exactly the same; the formatting performed by
fprintf and cout << "hello" has cost. (The cost difference tends
be larger, however; C++ iostreams have only a few years of
optimization behind them, whereas C streams have a few decades.)

Just as one should not sort data that is already sorted, one should
not format output that is already formatted. (More important
than performance, both fprintf and cout << "" offer opportunities
to get the formatting wrong. :-)
 
 
 

C or C++ do you prefer to program?

Post by llewell » Mon, 14 Jul 2003 16:37:55


XXXX@XXXXX.COM writes:


You prefer the language you know best. Some people will say you can
write good code in any language, but the reality is that you
can only write good code in a language you know well. Some people
will tell you to use the right tool for the right job - this has
truth to it; but should be considered second; if you do not
understand a tool, it can't help you, however 'right' it may be
for the job. However, if you know the tool well, you may not have
much trouble making it do an unusual task. This is especially true
w.r.t. to C vs C++, and unix; there is enourmous overlap in the
kinds of applications both are well suited to, and enourmous
overlap in the kinds of library facilities provided.
 
 
 

C or C++ do you prefer to program?

Post by llewell » Mon, 14 Jul 2003 17:10:41

Peter Ammon < XXXX@XXXXX.COM > writes:




But that's exactly the beauty of const: it controls *who* changes a
variable. Why do you use local or static variables in preference
to global variables? To control who can change them. Pointers and
referneces to const fill a similar role.


Nit: Dynamicly typed object oriented languages have no need for any
explicit equivalent to dynamic cast; the translator decides when
to do view conversions, and as far as the programmer is concerned,
they are automagic.


Their major benifts are in making code easier to read, and easier to
grep. They don't offer new functionality.


? Sorry, but restrict, _Complex, etc, seem like a very different
direction to me. Over half of the new C99 stuff seems
(conceptually) adapted from fortran. Most places where the two seem
similar: inline - inline, std::complex - _Complex,
<tgmath> - templates, are all incompatible, have both loud and
subtle conceptual differences, aim to fill different goals, and
were put into the languages by very different people.

I don't see C++ as being C's guinea pig, and I don't see C as moving
in anything like the same direction as C++.


http://www.yqcomputer.com/

(I don't have a serious answer. I suppose you could try scheme or
forth. :-)