11–20 of 64 posts
I prefer Raymond Chen's take on exceptions: http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/35294...
This reads to me like 'writing good code is hard, and writing even better code is even harder'. With modern C++0x smart pointers (like unique_ptr) and RAII, you can get very high performance and (more) easily exception-safe code. Maybe a lot of C++ exception criticism comes from people still trying to code like C in C++?
Today with terabyte harddrives, gigabytes of RAM and broadband connections, when is the binary size a more important factor than both execution speed and ease of development? Especially when the binary size difference is probably not huge? Shouldn't the advice of this article just be "use exceptions"?
Cache sizes have not seen gains proportional to RAM or HDs.
My 486 built in 1993 had 8 KB cache, 4 MB RAM, and a 120 MB HD.
My desktop built in 2009 has 2 MB cache, 2 GB RAM, and a 250 GB HD.
Okay, the cache has lagged behind by one or three doublings compared to the other storage types. But that's still pretty close to proportional in a world of exponential gains.
I prefer Raymond Chen's take on exceptions: http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/35294...
This reads to me like 'writing good code is hard, and writing even better code is even harder'. With modern C++0x smart pointers (like unique_ptr) and RAII, you can get very high performance and (more) easily exception-safe code. Maybe a lot of C++ exception criticism comes from people still trying to code like C in C++?
some folks have decided to get off the C++ feature treadmill and go back to, well... getting things done with solid languages (e.g. C) instead of learning about the latest C++ non-solutions to non-problems.
Earlier quoted context omitted.
"since you have to check every single line of code (indeed, every sub-expression) and think about what exceptions it might raise and how your code will react to it" Yes, that's my concern with exceptions as well. It seems like the Java model (if I remember it right -- it's been a decade), which requires a method to either handle an exception that a sub-method throws or explicitly allow it to be thrown, would be prefe…
You're thinking of "checked exceptions" and C++ already has them (pre 0X) via the "throws" clause on method declarations. Checked exceptions is a hotly debatted topic and I think the world has kinda finally come around to deciding that the are a bad idea overall. Google it and see for yourself.
I prefer Raymond Chen's take on exceptions: http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/35294...
I didn't see any timings in his code.
Earlier quoted context omitted.
Cache sizes have not seen gains proportional to RAM or HDs.
Sure they have. My 486 built in 1993 had 8 KB cache, 4 MB RAM, and a 120 MB HD. My desktop built in 2009 has 2 MB cache, 2 GB RAM, and a 250 GB HD. Okay, the cache has lagged behind by one or three doublings compared to the other storage types. But that's still pretty close to proportional in a world of exponential gains.
Here's a different take, then, and probably harder to verify, but I am guessing is true:
Cache utilization has increased much more than RAM or HD, not just because programs are handling more data but also because of increases in program size and number of programs being run simultaneously.
Your hard drive is probably not full... RAM could be, depends on your workload... but I bet most caches are churning like mad, more than they used to be.
If an exception is being thrown then something is wrong, if something isn't wrong then you implemented your exceptions incorrectly as exceptions shouldn't exist in normal program flow.
So to recap, you're writing a crap ton of more code just so you can return your error code _slightly_ faster than it would take an exception. You're optimising your failure cases, which (in the _vast_ majority of cases) is UTTERLY ABSURD.
Nice article but as far as I'm concerned you don't need to _prove_ this as it is a logical fallacy to start with. If an exception is being thrown then something is wrong, if something isn't wrong then you implemented your exceptions incorrectly as exceptions shouldn't exist in normal program flow. So to recap, you're writing a crap ton of more code just so you can return your error code _slightly_ faster than it woul…
Nice article but as far as I'm concerned you don't need to _prove_ this as it is a logical fallacy to start with. If an exception is being thrown then something is wrong, if something isn't wrong then you implemented your exceptions incorrectly as exceptions shouldn't exist in normal program flow. So to recap, you're writing a crap ton of more code just so you can return your error code _slightly_ faster than it woul…
Example: a listen loop which handles disconnections through exceptions. This isn't stupid but it's not very efficient.
Earlier quoted context omitted.
Cache sizes have not seen gains proportional to RAM or HDs.
Sure they have. My 486 built in 1993 had 8 KB cache, 4 MB RAM, and a 120 MB HD. My desktop built in 2009 has 2 MB cache, 2 GB RAM, and a 250 GB HD. Okay, the cache has lagged behind by one or three doublings compared to the other storage types. But that's still pretty close to proportional in a world of exponential gains.
http://seven-degrees-of-freedom.blogspot.com/2009/10/latency...