8 ms·

Rarely known C++ constructs (part 1): Function try blocks

76 points by sztomi 13y ago

tenfingers 13y ago
Every C++ book I even read mentions function-level try blocks. Unfortunately, they are rarely useful due to scope semantics (it's difficult to perform shared cleanup, even when using object guards).
- mattgreenrocks 13y ago
  FWIW, I have never seen this, and I have quite a few C++ books on my shelf. I either missed it repeatedly, or it is so obscure that it never came up.
  - nikbackm 13y ago
    They are included in TC++PL at least. But so is everything else in C++ :) They are probably obscure because they are only really useful for logging or remapping exceptions (unless a new exception is thrown the original one will be re-thrown at the end of the catch-block) in constructors and destructors. They can be used in normal functions as well, but offers nothing beyond what normal try-blocks do there.
    - pjmlp 13y ago
      My copy of the book is currently 2000 km away from me, but I think the "C++ ARM" already mentioned it, does anyone know?
barrkel 13y ago
This is hack on top of a broken feature. C++ doesn't zero-initialize instances before calling the constructor. Thus you can't tell which fields need to be cleaned up in a destructor in case of a partial construction [1]. So destructors aren't called for partial construction, and you need to handle the exception cleanup in the constructor. But you can't do that for member initialization lists, so there's this thing. RAII and wrappers is one reasonable way out of the insanity, but the costs are arguably higher than zero initialization - certainly in ugliness of wrapper classes, if not in absolute runtime. Forbidding exceptions in constructors is another reasonable way out, but that kind of sucks - constructors have no other way of communicating error, so you need to add isValid flags to your classes, and to be belt and braces secure, you need to check this flag for every operation. The correct answer is zero initialization, possibly with some kind of pragma to prevent zero init for critical performance classes. The thing with zero init is that data flow analysis can mitigate the costs - the compiler would be able to eliminate the earlier zero assignment much of the time. Overall it's more of the same from C++: unsafe, broken by default, bodged up with hacks to make it slightly more stable, and usually works mostly OK in practice owing to limiting C++ to a reasonable subset. [1] I know that technically 0 can be a valid physical address, but even for (embedded) systems that do allocate there, it's worthwhile reserving it.
- sztomi 13y ago
  I agree. I'm sure many people do in the committee even. Unfortunately C++ can't introduce breaking changes even though now we know better. I wish D or a similar (sane) native language gained some real momentum, since C++ is a "lost cause" in this regard (I can't deny that the new standards make it much nicer, the problem is the baggage that is called backwards compatibility).
  - voidlogic 13y ago
    You should checkout Go (http://golang.org/ http://golang.org/). It is more popular than D on github and has a lot of momentum.
    - voidlogic 13y ago
      Why the down votes. The poster asked for "sane" native languages with momentum? I gave him a suggestion that met his needs and made no false claims...
      - jmgao 13y ago
        You recommended a garbage collected language that doesn't even have generics as a replacement for C++.
        voidlogic 13y ago
        When it really matters- Nothing makes you use the GC... You can use a your own pool (or in tip sync.Pool) or mmap and your own allocator... I used to do a lot of C#/C++/Java and after two years of Go... I don't miss generics. Go has been a great C++ replacement for me...
- pjmlp 13y ago
  All caused by C compatibility, while trying to bring C developers on board with the "pay only for what you use mantra". C developers tend to think on micro-optimizations and Assembly level before writing any line of code, even when it doesn't matter at all for the problem being solved. C++ would be a much better language if C compatibility had been thrown out of the window. However, it might had not spread into the industry as it did.
acron0 13y ago
Jesus Christ. Never ever use try catch inside a constructor. It's the fastest way to a headache.
- seabrookmx 13y ago
  Exceptions are utterly broken in C++. I get flamed a lot for this, but I just avoid them in general in C++. In most languages this isn't the case, but in C++ I find explicit error handling code to be less work to write/maintain, even if it is a bit more verbose.
  - Iftheshoefits 13y ago
    I don't care for them, either, for the same reason: they are less explicit (to me) than direct error handling at the point-of-failure. I've found exceptions are also actually more verbose in many cases, for the same level of granularity in error trapping. My view is that exceptions handled in try-catch blocks are okay when handling "bulk" initialization or other computations where it doesn't matter which particular step failed. In every other case, it's better, in my view, to use explicit code.
  - byuu 13y ago
    I see two major use cases for exceptions in C++. The first, is for errors during recursive functions. Very challenging to escape from 13 levels deep into a recursive descent parser without throw. The second, is for container access-by-reference functions that are called on empty or out-of-bounds elements (eg array(4); array[16] = value;), since otherwise there is no way to return from the function, as you may not know how to construct a new container element (eg no default constructor), nor would you necessarily want to return a dummy object in that case.
  - nikbackm 13y ago
    How are they more broken compared to e.g. Java and C#? (Assuming you don't have a problem with these.) I would think having automatic cleanup via destructors would make C++ more pleasant to use in this aspect as you don't need to wrap all resource handling code in using and try-finally blocks.
72deluxe 13y ago
"They are also syntactically valid on regular functions, but of little use." I might litter my code with some of these to make it more "fun" for others to maintain it after I am gone / hit by a bus. At least I will go with the knowledge that they'll have to learn an obscure feature of the language, plus it'll remind me every time I see it (to stop the synapse degradation)

76 points by sztomi 13y ago

Every C++ book I even read mentions function-level try blocks. Unfortunately, they are rarely useful due to scope semantics (it's difficult to perform shared cleanup, even when using object guards).

mattgreenrocks 13y ago
FWIW, I have never seen this, and I have quite a few C++ books on my shelf. I either missed it repeatedly, or it is so obscure that it never came up.
- nikbackm 13y ago
  They are included in TC++PL at least. But so is everything else in C++ :) They are probably obscure because they are only really useful for logging or remapping exceptions (unless a new exception is thrown the original one will be re-thrown at the end of the catch-block) in constructors and destructors. They can be used in normal functions as well, but offers nothing beyond what normal try-blocks do there.
  - pjmlp 13y ago
    My copy of the book is currently 2000 km away from me, but I think the "C++ ARM" already mentioned it, does anyone know?

barrkel 13y ago

This is hack on top of a broken feature. C++ doesn't zero-initialize instances before calling the constructor. Thus you can't tell which fields need to be cleaned up in a destructor in case of a partial construction [1]. So destructors aren't called for partial construction, and you need to handle the exception cleanup in the constructor. But you can't do that for member initialization lists, so there's this thing. RAII and wrappers is one reasonable way out of the insanity, but the costs are arguably higher than zero initialization - certainly in ugliness of wrapper classes, if not in absolute runtime. Forbidding exceptions in constructors is another reasonable way out, but that kind of sucks - constructors have no other way of communicating error, so you need to add isValid flags to your classes, and to be belt and braces secure, you need to check this flag for every operation. The correct answer is zero initialization, possibly with some kind of pragma to prevent zero init for critical performance classes. The thing with zero init is that data flow analysis can mitigate the costs - the compiler would be able to eliminate the earlier zero assignment much of the time. Overall it's more of the same from C++: unsafe, broken by default, bodged up with hacks to make it slightly more stable, and usually works mostly OK in practice owing to limiting C++ to a reasonable subset. [1] I know that technically 0 can be a valid physical address, but even for (embedded) systems that do allocate there, it's worthwhile reserving it.

sztomi 13y ago
I agree. I'm sure many people do in the committee even. Unfortunately C++ can't introduce breaking changes even though now we know better. I wish D or a similar (sane) native language gained some real momentum, since C++ is a "lost cause" in this regard (I can't deny that the new standards make it much nicer, the problem is the baggage that is called backwards compatibility).
- voidlogic 13y ago
  You should checkout Go (http://golang.org/ http://golang.org/). It is more popular than D on github and has a lot of momentum.
  - voidlogic 13y ago
    Why the down votes. The poster asked for "sane" native languages with momentum? I gave him a suggestion that met his needs and made no false claims...
    - jmgao 13y ago
      You recommended a garbage collected language that doesn't even have generics as a replacement for C++.
      - voidlogic 13y ago
        When it really matters- Nothing makes you use the GC... You can use a your own pool (or in tip sync.Pool) or mmap and your own allocator... I used to do a lot of C#/C++/Java and after two years of Go... I don't miss generics. Go has been a great C++ replacement for me...
pjmlp 13y ago
All caused by C compatibility, while trying to bring C developers on board with the "pay only for what you use mantra". C developers tend to think on micro-optimizations and Assembly level before writing any line of code, even when it doesn't matter at all for the problem being solved. C++ would be a much better language if C compatibility had been thrown out of the window. However, it might had not spread into the industry as it did.

acron0 13y ago

Jesus Christ. Never ever use try catch inside a constructor. It's the fastest way to a headache.

seabrookmx 13y ago
Exceptions are utterly broken in C++. I get flamed a lot for this, but I just avoid them in general in C++. In most languages this isn't the case, but in C++ I find explicit error handling code to be less work to write/maintain, even if it is a bit more verbose.
- Iftheshoefits 13y ago
  I don't care for them, either, for the same reason: they are less explicit (to me) than direct error handling at the point-of-failure. I've found exceptions are also actually more verbose in many cases, for the same level of granularity in error trapping. My view is that exceptions handled in try-catch blocks are okay when handling "bulk" initialization or other computations where it doesn't matter which particular step failed. In every other case, it's better, in my view, to use explicit code.
- byuu 13y ago
  I see two major use cases for exceptions in C++. The first, is for errors during recursive functions. Very challenging to escape from 13 levels deep into a recursive descent parser without throw. The second, is for container access-by-reference functions that are called on empty or out-of-bounds elements (eg array(4); array[16] = value;), since otherwise there is no way to return from the function, as you may not know how to construct a new container element (eg no default constructor), nor would you necessarily want to return a dummy object in that case.
- nikbackm 13y ago
  How are they more broken compared to e.g. Java and C#? (Assuming you don't have a problem with these.) I would think having automatic cleanup via destructors would make C++ more pleasant to use in this aspect as you don't need to wrap all resource handling code in using and try-finally blocks.

72deluxe 13y ago

"They are also syntactically valid on regular functions, but of little use." I might litter my code with some of these to make it more "fun" for others to maintain it after I am gone / hit by a bus. At least I will go with the knowledge that they'll have to learn an obscure feature of the language, plus it'll remind me every time I see it (to stop the synapse degradation)