To go with Go or C/C++?

[Tony]

Sorry, your word alone doesn't carry any weight.

"weight" and words. What if your president said it? Would you hurry to go to
war? Do his words have "weight"? What is fear? What is stupidity? I don't see
any presidents or "stalwarts" chompin to go to war.

What you want is "authority". Hmm? Or you don't but want to war against the
oppression that you know. More bombs? More government. More politics. Everything
but practicality and humanity.

You want "a leader"? Aren't "they" just waiting for you to say that "they" are
admonished, and that you elected them?

You want the same, "at another level", maybe? You "want" to comply to programmed
paths. I'm just sayin. I'm kinda a victim of that, I understand.

Are you actually able to
substantiate

If you are calling for substance, didn't you already lose?

your claim

What's the point of arguing with others on the boats to Normandy?

with any basis or even with tangible evidence,

OK, so you feel something is very wrong but afraid or unable to do anything
about it. This feeling I know. No control. It's bad, and "the leaders" are bad,
because they are not that: they are bad. Whoa before you call me a disser, you
got to elect them, yes? Bring it: "the vote", is bad. You do that, and all those
who voted against whatever issue are not in agreement.

I know what you're thinking: so "Tony", are you suggesting that a "government"
based upon "the vote", is bad?". Yes. It's not academic, but "they" don't care
about that.

"the fed": get off my money. You don't tell me what my money is worth: I earned
it, and it is worth today, what I put into it yesterday. "Mr. Fed": get your
hand off the button.

There are many things to do to make things better. There is no reason for
bullshit like war, governments, voting, etc.

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?

I don't understand. Are you saying you like to operate the power plant and that
is your life and livelihood? Help me with this.

 

[Rui Maciel]

Yes, we get it. On if and an exception is usually slower than just an
if.

Feel free to come up with a counterexample.

(Not really sure what that adds to the rest of the discussion though.)

The example is patently convoluted and poorly conceived, but it was the one
which was presented as proof that exceptions were magical. If it was the
only evidence presented to support that myth then demonstrating it's bull is
enough to refute the whole hypothesis.

In other words, it's silly to insist that something is more efficient if
it's not possible to come up with a case where that efficiency is actually
observed.


Rui Maciel

 

[Tony]

I think that's C.

I once saw C compared to a really, really sharp knife. In the hands of
the expert it's a powerful tool; in the hands of the inexperienced it's
thoroughly dangerous.

Andy

You seem like a spirited fellow Andy, I just feel like maybe you wanna go a few
rounds in the ring with "me": you punch me in the face, I punch you in the face.
Someone said I was angry. Are you 'scared Andy? Hmm?

 

[Tony]

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

Well, Rui, it isn't. I'm not going to spend any time "enlightening your" or
responding to your troll. I "don't go well with BS online", so shut up. You are
trying to provoke me.

 

[Tony]

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.

It's not about that at all. C is a thing, not a person. If you want to discuss
the things about things people do for money, oh wait, C++ is the next crime
against humanity? (Don't tempt me, you KNOW I will go there, not to calm you
though).

What is important Bo?

 

[Tony]

Well C is still the dominant language in kernel and embedded
programming, an area where C++ is equally well suited. C++ tends to
loose out to C in this area more due to dogma and FUD than technical
shortcomings.

That's a trick question?

 

[Öö Tiib]

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

(Get my drift about my point above now?)

I see that "not meant as example of good code" is so difficult to
understand especially when why it was not meant to be a demo of good
code should be apparent. I was asked to provide evidence about
performance of the language elements under discussion. Therefore no
"idioms", "syntactic sugars", "nice naming", "good algorithms for
calculating 197990000" or other things like that were attempted to
be demonstrated.

It must not be surprise that any real code should not aim to madly
throw 64 000 trues per second like the example that I posted
did. That 'true' was also thrown just for simplicity, thrown pointer
to some 'static std::runtime_error const TheTrue("true");' performs
as fast as a thrown bool on most platforms however it does take

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

Both return values and exceptions are used in C++. Both are idiomatic C++
ways. Both are sometimes supported side-by-side even by the language
elements and standard library. Exceptions are used for exceptionally
rare show-stopper problems. For everything more tolerable various
'nullable', 'optional' or 'fallible' patterns/values can be used instead.
If some condition is exceptional or common is a meta-information that
the designer of software should estimate; the language does not dictate
anything here.

See for example dynamic_cast. If a programmer expects dynamic_cast
to fail relatively commonly then he can cast a pointer and check for
nullptr returned. If he considers dynamic_cast's failing to be
exceptionally rare show-stopper problem then he can cast a reference
and catch bad_cast somewhere up-stream where that whole failing
operation was started. If he considers dynamic_cast to be smelly and
expensive language element then he can forbid its usage in his
coding standards and not to use it at all.

I was showing a break-point where exceptions already perform a bit
better than checked return values and nothing else.

 

[Daniel]

The problem is that you have to forget A LOT of C, like

printf and scanf

C string handling

pointers and arrays

malloc and free

inventing odd names instead of overloaded functions

typedef struct

prefixed names instead of namespaces

pass-by-pointer instead of pass-by-reference

that << and >> are some odd bit shifting instead of I/O operators

How much time have we lost after learning all this?

Not so much, I think Coming from a Pascal and FORTRAN background, I taught myself C in one day with the help of a book, albeit a very long day in front of an 8086 PC, and digested all of those things except perhaps

prefixed names instead of namespaces

(I learned about prefixed names much later from Lakos.) In contrast, it took me several years to become somewhat proficient with C++.

Daniel

 

[Stefan Ram]

(I learned about prefixed names much later from Lakos.)

From my knowledge of the English word »prefix«, I tought
a prefix name was just a name a part of which is considered
to be a »prefix« (like »str« in »strcpy«, »strcat« and so on).

Is it something more elaborate?

BTW: C89 and C90 only require linkers to have six
significant characters (»strcpy«, »strcat«). So, a prefix
cannot be very long. However, one might try to work around
this using structs, which also might double as a kind of
»namespace« in C.

 

[88888 Dihedral]

Stefan Ramæ–¼ 2013å¹´5月6日星期一UTC+8下åˆ8時29分06秒寫é“：

From my knowledge of the English word �prefix�, I tought

a prefix name was just a name a part of which is considered

to be a �prefix� (like �str� in �strcpy�, �strcat� and so on).



Is it something more elaborate?



BTW: C89 and C90 only require linkers to have six

significant characters (�strcpy�, �strcat�). So, a prefix

cannot be very long. However, one might try to work around

this using structs, which also might double as a kind of

�namespace� in C.

Well, lets check the C++ libraries about the hash table.

A constant string can be the key.

I am glad that I don't want to build some sparse n-ary trees.

 

[88888 Dihedral]

88888 Dihedralæ–¼ 2013å¹´5月6日星期一UTC+8下åˆ9時03分51秒寫é“：

Stefan Ramæ–¼ 2013å¹´5月6日星期一UTC+8下åˆ8時29分06秒寫é“：




Well, lets check the C++ libraries about the hash table.



A constant string can be the key.



I am glad that I don't want to build some sparse n-ary trees.

Sorry, I don't want to build a library
of n-ary trees in C/C++ as long as I can use a good
built-in hash table to perform operations required
of a tree.

 

[James Kanze]

On Fri, 03 May 2013 18:32:27 +0100

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

Checking return codes come with cost. Significantly more
cost than exceptions in terms of runtime. As for space... extra
code is extra code, in both cases. With the difference that the
exception code is more or less generic, so while it is more
complicated than a single runtime check, it only occurs once,
where as the runtime checking occurs every time you return from
a function. Not to mention that the runtime checking is inline,
and so blows up the locality of the functions which contain it.

The one case where exception handling could have a negative
impact is in optimization. The optimizer must take into account
the extra paths of flow control, which could possibly in some
cases prevent code movement (although not that much, because C++
doesn't give you many guarantees in this regard anyway). The
effect is probably very small, however.

 

[Melzzzzz]

Checking return codes come with cost. Significantly more cost than
exceptions in terms of runtime. As for space... extra code is extra
code, in both cases. With the difference that the exception code is
more or less generic, so while it is more complicated than a single
runtime check, it only occurs once, where as the runtime checking occurs
every time you return from a function. Not to mention that the runtime
checking is inline,
and so blows up the locality of the functions which contain it.

Problem with exceptions is that they come with cost used or not.
You have to annotate functions with throw() in order to avoid that
cost. In that convinced me P.J.Plaugger some years ago ...

 

[Melzzzzz]

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

bmaxa@maxa:~/examples$ g++-trunk -Wall -O0 tryif.cpp -o tryif
bmaxa@maxa:~/examples$ ./tryif
It took 830 msec; (sum 197990000)
It took 760 msec; (sum 197990000)
bmaxa@maxa:~/examples$ g++-trunk -Wall -O1 tryif.cpp -o tryif
bmaxa@maxa:~/examples$ ./tryif
It took 540 msec; (sum 197990000)
It took 240 msec; (sum 197990000)
bmaxa@maxa:~/examples$ g++-trunk -Wall -O2 tryif.cpp -o tryif
bmaxa@maxa:~/examples$ ./tryif
It took 410 msec; (sum 197990000)
It took 270 msec; (sum 197990000)

 

[Melzzzzz]

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.

bmaxa@maxa:~/examples$ g++-trunk -c -O2 module.cpp -o module.o
bmaxa@maxa:~/examples$ g++-trunk -O2 tryif.cpp module.o -o tryif
bmaxa@maxa:~/examples$ ./tryif
It took with try 400 msec; (sum 197990000)
It took with if 410 msec; (sum 197990000)
bmaxa@maxa:~/examples$ g++-trunk -c -O1 module.cpp -o module.o
bmaxa@maxa:~/examples$ g++-trunk -O1 tryif.cpp module.o -o tryif
bmaxa@maxa:~/examples$ ./tryif
It took with try 440 msec; (sum 197990000)
It took with if 400 msec; (sum 197990000)
bmaxa@maxa:~/examples$ g++-trunk -c -O0 module.cpp -o module.o
bmaxa@maxa:~/examples$ g++-trunk -O0 tryif.cpp module.o -o tryif
bmaxa@maxa:~/examples$ ./tryif
It took with try 840 msec; (sum 197990000)
It took with if 760 msec; (sum 197990000)

 

[Melzzzzz]

With more realistic example:

bmaxa@maxa:~/examples$ cat module.cpp
#include <cstring>
#include <stdexcept>

bool checkThingsWithIf( int param, char* error, unsigned errsz )throw()
{
if( param % 10000 == 0)
{
strncpy(error,"some error",errsz);
return false;
}
return true;
}

void checkThingsWithTry( int param )
{
if ( param % 10000 == 0 )
{
throw std::runtime_error("some error");
}
}

bmaxa@maxa:~/examples$ cat tryif.cpp
#include <cstdio>
#include <ctime>
#include <exception>

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

bool checkThingsWithIf( int param, char* error,unsigned errsz )throw();

void checkThingsWithTry( int param );

int testWithIf( int param )
{
int ret;
char buf[256];
for ( int j = 0; j < 200; ++j )
{
if ( !checkThingsWithIf( param+j,buf,sizeof buf ) )
{
return ret;
}
++ret;
}
return ret;
}

int testWithTry( int param )
{
int ret;
try
{
for ( int j = 0; j < 200; ++j )
{
checkThingsWithTry( param+j );
++ret;
}
}
catch (const std::exception& )
{ }
return ret;
}



void benchmark( int (*foo)(int), const char* label)
{
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( "%s it took %d msec; (sum %d)\n", label,ms_elapsed( start,stop) , sum );
}

int main( int argc, char* argv[] )
{
benchmark( &testWithTry,"With try");
benchmark( &testWithIf,"With if");
}

bmaxa@maxa:~/examples$ g++-trunk -c -O2 module.cpp -o module.o
bmaxa@maxa:~/examples$ g++-trunk -O2 tryif.cpp module.o -o tryif
bmaxa@maxa:~/examples$ ./tryif
With try it took 340 msec; (sum 197990000)
With if it took 410 msec; (sum 197990000)
bmaxa@maxa:~/examples$ g++-trunk -c -O1 module.cpp -o module.o
bmaxa@maxa:~/examples$ g++-trunk -O1 tryif.cpp module.o -o tryif
bmaxa@maxa:~/examples$ ./tryif
With try it took 490 msec; (sum 197990000)
With if it took 510 msec; (sum 197990000)
bmaxa@maxa:~/examples$ g++-trunk -c -O0 module.cpp -o module.o
bmaxa@maxa:~/examples$ g++-trunk -O0 tryif.cpp module.o -o tryif
bmaxa@maxa:~/examples$ ./tryif
With try it took 870 msec; (sum 1525529904)
With if it took 860 msec; (sum 1525529904)


Seems that exceptions win when throwing exception
objects instead of filling error buffer

 

[Melzzzzz]

int testWithIf( int param )
{
int ret;

int testWithTry( int param )
{
int ret;

bmaxa@maxa:~/examples$ g++-trunk -c -O2 module.cpp -o module.o
bmaxa@maxa:~/examples$ g++-trunk -O2 tryif.cpp module.o -o tryif
bmaxa@maxa:~/examples$ ./tryif
With try it took 340 msec; (sum 197990000)
With if it took 410 msec; (sum 197990000)
bmaxa@maxa:~/examples$ g++-trunk -c -O1 module.cpp -o module.o
bmaxa@maxa:~/examples$ g++-trunk -O1 tryif.cpp module.o -o tryif
bmaxa@maxa:~/examples$ ./tryif
With try it took 490 msec; (sum 197990000)
With if it took 510 msec; (sum 197990000)
bmaxa@maxa:~/examples$ g++-trunk -c -O0 module.cpp -o module.o
bmaxa@maxa:~/examples$ g++-trunk -O0 tryif.cpp module.o -o tryif
bmaxa@maxa:~/examples$ ./tryif
With try it took 870 msec; (sum 1525529904)
With if it took 860 msec; (sum 1525529904)


Seems that exceptions win when throwing exception
objects instead of filling error buffer

It was result of undefined behavior
Actually exceptions are slower...

bmaxa@maxa:~/examples$ g++-trunk -c -O2 module.cpp -o module.o
bmaxa@maxa:~/examples$ g++-trunk -O2 tryif.cpp module.o -o tryif
bmaxa@maxa:~/examples$ ./tryif
With try it took 450 msec; (sum 197990000)
With if it took 400 msec; (sum 197990000)
bmaxa@maxa:~/examples$ g++-trunk -c -O1 module.cpp -o module.o
bmaxa@maxa:~/examples$ g++-trunk -O1 tryif.cpp module.o -o tryif
bmaxa@maxa:~/examples$ ./tryif
With try it took 500 msec; (sum 197990000)
With if it took 450 msec; (sum 197990000)
bmaxa@maxa:~/examples$ g++-trunk -c -O0 module.cpp -o module.o
bmaxa@maxa:~/examples$ g++-trunk -O0 tryif.cpp module.o -o tryif
bmaxa@maxa:~/examples$ ./tryif
With try it took 920 msec; (sum 197990000)
With if it took 880 msec; (sum 197990000)

 

[Öö Tiib]

With more realistic example:

bmaxa@maxa:~/examples$ cat module.cpp
#include <cstring>
#include <stdexcept>

bool checkThingsWithIf( int param, char* error, unsigned errsz )throw()
{
if( param % 10000 == 0)
{
strncpy(error,"some error",errsz);
return false;
}
return true;
}

I omitted that 'throw()' in hope that compilers can well see themselves
that the function does not throw. At least visual studio did not
add stack unwinding code to it.

In C code that I have seen the functions return an int. Sometimes
there is enum returned. One value (often 0) indicates success and rest
of the values mean error codes. It is unlikely that whole string buffer
and its size as parameters will be devoted to error handling in real
code.

void checkThingsWithTry( int param )
{
if ( param % 10000 == 0 )
{
throw std::runtime_error("some error");
}
}

Lot of C++ coding standards require throwing application-specific
exceptions. Such may be inherited from std::exception family but note
that in memory-constrained situation the bad_alloc will fly here
instead of runtime_error.

Other code was like it was for testing purposes. Catch
chains in actual applications are commonly farther around big
operations not around for cycles of 200.

bmaxa@maxa:~/examples$ g++-trunk -c -O2 module.cpp -o module.o
bmaxa@maxa:~/examples$ g++-trunk -O2 tryif.cpp module.o -o tryif
bmaxa@maxa:~/examples$ ./tryif
With try it took 340 msec; (sum 197990000)
With if it took 410 msec; (sum 197990000)
bmaxa@maxa:~/examples$ g++-trunk -c -O1 module.cpp -o module.o
bmaxa@maxa:~/examples$ g++-trunk -O1 tryif.cpp module.o -o tryif
bmaxa@maxa:~/examples$ ./tryif
With try it took 490 msec; (sum 197990000)
With if it took 510 msec; (sum 197990000)
bmaxa@maxa:~/examples$ g++-trunk -c -O0 module.cpp -o module.o
bmaxa@maxa:~/examples$ g++-trunk -O0 tryif.cpp module.o -o tryif
bmaxa@maxa:~/examples$ ./tryif
With try it took 870 msec; (sum 1525529904)
With if it took 860 msec; (sum 1525529904)

Btw ... I assumed -fno-inline-small-functions with gcc just to make
it harder for it to merge the ifs in exception-less code. However that
does not matter, the whole thing only demonstrated that exceptions and
return value checking are comparable, both cost something and when
exceptions are thrown rarely (often more rarely than 1:10000) then
return value checking slows the application needlessly by costing
more.

Seems that exceptions win when throwing exception
objects instead of filling error buffer

Likely some dynamic memory management in std::runtime error kicked
the tables here. Note that in real code the performance of exception
objects does matter less since throwing thousands of exceptions per
second is unusual. I just wanted to demonstrate that the thing is far
more efficient than lot of people seem to think; it was no way meant
as example of realistic usage of exceptions.

If you want to improve performance of exception objects then you can
throw pointers to static exception objects or throw your own exception
objects that do not manage memory dynamically or derive such from std::exception by overriding what() instead of having string
constructor arguments.

 

[Öö Tiib]

It was result of undefined behavior

Can you be more specific what undefined behavior you are talking
about?

 

[Melzzzzz]

Can you be more specific what undefined behavior you are talking about?

I forgot to initialize variable 'ret' (it was initialized
in your code but I have experimenting with objects and when returning
to plain int, forgot to set ret to 0 ).