To go with Go or C/C++?

[Jorgen Grahn]

Beautiful. The analogy is perfect: C is a unicycle, C++
a bicycle, and Java a tricycle.

Beautiful indeed, but a bit unfair to C. It's more like a fixed-gear
bike without mudguards or chainguard -- it will take you to your
destination, but with larger effort on your part and your clothes will
be dirty afterwards.

/Jorgen

 

[Rui Maciel]

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.

Instead of trying to evade question with petty insults it would be better if
you addressed the flaws in your reasoning. You specifically addressed cases
"where further processing is impossible", and proceeded to state that your
unfounded claims regarding efficiency would shine specifically on these
circumstances.

So, do your claims actuallly have a shred of substance or are you going to
yet again avoid the issue by throwing a string of insults?


Rui Maciel

 

[Öö Tiib]

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

This contrived benchmark illustrates nothing.

The example only replaced 200 simple ifs in cycle with try catch outside
cycle because the condition was rare. Exactly like I told. What was so
contrived about it?

If to look into real code bases then 60-80% of the code deals with such rare
cases so the effect is bigger. All edge cases are handled in good code.
Exceptions + RAII let to deal with most rare edge cases more elegantly
(like James told) and more efficiently (like I did show).

 

[Rui Maciel]

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.

They are actually only two swallows: it's the same specific example compiled
under a different compiler.

I don't doubt that C++'s version may run faster. It's just that it's a
mistake to extrapolate particular results in this way.


Rui Maciel

 

[Öö Tiib]

Instead of trying to evade question with petty insults it would be betterif
you addressed the flaws in your reasoning.

The flaw was in your reasoning. You interpreted what I told as nonsense.

You specifically addressed cases "where further processing is impossible",

The case when a function in situation where further processing is impossible
is very commonly handled in every real piece of code. Wtf? You were asking
that seriously? Do you handle edge cases by crashing the software?

and proceeded to state that your unfounded claims regarding efficiency
would shine specifically on these circumstances.

Specifically when the condition occurs "very rarely". I provided a benchmark
else thread.

So, do your claims actuallly have a shred of substance or are you going to
yet again avoid the issue by throwing a string of insults?

If yours was proper question then mine answer was fine explanation of
what really happened.

 

[Stefan Ram]

Especially since other languages have inherited the syntax -- you need
to know parts of printf() to use shell scripting, Perl, Python, ...

This is like bacteria swapping DNA. For example, what is also
spreading like a wildfire between modern programming languages
are regular expressions. In this case, the origin might have be
shell programming and then Perl. For »printf« see
»The March of Progress« on

http://www.horstmann.com/

 

[Balog Pal]

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

This far we discussed exceptions. Those are for rare, but expected, and
*handled* conditions. Not crash.

Like you save your program state in a file -- it involves several
thousands or millions of individual writes. Any can fail due to disk
full condition, but it happens rarely. The C++ code is completely
straightforward, all you see is a series of writes for each object -- a
few throw instructions in the File implementation and one catch at top
level.

The naive C version uses ifs on every write and massive amount of code
doing return code football to propagate up, making it pretty unreadable,
so likely buggy. The realistic C code would miss half or all the
checks on the file operations so work only when everything actually
succeeds.

An advanced C version would probably create a File object with sticky
bits that will waste much time till getting to the end, but at least
correct for the write -- but doing same for read back still leaves lots
of mandatory checks of the state to avoid acting on non-read data.

With exceptions it is as straightforward -- the source reflects only
what is necessary and any kind of error immediately halts the load with
relevant error report.

 

[Rui Maciel]

This far we discussed exceptions. Those are for rare, but expected, and
*handled* conditions. Not crash.

The expression "where further processing is impossible" was explicitly used.
If the program is left in a state where it's possible to process away the
control flow , even when established through exceptions, then "further
processing" is undoubtedly possible. When it actually is impossible to
carry on then the flow of control won't go further than where it already is,
because the process is killed.


Rui Maciel

 

[Rui Maciel]

The case when a function in situation where further processing is
impossible is very commonly handled in every real piece of code. Wtf? You
were asking that seriously? Do you handle edge cases by crashing the
software?

Sorry, your word alone doesn't carry any weight. Are you actually able to
substantiate your claim with any basis or even with tangible evidence, or
will you carry on with a string of petty insults? For example, can you
provide an actual example where, in spite of further processing being
impossible, further processing is actually done and the process keeps on
running?

And before you make the mistake of claiming that exceptions make the
impossible possible, all exceptions do is define a regular control flow,
just like any conditional statement. If the system is left in a state where
it's possible to follow a control flow which has been established through
the exception handling mechanism then obviously further processing is quite
possible.


Rui Maciel

 

[Balog Pal]

The expression "where further processing is impossible" was explicitly used.

What from the context applied to the actual function. Not the whole
program. (Or should have been so).

IMO it is (or again, should be) common knowledge that exceptions are NOT
good for the assert/terminate condition, handling failed preconditions,
allowing to go ahead from *unknown* program state. If the program
derailed, you better stop right there.

But we have many situations with failing runtime conditions, that are to
be expected -- timeout of DB operations, exhausting system resources
including memory, file ops, etc -- that just ask for being handled via
exceptions. The program state is good, just the problem is detected
calling some system/library function that reports trouble and is
mandatory to check in the first place. But the handler shall not be at
the spot -- but centralized.

If the program is left in a state where it's possible to process away the
control flow , even when established through exceptions, then "further
processing" is undoubtedly possible. When it actually is impossible to
carry on then the flow of control won't go further than where it already is,
because the process is killed.

But we were not talking about that case. Please switch back to the
original line of thoughts or leave it -- no point to pursue a dead branch.

 

[Bart van Ingen Schenau]

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

In that case, there is even more to unlearn when going from Java to Lisp.
But I would not term it unlearning if you don't use knowledge that you
have because it is not applicable in the new language you are learning.

Bart v Ingen Schenau

 

[Nick Keighley]

Picking up enough C++ to start doing good (or harm) in any field does
not really require years of full-time exposure.  Since C++ is a general
purpose language (like Java or D, for instance), knowing the language is
really not a strict prerequisite for getting a job in some field of
applying the language.  At least not as much as knowing the field.

Seriously? I got my last two jobs for knowledge of C++ in
application fields I knew nothing about.

 

[Nick Keighley]

That's for sure. But to really understand C (or motivation behind it),
one has to know at least one assembler.

Nonsense

 

[Nick Keighley]

Picking up enough C++ to start doing good (or harm) in any field does
not really require years of full-time exposure.  Since C++ is a general
purpose language (like Java or D, for instance), knowing the language is
really not a strict prerequisite for getting a job in some field of
applying the language.  At least not as much as knowing the field.

Seriously? I got my last two jobs for knowledge of C++ in
application fields I knew nothing about.

 

[Rui Maciel]

This is easy to test.

It is.

<code>
#include <cstdio>
#include <ctime>

int ms_elapsed( clock_t start, clock_t stop )
{
return static_cast<int>( 1000.0 * ( stop - start ) / CLOCKS_PER_SEC
);
}

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

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

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;
}



void benchmark( int (*foo)(int))
{
clock_t volatile start;
clock_t volatile stop;
int volatile sum;

start = clock();
sum = 0;
for ( int i = 0; i < 1000000; ++i )
{
sum += (*foo)( i );
}
stop = clock();
printf( "It took %d msec; (sum %d)\n", ms_elapsed( start,stop) , sum
);
}

void benchmark( int (*foo)(int))
{
clock_t volatile start;
clock_t volatile stop;
int volatile sum;

start = clock();
sum = 0;
for ( int i = 0; i < 1000000; ++i )
{
sum += (*foo)( i );
}
stop = clock();
printf( "It took %d msec; (sum %d)\n", ms_elapsed( start,stop) , sum
);
}

int main( int argc, char* argv[] )
{
benchmark( &testWithTry);
benchmark( &testWithIf);
}
</code>

<output>
rui@kubuntu:tmp$ g++ -O0 main.c++ && ./a.out
It took 2130 msec; (sum 197990000)
It took 2280 msec; (sum 197990000)
rui@kubuntu:tmp$ g++ -O1 main.c++ && ./a.out
It took 1150 msec; (sum 197990000)
It took 1050 msec; (sum 197990000)
rui@kubuntu:tmp$ g++ -O2 main.c++ && ./a.out
It took 1160 msec; (sum 197990000)
It took 670 msec; (sum 197990000)
rui@kubuntu:tmp$ g++ -O3 main.c++ && ./a.out
It took 700 msec; (sum 197990000)
It took 670 msec; (sum 197990000)
</output>


Rui Maciel

 

[Öö Tiib]

Sorry, your word alone doesn't carry any weight. Are you actually able to
substantiate your claim with any basis or even with tangible evidence, or
will you carry on with a string of petty insults? For example, can you
provide an actual example where, in spite of further processing being
impossible, further processing is actually done and the process keeps on
running?

The "impossible to proceed" task has to be canceled not proceeded. What
is done after canceling depends on design. On most cases the software
continues running. May retry, may do other things. Mechanisms of such
canceling were discussed and then you jumped in with nonsense of
crashes in your software trying to pose like I was talking of those.

And before you make the mistake of claiming that exceptions make the
impossible possible, all exceptions do is define a regular control flow,
just like any conditional statement. If the system is left in a state where
it's possible to follow a control flow which has been established through
the exception handling mechanism then obviously further processing is quite
possible.

That is the nonsense that you try to push. Just stop it, such nonsense addsno
value and it was nowhere neither meant nor said how hard you try. I have
never claimed that program somehow manages to do what is impossible
(like to read from disconnected socket).

 

[Tony]

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

I "believe you", but with some reservations. I.e., multi-level propagation is no
panacea and is very likely to be used as a way to "pass the buck" rather than to
think about the problem at hand. I'm not comparing EH to return-an-error-code
and saying that the latter is in any way better, I'm just saying that EH, as
implemented in C++, is not something that gives a language evaluator the warm
fuzzies.

***

On another track, comparing C++ with C is implying that C++ can only compete
with that archaic language. C is not in the same class or same era as C++.
Comparing the two is comparing apples and oranges.

***

On still another track, I don't think C++ 14 will be as minor a release as is
being suggested. It will be late, but will have features to keep it a contender.
2017 is MUCH too far away for a major release cycle of a programming language.
(My .03). (Hehe, just the fact that I said I may target some of C++'s target
market with my "NBL", surely will kick the committee into high gear).

***

James, you are rather "textbooky", but your posts are good. Keep 'em coming!

 

[Tony]

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

scott

I sense a round-and-round issue being brought up again: how to best deal with
errorneous/exceptional conditions in software. As this seems to be "fun" for
many, and "no one does it right" yet, fine and dandy. It would seem to me,
though, that the long-time-redundant thoughts on the issue should be put
somewhere and linked-to rather than bring them up all over again ad infinitum.
(or is it that I should read/post in the moderated group for more mature
addressing of the issues?).

 

[Tony]

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

Was that a scapegoat? I understand. Are you afraid to post code here that you
think is "good code" for you know that there are a hundred programmers just
waiting for the opportunity to pounce on it and tell you, not only why it is
bad, but why you should be a manure slinger and they should be telling you where
to sling it?

bool checkThingsWithIf( int param )

"checkThingsWithIf"

I call that "stupidcase": not CamelCase, not lowercase with underscores between
words, just stupidCase.

(Get my drift about my point above now?)

Enough digression though (I have a tendancy!), the topic is dealing with errors,
in particular, dealing with errors A idiomatic C way, compared with THE
idiomatic C++ way (note that "dealing with errors in C idiomatically" is an
oxymoron). The function signature notes that a bool is returned. So, no
indication what that return value actually is though. It could be akin to "I'll
call you tomorrow, or maybe not", or "You offended me with your suggestion, so
I'm going to punch you in the nose". No way of telling.

{
return param % 10000 != 0;
}

So what if the remainder is not zero? (I'm not going to even try to consider
what you where getting at with your example, but I think you could have chosen a
clearer one: one that isolates the error stuff from the code. As it is, you have
one of those C-like statements as the body of the function which doesn't help at
all. It should be clear even to the novice, but isn't. I mean, you wouldn't use
that as an example in a teaching setting.)

That said, fine, we have your C-way example established. (Note, again, though,
that there is no idiomatic C-way of dealing with errors and your's is
particularly weak).

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

Throw 'true'? Surely you jest! Your example(s) now are going to the suck side of
the suckiness meter.

Oh man! I glanced at the rest of your post but was completely turned-off, but
surely you had something relevant to say that I missed IN THE FIRST FEW
PARAGRAPHS of your post, so I began responding from the beginning of it (I don't
"pre-read, then post" (else I'd be James Kanze? ), but I had something of
value (IMO) to say too, so it's all good.

Too simple so compilers want to inline those, make sure they don't.

I will make sure my compiler doesn't!

Now just write two test functions. To keep it simple

You wouldn't know "simple" if <I'm not good at quips, so add one here that I
would have liked to>.

I won't throw far
and deep like usual,

Football metaphor. Doesn't get points with me. I think there is an over-focus on
sports and those who like sports, make others pay for them, and that's not nice.

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;
}

Too long. You post as if you're talking to a bunch of hard-core, C-evolved, C++
programmers.

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 );
}

Were you drinking when you wrote that? Wow. It's OK, but shouldn't there
be/isn't there a separate NG for that kind of thing?

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.

Take another swig kid.

 

[Tony]

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:

He actually posts online in threaded discussion?

"I have of course known C well for
longer than most posters here have been alive

"years of experience" do count, but not like he appears to want them to in that
sentiment. Let me translate how that be comprehended:

"I have 'time in grade', and I damn do deserve more than I've gotten from giving
it away".

Was there anything else you wanted to do or be known for Bjarne? And while I'm
asking questions at you, having left AT&T with this white elephant C++ thing,
and having moved to academia, is it better? Yeah, for you: I mean they quickly
ravaged your quick hack, and gave you your pink slip. (rhetorical). (I don't
want to know your thoughts on "that" here. Every AT&T and the horse they rode in
are waiting to capitalize on it. Hmm? I conjecture, I don't "know".)

(and I am a major
contributor to modern C),

When was that stated? Because today "modern C" is an oxymoron.

but just in case I had overlooked something
major,

"just in case"?? Pray tell, what do are you on about?

I did have my C code in that paper looked at by C experts

Appeal to authority? So, not being an actual "expert", and them putting it in to
production is something you are "wrestling with"? (rhetorical).

of a
magnitude

That's a feeling, not a quantification. Hmm? (rhetorical).

or two

Whoa! Not one, but TWO. This is hurt. You are expressing hurt. A lot of hurt is
caused. "They" make is seem necessary. "They" rely on you to call "me" a
"conspiracy theorist"(?) (good gawd, are you retracting, or moving forward?).

larger

I believe you did and now it's probably even bigger (are you sorry you chose to
describe "in orders of magnitude", (rhetorical)).

than most people who hang out here (remember,
I was in Bell Labs

WTF, I'm not afraid of them: HELL labs? I need AT&T cables (copper?), to keep me
in my place? Someone here called me angry, while I am not that, don't push my
buttons. (Aside: AT&T says I owe them money, but that is so trivial not to be
said, but says something about my faith in ... well ok, I don't have to think or
say that everything is a bunch of bullshit, because while it is, it causes a lot
of hurt.)

Computer Science Research Center at the time - look
it up if you don't know what that is relative to C and C++).

Pfft. Look me up when you fix the "educational institutions". Bitch. I mean, can
we talk, it's like butter. The book thing. Books and publishers and authors that
milk the prospect. It's an example of wrong-doing: schools (pfft, ya mean
"schools", I've been to some of those) requiring (no they didn't, but my
"attack" has validity) what version of what book? I have ALL of my books from
college. A few years ago, at great dismay, mind you, I was willing to give them
up (too much to tell there, I collected others and it was all for naught, all
that information), and I found that they were worthless.

Worthless! Go figure. To me this was good information. But now worth only the
paper it was printed on.

Colleges (schools, prisons) are a business. Hmm? I hear someone saying, "Tony,
hello, what isn't?".

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

Pay me to read it. Pay me to evaluate it. Show me the money. What is Amway good
for: teaching. Read: I don't think it takes a BAD example to teach, but that is
the "order of the day". I don't offer any products or services for free. If you
are (ARE, don't hide behind your flag or corporate status) and exploiting others
(OMG, this is the order of the day?), what the **** you gonna do about it? Hmm?