Slashdot Mirror
A New C Standard Is On the Way
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."
It's not on the way, it was released last year. Both gcc and clang are already a good way along implementing it, and we've added a big chunk of the library support to FreeBSD libc already.
I am TheRaven on Soylent News
That's great! I'm still using C4, and every time I compile my code blows up!
C11 will make var arrays, one of the most widely used C99 features, optional due to pressure from Microsoft, who refuses to implement C99.
C99 -> C11, come on guys ...
Blame Microsoft, not the standards committee.
GCC had it ahead of time.
If I wanted plastic scissors I'd use Java. Give me my scalpel back.
Because C is an ultra-clean procedural language. The entire purpose of using it is the purity. C with OOP can be found in ObjectiveC, C++, C# and D.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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.
I still have more fans than freaks. WTF is wrong with you people?
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.
The multi-threaded stuff sounds nice. But bounds checking, really? How difficult is it to check buffer size before copying?
Given the number of buffer overflow bugs that are found in C programs, apparently it's fairly difficult to do it consistently and correctly.
I've never been a fan of putting multi-threading/multi-tasking in a programming language. You get one abstraction of threads/tasks, and that's it. If you want to do it differently, you have to do it yourself with library calls. So why not leave it that way and keep the language simple?
Unless there is an awfully good reason not to (and I haven't encountered one yet), I use pthreads.
...laura
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.
"I blame the programmers not the language."
Good! Now you have to change the language once or blame the programmers forever (since you shouldn't expect to change them anytime soon).
Where did C99 go awry? Some of its mandatory features proved difficult to implement in some platforms. Other C99 features were considered questionable or experimental, to such an extent that certain vendors even advised C programmers to replace C with C++.
Speak for yourself Microsoft. It is not our fault that you can't implement C99 features properly or on time. For the rest of us C99 is alive, well and popular. Just avoid Microsoft's shoddy compiler and you will be fine. Both GCC and LLVM do the job properly.
By the way, similar comments apply to Microsoft's tardy and dodgy implementation of C++11.
When all you have is a hammer, every problem starts to look like a thumb.
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.
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.
Anything but the pure C as defined in the sacred Whitebook pollutes the simple beauty of C and obscures the language's clarity and its similarity to the instruction sets of most common CPUs.
9/11 Eyewitnesses to Explosive WTC Demolition 1 of 2
Microsoft has publicly declared that they have no intention of supporting anything past C95
I gave up on Microsoft back when Byte magazine was in, or recently beyond, single-digit issue numbers.
A letter to the editor complained about Microsoft's support of their FORTRAN compiler: There was a bug in the floating point format handling that a customer needed to use. After several iterations of bug reports and fix requests, Microsoft had told the guy that not only had they not fixed it yet, but they were never going to fix it. IMHO that meant Microsoft had an institutional issue with customer support and adherence to standards.
Avoiding Microsoft software and products has saved me immeasurable grief over the several decades since.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
I used Ada some time back. It's a nice object-based language (not OO, object-based) but its strictness could sometimes be infuriating. Good, but infuriating.
I wouldn't want C to go in the direction of Ada - yes, the safety of C needs improving, but I regard C as being increasingly a universal starting point, a theoretical third-generation language rather than an actual one. There are now many dialects of C and many spin-off languages, some using that starting point better than others. It's a bit like the Cambrian Explosion, only the offshoots can still borrow from the central stem.
Ada, however, is highly architectured, like Occam. Architectured languages are intended for very specific purposes and fulfill those purposes extremely well. Well, when they've been architectured correctly, that is. They've traded in the theoretical base point and the benefits of evolution for the benefits of being highly predictable and highly dependable within their niches. A well-written Ada program has levels of assurance on reliability that no C program could have -- or ever should have, because to have that level of assurance would kill off the very thing that makes C so powerful, which is the rate at which it evolves and de-standardizes. (Destandardization means you can exploit and assimilate new ideas faster. C is The Borg.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Yes, I totally think we should rewrite the linux kernel in C++
I don't know if you're trolling, but I agree, it is the logical thing to do.
Linux has many, many C++ features implemented in an ad-hoc and poorly specified way in C.
It is very heavy on OO style with derived classes and virtual functions.
TRhe C style objects are complex and require init and cleanup functions to be called.
They have imlemented type-generic macros in order to reduce code duplication effectively.
Basically, C++ takes those three things and integrates them into the language in a standard way so that everyone uses them in the same way, you get sane error messages and compiler support. C++ has one additionmal advantage that it has one global vtable per class, so each instance has a single pointer to the vtable. Linux's C-style OO has each instance having a pointer to every virtual method otherwise the syntax would be too unpleasant. This makes it less memory efficient in C and increaces the cache footprint.
The only thing worse about C++ would be that the compile times would be increased.
But that's a tiny price to pay for fewer bugs and faster code.
SJW n. One who posts facts.
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.
SJW n. One who posts facts.
gcc is pretty good at vectorisation, provided it can prove a lack of aliasing (which is very, very hard).
If you make heavy use of statically sized C-style arrays allocated on the stack, proving a lack of aliasing is much easier, and gcc generates vectorised code pretty well.
What gcc can't do is specially tag pointers allocated from malloc() as somehow similar to stack allocated arrays and assume that they don't alias in the same way. I think thbe intel compiler is much better at that, which is where many of the gains come from.
GCC is getting better however. In some cases it can prove that malloc()/free() pairs haven't achieved anything and elides them entirely. However the functionality seems pretty new and incomplete and ti doesn't work with new/delete yet.
SJW n. One who posts facts.
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.