To go with Go or C/C++?

J

James Kanze

We can (and probably would) do the same in C++. A missing file isn't
necessarily an exceptional situation. Now if it were an exceptional
situation and the open was part of a group of resource allocations, C
code would have to include had written clean up code and quite likely a
"goto error". In C++, we'd just throw and rely on the automatic clean
up RAII provides.

The problem isn't the missing file. The problem is when you
find something in it which makes further processing impossible,
and your 10 or more levels deep in "use". At that point, in C,
you have to propagate the error up manually, to ensure that the
close is called (and that any memory you allocated in the
intermediate functions is freed). In C++, the problem more or
less takes care of itself (providing you're using the
established idioms).

This is one of the things that make C so much more difficult
than C++.
 
J

James Kanze

I learned C first. I still find that for certain kinds of I/O the
detailed control of printf & scanf is better than streams. Even though
in general the divorcing of format and values is a PITA...
eg:
printf("%4x", i)
std::cout << std::hex << std::setw(4) << i;

If you need something quick, and you've already invested the
time and effort to learn the printf markup language, then the
C style IO is OK. (Provided you only have to output simple
types, of course. In most larger applications, you'll mostly be
outputting user defined types. And usually through various
filters and such, and not directly to a file.)

But for larger applications, embedding the format in the output
string is a real maintenance nightmare. What happens when the
client says that all of the interest rates (but none of the
other values) should be output with one more digit of precision?
In C++, you modify the interest_rates manipulator, and the job
is done. In C, you have to find every fprintf in the code,
figure out which of the format specifiers concerns interest
rates, and modify it. And then get everything translated again
to other languages, since this information is embedded in the
translated strings. (Or if you're doing real local language
output, grammatically correct, etc., you have to rework all of
the language specific DLLs. Whereas in C++, all of the language
specific DLLs will have used your manipulator.)
 
Ö

Öö Tiib

The problem isn't the missing file. The problem is when you
find something in it which makes further processing impossible,
and your 10 or more levels deep in "use". At that point, in C,
you have to propagate the error up manually, to ensure that the
close is called (and that any memory you allocated in the
intermediate functions is freed). In C++, the problem more or
less takes care of itself (providing you're using the
established idioms).

This is one of the things that make C so much more difficult
than C++.

Also C is less efficient in the situation. When the case where
further processing is impossible occurs very rarely (is actually
exceptional) then all the eliminated error checking code in C++
makes it lot faster than same thing written in C.
 
8

88888 Dihedral

James Kanzeæ–¼ 2013å¹´5月3日星期五UTC+8下åˆ11時56分59秒寫é“:
If you need something quick, and you've already invested the

time and effort to learn the printf markup language, then the

C style IO is OK. (Provided you only have to output simple

types, of course. In most larger applications, you'll mostly be

outputting user defined types. And usually through various

filters and such, and not directly to a file.)



But for larger applications, embedding the format in the output

string is a real maintenance nightmare. What happens when the

client says that all of the interest rates (but none of the

other values) should be output with one more digit of precision?

In C++, you modify the interest_rates manipulator, and the job

is done. In C, you have to find every fprintf in the code,

figure out which of the format specifiers concerns interest

rates, and modify it. And then get everything translated again

to other languages, since this information is embedded in the

translated strings. (Or if you're doing real local language

output, grammatically correct, etc., you have to rework all of

the language specific DLLs. Whereas in C++, all of the language

specific DLLs will have used your manipulator.)



--

Over-loadable I/O functions are not new in C++.
But C++ emphasizes the over-loadable part in I/O
just like the virtual member functions of objects in classes.
 
R

Rui Maciel

Öö Tiib said:
Also C is less efficient in the situation. When the case where
further processing is impossible occurs very rarely (is actually
exceptional) then all the eliminated error checking code in C++
makes it lot faster than same thing written in C.

Let me get this straight: you claim that C++ is more efficient because when
C++ programs crash, they crash faster?


Rui Maciel
 
R

Rui Maciel

Tony said:
It's not nonsense. While unlearning ability varies with each individual,
there is time and effort required beyond what is required for learning to
do something "right" from the get go.

Well, it is nonsense. No one needs to unlearn anything to be able to learn
something new, let alone use a different tool.


Rui Maciel
 
Ö

Öö Tiib

For this, you must offer more evidence than simple assertion,
I'm afraid.

This is easy to test. For example two functions one returns bool that
is false very rarely, one throws very rarely (not meant as example of
good code):

bool checkThingsWithIf( int param )
{
return param % 10000 != 0;
}

void checkThingsWithTry( int param )
{
if ( param % 10000 == 0 )
{
throw true;
}
}

Too simple so compilers want to inline those, make sure they don't.
Now just write two test functions. To keep it simple I won't throw far
and deep like usual, just replace 200 ifs in cycle with one try/catch:

int testWithIf( int param )
{
int ret = 0;
for ( int j = 0; j < 200; ++j )
{
if ( !checkThingsWithIf( param+j ) )
{
return ret;
}
++ret;
}
return ret;
}

int testWithTry( int param )
{
int ret = 0;
try
{
for ( int j = 0; j < 200; ++j )
{
checkThingsWithTry( param+j );
++ret;
}
}
catch ( bool )
{ }
return ret;
}

The stuff is fast so lets run the tests million times. I write it as C-ish
as I can ...

#include <cstdio>
#include <ctime>

int main( int argc, char* argv[] )
{
clock_t volatile start;
clock_t volatile stop;
int volatile sum;

start = clock();
sum = 0;
for ( int i = 0; i < 1000000; ++i )
{
sum += testWithIf( i );
}
stop = clock();
printf( "With if it took %d msec; (sum %d)\n", ms_elapsed( start, stop ), sum );

start = clock();
sum = 0;
for ( int i = 0; i < 1000000; ++i )
{
sum += testWithTry( i );
}
stop = clock();
printf( "With try it took %d msec; (sum %d)\n", ms_elapsed( start, stop ), sum );
}


Output with Visual studio 2010 (run it *without* debugging otherwise it
heavily hooks itself to exceptions):
With if it took 921 msec; (sum 197990000)
With try it took 782 msec; (sum 197990000)

So 17% better performance thanks to replacing 200 ifs in cycle with one
try/catch.
 
Ö

Öö Tiib

#include <cstdio>

#include <ctime>

Oh, I forgot to type the ms_elapsed here:

int ms_elapsed( clock_t start, clock_t stop )
{
int main( int argc, char* argv[] )
{
clock_t volatile start;
clock_t volatile stop;
int volatile sum;

start = clock();
sum = 0;
for ( int i = 0; i < 1000000; ++i )
{
sum += testWithIf( i );
}
stop = clock();
printf( "With if it took %d msec; (sum %d)\n", ms_elapsed( start,stop ), sum );

start = clock();
sum = 0;
for ( int i = 0; i < 1000000; ++i )
{
sum += testWithTry( i );
}
stop = clock();
printf( "With try it took %d msec; (sum %d)\n", ms_elapsed( start, stop ), sum );
}
 
M

Melzzzzz

Let me get this straight: you claim that C++ is more efficient
because when C++ programs crash, they crash faster?


Rui Maciel

Exceptions come with cost (runtime or space)...
 
Ö

Öö Tiib

Let me get this straight: you claim that C++ is more efficient because when
C++ programs crash, they crash faster?

Let me get it straight, when you have your head full of nonsense then
whatever you look at looks like that nonsense in your head.
 
B

Bo Persson

Rui Maciel skrev 2013-05-03 19:35:
Well, it is nonsense. No one needs to unlearn anything to be able to learn
something new, let alone use a different tool.

This is about learning C as a prerequisite for learning C++. That's a
waste of time, unless the goal is to learn both. In that case, the order
is not important anyway.


Bo Persson
 
I

Ian Collins

Scott said:
There's a saying, "One swallow doesn't make a summer".

This contrived benchmark illustrates nothing.

Every contrived benchmark and real world example I've tried since gcc
2.95 days (the first g++ I used) have shown a similar result. That's
quite a lot of swallows.
 
I

Ian Collins

Bo said:
Rui Maciel skrev 2013-05-03 19:35:

This is about learning C as a prerequisite for learning C++. That's a
waste of time, unless the goal is to learn both. In that case, the order
is not important anyway.

There's an awful lot more to unlearn going from C++ to C!
 
B

Bo Persson

Scott Lurndal skrev 2013-05-03 21:55:
There's a saying, "One swallow doesn't make a summer".

This contrived benchmark illustrates nothing.

Right! :)

So when we have an example of where C++ is faster by design, that
doesn't count.

Want to see another contrived example of when using templates is faster
than function pointers?

std::sort vs qsort http://www.stroustrup.com/new_learning.pdf


Bo Persson
 
B

Bo Persson

Melzzzzz skrev 2013-05-03 20:22:
Exceptions come with cost (runtime or space)...

So easier to write code that runs faster is no longer an advantage?

You prefer to write more C code that runs slower, because that gets you
a smaller executable?


Bo Persson
 
M

Melzzzzz

Melzzzzz skrev 2013-05-03 20:22:

So easier to write code that runs faster is no longer an advantage?

You prefer to write more C code that runs slower, because that gets
you a smaller executable?

No. I use C++ (and exceptions) all the time. It's just a fact that
that comes with a cost.
 
A

Anand Hariharan

Want to see another contrived example of when using templates is faster
than function pointers?

std::sort vs qsort  http://www.stroustrup.com/new_learning.pdf

There was a belaboured discussion over at comp.lang.c regarding the
very paper some years ago:
http://groups.google.com/group/comp.lang.c/browse_frm/thread/6abed6973deb0bd6/

Some of the posts there really irked Bjarne Stroustrup that, he
reacted in that thread so:

"I have of course known C well for
longer than most posters here have been alive (and I am a major
contributor to modern C), but just in case I had overlooked something
major, I did have my C code in that paper looked at by C experts of a
magnitude or two larger than most people who hang out here (remember,
I was in Bell Labs Computer Science Research Center at the time - look
it up if you don't know what that is relative to C and C++).

Read the paper, you might be surprised and you might actually learn
something.".


(Apologies in advance if Google Groups messes up my post.)

I say all this simply to avoid repeating history. There is ZERO VALUE
in comparing two programming languages (especially so if they are
"siblings").

- Anand
 
I

Ike Naar

Every contrived benchmark and real world example I've tried since gcc
2.95 days (the first g++ I used) have shown a similar result.

What's the difference between an example and a real world example?
 
J

Jorgen Grahn

If you need something quick, and you've already invested the
time and effort to learn the printf markup language, then the
C style IO is OK.

Especially since other languages have inherited the syntax -- you need
to know parts of printf() to use shell scripting, Perl, Python, ...
(Provided you only have to output simple
types, of course. In most larger applications, you'll mostly be
outputting user defined types. And usually through various
filters and such, and not directly to a file.)

But for larger applications, embedding the format in the output
string is a real maintenance nightmare. What happens when the
client says that all of the interest rates (but none of the
other values) should be output with one more digit of precision?
In C++, you modify the interest_rates manipulator,

Or the ostream << InterestRate function.
and the job is done. In C, you have to find every fprintf in the code,
figure out which of the format specifiers concerns interest
rates, and modify it. And then get everything translated again
to other languages, since this information is embedded in the
translated strings. (Or if you're doing real local language
output, grammatically correct, etc., you have to rework all of
the language specific DLLs. Whereas in C++, all of the language
specific DLLs will have used your manipulator.)

Nice overview, but I think Mr Champ covered that with his "the
divorcing of format and values is a PITA" so you may not be in
disagreement.

/Jorgen
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top