Catching and Throwing in C++ can be tricky, but this chapter will help you to know when and how to use these functions effectively, as well as when you shouldn’t be using them.
C++: Throw by Value, Catch by Reference
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
and also oversimplified.
I just dont like exceptions.
If your a c++ programmer you should definately pick up the book. All the discussions are relatively short, but they’re direct, to the point, always dead on and I wouldn’t call any of them oversimplified. This is, after all, Herb Sutter and Andrei Alexandrescu; two of the foremost C++ experts on the planet.
Well Eugenia said it’s a chapter, not an article.
Nervertheless, it would have been good to show the various options and their potential dangers. Not to mention copy constructors that might be involved etc.
As much as I like c++, this is the kind of stuff that makes it unproductive. It takes months, if not years to the beginner to get up to speed and produce robust code.
actually, that was a chapter. If you’ve never read Sutter’s books many of the chapters are short (they’re generally best practices books) and to the point like this. What you’d see if you read the book though is that future points tend to exemplify and refernce the point made here. This is why I say that if you’re actually a C++ programmer, meaning a full-time C++ person instead of a part-time/sometime C++ person, you owe it to yourself to just go ahead and buy Sutter’s books.
Teaching basic things about programming first is good – it’s bad to throw everything to ones face in one huge package. This was good introduction to expections.
Hmm. This advice is so obvious its kind of retarded that there is any other way to do it. Especially the catch part: why would you *not* want to catch by reference? It’s like slicing — what possible good use could you have for castrating a poor object? Heck, if you’re worried about the extra pointer dereference in an exception path, its time to get your head examined.
The thing I like about C++ is that it is hard to master. There’s always something to discover. I’ve been doing C++ on my spare time for some years now, and there’s still much to learn and overcome.
Some of the embarassments, such as the Static Initialization Order Fiasco, I could have been without. One could maybe have wanted a garbage collector. But the very lack of it is exactly what makes C++ more of a challenge than C# and Java. (I’m sure I get pepper for this.)
Well, there’s no such thing as a language that’s perfect for all things, meaning that it’s ideal. However, other than CPU-specific instructions that are required for OS things like kernel mode instructions, there’s nothing you can’t do in C++ if you want to. And even in those rare special cases, the language has a provision for inline assembly if desired
C++ is an interesting mix of providing automatic support for certain things (like default copy constructors and assigment operators) that can cause some problems if you aren’t fully aware of them, while not providing automatic language-defined things like garbage collection. It is very much a language that allows an almost infinite range of abstraction from twiddling a given bit at an absolute memory location, to the larger abstractions of objects. The language costs in learning time and mastering the details is gained in the execution time, trusting the language user to know what they want and how to do it. By contrast, a language with automatic garbage collection forces you to give up many optimizations a knowledgeable developer could get by using C++ (or C). There are optimizations you can make as to when and how things are allocated, as well as optimizing at the system performance level, such as cache lines and VM pages, that no garbage collection system could ever hope to optimize for any particular system. It doesn’t come for free, but you have that choice with the language, whereas C#, Java, Python, etc. don’t give you those low level options, and protect you from some of the mistakes you can make in C/C++ (buffer overruns, anyone?) at a hit in performance.
Really, it comes down to what your objectives are: choose the right tool for the job, and don’t worry about what others think
It says that all you need to do is create a non-throwing copy constructor..
For a class that is on the stack and copied in the throw, how easy is this?
Their example of “AppendContext” .. arggh.
@Santa
thanks god C++ doesn’t have garbage collection and provides a decent ‘object lifetime’ implementation (that the Java and C# infamous ‘dispose’ method doesn’t)
@Jonathan Thompson
> the language has a provision for inline assembly if desired
> There are optimizations you can make as to when and how things are allocated, as well as optimizing at the system performance level, such as cache lines and VM pages, that no garbage collection system could ever hope to optimize for any particular system
Sorry but it sounds like a troll to me.
AFAIK, there’s no such inline assembly in C++
Sure C++ gives you great control on how objects are allocated, stack, heap, static or your own chunk of memory. But there’s no way you can control VM pages at the language level.
Things like ‘register’ and ‘inline’ are just *suggestions* and easily (and hopefully) ignored by the compiler. Other language compilers do this kind of things without explicity indicating it.
Last, garbage collection doesn’t protect you for buffer underruns nor hasn’t bad performance per se, don’t think malloc is the faster way to allocate things, that’s why C++ has the ‘placement new’.
It says that all you need to do is create a non-throwing copy constructor..
For a class that is on the stack and copied in the throw, how easy is this?
Well, a reference-counted implementation would probably do, where the stack allocated object in fact contains only the handles to the reference-counted implementation. One does not see this very often. I guess just building exception classes from non-throwing primitives is the superior way (if that is possible at all, of course).
Their example of “AppendContext” .. arggh.
Can you elaborate on that? I did not read the book.
This advice is so obvious its kind of retarded that there is any other way to do it.
It’s obvious only if you have experience in the language.
> AFAIK, there’s no such inline assembly in C++
Actually, most C and C++ compilers support inline assembly, usually using an “asm” keyword.
But not in the same way for every compiler – especially because there is no standard for inline assembly in c++. that is up to the compiler …
C++ programmers (mostly 12 year olds who’ve read a textbook or two) like to talk about how great manual memory management is, and how garbage collection is for unskilled programmers. What they don’t realize is that memory management in a typical C++ program is done with a combination of techniques, all inferior to garbage collection:
– stack allocation and making copies of everything
– reference counting
– and the most popular one: ad-hoc, call delete and hope no references remain
Any non-trivial C++ program is either slow due to refcounting and excessive copying, or it has a “hand-tuned” memory manager that causes the program to segfault and leak memory like a sieve, or it includes a garbage collector.
Well, I don’t see things by this angle. Of course, the great point of garbage collection is to free the programmer of worry about where and when to free objects. Also, as a bonus, as it is tested by a lot of people, the chance that errors on the algorithm get squashed and moved away of your code is improved.
But why do you think the mecanism is “inferior” to other techniques is out of my mind. They both call the OS to allocate unless you get if from a internal pool, and on this case, a good library seems to me to be faster (and have the wanted quality I referenced).
Also, if you are a good C++ programmer, you probably know how to avoid unnecessary copies of objects.
Yes, I do agree with other comments that C++ isn’t easy to master, what isn’t any good, and that one of the reasons of so many complaints is that many programmers tend to recreate even the most basic algorithms instead of relying on ones inside good libraries. But that’s a kind of tradeoff – I give you the liberty to do anything but will raise your duties.
On other words, feel free to use what you like at most.
Does OSNews have a with-boring-troll macro, or are you going to floating around for a indeterminate amount of time?
> Any non-trivial C++ program is either slow due to refcounting and excessive copying…
making such a generic afirmation, i will asume that you have analized *Any non-trivial C++ program* on the planet…
gargage collection is great for great bunch of cases, but it has well know pitfalls and it’s not the best way for every problem
stack allocation and copying is faster that you might think
it is the same as saying garbage collection is sh*t
This guy is obviously a Java fanboy who’s scared and confused by the mere sight of a delete operator.
It’s a fairly well-known fact that a large percentage of all commercial performance-critical software (read: games) are written in C++, whereas Java is mostly used for GUI-intensive software (read: apps that spend most of the time waiting for a slow human to press keys and click buttons).
Must be all that anti-Java propaganda being spewed by Microsoft. Yeah, that’s the ticket.