Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #167936
| From | BGB <cr88192@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Date | 2022-10-01 16:07 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <thaa6p$1dt05$2@dont-email.me> (permalink) |
| References | (1 earlier) <20220922201519.3@kylheku.com> <tgjogc$1ivg$2@gioia.aioe.org> <tgq39g$2pt$1@gioia.aioe.org> <20220925214731.135@kylheku.com> <tgric9$3mc4q$1@dont-email.me> |
On 9/26/2022 1:55 AM, David Brown wrote:
> On 26/09/2022 06:53, Kaz Kylheku wrote:
>> On 2022-09-25, Manfred <noname@add.invalid> wrote:
>>> Non-GC is definitely not for embedded programming only.
>>> I have seen a pretty large project for digital imaging workstations fail
>>> because of the non deterministic nature of GC.
>>
>> And are you sure that you didn't see a large project fail for various
>> reasons, whereby some people tried to shift the blame to garbage
>> collection?
>>
>> Today someone will pull it off ... in the browser.
>>
>> (How many decades before the web was this?)
>>
>
> In high reliability small embedded systems, garbage collection is
> generally a very bad idea because it requires more space and is
> non-deterministic in time and space. (Indeed you usually try to work
> without any kind of dynamic memory allocation at all.) Such systems
> don't have swap memory, or paging systems. There is no option for
> dealing with "out of memory" conditions. The code runs as expected 100%
> of the time, and you can justify that from the code source and testing,
> or it is useless. Your car brake system can't take a 200 ms pause to do
> a garbage collection sweep.
>
> Not all systems (even embedded systems) have to be high reliability, of
> course. But there are also many other kinds of programming where
> determinism is important and the kind of variability you can get from
> asynchronous garbage collection is not acceptable. Game programming is
> a fine example.
>
Generally agreed.
My first real attempt at a 3D engine had initially used a conservative
mark/sweep collector, and the results were "not particularly good"
(wasted lots of memory, and would then randomly stall when the GC did
its thing). I eventually ended up mostly defeating the GC and using it
more like "good ol' malloc".
My following projects generally avoided GC.
Though, admittedly, I have more recently started picking up the use of
"zone" allocators. These can allow some of the features of GC while also
avoiding some of their drawbacks.
The Doom engine had also used a zone allocator pretty effectively (most
of the engine was based around a "Z_Malloc" allocator that implemented
this), and Quake 1/2 had also used them (albeit to a much narrower
extent, instead moving most of the bulk allocation to a stack-like
"Hunk" allocator).
Major differences between a GC and zone:
GC needs a graph tracing and marking step, zone does not;
GC may happen whenever the GC decides, zone is explicit.
If not used correctly, a zone allocator can totally ruin a program, such
as if one frees data before one is done with it, or organizes stuff such
there are a lot of dangling pointers.
The Doom engine had a mechanism for this later case: a per object "user"
pointer, which if not null when the object is freed, it will interpret
the pointer as a double pointer which is then set to NULL.
Can also note that it seemingly fell into disuse or was dropped from
subsequent engines, implying it was kind of a gimmick.
In my BGBCC compiler, had also partly moved some stuff over to a zone
allocator, but had also not bothered with the user-pointer mechanism.
Generalizing the idea further, had ended up moving away from the "free
everything where ztag>=zref" to "free everything where
((ztag&zmask)==zref)" which allows freeing things in terms of specific
values or ranges, though requires the range of things to be freed to be
power-of-2.
Though, this could be a hint for why Quake and friends mostly went over
to its "Hunk" system: in most cases where Doom's original use was
sufficient, one could get basically the same effect via a big stack-like
allocator (and in many other cases, the Z_Malloc/Z_Free was basically
just being used like a normal malloc/free).
Well, and also with a "hunk", allocation is cheap, bulk free is fast,
and fragmentation issues are basically non-existent. Want to bulk free
stuff? Save the current hunk pointer, and restore it later to free
everything past this point.
However, one big downside is that one is on a thin edge between wasting
memory (by having the hunk bigger than needed), or not having enough.
However, as a "general purpose" construct, something like "the hunk" is
not so easily generalized. And, while it works well in Quake and
similar, this approach would be basically unusable for something like a
Minecraft clone.
Then again, Quake had some other limitations, such the inability to
spawn "new" types of entities once the map had already started, since
then the data in the hunk would no longer be in the correct order. IIRC,
Quake 2 and 3 had addressed this issue by moving over to multiple hunks
(say, with a "main hunk" for the map and similar, and another smaller
one for things like "precached" models and sound-effects).
Granted, could Quake 2 and 3 have worked had they malloc'ed all of the
alias models and sound effects instead? Probably.
I am less sure what happened in Doom 3, since it suddenly expanded to
nearly 1M lines and also switched from C to C++, my motivation to really
look too much into how its memory management worked was kinda reduced.
> On the other hand, garbage collection can make some kinds of code
> faster, by leaving the clearing up until there is a natural down-time in
> the program, or running it in separate threads to avoid messing with the
> main work of the program. (The big risk there is trashing your caches.)
>
Potentially.
With a zone allocator, one can also add a periodic zone-free for the
inner scratchpad zones into the outer loop, which then runs on a timer.
Any working data which is left in this inner working zone, is discarded
when the zone is freed.
In some of my use cases (such as in BGBCC), there is a "walk this graph
of nodes and reassign them do a different zone as needed" function.
Say, once one parses a program, one can reassign the AST to a "module
scope" zone, and clear up whatever remains (and intermediate working
nodes, etc).
For languages that need multiple toplevel passes (such as my BGBScript2
language), the ASTs can be reassigned to "program global".
Partly, the latter is because the front-end is organized like:
Parse every module (in order):
If C or C++ or similar, compile to IR bytecode;
If BS2 (or the faked Java or C# modes), add to a delayed queue.
For everything in the delayed queue:
Do a "toplevel only" compile step;
This stage mostly builds packages/namespaces and similar.
For everything in the delayed queue:
Compile it to bytecode.
If needed, invoke the backend to do its thing.
The output of the frontend is generally a big blob of linear stack-based
bytecode (all the metadata is also encoded via the linear bytecode),
with the "decoding" stage effectively working like a special purpose
interpreter which produces 3AC as output.
Had on/off considered moving to a RIFF based packaging instead of linear
bytecode, but had admittedly not done so yet (not a strong enough
incentive to go through the effort of doing so). Even if doing a big
blob of linear bytecode (like this was PostScript or something) is a
little, errm...
Note that it is possible to fairly directly interface between C and BS2
in BGBCC.
C:
int bar(int z);
int foo(int x, int y)
{ return(x+y); }
BS2:
native int foo(int x, int y);
native int bar(int z)
{ return(z*z); }
Where, the compiler interprets top-level declarations with 'native' as
"this should use the C ABI" (similar to 'extern "C" { ... }' in C++).
Note that, unlike Java or C#, the BS2 language does not impose much in
terms of program structure (despite it using a mostly Java-inspired syntax).
Though, one potential gotcha is that BS2 does (like C# and Java) use a
16-bit 'char' type, so if one ones 8-bit values they need to use
cchar/byte/sbyte/ubyte.
Well, and other differences, like:
int a[8][8];
Is very different from:
int[][] a=new! int[8][8];
Where:
int a[8]; //C-like, decays to int*
int[8] a; //similar, but bounds-checked and decays to int[], *1
int[] a=new! int[8]; //dynamically allocated (automatic lifetime, *1)
int[] a=new int[8]; //dynamically allocated (global lifetime, *2)
*1: These two cases are "mostly equivalent" in terms of semantics,
though the former is "less awkward" and more likely to be handled
efficiently.
*2: BS2 requires 'delete', else the array will be leaked.
Note that, unlike C, 'int[]' and 'int*' represent different concepts,
where 'int*' is a bare pointer (like C), and 'int[]' will be a tagged
type that also does bounds-checks and dynamic type-conversion checks
(whereas pointer casts may be done freely, and otherwise behave mostly
like in C). Unlike C#, "unsafe" blocks aren't really a thing (the
compiler can figure this part out easily enough on its own).
There was a consideration for:
int[] a=new(ztag) int[8];
Which would then assign the array to a given zone.
And, the potential gotcha if a person tries using BS2 and expecting
something like C# or Java, in that BS2 does not use automatic garbage
collection.
Generally, it exists more alongside C in my case (semi-competes with C,
but I am still mostly using C in my ISA project). I don't really use C++
much though, and BGBCC's C++ support is too limited to really be all
that useful (though, did recently get partial support for C++ templates).
In BGBCC's case, all of these languages use the same underlying compiler
machinery, mostly enabling/disabling different parts of the parser and
similar depending on which language it is compiling.
And, for the codebase's origins originally as an interpreter for a
terrible JavaScript knock-off, it hasn't done too horribly...
In some ways though still more like a JS interpreter hacked to function
as a C compiler, than a "proper" C compiler though.
It has its funkiness; doing "static libraries" by loading in big blobs
of stack-oriented bytecode rather than linking in object files, ... But,
alas.
> I suspect that if a program is actually /failing/ due to garbage
> collection, rather than just having glitches, it is because someone is
> putting too much in the clean-up code or destructors. It's fine to use
> if for recycling memory, but if you use it for other acquired resources
> such as file handles, GUI handles, locks, etc., then things can go
> unexpectedly wrong - usually not in testing, but after delivery to the
> customer.
>
Apparently this is an annoyingly common practice.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
“Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Lynn McGuire <lynnmcguire5@gmail.com> - 2022-09-21 14:04 -0500
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-21 12:28 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-22 06:16 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 09:45 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Single Stage to Orbit <alex.buell@munted.eu> - 2022-09-22 09:42 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 11:16 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-22 16:48 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 23:12 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-23 01:40 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-09-26 02:07 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-26 08:42 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be Muttley@dastardlyhq.com - 2022-09-26 15:24 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? The Real Non Homosexual <cdalten@gmail.com> - 2022-10-10 19:12 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-22 09:41 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-22 16:46 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? gazelle@shell.xmission.com (Kenny McCormack) - 2022-09-22 16:15 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 20:43 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-22 20:15 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 22:56 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bart <bc@freeuk.com> - 2022-09-22 23:15 +0100
g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] Ralf Goertz <me@myprovider.invalid> - 2022-09-23 13:44 +0200
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] Bart <bc@freeuk.com> - 2022-09-23 13:53 +0100
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] David Brown <david.brown@hesbynett.no> - 2022-09-23 15:31 +0200
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] David Brown <david.brown@hesbynett.no> - 2022-09-23 15:53 +0200
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] Ralf Goertz <me@myprovider.invalid> - 2022-09-23 16:21 +0200
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] David Brown <david.brown@hesbynett.no> - 2022-09-24 17:05 +0200
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] red floyd <no.spam.here@its.invalid> - 2022-09-24 12:33 -0700
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Muttley@dastardlyhq.com - 2022-09-25 08:45 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-23 00:08 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-23 07:45 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Paavo Helde <eesnimi@osa.pri.ee> - 2022-09-23 12:13 +0300
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-23 10:01 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-23 11:58 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:01 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-09-26 02:03 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-23 13:32 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? red floyd <no.spam.here@its.invalid> - 2022-09-23 14:43 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-23 07:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-23 11:15 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-23 12:35 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-23 12:44 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:09 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-24 13:25 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:13 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-26 10:44 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-27 06:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2022-09-27 09:56 -0600
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-27 10:50 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-09-26 01:57 -0400
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2022-09-22 14:01 +0000
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Ben Collver <bencollver@tilde.pink> - 2022-09-22 15:19 +0000
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” gazelle@shell.xmission.com (Kenny McCormack) - 2022-09-22 15:23 +0000
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-22 12:13 -0700
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Andrea Biscuola <a@abiscuola.com> - 2022-09-22 20:32 +0200
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” scott@slp53.sl.home (Scott Lurndal) - 2022-09-22 19:01 +0000
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Richard Harnden <richard.nospam@gmail.com> - 2022-09-22 17:36 +0100
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-23 03:17 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-23 07:50 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-23 13:37 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:19 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-26 13:55 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 14:31 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bart <bc@freeuk.com> - 2022-09-26 16:05 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-27 06:36 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 11:21 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-27 13:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bo Persson <bo@bo-persson.se> - 2022-09-27 16:53 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-28 10:32 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-27 18:18 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Paavo Helde <eesnimi@osa.pri.ee> - 2022-09-27 22:32 +0300
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-27 23:52 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-27 19:57 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 00:03 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-09-28 01:30 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 08:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 14:18 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 15:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-09-28 13:15 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 23:38 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-29 11:46 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-29 17:58 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-29 20:45 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-30 17:20 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Paavo Helde <eesnimi@osa.pri.ee> - 2022-09-30 20:59 +0300
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Michael S <already5chosen@yahoo.com> - 2022-10-01 11:40 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-10-02 13:38 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-02 13:00 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-10-02 16:20 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-30 09:17 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-30 16:39 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-10-01 12:47 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 14:17 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-28 09:40 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Richard Damon <Richard@Damon-Family.org> - 2022-09-28 07:56 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-28 15:50 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 14:21 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 16:17 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 16:56 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 18:48 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-29 11:50 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Richard Damon <Richard@Damon-Family.org> - 2022-09-28 19:33 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? rbowman <bowman@montana.com> - 2022-09-26 09:04 -0600
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 11:27 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bart <bc@freeuk.com> - 2022-09-27 12:41 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-27 15:22 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 18:13 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 16:50 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? rbowman <bowman@montana.com> - 2022-09-27 08:11 -0600
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 18:10 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? rbowman <bowman@montana.com> - 2022-09-27 17:30 -0600
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 00:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-28 11:00 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-28 13:33 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Manfred <noname@add.invalid> - 2022-09-25 19:31 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-26 04:53 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-26 08:55 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? BGB <cr88192@gmail.com> - 2022-10-01 16:07 -0500
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Opus <ifonly@youknew.org> - 2022-09-23 18:32 +0200
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-09-26 02:08 -0400
csiph-web