Exception Misconceptions: Exceptions are for unrecoverable errors.

[tanix]

(e-mail address removed)-berlin.de (Stefan Ram) wrote:
[...]

More elegantly? Actually, for correct and secure C++ code,
all functions need to be written to be =BBexception safe=AB,

Correct.
Almost everything you do will generate some kind of exception,
at least in modern languages, and it is good it does.

In order to write exception safe code, at least with value
semantics (and I suspect even without value semantics, but I've
not analysed the question in detail), it's been proven that you
need a certain number of primitives which are guaranteed not to
throw---one of the most classical C++ idioms, for example, only
works if you have a version of swap that doesn't throw.

Cool. I like that. You ARE pretty inventive I'd say.
:--}

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

 

[Vladimir Jovic]

Stefan Ram wrote:
[snip]
More elegantly? Actually, for correct and secure C++
code, all functions need to be written to be »exception
safe«, but only a minority of C++ programmers does so or
even is aware of it.
Why?

The above is false. Exception-safe code is needed to write
code that avoids resource leaks in the face of an exception.

It's need to write code that is correct in the face of an
exception. What "correct" means depends on the application
specifications. (On the other hand, what he wrote is false in
so far that if the function calls no other function, or only
calls functions guaranteed not to throw, it doesn't have to be
exception safe.)

Ok, I forgot about that. Thank you.

But how many people are adding what exception can a method throw in it's
declaration? (forgot how it is called. Is it exception declaration?)
All normal coding styles are telling that is causing more trouble then
it helps.

For instance:

{
char *p = new char[256];
f();
}

If f throws an exception, this statement block is abandoned,
and the allocated memory is leaked.

Or not. If the application is using garbage collection, it's
not leaked. If the application immediately terminates (and is
in a hosted environment), it's not leaked.

Not many people are using GC

 

[Vladimir Jovic]

Or by calling exit. (Calling exit does not unwind the stack,
which means that destructors of local variables are not called.)

Is there a function to terminate a process, but to unwind the stack?

 

[tanix]

On 2009-12-22, Vladimir Jovic <[email protected]> wrote:

Stefan Ram wrote:
[snip]

More elegantly? Actually, for correct and secure C++
code, all functions need to be written to be »exception
safe«, but only a minority of C++ programmers does so or
even is aware of it.

The above is false. Exception-safe code is needed to write
code that avoids resource leaks in the face of an exception.

It's need to write code that is correct in the face of an
exception. What "correct" means depends on the application
specifications. (On the other hand, what he wrote is false in
so far that if the function calls no other function, or only
calls functions guaranteed not to throw, it doesn't have to be
exception safe.)

Ok, I forgot about that. Thank you.

But how many people are adding what exception can a method throw in it's
declaration? (forgot how it is called. Is it exception declaration?)
All normal coding styles are telling that is causing more trouble then
it helps.

For instance:

{
char *p = new char[256];
f();
}

If f throws an exception, this statement block is abandoned,
and the allocated memory is leaked.

Or not. If the application is using garbage collection, it's
not leaked. If the application immediately terminates (and is
in a hosted environment), it's not leaked.

Not many people are using GC

I recall seeing some articles on gc issue in C++ a while back
on this very group. Do not remember what it was.

But what can I say out of my own experience with Java is this:
A well written GC is such a help, that I can not even see the
argument of not implementing it to this day.

I bet you can not even imagine how much times was wasted to date
by the programmers to deal with this totally stoopid issues
related to memory deallocation. Probably at least 30% of total
time spend on developing the C++ code.

C++ would probably be benefited tremendously if it adopted some
of the central Java concept, such as GC, threads and GUI.

Except that would require an equivalent of a virtual machine
underneath.

And that is one of central issues with Java.
I even had a long argument AGAINST JVM a while back
on the basis of program fat. JVM takes at least 10-20 megs
of memory to even run a program. But, by todays standards,
it is not even worth mentioning since almost any modern
program takes hundreds of megs of memory to run, and the
JVM load time is negligeable compared to run time of any
more or less complex application.

So, there you have it...

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

 

[tanix]

Is there a function to terminate a process, but to unwind the stack?

Yes. It is called clean exit.
:--}

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

 

[James Kanze]

Stefan Ram wrote:
[snip]
More elegantly? Actually, for correct and secure C++
code, all functions need to be written to be »exception
safe«, but only a minority of C++ programmers does so or
even is aware of it.
Why?
The above is false. Exception-safe code is needed to write
code that avoids resource leaks in the face of an exception.
It's need to write code that is correct in the face of an
exception. What "correct" means depends on the application
specifications. (On the other hand, what he wrote is false
in so far that if the function calls no other function, or
only calls functions guaranteed not to throw, it doesn't
have to be exception safe.)

Ok, I forgot about that. Thank you.
But how many people are adding what exception can a method
throw in it's declaration? (forgot how it is called. Is it
exception declaration?) All normal coding styles are telling
that is causing more trouble then it helps.

First, many people do use "throw()" when a function cannot
throw. But that's beside the point: when you're writing code,
you do have to know whether the function can throw or not;
whether this information is provided by a language construct or
the documentation is really irrelevant.

For instance:
{
char *p = new char[256];
f();
}
If f throws an exception, this statement block is
abandoned, and the allocated memory is leaked.
Or not. If the application is using garbage collection,
it's not leaked. If the application immediately terminates
(and is in a hosted environment), it's not leaked.

Not many people are using GC

I recall seeing some articles on gc issue in C++ a while back
on this very group. Do not remember what it was.

But what can I say out of my own experience with Java is this:
A well written GC is such a help, that I can not even see the
argument of not implementing it to this day.

I agree, but you can't loose sight of the fact that Java and C++
are two different languages. Garbage collection is nice in C++:
it definitely makes it easier to write correct code in a lot of
cases, and it is essential for safety (no dangling pointers) in
others. But it isn't nearly as essential in C++ as in Java,
because C++ supports value semantics. Which mean that you don't
use nearly as many dynamically allocated objects, and most of
the ones you do use have deterministic lifetimes anyway. (Of
course, the safety issue still stands.)

I bet you can not even imagine how much times was wasted to
date by the programmers to deal with this totally stoopid
issues related to memory deallocation. Probably at least 30%
of total time spend on developing the C++ code.

Generally less than 10% of the time. But given the cost of
competent engineers, even 10% is worth it.

C++ would probably be benefited tremendously if it adopted
some of the central Java concept, such as GC, threads and GUI.

Except that would require an equivalent of a virtual machine
underneath.

Not at all. I've used garbage collection in C++, and I've used
C++ in multithreaded programs. And a lot of people have written
GUI's in C++. All without a virtual machine.

All would be nice additions, IMHO, although for various
reasons, I don't think a standard GUI would be possible today.

 

[James Kanze]

James Kanze wrote:

Is there a function to terminate a process, but to unwind the
stack?

No, but it's easy to implement. Just wrap all of the code in
main in a try block, e.g.:

int
main( int argc, char** argv )
{
try {
// all of the code...
return EXIT_SUCCESS;
} catch ( int returnCode ) {
return returnCode;
}
}

That's what I usually do, anyway.

 

[Vladimir Jovic]

Yes. It is called clean exit.
:--}

Nope. That doesn't unwind the stack. Test is here:


#include <iostream>
#include <cstdlib>
struct A
{
A(){std::cout<<"A()"<<std::endl;}
~A(){std::cout<<"~A()"<<std::endl;}
};
int main()
{
A a;
exit(0);
}

 

[tanix]

James Kanze wrote:
Stefan Ram wrote:
[snip]
More elegantly? Actually, for correct and secure C++
code, all functions need to be written to be =BBexception
safe=AB, but only a minority of C++ programmers does so or
even is aware of it.
Why?
The above is false. Exception-safe code is needed to write
code that avoids resource leaks in the face of an exception.
It's need to write code that is correct in the face of an
exception. What "correct" means depends on the application
specifications. (On the other hand, what he wrote is false
in so far that if the function calls no other function, or
only calls functions guaranteed not to throw, it doesn't
have to be exception safe.)
Ok, I forgot about that. Thank you.
But how many people are adding what exception can a method
throw in it's declaration? (forgot how it is called. Is it
exception declaration?) All normal coding styles are telling
that is causing more trouble then it helps.

First, many people do use "throw()" when a function cannot
throw. But that's beside the point: when you're writing code,
you do have to know whether the function can throw or not;
whether this information is provided by a language construct or
the documentation is really irrelevant.

Well, I use throw() as a matter of practice.
In YOUR language, it becomes a part of "program logic".
In MY language, it becomes a part of your defense system
against ANY kinds of most unpleasant errors.

Even if I open a file that does not throw, and I detect
an error opening it, I may throw() myself. Because I know
the higher levels have a catch that catches ANY kind of funk,
and it KNOWS what is the logical meaining of ANY ot those
throws in bulk is.

On lower level, I may not even be able to formulate a logical
error. Because I do not even know who the hell is doing what
while they are calling me to deal with this file.
So, what is the point of me reporting: "error: could not open file"?

Not much. Because you could not open it doing what?
You might be opening tens of files, and some of them may
be functionalli similar. But what is the CONTEXT?

You see?

So, this IS the case where your throws and exception mechanism
becomes a direct part of your program logic, and I mean HIGHER
level logic than simply ifs and buts of some routine.

For instance:
{
char *p =3D new char[256];
f();
}
If f throws an exception, this statement block is
abandoned, and the allocated memory is leaked.
Or not. If the application is using garbage collection,
it's not leaked. If the application immediately terminates
(and is in a hosted environment), it's not leaked.
Not many people are using GC

I recall seeing some articles on gc issue in C++ a while back
on this very group. Do not remember what it was.

But what can I say out of my own experience with Java is this:
A well written GC is such a help, that I can not even see the
argument of not implementing it to this day.

I agree,

Cool. So GET TO WORK, you high tower priests!
:--}

but you can't loose sight of the fact that Java and C++
are two different languages.

So what?

Garbage collection is nice in C++:
it definitely makes it easier to write correct code in a lot of
cases, and it is essential for safety (no dangling pointers) in
others.

Cool, so wire it into language on a level of a spec
and STANDARD functionality.

But it isn't nearly as essential in C++ as in Java,
Wut?

because C++ supports value semantics. Which mean that you don't
use nearly as many dynamically allocated objects, and most of
the ones you do use have deterministic lifetimes anyway. (Of
course, the safety issue still stands.)

Well, to tell you the truth, I do like java in this respect
better.

There is no such things as -> in java.

Everything is bla.bla.blah.

So, if you need to extend your code, you don't have to worrry
about replacing the -> notation to . notation in some instances,
which may take hours for you if you change your objects and
create some super objects than include those, etc.

Secondly, I don't have to worry about "value semantics".
I could care less if it exists. I don't have to add THIS
level of ganularity, which only creates more complications
at the end.

Just look at some "improvements" in C++, like references?
What the funk are those?
Nobody can even agree on how some compilers interpret it.
You can not assume ANY semantics if you use references.

I did not watch the C++ development for years now.
But I just have an intuitive feeling that what you guys
are doing is everything you can to kill the language.

The amount of complexities you introduce and the amount
of visible, tangible benefits they produce as a bottom
line is just WAY too lil bang for a buck.

Jeeez. I bet they are going to jump at me in bulk now!
:--}

I think language is moving in a totally dead end direction.

Again, look at the experience of Java.
Do you think, in your clear mind that it was just a waste?
That the whole Java thing is nothing more than a bad joke?

I'd think REALLY hard before answering this question.

And what do YOU guys do?

Well, just IGNORE it all, like it is some "terrorist" camp,
like some "evil" Saddam.

Instead of learning from it and appreciating that grand
piece of work called Java.

What do you learn from Php or Python, or even stinky
Javascript, as screwed up as it it?

ANYTHING?

Well, you, hight tower priests, could care less those
languages exist, because to you, "purists", those are
not really languages. Those are just toys for infantiles.

Meanwhile, more and more of the most significant development
is being implemented every single day using the Php, Python,
Ruby, Javascript, SQL or even that HTML, NONE of which has
the kind of portability problems C++ has.

Do you see ANYTHING?

Or you are blind, sitting in that fortress of yours,
in that high tower of yours, hoarding the "secrets"
of the "craft"?

I just bet you, the significance of C++ is going to be diminished
to the point, where it will become an atrophied organ in the
body of modern world, and information processing specifically.

And information processing is probably the most critical
aspects of the entire mankind's development and survival.

Because things need to happen URGENTLY now and at a rate
never seen before in the entire history of mankind.
By the time those monsters, aka politicians, keep hoarding
some of their "private interests" and making some deal
as far as environmental situations goes, that are simply
insane, we need the information machine to work as smoothly
and as efficiently as we can manage.

And that is YOUR OBLIGATION. It is not longer a luxury,
or some game you play when you have nothing better to do.

So, the VAST majority of programming nowadays better be
directed towards information processing.

TOTAL portability is a MUST from now on.
I do not want to hear the type of arguments I keep hearing.
Not that it matters to me personally more than a dead
mosquito fart.

I want to see C++, if it EVER has a chance, to run
on ANY platform and I want to see a GUI wired into the
language. Sure, you don't have an equivalent of JVM,
so you can not rely on things it provides you.

Well, but WHO prevents you from having something of
that kind or even going as far as starting out with
using the existing JVM? After all, how was C++
initially implemented?

Ask Strousrup.
And I did, and he lied.
At Ruben Engineering, Cambridge, Mass. USA.

Because I asked him this:
"why did you implement C++ as a preprocessor to C?"

And he said:
Nope. It is NOT a preprocessor.
And it is a lie.
Because it was literally a fancy preporocessor.
Because after the 1st phase of "compilation",
it simply ran the C compiler.
Ask him.

And what about those "objects" and how the first versions
of C++ were linked?

Well, the stuff was PATCHED in your executable,
just to make C++ behavior out of standard C exectutables.

So...

Why don't you hack something up that can help to save
this dinasaur called C++?

Ok, enough for now.
Cya.

Generally less than 10% of the time. But given the cost of
competent engineers, even 10% is worth it.



Not at all. I've used garbage collection in C++, and I've used
C++ in multithreaded programs. And a lot of people have written
GUI's in C++. All without a virtual machine.

All would be nice additions, IMHO, although for various
reasons, I don't think a standard GUI would be possible today.

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

 

[Kaz Kylheku]

And there can be other issues besides leaking. In the end,
you've got to ensure internal consistency for all possible
control flows. When some of the possible control flows are the
result of an exception, then this requirement is called
exception safety.

Right; for instance failing to unlock a mutex, or roll
back a transaction, aren't resource leaks.

 

[Branimir Maksimovic]

Saying "Exceptions are for unrecoverable errors" seems to imply that they
are to be used only or mostly in such situations.

I use exception everywhere instead of error code return from function.
It is easier to program if you get rid of statements like
if(f()==error){ return error or handle error }

Also I have very few try's only in places for top level cleanup...
Exceptions are mechanism to make code cleaner...and to get rid of
error codes as return values from functions..

Greets

 

[Branimir Maksimovic]

Stefan Ram wrote:
[snip]

More elegantly? Actually, for correct and secure C++ code,
all functions need to be written to be »exception safe«, but
only a minority of C++ programmers does so or even is aware
of it.

Why?

The above is false. Exception-safe code is needed to write code
that avoids resource leaks in the face of an exception.

For instance:

{
char *p = new char[256];
f();
}

hm , why would you do this?

isnt't that
{
vector<char> p(256);
f();
}
is simpler?
You can always get &p[0] and use it like buffer and you get
size for free....

If f throws an exception, this statement block is abandoned, and the
allocated memory is leaked. Of course other kinds of resources can be
leaked, like handles to operating system resources such as open files.

I use vectors ....strings and such stuff.

Greets

 

[Kaz Kylheku]

Stefan Ram wrote:
[snip]
More elegantly? Actually, for correct and secure C++ code,
all functions need to be written to be »exception safe«, but
only a minority of C++ programmers does so or even is aware
of it.

Why?

The above is false. Exception-safe code is needed to write code
that avoids resource leaks in the face of an exception.

For instance:

{
char *p = new char[256];
f();
}

hm , why would you do this?

To demonstrate one way in which code fails to be exception safe.

isnt't that
{
vector<char> p(256);
f();
}
is simpler?

This code no longer demonstrates a resource leak in the face of an exception,
and so it would not have made a sutitable example to accompany my article.

Doh?

 

[Kaz Kylheku]

GC is heavy performance killer especially on multiprocessor systems

Is not.

in combination with threads....it is slow, complex and inefficient...

Religious belief.

It has sense in functional languages because of recursion, but
in java?!

Java has recursion. Moreover, there are functional languages built on the Java
platform.

Recursion is not directly connected to the need for garbage collection; this is
some kind of strange misconception.

GC without threads, but processes and shared memory instead, is ok on
multiprocessor systems...

GC is very efficient from an SMP point of view, because it allows
for immutable objects to be truly immutable, over most of their
lifetime. No book-keeping operations have to be performed on objects
that are just passed around throughout the program (such as bumping
refcounts up and down).

No storage reclamation strategy is free of overhead. Even if your program
correctly manages memory by itself with explicit new and delete, there is a
cost.

Moreover, a poorly implemented heap allocator (like virtually
every default malloc implementation out there in the real world)
is an SMP performance killer.

Like malloc and new, GC can be badly implemented in a way that kills SMP
performance. So can any aspect a programming language implementation, including
the compiler.

If you find a sufficiently bad compiler and library for some language, you can
``prove'' any statement about how bad that language is.

virtual machine is also heavy performance killer...

That may be so, but GC does not require a virtual machine. GC has been used for
five decades, with natively compiled code, starting in the late 1950's on IBM
704 mainframes, as part of the Lisp run-time support.

Yes.
I think java is designed in such way that it will still be slow in
comparison to other compiled languages...if it is compiled
language.

Unfortunately, that is wishful thinking. Natively compiled Java has very little
disadvantage compared to C and C++. (Mainly in areas of doing low-level things
with memory, or directly interfacing with the ``bare iron''; the sorts
of things that are poorly supported in Java).

Java has the same low-level numeric types, and the way it deals with objects is
not much different from pointers to classes in C++.

There is no reason to expect something like a matrix multiplication with
Java arrays to be slow, when Java is compiled to native code by an optimizing
compiler.

 

[Branimir Maksimovic]

Is not.

Hm, explain to me how can any thread, access or change any pointer in
memory without lock while gc is collecting....
There is no way for gc to collect without stopping all threads
without locking.... because gc is just another thread(s) in itself...

Religious belief.

Of course. GC is complex program that has only one purpose.
To let programmer not write free(p), but programmer
still has to write close(fd).
What's the purpose of that?

Recursion is not directly connected to the need for garbage collection; this is
some kind of strange misconception.


GC is very efficient from an SMP point of view, because it allows
for immutable objects to be truly immutable, over most of their
lifetime. No book-keeping operations have to be performed on objects
that are just passed around throughout the program (such as bumping
refcounts up and down).

Refcounts are negligible in comparison to what gc is doing.
GC cannot be efficient since it cannot access program
memory while program is working....ad it doesn;t know what program is
doing... therefore GC can perform well only if it collect
when absolutely necessary. And when it had to collect performance
became catastrophic...

No storage reclamation strategy is free of overhead. Even if your program
correctly manages memory by itself with explicit new and delete, there is a
cost.

Manual memory deallocation is simple, fast and efficient. Nothing
so complex like GC.
Cost of new and delete is nothing in comparison to GC.

Moreover, a poorly implemented heap allocator (like virtually
every default malloc implementation out there in the real world)
is an SMP performance killer.

Yeah right. And GC thread is black magic , right?

Like malloc and new, GC can be badly implemented in a way that kills SMP
performance. So can any aspect a programming language implementation, including
the compiler.

GC cannot be implemented efficiently since it has to mess with
memory...while other threads are working.
Add that compacting collector which have to update all references
in program and some copy/pasting... that can be optimised... to be
faster than new/delete , yeah right

That may be so, but GC does not require a virtual machine. GC has been used for
five decades, with natively compiled code, starting in the late 1950's on IBM
704 mainframes, as part of the Lisp run-time support.

I used GC with C++...

Unfortunately, that is wishful thinking. Natively compiled Java has very little
disadvantage compared to C and C++. (Mainly in areas of doing low-level things
with memory, or directly interfacing with the ``bare iron''; the sorts
of things that are poorly supported in Java).

I don;t want to discuss this, but it is obvious that nothing in java is
designed with performance in mind. Quite opposite....

Greets

 

[tanix]

No idea what you are talking about.

Is not.

Where are you pulling THIS stuff from?

Religious belief.

I'd say so.

No idea what does recursion has to do with it.

Java has recursion. Moreover, there are functional languages built on the Java
platform.

Recursion is not directly connected to the need for garbage collection; this is
some kind of strange misconception.

I would think recursion has 0 impact on GC from what I see.

GC is very efficient from an SMP point of view, because it allows
for immutable objects to be truly immutable, over most of their
lifetime. No book-keeping operations have to be performed on objects
that are just passed around throughout the program (such as bumping
refcounts up and down).

No storage reclamation strategy is free of overhead. Even if your program
correctly manages memory by itself with explicit new and delete, there is a
cost.

Moreover, a poorly implemented heap allocator (like virtually
every default malloc implementation out there in the real world)
is an SMP performance killer.

Like malloc and new, GC can be badly implemented in a way that kills SMP
performance. So can any aspect a programming language implementation, including
the compiler.

If you find a sufficiently bad compiler and library for some language, you can
``prove'' any statement about how bad that language is.

That may be so, but GC does not require a virtual machine. GC has been used for
five decades, with natively compiled code, starting in the late 1950's on IBM
704 mainframes, as part of the Lisp run-time support.

Unfortunately, that is wishful thinking. Natively compiled Java
has very little disadvantage compared to C and C++.
(Mainly in areas of doing low-level things
with memory, or directly interfacing with the ``bare iron''; the sorts
of things that are poorly supported in Java).
Correct.

Java has the same low-level numeric types, and the way it deals with
objects is not much different from pointers to classes in C++.

Indeed. And once you deal with objects, ALL the "advantages"
in performance of C++, or even C, are gone, and you are on the
same level, if not better, depending on what kind of algorithms
are implemented to handle things like collections, such as list,
tree, hash map, map, etc.

In real programs, you don't deal with bits and bytes and register
values. You deal with OBJECTS. Once you deal with objects and do
just about any operation on them of any significance, all your
"performance" gains are gone. Non existant.

There is no reason to expect something like a matrix multiplication with
Java arrays to be slow, when Java is compiled to native code by an optimizing
compiler.

Interesting point people seem to miss is that overall performance,
people seem to miss is that the overall advantage of having a JVM
is shielding you from all sorts of nasty problems when you
have to deal directly with O/S and provides you a portability
mechanism, so if you decide to wire in the GUI, threads, gc or
whatever, you don't have to worry about how it is going to run
on a different platform.

The cost of JVM in terms of memory footprint is negligible
by today's standards. Probably 10 - 15 % of your total memory
requirements for more or less complex apps that are useful
enough to even bother about.

Another point about performance is if your language has a rich
set and enough of expressive power so you do not incure that
much performance overhead. Overall impact on your performance
I'd estimate to be no more than 10-20%, probably in the worst case.

I'd be curious to see the benchmarks.

You incure performance overhead when you do lil things on a
very low level, poking into memory or what have you.

You'd have to substantiate your claims with some hard data,
and even there, it highly depends on what kind of things
your app does.

I my case, I have not noticed ANY issues with performance.
I am processing at least 1000 of articles per second, and
even that is not the limit because of my overly defensive
coding style for reading file. I bet I can double that
performance if I spend a couple of days, if not couple of
hours on it. It think at least 30 to 50% is quite realistic.

The way I check it, is to see how fast my app is processing
files by simply looking at the rate at which my drive light
flashes. In a perfect app, it would stay solid red with
very little flashing. That means it achieved a PERFECT
performance or theoretical limit, bound by disk i/o.

In my case, it does not. So, in my case, I am processing the
stuff at a rate equivalent to about 6 megs per second in
terms of disk access speed. Considering the amount of
processing going on under the hood, I'd like to see YOUR
app doing better using C++.

And what is going on during the processing is this:
you read each text line, pass it to the article parser
engine. That one detects various article headers,
saves them in the object to generate an article object.
Once the article is parsed, the filtering engine kicks
in to filter the articles on anything you can imagine,
including the article headers and article body, a pretty
heavy duty filter.

THEN, two indexes are constructed on the fly, by message
ID and by article date stamp. A typical operation
processes at least 100k articles. So, just to construct
a sorted index on that many articles is quite a trip
by itself.

So, if you consider that overall speed of processing
is not far from direct disk read, such as in file copy,
then that is good enough for a poor guy like me.

I bet you can't do it faster in C++, no matter WHAT you do.
Prolly 10-20% is the best case.

But...

What I get in return is to be able to write the GUI code
with a single language, without worrying about all sorts
of graphics toolkits. I do not have to worry about threads.
I know it will run on any platform where you can install
JVM. I have a pretty rich set of language. Just collections
alone, out of the box is all I needed to date.

And I don't have to worry of someone's toolkit or library,
all of a sudden, will either becomes a closed source, or
stops being maintained and develop. And I don't have to
worry whether there IS such a toolkit on a different
platform of IDE environment or not.

I am not even using the Java preferred IDE, becase I don't
like any of them. Just code completion alone, is my MAJOR
concern, and I mean code completion from the moment you
type your first character, that is able to recognize what
are the valid symbols in the scope I am in.

I can crank out the code probably twice as fast as they
can on those IDEs. Well, I did not try to compete with
anyone, but just for the sake of arguments. Sure, IDE
alone is not enough to achive such results. But, combined
with code design and architecture issues, a typical
significant program update, where some more or less
major functionality added, take a couple of days on average.
I don't rememober a case where I had to spend more than
a week, and I mean thing so radical, that I had to modify
at least 10 source files and change all sorts of GUI
code in several panels.

And THAT is what I am after. An OVERALL performance of
development cycle, portability, the amount of worrying,
the clarity of syntax and language notation.

I do not even use generics. A matter of principle.
I personally think it is one of the worst ideas in Java
since the day one. Most of it is bluff that translates
in orders of magnitude increase in complexity in terms
of being able to quickly read your code and understand
what it does.

I work on my code by looking at some scren for a couple
of seconds and I can see what is going on there.
I do not need to spend half an hour staring at some
hieroghlyphs from Martians. I don't have that time.

My brain is not overloaded with all sorts of useless
bells and whistles, taking most of my brain processing
time just to understand those utterly unintuitive
constructs and tricks.

So far, never regretted it.

In other words, just about ALL I have to worry is a single
something, a single language, a single syntax, a single
set of tricks.

Just the fact of me being able to run my app on Windows
and linux without even recompiling it, as I did,
wins the argument hands down, no matter what kind of artument its.

Simple as that.

But that is for ME. Not for you.

For you, I can only wish good luck.

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

 

[tanix]

tanix wrote:

Hm, explain to me how can any thread, access or change any pointer in
memory without lock while gc is collecting....
There is no way for gc to collect without stopping all threads
without locking.... because gc is just another thread(s) in itself...

To me, you are talking a kernel moder device driver talk.
You are saying things that may or may not happen in THEORY,
without considering the overall applicability of some concept
to the overall program performance, feature set, ease of use,
and on and on and on.

To tell you the truth, about the ONLY things I care about
as far as memory management goes is how much headache does
it produce for me for managing it and whether it works or not.

YOU can fiddle with those bits all you want.
Does not matter to me even a bit. I have no plans to rewrite
GC and can not even conceive such an idea.

All I know IT WORKS. And I can do it number of times faster
than you. And it still going to work. I don't even WANT
to hear about memory management issues as being ANY kind
of problem. We are WAY past that stage in the game.

Simple as that.

Now we have to solve the issues of having non dynamically
scoped languages being as portable as modern dynamically
scoped languages, such Php, the premiere language of web,
Javascript, Python, Ruby, SQL, and even HTML.

What seems to apply here is the issue of not seeing the
forest for the trees, more than anything else.

Of course. GC is complex program that has only one purpose.
To let programmer not write free(p), but programmer
still has to write close(fd).
What's the purpose of that?

Because close is a LOGICAL operation that can not be performed
automatically unless the program terminates.

And free() is not, just as GC proves beyond all doubt.

Refcounts are negligible in comparison to what gc is doing.
GC cannot be efficient since it cannot access program
memory while program is working....ad it doesn;t know what program is
doing... therefore GC can perform well only if it collect
when absolutely necessary. And when it had to collect performance
became catastrophic...

Sorry. But this is totally unproductive.
Cya.

Manual memory deallocation is simple, fast and efficient. Nothing
so complex like GC.
Cost of new and delete is nothing in comparison to GC.


Yeah right. And GC thread is black magic , right?


GC cannot be implemented efficiently since it has to mess with
memory...while other threads are working.
Add that compacting collector which have to update all references
in program and some copy/pasting... that can be optimised... to be
faster than new/delete , yeah right


I used GC with C++...


I don;t want to discuss this, but it is obvious that nothing in java is
designed with performance in mind. Quite opposite....

Greets

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

 

[Branimir Maksimovic]

To me, you are talking a kernel moder device driver talk.
You are saying things that may or may not happen in THEORY,
without considering the overall applicability of some concept
to the overall program performance, feature set, ease of use,
and on and on and on.

To tell you the truth, about the ONLY things I care about
as far as memory management goes is how much headache does
it produce for me for managing it and whether it works or not.

Memory managment is not a problem. You can implement GC,
for any apllication even in assembler. Reference counting
is simple form of gc and works well in c++ because
of RAII.
Problem is that that in java you don;t have raii and
resource management you still have
to implement by reference counting, or you close files
immediately in same scope? Never return descriptors
or other resources tu user?
So you have to manually call addRef/releaseRef
to implement GC for averything that is not java object....
in java

All in all first I was first warmed with idea of GC,
it is not problem to have it , but then I tried
haskell, and didn;t have memory leaks,rather
"space leaks"
And somebodey tried to convince me that conservative GC
is faster that shared_ptr/auto_ptr (what a ....


Greets

 

[peter koch]

Stefan Ram wrote:
[snip]
  More elegantly? Actually, for correct and secure C++ code,
  all functions need to be written to be »exception safe«, but
  only a minority of C++ programmers does so or even is aware
  of it.
Why?
The above is false. Exception-safe code is needed to write code
that avoids resource leaks in the face of an exception.
For instance:
   {
      char *p = new char[256];
      f();
   }

hm , why would you do this?

To demonstrate one way in which code fails to be exception safe.

isnt't that
     {
        vector<char> p(256);
        f();
     }
is simpler?

This code no longer demonstrates a resource leak in the face of an exception,
and so it would not have made a sutitable example to accompany my article..

Doh?

I guess what Branimir tried to tell was that you should always release
your ressources in a destructor. This gives you automatically the
basic exception guarantee.

 

[peter koch]

Right; for instance failing to unlock a mutex, or roll
back a transaction, aren't resource leaks.

Yes it is. A mutex held is also a ressource, and so is a transaction.
Both should be wrapped in a class having appropriate destructor
semantics.

/Peter