3 ms·

Took a few years for C to adopt function prototypes from C++, one can hope that RAII makes it in less than a century

thechao 5y ago
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.
- edflsafoiewq 5y ago
  Can you give an example of how initialization nukes performance?
  - thechao 5y ago
    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.
    - jcelerier 5y ago
      > Initializing 512 bytes 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() { } }; only "header" and "footer" will be initialized: https://gcc.godbolt.org/z/4W1WzfPEv https://gcc.godbolt.org/z/4W1WzfPEv 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++)
      - dataangel 5y ago
        > It's not a matter of optimization, absolutely no compiler will zero-initialize unless you explicitely ask for it Oh man I'm about to ruin your day. Behold the horror: https://stackoverflow.com/questions/29765961/default-value-and-zero-initialization-mess https://stackoverflow.com/questions/29765961/default-value-a...
        Gibbon1 5y ago
        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.
        foxfluff 5y ago
        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..
        dataangel 5y ago
        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.
jibalt 5y ago
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.
- Sindisil 5y ago
  Oy. Your history is ... confused. 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++.
  - jibalt 5y ago
    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.

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.

edflsafoiewq 5y ago
Can you give an example of how initialization nukes performance?
- thechao 5y ago
  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.
  - jcelerier 5y ago
    > Initializing 512 bytes 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() { } }; only "header" and "footer" will be initialized: https://gcc.godbolt.org/z/4W1WzfPEv https://gcc.godbolt.org/z/4W1WzfPEv 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++)
    - dataangel 5y ago
      > It's not a matter of optimization, absolutely no compiler will zero-initialize unless you explicitely ask for it Oh man I'm about to ruin your day. Behold the horror: https://stackoverflow.com/questions/29765961/default-value-and-zero-initialization-mess https://stackoverflow.com/questions/29765961/default-value-a...
      - Gibbon1 5y ago
        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.
        foxfluff 5y ago
        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..
        dataangel 5y ago
        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.

jibalt 5y ago

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.

Sindisil 5y ago
Oy. Your history is ... confused. 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++.
- jibalt 5y ago
  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.