Rarely known C++ constructs (part 1): Function try blocks
szelei.me
szelei.me
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.
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...
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.
Um, citation, please? Speaking as, you know, an actual C developer working in a company full of actual C developers, I would say that "bad C developers tend to think on...", etc. There are times when we need to use assembly and micro-opts, but trust me, no one ever wants to.
Though I agree that C++ would be a better language without the backwards compatibility constraint.
I never liked pure C, and had my endless share of performance discussions since around 1993.
Just one example, discussing how slow C++ virtual calls were and how one cannot afford to use them, while coding an application where Clipper would still be fast enough for the job.
Worse is better. C++ is nothing if not pragmatic, and the core of C++ programmers are similarly pragmatic.
If D or go or rust or whatever else ever become more practical to use than C++, then people will switch. I know C++ is very ugly, but it gives me an unmatched combination of runtime performance, good tools, API/OS compatibility, and acceptable language design. There's a good reason why so many VMs for other languages are written in C and C++, and it isn't elegance.
The thing is that many of the WTF people associate with C++, are caused by C underpinnings.
> There's a good reason why so many VMs for other languages are written in C and C++, and it isn't elegance.
While I do like C++, enough to have lots of C++ books, I only partially agree.
I come from the Pascal branch of languages and consider it has more to do with existing toolchain infrastructure than anything else.
One thing I've noticed is that the dominant languages for resource-constrained programs all seem to envelop the previous generation. You can embed assembly in C. You can embed C in C++. C++ has yet to be embedded in another language, at least if you want to keep the same memory layout of objects.
I'm curious to see if D or some other language can buck the trend.
If you look at the history of systems languages, the only ones that won market share, had the sponsorship of an OS vendor as their official language. Specially because many people hate to write FFI bindings for their favourite language and it doesn't scale to map the full OS API.
So the question is which OS vendors would pick the wannabe replacements.
I think that language exists. Depending on what you need from it, presumably it's Java, or one of a number of other languages.
On my type of work we have long moved into other languages.
http://www.reddit.com/r/cpp/comments/1ygcay/rarely_known_c_c...
These days all resources should be wrapped in some kind of manager class like std::unique_ptr so there's really no need to use function try-blocks for that.
Observe: https://ideone.com/DYthrB
#include <iostream>
#include <memory>
struct Foo {
int x_;
Foo (int const x): x_(x) {
if (x == 1) {
throw x;
}
}
~Foo() { std::cerr << "foo_" << x_ << " destroyed" << std::endl; }
};
struct Bar {
std::shared_ptr<Foo> foo_0;
std::shared_ptr<Foo> foo_1;
std::shared_ptr<Foo> foo_2;
Bar():
foo_0 (std::make_shared<Foo>(0)),
foo_1 (std::make_shared<Foo>(1)),
foo_2 (std::make_shared<Foo>(2)) {
}
~Bar() {
std::cerr << "Bar destroyed" << std::endl;
}
};
void xul() {
Bar bar;
}
int main() {
try { xul(); } catch (...) { return EXIT_FAILURE; }
}
foo_0 destroyed
Change main to:
int main() { xul(); }
The alternative to relying on there being a try{} block somewhere up the stack is to add a function-try block on Bars constructor.
tl;dr: member destructors aren't called if you throw from a constructor init list, function-try blocks fix that.
Exceptions in constructors are incredibly more useful than isValid()'s due to their composability. isValid()'s have to be checked and fail in the constructor body after the initialization list. This is why you're concluding that zero-initialization is the only way out of a problem that you're creating in the first place.
Try doing everything in the initialization list, and rely on nothing in the constructor body.
I was a compiler engineer at Borland / Embarcadero on Delphi, a non-GC language with a zero-init approach. Java zero-initializes. C# zero-initializes. In fact, I struggle to think of a modern language that doesn't zero-init or prevents access to uninitialized fields by definite assignment analysis.
Overhead in C++ is a different story. C++ is not low overhead enough, to me, to justify the claims made for it. For example, I like static data structures, especially in C. But in C++ they are unidiomatic. How do you statically initialize (in the rdata / rodata segment) an object graph (even as simple as a tree) with zero-copying at runtime?
Or how about copy constructors that may throw exceptions. That leads to inefficient APIs for things like std::stack::pop(). Guarding against exceptions in generic code has implicit overhead when the type system is as user-mutable as C++.
How do you do that in C? Does unidiomatic mean you can't do it? Interesting challenge.
That's also an interestingly-sized data structure. Apparently big enough that the initialization time is a performance concern, but small enough to be able to lay out statically and not burden your binary size.
You can zero-initialize an object on the stack in C like this:
struct my_object obj = { 0 };
In C++, you can still do this, but only for POD types. Basically, in C++, it is assumed that you will manually initialize all data members in the constructor. POD objects get a free pass since they're essentially C structs.
It's true that the language support for generating such a thing is minimal (though templates in C++ can get you pretty far), so other techniques like generating code at build time or (the emacs trick) actually executing the script interpreter in a bootstrap mode to generate the pickled data are common.
To be fair, with move semantics in C++11, C++ has started to depend on dataflow optimizations for zero-initialization (or, to be more precise, zero-deinitialization). After a value is moved, typical objects will zero themselves out so that the call to the destructor won't do anything, and they count on data flow analysis to strip out the zeroing out and the overhead of the destructor call.
(That said, I much prefer definite assignment analysis to zero-initialization. I tend to think zero values in general are kind of a wart in language design.)
A::A() {
B::B();
try {
foo(1);
}
catch (...) {}
// you could even
if (something)
bar(2)
else
bar(3);
// or maybe with a different syntax,
// but without copying if this is an object
bar = 3
}This is exactly the reason why we use C++ for high performance applications: we don't pay for features we don't need. On one commercial product I worked on [1], we found out that zero-initialization of 3D vectors was consuming around 5% of the total running time on some scenes.
[1] The CPU kernel of iray: http://www.nvidia.com/object/nvidia-iray.html
struct Bar
{
int * one;
int * two;
int * three;
Bar()
{
one = new int{1};
two = new int{2};
three = new int{3};
}
~Bar()
{
if (!one) return;
delete one;
if (!two) return;
delete two;
if (!three) return;
delete three;
}
};
struct Bar
{
std::unique_ptr<int> one;
std::unique_ptr<int> two;
std::unique_ptr<int> three;
Bar()
:
one{new int{1}},
two{new int{2}},
three{new int{3}}
{}
};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)
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.
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.
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.
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.