
C11, yo - reirob
http://lcinexile.blogspot.fr/2012/12/c11-yo.html
======
angersock
I support a lot of the language cleanup, but goddamnit can we either a.) bring
pitchforks to Redmond to get proper VS support, b.) bring pitchforks to
$CLANG_DEV_LOCATION to get proper Windows support for Clang thus obviating the
need for a, or c.) write some shims so that C11-ish features are available in
Windows.

:(

There is a world outside of Linux and mobile.

~~~
udp
There is indeed a world outside of Linux and mobile, and most of that world
doesn't have a problem working with C99 and C11. Windows is - as with many
other things - the exception, and it's getting tiresome.

There's no way Windows developers are going to stop using Visual Studio - and
rightly so, because it's a very good IDE. So there are basically three things
Microsoft could do to resolve this situation and let Windows developers make
use of modern C code:

1\. Update their C89 compiler to a newer C standard. This is unlikely, and
probably a lot of work for Microsoft (I'm guessing they'll be removing the C
compiler from one of the next releases of Visual Studio).

2\. Add support for essential C99/C11 features to their C++ compiler, such as
designated initializers. This would still force us to compile our C as C++ and
do nasty things like casting the return type of malloc, but it might be the
easiest solution.

3\. Switch to a modern, open source C compiler like Clang. I would be very
surprised if Microsoft would do anything like this (else IE would be using
WebKit already).

So we're basically forced to either butcher our C code to make it compile as
C++, or write C89. Or drop MSVC support, making our projects difficult for
Windows developers to work with.

~~~
norswap
Or choose the path of least resistance and use C++. Even if it is C-like C++.
Not that I wouldn't like to have MS to support C99 and C11 though.

~~~
jlarocco
That may work for developers writing their own projects on Windows, but
presents a problem when using other people's code.

Not many developers on Linux and OSX are going to hold out on using new
features just to coddle Windows users.

~~~
norswap
So Linux does not have C++ those day? (Just kidding.) But C++ definitely
matches C feature for feature, even tough the way or doing things are not
always the same.

------
buster
As someone who just started playing around with C++ after many many many years
of absence, i must say i am surprised how well it goes. I love the new "auto"
keyword for variable declarations. I had a hard time to get into pointer
arithmetics again but it's slowly coming back.

Also i took this opportunity to use LLVM/clang, Qt5, Qt Creator and all in all
i'm really surprised. I thought everything would be much more cumbersome, i'd
have to dig through terrible error messages or reinvent basic stuff on my own,
but so far the stdlib and Qt offer what i need.

If you're like me amd avoided C/C++ like the plague, i'd suggest you try again
next time, it may not be as bad as you remember :P

~~~
archangel_one
Just FYI: this article is about C11, not C++11. It was easier in the past when
their revisions came in different years ;-)

~~~
buster
I know, but it's slightly related :P

------
jstanley
"Variable-length arrays, alone, would save a tremendous amount of time and
energy"

That is, until you overflow the stack with no way to know if that's going to
happen and no way to recover if it does.

~~~
Someone
Firstly, that can happen with fixed-length arrays or even without arrays, too.

Secondly, I don't have access to the official standard, but it would surprise
me if it required VLA's to be stack allocated. That would give implementers of
the language too little leeway.

In fact, I see no clear reason why the standard would mention the word 'stack'
at all. A quick check of the candidate PDF of the standard seems to confirm
that, but that's not the real standard, and it may be a shortcoming of the iOS
PDF reader.

------
Aardwolf
I don't really see how variable length arrays save time? Those seem like a
feature that belongs in C++ but definitely not in C imho.

However, what I like to see in C are "//" style comments, declaring variables
at other places than start of scope, the integer types with bit size
specified, etc...

But the VLA's? They're created on the stack, right? So you'd need malloc for
large ones anyway.

What actually would save time (for the coder of course) in C, imho, would be a
way to automatically clean up resources no matter where you exit a scope or
function. Something like destructors do in C++. E.g. if you could type
something like "onleave free(myresource);" which would execute what you type
after "onleave" whenever the scope exits.

~~~
cjh_
Regarding your 'onleave' idea; go has a similar construct called defer [1], it
is exactly what you are talking about and (imo) is a really elegant way of
dealing with cleanup.

[1]<http://golang.org/doc/effective_go.html#defer>

------
comex
I love $new_C_stuff, but variable-length arrays are generally a security hole
waiting to happen. Be very careful before using them.

~~~
eridius
What do you mean by that? All I can think of is taking user-supplied input as
the length of the VLA, but I would hope anyone using VLAs are not stupid
enough to think that giving the user control over the size of their stack
frame is a good idea.

~~~
comex
I'd say that most of the time when you want an array whose size is variable,
the size relates in some way to user input. Your mileage may vary.

------
drv
"All the major C compilers have committed to implementing these features":
including MSVC, which doesn't even implement C99?

"Static compile-time assertions allow the use of sizeof() and friends" could
already be done with the preprocessor and typedefs; see e.g. C_ASSERT:
[http://msdn.microsoft.com/en-
us/library/windows/desktop/ms67...](http://msdn.microsoft.com/en-
us/library/windows/desktop/ms679289\(v=vs.85\).aspx) It will still be nice to
have a standard way to do it, though.

~~~
brigade
Microsoft doesn't consider themselves a C compiler vendor. They only ship a C
compiler because they shipped a C compiler.

Really, I think we'd be better off if they actually removed it from future
toolkit releases. That way no one would be confused into thinking that
Microsoft supported C.

------
tytso
Unfortunately, Variable Length Arrays (VLA's) are optional in C11. So use of
VLA's may lead to portability problems, especially if you care about your code
getting compiled on minority compilers.... such as MSVC.

For this reason I'm not planning on allowing the use of C11 features in
e2fsprogs, because I know there are people compiling libext2 so they can
access ext[234] filesystems using FUSE on Windows (and MacOS, but MacOS is at
least using a reasonable compiler).

------
cpeterso
Why are C11's char16_t and char32_t simply typedefs for uint16_t and uint32_t
instead of new distinct types? C++ needed a distinct char16_t type so
functions could be overloaded for both char16_t and uint16_t. I guess the C
standards committee wants to ease char16_t adoption for code that is already
using uint16_t for UTF-16.

------
pascal_cuoq
Variable length arrays:

If, because of parameters outside the programmer's control, a call to malloc()
fails to allocate an array of n doubles, it returns NULL.

If, because of parameters outside the programmer's control, the variable-
length definition “array double arr[n];” fails to allocate an array of n
doubles, the behavior is undefined.

Your choice.

~~~
popee
How do you "allocate" memory on stack? You can always do 'double
arr[huge_constant]' and, depending on resources, overflow heap data. Or with
recursion. Damn those bugs >:-)

The thing about C is that programmer should do check size before calling
function with double arr[n]. Isn't that point of C? On the other hand, user
can make fast stack allocation which, depending on situation, can be good.
Stack is insecure by default, OS should put it really far from other parts. In
embedded systems, well there you must always think about these kind of things.

Btw, how are (p)thread stacks implemented? Every thread has it's own stack,
that's ein interesting situation.

~~~
pascal_cuoq
> How do you "allocate" memory on stack?

I have no idea why you would be asking me this, unless you are quibbling over
the idiom associating the verb “allocate” and the complement “on the stack”,
in which case Google should be able to find you about 56000 uses, in context,
of this precise association.

> The thing about C is that programmer should > do check size before calling
> function with double arr[n]. > Isn't that point of C?

What part of “because of parameters outside the programmer's control” do you
not understand? What limit, in a portable C program, do you check the value of
n against before allocating a VLA of size n?

------
huhtenberg
No computed goto's :-/

------
lmm
>which drives coders away from C, which harms (a different type of)
portability.

I'd say writing as much code as possible in other languages (whether guile or
perl/python/ruby/java/...) improves portability. C code tends to be less
portable than that written in higher level languages.

~~~
EliRivers
I disagree. C compilers are everywhere. A C compiler is the standard tool
expected (and provided) with every embedded processor I've ever worked with.
As a rule of thumb, if a microprocessor is meant to be user-programmable, you
get a C compiler with it. It will be a long time before I get a Ruby
interpreter for a blackfin processor.

~~~
lmm
You get a C compiler sure, but will a given C program work on it?

Maybe not for ruby, but I'd certainly expect most new processors to run Java.
A quick search suggests there are ruby interpreters for blackfin - and if you
have a ruby interpreter you can be reasonably confident any given ruby program
will behave correctly on it.

~~~
tobiasu
There is a bare-metal ruby cross-compiler?

Or are you talking about the ruby interpreter written in C running on an OS
written in C?

Java is available? Again are we talking about a bare-metal Java compiler
(possibly supported by hardware being able to execute a subset of Java
natively), or the large collection of software written in C and C++ that is
supplied by Oracle?

~~~
lmm
Ruby interpreter written in C running on an OS written in C.

No this is not inconsistent; I said move as much code as possible away from C.
That which is impossible to move has to stay in C (and will probably be
responsible for 99% of the headaches when porting to a new architecture).

