On Dec 22, 12:48 am, (e-mail address removed) (tanix) wrote:
<a65d3221-02ca-4a18-907f-9027cce07...@c34g2000yqn.googlegroups.com>, James
[...]
The rate of coding is orders of magnitude higher nowadays
and complexities also.
Actually, I think in a lot of cases, the reverse is true.
I know, I know. That is your style after all.
:--}
Zo... Let us see here the next jewel.
The
applications I see today are generally a lot simpler than those
of yesterday.
Wut?
That bites, I tellya!
For one thing, there's true runtime support for a
lot more functionality,
True, which means?
so you don't have to implement it in the
application.
Kinda.
And there are a lot of applications doing very
simple things---computers are cheap enough that you don't have
a complex operation to justify using one.
Huh?
I'll skip that one. Just don't get what you are talking about.
But both now and in previous times, there is a large interval
between the extremes. It wouldn't surprise me if the most
complex applications today were more complex than in previous
times. The least complex are certainly less complex. About all
I'd say is that the average application is less complex than
previously.
Well, sorry, I'd have to spend way too much time arguing this.
Seems like you are stretching things WAY too far for my taste.
Kernel mode drivers were one of the cases I was thinking about.
I've also written for embedded processors with only 2 KB of ROM,
and 64 bytes of RAM.
Hey, what a time that was!
When you have to write the most compact code for your BIOS.
Otherwise it won't fit into a 4 K ROM!
:--}
THOSE were the times!
That was a long time agom but I'm sure
that there are still embedded processors with very limited
resources (many of which probably don't even have a C++
compiler---just C).
Sure, for some reason, C is STILL the most popular language
around, at least looking at the amount of traffic on C groups.
For an application on a general purpose machine, I'd have
serious doubts about a company which used C, or banned
exceptions in C++.
I said that just for the sake of argument.
Not that anyone in his clear mind would go as far
as BANNING exceptions code, even though I have seen things
not to far from it.
But there's a lot more out there than just
general purpose machines.
[...]
Once you decide to go with return codes, that's it.
You have to test EVERY SINGLE return code.
That is definitely true. (Provided the "return code" returns
something useful or important. I wouldn't normally bother with
checking the return code of printf, for example, because it's
really meaningless.)
Yep, some of them are funny.
But what about scanf? :--}
You can not make ANY assumptions.
If I EVER find something that does not need to return the
return code, because, for example, I solved it differently,
I immediately rewrite the called routine so it does not
return any return codes, just for the purity of code's sake.
The possible problem here is virtual functions: if one of the
derived classes can fail, all of the derived classes need a
return value (or to be able to throw an exception, or whatever).
[...]
But I am just curious: what is the essense of argument
that the exception processing, under non exception conditions,
can possibly incure a significant enough overhead to even
bother about it?
That it once did, for some primorial compiler? I don't know,
otherwise. It's certainly false today.
Cool. Makes me feel better. That is ALL I want to hear
about this issue.
Exceptions are easier to make efficient when you don't have
value semantics, and objects with non-trivial destructors.
Oh, don't tell me about those non-tivial destructors.
It makes me shiver! :--}
It's
also easier to write incorrect code in such cases---as I said
elsewhere, one of the most common errors in Java is a missing
finally block. Still, except for some very early, experimental
implementations, I don't know of a case where an exception that
wasn't thrown has caused performance problems in C++ either.
See?
Then my argument stands.
And that is, once the exception IS hit,
take as much time as you want to do as good of a job of
handling or reporting it as you can imagine.
Because, first of all, it is going to happen in about 0.00001%
of all cases and the overall impact of it is less than you
know what by know hopefully.
Even in some local exceptions I try to do error reporting
and logging to the point where you know EXACTLY at which
exact point happened what and what were the "wrong" paramters
or values of what.
In my main app, I designed a pretty cool mechanism
of error reporting.
What it does is this:
The main class, which is the master of everything,
had a listbox, displayed at the bottom of the main program
window. And there is a checkbox for error reporting that
triggers finer granularity of reporting.
Every single operation that is performed by ANY modules
is passed to the main class via interface.
It is automatically shown in the history listbox.
The contents of this box is automatically logged into
perpetual logs, with file names time stamped to the day.
Which means what?
Well, which means that if I ever find something funky,
not only I can see it immediately in the history box,
but I can even dig those logs, going MONTHS back and
see if some of this funk already happened in the past.
Now, the way things are logged is that you have the
leading characters and keywords that allow you to basically
find anything you want by opening a history log for
your current session and search for those lil hooks,
or things like *** Error: .....
The history listbox has about 1000 entries history,
configurable to anything you want by simply modifying
your main program config file.
So, you can scroll back in history and see ALL sorts
of nice things, such as performance of your program,
the amount of records processed, the time it took,
the amounts of duplicates you found, the amount of
records you had to skip and ALL sorts of "nice to know"
things.
That is probably the best solution I saw to day
that utilizes the concept of logging vs. debugging
and makes your logs as clear and as simple do work with,
as you can imagine. So far, have not had to regret
this design even once. Probably one of the most
powerful aspects of the whole program and I was able
to get more help out of it, than even if I had to debug
this thing for days.
You like that one? :--}
It's also possible to misuse exceptions, so that they get thrown
in the normal logic of program execution.
Well, again, my classic example of string to number conversion.
The conversion error is quite "normal" flow
and exception simply replaces the result with default value.
I did see one guy, who is a super programmer,
or world class programmer, who even designed the whole
language that used exceptions as an equivalent of return code
in the language he wrote.
I don't want to tell you his name or the name of that language
But the whole thing looked a bit insane to me.
His language was event driven language.
Jeeez!
Yep, I'd have to agree with you on that one.
Using exceptions in this way is a bit sick.
I've heard of such
cases (although I've never seen them in code I've had to deal
with).
Lucky you! :--}
Still, any argument against exceptions based on performance is
simply FUD, at least IMHO.
That is what I thouht. I was just curious.
Who knows, they might have invented some trans gallactic
exception mechanism that allows you FULLY recover all the
intermediate what have you once the exception is hit.
The problem is that they don't necessarily learn. Since the
problem only occurs in "exceptional" cases, and a lot of people
neglect testing those.
Well, then who knows, that manager may loose his job.
During severl years, when I was cranking a lot of code out,
in the middle of major development phase, I had some situations
when I basically wrote the code to the point where
"it should never happen", while handling some weird errors.
It ran fine for a day or two, and then BOOM!
I had to go back and handle that "impossible to happen" thing.
And this thing happened to me several times during the next
few months. And EVERY SINGLE TIME when I thought, hey this
thing works like a champ, BOOM!
Since then, I never try to forget about some funky
condition I was too lazy to handle or was to itchy just to
get the whole thing to work. But hey, it is more pleasure
to see the whole thing working than to deal with all those
nasty lil lice that get under your skin.
Zo...
There is a fine balance, a tradeoff.
You want to get the kicks out of seeing your thing working?
Then write the major stuff and look at how it runs.
But remember one thing: design your code in such a way,
that there are nice hooks left so that you can easily
plugin the exception or error handling code in without
needing to rewrite some major pieces of code.
Otherwise, you are screwed for good,
and it is going to cost you 10 times more time and effort
to finally make it all hum like Bentley.
It's interesting to note that in the Java runtime, when opening
a file fails, they run garbage collection and try again.
Actually, I am impressed with Java gc.
It turns out that it garbage collects your local scope
allocations almost as efficiently as your normal stack unwind
code.
And it garbage collects on ajacent stack slots almost as
fast.
I, personally, think C++ BADLY needs this.
Just to make sure you don't have even theoretical leaks,
all you have to do is to set some object "pointer" to null
at the end, in that finally block or at the end of your code,
which should ALWAYS have a try/catch/finally blocks if that
code is ANY good.
ALL my major code has it. Several levels deep.
NEVER had to regret it.
Outstanding logging and error reporting is a piece o cake
with this design for one thing.
Because a lot of people forget a finally block when they've
opened a file, and in case of an exception, never close it.
Interesting thing about finally block is that it is executed
no matter what, even if there is no exceptions.
Nice.
(Whereas in my code, most of the time, if it's an output file,
and there is an exception, I not only close the file, but delete
it. So there's no inconsistent file lying around after the
program has run.)
Well, I do not bother to go THAT far.
When operation STARTS, that is where I need to know all my
files are good if they are input.
I can not just delete the output file if some error occurs.
Because that file already has several hundred of perfeclty
good data, and even if it is damaged as a result of some
funk, the file is a text file. I don't use any other stuff.
A matter of principle.
So what I do instead is to have the archive maintenance
module, that is as powerful as it gets. It allows you
to do magic with your files, including sorting the records,
removing duplicates, normalizing the structure to increase
the processing efficiency, filtering the archive with the
most sophisticate filters, merging archives, appending
archives and verifying the archive integrity.
If some record, even in the middle of archive, is damaged,
we report and log where exactly did it happen, so it is
a matter of seconds to find the exact place and manually
fix the record or delete it if it screwed up beyond
repair.
So, after I run the archive clean operation,
I am guaranteed to have the cleanest data you can imagine
in your wildest dreams. Even clearner than it was in the
original, non error input, that sometimes still has
errors becuase of some funky servers serving some funky
non RFC compliant data.
Cool eh?
:--}
We are sitting pretty here with this thing.
[...]
Do you have MORE logic in your program if you use return codes?
Or LESS?
You have the same amount of logic.
Not true. But I know you are going to come up with something
kinky. Let us see here.
Or else there's an error
somewhere.
I'd like to see a more substantial argument on this.
The only difference is that with exceptions, some of
the logic isn't visible, and doesn't have to be manually
written. (It does still have to be considered when analysing
program correctness.)
You ARE a pervert! :--}
But fine, I appreciate THIS kind of thing.
Don't confuse logic with lines of code.
Well, I bet this argument is SO subtle,
that you'll crack your scull sooner than you can prove it.
:--}
Enjoy the trip.
--
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.
