C or C++ do you prefer to program?

[David Schwartz]

<mtsouk@freemail.gr> wrote in message
news:bejcse$1eqp$1@ulysses.noc.ntua.gr...

> Dear list,
> I want to ask a rather "philosophical" question but I would like to
> know your opinion:
>
> In which language do you prefer to program in
> a UNIX environment: C or C++?

Whichever works best for the task at hand.

If it's a project that will take less than hour and doesn't require
using a lot of previously written code, C usually wins hands down. (Though
most programmers would probably use C++ anyway, just not really use it.
Think of it as C with C++ strings and/or other minor conveniences.)

If it's a massive project that requires reusing a lot of existing code,
must be maintainable, and requires dozens of cooperating programmers, C++
wins hands down.

In-between, it's largely a matter of preference.

DS

[Måns Rullgård]

[email]mtsouk@freemail.gr[/email] writes:

> I want to ask a rather "philosophical" question but I would like to
> know your opinion:
>
> In which language do you prefer to program in
> a UNIX environment: C or C++?

C. C++ just adds trouble.

--
Måns Rullgård
[email]mru@users.sf.net[/email]

[Lorinczy Zsigmond]

[email]mtsouk@freemail.gr[/email] wrote:

> Dear list,
> I want to ask a rather "philosophical" question but I would like to
> know your opinion:
>
> In which language do you prefer to program in
> a UNIX environment: C or C++?

Very good question to start a never-ending flame-war ;)

Let me ask an other question:
which language do you know: C or C++ or both or none?

[mtsouk@freemail.gr]

Lorinczy Zsigmond <nospam@for.me> wrote:

> [email]mtsouk@freemail.gr[/email] wrote:

>> Dear list,
>> I want to ask a rather "philosophical" question but I would like to
>> know your opinion:
>>
>> In which language do you prefer to program in
>> a UNIX environment: C or C++?

>
> Very good question to start a never-ending flame-war ;)
>
> Let me ask an other question:
> which language do you know: C or C++ or both or none?

I know both but not that much.
I will soon start a project and I will like to hear
the opinions of professionals.
I have no-intention to start a flame-war so please don't
blame :-)

Mihals.

[Chuck Dillon]

[email]mtsouk@freemail.gr[/email] wrote:

> Dear list,
> I want to ask a rather "philosophical" question but I would like to
> know your opinion:
>
> In which language do you prefer to program in
> a UNIX environment: C or C++?
>
> many thanks in advance,
> Mihalis.

I suppose I prefer C but what I like isn't relevant to what I do. When
I evaluate a job my personal preference has a weight factor of just
about zero. In fact, I'm more likely to want to select a new
technology than focus on what I 'like'.

Don't fall in love with any technology.

-- ced

--
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.

[Robert Synnott]

[email]mtsouk@freemail.gr[/email] wrote:

> Dear list,
> I want to ask a rather "philosophical" question but I would like to
> know your opinion:
>
> In which language do you prefer to program in
> a UNIX environment: C or C++?
>
> many thanks in advance,
> Mihalis.

Ususally C, if only to prevent library-linking nastiness, vague guilt
over not using OO properly, etc. :)
Bob.

[Peter Ammon]

[email]mtsouk@freemail.gr[/email] wrote:

> Dear list,
> I want to ask a rather "philosophical" question but I would like to
> know your opinion:
>
> In which language do you prefer to program in
> a UNIX environment: C or C++?
>
> many thanks in advance,
> Mihalis.

I like C in part because it's the common denominator. If there's some
task you want to perform, someone somewhere has written a C library to
do it. You can maybe get it to work with C++ if you tweak it a lot, but
no guarantees.

-Peter

[Peter Ammon]

Gianni Mariani wrote:

> Peter Ammon wrote:
>

>> Gianni Mariani wrote:
>>

>>> [email]mtsouk@freemail.gr[/email] wrote:
>>>
>>>> Dear list,
>>>> I want to ask a rather "philosophical" question but I would like to
>>>> know your opinion:
>>>>
>>>> In which language do you prefer to program in
>>>> a UNIX environment: C or C++?
>>>>
>>>> many thanks in advance,
>>>> Mihalis.
>>>
>>>
>>>
>>>
>>> C++
>>>
>>> Everything should be C++ from now on.

>>
>>
>>
>> I'm hoping you mean all C programs, not all programs period. :/

>
>
> Well, one of the probs with C++ is the lack of a CPAN like set of
> libraries. Yep, I still write some perl ... :)
>

>>

>>> It has taken a long time to mature the compilers to the point that
>>> it is significantly better than C.
>>>
>>> With gcc 3.x, you can do some very neat things that eliminate some of
>>> the errors people normally make using C.

>>
>>
>>
>> Can you give an example?

>
>
> templates have matured. You can do some really cool stuff there that
> eliminates alot of duplicate code otherwise.

Those aren't examples of eliminating errors that people commonly make
with C. In any case, C++ introduces lots more opportunities for errors.

As for templates, they're a pretty shoddy implementation of a great
idea. I like the ML type-inferencing model of generic programming myself.

>

>>

>>> While some of the STL is good it could be better, but it's far
>>> better than C.

>>
>>
>>
>> In what manner is it better?

>
>
> lists, maps, algorithms, strings ... need more ?
>

I'm not convinced that those structures are worth the tradeoff. If
nothing else, you have to look at stuff like "`void std::vector<_Tp,
_Alloc>::push_back(const _Tp&) [with _Tp = int, _Alloc =
std::allocator<int>]'" when you get a type error.

>>
>> One way that it's worse is that it's much slower, in my experience.
>> See my page at [url]http://www.people.cornell.edu/pages/pa44/scrabble/[/url] .
>> C++ with the STL was ten times slower than C and about twice as slow
>> as Java(!). This translated into more than four second wait for a
>> program with C++, which was unacceptable when you could get the same
>> results in about .4 seconds with C.

>
>
> I can write slow code in any language. What's the point ?

I did my best to write in the language as the designer(s) intended for
them to be written in. I used essentially the same algorithm for each
of them. I guess the moral is that you have to write poor C++ (i.e.
avoid the STL) to get good performance.

>

>>

>>>
>>> Learning curve is a bit long though. I've been using C++ heavily for
>>> nearly 4 years and I still run into gaps in my knowledge of C++.

>>
>>
>>
>> I'll bet that almost everybody does.
>>

>>> Most of the gaps are mostly irrelevant but still keeps the juices
>>> going.

>>
>>
>>
>> I've been using C++ for a bit over four years (though not
>> exclusively), and every time I try to write a program in C++, I run
>> into something nasty. Here's the latest example. It took the
>> combined efforts of me and a C++ expert an hour or so to figure out
>> why this program:
>>
>> #include <string>
>> #include <iostream>
>> using namespace std;
>> int main(void) {
>> string foo="My age is: ";
>> foo += 22;
>> cout << foo << endl;
>> return 0;
>> }
>>
>> was only outputting this:
>>
>> My age is:

>
>
> And this issue is limited to C++ ?

How many languages can YOU name that have operator overloading?

> Firstly, it's obvious to me what's
> wrong,

Pretty much anyone looking at that code would get the wrong idea of what
it does.

> secondly, your expert must not have had his coffee when you
> showed him.

RIP useful type safety.

>

>>

>>> I admit that learning C was far easier and that was over 20 years
>>> ago now but the language is limiting.

>>
>>
>>
>> C++ is limiting! Most (though not all) of its features are compile
>> time trickery and don't let you do anything fundamentally new.

>
>
> Oh, but there are plenty of things that are fundamentally new.
>
> You may call it syntactic sugar but it can really help write more robust
> and better programs faster.
>
> C++ is not for slouches though. There are many paradigm shifts from C
> to C++. Some that I came across are that C++ classes are fundamental
> building blocks and that the threshold to designing a new class is very
> low.

This is true. C++ has very inexpensive classes.

> Another is the power of templates and just how much the compiler
> may be able to deduce by itself if you design templates correctly.

I agree that templates are powerful, but I think the syntax and
difficulty of debugging them compromises their utility.

>
>
> For example, the code you have above.
>
> #include <iostream>
> #include <sstream>
>
> using namespace std;
>
> template <typename T> string to_string( const T & val )
> {
> ostringstream sstr;
> sstr << val;
> return sstr.str();
> }
>
> int main(void)
> {
> string foo = string( "My age is: " ) + to_string( 22 );
>
> cout << foo << endl;
>
> cout << "My age is: " << to_string( 21.6 ) << endl;;
>
> }
>
> Now, to_string( any_type ) will work as long as there exists an
>
> ostream & operator<<( ostream &, const any_type & )
>
> Cool no ?

This strikes me as pretty silly. Instead of having to implement
to_string(const SomeType_t & val), you have to implement ostream &
operator<<(ostream &, const SomeType_t & val), and they do essentially
the same thing. You haven't saved any real work. I don't think that
feature is worth the sheer counterintuitiveness of C++.

(And besides, overreliance on the static types of variables causes
problems. I've lost count of the number of times I've been asked why
cout << toupper('a') doesn't output 'A'.)

There are languages where you could make a *truly* generic to_string
function, where the function could look up the positions and types of
the instance variables of the class (at runtime, no less) and construct
a string based on those. That's the sort of feature that I'd be happy
to endure a steep learning curve to get.

-Peter

[santa]

i seem to like c++ a lot and never usually use c unless the task at hand is
so simple that it really doesnot matter.

OOP is a concept that is indeed worth its name

santa

[Gianni Mariani]

Peter Ammon wrote:

>>
>>
>> lists, maps, algorithms, strings ... need more ?
>>

>
> I'm not convinced that those structures are worth the tradeoff. If
> nothing else, you have to look at stuff like "`void std::vector<_Tp,
> _Alloc>::push_back(const _Tp&) [with _Tp = int, _Alloc =
> std::allocator<int>]'" when you get a type error.
>

So ?

>>
>>
>> I can write slow code in any language. What's the point ?

>
>
> I did my best to write in the language as the designer(s) intended for
> them to be written in. I used essentially the same algorithm for each
> of them. I guess the moral is that you have to write poor C++ (i.e.
> avoid the STL) to get good performance.

Yes, this can be the case sometimes. The STL may get in the way.

>

....

>>>
>>> I've been using C++ for a bit over four years (though not
>>> exclusively), and every time I try to write a program in C++, I run
>>> into something nasty. Here's the latest example. It took the
>>> combined efforts of me and a C++ expert an hour or so to figure out
>>> why this program:
>>>
>>> #include <string>
>>> #include <iostream>
>>> using namespace std;
>>> int main(void) {
>>> string foo="My age is: ";
>>> foo += 22;
>>> cout << foo << endl;
>>> return 0;
>>> }
>>>
>>> was only outputting this:
>>>
>>> My age is:

>>
>>
>>
>> And this issue is limited to C++ ?

>
>
> How many languages can YOU name that have operator overloading?

Operator overloading is an integral part of C++. If std::string does
somthing wierd with operator +=, then smack the guy who wrote
std::string and all those who voted to adopt it. You just can't do some
very cool things with C++ without operator overloading.

>

>> Firstly, it's obvious to me what's wrong,

>
>
> Pretty much anyone looking at that code would get the wrong idea of what
> it does.

lay this down to experience. When I wrote my first printf( ...) in C++
I had similar woes. So, what ! You'll not make this mistake again.
Chalk it off to learning curve.

>

>> secondly, your expert must not have had his coffee when you showed him.

>
>
> RIP useful type safety.

how ?

>> Another is the power of templates and just how much the compiler may
>> be able to deduce by itself if you design templates correctly.

>
>
> I agree that templates are powerful, but I think the syntax and
> difficulty of debugging them compromises their utility.

Yes, debuggers up until recently have proved near useless. All the more
reason to have a good set of test cases.

>

>>
>>
>> For example, the code you have above.
>>
>> #include <iostream>
>> #include <sstream>
>>
>> using namespace std;
>>
>> template <typename T> string to_string( const T & val )
>> {
>> ostringstream sstr;
>> sstr << val;
>> return sstr.str();
>> }
>>
>> int main(void)
>> {
>> string foo = string( "My age is: " ) + to_string( 22 );
>>
>> cout << foo << endl;
>>
>> cout << "My age is: " << to_string( 21.6 ) << endl;;
>>
>> }
>>
>> Now, to_string( any_type ) will work as long as there exists an
>>
>> ostream & operator<<( ostream &, const any_type & )
>>
>> Cool no ?

>
>
> This strikes me as pretty silly. Instead of having to implement
> to_string(const SomeType_t & val), you have to implement ostream &
> operator<<(ostream &, const SomeType_t & val), and they do essentially
> the same thing. You haven't saved any real work. I don't think that
> feature is worth the sheer counterintuitiveness of C++.

Heck ... no one stopped you from writing a one liner:

cout << foo << 22 << endl;

>
> (And besides, overreliance on the static types of variables causes
> problems. I've lost count of the number of times I've been asked why
> cout << toupper('a') doesn't output 'A'.)

fair comment. This requires another shift of thinking away from C.

>
> There are languages where you could make a *truly* generic to_string
> function, where the function could look up the positions and types of
> the instance variables of the class (at runtime, no less) and construct
> a string based on those. That's the sort of feature that I'd be happy
> to endure a steep learning curve to get.

There are a few more things I'd like to see as well. Does that mean you
stick with C until there is a perfect alternative ?

G

[mtsouk@freemail.gr]

M?ns Rullg?rd <mru@users.sourceforge.net> wrote:

> [email]mtsouk@freemail.gr[/email] writes:
>

>> I want to ask a rather "philosophical" question but I would like to
>> know your opinion:
>>
>> In which language do you prefer to program in
>> a UNIX environment: C or C++?

>
> C. C++ just adds trouble.

I have that feeling too, but C++ has also some advantages:
- STL (you get a lot of tested functions and structures)
- ACE library for network programming

What do you think about those?

Mihalis.

[felix zaslavskiy]

Peter Ammon wrote:

> Gianni Mariani wrote:
>

>> [email]mtsouk@freemail.gr[/email] wrote:
>>

>>> Dear list,
>>> I want to ask a rather "philosophical" question but I would like to
>>> know your opinion:
>>>
>>> In which language do you prefer to program in
>>> a UNIX environment: C or C++?
>>>
>>> many thanks in advance,
>>> Mihalis.

>>
>>
>>
>> C++
>>
>> Everything should be C++ from now on.

>
>
> I'm hoping you mean all C programs, not all programs period. :/
>

>> It has taken a long time to mature the compilers to the point that it
>> is significantly better than C.
>>
>> With gcc 3.x, you can do some very neat things that eliminate some of
>> the errors people normally make using C.

>
>
> Can you give an example?
>

>> While some of the STL is good it could be better, but it's far better
>> than C.

>
>
> In what manner is it better?
>
> One way that it's worse is that it's much slower, in my experience. See
> my page at [url]http://www.people.cornell.edu/pages/pa44/scrabble/[/url] . C++
> with the STL was ten times slower than C and about twice as slow as
> Java(!). This translated into more than four second wait for a program
> with C++, which was unacceptable when you could get the same results in
> about .4 seconds with C.
>

That is absurd !!! STL can produce faster code then C equivalents
sometimes. For example std::string class can take advantage of
reference counting and avoid copy where and in C you usualy have to make
copies right away and cant do it lazily like in C++.

Your little bench is not meaningful sorry.
When you do a bench next time dont forget to
1. tell us the compiler version
2. tell us the Operating System, libstd++ and libc versions.
3. use the clock() function to make measurements
4. run many iterations to get good statistical results.
5. write the program optimaly. ex dont use formated io when unformated
can do just as fine.

>>
>> Learning curve is a bit long though. I've been using C++ heavily for
>> nearly 4 years and I still run into gaps in my knowledge of C++.

>
>
> I'll bet that almost everybody does.
>

>> Most of the gaps are mostly irrelevant but still keeps the juices going.

>
>
> I've been using C++ for a bit over four years (though not exclusively),
> and every time I try to write a program in C++, I run into something
> nasty. Here's the latest example. It took the combined efforts of me
> and a C++ expert an hour or so to figure out why this program:
>
> #include <string>
> #include <iostream>
> using namespace std;
> int main(void) {
> string foo="My age is: ";
> foo += 22;
> cout << foo << endl;
> return 0;
> }
>
> was only outputting this:
>
> My age is:
>

>> I admit that learning C was far easier and that was over 20 years ago
>> now but the language is limiting.

>
>
> C++ is limiting! Most (though not all) of its features are compile time
> trickery and don't let you do anything fundamentally new.
>
> -Peter
>
> (another one of THOSE threads)
>

[felix zaslavskiy]

[email]mtsouk@freemail.gr[/email] wrote:

> Dear list,
> I want to ask a rather "philosophical" question but I would like to
> know your opinion:
>
> In which language do you prefer to program in
> a UNIX environment: C or C++?
>

Most libraries available in unix are C libraries
C++ works with C libraries just fine

if the author of C library forgot to include this in the header
#ifdef __cplusplus
extern "C" {
#end if

You can simply put this in. thats all to it !
extern "C" {
#include<someCheader.h>
}

> many thanks in advance,
> Mihalis.

[Fritz M]

[email]mtsouk@freemail.gr[/email] wrote:

> In which language do you prefer to program in
> a UNIX environment: C or C++?

"Which is better, Babylon 5 or Star Trek?" Find the answer to this FAQ
at:

[url]http://www.templetons.com/brad/emily.html[/url]


This is the troll that never ends,
It goes on and on my friends.
Some people starting singing it
Not knowing what it was
And they'll go on singing it forever just because
This is the troll that never ends...

RFM
--
To reply, translate domain from l33+ 2p33|< to alpha.
4=a 0=o 3=e +=t

[Peter Ammon]

Gianni Mariani wrote:

> Peter Ammon wrote:
>

>>>
>>>
>>> lists, maps, algorithms, strings ... need more ?
>>>

>>
>> I'm not convinced that those structures are worth the tradeoff. If
>> nothing else, you have to look at stuff like "`void std::vector<_Tp,
>> _Alloc>::push_back(const _Tp&) [with _Tp = int, _Alloc =
>> std::allocator<int>]'" when you get a type error.
>>

>
> So ?
>

It turns debugging into a process of trial and error, at least until you
learn to read C++-error-ese.

[...]

>>>> I've been using C++ for a bit over four years (though not
>>>> exclusively), and every time I try to write a program in C++, I run
>>>> into something nasty. Here's the latest example. It took the
>>>> combined efforts of me and a C++ expert an hour or so to figure out
>>>> why this program:
>>>>
>>>> #include <string>
>>>> #include <iostream>
>>>> using namespace std;
>>>> int main(void) {
>>>> string foo="My age is: ";
>>>> foo += 22;
>>>> cout << foo << endl;
>>>> return 0;
>>>> }
>>>>
>>>> was only outputting this:
>>>>
>>>> My age is:
>>>
>>>
>>>
>>>
>>> And this issue is limited to C++ ?

>>
>>
>>
>> How many languages can YOU name that have operator overloading?

>
>
> Operator overloading is an integral part of C++. If std::string does
> somthing wierd with operator +=, then smack the guy who wrote
> std::string and all those who voted to adopt it. You just can't do some
> very cool things with C++ without operator overloading.

I agree that operator overloading is fundamental to C++ and without it,
C++ would be much less cool. The problem here was related to both
operator overloading and being type unsafe.

>

>>

>>> Firstly, it's obvious to me what's wrong,

>>
>>
>>
>> Pretty much anyone looking at that code would get the wrong idea of
>> what it does.

>
>
> lay this down to experience. When I wrote my first printf( ...) in C++
> I had similar woes.

Yup. C has its warts and you just lanced one.

> So, what ! You'll not make this mistake again.
> Chalk it off to learning curve.
>

I have. But I run into some new mistake new almost every time I try to
program with C++. Meanwhile, I'm feeling happily productive in other
languages with much less time invested in learning them, so it's
becoming harder and harder to justify C++. Your mileage may vary.

>>

>>> secondly, your expert must not have had his coffee when you showed him.

>>
>>
>>
>> RIP useful type safety.

>
>
> how ?

The integer literal 22 was implicitly converted to a char because
std::string had overloaded += for a char. I can't imagine that many
people ever want to append a character to a string when they've
specified it using its decimal representation, so i consider this to be
a type error.

>

>>> Another is the power of templates and just how much the compiler may
>>> be able to deduce by itself if you design templates correctly.

>>
>>
>>
>> I agree that templates are powerful, but I think the syntax and
>> difficulty of debugging them compromises their utility.

>
>
> Yes, debuggers up until recently have proved near useless. All the more
> reason to have a good set of test cases.

I definitely agree with that! (I wish I lived it more often!)

[...]

>
> Heck ... no one stopped you from writing a one liner:
>
> cout << foo << 22 << endl;

True.

>

>>
>> (And besides, overreliance on the static types of variables causes
>> problems. I've lost count of the number of times I've been asked why
>> cout << toupper('a') doesn't output 'A'.)

>
>
> fair comment. This requires another shift of thinking away from C.

I guess it does.

>

>>
>> There are languages where you could make a *truly* generic to_string
>> function, where the function could look up the positions and types of
>> the instance variables of the class (at runtime, no less) and
>> construct a string based on those. That's the sort of feature that
>> I'd be happy to endure a steep learning curve to get.

>
>
> There are a few more things I'd like to see as well. Does that mean you
> stick with C until there is a perfect alternative ?
>

Well, no, but it means I choose alternatives to C++ more often than not.

-Peter

[Peter Ammon]

Wim Lauwers wrote:

> Peter Ammon wrote:
>

>>
>> C++ is limiting! Most (though not all) of its features are compile
>> time trickery and don't let you do anything fundamentally new.
>>
>> -Peter

>
>
> That's the point: the C++ compiler catches stuff that a C-compiler
> doesn't, which allows you to write more robust programs. Think about the
> usage of "const"

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.

> and the stricter casting rules.

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.

> Some of those features
> have been ported back to C now, so it cannot all be useless ;-)

C++ is C's guinea pig :)

>
> Same complaint as everyone else though: C++ is too complicated.
>

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

-Peter

[Peter Ammon]

llewelly wrote:

> Peter Ammon <pa44@cornell.edu> writes:
> [snip]
>

>>I've been using C++ for a bit over four years (though not
>>exclusively), and every time I try to write a program in C++, I run
>>into something nasty. Here's the latest example. It took the
>>combined efforts of me and a C++ expert an hour or so to figure out
>>why this program:
>>
>>#include <string>
>>#include <iostream>
>>using namespace std;
>>int main(void) {
>> string foo="My age is: ";
>> foo += 22;
>> cout << foo << endl;
>> return 0;
>>}
>>
>>was only outputting this:
>>
>>My age is:

>
> [snip]
>
> The key here is to realize:
>
> (a) One can add a char to the end of a string using +=. Frankly, I
> think supporting += for strings is a perverse design error in
> std::string, but that is another matter.
>
> (b) As in C, a char is an integral type.
>
> (c) As in C, 22 is an integer literal that converts readily into a
> char.
>

Yup, that's what we concluded.

> Since (b) and (c) are long time parts of C, we must conclude your 'C++
> expert' did not know C.

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

> The lesson learned here is that whatever
> you have been told, C++ still requires one to know C.

I'm torn :)

>
> Since the C++ tool for producing formatted strings is in any case
> <sstream>, and not <string>, we can also conclude that either your
> 'C++ expert' did not know C++, or that he was accostomed to
> incomplete C++ implementations, such as gcc < 3.0, which did not
> have <sstream>

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.

>
> I will note this same principle applies to your benchmark; you thought
> string would be ok because you thought string would save you from
> the trials of allocation. You were wrong; string does allocations
> behind your back, and in C++, just as in C, unecessary allocations
> are slooow.

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.

>
> With respect to the OP's question, I reccomend that he use the
> language he knows best.

:D

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

> In support of this, I refer him to Peter
> Ammon's benchmark page. In Peter's C code, he parallelized
> processing and I/O, by doing the output during the sort, a
> superior performance technique which so far as I can see he does
> not use any of the other examples.

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.

> Peter used this technique in C,
> because he is well skilled in C, and comfortable writing a sort
> that mixes processing with I/O. Mixing processing with I/O is
> important for performance, but not something one does in an
> unfamiliar language, as it is error-prone. Due to Peter's lesser
> knowledge of other languages, other examples did not benefit from
> this technique. (I don't mean to imply outputing the strings
> during the sort would have made the other examples as fast or
> faster than C; I didn't test that, but I am sure they would have
> benefited performance wise.)
>

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

[Randy Howard]

In article <bejgj5$osm$1@nntp.webmaster.com>, [email]davids@webmaster.com[/email] says...

> If it's a massive project that requires reusing a lot of existing code,
> must be maintainable, and requires dozens of cooperating programmers, C++
> wins hands down.

That sure explains the Linux kernel. :-)

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

[Peter Ammon]

felix zaslavskiy wrote:

> Peter Ammon wrote:
>

[...]

>> One way that it's worse is that it's much slower, in my experience.
>> See my page at [url]http://www.people.cornell.edu/pages/pa44/scrabble/[/url] .
>> C++ with the STL was ten times slower than C and about twice as slow
>> as Java(!). This translated into more than four second wait for a
>> program with C++, which was unacceptable when you could get the same
>> results in about .4 seconds with C.
>>

> That is absurd !!! STL can produce faster code then C equivalents
> sometimes.

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

> For example std::string class can take advantage of
> reference counting and avoid copy where and in C you usualy have to make
> copies right away and cant do it lazily like in C++.

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).

>
> Your little bench is not meaningful sorry.

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

> When you do a bench next time dont forget to
> 1. tell us the compiler version
> 2. tell us the Operating System, libstd++ and libc versions.

You're right, I should have documented that.

> 3. use the clock() function to make measurements

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

> 4. run many iterations to get good statistical results.

3 was enough for me :)

> 5. write the program optimaly. ex dont use formated io when unformated
> can do just as fine.

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

[...]

-Peter

[Peter Ammon]

santa wrote:

> i seem to like c++ a lot and never usually use c unless the task at hand is
> so simple that it really doesnot matter.
>
> OOP is a concept that is indeed worth its name
>
> santa

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

Uhm, ok.

-Peter