
ISO updates C Standard (Now we have C11) - kzrdude
http://www.h-online.com/open/news/item/ISO-updates-C-standard-1400814.html
======
kia
Here are major C11 Standard changes:

    
    
      - standard multithreading support (<threads.h> header)
      - atomic operations (<stdatomic.h> header)
      - type-generic macros (sqrt translates to sqrt, sqrtf, sqrtl depending on argument type)
      - Unicode support (char16_t and char32_t types)
      - gets function is removed from the standard (use gets_s)
      - static assertions
      - aligned memory allocation (aligned_alloc)
      - anonymous structures and unions
      - no-return functions (specify functions that never return)
      - exclusive access for opened files ("x" in fopen)
      - macros to create complex numbers
      - additional way to terminate the program (quick_exit and at_quick_exit)

~~~
radarsat1
> exclusive access for opened files ("x" in fopen)

Wouldn't this need to be a service provided by the operating system? How can
it be part of the standard? Or is it just that the standard prescribes that
"x" must work if the operating system allows it.

I know Windows usually defaults to exclusive access, but in practice do any
unix-like systems provide exclusive access for file read? Just wondering since
I've never requested exclusive read access in my Linux programming.

~~~
jlarocco
Yeah, it requires OS support, but it's no different than most of the standard
library. Opening files, writing to files, printing to the console, allocating
memory, etc. all require OS support, too.

As to how it can be implemented, "man 2 open" on OSX shows O_EXLOCK and
O_SHLOCK flags, and they're from BSD. Not sure if they're POSIX, but I'd bet
Linux has something equivalent. And there's also the flock() function. My
guess is the new "x" option to fopen can be implemented using O_EXLOCK and
flock(), though I'm too tired to look up details on how it could be done.

~~~
kzrdude
It should be just O_EXCL, which is POSIX.

------
wnoise
And they _still_ haven't adopted the C++ const-correctness rules (for pointers
to pointers to ...), which really do help in writing correct code, and correct
code that has flavor of C89.

~~~
erydo
What? C has those const rules. The type "int const* const*" is valid C.

The differences are primarily that in C you can't use a const symbol in a
place where a constant expression is expected (e.g. initializing another
const, or a statically sized array).

But you can absolutely do const-correct code in C.

~~~
wnoise
It has _a_ set of const-correctness rules. They're much simpler than the C++
rules. While they handle the simple cases perfectly well, they forbid some
assignments that really can't get you in trouble, and would be quite useful in
practice. In particular, while "int const * const * " exists, it can't be
assigned from an "int * * ", even though this is sound. This makes it hard to
write const-correct functions handling 2-d arrays.[1] kzrdude's link shows how
they have to rule out certain constructs that are not obviously wrong. It
doesn't explain how the C++ assignment compatibility rules allow more, while
still being sound, but that's a bit much to expect from a C FAQ, particularly
as the C++ rules are somewhat involved. (I can't find a decent reference that
explains the rules well. I found one about six months ago, but didn't save it,
as I don't professionally use C++.)

[1]: Preemptive pedanticism: Yes, there are difference between C arrays and
pointers, the expression types merely decay in the right contexts. But if I'm
using [] to dereference, they're being used as arrays.

------
frou_dh
For personal projects, I'm going to try and use ANSI C89 forever. I know this
isnt especially rational but it's somehow appealing to stick with a small(er)
and more historic version.

~~~
haberman
I think that <stdint.h> is a C99 feature worth using -- otherwise each project
has to redefine eg. myuint32_t over and over again. Colossal waste of effort
and namespace pollution.

~~~
TheNewAndy
Most of the time you don't actually care about the exact size of your integer
types (especially for signed integers).

At work, we use C90 with a few C99 extensions which can be disabled through
the preprocessor (e.g. inline, restrict) and although we stared out with a
stdint.h like thing, it is proving to be less useful.

------
Apocryphon
I'm still disappointed that K&R never released a third edition.

------
xxiao
nice. would like to find out all the new stuff in some blog/books before I had
to read the standard itself, plus the status of toolchain supports of them(gcc
seems only support part of the new standard)

~~~
Kliment
You have to pay money to even look at it. That makes supporting things
difficult.

~~~
bchjam
at least you can read the draft

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf>

~~~
Kliment
Wow, I missed that that one was free. Thank you!

~~~
eschaton
This is often the case with language and file format standards: The working
group drafts are free, and the standard is just an approval-without-change of
the final draft.

