To go with Go or C/C++?

[Tinxx]

Don't worry, this is not about some religious language war. I'm just looking for some advice from some C/C++ people who can judge better than me since my experience in C/C++ is very limited. I have been developing 10 years with Smalltalk and 10 years with Java. I did some C++ during my studies for my thesis, that's all.

Now I regret never having done any systems programming and I would like to dig a bit into it in my spare time. So I have to pick a language and I was looking at C/C++, D, and Go. I have never seen any job ad asking for a Java developper with some knowledge of C/C++ appreciated. To learn C/C++ well I need 3-4 years full time work with it. So even if I do some C/C++ programming in my sparetime I guess it will never make up for anything that counts job wise. Even when I have 20+ years to go till I retire. So my conclusion is that "systems programming" would be something for my spare time that should be done for the fun of it and not with a job goal, because that is unrealistic. My question is whether that opinion is too pessimistic or not. What I came up with so far is that choosing Go for some fun and leisure development work would make sense. D is surely much more complete than Go, but the Go community is really alive and kicking. I'm asking this question here, because I think I know what the people in the Go forum would answer ;-).

Regards, Tinxx

[Melzzzzz]

On Wed, 1 May 2013 07:05:35 -0700 (PDT)
Tinxx <jet...@web.de> wrote:

> I'm asking this question here, because I think I know what the people
> in the Go forum would answer ;-).
>

Go go go...

[Victor Bazarov]

On 5/1/2013 10:05 AM, Tinxx wrote:
> Don't worry, this is not about some religious language war. I'm just
looking for some advice from some C/C++ people who can judge better than
me since my experience in C/C++ is very limited. I have been developing
10 years with Smalltalk and 10 years with Java. I did some C++ during my
studies for my thesis, that's all.

There is no such language as "C/C++". I'll presume you mean C++.

> Now I regret never having done any systems programming and I would
like to dig a bit into it in my spare time. So I have to pick a language
and I was looking at C/C++, D, and Go. I have never seen any job ad
asking for a Java developper with some knowledge of C/C++ appreciated.
To learn C/C++ well I need 3-4 years full time work with it.

It probably depends on what you're going to be using it for. Often the
exposure to language features can be quite limited if the projects do
not demand it.

> So even if
I do some C/C++ programming in my sparetime I guess it will never make
up for anything that counts job wise. Even when I have 20+ years to go
till I retire. So my conclusion is that "systems programming" would be
something for my spare time that should be done for the fun of it and
not with a job goal, because that is unrealistic. My question is whether
that opinion is too pessimistic or not. What I came up with so far is
that choosing Go for some fun and leisure development work would make
sense. D is surely much more complete than Go, but the Go community is
really alive and kicking. I'm asking this question here, because I think
I know what the people in the Go forum would answer ;-).

And you don't know what people in a C++ forum would answer?

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.

I can't tell you anything about Go. You would have to ask "some Go
people" as you'd put it.

V
--
I do not respond to top-posted replies, please don't ask

[Balog Pal]

On 5/1/2013 4:44 PM, Stefan Ram wrote:
...
> you must choose C!
...

I thought we have May 1 not April 1.

[Balog Pal]

On 5/1/2013 4:05 PM, Tinxx wrote:
> Don't worry, this is not about some religious language war.
>I'm just looking for some advice from some C/C++ people who can judge better than
>me since my experience in C/C++ is very limited. I have been developing 10 years with
>Smalltalk and 10 years with Java. I did some C++ during my studies for
my thesis, that's all.
>
> Now I regret never having done any systems programming and I would like to dig a bit into it in my spare time.

Hm, systems programming and spare time is not the best mix.

> So I have to pick a language and I was looking at C/C++, D, and Go.

Is there any systems programming dome in D or Go actually? Or could be
done in theory at least?

> I have never seen any job ad asking for a Java developper with some knowledge of C/C++ appreciated.

I saw many, but that's hardly relevant.

If you really look to widen yor horizon as a programmer, I'd suggest
first to study SICP http://mitpress.mit.edu/sicp/ then some more
languages that play in different category than all you mentioned.

And after that extend to things you do actual work with.

As of C++, it is a huge investment. I'd only suggest it to those who can
commit bigtime and then use it in practice too.

An C I'd put as avoid unless you're forced and could not figure an
escape route.

[Paavo Helde]

Tinxx <jet...@web.de> wrote in
news:236d3436-89a5-411b...@googlegroups.com:

> Don't worry, this is not about some religious language war. I'm just
> looking for some advice from some C/C++ people who can judge better
> than me since my experience in C/C++ is very limited. I have been
> developing 10 years with Smalltalk and 10 years with Java. I did some
> C++ during my studies for my thesis, that's all.

First note that C and C++ are very different languages, without not much in
common except of a limited subset of common syntax. Both can be used for
"system programming", whatever you mean by it, but the actual code would be
drastically different.

> So my conclusion is that "systems
> programming" would be something for my spare time that should be done
> for the fun of it and not with a job goal

Good point. I would reverse it and say that one should always try to pick a
job which could be done for the fun of it, at least to some extent.

(As I don't have any experience with Go I cannot answer you actual
question.)

Cheers
Paavo

[Melzzzzz]

On 1 May 2013 14:44:05 GMT
r...@zedat.fu-berlin.de (Stefan Ram) wrote:

> Tinxx <jet...@web.de> writes:
> >Now I regret never having done any systems programming and I
> >would like to dig a bit into it in my spare time. So I have
> >to pick a language and I was looking at C/C++, D, and Go.
>

> C is much easier to learn then C++. D and Go I don't know.
> Therefore,
>
> you must choose C!

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

[Melzzzzz]

;))))

[Scott Lurndal]

Paavo Helde <myfir...@osa.pri.ee> writes:
>Tinxx <jet...@web.de> wrote in
>news:236d3436-89a5-411b...@googlegroups.com:
>
>> Don't worry, this is not about some religious language war. I'm just
>> looking for some advice from some C/C++ people who can judge better
>> than me since my experience in C/C++ is very limited. I have been
>> developing 10 years with Smalltalk and 10 years with Java. I did some
>> C++ during my studies for my thesis, that's all.
>
>First note that C and C++ are very different languages, without not much in
>common except of a limited subset of common syntax. Both can be used for
>"system programming", whatever you mean by it, but the actual code would be
>drastically different.

I wouldn't say drastically. Valid, Useful C++ code can be very similar
to C code, with the primary difference being the visibility of data
members in 'class' aggregates vs. 'struct' aggregates. One doesn't need
to use any of the std:: crap in perfectly usable C++ "systems programming",
or lambdas, or templates.

scott

[Paavo Helde]

sc...@slp53.sl.home (Scott Lurndal) wrote in
news:EAbgt.138685$ep4....@fed01.iad:

> Paavo Helde <myfir...@osa.pri.ee> writes:
>>First note that C and C++ are very different languages, without not
>>much in common except of a limited subset of common syntax. Both can
>>be used for "system programming", whatever you mean by it, but the
>>actual code would be drastically different.
>
> I wouldn't say drastically. Valid, Useful C++ code can be very
> similar to C code,

Sure, C is almost a proper subset of C++, and for sure C code can be both
valid and useful. However, this does not make it the best C++ code.

> with the primary difference being the visibility of
> data members in 'class' aggregates vs. 'struct' aggregates. One
> doesn't need to use any of the std:: crap in perfectly usable C++
> "systems programming", or lambdas, or templates.

I was more thinking about differences in resource cleanup and error
handling. In C code these tasks often take most of the lines and distract
the attention from the actual functionality.

String and array processing would most probably be different as well.

Cheers
Paavo

[Rui Maciel]

Tinxx wrote:

> I'm asking this question here, because I think I know what the people in
> the Go forum would answer ;-).

I believe the better option is either C or C++. Both have their downsides,
but they do have an upside which none of the other languages you've
mentioned has: they are standardised. Both C and C++ have been set in stone
though international standards. This means that it is guaranteed that all
you will learn right now will still be applicable decades from now. There
is absolutely no assurance that bit rot won't catch up with the other
alternatives you are considering, and if we look at the history of
unstandardised languages, it will.


Rui Maciel

[Rui Maciel]

Melzzzzz wrote:

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

Nonsense.

Queue in the "no true scotsman".


Rui Maciel

[Melzzzzz]

On Wed, 01 May 2013 18:11 +0100
Rui Maciel <rui.m...@gmail.com> wrote:

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

Oh yeah...
You don;t need to know C in order to program in C++, as well...

>
> Queue in the "no true scotsman".

So you can do system programming without understanding/knowing hardware
you program?

[Victor Bazarov]

Hello! It's *system* programming, silly. All you need to understand or
know is the *system*. Hardware-shmardware!... :-)

[Gerald Breuer]

Learn C first because you need a magnitude of time less to learn.
Then learn C++ and forget some idioms of C-programming.

[Melzzzzz]

System programming (or systems programming) is the activity of computer
programming system software. The primary distinguishing characteristic
of systems programming when compared to application programming is that
application programming aims to produce software which provides
services to the user (e.g. word processor), whereas systems programming
aims to produce software which provides services to the computer
hardware (e.g. disk defragmenter). It requires a greater degree of
hardware awareness.
"

http://en.wikipedia.org/wiki/System_programming

Well, yes, I agree that one need to know system. Depending on task and
system, hardware knowledge is required (or not).

[Victor Bazarov]

On 5/1/2013 2:44 PM, Gerald Breuer wrote:
> Learn C first because you need a magnitude of time less to learn.
> Then learn C++ and forget some idioms of C-programming.

Nonsense. "Learn to crawl because it's quicker, then learn to fly while
simultaneously unlearning to crawl." Learning C is a waste of time if
your goal is to learn C++. Even if it takes only a month to learn C
before going over to C++, it's one month too many, especially
considering that certain concepts and idioms *need* to be expunged from
memory. Do it correctly to begin with - start with C++.

[Tinxx]

"Picking up enough C++ to start doing good (or harm) in any field does
not really require years of full-time exposure."

Well, that is good news. This is somewhat why I was asking this in the C++ forum.

@Stefan Ram: Great post! Enjoyed a lot reading it. "C is more widespread than C++ ...". This is true according to Tiobe. Makes sense first to learn C. Before you can understand why square root of -1 is a problem you need to understand what a square root is ... Also using C++ as a pimped C or modern C becomes an option this way.

"So you can do system programming without understanding/knowing hardware
you program?"

Well, this makes me realize that I would have to revector as to what to do with C or C++. As I don't have the required hardware knowledge I would change to do some kind of application-independent performance critical development such as socket programming (raw sockets or zeromq.org), number crunching, image processing, something like that).

"Learn C first because you need a magnitude of time less to learn.

Then learn C++ ..."

Think this makes sense as already said earlier. Once saw some C++ code which was full with "extern C" statements. Doing plain C++ without any C is not a reality.

Thanks for all the comments.
Cheers, Tinxx

[Gerald Breuer]

Am 01.05.2013 21:37, schrieb Victor Bazarov:

> Nonsense. "Learn to crawl because it's quicker, then learn
> to fly while simultaneously unlearning to crawl."

If there would be a large intersection of crawling and flying
this suggestion might be right.

> Even if it takes only a month to learn C before going over
> to C++, it's one month too many, especially considering
> that certain concepts and idioms *need* to be expunged
> from memory.

These concepts can be expunged almost immediately if you
arent going to develop larger idiomatic C-projects in between.

C++ is a complicated language and learning C++ right from the
start might be too difficult and the learning curve may be too
steep for the novice. So it's educational meaningful to learn
the basic concepts of C which also apply C++ also first.

[Balog Pal]

On 5/1/2013 10:57 PM, Gerald Breuer wrote:
> Am 01.05.2013 21:37, schrieb Victor Bazarov:
>
>> Nonsense. "Learn to crawl because it's quicker, then learn
>> to fly while simultaneously unlearning to crawl."
>
> If there would be a large intersection of crawling and flying
> this suggestion might be right.

They both are involved with movement -- and even may be connected by
history. :-o About the same as how C and C++ programming is connected.

>> Even if it takes only a month to learn C before going over
>> to C++, it's one month too many, especially considering
>> that certain concepts and idioms *need* to be expunged
>> from memory.
>
> These concepts can be expunged almost immediately if you
> arent going to develop larger idiomatic C-projects in between.

My experience shows that established C programmers fare pretty badly
with C++ in general and good C++ even more. Rather they fall back to
(likely bad in the first place) habits and write C code in C++, that
falls back on everyone's head. While fresh starters have no such problems.

> C++ is a complicated language and learning C++ right from the
> start might be too difficult and the learning curve may be too
> steep for the novice.

Sure it is, so the way to do it is using a proper learning book or
course that adds elements in proper pace and order. But all C++
elements. Creating a foundation in C++ then build on it more and more.

There is absolutely no necessity to use C as foundation. And we have a
ton of observations that it is a particularly bad and/or dangerous one.
If it weren't going backwards it would still be a waste of time going on
an oblique vector instead right on target.

> So it's educational meaningful to learn
> the basic concepts of C which also apply C++ also first.

Not really -- the basic concepts of C, like "arrays" are there for sake
of compatibility, and carried as undroppable ballast, but can and are
avoided in usage. So they may be skipped for a long time on the the
proper route. Similar applies to usage of the C library.

[Ian Collins]

Tinxx wrote:
>
> "Learn C first because you need a magnitude of time less to learn.
> Then learn C++ ..."
>
> Think this makes sense as already said earlier. Once saw some C++
> code which was full with "extern C" statements. Doing plain C++
> without any C is not a reality.

Yes it is. You only need to declare something extern "C" if you want to
expose it to C code. My day job is systems programming and I do most of
it in C++. If your system has a C++ compiler, why restrict yourself to C?

Get a copy of "Accelerated C++: Practical Programming by Example", it's
probably still the best learn C++ from the ground up book.

--
Ian Collins

[William Ahern]

For the sanity of C programmers?

Some enterprising C++ developer at Apple decided to rewrite the linker and
allocator in C++, which had the effect of compounding their otherwise poor
design choices.

Now before main() is even called the linker and runtime initializer has done
an ungodly amount of useless bookkeeping. It's slowed down process startup,
and has made it a nightmare to debug your applications because everything
looks like a memory leak or invalid reference to debuggers.

That's not C++'s fault per se, but it sure has heck didn't help. C++ doesn't
offer many useful features in that particular domain, but it still brings
along all the baggage. It was probably used because that's what the
developer was comfortable with, even though it was likely the wrong tool.

[Tinxx]

I think I start with learning C and play around with C calling Lua and vice versa. Maybe some DI framework for C where the configuration definition language is Lua. Might have been done a zillion times before, but it's for fun and learning and you first have to be able to walk before you want to fly. Knowing plain C is always useful, because C++ is sometimes an overkill or not the appropriate choice. Then I do some socket programming with zeromq.org first with C and later with C++. This way I can slowly fight my way up at the pace I have time in my spare time.

Thanks for all replies,
Tinxx

[Bo Persson]

Gerald Breuer skrev 2013-05-01 20:44:
> Learn C first because you need a magnitude of time less to learn.
> Then learn C++ and forget some idioms of C-programming.

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?


Bo Persson

[Bo Persson]

Tinxx skrev 2013-05-02 13:30:
> I think I start with learning C and play around with C calling Lua and vice versa. Maybe some DI framework for C where the configuration definition language is Lua. Might have been done a zillion times before, but it's for fun and learning and you first have to be able to walk before you want to fly. Knowing plain C is always useful, because C++ is sometimes an overkill or not the appropriate choice. Then I do some socket programming with zeromq.org first with C and later with C++. This way I can slowly fight my way up at the pace I have time in my spare time.
>

Right, if you want to learn both C and C++ (and Lua), just do that.

We are just saying that learning one doesn't help much in learning the
next one, because you will also have to unlearn what you just learned.
So the order is of less importance.


Bo Persson

[Scott Lurndal]

Bo Persson <b...@gmb.dk> writes:
>Gerald Breuer skrev 2013-05-01 20:44:
>> Learn C first because you need a magnitude of time less to learn.
>> Then learn C++ and forget some idioms of C-programming.
>
>The problem is that you have to forget A LOT of C, like

Why? It all still works in C++. That's a benefit.

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

And here you are joking, right? Or do you truely think that bit shifting
and C++ don't mix?

>

scott

[Rui Maciel]

Bo Persson wrote:

> We are just saying that learning one doesn't help much in learning the
> next one, because you will also have to unlearn what you just learned.

Nonsense.


Rui Maciel

[Rui Maciel]

Bo Persson wrote:

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

Nonsense.


Rui Maciel

[Bo Persson]

Stefan Ram skrev 2013-05-02 18:49:

> C is the most popular language according to Tiobe.
> Twice as popular as C++, which is declining in popularity.
> How is learning the most popular and most influential
> language a loss of time?
>

Popularity according to Tiobe is the language producing most noise on
the Internet. Arguably it is the one that is hardest to use that
produces the most questions.

If you WANT to learn "the most popular language", just do that. If it is
just a prerequisite for learning the other language, it is a waste of
your time.


If I want to learn to ride a bicycle, I wouldn't start with a unicycle
just because it looks easier.



Bo Persson

[Bo Persson]

Scott Lurndal skrev 2013-05-02 19:06:
> Bo Persson <b...@gmb.dk> writes:
>> Gerald Breuer skrev 2013-05-01 20:44:
>>> Learn C first because you need a magnitude of time less to learn.
>>> Then learn C++ and forget some idioms of C-programming.
>>
>> The problem is that you have to forget A LOT of C, like
>
> Why? It all still works in C++. That's a benefit.

No, it's a big disadvantage because C++ has better tools for this. Why
not learn them first?

Try

std::string s = t;

over

char * s = malloc(strlen(t) + 1);
strcpy(s, t);

// and much later:

free(s);

and guess which is easier to learn (without missing the meaning of the
+1, or forgetting the free).

>
>>
>> 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
>
> And here you are joking, right? Or do you truely think that bit shifting
> and C++ don't mix?
>

No, but I believe a new student shouldn't START there. You can learn
that later, if and when you need it.


Bo Persson

[James Kanze]

On Wednesday, 1 May 2013 15:44:05 UTC+1, Stefan Ram wrote:
> Tinxx <jet...@web.de> writes:

> >Now I regret never having done any systems programming and I
> >would like to dig a bit into it in my spare time. So I have
> >to pick a language and I was looking at C/C++, D, and Go.

> C is much easier to learn then C++.

I would argue about that. Learning all of the formal aspects of
the language, yes. But knowing all of the formal aspects of the
language doesn't mean that you know how to write robust,
maintainable programs in it. And it's a lot easier to write
robust, maintainable programs in C++ than in C.

--
James

[James Kanze]

Learning C right is more difficult than learning C++ right.
Writing efficient, robust, maintainable applications in C is
very, very difficult.

--
James

[James Kanze]

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

--
James

[James Kanze]

On Wednesday, 1 May 2013 21:02:28 UTC+1, Tinxx wrote:
> "Picking up enough C++ to start doing good (or harm) in any field does

> "Learn C first because you need a magnitude of time less to learn.
> Then learn C++ ..."

> Think this makes sense as already said earlier.

Except that it's totally false. It takes more time to learn to
write working programs in C than in C++.

> Once saw some C++ code which was full with "extern C"
> statements. Doing plain C++ without any C is not a reality.

In the sense that the OS you're running on might have some parts
written in C (although most modern OS's are mainly C++), yes.
In the sense that C++ uses curly braces (instead of BEGIN and
END), and C used them first, yes. Otherwise, no. I'm currently
working on 500KL application, and there are very few places
where we use extern "C", most of the people working on the
application never see them, and they're only there so that
applications which use a C API (like Excel or Python) can call
into us.

--
James

[Scott Lurndal]

James Kanze <james...@gmail.com> writes:
>On Wednesday, 1 May 2013 21:02:28 UTC+1, Tinxx wrote:
>> "Picking up enough C++ to start doing good (or harm) in any field does
>
>> "Learn C first because you need a magnitude of time less to learn.
>> Then learn C++ ..."
>
>> Think this makes sense as already said earlier.
>
>Except that it's totally false. It takes more time to learn to
>write working programs in C than in C++.
>
>> Once saw some C++ code which was full with "extern C"
>> statements. Doing plain C++ without any C is not a reality.
>
>In the sense that the OS you're running on might have some parts
>written in C (although most modern OS's are mainly C++)

C'est what? Linux is 100% C, NTOSKERNEL is 100% C. The UI for
Windows, and many applications are C++, but the kernel (i.e. the OS)
is all C.

scott

[Tobias Müller]

Bo Persson <b...@gmb.dk> wrote:
> char * s = malloc(strlen(t) + 1);

// Don't forget error handling:
if (s == NULL)
{
/* handle error */
}

> strcpy(s, t);

// But usually you just use:
char* s = strdup(t);
// it's not standard but easy to define yourself
// if not already present in libc

Tobi

[Ian Collins]

Stefan Ram wrote:

> James Kanze <james...@gmail.com> writes:
>> maintainable programs in it. And it's a lot easier to write
>> robust, maintainable programs in C++ than in C.
>

> I am not sure about this. For example, exceptions introduce
> so many hidden paths into a seemingly simple piece of code
> in C++.
>
> http://www.gotw.ca/gotw/020.htm
>
> In C, one can write
>
> if( f = fopen( "file", "r" )){ use( f ); close( f ); }
>
> , i.e., apply the well-established style of structured
> programming. Without exception, we do not need no RAII,
> we can assert that »close« will be executed iff the file
> was opened successfully.

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.

--
Ian Collins

[Paavo Helde]

r...@zedat.fu-berlin.de (Stefan Ram) wrote in news:structured-programming-
2013050...@ram.dialup.fu-berlin.de:

> Ian Collins <ian-...@hotmail.com> writes:
>>>if( f = fopen( "file", "r" )){ use( f ); close( f ); }

>>We can (and probably would) do the same in C++. A missing file isn't
>>necessarily an exceptional situation.
>

> The point is that »use« might throw,
> not that »fopen« might throw.

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

> »close« /is/ the clean-up code here.

Yes, and this cleanup code must be written explicitly in every place a
file is opened, and care must be taken that it gets executed in all code
branches, after each code modification. In C++, you write the cleanup
code once, in the destructor, and it gets executed automatically.

Sure one can write robust, correct and maybe even maintainable code in C.
It just takes a lot more effort and patience. A kind of patience I do not
have for example. Why should I do such tedious work and check and recheck
all these tiny details when the compiler can do the work for me? When
writing the code I want to concentrate on the main algorithm, not on
remembering to close the files and such.

Cheers
Paavo

[Paavo Helde]

r...@zedat.fu-berlin.de (Stefan Ram) wrote in news:C++-20130502194610
@ram.dialup.fu-berlin.de:

> James Kanze <james...@gmail.com> writes:
>>maintainable programs in it. And it's a lot easier to write
>>robust, maintainable programs in C++ than in C.
>

> I am not sure about this. For example, exceptions introduce
> so many hidden paths into a seemingly simple piece of code
> in C++.
>
> http://www.gotw.ca/gotw/020.htm
>
> In C, one can write
>

> if( f = fopen( "file", "r" )){ use( f ); close( f ); }
>

> , i.e., apply the well-established style of structured
> programming. Without exception, we do not need no RAII,

You have it backwards. RAII makes it feasible to have exceptions, as an
additional bonus.

[Tinxx]

"C'est what? Linux is 100% C, NTOSKERNEL is 100% C. The UI for
Windows, and many applications are C++, but the kernel (i.e. the OS)
is all C."

Yeah, it depends whether your C program needs to compile with a plain C compiler like Lua. Because Lua does so, it exists on almost any platform for which a C compiler exists. Otherwise, I could also use C++ as a modern C. Use C++ streams instead of sprintf, etc. Problem is that C has not even modules. I can do without classes (classes as in OOP). But even without modules (as in Modula-II) makes it really hard. You would do something like a struct and all functions that act on it are in the same file and receive the struct as the first parameter. This is actually what Go is doing. It is a modern C in many ways.

" In C, one can write
if( f = fopen( "file", "r" )){ use( f ); close( f ); }"

Yes, Go does the same thing: no exceptions and checking an error code. For the above sample this seems suitable. But no exceptions at all can get effortful (endless return cascades where the error is returned). But maybe for "low-level programming" this makes sense.

Go seems to me to be designed as a modern C. And I think they did things well in many ways. But no link libraries at all, no exceptions. That's a bit strange. And the tooling and industry support is really weak. Will stick to C or C++ and after 5 years or so have a look how Go has been doing. The investment in C or C++ won't be lost anyway.

Cheers, Tinxx

[Tony]

In article <ab93edb4-2c20-4781...@googlegroups.com>,
james...@gmail.com says...

> it's a lot easier to write
> robust, maintainable programs in C++ than in C.

But do you really think that is enough? That's the C++ brochure? Stepped in
what?

(rhetorically)

[Tony]

In article <C++-20130...@ram.dialup.fu-berlin.de>, r...@zedat.fu-berlin.de
says...

>
> James Kanze <james...@gmail.com> writes:
> >maintainable programs in it. And it's a lot easier to write
> >robust, maintainable programs in C++ than in C.
>

> I am not sure about this. For example, exceptions introduce
> so many hidden paths into a seemingly simple piece of code
> in C++.
>
> http://www.gotw.ca/gotw/020.htm
>

> In C, one can write
>
> if( f = fopen( "file", "r" )){ use( f ); close( f ); }
>

> , i.e., apply the well-established style of structured
> programming. Without exception, we do not need no RAII,

> we can assert that »close« will be executed iff the file
> was opened successfully.

That pattern is valid, but to be limited to only that one is, well, a
limitation. I.e., it is constraining. (Not to feed Kanze's "all the expressivity
of C++" spiel though!). The lure of a C++ approach in the above kind of code is
that you can implement an abstraction once and eliminate a potential error of
omission at every place where such code is required, thereby making the program
more robust. If you want the C code above to be robust in all the places you put
it, you have to have a code generator create it, because the programmer is apt
to screw it up, and you're not going to get any compiler help with that bug
either.

[Tony]

In article <aa0d4ee0-645c-45fd...@googlegroups.com>,
james...@gmail.com says...

C++ is like one of those rocket "motorcycles" used for land speed records at the
Bonneville salt flats: you better know what you are doing when piloting one of
those things, and you may end up crashing and burning anyway. Very perilous.

[Tony]

In article <a3cc5ed1-3ed3-47fb...@googlegroups.com>,
james...@gmail.com says...

Not even close: the cycles are examples of simple elegance whereas C++ is a mire
of complexity. Somehow, C++ is able to move, but you'd be hard-pressed to
identify which one of those round turning things is a wheel or if it has any
actual wheels at all! A circus act? A freak show? Are 10 clowns carrying
unicycles going to jump out of the old jalopy now? Ya never really know with
C++... it could happen!

;)

[Tony]

In article <klu739$g44$1...@dont-email.me>, rui.m...@gmail.com says...

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.

[Andy Champ]

But is C a unicycle, or a Laufmaschine - a bike with no pedals?

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;

Andy

[Andy Champ]

On 03/05/2013 05:43, Tony wrote:
> C++ is like one of those rocket "motorcycles" used for land speed records at the
> Bonneville salt flats: you better know what you are doing when piloting one of
> those things, and you may end up crashing and burning anyway. Very perilous.

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

[Shriramana Sharma]

On Wednesday, May 1, 2013 7:35:35 PM UTC+5:30, Tinxx wrote:
> D is surely much more complete than Go,

Thanks for prompting me to look into D. It looks very interesting. C++ is great, lots of great software is written in it, but it's also a great big cave with lots of surprises. Looks like D might be quite useful for my purposes. Thanks again.

Shriramana.

[James Kanze]

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

--
James

[James Kanze]

On Friday, 3 May 2013 10:05:40 UTC+1, Andy Champ wrote:

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

--
James

[Öö Tiib]

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.

[Scott Lurndal]

=?ISO-8859-1?Q?=D6=F6_Tiib?= <oot...@hot.ee> writes:
>On Friday, 3 May 2013 18:44:37 UTC+3, James Kanze wrote:
>> On Thursday, 2 May 2013 20:42:03 UTC+1, Ian Collins wrote:
>> > Stefan Ram wrote:
>> > > James Kanze <james...@gmail.com> writes:
>> > >> maintainable programs in it. And it's a lot easier to write
>> > >> robust, maintainable programs in C++ than in C.
>
>> > > I am not sure about this. For example, exceptions introduce
>> > > so many hidden paths into a seemingly simple piece of code
>> > > in C++.
>
>> > > http://www.gotw.ca/gotw/020.htm
>
>> > > In C, one can write
>

>> > > if( f =3D fopen( "file", "r" )){ use( f ); close( f ); }

>
>> > > , i.e., apply the well-established style of structured
>> > > programming. Without exception, we do not need no RAII,

>> > > we can assert that =BBclose=AB will be executed iff the file
>> > > was opened successfully.
>
>> > We can (and probably would) do the same in C++. A missing file isn't=
>=20
>> > necessarily an exceptional situation. Now if it were an exceptional=20
>> > situation and the open was part of a group of resource allocations, C=
>=20
>> > code would have to include had written clean up code and quite likely a=
>=20
>> > "goto error". In C++, we'd just throw and rely on the automatic clean=
>=20

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

>Also C is less efficient in the situation. When the case where=20

>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.=20

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

scott

[88888 Dihedral]

James Kanze於 2013年5月3日星期五UTC+8下午11時56分59秒寫道：

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.

[Rui Maciel]

Öö Tiib wrote:

> 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

[Rui Maciel]

Tony wrote:

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

On Friday, 3 May 2013 19:09:41 UTC+3, Scott Lurndal wrote:

> Öö Tiib <oot...@hot.ee> writes:
> >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.
>

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

On Friday, 3 May 2013 20:46:39 UTC+3, Öö Tiib wrote:
> On Friday, 3 May 2013 19:09:41 UTC+3, Scott Lurndal wrote:
>
> > Öö Tiib <oot...@hot.ee> writes:

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

Oh, I forgot to type the ms_elapsed here:

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

[Melzzzzz]

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

[Öö Tiib]

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.

[Scott Lurndal]

=?ISO-8859-1?Q?=D6=F6_Tiib?= <oot...@hot.ee> writes:
>On Friday, 3 May 2013 19:09:41 UTC+3, Scott Lurndal wrote:

>> =D6=F6 Tiib <oot...@hot.ee> writes:
>> >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.

>>=20
>> For this, you must offer more evidence than simple assertion,=20

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

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

This contrived benchmark illustrates nothing.

scott

[Bo Persson]

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

[Ian Collins]

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.

--
Ian Collins

[Ian Collins]

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

--
Ian Collins

[Bo Persson]

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

[Bo Persson]

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

[Melzzzzz]

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

[Anand Hariharan]

On May 3, 3:13 pm, Bo Persson <b...@gmb.dk> wrote:
> 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

[Ike Naar]

On 2013-05-03, Ian Collins <ian-...@hotmail.com> wrote:
> 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?

[Ian Collins]

Something like the code above and something that's in production code.

--
Ian Collins

[Jorgen Grahn]

On Fri, 2013-05-03, James Kanze wrote:
> On Friday, 3 May 2013 10:05:40 UTC+1, Andy Champ wrote:
>
>> 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.

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

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Jorgen Grahn]

On Thu, 2013-05-02, James Kanze wrote:
> On Thursday, 2 May 2013 18:23:37 UTC+1, Bo Persson wrote:
>> Stefan Ram skrev 2013-05-02 18:49:
>
>> If I want to learn to ride a bicycle, I wouldn't start with a unicycle
>> just because it looks easier.
>
> 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.

[Rui Maciel]

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]

On Friday, 3 May 2013 22:55:42 UTC+3, Scott Lurndal wrote:

> Öö Tiib <oot...@hot.ee> writes:
> >On Friday, 3 May 2013 19:09:41 UTC+3, Scott Lurndal wrote:

> >> Öö Tiib <oot...@hot.ee> writes:
> >> >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.

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

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

Ian Collins wrote:

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

On Saturday, 4 May 2013 13:34:41 UTC+3, Rui Maciel wrote:
> Öö Tiib wrote:
> > On Friday, 3 May 2013 20:32:27 UTC+3, Rui Maciel wrote:
> >> Öö Tiib wrote:
> >> > 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?

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

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.

[Balog Pal]

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]

Balog Pal wrote:

> On 5/3/2013 7:32 PM, Rui Maciel wrote:
>> Öö Tiib wrote:
>>
>>> 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?
>
> 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]

Öö Tiib wrote:

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

On 5/4/2013 10:26 PM, Rui Maciel wrote:
> Balog Pal wrote:
>
>> On 5/3/2013 7:32 PM, Rui Maciel wrote:
>>> Öö Tiib wrote:
>>>
>>>> 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?
>>
>> 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.

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]

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]

On May 1, 5:31 pm, Melzzzzz <m...@zzzzz.com> wrote:
> On 1 May 2013 14:44:05 GMT
> r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> > Tinxx <jeti...@web.de> writes:
>
> That's for sure. But to really understand C (or motivation behind it),
> one has to know at least one assembler.

Nonsense

[Nick Keighley]

[Paavo Helde]

sc...@slp53.sl.home (Scott Lurndal) wrote in news:2DUgt.205912$P%5.75976
@fed16.iad:

Who cares? Exceptions make the code cleaner and more maintainable so they
would be useful even if they were slower.

Cheers
Paavo

[Paavo Helde]

Rui Maciel <rui.m...@gmail.com> wrote in
news:km0s4t$m9b$1...@dont-email.me:

> C�C� Tiib wrote:
>
>> 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?

No, not at all. When an exception is actually thrown, it is much slower
than C-style error code returns (by a factor of thousands or so), so
failing with an error (this is not crashing, BTW) is much slower with C++-
style exception-handling than in C. This is the price to be paid for having
it faster in the non-exceptional path.

Cheers
Paavo

[Rui Maciel]

Öö Tiib wrote:

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

On Saturday, 4 May 2013 23:43:43 UTC+3, Rui Maciel wrote:
> Öö Tiib wrote:
> > 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?

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

[Andy Champ]

On 03/05/2013 16:56, James Kanze wrote:
> On Friday, 3 May 2013 10:05:40 UTC+1, Andy Champ wrote:
>
>> 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.)
>

It's only true for _certain kinds of I/O_.

As you point out, it's not at all OO.

Andy

[Martin Shobe]

Yes, we get it. On if and an exception is usually slower than just an
if. (Not really sure what that adds to the rest of the discussion though.)

Martin Shobe

[Tony]

In article <e1a49da6-f877-4845...@googlegroups.com>,
james...@gmail.com says...
>
> On Thursday, 2 May 2013 20:42:03 UTC+1, Ian Collins wrote:
> > Stefan Ram wrote:
> > > James Kanze <james...@gmail.com> writes:
> > >> maintainable programs in it. And it's a lot easier to write
> > >> robust, maintainable programs in C++ than in C.
>
> > > I am not sure about this. For example, exceptions introduce
> > > so many hidden paths into a seemingly simple piece of code
> > > in C++.
>
> > > http://www.gotw.ca/gotw/020.htm
>
> > > In C, one can write
>
> > > if( f = fopen( "file", "r" )){ use( f ); close( f ); }
>
> > > , i.e., apply the well-established style of structured
> > > programming. Without exception, we do not need no RAII,
> > > we can assert that »close« will be executed iff the file
> > > was opened successfully.
>
> > 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++.

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]

In article <9jRgt.122224$aK1....@fed02.iad>, sc...@slp53.sl.home says...
>
> =?ISO-8859-1?Q?=D6=F6_Tiib?= <oot...@hot.ee> writes:

> >On Friday, 3 May 2013 18:44:37 UTC+3, James Kanze wrote:
> >> On Thursday, 2 May 2013 20:42:03 UTC+1, Ian Collins wrote:
> >> > Stefan Ram wrote:
> >> > > James Kanze <james...@gmail.com> writes:
> >> > >> maintainable programs in it. And it's a lot easier to write
> >> > >> robust, maintainable programs in C++ than in C.
> >
> >> > > I am not sure about this. For example, exceptions introduce
> >> > > so many hidden paths into a seemingly simple piece of code
> >> > > in C++.
> >
> >> > > http://www.gotw.ca/gotw/020.htm
> >
> >> > > In C, one can write
> >

> >> > > if( f =3D fopen( "file", "r" )){ use( f ); close( f ); }

> >
> >> > > , i.e., apply the well-established style of structured
> >> > > programming. Without exception, we do not need no RAII,

> >> > > we can assert that =BBclose=AB will be executed iff the file
> >> > > was opened successfully.
> >
> >> > We can (and probably would) do the same in C++. A missing file isn't=
> >=20
> >> > necessarily an exceptional situation. Now if it were an exceptional=20
> >> > situation and the open was part of a group of resource allocations, C=
> >=20
> >> > code would have to include had written clean up code and quite likely a=
> >=20
> >> > "goto error". In C++, we'd just throw and rely on the automatic clean=
> >=20

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

> >Also C is less efficient in the situation. When the case where=20

> >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.=20
>
> 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]

In article <8cd19dc1-0e4d-4b54...@googlegroups.com>,
oot...@hot.ee says...

>
> On Friday, 3 May 2013 19:09:41 UTC+3, Scott Lurndal wrote:

> > Öö Tiib <oot...@hot.ee> writes:
> > >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.
> >

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

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]

In article <d079085d-e31e-45f6...@oj8g2000pbb.googlegroups.com>,
mailto.anan...@gmail.com says...
>
> On May 3, 3:13 pm, Bo Persson <b...@gmb.dk> wrote:
> > 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:
>

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 fuck you gonna do about it? Hmm?


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

[Tony]

In article <km3rnh$ofh$1...@dont-email.me>, rui.m...@gmail.com says...

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

Martin Shobe wrote:

> 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