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."
Hmm (Score:2, Funny)
No wonder they're not popular. C99? C11? It should be "C... X!" :p
Re: (Score:3)
Re: (Score:3)
But by then, we'd have lost the hardware to that software answer (unless someone still has a C64 in the attic)
On the way? (Score:5, Informative)
Re: (Score:2, Funny)
It's not on the way, it was released last year.
C'mon, this is /. -- it's either a dupe or it's old news.
Re: (Score:2, Redundant)
You'd think people would have figured that from it being called C11, too...
Re:On the way? (Score:5, Funny)
The "11" actually refers to how far you can turn up the volume.[1]
[1] Quoted from Tough Love's Album of Unreliable Facts (c)
Re:On the way? (Score:5, Insightful)
This being C, 11 would mean that you can turn the volume from 0 all the way up to 10.
Re:On the way? (Score:5, Funny)
No, you can turn the volume up as high as you want, but it's only defined for 0 to 10.
Re: (Score:3)
Y3k bug strikes again, he meant C3011
C11???? (Score:5, Funny)
That's great! I'm still using C4, and every time I compile my code blows up!
Re: (Score:3)
I hear C5 was dog-slow and users suffered humiliation.
Re:C11???? (Score:5, Funny)
Plus, as using C-14, I am able to determine the compiling date of any given code.
Re:C11???? (Score:5, Funny)
Since I'm using C64, I find I have to be careful with my memory usage.
Re: (Score:2)
Re:C11???? (Score:4, Informative)
Re:C11???? (Score:5, Funny)
Re:C11???? (Score:4, Funny)
Re: (Score:3)
Re: (Score:2, Funny)
I've been using CB. All functions are called by the new "breaker.breaker" operator--and don't even get me started on the crazyvariable names you have to use...
Re:C11???? (Score:5, Funny)
Re: (Score:3)
--insert ~ath comments here--
not thii2 2hiit...
Drops the most important feature of C99 (Score:5, Interesting)
C11 will make var arrays, one of the most widely used C99 features, optional due to pressure from Microsoft, who refuses to implement C99.
Re: (Score:2)
Do you have any references that this is "due to pressure from Microsoft"? Last I checked, VC++ team has plainly stated that they are simply not interested in working on vanilla C, so why would they care about what is and isn't in C11?
Re:Drops the most important feature of C99 (Score:4, Funny)
Last I checked, VC++ team has plainly stated that they are simply not interested in working on vanilla C, so why would they care about what is and isn't in C11?
Given that Microsoft's implementation of C++11 also sucks, exactly what is the VC++ team interested in working on?
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: (Score:2, Interesting)
Clang only ever looked dated compared to VC++ because the damn thing wasn't even finished yet. I doubt VC++ will ever catch up again with it, though. Clang in a relatively short time managed to go from barely able to compile C++03 to possibly the most complete implementation of C++11.
Re: (Score:2)
That's easy to fix, just don't use Microsoft's crappy compiler. The days when it could compete effectively with GCC are long gone, and LLVM is coming up fast too.
Re: (Score:3)
Having followed C++11 support in compilers, I can tell you that the C++11 support in even the latest version of Visual C++ (Visual C++ 2012 RC) is lagging behind both GCC and clang. To be fair, a lot of the lag is caused because Microsoft spent a lot of their resources in the VS2012 development cycle attempting to implement Variadic Templates (and not getting it done in time for the VS2012 release)
Re: (Score:3, Interesting)
Which is ironic, because Microsoft's Visual Studio team has stated they have no intention of supporting anything newer than C95. I don't understand why Microsoft is even allowed representation on the ISO committee.
And the bounds-checking API which Microsoft "contributed" is useless. It's clunky, and requires more boilerplate coding than just using the standard interfaces with proper bounds checking. Plus they added a completely new errno_t typedef, which will probably breaks tons of existing code. Not to me
Integer overflow! (Score:5, Funny)
Re: (Score:3)
It should at least have been C111
Re: (Score:2)
The multi-threaded stuff sounds nice. But bounds checking, really? How difficult is it to check buffer size before copying?
Re: (Score:5, Insightful)
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.
Re: (Score:5, Insightful)
"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).
Re: (Score:2)
"If it is such a problem, go use another language."
But he was blaming *other* programers. You don't deal with this by *you* changing to another language.
Re: (Score:3)
Because it costs extra cycles, and you can't make the assumption that it's neglegable every single time? Because of C's promise that you don't pay for what you don't use? Because it's a logic error to begin with and you should fix your logic errors, program your intent, and not rely on the compiler to figure out what you meant? Because you want to control the binary output?
Take your pick.
Re: (Score:2)
Re: (Score:2)
The road to hell is paved (Score:3)
I blame the programmers not the language.
I blame the program architects. C isn't the right choice if you want strong typing, bounds checking, auto-alignment, the concept of finite arrays and all the other safety nets.
C is the right task for some jobs precisely because it doesn't have these features. And the wrong task for many jobs for the same reason.
Adding features like this reduces C, by making it more like other languages that already are better suited for the job.
Use C if you can handle all (and I mean all) checking yourself, be it through
Re: (Score:2)
It's not difficult at all, but people forget about doing it all the time. The point of those new interfaces is really more about forcing you to do that check (the function will do it, but you have to provide the size of the buffer to it).
Re: (Score:2)
Why do you need to explicitly check the buffer size at all?
A well-designed program ensures you can't crash the buffer to start with.
Re: (Score:2, Insightful)
Are you suggesting it is possible to create a program that doesn't involve buffers?
Even the simplest Hello World program uses buffers. Even fancy languages that have run-times and virtual machines use buffers. Buffers are an integral part of designing software because they are an integral part of how the machine works at the hardware level.
Re: (Score:3)
I'm not sure how you think printf"(hello world\n"); uses any dynamic (i.e. user-created/maintained )memory but never mind thats not my point here.
What I am saying is that you write your code such that once you created a buffer, your program knows its length and is written in such a way that it isn't possible to crash it.
For example, only use bounded functions like strncpy() rather than unbounded ones like strcpy().
Re: (Score:3)
>> Some how you went from "buffer" to "dynamically allocated memory"
Yes because if you need a buffer of a length only known at runtime you should be using dynamic memory rather than statically define an array of some guessed length.
>> 1) your string isn't actually a string because it isn't null-terminated.
This is only true if you were stupid enough to make your buffer too small, which usually happens because junior or hacky programmers are often inexperienced or hacky enough to incorrectly think
Re: (Score:2)
I'm not saying that at all. All potential buffer overflows are just a result of sloppy coding.
Even in languages with no built-in protection like C you can easily and elegantly architect your code such that crashing buffers is impossible.
People need to stop expecting languages to make up for their own lack of skill and/or attention to detail.
Re: (Score:3)
hrmph... (Score:2)
All the fuss over C, yet there's still no "H" programming language...
Re: (Score:2)
Personally, I think they should have named this standard MMXII.
Jeezus christ (Score:5, Funny)
If I wanted plastic scissors I'd use Java. Give me my scalpel back.
Re:Jeezus christ (Score:4, Funny)
Too many people have been randomly slicing people.
I don't get it... (Score:2, Insightful)
Re: (Score:2)
If you want OOP and C go with C++ instead.
C is supposed to be a high level assembly language, so simplicity and brevity are key.
I find that Objective-C is pretty nice to. It is a very strict super-set of C that adds some OOP functionality and is no where near as complex as C++, in fact it is just a library or two sitting on top of a C compiler to interpret the OOP syntax. It is a shame that it is so tightly bound to Apple products.
Re: (Score:3)
Objective C, like Smalltalk, has an issue with construction and destruction: Overridden methods use the sub/derived version if called during the execution of the super/base class constructor. This means writing a sub/derived class has the potential to break the already-debugged super/base class constructruction, which must be rechecked for every sub/derived class.
C++ gets this ALMOST exactly right: Base class constructors get the base class version, derived class constructors get the derived class versio
Re: (Score:2)
I see.
Well, as far as a little OOP in C goes, what I have done is to create structures with whatever member data I need, and within those structures I place function pointers to emulate methods.
If you see yourself doing a lot of that you can create functions that return pointers to your makeshift structure-class.
Obviously you don't really get any advanced OOP stuff, but you can get simple inheritance using this method and a whole lot of encapsulation. If I'm not mistaken I think that C-family languages that
Re: (Score:3)
You don't have to use all the features the language offers to you, you know. It is absolutely possible to use C++ as "C with some objects".
Re: (Score:2)
It actually predates NeXT as well. XD It was developed by the founders of a company called Stepstone who originally licenced it to the NeXT company, then NeXT bought the rights to Objective-C and then Apple bought NeXT.
Re:I don't get it... (Score:5, Insightful)
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.
Re: (Score:3)
Because C is an ultra-clean procedural language.
Haha, ultra-clean is not a term I would apply to either C or its demon child C++. Speaking as someone who has written hundreds of thousands of lines of both.
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.
Re: (Score:3)
No, I don't think "the usefulness of potential features" should be considered, if you're talking about something like bolting object orientation onto C. As other people have said, that has already been done, several times. If you want object-oriented C, use C++ or Objective-C. If you want to go even further that direction, use C# or even Java. The difference between an object oriented language and a structured procedural language like C is significant. Or maybe you could explain a little more what you mean
Re: (Score:2)
There are however more stuff from C++ that could trickle back to C. Personally I'd like to see C inherit (pun intended) namespaces, better enums, default parameters values, and maybe templates from C++. C11 seem to have some basic template support in place at least, which is probably good enough.
Re: (Score:3)
So why don't you just use C++ then in the first place? No, I'm absolutely serious. You can basically take your existing C code and compile it with a C++ compiler in C++ mode, and with a very few exceptions it will compile and work just fine. Then you can start adding just those C++ features you want; no back-porting to C necessary.
I mean, that was the WHOLE IDEA of C++ right from the beginning. There's nothing that says you need to use a single class in C++.
Re:I don't get it... (Score:4, Interesting)
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.)
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
Re: (Score:3)
What features do you want?
Automatic memory management? Isn't this what makes C++ so fucking insanely complex?
No. Have you ever used C++?
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.
Who needs threads? (Score:4, Insightful)
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
Re: (Score:2)
I've never been a fan of putting multi-threading/multi-tasking in a programming language.
This is probably to promote and facilitate the use of C on multi-core machines, but I haven't RTFA.
Re: (Score:3)
You will still be able to use one or the other. In some implementations you may be able to leverage both facilities (like using _Thread_local storage qualifiers in code that otherwise uses posix threads).
Re: (Score:3)
GCC and Clang/LLVM may support using _Thread_local with a pthread, but some other compiler you may need to use (for some strange reason) might not and then you would need to do a lot of work to get things going with that compiler.
It's a pet peeve of mine when I see a lot of mixed standards... If you're going to use pthread, use pthread. Don't try to mix it w
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]
Mod up! (Score:2)
Give this man some points! He has it exactly right.
Adds Rock music support (Score:3)
cause this language goes to 11
*puts on sunglasses*
Bullshit (Score:4, Insightful)
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.
Multithreaded support (Score:2)
I'd like an updated K&R please! (Score:2)
R no more (Score:2)
C99 not a success? (Score:2)
Bah, Humbug! (Score:4, Funny)
Re: (Score:3)
Re: (Score:2)
If this version is P, then when will L finally come out?
Re: (Score:2)
Re: (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:Slow Adoption of Current Standards (Score:5, Informative)
Blame Microsoft, not the standards committee.
GCC had it ahead of time.
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, Insightful)
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.
Re: (Score:3)
Of course, the "safer" C library string functions are already supported by Visual Studio because they're part of Microsoft's cargo-cult approach to security. You know, the one where they're so busy making everyone rewrite all their existing code to new APIs that they don't think about little details like whether it's a good idea to hand out Microsoft certificates which have code-signing permissions for no real reason and can be used to sign fake Windows updates to anyone and everyone. And where they don't b
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:5, Interesting)
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.
Re: (Score:3)
"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."
Err, C++ vtables require a double pointer dereference - the C version requires 1. That alone is a good enough reason not to use C++. Aside from that when you;re writing an OS you want to know exactly how your memory is set up and used, not hope the compiler doesn't fuck something up when it tries to get clever
Re: (Score:3)
Why do people keep modding up this old, tired tripe.
Just about everything in the article is either correct and very out of date (amazingly, the world of C++ has changed in the last 20 years) or was never true in the first place.
Re: (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: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: (Score:3)
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.
Well, it already has all common math operations on floating point numbers as part of the standard language/library. Quite obviously, any vector operation can be implemented as a simple loop over the elements invoking the corresponding (already standard) scalar operation. Making them better optimized would then be a quality of implementation issue. Making this standard would mean that people could write portable code that works faster on compilers with special support for it, but still works correctly (and n
Re: (Score:3)
Quite obviously, any vector operation can be implemented as a simple loop over the elements invoking the corresponding (already standard) scalar operation. Making them better optimized would then be a quality of implementation issue. Making this standard would mean that people could write portable code that works faster on compilers with special support for it, but still works correctly (and no slower than corresponding code with explicit loops) everywhere else.
I believe the idea was that restrict pointers would help the compiler discover where it can transform existing code to use vectors.
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:Missing features (Score:4, Interesting)
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.
Re: (Score:3)
Oddly enough all the _s crap seems to be driven by Microsoft. They proposed them, then modified their compiler to complain if you did not use them and instead used strcpy, etc. This includes functions such as snprintf which are *identical* to the _s versions, and a "safe" version of fopen that only checks if the FILE* argument is non-null (WtF?). For some reason no WIN32 api that could overflow buffers got a "_s" version and there was no warning for using them! The purpose appeared to be to piss off program
Re: (Score:3)
At its core, C is designed to be a sort of portable assembly language.
No, it was designed as a replacement for assembly language. There's a difference.
Most of its original features were intended to map directly to PDP-11 opcodes
This is a myth. Most of C's original features are inherited or evolved from its predecessor languages.
http://cm.bell-labs.com/who/dmr/chist.html [bell-labs.com]
Unfortunately, it hasn't really kept up with the improvements in modern instruction sets.
C has never had any direct support for the instructions of any particular machine architecture. In this, of course, it is in good company with virtually every other non assembly language because, not being assembler, you wouldn't expect it to have direct support for any particular m