From: cr88192@gmail.com   
      
   On 10/15/2025 11:37 PM, Janis Papanagnou wrote:   
   > On 15.10.2025 03:13, BGB wrote:   
   >> On 10/13/2025 11:29 PM, Janis Papanagnou wrote:   
   >>> (Sorry for the delayed reply; your ~450 lines post was too long for   
   >>> me to consider a timely reply.)   
   >   
   > (Now ~800 lines; it escalates.)   
   >   
   >>>   
   >>> On 09.10.2025 05:49, BGB wrote:   
   >>>> On 10/8/2025 2:04 PM, Janis Papanagnou wrote:   
   >>>>> On 08.10.2025 19:29, BGB wrote:   
   >>>>>> On 10/8/2025 8:59 AM, Janis Papanagnou wrote:   
   >   
   >> [...]   
   >>   
   >> Well, and for a given Cygwin install attempt, whether or not "g++" would   
   >> work, etc, was a bit like playing roulette.   
   >   
   > I didn't "like" Cygwin, but also never had any "roulette" experience.   
   >   
      
   Can't say, but I had issues with "g++" on Cygwin.   
   Usually, "gcc" still worked fine, so long as it was used to compile C.   
      
   >>   
   >>>> [...]   
   >>>>   
   >>>> In most cases, it left C as a more preferable option.   
   >>>> C can be made to do the same stuff at similar performance, with often   
   >>>> only minimal difference in expressive power.   
   >>>   
   >>> The problem is, IMO, rather that "C", in the first place, doesn't   
   >>> compare to C++ in its level of "expressive power".   
   >>   
   >> ?...   
   >>   
   >> I have yet to find much that can be expressed in C++ but is not also   
   >> expressible in C.   
   >   
   > You may adhere to another sort of expressiveness than I. (For me   
   > assembler, for example, is not more expressive than "C".) It's all   
   > about expressing "complex" things in easy ways.   
   >   
      
   Assembler is very expressive.   
      Concise, or portable, it is not...   
      
      
   Contrast is, say, BASIC, where the things it can do can often be done in   
   comparably few lines, but it often doesn't take long to run into limits   
   as to what can be expressed in the language.   
      
      
   Well, except in one project where I had made some funky extensions to   
   BASIC and then proceeded to use it for CSG tasks. Though, in the   
   context, I already had a BASIC interpreter, but wanted to do something   
   similar to OpenSCAD, but it was a lot more of a "quick and dirty"   
   solution to glue OpenSCAD functionality onto BASIC than to write a SCAD   
   interpreter.   
      
   Ironically, the BASIC code ended up being more concise than the SCAD as   
   well, but "very weird".   
      
   This dialect ended up with wackiness like:   
      box1n=(csgaabb mins=[-15,-4,-4],maxs=[15,4,4],color=0x55AAFF)   
      box3=(csgunion box1,box2)   
   And:   
      temp neck1=(gosub neck0 offs=[0,0,48])   
      
   With the parenthesis allowing some statement-context keywords to be used   
   as expressions (such as GOSUB).   
      
   No proper functions or structured programing, mostly:   
      GOTO label   
      GOSUB label   
      IF cond THEN GOTO label   
      
   Also ended up being dynamically scoped, with each environment frame   
   existing between GOSUB/RETURN pairs (contrast traditional BASIC being   
   global-scoped). Though, ended up label-based rather than using line numbers.   
      
   Why BASIC? Mostly because the language is well suited to doing a small   
   interpreter (in this case, roughly 1500 lines of C).   
      
   IIRC, was initially around 1000 lines, but the stuff for   
   statements-as-expressions, dynamic scope, etc, added roughly 500 lines.   
      
   Doing a structured BASIC (more like QBasic) would have required a more   
   complex interpreter design.   
      
      
      
   >> The main things that are fundamentally different, are things like   
   >> Exceptions and RTTI, but even in C++, these don't come free.   
   >   
   > Back then they said that exceptions come for "almost free" (or so);   
   > I've never counted the seconds difference, since our project goals   
   > and priorities were lying on other factors.   
   >   
   > RTTI, OTOH, I rarely used in the first place. Part of it was due to   
   > my design principle to avoid casts; here (WRT RTTI), dynamic casts.   
   > This features wasn't often used in our projects.   
   >   
      
   The usual cost of exceptions is, say:   
      You need a table to map program locations to exception entry points;   
      You need exception unwinders, even if mostly no-op stubs;   
        Though, you might also need the handlers to call destructors, etc.   
      Some provisions need to be made for unwinding the stack.   
      
   The performance cost is usually fairly small, but it has a non-zero cost   
   on code footprint.   
      
   So, say, there is a delta of a few % or so on the size of the binary   
   based on whether or not exceptions are disabled.   
      
      
   The cost of RTTI is usually that it adds additional metadata structures   
   that are typically pointed to by the first entry of the VTable (with the   
   second entry usually holding an offset to be added to the object-address   
   during method calls to get to the proper address for 'this' within the   
   called method, *).   
      
      
   *: Usually still applies to interfaces in a single-inheritance model,   
   but is N/A for normal base classes. In C++ this would generally be   
   required for all method calls because any given base-class could   
   potentially be used as a secondary base class in a multiple-inheritance   
   pattern.   
      
   This potentially adds the cost of a memory load and an ADD instruction   
   or similar to each virtual method call.   
      
      
   >> Though, if exceptions are implemented using an approach similar to VEH   
   >> in the Windows X64 ABI, it is at least modest.   
   >>   
   >>   
   >>>>   
   >>>> And, the main "powerful" tool of C++, templates,   
   >>>   
   >>> (IMO, the main powerful tool was primarily classes, polymorphisms,   
   >>> also [real] references.)   
   >>   
   >> These can be done in C via manually written vtables, and passing the   
   >> address of a variable.   
   >   
   > (Yes, and you can also do it in assembler. - But that's not the point   
   > of using higher level structuring features. - Frankly, I'm so stumped   
   > that you wrote such a strange thing that I suppose it makes no sense   
   > to discuss that point further with you; our views, it seems, are here   
   > so fundamentally different, obviously.)   
   >   
      
   Possibly.   
      
      
   Often there does end up being a non-zero amount of dealing with OO stuff   
   in assembler. For example, in my project I had used some COM-like   
   interfaces for part of the system-call mechanism. Some of the logic for   
   mapping COM method calls over a system call being written in assembler.   
      
   Well, actually, there are several versions, mostly to there being   
   several ISAs in use (both my own ISAs and RISC-V).   
      
      
   Granted, one wouldn't usually want to do OO programming in assembler in   
   most other contexts.   
      
   Where, say, one merit of C here being its higher level of portability if   
   compared with assembler.   
      
      
      
   >> [...]   
   >>   
   >> We can do OO, just using a different approach, say:   
   >> [...]   
   >   
   > *shudder*   
   >   
   >> It all works, and doesn't require significantly more LOC than it would   
   >> have in C++.   
   >>   
   >>>>   
   >>>> Though, similar was often a problem in my other language design   
   >>>> attempts: The most efficient way to do things was often also the C way.   
   >>>   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)