Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
uc"..." string literals might be made even simpler, for example allowing[...]
only hex digits and not requiring \x (uc"01020304" rather than
uc"\x01\x02\x03\x04"). That's probably overkill. uc"..." literals
could be useful in other contexts, and programmers will want
flexibility. Maybe something like hex"01020304" (embedded spaces could
be ignored) could be defined in addition to uc"\x01\x02\x03\x04".
*If* hexadecimal string literals were to be added to a future version
of the language, I think I have a syntax that I like better than
what I suggested.
Inspired by the existing syntax for integer and floating-point
hex constants, I propose using a "0x" prefix. 0x"deadbeef" is an
expression of type `const unsigned char[4]` (assuming CHAR_BIT==8),
with values 0xde, 0xad, 0xbe, 0xef in that order. Byte order is
irrelevant; we're specifying byte values in order, not bytes of
the representation of some larger type. memcpy()ing 0x"deadbeef"
to a uint32 might yield either 0xdeadbeef or uxefbeadde (or other
more exotic possibilities).
Again, unlike other string literals, there is no implicit terminating
null byte. And I suggest making them const, since there's no
existing code to break.
If CHAR_BIT==8, each byte is represented by two hex digits. More
generally, each byte is represented by (CHAR_BIT+3)/4 hex digits in
the absence of whitespace. Added whitespace marks the end of a byte, 0x"deadbeef" is 1, 2, 3, or 4 bytes if CHAR_BIT is 32, 16, 12, or 8 respectively, but 0x"de ad be ef" is 4 bytes regardless of CHAR_BIT.
0x"" is a syntax error, since C doesn't support zero-length arrays.
Anything between the quotes other than hex digits and spaces is a
syntax error.
0x"dead beef" is still 4 bytes if CHAR_BIT==8; the space forces the
end of a byte, but the usage of spaces doesn't have to be consistent.
This could be made more flexible by allowing various backslash
escapes, but I'm not inclined to complicate it too much.
Note that the value of a (proposed) hex string literal is not a
string unless it happens to end in zero. I still use the term
"string literal" because it's closely tied to existing string
literal syntax, and existing string literals don't necessarily
represent strings anyway ("embedded\0null\0characters").
Binary string literals 0b"11001001" might also be worth
considering (that's of type `const unsigned char[1]`).
Octal
string literals 0"012 345 670" *might* be worth considering.
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3193.htm>
proposes a new "0o123" syntax for octal constants; if that's adopted,
I propose allowing 0o"..." and *not" 0"...". I'm not sure whether
to suggest hex only, or doing hex, octal, and binary for the sake
of completeness.
What I'm trying to design here is a more straightforward way to
represent raw (unsigned char[]) data in C code, largely but not
exclusively for use by #embed.
Inspired by the existing syntax for integer and floating-point
hex constants, I propose using a "0x" prefix. 0x"deadbeef" is an
expression of type `const unsigned char[4]` (assuming CHAR_BIT==8),
with values 0xde, 0xad, 0xbe, 0xef in that order. Byte order is
irrelevant; we're specifying byte values in order, not bytes of
the representation of some larger type. memcpy()ing 0x"deadbeef"
to a uint32 might yield either 0xdeadbeef or uxefbeadde (or other
more exotic possibilities).
Again, unlike other string literals, there is no implicit terminating
null byte. And I suggest making them const, since there's no
existing code to break.
If CHAR_BIT==8, each byte is represented by two hex digits. More
generally, each byte is represented by (CHAR_BIT+3)/4 hex digits in
the absence of whitespace. Added whitespace marks the end of a byte, 0x"deadbeef" is 1, 2, 3, or 4 bytes if CHAR_BIT is 32, 16, 12, or 8 respectively, but 0x"de ad be ef" is 4 bytes regardless of CHAR_BIT.
0x"" is a syntax error, since C doesn't support zero-length arrays.
Anything between the quotes other than hex digits and spaces is a
syntax error.
What I'm trying to design here is a more straightforward way to
represent raw (unsigned char[]) data in C code, largely but not
exclusively for use by #embed.
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
uc"..." string literals might be made even simpler, for example allowing[...]
only hex digits and not requiring \x (uc"01020304" rather than
uc"\x01\x02\x03\x04"). That's probably overkill. uc"..." literals
could be useful in other contexts, and programmers will want
flexibility. Maybe something like hex"01020304" (embedded spaces could
be ignored) could be defined in addition to uc"\x01\x02\x03\x04".
*If* hexadecimal string literals were to be added to a future version
of the language, I think I have a syntax that I like better than
what I suggested.
Inspired by the existing syntax for integer and floating-point
hex constants, I propose using a "0x" prefix. 0x"deadbeef" is an
expression of type `const unsigned char[4]` (assuming CHAR_BIT==8),
with values 0xde, 0xad, 0xbe, 0xef in that order. Byte order is
irrelevant; we're specifying byte values in order, not bytes of
the representation of some larger type. memcpy()ing 0x"deadbeef"
to a uint32 might yield either 0xdeadbeef or uxefbeadde (or other
more exotic possibilities).
Again, unlike other string literals, there is no implicit terminating
null byte. And I suggest making them const, since there's no
existing code to break.
If CHAR_BIT==8, each byte is represented by two hex digits. More
generally, each byte is represented by (CHAR_BIT+3)/4 hex digits in
the absence of whitespace. Added whitespace marks the end of a byte, 0x"deadbeef" is 1, 2, 3, or 4 bytes if CHAR_BIT is 32, 16, 12, or 8 respectively, but 0x"de ad be ef" is 4 bytes regardless of CHAR_BIT.
0x"" is a syntax error, since C doesn't support zero-length arrays.
Anything between the quotes other than hex digits and spaces is a
syntax error.
0x"dead beef" is still 4 bytes if CHAR_BIT==8; the space forces the
end of a byte, but the usage of spaces doesn't have to be consistent.
This could be made more flexible by allowing various backslash
escapes, but I'm not inclined to complicate it too much.
Note that the value of a (proposed) hex string literal is not a
string unless it happens to end in zero. I still use the term
"string literal" because it's closely tied to existing string
literal syntax, and existing string literals don't necessarily
represent strings anyway ("embedded\0null\0characters").
Binary string literals 0b"11001001" might also be worth
considering (that's of type `const unsigned char[1]`).
Octal
string literals 0"012 345 670" *might* be worth considering.
What I'm trying to design here is a more straightforward way to
represent raw (unsigned char[]) data in C code, largely but not
exclusively for use by #embed.
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
If CHAR_BIT==8, each byte is represented by two hex digits. More
generally, each byte is represented by (CHAR_BIT+3)/4 hex digits in
the absence of whitespace. Added whitespace marks the end of a byte,
0x"deadbeef" is 1, 2, 3, or 4 bytes if CHAR_BIT is 32, 16, 12, or 8
respectively, but 0x"de ad be ef" is 4 bytes regardless of CHAR_BIT.
0x"" is a syntax error, since C doesn't support zero-length arrays.
Anything between the quotes other than hex digits and spaces is a
syntax error.
Would "0x1 23 45 67" be a syntax error or { 0x1, 0x23, 0x45, 0x67 }?
C23 adds the option to use apostrophes as separators in numeric
constants: 123'456'789 or 0xdead'beef, for example. (This is borrowed
from C++.
Most situations where octal could be useful died out many decades ago -
it is vastly more likely that "012" is intended to mean 12 than 10. No serious programming language supports a leading 0 as an indication of
octal unless they are forced to do so by backwards compatibility, and
many that used to support them have dropped them.
AFAIK nobody uses octal anymore.
You could use some kind of type punning. For example, this is currently legal:
union {
unsigned char buf[4];
uint32_t n;
} obj = {
.buf = { 0x01, 0x02, 0x03, 0x04 }
};
The { 0x01, 0x02, 0x03, 0x04 } could be replaced with 0x"01020304".
bart <bc@freeuk.com> writes:
AFAIK nobody uses octal anymore.
There are circumstances where being able to write constants
in octal is useful. It also would be nice to be able to
write constants in base 4 and base 32 (because 5 is half
of 10). I don't have occasion to prefer octal very often
but I'm glad it's there for those times when I do.
AFAIK nobody uses octal anymore.
On Mon, 17 Jun 2024 22:39:00 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
bart <bc@freeuk.com> writes:
AFAIK nobody uses octal anymore.
There are circumstances where being able to write constants
in octal is useful. It also would be nice to be able to
write constants in base 4 and base 32 (because 5 is half
of 10). I don't have occasion to prefer octal very often
but I'm glad it's there for those times when I do.
Ada/VHDL permits any base from 2 to 16. They didn't go as far up as
32.
I would imagine that reading base 32 number would take time to become accustomed.
David Brown <david.brown@hesbynett.no> writes:
On 17/06/2024 01:48, Keith Thompson wrote:[...]
For binary,
the compaction is irrelevant and indeed counter-productive - binary
literals became a lot more practical with the introduction of digit
separators. (For standard C, these are from C23, but for C++ they came
in C++14, and compilers have supported them as extensions in C.)
I forgot about digit separators.
C23 adds the option to use apostrophes as separators in numeric
constants: 123'456'789 or 0xdead'beef, for example. (This is
borrowed from C++. Commas are more commonly used in real life,
at least in my experience, but that wouldn't work given the other
meanings of commas.)
I briefly considered that, for consistency, we might want to
use apostrophes rather than spaces in hex string constants:
0x"de'ad'be'ef". But since digit separators are purely decorative,
and spaces in my proposed hex string literals are semantically
significant (they terminate a byte), I'll stick with spaces.
You could even write 0x"0 0 0 0" to denote 4 zero bytes (where
"0x0000" is 2 bytes) but 0x"00 00 00 00" or "0x00000000" is probably
clearer.
I think allowing both spaces and apostrophes would be too confusing.
Octal
string literals 0"012 345 670" *might* be worth considering.
Most situations where octal could be useful died out many decades ago
- it is vastly more likely that "012" is intended to mean 12 than 10.
No serious programming language supports a leading 0 as an indication
of octal unless they are forced to do so by backwards compatibility,
and many that used to support them have dropped them.
Having /some/ way to write octal can be helpful to old *nix
programmers who prefer 046 to "S_IRUSR | S_IWUSR | S_IRGRP" in their
chmod calls. (And to be fair, the constant names made in ancient
history with short identifier length limits are pretty ugly.) But it
is not something to be encouraged, and I think there is no simple
syntax that is obviously octal, and not easily mistaken for something
else.
There is, the proposed "0o" prefix. It's already supported in both Perl
and Python, and likely other languages.
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3193.htm>
proposes a new "0o123" syntax for octal constants; if that's adopted,
I propose allowing 0o"..." and *not" 0"...". I'm not sure whether
to suggest hex only, or doing hex, octal, and binary for the sake
of completeness.
Binary support is useless, and octal support would be worse than
useless - even using an 0o rather than 0 prefix. Completeness is not
a justification for repeating old mistakes or complicating a good idea
with features that will never be used.
I like binary integer constants (0b11001001), but I suppose I
agree that they're not useful for larger chunks of data.
I have no
problem supporting only hex string literals, not binary or octal --
but I'd have no problem with having all three if anyone thinks that
would be sufficiently useful.
What I'm trying to design here is a more straightforward way to
represent raw (unsigned char[]) data in C code, largely but not
exclusively for use by #embed.
Personally, I'd see it as useful when /not/ using #embed. I really do
not think programmers will care what format #embed uses. I don't
share your concerns about efficiency of implementation, or that
programmers need to know when it is efficient or not. In almost all
circumstances, C programmers never see or need to think about a
separation between a C preprocessor and a post-processed C compiler -
they are seen as a single entity, and can use whatever format is
convenient between them. And once you ignore the implementation
details, which are an SEP, the way #embed is defined is better than a
definition using these new hex blob strings.
I think my main problem with the current #embed is that it's
conceptually messy. I'm probably an outlier in how much I care about
that.
It's not clear whether the problems with the current definition of
#embed are as serious as I suggest; you clearly think they aren't.
But
even if the current #embed is ok, I think adding hex string literals and adding a language defined embed parameter that specifies using hex
string literals rather than a list of integer constant expressions would
be useful.
Among other things, it lets the programmer specify that a
given #embed is only to be used to initialize an array of unsigned char.
For example, given a 4-byte foo.dat containing bytes 1, 2, 3, and 4:
const unsigned char buf[] = {
#embed "foo.dat"
};
would expand to something like:
const unsigned char buf[] = {
1, 2, 3, 4
};
(and the same if buf is of type int[] or double[]), while this:
const unsigned char buf[] =
#embed "foo.dat" hex(true) // proposed new parameter
;
would expand to something like:
const unsigned char buf[] =
0x"01020304"
;
(and would result in an error if buf is of type int[] or double[]).
[...]
On 2024-06-17, bart <bc@freeuk.com> wrote:
AFAIK nobody uses octal anymore.
Unix shell and C programmers fairly often use octal unintentionally,
Richard Kettlewell <invalid@invalid.invalid> writes:
There’s more to life than byte arrays, though, so I wonder if there’s
more to be said here. I find myself dealing a lot with large integers
generally represented as arrays of some unsigned type (commonly uint32_t
but other possibilities arise too).
In C as it stands today this requires a translation step before
constants can be embedded in source code (which is error-prone if
someone attempts to do it manually).
So being able to say ‘0x8732456872648956348596893765836543 as array of
uint64_t, LSW first’ (in some suitably C-like syntax) would be a big
improvement from my perspective, primarily as an accelerator to
development but also as a small improvement in robustness.
You could use some kind of type punning. For example, this is currently legal:
union {
unsigned char buf[4];
uint32_t n;
} obj = {
.buf = { 0x01, 0x02, 0x03, 0x04 }
};
The { 0x01, 0x02, 0x03, 0x04 } could be replaced with 0x"01020304".
Of course you have to deal with endianness.
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2024-06-17, bart <bc@freeuk.com> wrote:
AFAIK nobody uses octal anymore.
Unix shell and C programmers fairly often use octal unintentionally,
Perhaps you do. Don't speak for others, please.
On Mon, 17 Jun 2024 22:39:00 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
bart <bc@freeuk.com> writes:
AFAIK nobody uses octal anymore.
There are circumstances where being able to write constants
in octal is useful. It also would be nice to be able to
write constants in base 4 and base 32 (because 5 is half
of 10). I don't have occasion to prefer octal very often
but I'm glad it's there for those times when I do.
Ada/VHDL permits any base from 2 to 16. They didn't go as far up as
32.
I would imagine that reading base 32 number would take time to become accustomed.
On Mon, 17 Jun 2024 22:39:00 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
bart <bc@freeuk.com> writes:
AFAIK nobody uses octal anymore.
There are circumstances where being able to write constants
in octal is useful. It also would be nice to be able to
write constants in base 4 and base 32 (because 5 is half
of 10). I don't have occasion to prefer octal very often
but I'm glad it's there for those times when I do.
Ada/VHDL permits any base from 2 to 16. They didn't go as far up as
32.
I would imagine that reading base 32 number would take time to become accustomed.
Besides, using I and O as digits is problematic because of visual
similarity to 1 an 0. Using l is problematic both because of visual similarity to 1 and because of clash with existing use as suffix.
[...] I noticed this strange discrepancy between
between my hex floats and C's. In C, this value:
0x12.34p10
has the decimal value 18640.0; why was that? It turns that this is:
18.203125 x 2 ** 10
The main part is interpreted as actual hex; the exponent is in
decimal, and exponent scaling is in binary bits. So THREE diferent
bases are involved!
In my scheme (which as I said worked for bases from 2 to 16), the
0x12.34p10 value would mean this:
18.203125 x 16 ** 16 ~= 3.58e20
The same base is used for all parts, including the exponent, and the
digits that are to be shifted. After all in decimal, 12.34e10 would
mean:
12.34 x 10 ** 10 = 123400000000.0
In my language, a base 5 version 5x12.34e10 (not valid below base 5)
would mean this (I think, as I no longer have the compiler):
7.76 x 5 ** 5 = 24250.0
This has a consistency lacking in C's hex floats.
On 18/06/2024 15:56, Scott Lurndal wrote:
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2024-06-17, bart <bc@freeuk.com> wrote:
AFAIK nobody uses octal anymore.
Unix shell and C programmers fairly often use octal unintentionally,
Perhaps you do. Don't speak for others, please.
Others do it too. Perhaps not "fairly often", but it certainly happens.
On 18/06/2024 16:21, David Brown wrote:
On 18/06/2024 15:56, Scott Lurndal wrote:
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2024-06-17, bart <bc@freeuk.com> wrote:
AFAIK nobody uses octal anymore.
Unix shell and C programmers fairly often use octal unintentionally,
Perhaps you do. Don't speak for others, please.
Others do it too. Perhaps not "fairly often", but it certainly happens.
This has bit me ...
$ ping -c 1 192.168.1.17
PING 192.168.1.17 (192.168.1.17) 56(84) bytes of data.
64 bytes from 192.168.1.17: icmp_seq=1 ttl=64 time=0.097 ms
--- 192.168.1.17 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.097/0.097/0.097/0.000 ms
$ ping -c 1 192.168.001.017
PING 192.168.001.017 (192.168.1.15) 56(84) bytes of data.
From 192.168.1.17 icmp_seq=1 Destination Host Unreachable
--- 192.168.001.017 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
... C++ could not use underscores
due to their use in user-defined literals, and C followed C++.
David Brown <david.brown@hesbynett.no> writes:
On 18/06/2024 02:19, Keith Thompson wrote:[...]
I forgot about digit separators.
C23 adds the option to use apostrophes as separators in numeric
constants: 123'456'789 or 0xdead'beef, for example. (This is
borrowed from C++. Commas are more commonly used in real life,
at least in my experience, but that wouldn't work given the other
meanings of commas.)
Commas would be entirely unsuitable here, since half the world uses
decimal commas rather than decimal points. I think underscores are a
nicer choice, used by many languages, but C++ could not use
underscores due to their use in user-defined literals, and C followed
C++.
C already uses '.' as the decimal point, though half the world uses ','.
That's already US-centric. ',' is unusable as a digit separator because `123,456` already has any of several meanings, depending on the context.
If it weren't for that issue, I think that using ',' as a digit separator would be no more problematic than using '.' as a decimal point. And C++
and C23 already use the apostrophe as a digit separator, which is likely
to be jarring to anyone outside Switzerland.
In any case, as discussed, I'm not proposing an ignorable digit
separator for hex string literals.
[...]
I don't see the benefit here. This is C - the programmer is expected
to get the type right, and I think it would be rare to get it wrong
(or worse wrong than forgetting "unsigned") in a case like this. So
the extra type checking here has little or no benefit. (In general, I
am a fan of stronger type checking, but it is only important if it
catches real errors.)
The end result is completely identical to the user - adding
"hex(true)" makes no difference to the generated code. Thus it is
just an implementation detail which the user should not have to deal
with.
The point isn't to change the generated code. The point is to let programmers say more directly what they mean: "Treat the contents
of this file as an array of unsigned char", rather than the existing
"Treat the contents of this file as a sequence of comma-separated
integer constant expressions (which, by the way, I'm going to use
in an initializer for an array of unsigned char)".
(I don't think either of us is going to change our minds on the
esthetics. And yes, that sentence isn't entirely grammatically
correct.)
On Tue, 18 Jun 2024 15:54:15 +0200, David Brown wrote:
... C++ could not use underscores
due to their use in user-defined literals, and C followed C++.
C can still offer the option for them, though.
Computing is Amerian, basically. Almost any big co. you can think of,
current or historic, was or is American. IBM, DEC, Sun Microsystems, Microsoft, Google, Apple, ...
On 19/06/2024 00:00, Keith Thompson wrote:
David Brown <david.brown@hesbynett.no> writes:
On 18/06/2024 02:19, Keith Thompson wrote:[...]
I forgot about digit separators.
C23 adds the option to use apostrophes as separators in numeric
constants: 123'456'789 or 0xdead'beef, for example. (This is
borrowed from C++. Commas are more commonly used in real life,
at least in my experience, but that wouldn't work given the other
meanings of commas.)
Commas would be entirely unsuitable here, since half the world uses
decimal commas rather than decimal points. I think underscores are a
nicer choice, used by many languages, but C++ could not use
underscores due to their use in user-defined literals, and C followed
C++.
C already uses '.' as the decimal point, though half the world uses ','.
Sure - a programming language has to pick /one/ such option. And since
C was written by Americans, they got to choose. (I don't mind - we use
a decimal point in the UK too.) However, if someone from one of several European countries sees "1,234" they will read it as 1.234, not 1234.
This means using a comma as a separator would be a bad idea.
(+ 1,234.56 2,000)3234.56
(pic "#,###,###" 1)" 1"
(pic "0,###,###" 1)"0,000,001"
(pic "0,###,###.##" 1)"0,000,001.00"
(pic "0,###_###.##" 1)** expr-1:1: pic: insufficient arguments for format
(pic "0,###_###.##" 1 2)"0,001_ 2.00"
On Wed, 19 Jun 2024 10:17:45 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
Computing is Amerian, basically. Almost any big co. you can think of,
current or historic, was or is American. IBM, DEC, Sun Microsystems,
Microsoft, Google, Apple, ...
Arguably, today's most influential CPU company is British, even if two
of the 3 founders were American and current owner is from Japan.
Today's most important silicon manufacturer, the one that keeps the
progress crawling forward instead of standing still, is Taiwanese.
And the company which made most of research that allowed to this
manufacturer to make progress is based in Netherlands.
On Wed, 19 Jun 2024 10:17:45 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
Computing is Amerian, basically. Almost any big co. you can think of,
current or historic, was or is American. IBM, DEC, Sun Microsystems,
Microsoft, Google, Apple, ...
Arguably, today's most influential CPU company is British,
Michael S <already5chosen@yahoo.com> writes:
On Wed, 19 Jun 2024 10:17:45 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
Computing is Amerian, basically. Almost any big co. you can think
of, current or historic, was or is American. IBM, DEC, Sun
Microsystems, Microsoft, Google, Apple, ...
Arguably, today's most influential CPU company is British,
By what criteria? Yes, they ship a lot of CPUs, but architecturally,
what have they influenced?
I would imagine that reading base 32 number would take time to become accustomed.
On 19/06/2024 09:25, Lawrence D'Oliveiro wrote:
On Tue, 18 Jun 2024 15:54:15 +0200, David Brown wrote:
... C++ could not use underscores due to their use in user-defined
literals, and C followed C++.
C can still offer the option for them, though.
Sometimes it makes sense for C to do the same thing in a different way
from C++ - but it is rare, and needs very strong justification.
On Wed, 19 Jun 2024 10:49:24 +0200, David Brown wrote:
On 19/06/2024 09:25, Lawrence D'Oliveiro wrote:
On Tue, 18 Jun 2024 15:54:15 +0200, David Brown wrote:
... C++ could not use underscores due to their use in user-defined
literals, and C followed C++.
C can still offer the option for them, though.
Sometimes it makes sense for C to do the same thing in a different way
from C++ - but it is rare, and needs very strong justification.
The fact that it is something of a de-facto standard among other popular languages would count.
Is C doomed to remain forever a strict subset of C++?
On Wed, 19 Jun 2024 10:49:24 +0200, David Brown wrote:...
Sometimes it makes sense for C to do the same thing in a different way
from C++ - but it is rare, and needs very strong justification.
The fact that it is something of a de-facto standard among other popular languages would count.
Is C doomed to remain forever a strict subset of C++?
This has bit me ...
$ ping -c 1 192.168.001.017 ...
- in the language that is most relevant for cooperation with C.
On Fri, 21 Jun 2024 13:06:14 +0200, David Brown wrote:
- in the language that is most relevant for cooperation with C.
Not sure why C++ is relevant to C at all, since C++ does pretty much everything that C does (if a bit differently) and more, which renders C essentially obsolete in that scenario.
Where the usage of C would be more relevant is as an implementation
language for CPU-intensive “engine” code meant to be callable from higher-
level languages. For example, extension modules for Python. Being able to interoperate with such languages would be more of a benefit.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 02:14:39 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,581 |