Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

A New C Standard Is On the Way

samzenpus posted more than 2 years ago | from the new-guidelines dept.

Programming 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."

cancel ×

305 comments

Oh! (-1, Redundant)

omar.sahal (687649) | more than 2 years ago | (#40444607)

Not seen this but looking forward to it!

Hmm (2, Funny)

mholve (1101) | more than 2 years ago | (#40444631)

No wonder they're not popular. C99? C11? It should be "C... X!" :p

On the way? (5, Informative)

TheRaven64 (641858) | more than 2 years ago | (#40444653)

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.

Re:On the way? (2, Funny)

Anonymous Coward | more than 2 years ago | (#40444861)

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:On the way? (1, Redundant)

shutdown -p now (807394) | more than 2 years ago | (#40445219)

You'd think people would have figured that from it being called C11, too...

Re:On the way? (5, Funny)

Tough Love (215404) | more than 2 years ago | (#40445977)

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? (5, Insightful)

shutdown -p now (807394) | more than 2 years ago | (#40446149)

This being C, 11 would mean that you can turn the volume from 0 all the way up to 10.

Re:On the way? (5, Funny)

Bacon Bits (926911) | more than 2 years ago | (#40446399)

No, you can turn the volume up as high as you want, but it's only defined for 0 to 10.

D? (1)

Anonymous Coward | more than 2 years ago | (#40444673)

Is that finally D?

Re:D? (2)

chinton (151403) | more than 2 years ago | (#40444721)

No, it's finally P.

Re:D? (1)

sconeu (64226) | more than 2 years ago | (#40445269)

If this version is P, then when will L finally come out?

Re:D? (1)

viperidaenz (2515578) | more than 2 years ago | (#40445597)

pseudo methamphetamine?

just great (-1, Redundant)

sci-fi fantasies (2670099) | more than 2 years ago | (#40444689)

I program i C++. I do not mean the parentheses :p,just little blocks.So does that mean I now have to program in C11 on http://scratch.mit.edu/ [mit.edu] ?

C11???? (5, Funny)

highphilosopher (1976698) | more than 2 years ago | (#40444703)

That's great! I'm still using C4, and every time I compile my code blows up!

Re:C11???? (2)

jd (1658) | more than 2 years ago | (#40444925)

I hear C5 was dog-slow and users suffered humiliation.

Re:C11???? (5, Funny)

Anonymous Coward | more than 2 years ago | (#40444951)

Plus, as using C-14, I am able to determine the compiling date of any given code.

Re:C11???? (0)

Anonymous Coward | more than 2 years ago | (#40445025)

--insert ~ath comments here--

Re:C11???? (1)

freeze128 (544774) | more than 2 years ago | (#40445027)

C11 is a stupid name. They should call it C02.

Re:C11???? (3, Informative)

Imagix (695350) | more than 2 years ago | (#40445865)

Uh, why C02 when is was standardized in 2011? The headline is simply wrong. C11 isn't "On the way". It's already here, and has been here for > 5 months. You _might_ have an argument for C0B. (Long-running joke. C++0x was the next C++ standard, and there was a joke that they hoped that the x wasn't going to be a hex digit....)

Re:C11???? (4, Funny)

GoodNewsJimDotCom (2244874) | more than 2 years ago | (#40445063)

I am still using the programming language made a long time ago C3PO. You'd be surprised how similar it is to Jawa.

Re:C11???? (3, Funny)

idontgno (624372) | more than 2 years ago | (#40445363)

It's really only useful for controlling 'vaporators and binary loadlifters.

Re:C11???? (2, Funny)

Anonymous Coward | more than 2 years ago | (#40445371)

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???? (5, Funny)

Sduic (805226) | more than 2 years ago | (#40446389)

The worst part was the C4 standard was prepared with SemTeX.

Slow Adoption of Current Standards (1)

otterpop81 (784896) | more than 2 years ago | (#40444705)

I wish new standards could be adopted more quickly. In Visual Studio it wasn't until 2010 that I could even get basic C99 headers like stdint.h.

Re:Slow Adoption of Current Standards (4, Informative)

JustNiz (692889) | more than 2 years ago | (#40444763)

Blame Microsoft, not the standards committee.
GCC had it ahead of time.

Re:Slow Adoption of Current Standards (0)

ackthpt (218170) | more than 2 years ago | (#40445139)

Blame Microsoft, not the standards committee.
GCC had it ahead of time.

Takes Microsoft longer because they have not only the compiler to think about but all your friendly (annoying) pop-up help on everything

Plus, give Steve Balmer a chance to give the dev team a pep talk and an Executive Chair Toss

Re:Slow Adoption of Current Standards (5, Informative)

Anonymous Coward | more than 2 years ago | (#40445117)

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 (5, Informative)

shutdown -p now (807394) | more than 2 years ago | (#40445249)

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 (2, Informative)

Anonymous Coward | more than 2 years ago | (#40445357)

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.

Drops the most important feature of C99 (5, Interesting)

Anonymous Coward | more than 2 years ago | (#40444719)

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:Drops the most important feature of C99 (1)

shutdown -p now (807394) | more than 2 years ago | (#40445263)

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 (3, Funny)

Tough Love (215404) | more than 2 years ago | (#40445921)

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 (3, Informative)

shutdown -p now (807394) | more than 2 years ago | (#40446123)

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:Drops the most important feature of C99 (2, Interesting)

Anonymous Coward | more than 2 years ago | (#40446397)

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:Drops the most important feature of C99 (1)

Tough Love (215404) | more than 2 years ago | (#40445875)

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:Drops the most important feature of C99 (1)

Anonymous Coward | more than 2 years ago | (#40446381)

Because it's no longer standard it won't be permitted under some government contracts, it's going to make my life suck a lot more starting next yet. :(

Re:Drops the most important feature of C99 (3, Interesting)

Anonymous Coward | more than 2 years ago | (#40446049)

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 mention that not even Microsoft supports the API. The Win32 precursor to Annex K is incomplete and inconsistent. In other words, Annex K is dead in the water. Microsoft won't support it, and the BSD and GNU libc take completely different approaches.

Integer overflow! (5, Funny)

Montreal (594947) | more than 2 years ago | (#40444745)

C99 -> C11, come on guys ...

Re:Integer overflow! (1)

Anonymous Coward | more than 2 years ago | (#40444815)

ASCII code 99: c
ASCII code 11: Mars symbol

[feminist conspiracy theorist]Clearly this is a sign that the C++ standards committee is biased against womyn!

Re:Integer overflow! (1)

Anonymous Coward | more than 2 years ago | (#40445897)

C revision naming is non-Y2K compliant!

Re:Integer overflow! (2)

Tanktalus (794810) | more than 2 years ago | (#40446135)

It should at least have been C111

Re: (2)

bleedingsamurai (2539410) | more than 2 years ago | (#40444779)

The multi-threaded stuff sounds nice. But bounds checking, really? How difficult is it to check buffer size before copying?

Re: (4, Insightful)

hawguy (1600213) | more than 2 years ago | (#40445175)

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: (1)

bleedingsamurai (2539410) | more than 2 years ago | (#40445377)

I blame the programmers not the language.

I don't even have to think about doing it. Often times it is as simple as an additional if statement to check the size of your source and destination buffers. If the destination buffer is smaller, just don't do the copy.

Re: (4, Insightful)

turbidostato (878842) | more than 2 years ago | (#40445577)

"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: (0)

bleedingsamurai (2539410) | more than 2 years ago | (#40445823)

If it is such a problem, go use another language. One that does all the thinking for you.

Re: (1)

turbidostato (878842) | more than 2 years ago | (#40445899)

"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: (0)

Anonymous Coward | more than 2 years ago | (#40446095)

I do use a different language. Why don't you tell all those people using C to switch to a different language?

Given your responses I wonder if you really can think well enough to use C safely (and do so consistently).

If it's so simple to check the bounds size before copying, why not have the language+compiler do it by default when necessary? Because you like to type extra lines?

Re: (1)

viperidaenz (2515578) | more than 2 years ago | (#40446309)

That's a great way to hide bugs, not fix them. If the inputs are not as expected then the result should be failure, not nothing. hence the concept of exceptions and exception handling.

multithreading is too little, too late (1)

Anonymous Coward | more than 2 years ago | (#40445253)

multithreading support was desperately needed 15+ years ago. But now low-level multithreading model doesn't scale, and we actually need more distributed parallel processing features. Extension libraries, such as posix, can fill in support for multithreading for those rare cases where it is worthwhile. (where you need concurrency, but not a lot of concurrency)

bounds checking on the otherhand lets a programmer take advantage of information the compiler often already has available. Although I would argue that simple bound checking is too small, and would like for a full set of formal verification extensions standardized for C.

Re: (1)

shutdown -p now (807394) | more than 2 years ago | (#40445309)

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: (1)

JustNiz (692889) | more than 2 years ago | (#40445369)

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: (2, Insightful)

bleedingsamurai (2539410) | more than 2 years ago | (#40445541)

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: (0)

Anonymous Coward | more than 2 years ago | (#40445693)

Where did he say it is possible to create a program that doesn't involve buffers? Way to deliberately misinterpret what he is saying.

What he is saying is that given the right language, buffer handling is done for you, drastically decreasing the numerous security flaws attributable to wrong buffer sizes, which is fairly common in C. Stop being obtuse in an attempt to be a pedantic troll.

Re: (1)

JustNiz (692889) | more than 2 years ago | (#40446113)

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: (2)

JustNiz (692889) | more than 2 years ago | (#40445987)

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: (1)

bleedingsamurai (2539410) | more than 2 years ago | (#40446367)

Some how you went from "buffer" to "dynamically allocated memory" which although related is not one and the same. I'm sure you can figure out how too look up the definitions of both and see that there is a difference.

I'll admit I misinterpreted what you wrote.

But here is the problem with strncpy() and similar functions it only reads so many characters. So if you are in a situation where more is being written into a buffer then is there;
1) your string isn't actually a string because it isn't null-terminated.
2) it is actually more work for you to implement the handling of the error, I can't think of too many situations where not having the whole string is useful. By explicitly checking buffer size, I can adjust my destination buffer to include enough space for the whole string and not loose any data OR if it is such a hideous problem I can simply exit() or return right then and there in fewer lines of code that are easier to read. At which point why even bother using strncpy() if I'm already checking buffer size manually?

hrmph... (1)

logicassasin (318009) | more than 2 years ago | (#40444781)

All the fuss over C, yet there's still no "H" programming language...

Re:hrmph... (0)

Anonymous Coward | more than 2 years ago | (#40444971)

All the fuss over C, yet there's still no "H" programming language...

But there is a Ch [wikipedia.org] programming language...

Re:hrmph... (1)

jd (1658) | more than 2 years ago | (#40444993)

Personally, I think they should have named this standard MMXII.

Jeezus christ (5, Funny)

JustNiz (692889) | more than 2 years ago | (#40444789)

If I wanted plastic scissors I'd use Java. Give me my scalpel back.

Re:Jeezus christ (4, Funny)

arkane1234 (457605) | more than 2 years ago | (#40445365)

Too many people have been randomly slicing people.

Schools (1)

Murdoch5 (1563847) | more than 2 years ago | (#40444801)

It's time for school's to update what they teach for standard C, Even after C99 was released and C11 I had profs teaching C89, I think school's should follow suite with industry and upgrade.

Re:Schools (1)

Anonymous Coward | more than 2 years ago | (#40444853)

Your school should also teach the proper use of apostrophes.

Re:Schools (0)

BenoitRen (998927) | more than 2 years ago | (#40446035)

Did you also have professors that taught you to abuse the apostrophe?

Re:Schools (0)

Anonymous Coward | more than 2 years ago | (#40446293)

I believe the idiom is "follow suit", not "follow suite". I have no idea what "follow suite" is supposed to mean.

A certain well-known coder will dump all over this (-1)

Anonymous Coward | more than 2 years ago | (#40444803)

as the stupidest standard ever, on kerneltrap.org. 3... 2... 1...

Re:A certain well-known coder will dump all over t (0)

Anonymous Coward | more than 2 years ago | (#40444873)

0... and... ...[crickets chirping]

I don't get it... (2, Insightful)

xor.pt (882444) | more than 2 years ago | (#40444823)

Why didn't they include some simple OOP features aswell? I understand this is a language for low level programming, and needs to be close to the metal, but many OOP features don't carry any significant overhead, and could just be avoided anyway.

Re:I don't get it... (2)

bleedingsamurai (2539410) | more than 2 years ago | (#40444875)

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:I don't get it... (1)

xor.pt (882444) | more than 2 years ago | (#40445041)

I would like _some_ OOP with C, C++ has too much, if I can frase it that way. GObject, Objective-C, Vala are good examples of projects trying to fill that gap but they come with their own set of drawbacks.

Re:I don't get it... (2)

bleedingsamurai (2539410) | more than 2 years ago | (#40445337)

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 support OOP actually do something like this behind the scenes.

I guess I wouldn't mind a smidgen of OOP in C as long as they implement it through a library and not directly into the core language.

Re:I don't get it... (2)

shutdown -p now (807394) | more than 2 years ago | (#40445341)

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:I don't get it... (1)

BenoitRen (998927) | more than 2 years ago | (#40446105)

I don't find Objective C to be nice at all. It's a very ugly hack and I despised working with it.

Re:I don't get it... (1)

Bing Tsher E (943915) | more than 2 years ago | (#40446201)

Back in about 1995 the Slackware distros included a complete Objective-C build environment as a set of packages. That's where I first saw it. It was presented as a parallel option of about the same size and significance as the plain vanilla C build environment. How it turned into an Apple-owned deal I don't understand. It's from NeXT, isn't it? (almost everything good from Apple comes from outside the Infinite Loop)

Re:I don't get it... (2)

bleedingsamurai (2539410) | more than 2 years ago | (#40446527)

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... (4, Insightful)

jd (1658) | more than 2 years ago | (#40444975)

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:I don't get it... (1)

xor.pt (882444) | more than 2 years ago | (#40445615)

Shouldn't the usefulness of potential features be considered aswell? This purity you speak of could just as easily be disturbed by the features added with C11, which are also present in other programming languages.

Re:I don't get it... (2)

PCM2 (4486) | more than 2 years ago | (#40445745)

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 by "some OOP." You seem to be arguing that C gives you nothing but C++ gives you too much -- but complaining that a language gives you too much of exactly what you're asking for is a pretty confusing way to make your case.

Re:I don't get it... (1)

pipatron (966506) | more than 2 years ago | (#40446231)

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:I don't get it... (2)

Tough Love (215404) | more than 2 years ago | (#40445807)

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... (0)

Anonymous Coward | more than 2 years ago | (#40446193)

If you're using a large C code base you can just use structs and function pointers like everyone else.

I suspect, though, due to the way you are writing and asking the question, that you've never worked on a large C code base (which if they know what they are doing are already taking the good ideas from OOP methodology - but don't need the "class" keyword as a mental crutch).

Missing features (1)

Anonymous Coward | more than 2 years ago | (#40444867)

vector types:
I don't mean c++ vectors, I mean opencl like vectors. float4, double2, etc... and vectorized versions of the standard math libraries sin, cos, etc... So you can do true cross compiler, cross platform, and cross cpu vector programming.

closures:
In corporate Clang blocks [llvm.org] . They are just so useful.

Re:Missing features (5, Informative)

AuMatar (183847) | more than 2 years ago | (#40445099)

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:Missing features (2)

shutdown -p now (807394) | more than 2 years ago | (#40445395)

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 no slower than corresponding code with explicit loops) everywhere else.

It doesn't even require any new language features, just libraries. Just add float4 etc as structs, and define standard library functions for all operations including arithmetic. Let compilers implement them as intrinsics where that makes sense.

Maybe it doesn't make sense as part of the core standard, but it would make for a good TR.

Re:Missing features (2)

tepples (727027) | more than 2 years ago | (#40445795)

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 (3, Informative)

shutdown -p now (807394) | more than 2 years ago | (#40445907)

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 (0)

Anonymous Coward | more than 2 years ago | (#40445835)

C runs on way too many devices without floating point support to add those as standard libraries.

Then how is it that C can support float, double, complex float and complex double (along with the associated standard libraries), if it runs on "way too many devices without floating point". I don't see why it's such a big deal to add vector types.

On platforms without vector instructions, the compiler fails back to scaler versions, then on platforms without floating point, the scaler floating point is then emulated using integer instructions. Or you just don't use that feature if your platform doesn't support it. There is no reason to hamstring the language because of that.

Re:Missing features (0)

Anonymous Coward | more than 2 years ago | (#40446481)

It wouldn't be useful on many platforms.

Only useful on x86, arm, ppc, sparc... but who uses those?

Who needs threads? (3, Insightful)

spaceyhackerlady (462530) | more than 2 years ago | (#40445223)

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:Who needs threads? (1)

Monkey-Man2000 (603495) | more than 2 years ago | (#40445259)

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:Who needs threads? (0)

Anonymous Coward | more than 2 years ago | (#40445559)

Consistency checking, probably. The article mentions a new atomic type qualifier and a thread local storage class.

Re:Who needs threads? (2)

moogla (118134) | more than 2 years ago | (#40445663)

They standardized the naming convention of thread primitives for C11-compliant compilers and C-libraries. The system can still use posix threads under the hood, but now there is a <threads.h> intended to be forward compatible that you can leverage.

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:Who needs threads? (2)

Jerslan (1088525) | more than 2 years ago | (#40446101)

Yeah, but you really should try to code for a single standard... Mixing them because one or even most implementations support it is bad juju IMHO.

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 with something else just because you think you can (or your compiler lets you). Even if the new threads.h is just an abstraction layer on top of pthreads, it's best to stick to the threads.h method calls if you go that route. Mixing calls can sometimes lead to unexpected results.

Re:Who needs threads? (5, Informative)

Mr Thinly Sliced (73041) | more than 2 years ago | (#40446317)

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]

Adds Rock music support (2)

PaddyM (45763) | more than 2 years ago | (#40445305)

cause this language goes to 11
*puts on sunglasses*

Header files dependency (0)

Anonymous Coward | more than 2 years ago | (#40445519)

What about solving header [hell] dependency in the new C standards ?

Bullshit (3, Insightful)

Tough Love (215404) | more than 2 years ago | (#40445707)

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 (1)

slasho81 (455509) | more than 2 years ago | (#40445957)

Nothing says irrelevant standard like having standardized multithreading support on year 2011.

I'd like an updated K&R please! (1)

Zaiff Urgulbunger (591514) | more than 2 years ago | (#40446331)

I'd like an updated "The C programming language", although not necessarily by K and almost certainly not R! 'cos otherwise, I'll wind up buying some other book and I'll hate it because it's not as nice as K&R. And then I'll be all cross. :(
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...