Hacker News Reader

Comment by waterlesscloud | Hacker News Reader

There's still a ton of C legacy code running on windows machines out there.

You say that like they are removing all C support. Unless that "legacy" code suddenly mutates to use C99 features that aren't in C++, it'll still compile in the future.

But will never be updated to include C99 features. Exactly.

Exactly what? C99 doesn't have any killer features that legacy code would need to "update" to. If a C89 program is working, adding unique-to-C99 features isn't going to magically make it better.

> Unless that "legacy" code suddenly mutates to use C99 features that aren't in C++, it'll still compile in the future.

Forcing legacy code to stay woefully out of date to support a single vendor's stubbornness, perpetually growing its maintenance burden as the rest of the world moves on. Hooray for the Microsoft way!

I have severals problems with this. 1) The implication that working legacy code needs to be modified to use C99 features lest it be "out of date". 2) The idea that the world is moving on to newer C standards. 3) The idea that legacy code is moving on at all.

C90 isn't going away, and it's not Microsoft's fault. Many C compilers still support 1st edition K&R style for a reason — old C code is going to stick around, and it's probably not going to change much, let alone in any way that needs C99 features.

Ad 1) If C99 (or C11) was supported, you could perhaps use C99/11's features to refactor parts of the legacy code into more elegant code than possible with C89 (and yes, there are sometimes good reasons not to use C++).

Ad 2) If there is support for features there will be people using them.

Right but not a lot of C99 code, hence the indefinite C90 support.

Reply on news.ycombinator.com