From Newsgroup: comp.lang.c


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)

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 21/01/2025 17:22, Thiago Adams wrote:

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.

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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.
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Tue, 21 Jan 2025 21:19:49 +0100
Opus <ifonly@youknew.org> wrote:

On 21/01/2025 17:22, Thiago Adams wrote:

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++.

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 21/01/2025 16:22, Thiago Adams wrote:

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.
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Wed, 22 Jan 2025 02:45:20 +0000, Jack Lemmon wrote:

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?

I believe Herb Sutter has left Microsoft and is now working somewhere
else.

Surprised it didn’t happen sooner. He must have been continually
embarrassed to come back from standards meetings, to find his employer
among the last to adopt the new specs.
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 21/01/2025 13:22, Thiago Adams wrote:

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)

Update

working (MSVC 17.12)
- empty initializer
- __has_include
-

not working
- embed
-
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 22/01/2025 05:41, Lawrence D'Oliveiro wrote:

On Wed, 22 Jan 2025 02:45:20 +0000, Jack Lemmon wrote:

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.

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 1/22/25 21:28, Jack Lemmon wrote:
...

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."


--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2025-01-23, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

On 1/22/25 21:28, Jack Lemmon wrote:
...

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."

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: @Kazinator@mstdn.ca
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Thu, 23 Jan 2025 02:28:43 +0000, Jack Lemmon wrote:

On 22/01/2025 05:41, Lawrence D'Oliveiro wrote:

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? --- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2025-01-21 4:20 p.m., Lawrence D'Oliveiro wrote:

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.

That chart is inaccurate for MSVC 17.12.4 with /std:clatest.
For instance, [[fallthrough]] is certainly supported.


--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Thu, 23 Jan 2025 20:06:02 -0500, mjos_examine wrote:

On 2025-01-21 4:20 p.m., Lawrence D'Oliveiro wrote:

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.

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.
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Fri, 24 Jan 2025 06:58:47 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Thu, 23 Jan 2025 20:06:02 -0500, mjos_examine wrote:

On 2025-01-21 4:20 p.m., Lawrence D'Oliveiro wrote:

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.

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.


--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Fri, 24 Jan 2025 14:06:05 +0200, Michael S wrote:

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 ...

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?
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 24/01/2025 13:06, Michael S wrote:

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.

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.

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Fri, 24 Jan 2025 14:06:05 +0200, Michael S wrote:

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.

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+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Jack Lemmon <noreply@mandrill.com> wrote:

On 22/01/2025 05:41, Lawrence D'Oliveiro wrote:

On Wed, 22 Jan 2025 02:45:20 +0000, Jack Lemmon wrote:

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
--- Synchronet 3.20c-Linux NewsLink 1.2