Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: "A diagram of C23 basic types"
Date: Sat, 5 Apr 2025 17:10:18 -0500
Organization: A noiseless patient Spider
Lines: 344
Message-ID: <vss9r7$3bs2o$1@dont-email.me>
References: <87y0wjaysg.fsf@gmail.com> <vsj1m8$1f8h2$1@dont-email.me>
 <vsj2l9$1j0as$1@dont-email.me> <vsjgk0$207gb$1@paganini.bofh.team>
 <vsjkc8$252sk$1@dont-email.me> <vsk5h5$2kpbg$3@dont-email.me>
 <vsn3vu$1rigp$1@dont-email.me> <vso9ju$352et$1@dont-email.me>
 <vsoc2k$367mr$1@dont-email.me> <vsoc85$37e62$1@dont-email.me>
 <vsons8$3htha$3@dont-email.me> <85zfgvivkt.fsf@nosuchdomain.example.com>
 <vsrihl$2jlgk$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 06 Apr 2025 00:11:52 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="91cbb3cfceb38cfe3d9b8aab06b7536c";
	logging-data="3534936"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/+YFIv5QhlRIVTIvFQdI9+fqYHDFMpGug="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:nrGEzapVLyjar9gpz441rsF9S90=
In-Reply-To: <vsrihl$2jlgk$1@dont-email.me>
Content-Language: en-US

On 4/5/2025 10:34 AM, David Brown wrote:
> On 04/04/2025 21:18, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> It is easy to write code that is valid C23, using a new feature copied
>>> from C++, but which is not valid C++ :
>>>
>>>     constexpr size_t N = sizeof(int);
>>>     int * p = malloc(N);
>>
>> It's much easier than that.
>>
>>      int class;
>>
>> Every C compiler will accept that.  Every C++ compiler will reject
>> it.  (I think the standard only requires a diagnostic, which can
>> be non-fatal, but I'd be surprised to see a C or C++ compiler that
>> generates an object file after encountering a syntax error).
>>
>> Muttley seems to think that because, for example, "gcc -c foo.c"
>> will compile C code and "gcc -c foo.cpp" will compile C++ code,
>> the C and C++ compilers are the same compiler.  In fact they're
>> distinct frontends with shared backend code, invoked differently
>> based on the source file suffix.  (And "g++" is recommended for C++
>> code, but let's not get into that.)
>>
>> For the same compiler to compile both C and C++, assuming you don't
>> unreasonably stretch the meaning of "same compiler", you'd have to
>> have a parser that conditionally recognizes "class" as a keyword or
>> as an identifier, among a huge number of other differences between
>> the two grammars.  As far as I know, nobody does that.
> 
> Mr. Flibble's universal compiler?  :-)
> 

FWIW, BGBCC does actually handle multiple languages in the same parser 
(*1), but it is a hand-written recursive descent parser, so I don't need 
to care as much about minor syntactic differences (it can check which 
language is being compiled and enable/disable features as needed).

Though, language-specific behavior is a little more tricky in the 
tokenizer because this tends to be more performance-sensitive, but 
luckily the languages have mostly similar tokenization rules.


*1: Namely:
   C (main language used in current projects)
     C89, C99 (mostly), assorted newer features.
   BGBScript (not used as much now, kinda resembles ActionScript)
     It is more or less in the JavaScript/ECMAScript family.
     Most directly tied back to ECMAScript3 and ActionScript3.
       Later JS went in different directions.
     No GC, may need to "delete" stuff to not leak.
       Supports automatic and zoned memory lifetimes.
     Default is to use default or auto-typing, but supports static.
       "var i:int;" or "var i:Integer;" or similar.
   BGBScript2
     Switched to a more Java-like syntax, primarily static-typed.
       Also has some features in common with C#.
       Retains ability to use dynamic types or similar if desired.
     No GC.
       Uses a mix of manually, automatic, and zoned memory management.
   Java (sorta, not really used)
     Mostly covers Java 1.1 syntax;
       Eg: It predates the addition of generics, etc.
     Lacks a garbage collector though.
       Will need an Object.delete() to not leak.
       Had previously wrote a JavaME style library.
   C# (also sorta, also not used)
     Also limited to early C# syntax (no generics/...).
     Also no GC.
     Nor any of the runtime library.
   C++ (also sorta)
     It is similar to Embedded C++, but with namespaces.
     Lacks proper multiple inheritance.
       Single inheritence with abstract base classes
         (the abstract classes are understood as interfaces).
     Mostly doesn't support templates (partly added, mostly untested).
     Roughly early 90s level features.
     Pretty much none of the standard library.

In the case of BS2 / Java / C# / EC++, there was enough overlap to where 
most of the same mechanisms could address the languages with minor 
syntactic reskinning. Most of the rest is common among C-family languages.

Going further up the ladders (for Java, C#, or C++) would be a big 
uphill battle, and not really worth it.

Doesn't make as much sense to advertise support for these languages if 
limited to very limited forms.

Can note that the original ancestor language (what BGBCC was before it 
was a C compiler) was originally BGBScript, which, as can be noted, was 
originally inspired by JavaScript, which along with XML, were hot new 
things back when I was in high-school, where the origins of what became 
BGBCC got started, though BGBCC proper didn't get started until I was 
taking college classes. However, it didn't initially live up to my hopes 
(*2), so I had partly shelved it until my current project got started 
(nearly a decade ago now), where BGBCC has ended up playing a much more 
prominent role.


*2: Early on, I had wanted to use it like a dynamic C compiler for 
scripting inside of my 3D engine (partly inspired by Quake 3 and Doom 3; 
before pivoting over to copying Minecraft). I soon realized that C 
wasn't a great language for this sort of scripting, and returned at the 
time mostly to using my JS based language (which had since forked off 
into a separate VM), which then started pulling some features from 
ActionScript.

I then later stopped working on this 3D engine, and wrote another 
shorter-lived 3D engine with the purpose of it being smaller, faster, 
and less complicated. For this, had created the BS2 language, but in 
some ways BS2 was less good as a scripting language than its predecessor 
(but, was better at things like "implementing stuff", so a lot of the 
higher-level parts of the engine ended up using this; with mostly the 
renderer, VFS, and VM and similar, remaining in C).

Then I switched to doing CPU ISA design and FPGA stuff.

Wrote another smaller 3rd Minecraft like engine, but mostly to try to be 
lightweight enough to run on a 50 MHz CPU and under 60MB of RAM (and 
using raycasts for visibility determination rather than drawing 
everything within a given radius).

This one was plain C, and used a similar chunk format to the prior, just 
mostly switching to a smaller region size (and switching from a 
Rice-coded LZ scheme to a byte-oriented LZ).
   Where:
     Chunks were 16x16x16 with an index into a table of blocks.
       We can assume fewer that 256 unique blocks per chunk.
       Each block was 64 bits in 2nd engine, 32 bits in 3rd engine.
     In storage, these are LZ compressed and stored into a "region file".
     My 2nd engine used 16x16x16 chunks per region (256x256x256 cube).
       Chunk LZ: AdRice+STF based.
     My 3rd engine used 8x8x8 chunks per region (128x128x128 cube).
       Chunk LZ: RP2 (byte based, sorta like LZ4)
     Regions being theoretically in a 3D grid, but 2D in practice.
     2nd engine: generated/drew meshes for every chunk in-radius.
       Every in-radius chunk also was fully loaded into RAM.
     3rd engine: Used raycasts, only built mesh for visible terrain.
       Mostly only visible/active chunks get fully loaded.
       If no mobs are there, and no raycast reaches it, it is not loaded.
   Data Storage:
     2nd engine: EXPAK (custom, like simplified ZIP, Deflate based).
       Images: BMP, custom codecs.
       Audio: WAV (modified IMA ADPCM)
     3rd engine: WAD4 (like WAD2, but 32-byte names, and directories).
       Images: DDS (mostly DXT1), BMP
       Audio: WAV (A-Law, IMA ADPCM)

Contrast, 1st engine:
   Chunks were 16x16x128, regions 32x32, mostly like older Minecraft.
     Chunks were compressed with RLEW (same algo as Wolf3D and ROTT).
   Data was stored in ZIP;
   Textures were mostly stored in a modified T.81 JPEG
     (extended with optional Alpha channel).
     Animated textures used repurposed AVI (sometimes MJPG).
   Audio: Also ADPCM? (I forget now.)
Memory use and performance for first engine was terrible though.

Though, can mostly note that similar tech does seem to come up between 
one project and another.



Note that, technically, the C mode supports dynamic types and similar, 
but with non-standard syntax, eg:
   __variant obj = (__variant) { .x=3, .y=4 };
For a JavaScript style ex-nihilo object.

Though, there is an implicit downside:
Using dynamic types will come with a performance penalty, as there is 
basically no way to avoid this stuff being slow (if static types are 
========== REMAINDER OF ARTICLE TRUNCATED ==========