> [C++] also had type inference very early on, but the developers of the mid-80s were not quite ready for that and Bjarne Stroustrup was pressured into removing auto, until it was added back to C++11. Does anybody have background information on this claim? Was there actually a working compiler with it back then or was it just some proposal paper at the time?
I found a post claiming it was used in B and C to specify a data type stored on the stack. https://stackoverflow.com/a/8272497/7608007
The Problem with C (2020)
11–20 of 177 posts
Re: The Problem with C (2020)
#12> [C++] also had type inference very early on, but the developers of the mid-80s were not quite ready for that and Bjarne Stroustrup was pressured into removing auto, until it was added back to C++11. Does anybody have background information on this claim? Was there actually a working compiler with it back then or was it just some proposal paper at the time?
I found a post claiming it was used in B and C to specify a data type stored on the stack. https://stackoverflow.com/a/8272497/7608007
Re: The Problem with C (2020)
#13C is the glue interface that connects all the different languages together. I wouldn't want to see anything new added to the language that complicates this lingua franca. I liked C in the 80s, 90s and 2000s. It was a neat and simple language, but that changed as compilers got more aggressive with their optimizations and exposed just how complicated and unintuitive the spec actually is (and the impossibility of avoidi…
Re: The Problem with C (2020)
#14Anyway, some things I think would make for interesting content at such a conference, should one decide to exist:
Modern C. It would be useful with practical down-to-earth comparison between C the way (I feel) many think it "should" be written, i.e. C89-style with lots of worry that the compiler may be broken, and something more modern/sensible.
Standard directions. Some kind of survey-style talk trying to both summarize known interests covered by the committe now, and also perhaps polling the audience for input about where C needs to go.
Compiler architect's thoughts. Get the major compiler writers in a panel, have them talk about how various language (mis)features affect their ability to write good compilers, and what changes would help with that, if any.
Code sight-seeing. Just having a few knowledgable folks navigate some well-known codebases on a projector with commentary/analysis would be very interesting I think, both to see how others have solved things, and perhaps spot problems/possible improvements. Must be done respectfully of course.
Now I almost feel as if I miss that conference. :/ More ideas, anyone?
(Edited for typos and grammar)
Re: The Problem with C (2020)
#15C is the glue interface that connects all the different languages together. I wouldn't want to see anything new added to the language that complicates this lingua franca. I liked C in the 80s, 90s and 2000s. It was a neat and simple language, but that changed as compilers got more aggressive with their optimizations and exposed just how complicated and unintuitive the spec actually is (and the impossibility of avoidi…
What makes you think Rust and Zig will not suffer the same issue given enough time?
Re: The Problem with C (2020)
#16Re: The Problem with C (2020)
#17C is the glue interface that connects all the different languages together. I wouldn't want to see anything new added to the language that complicates this lingua franca. I liked C in the 80s, 90s and 2000s. It was a neat and simple language, but that changed as compilers got more aggressive with their optimizations and exposed just how complicated and unintuitive the spec actually is (and the impossibility of avoidi…
Re: The Problem with C (2020)
#18C is the glue interface that connects all the different languages together. I wouldn't want to see anything new added to the language that complicates this lingua franca. I liked C in the 80s, 90s and 2000s. It was a neat and simple language, but that changed as compilers got more aggressive with their optimizations and exposed just how complicated and unintuitive the spec actually is (and the impossibility of avoidi…
Indeed, and rust, zig, fortran, and julia don't have the problems with c that c++ does, so is it a problem with c or with c++ that the author is actually talking about?
If C++ would just treat C as an interface like everyone else does, this problem would shrink considerably.
Re: The Problem with C (2020)
#19At least with cfront you had some idea of what was getting generated.
My favourite C++ compiler was Symantec 7 on windows. It was a great, affordable tool for making MFC applications and had a neat GUI builder too. I still have the CD of it but it refuses to install on windows 11 sadly.
Nowadays I just use C or C#, C++ just seems like a hard to use version of C# and I have little use for the extra performance it might have.
Re: The Problem with C (2020)
#20C is the glue interface that connects all the different languages together. I wouldn't want to see anything new added to the language that complicates this lingua franca. I liked C in the 80s, 90s and 2000s. It was a neat and simple language, but that changed as compilers got more aggressive with their optimizations and exposed just how complicated and unintuitive the spec actually is (and the impossibility of avoidi…
What makes you think Rust and Zig will not suffer the same issue given enough time?