Quote:Original post by Jan Wassenberg
Quote:The second, RAII version is still smaller.
Duh! Are you surprised?
Point is, if we're going to talk about the horrible ballooning effects of adding 5 lines of code elsewhere, we shouldn't ignore the fact that we're saving 5 lines of code in two uses as well.
Quote:Quote:This is all good argument, but it simply states that error codes arn't much slower, rather than arn't slower period :-). If for god knows why I'm forced to have error checking in an innermost loop which happens to be a bottleneck, 1 cycle can add up.
*sigh* You really think exceptions are faster? I mean, that's just amazing. For someone who has implemented them, you really have no clue.
You said it yourself ;-). It dosn't even have to be in an innermost loop, if every single function call you make has return codes to keep track of. Is the difference small enough that it's not going to be a main arguing point? Probably. Is the difference small enough that it won't offset the overhead during a throw, making the argument a moot point? That will depend on usage...
Quote:Quote:Well, sounds like VC sucks ;-). But seriously, that's an argument against VC's implementation of exceptions, not exceptions in general.
I was under the impression that this was the standard approach. See the end of the other thread, which gives performance and implementation data.
Program Code Size Time (no throws) Time (with throws) XBench.c 4.6k 1392 ms 1362 ms CPPBench.cpp; 35.3k 1492 ms 71343 ms
Of course, you just took the code without checking that these benchmarks were on a decent compiler and recent. Compiling them myself, we get:
CPPBench.cpp; 35.3k 47 ms 1140 ms
Notes:
1) This is in release mode, exceptions preform the same either way, nothrow preforms faster in release.
2) This benchmark compares running normally every time to throwing an exception every time. Exceptions are not meant to fail 25 billion times a frame, this is not where they excell. Even so, they only preform 25x slower than a simple divide, a few adds, and a return, when we're re-entering our try/catch block, throwing an exception, and appropriately catching it every frame!
3) Yes, I've allready admitted that exceptions preform slower when they allways fail. For fair comparison, one must look at how often the operation will fail, and compare that to the speed gained when they don't fail.
Quote:Quote:I intentionally left it out, actually. If there's no placeholder.bmp, then something's seriously messed up and needs looking into. Worst case scenario, it was just pure coincidence, programmer plays around in paint for 5 seconds, and saves placeholder.bmp :-).
Riight.
I've had bugs in my Zip IO code (part of VFS) that only failed on files with certain offsets. You do not want such a bug to take down the entire game. Which it would here, since that may throw an exception which you don't catch (=> boom).
It'd be caught in my main handler, like all such "missed" exceptions are. If you'd rather replace it with a whitespace texture, and maybe adding a log entry, then do that. Me? If the bitmap that clearly indicates a resource is missing is in and of itself missing, I want the fact uncovered, rather than running around prehaps in my rendering code wondering why the screen is all white, when in fact some goofball thought it'd be funny to not commit ANY of the textures of a scenario someday.
Quote:Quote:Commonplace for a project does not mean commonplace on a per-call level. If a function is run 1 million times each time, and on average, one of those calls fails, then it's commonplace for that project to have that occur. On the other hand, from the function's perspective, it's an extremely rare exceptional circumstance which only happens 1 in a million times.
It's great that you can make everything seem small by pulling "million" out of your hat. Point is taken, but when writing a library/code module, you can't assume exactly how often you will be called.
But you can make educated guesses. Considering how much of my code never throws period, 1 in a million would be a conservative measure.
Quote:It seems quite arrogant to say "all errors are exceptions".
Not all are, but the ones you don't deal with are. If you don't want it to be an exception, head it off at the source. Check that a file exists before trying to open it, and whine in a dialog for the user when it dosn't. Whine again when he types in 1.2.3.4.5 for an IP address. If you've tried to open a file that dosn't exist, it's obvious you havn't planned for that contingency, and therefor, this problem is unexpected - which is when I throw an exception. If this causes 20 billion exceptions to be called a second, then that's a bug that needs fixing, because it's become the rule rather than the exception.
Quote:Quote:One problem at a time, eh? :-).
hehe. Well, as we stand, these problems leave your exception->error thunks not suitable for production use.
Which is why I don't use them. For dtor errors, I simply log them and/or assert them.
Quote:Quote:Diehard in the sense that my requirements are for myself, and that I'm not going to limit myself to a reduced functionality in an extremely versitile language. I havn't found real problems reimplementing the functionality found in other languages - it might be more verbose (functors for lambada, weird crazy ass templates for smalltalkesque syntax) but it works :-).
Let me guess - you really only use (i.e. know well enough) C++? Now obviously all non-toy languages are Turing complete, so anything you can do in one you can emulate in another. But that does not address the fact that certain tasks are much easier in higher-level languages.
I've programmed in many flavors of BASIC (Q, VB, the "real" kind on the apple 2 - built a tanks game with destructable terrain using the first one), x86 assembly, plenty of different shells, XSL (if that counts), PHP (written online file managers using it), and would be programming in smalltalk probably right now if I hadn't simply ripped off some of the ideas and ported them to C++, where my pre-existing library is.
I feel that I can approach C++ as one of the highest-level languages out there. When I'm missing a feature, I can implement it. Array slicing? boost::range. Lambada? functors or boost::lambada. N-greater-than-single-dynamic-dispatch? Hack out some of the type macros from the boost::function source and do it. Signals and slots? Again, boost.
Quote: I have high enough productivity and flexibility in C++ that I can adapt the padigrams of other languages, rather than depending on actually having the language to use it.
"*Enough* productivity and flexibility", heh. Someone using assembly language could say that of themselves. Now it's great to adapt useful things from other languages, but you can't say with a straight face that Python offers no advantages over C++.
Wrong emphisis, and no I can't. At the same time, I can't say Python offers enough advantages over C++ and PHP for me to not use one of them. Even BASIC has it's advantages. You don't see me writing it anymore though, do you?
Quote:Quote:It wouldn't get in the way, because I'd use the sane way to deal with things - a signal handler.
Oops, those aren't raised on Windows. What do you do then?
Quote:Quote:Quote:Also, just to show that throwing and catching have nothing to do with wheither or not signals will reach their intended target on my sane GCC system:
That's great, but irrelevant - unless you are writing off all Windows systems.
Unless, of course, the example compiles on Windows. Which it does.
You misunderstand. Since signals are not the delivery vehicle for access violation notifications on Windows, whether or not they arrive is irrelevant.
I was under the impression that signals still worked. My compile test proves me right:
#include <signal.h>#include <iostream>using namespace std;#define SIGSEGV 11 //C void handler_sigsegv( int ){ cout << "We caught a SIGSEGV, aka Segfault or Access Violation" << endl;}int main ( int argc , char ** argv ){ signal( SIGSEGV , handler_sigsegv ); cout << "About to access 0x00000000..." << endl; *((int *)0x00000000) = 0; cout << "Accessed 0x00000000!!!" << endl;}
C:\eclipse\workspace\test.2>Debug\test.2About to access 0x00000000...We caught a SIGSEGV, aka Segfault or Access ViolationC:\eclipse\workspace\test.2>_
Funny, that.
Quote:Quote:You have unwinding with your bailout ladder, too. Real-world exceptions will also have optimizations turned on.
Duh.
So, same overhead, and converging times since the difference between them remains a constant.
Quote:Quote:There's half a bazillion things that can go wrong which can cause you to loose a file, after all :-).
What does that have to do with our discussion?! But hey, if a bug destroys user work, at least you can tell them: "maybe your cat would have also caused it".
*sigh* I'm simply trying to point out that auto-save is a valid technique for helping prevent user data loss. No, your program should preferibly not be buggy, but I have no faith in Microsoft to be able to pull that off, and if they're going to give me a buggy piece of ****, I'd much prefer it have auto-save stuck on as a bandaid, which will also protect against said cat, than just loose my work every 5 minutes.
Quote:Quote:but that "band-aid" works just as well for hardware failures and OS bugs, which is where any sort of after-the-fact system is going to have a big chance to fail.
This obviously went right past you. A safety net is great, but you still don't want to *rely on* (<- did you spot the emphasis this time?) it by being careless on the tightrope.
Being careless on the tightrope is stupid, yes. It's even stupider to assume that you're a god with no need for a safety net.
Quote:Quote:Yes, because we're programming torpedos </sarcasm>.
Sarcasm is not an adequate reply. And speak for yourself - if at work we screw up, people run into walls (ouch) and bang up a rather expensive helmet.
It would do the industry good to assume more responsibility than "manajmint not responsible fer nuthin'".
Oh I'll agree with that. But the point remains,
I'm not programming torpedos,
You (havn't mentioned any projects where you) are programming torpedos, and my
Cat dosn't exist, so even if he were a super-kitty, he wouldn't be programming no torpedos neither ;-).
Rely on bandaids? I wouldn't, because it's a bad idea.
Don't use a safey net because it's a bandaid? I wouldn't do that either.
There's a difference between not working on bug fixing because you've got a safety net, and realizing the fact that you're only human. No, I think it'd be pretty stupid to rely on having auto-save exist for the sole purpouse of dealing with that bug you couldn't track down. But yes, I think it'd be a solution to hardware failures (one of the many things that can send out signals). If you want to set up a signal handler to deal with specialized contigencies, the more power to you. Just realize that you can't plan for, and deal with, every one outside of a controlled environment.