A New C Standard Is On the Way 305
Esther Schindler writes "Last year, Danny Kalev — a former member of the C++ standards committed — explained the new features in C++. Now, in C11: A New C Standard Aiming at Safer Programming, he shares an overview of the changes in C — 13 years after the ratification of the C99 standard. Kalev describes the goodies in C11, including multi-threading support, safer standard libraries, and better compliance with other industry standards."
On the way? (Score:5, Informative)
Re:Slow Adoption of Current Standards (Score:5, Informative)
Blame Microsoft, not the standards committee.
GCC had it ahead of time.
Re:Missing features (Score:5, Informative)
C runs on way too many devices without floating point support to add those as standard libraries. It wouldn't be useful on many platforms.
And C isn't about adding every feature in the world. The language itself is pretty much done. They're just changing libraries. They'll never add a major feature like closures, nor should they. If you want them, use another language when they're designed in well, not hacked on.
Re:Slow Adoption of Current Standards (Score:5, Informative)
Visual Studio added stdint.h not to comply with C, but to comply with the pending new C++ standard. Microsoft has publicly declared that they have no intention of supporting anything past C95 (basically ANSI C circa 1989 with a few tweaks).
So some of the coolest things in C99 and C11, like named initializers, compound literals, etc, will never be in Visual Studio, because C++ has refused to adopt those features from C.
Re:Slow Adoption of Current Standards (Score:5, Informative)
Visual Studio is explicitly a C++ implementation, and does not focus on C support. It has what effectively amounts to C89 support, but that's a legacy thing. Any support for C99 and C11 features is purely accidental, and usually happens when some header is required by both C99/C11 and C++11 (hence why it's just headers and never language features).
In the meantime, other implementations, which actually care about C as well and C++ - like gcc or clang - add C11 support fairly quick.
Re:Slow Adoption of Current Standards (Score:2, Informative)
I feel your pain on this, but MS has said time and again that they don't bother with the C standard because they make a C++ compiler, not a C compiler. So they only bother complying with C++98/03 and C++11. Any C99 compliance we get is essentially just due to the shared standards that C99 has with C++11. This isn't to say I excuse this decision, just a little insight as to why it took so long to get stdint.h.
Re:C11???? (Score:4, Informative)
Re:Missing features (Score:4, Informative)
Restrict is to help the compiler discover when it can assume the lack of aliasing, and therefore aggressively prefetch and cache values. This is especially so when combined with static size array arguments (as in int[static 4]), which by definition cannot be null, permitting compiler to fetch without any checks. I guess it can also be used to improve parallelization by letting the compiler assume lack of dependencies between reads and writes where otherwise it would have to assume they exist, but that's not quite the same as vectorization.
I know some compilers can do auto-vectorization on loops over arrays - notably Intel - but this is still too limited to be portable. Most implementations require you to use the (implementation-defined) intrinsics to do the same, which to me strongly indicates that this is the way this should be standardized. Also, writing such loops explicitly every time is unnecessarily verbose.
Re:Drops the most important feature of C99 (Score:4, Informative)
For VS 2010, C++11 (then 0x) implementation was actually better than g++. It looks dated today because g++ has more frequent releases and it didn't take it long to catch up and overtake. Ditto for Clang.
For VS 2012, yeah, it's lagging behind, mostly because a lot of time was spent on C++/CX [microsoft.com] language extensions for Metro. They did update existing features to be spec conforming - e.g. lambdas were previously implementing draft semantics which have changed in the FCD, so those were updated to match the latter. It also adds a bunch of minor stuff like range-for and strongly typed enums, and a good chunk of new libraries (most notably atomics, threads and futures). Here [microsoft.com] are the details.
There is talk about doing a separate release later on specifically for VC++ to catch up with C++11 support. If you care about that, rather than just seeing it as an opportunity for some MS bashing, please add your vote here [uservoice.com] (I did).
Re:Who needs threads? (Score:5, Informative)
IIRC it's because without putting explicit constraints on the memory model (needed for threading), you end up with holes of varying sizes when talking to memory from threads.
It's mostly to do with CPU caching / memory barriers and having a consistent temporal view of data in and out.
If it's not in the language, you end up with each platform/compiler having their own approach to barriers / atomics which makes glueing different bits of code together with different approaches a crap shoot when it comes to consistency.
Here's a good place to start [open-std.org]
OOP sucks (Score:3, Informative)
What features do you want?
Automatic memory management? Isn't this what makes C++ so fucking insanely complex? Bad idea.
Overloading? Umm, that's extremely dangerous in subtle complex code like operating system schedulers, computational code, etc. Very bad idea.
Inheritance? Nah. Almost as bad as overloading, but also useless for most most activities.
Templates? No, they're even worse than overloading. I suppose Java interfaces or Haskell typeclass could provide a safe form of overloading. I certainly acknowledge the desire to parameterize a struct on another type, but that's extremely complex for a low level language.
Lambda expressions, ala C++0x? Interesting proposal, not exactly sure how the memory management works out, but perhaps one could grant the compiler the ability to build closures in this way, but subject to the programer's memory management.
Yes, I'll grant that lambda expressions make sense, but not C++0x's lambda expressions, since they impose a memory management scheme. In essence, lambda expressions in C should be just-in-time optimizations that the programer controls manually.
In truth, most object oriented language 'features' are actually bad design choices, well unless your doing GUI work where the error object oriented programming creates aren't catastrophic.
Yes, there are vaguely functional features like parametric polymorphism and lambda expressions that might aid low-level programming, but they're complex enough to require a proof-of-concept language first. C must avoid the mad dash into standardization that created C++'s complexity.
Re:Drops the most important feature of C99 (Score:2, Informative)
If by "short time" you mean 5 to 6 years, okay. It was open sourced in 2007, but had been in development at Apple for longer than that.
Re:D? (Score:3, Informative)
no -- C was based on B, which was based on BCPL. So first came BCPL, then B, then C, therefore the next one will be P.
Re:OOP sucks (Score:4, Informative)
Automatic memory management? Isn't this what makes C++ so fucking insanely complex? Bad idea.
You're doing it wrong, frankly.
If your programs are full of new/deletes in mismatched pairs, then you're missing out on much of the point of C++.
Overloading? Umm, that's extremely dangerous in subtle complex code like operating system schedulers, computational code, etc. Very bad idea.
WTF? I write computational code for a living. Good numerics libraries full of operator overloading make my code much, much more simple, reliable and correct. So, I'll stick with overloading thankyouverymuch.
Inheritance? Nah. Almost as bad as overloading, but also useless for most most activities.
I've honestly no idea what you're talking about. Classic OOP inmheritance has its uses, and it's used throughout the Linux kernel for instance (see e.g. vtables). C++ just adds compiler support. Other inheritance is just aggregation of data which is an entirely reasonable thing to do.
Templates? No, they're even worse than overloading. I suppose Java interfaces or Haskell typeclass could provide a safe form of overloading. I certainly acknowledge the desire to parameterize a struct on another type, but that's extremely complex for a low level language.
Templates are what makes sane numerics libraries great, and container libraries. In fact you've just admitted that they're useful, but for some reason, you don't want expressivity in your low level language. Also, C++ allows parameterization on an int, as well as a type, which is an especially powerful featureand is missing from almost all other generics systems.
Lambda expressions, ala C++0x? Interesting proposal, not exactly sure how the memory management works out, but perhaps one could grant the compiler the ability to build closures in this way, but subject to the programer's memory management.
You tell the compiler whether you want the closure to capture by reference or by making a copy of the data. In the former case, the memory in managed in exactly the same way as normal (via destructors) in the referenced variables. In the latter case, the lambda justs acts like a class with a bunch of data members and calls the destructors when it goes out of scope.
Yes, I'll grant that lambda expressions make sense, but not C++0x's lambda expressions, since they impose a memory management scheme. In essence, lambda expressions in C should be just-in-time optimizations that the programer controls manually.
I don't think you understnd lambdas. A lambda is a shorthand for making a struct with a bunch of data members and an overloaded operator(). That is all. It interacts with the language in exactly the same way as all other structs.
In truth, most object oriented language 'features' are actually bad design choices, well unless your doing GUI work where the error object oriented programming creates aren't catastrophic.
Now we have a kernel of truth which doesn't apply to C++. Yes, OO concepts are somewhat limited in scope. They are useful for some things, but not for others. People have widely abused them to apply to everything either by choice or because languages often provide few other mechanisms. C++ does provide those other mechanisms and doesn't force you to make make everything a massive ovject heirachy.
Apart from in a small number of libraries I use, I make very little use of classic OO concepts like polymorphism etc. I use classes and methods, but as an encapsulation and occasionally aggregation mechanism. That's a far cry from classic OO, though.
Yes, there are vaguely functional features like parametric polymorphism and lambda expressions that might aid low-level programming, but they're complex enough to require a proof-of-concept language first. C must avoid the mad dash into standardization that created C++'s complexity.
lolwut? C++ a mad dash in t standardisation? Good troll, sir.
Re:I don't get it... (Score:4, Informative)
It is a third-generation language with no features taken from the first, second, fourth or fifth generations.
You're way overstating the case for C as some theoretically pure language. It's been tagged as a "high level assembler" for a reason, in that the underlying machine bleeds through (the second generation) much more than in other "third generation" languages.
C is just a language that happened to take off. It isn't pure in any sense of the word. It's got half-assed "modules" based on crude file inclusion. Its mix of pointers, arrays, and integer types is baroque. It's got the beginnings of inheritance with its unions. It's structural but supports goto and setjmp/longjmp. This list is by no means exhaustive.
It's also extremely dubious to say that object-oriented doesn't belong in the third generation of languages. Simula 67 was the first -- that's 1967, predating C. Also, Cobol, Lisp, and Fortran were third generation languages, all with distinct forms.