Quote:Original post by Jan Wassenberg
You have utterly disqualified yourself by giving only the C++ portion of the benchmark results on your system.

Wait, what? I was simply trying to point out that the original benchmark was outdated. If you look at the C version, you'll notice that in fact the "throwing" version IS faster allready. It's using an exception mechanism, albiet an extremely crude one.

Quote:What, you want the C++ version to reflect your newer compiler and faster test system, but not C? What I'd like to know is whether this is due to bad faith or ignorance ("Heinlein's razor"). Congratulations either way.

I simply focused on the language I used. I'm well aware the C version will also run faster on my system, I'm not going to make the claim "and so we see the C++ version is obviously faster" - that'd take a good deal of faulty brain cells to assume.

Quote:No less ridiculous is that in reply to "Since signals are not the delivery vehicle for access violation notifications on Windows, whether or not they arrive is irrelevant" you say:

Quote:I was under the impression that signals still worked. My compile test proves me right

No comment needed.

Sorry, I was under the impression that you were arguing that they did not in fact work, and the arrival reffered to was the delivery of the message, whereas your prelude refered to the fact that signals would not work (or this is how I read your argument).

I'm confused because first I stated that "my sane GCC system" will reach their intended target - the signal handler, you counterargued that this writes off all windows systems, to which I pointed out that the example compiled on windows just fine, to which you counterargued something about it being irrelevant due to the fact that "signals are not the delivery vehicle for access violation noficiations on Windows". I assumed (since I wasn't exactly sure what you meant with the last bit of your sentance) that you meant the access violation would not trigger the signal handler - so I provided an example which proved that an access violation could indeed be caught via signal handler.

Obviously I'm missing something, so instead of saying what's irrelevant here, can we state what IS relevant?

In any case, I believe my point still stands on this issue - you don't need to deal with SEH directly with the exceptions mechanism.

Quote:Semi-related side note: you are hard to take seriously when speaking repeatedly of "Lambada".

Lambda, Lambada, same diff :-p. I have the annoying tendancy to speed-read words, "hear" them in my brain, then forever start using that spelling.

Quote:

Quote:Yes, I've allready admitted that

It is regrettable you are speaking of "admitted"; after all, this is not a cross-examination. Got something to prove, eh? What place does ego have here?

... huh?

I'm quite confused as to what the heck you're trying to say. Are you saying my manhood is small? Is that it?

(Seriously though... "huh?")

Quote:

Quote:I feel that I can approach C++ as one of the highest-level languages out there.

Get a clue.

Show me an example of something I could not do in C++ and then we'll argue about wheither or not I need a clue.

Quote:

Quote:I'm not programming torpedos

Good. Anyway, the Torpedo Bureau thing was billed as an *analogy*.

I'm not even going to mention the safety net thing, because it seems to be hopelessly beyond you. Try reading exactly what I said again.

But hey, these individual things add up to: my mistake. (recognize yourself?) Since this discussion is not bringing us forward, no further replies will be forthcoming.

A shame, although considering personal attacks seemed to consist of most of your counter-reply this time around, prehaps it is for the best. I'll post a quick review of the points I believe were covered on in my next post.

Quote:from the linked article:
(NOTE: This is an installment in my “Handling Online Vermin” series about addressing people with poor online communication habits...

Neither of you have "poor online communication habits", so that article is irrelevant to both of you.

Interesting thread. But why did some very intelligent people go to such great lengths to place exceptions into the language if they are not a good solution to a problem, Jan? (And from what I can tell, they _are_ a good solution to a problem. They don't slow down your code _unless_ something exceptional happens. And oddly enough, I have seen situations where placing a 'try - catch' block around something actually made it go slightly Faster, although I don't remember if that was only in Debug or what - it was a long time ago.)

David

Okay, this list is obviously going to be biased by my opinion on exceptions (that they are good), but I think some of the points raised are informative if nothing else. They're also extremely sumerized. Hopefully, those reading may gain some nuggets of information - such as using the language-level nothrow guarantee (throw()) to help prevent bugs in transactional operations.


Argument: RAII dosn't give control over making sure dependancies are destroyed before "this".
MM Counter: Reverse-order-of-construction should ensure this
Jan Counter: Reverse order is not allways appropriate
MM Counter: Then provide an explicit close() as per std::auto_ptr (see release()) and std::_fstream.
Jan Counter: That's not RAII
MM Counter: I, and most of the sources I've read say it is.


Argument: RAII requires you to mantain more classes
MM Counter: Well, 1 reusable class minimum: raii_scope<>
Jan Counter: Your class is ballooning (RE: adding of release())
MM Counter: No, it still reduces usage code, meaning less lines overall.


Argument: Majority of programmers of today suck, they can't write exception safe code.
MM Counter: Can't expect them to write error-checking code, or even buffer-overflow-safe code anyways.


Argument: RAII requires you to mantain documentation (RE: Exception guarantees)
MM Counter: Only as much as exceptionless code with error checking would - e.g. you could have strong/weak/noerror guarantees,
MM Counter: just like strong/weak/no exception guarantees.


Argument: Exceptions can be thrown anywhere (in 2+2)
MM Counter: Fault of the library(s) and/or C++ operator overloading mechanism. Argument against that rather than exceptions.
MM Counter: With operator overloading, you can set error codes that would need to be checked for "proper" execution all the same.


Argument: Transactional programming easier with error codes
MM Counter: Error codes will only catch errors at run time. No throw guarantee at language level (e.g. throw()) can be used to catch bugs
MM Counter: that could cause a transaction to fail at runtime and only be caught then.


Argument: Exceptions are slow
MM Counter: Don't use them for the rule rather than the exception, then.
MM Counter: 86K caught exceptions/second on crappy server
Jan Counter: MSDN Benchmark (catching much slower than normal execution)
MM Counter: MSDN Benchmark outdated (reposted C++ results on recent system)
MM Counter: Exceptions arn't meant to be thrown every frame - throwing an exception is slower than returning an error code.
Jan Counter: You fool, why havn't you included the C benchmark as well
MM Counter: ?!?


Argument: Exceptions are slow
MM Counter: Exceptions can be faster for normal flow (e.g. no exceptions thrown) than return codes
Jan Counter: by maybe 1 cycle.
MM Counter: It adds up when it occurs with every function call
MM Counter: (after the fact) : Also, only general solution is GetLastError, which will be more than 1 cycle likely.


Argument: Throwing C++ Exceptions is slow.
MM Counter: 86K caught exceptions/second on crappy server
Jan Counter: ...slower than return codes.
MM Counter: No contest, but return codes slower for normal use.


Argument: SEH Exceptions thrown by anything
MM Counter: Don't use SEH, use signal handlers.
Sidenote: Signal handlers will catch access violations.
Jan Counter: MM: Not exactly sure? Seemed to be pointing out that they wouldn't work, but apparently I'm missing the argument here...


Argument: Pre-empt error conditions by checking (e.g. if it dosn't matter if a file exists or not, check if_exists(...) before trying to open it which would cause an exception ("slow").
Jan Counter: Too slow.
MM Counter: 16,000 files/second size checked benchmark
Jan Counter: VC's stat() slower
MM Counter: Fault of HD, filesystem, or VC.
Jan Counter: Still, 1 second is too much for my binaries/ directory.
MM Counter: Most of 1 second latency probably from looking up file data, which will be cached assuming you then try and open the file, so overhead is 1-time occurance and shared.


Argument: Hard to convert exceptions to error codes at library boundry.
MM Counter: Example using dispatch()
Jan Counter: Not especially fast
MM Counter: Just use C++, it's flexible enough
Jan Counter: Get a clue
MM Counter: Show me that I need to get one.