I hope it's not mandatory. I'd much prefer static analysis to tell me of use-before-acquire errors: I have a number of hot-inner-loops where initialization nukes performance.
In the context I'm thinking of, I have fairly sizable arrays -- up to 512 bytes; usually, only the first few bytes are used (for state tracking); an `int` tells me the high-water mark so the data is only read after being written. The amount of work int the loop is (in almost all cases) only 5 or 6 instructions before termination. Initializing 512 bytes is best case 8 ops, which is >100% overhead. The code is recursive, but bounded to a depth of 8, wity internal linkage (only two `int`s and a pointer are passed) in the tail call position, so the calling convention is just three registers. Even a compiler like q9x, or clang with no opts, produces excellent code. But, even a sniff of initialization tanks perf to the tune of 3x.
RAII in C++ does not mean that all bytes are initialized, only the ones you want. In
struct Foo {
int header = 0;
float foo;
int data[64];
int footer;
// just to show that having an explicit constructor / dtor does not change anything
Foo(): footer{456} { }
~Foo() { }
};
It's not a matter of optimization, absolutely no compiler will zero-initialize unless you explicitely ask for it (or you are in a situation where the language mandates initialization, like global static in C and C++)
Well don't know about the parent but you ruined my day.
Thing I keep coming back to is the proportion of effort you have to spend learning and keeping up with your tools vs the problem domain your working on. Feels like a big problem with C++ is how much energy the language itself uses up.
A friend of mine is, unlike me, really really smart. He likes golang and hates C++. And not like he hasn't spent years professionally writing C++ code. I think the advantage of golang is he can write it reflexively. So all of his attention is on the problem not the language.
Me I feel like the problem with C is not so much the language. It's that I'm always worried about stepping off a ledge. Things like defer would help. Because failing to clean up resources is a big problem with C.
The silver lining is that really 99% of the time it just doesn't matter. I just explicitly initialize everything to zero/nullptr (unless I have a specific reason to want a different explicit value), and I only worry about looking up the particular rules if I need them in a situation where I know initialization can be a significant cost like a gigantic array. It is annoying to look up every time that happens but it's not that often.
But is failing to clean up transient resources that are only allocated for the duration of one function (or block) really a big problem with C? These tend to be the easiest ones to handle (but admittedly a bit annoying & verbose without defer) and spot if missing. (Also: static analyzers are relatively good at pointing out resources leaked in a single function.)
I think most of my functions that allocate a resource only release it on error; otherwise the allocated resource lives on and gets freed later by another function. Defer doesn't help at all here. It just helps with the trivial ones..
This link is exactly what I'm saying, if you don't ask for it you don't get initialization. There are multiple ways to ask for it because the person who writes the type may eitherwant to take on the responsibility of initializing entirely by initializing on the ctor, or delegate it to the call site which can then either initialise (T t{};) or not (T t;).
The SO post looks confused ; A, B, D, E and F are the exact same case wrt the initialization of the int. It does not matter that there's a constructor or not and which shape it has, only that the variables get initialization somewhere or not (and that can be in the ctor's member init list, in the struct définition or even when creating a value if aggregate-initializing).
I'm sure you know what you're talking about wrt C++ spec, but you ignored the main point. It's easy to be confused by stuff like that. It's hard to read C++ code and know (other than intuit) what it does. For a lot of people including myself, at least.
Prototypes were in the original C standard of 1985, before first edition of The C++ Programming Language was released and long before C++ was formalized standardized.
While the first draft was released in 1983, the first ratified C standard was in 1989.
The first edition of "The C Programming Language" (from which I first learned the language) was published in 1978, over a decade before the language was standardized.
You are correct that C89 added function prototypes. However, contrary to your implication, C borrowed the concept and syntax from C++.
Everything I said was correct. I was a member of X3J11 (which was established in summer 1983), the C language standard, and was the first person on the planet to vote to approve it (due to alphabetical order) ... that was in 1985. It was several years before it was ratified, the delay having to do with standardization politics which required a lot of buy-in. I have no idea why you're mentioning the first edition of K&R from years earlier, which of course did not have prototypes.
There's a notable difference between C's prototypes and C++'s ... `int foo();` in C is not a prototype, whereas in C++ it's equivalent to `int foo(void);` ... C had to maintain compatibility with K&R style declarations, whereas C++ didn't.
