

The Great C Runtime Refactoring - twoodfin
http://blogs.msdn.com/b/vcblog/archive/2014/06/10/the-great-crt-refactoring.aspx

======
aktau
All very well, but I'd be really happy once (if) we ever get proper C99
support in MSVC. We basically need that at the neovim project if we want our
code to compile with MSVC. We don't want to compromise either, by for example
compiling as C++ and not using some C99 features (we do use compound literals,
we don't cast from void pointers, et cetera). The CRT improvements in MSVC
2013 and 2014 are a step, but only a small one. Sadly, compiling as C forces
some kind of old mode where we can't even use declare-anywhere. For now, it
seems like we'll need to let MingW and its offspring do it. Does anyone have a
workaround?

~~~
bluecalm
Is there any problem with MinGW ? From my very limited experience gcc is just
a better compiler than MSVC: it generates faster code, has more options to
configure it (more optimization options, more options for displaying warnings,
all the new floating point stuff available, actually supports new standards
and let you choose which language version you want etc.).

~~~
stinos
_it generates faster code_

Not sure if that is true in general - the few proper benchmarks I found
indicate that there is no clear winner. (Except for the Intel compiler, which
beats both)

~~~
bluecalm
Right. I am speaking from experience with relatively simple number crunching
code. It became faster once I upgraded to newer version of gcc. Now even very
simple things (like say 8 queens) are just 5-10% faster when compiling with
GCC 4.8 comparing to MSVC.

------
jasode
From the blog post: >We have eliminated most of the manual resource management
in the code through the introduction of several special-purpose smart pointer
and handle types. Enormous functions have been split into smaller,
maintainable pieces. We have eliminated 75%(2) of the conditional compilation
preprocessor directives (#ifdef, #else, etc.) by converting internal
implementation details to use C++ features like templates and overloading.

FYI... The author of the blog post (James McNellis) also has an excellent
video presentation that explains that paragraph in more detail.

[http://channel9.msdn.com/events/TechDays/Techdays-2014-the-N...](http://channel9.msdn.com/events/TechDays/Techdays-2014-the-
Netherlands/Modernizing-Legacy-C-Code)

------
malkia
I kind of joked here:
[https://news.ycombinator.com/item?id=7843301](https://news.ycombinator.com/item?id=7843301)
\- but now I can't really wait for it. This is huge! This means that once
major products pick up and develop their creative tools (Maya, MotionBuilder,
Photoshop, etc.) - plugin developers no longer have to ship for multitude of
CRT versions.

Also finally things like Python, Perl, etc. can stick on one runtime and not
care for a very long time.

Great stuff Microsoft! I really really can't wait for it. I don't care even if
no new C++ features are implemented - only this is that important.

------
nnq
Nice to see them talking about C99, even after they said the focus is only
C++... when for everybody else, the horizon is C11. Guess it's something along
the lines of "let's handicap a bit all open-source projects that want to
support Windows by forcing them to use an older language version that also has
platform specific gotchas, maybe even rewrite the runtime to add more platform
specific goodness"...

------
rogerbinns
I was expecting them to figure out symbol versioning (eg how glibc deals with
the similar problem). It isn't clear if they have done that, or instead are
hoping to always have backwards/forwards compatible code and data structures.

------
pjmlp
"We have converted most of the CRT sources to compile as C++, enabling us to
replace many ugly C idioms with simpler and more advanced C++ constructs. "

+1 I love it.

~~~
norswap
Do I smell irony?

~~~
pjmlp
Yeah, eventually people will have to accept that C is dead on Windows (Visual
Studio), unless Microsoft's management decides otherwise.

------
frik
I doubt that GCC (MinGW) will be able to use this. What a pitty.

MinGW relies on the CRT that ships with every Windows since Win95 (and Visual
Studio 6).

Microsoft could fix this situation by merging the CRT that ships with Windows
(the original one) and Visual Studio (the forked of version madness) together.
A simple Windows update for Windows NT 5.x+ would be great (of course it
should be backward compatible).

------
Karellen
"Before this refactoring, the sprintf functions, which write formatted data to
a character buffer, were implemented by wrapping the result buffer in a
temporary FILE object and then deferring to the equivalent fprintf function."

＊headdesk＊

~~~
cremno
That's actually common practice. Look at other libc implementations.

Even the original implementation did that:

[http://minnie.tuhs.org/cgi-
bin/utree.pl?file=V7/usr/src/libc...](http://minnie.tuhs.org/cgi-
bin/utree.pl?file=V7/usr/src/libc/stdio/sprintf.c)

[http://minnie.tuhs.org/cgi-
bin/utree.pl?file=V7/usr/src/libc...](http://minnie.tuhs.org/cgi-
bin/utree.pl?file=V7/usr/src/libc/stdio/fprintf.c)

