Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

MSVC supports C11 and C17, minus the C99 stuff that was made optional in C11.

Anyway given the option, one should always favour C++ over C, if they care about secure code, which while not perfect it is much better than any C compiler will do.



> MSVC supports C11 and C17, minus the C99 stuff that was made optional in C11.

Sure they do now. They were particularly slow at implementing a bunch of C99 stuff, some of it landing only in VS 2019

https://learn.microsoft.com/en-us/cpp/overview/visual-cpp-la...

MSVC has long lagged in C support because they focused on that subset of C standards that were required for C++.

https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...


> Anyway given the option, one should always favour C++ over C

Eh. I work in embedded, where C reigns supreme. C++ has its own issues in the area, namely that you need to construct your own sub-dialect that removes some features of C++ to make it fit embedded constraints. Commonly, it's C++-but-no-exceptions, sometimes C++-but-no-templates, and others.

That said, I'll grant that us embedded developers are effectively "traumatized" and have difficulty accepting new approaches because we're too focused on certain paradigms that are no longer relevant (See my previous about returning structures, which has encountered responses like "but then it might do an extra memcpy()!!11")


> sometimes C++-but-no-templates

I can understand exceptions, but what constraints require you to ban templates? If its just code size then it seems a bit arbitrary to ban them completely.

AFAIK most users of C++ do ban some features in their projects so I don't see why that specifically is holding embedded back. Disabling exceptions specifically is something that is not unheard of outside embedded either.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: