Discussion:
C23 on MSVC
Add Reply
Thiago Adams
2025-01-21 16:22:13 UTC
Reply
Permalink
working (MSVC 17.12)
- static_assert as keyword
- elifdef
- typeof
- binary literal
- digit separator
- Attributes!
-

not working
- u8 char literal
- # warning
- auto
- true/false
- nullptr
- constexpr
- extended enuns


Can be verified here
https://godbolt.org/z/oo7d36jx5

I didn't find release notes! (Is like MS pretending C does exist anymore
but still updating it)
Opus
2025-01-21 20:19:49 UTC
Reply
Permalink
Post by Thiago Adams
I didn't find release notes! (Is like MS pretending C does exist anymore
but still updating it)
They've been doing just that for about 25 years.
Michael S
2025-01-21 21:50:30 UTC
Reply
Permalink
On Tue, 21 Jan 2025 21:19:49 +0100
Post by Opus
Post by Thiago Adams
I didn't find release notes! (Is like MS pretending C does exist
anymore but still updating it)
They've been doing just that for about 25 years.
Not exactly. Between 1993 and ~2010 their C front end had seen
very little chang. At most, they added few trivial headers, like
<stdint.h>
I would not call it 'updating it'.
Of course, back end(s) were updated regularly, but this part is shared
with C++.
Lawrence D'Oliveiro
2025-01-21 21:20:55 UTC
Reply
Permalink
Interesting to compare the different compilers on this chart:

<https://en.cppreference.com/w/c/compiler_support/23>.

The only one with a solid green column is GCC. MSCV is mostly red.
mjos_examine
2025-01-24 01:06:02 UTC
Reply
Permalink
Post by Lawrence D'Oliveiro
<https://en.cppreference.com/w/c/compiler_support/23>.
The only one with a solid green column is GCC. MSCV is mostly red.
That chart is inaccurate for MSVC 17.12.4 with /std:clatest.
For instance, [[fallthrough]] is certainly supported.
Lawrence D'Oliveiro
2025-01-24 06:58:47 UTC
Reply
Permalink
Post by mjos_examine
Post by Lawrence D'Oliveiro
<https://en.cppreference.com/w/c/compiler_support/23>.
The only one with a solid green column is GCC. MSCV is mostly red.
That chart is inaccurate for MSVC 17.12.4 with /std:clatest.
For instance, [[fallthrough]] is certainly supported.
Still leaving MSVC mostly red, is it not? And still the only one with a
solid green column remains GCC.
Michael S
2025-01-24 12:06:05 UTC
Reply
Permalink
On Fri, 24 Jan 2025 06:58:47 -0000 (UTC)
Post by Lawrence D'Oliveiro
Post by mjos_examine
Post by Lawrence D'Oliveiro
<https://en.cppreference.com/w/c/compiler_support/23>.
The only one with a solid green column is GCC. MSCV is mostly red.
That chart is inaccurate for MSVC 17.12.4 with /std:clatest.
For instance, [[fallthrough]] is certainly supported.
Still leaving MSVC mostly red, is it not? And still the only one with
a solid green column remains GCC.
May be, because majority of additions to the Standard were codifying
existing gcc practice?
BTW, there is nothing wrong with that. In the situation where gcc team
is the only capable team interested in further development of C
language, it is the most logical outcome.


I suppose, MSVC team would appreciate addition of
__try/__except/__finally.
But since it didn't happen in last 31 years, it is not very likely to
happen in the future.
Lawrence D'Oliveiro
2025-01-25 00:41:35 UTC
Reply
Permalink
Post by Michael S
May be, because majority of additions to the Standard were codifying
existing gcc practice?
Interesting. When I ventured a few months ago in this group that GCC had
become the closest we have to a de-facto-standard C implementation, quite
a few people objected.

Did you know GCC allows nested function definitions, with references to
uplevel locals? I wonder how long it is before that makes it into ANSI/ISO
C ...
Post by Michael S
BTW, there is nothing wrong with that. In the situation where gcc team
is the only capable team interested in further development of C
language, it is the most logical outcome.
What, no love for LLVM/clang?
Keith Thompson
2025-01-25 04:51:11 UTC
Reply
Permalink
Post by Lawrence D'Oliveiro
Post by Michael S
May be, because majority of additions to the Standard were codifying
existing gcc practice?
Interesting. When I ventured a few months ago in this group that GCC had
become the closest we have to a de-facto-standard C implementation, quite
a few people objected.
Did you know GCC allows nested function definitions, with references to
uplevel locals? I wonder how long it is before that makes it into ANSI/ISO
C ...
There's no contradiction. The assertion (on which I offer no opinion)
was that the majority of additions to the standard have codified
existing gcc practice. This deons't imply that most gcc extensions find
their way into the standard.
Post by Lawrence D'Oliveiro
Post by Michael S
BTW, there is nothing wrong with that. In the situation where gcc team
is the only capable team interested in further development of C
language, it is the most logical outcome.
What, no love for LLVM/clang?
My impression is that clang mostly follows gcc in terms of language
feature and extensions. Its innovations are more in the internals of
the implementation.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+***@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
Opus
2025-01-25 01:48:22 UTC
Reply
Permalink
Post by Michael S
May be, because majority of additions to the Standard were codifying
existing gcc practice?
BTW, there is nothing wrong with that. In the situation where gcc team
is the only capable team interested in further development of C
language, it is the most logical outcome.
Yes, the main reason is that GCC actually cares about C.
MS hasn't for over 2 decades.
They just mostly stuck to C89 for their own needs (kernel, drivers...)
with just a few proprietary MS extensions. They never cared beyond that
and switched to C++ entirely mid-90's for all their developments (apart
again from the very low level) even when the Windows API itself was
still C for the most part.
Post by Michael S
I suppose, MSVC team would appreciate addition of
__try/__except/__finally.
But since it didn't happen in last 31 years, it is not very likely to
happen in the future.
Considering they are using C only for the low-level parts, shouldn't
they embrace Rust instead, which they are promoters of? Or are they
"promoting" it for everyone else except themselves? Not really willing
to start a flamewar (although it can be fun with some topics), but just
curious.
Jack Lemmon
2025-01-22 02:45:20 UTC
Reply
Permalink
Post by Thiago Adams
I didn't find release notes! (Is like MS pretending C does exist anymore
but still updating it)
Correct. Microsoft is not actively developing C and the release notes
don't actually tell you much about C++.

<https://learn.microsoft.com/en-us/visualstudio/releases/2022/release-notes#17.12.4>

Microsoft's main language is C# and they are investing a lot on it. They
want C# to be the main language for everyday use.

I believe Herb Sutter has left Microsoft and is now working somewhere else.
Jack Lemmon
2025-01-23 02:28:43 UTC
Reply
Permalink
Post by Jack Lemmon
Microsoft's main language is C# and they are investing a lot on it. They
want C# to be the main language for everyday use.
What did they write C♯ in, though?
First release was written in assembly code. Subsequent releases are in
C# itself. The c# language is class based object oriented, so you don't
need anything else to expand the language. Just write a new object and
compile it to be used by other objects. This is the same as in C or C++.
First release were in assembly and any enhancement were in the same
language = C or C++ respectively.

C# is now cross platform; You can download VS code and .net extension
and compile the code in Linux and/or Mac. There are many tutorials
teaching new users how to write and compile c# code in Linux.
James Kuyper
2025-01-23 07:35:20 UTC
Reply
Permalink
On 1/22/25 21:28, Jack Lemmon wrote:
...
Post by Jack Lemmon
compile it to be used by other objects. This is the same as in C or
C++. First release were in assembly and any enhancement were in the
same language = C or C++ respectively.
Not quite - the original C++ compiler was Cfront, which produced C code
which was then compiled by a conventional C compiler. Per Wikipedia:

"As Cfront was written in C++, it was a challenge to bootstrap on a
machine without a C++ compiler/translator. Along with the Cfront C++
sources, a special "half-preprocessed" version of the C code resulting
from compiling Cfront with itself was also provided. This C code was to
be compiled with the native C compiler, and the resulting executable
could then be used to compile the Cfront C++ sources."
Kaz Kylheku
2025-01-23 21:45:34 UTC
Reply
Permalink
Post by James Kuyper
...
Post by Jack Lemmon
compile it to be used by other objects. This is the same as in C or
C++. First release were in assembly and any enhancement were in the
same language = C or C++ respectively.
Not quite - the original C++ compiler was Cfront, which produced C code
"As Cfront was written in C++, it was a challenge to bootstrap on a
machine without a C++ compiler/translator. Along with the Cfront C++
sources, a special "half-preprocessed" version of the C code resulting
from compiling Cfront with itself was also provided. This C code was to
be compiled with the native C compiler, and the resulting executable
could then be used to compile the Cfront C++ sources."
The code is available, up through some final release back around 1994.

I was looking at it some time ago.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @***@mstdn.ca
Lawrence D'Oliveiro
2025-01-23 23:51:27 UTC
Reply
Permalink
Post by Jack Lemmon
What did they write C♯ in, though?
First release was written in assembly code. Subsequent releases are in
C# itself.
Isn’t there a dependency on CLR as the OO engine? What is that written in?
Waldek Hebisch
2025-01-25 23:36:41 UTC
Reply
Permalink
Post by Jack Lemmon
Post by Jack Lemmon
Microsoft's main language is C# and they are investing a lot on it. They
want C# to be the main language for everyday use.
What did they write C♯ in, though?
First release was written in assembly code. Subsequent releases are in
C# itself. The c# language is class based object oriented, so you don't
need anything else to expand the language. Just write a new object and
compile it to be used by other objects. This is the same as in C or C++.
First release were in assembly and any enhancement were in the same
language = C or C++ respectively.
Do you have insider info? Writing substantial piece of code in
nineties using assembler would be highly unusual. Slightly
earlier Microsoft supposedly had a rule that all code should
be in C (presumably with exceptions for lowest level machine
dependencies and some performance critical parts, but both
should be relatively small).

Also, when a company has compilers for multiple languages, it
is natural to share substantial part for other languages. In
case of gcc Ada front-end is in Ada, but most work is in "middle
end" that is common to all compilers in gcc and is written in C++.
I would guess that now Microsoft C compiler is written in C++.
--
Waldek Hebisch
Andrey Tarasevich
2025-02-04 14:36:09 UTC
Reply
Permalink
Post by Thiago Adams
I didn't find release notes! (Is like MS pretending C does exist anymore
but still updating it)
Nope. Microsoft has been officially saying that they are fully
supporting modern C standards for quite a while

https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/

It is clear that most of their resources are dedicated to supporting C++
(as is the case with all other mainstream compiler developers), but
their C support is not wavering either.
--
Bets regards,
Andrey
David Brown
2025-02-04 20:04:39 UTC
Reply
Permalink
Post by Andrey Tarasevich
Post by Thiago Adams
I didn't find release notes! (Is like MS pretending C does exist
anymore but still updating it)
Nope. Microsoft has been officially saying that they are fully
supporting modern C standards for quite a while
https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/
It is clear that most of their resources are dedicated to supporting C++
(as is the case with all other mainstream compiler developers), but
their C support is not wavering either.
If I understand it correctly (and I don't really care about MSVC's C
support, except on how their lack of C support negatively impacts the C
standards and other C programmers), they still fail to support C99.
They pushed for some aspects of C99 - specifically VLA's - to be
optional in C11 so that they could avoid supporting it.

So in 2020 with their latest compiler, MS is proudly supporting a
decade-old standard while still failing to handle a massively popular
twenty-year old standard. Forgive me for not being impressed.

Loading...