On 07/07/2021 13:09, Thomas Koenig wrote:
> David Brown <david.brown@hesbynett.no> schrieb:
>> On 06/07/2021 08:48, Thomas Koenig wrote:
>>> BGB <cr88192@gmail.com> schrieb:
>>>> On 7/4/2021 11:59 PM, Thomas Koenig wrote:
>>>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>>>
>>>>>> Prolog is the perfect tool for Prolog-shaped problems. As is Snobol for
>>>>>> the Snobol-shaped.
>>>>>
>>>>> Some people who don't like C++ say that C++ is the perfect tool
>>>>> for thumb-shaped problems :-)
>>>>>
>>>>
>>>> Main problems I have with C++ ATM:
>>>> Compiler would be too complicated, don't want to bother with this;
>>>
>>> Certainly correct.
>>>
>>> C++ has a way of accumulating features because somebody on the
>>> commitee (usually representing some company) feels that they
>>> need something.
>>>
>>> Modules are an example. I attended a talk at a GNU cauldron
>>> where somebody seriously suggested doing a http request to
>>> an oracle as part of the compilation process.
>>>
>>> This was to solve the problem of "which file defines which module".
>>> When I asked how the oracle should know, the answer was basically
>>> "not my department".
>>
>> Modules (or units, or whatever a language wants to call them) are always
>> difficult if there is not a one-to-one correspondence between module
>> names and file names.
>
> I certainly know that, Fortran also has modules.
>
> The problem is that, when C++ added the new module feature, the
> major problems this introduced were well known (including that
> modules were a totally different thing from namespaces, and that
> a #define outside a module should have an effect inside the used
> module).
>
> The fact that this feature was approved anyway points towards
> a broken language design process.

There are plenty of things that have gone wrong in the C++ (and C)
design process. For example, there are a number of things in the
language and the libraries that exist solely because of oddities in MS's
tools and OS. There are lots of things that are compromises that are
not great for anyone. There are things that were perhaps a good idea at
the time, but with long-term costs and limitations that outweigh the
benefits. I think a lot of that is inevitable in a language that has
been around for a very long time, and is used by such an extraordinary
wide range of developers. (As Stroustrup has said, there are only two
kinds of languages - those that people complain about, and those that no
one uses.)

I don't know enough of the details of modules in C++ to say what I think
is right or wrong about them.

>
>> C++ suffers from historical baggage here, going
>> right back to the early days of C. There really is no good way out of
>> this while getting the features people want (including being able to
>> treat existing headers as modules, during transitions to modules). But
>> to a very large extend, programmers don't care how the details of the
>> compiler works, as long as it works efficiently and correctly.
>
> I would certainly be concerned if the compiler I used suddenly started
> making http requrests to god knows where.
>

/You/ might not know where, but other people do - the suggestion is for
the "oracle" running on /your/ computer, accessible only to compilers
running locally. I believe (again, I don't know the details) the idea
is to make it possible for different compilers to share the same oracle,
but it is all on your own system. There are plenty of languages that
have centralised repositories on the Internet which are accessible as
part of build processes - C++ is not one of them.

>> No one
>> (except compiler writers and maintainers) cares that many C++ compilers
>> today are composed of multiple executables, that they generate assembly
>> rather than object code directly, or how they interact with linkers for
>> link-time optimisation. No one using a C++ compiler with modules will
>> care how the right module is found, as long as it /is/ found.
>>
>>>
>>> Everybody agrees that using the whole of C++ for a project is
>>> madness and a sane subset is required, but apparently not two
>>> people agree on what this sane subset should be.
>>
>> You can say that about /any/ language. Can you give an example of a C
>> project that uses all of C's language features?
>
> There is no particular reason to restrict the use of C to a subset
> of the language, because the language is small enough.
>

Sure there is. In my line of work, malloc/free is regularly banned.
Printf and friends might be banned. Floating point might be banned.
There are countless ways of writing code in C that are restricted by
code style guides. People who program C seriously will invariably
restrict themselves to a subset - whether they do so explicitly (with
formal style guides, compiler warnings, etc.) or simply because "this is
the way you write good code".

> With C++, this is different.

Nope, not at all. At most, it is just a matter of proportions.

>
>> Can you give an example
>> that uses more than perhaps 5% of the C standard library? Languages and
>> their libraries cover features that people want and need (and yes,
>> sometimes the designers make mistakes and include stuff that later turn
>> out not to be popular). But no one expects any given person to use all
>> the features - with many features only being useful to a very small
>> proportion of users.
>
> That is a big problem.

It hasn't been a problem for C for 50 years - the vast majority of C
programmers neither understand nor use the entire language in all its
details.

>
> C.A.R. Hoare of quicksort fame expressed this better than I could ever
> hope to do in his "Hints on Programming Language Design":
>
> # Some language designers have replaced the objective of simplicity
> # by that of modularity, by which they mean that a programmer who
> # cannot understand the whole of his language can get by with a
> # limited understanding of only part of it. For programs that work
> # as the programmer intended this may be feasible; but if his program
> # does not work, and accidentally invokes some feature of the language
> # which he does not know, he will get into serious trouble. If he is
> # lucky, the implementation will detect his mistake, but he will not
> # be able to understand the diagnostic message. Otherwise, he is even
> # more helpless. If to the complexity of his language is added the
> # complexity of its implementation, the complexity of its operating
> # environment, and even the complexity of institutional standards
> # for the use of the language, it is not surprising that when faced
> # with a complex programming task so many programmers are overwhelmed.
>

This is /always/ a problem. Hoare was writing here in a time where
programs were much smaller and did much less, and it was possible to
have a full overview. That time is /long/ gone.

If you program in C, even if you are one of the 0.1% that can claim to
have a pretty complete understanding of the language, standard library,
and target and compiler details on the particular implementation you are
using, you haven't a hope of having a complete knowledge of the OS API's
for system you are using.

>> The bigger the language and library, the greater this effect - but it is
>> not by any means a C++ effect. Basically, you are complaining that C++
>> is big.
>
> It is big, and it is a piecework of questionable features whose
> interactions are poorly understood.
>
>> It's like complaining about the range of shops in a city.
>
> That is a false analogy. The problem is that, in a project, people
> a) use features which they do not understand, or b) have to work
> with other people's code which uses features they do not understand.
>

That's a people problem, not a language problem. Can you tell me you
have never had to look at C code that was incomprehensible?

> If, by buying from one shop in the city, I would force everybode
> else to buy from the same shop, if they wanted it or not, and
> if they didn't even know what they were buying and whay, and then would
> be forced to check these purchases for defects and return them
> to the store accordingly... that would be a bit more apt.
>
>> Perhaps you
>> come from a small village, where there are only a dozen shops and
>> everyone uses them all. But here in the city there are so many - it
>> would be madness to try to look in them all, but no two city dwellers
>> can agree on which subset of shops are useful.
>>
>>
>>>
>>> And of course, if you're a compiler writer, you cannot restrict
>>> yourself to a subset of a language.
>>>
>>
>> Writing a good compiler is hard. Writing a good compiler for a big,
>> complex language is even harder - and even more effort. A single person
>> can perhaps write a passable C compiler with enough dedication - C++ is
>> far too big for that.
>
> That is correct. For Fortran 95, a single person can do it, but
> that single person has to be extremely good; so far, only two
> people have managed it effectively on their own, Malcolm Cohen
> and Andy Vaught. And both of them got around the code generation
> bit - Malcolm Cohen (the primary author of NAG's compiler) chose
> to compile to C as an intermediate language, and Andy Vaught had
> help with the scalarizer and with the glue code to gcc (which is
> why g95 stagnated after the fork with gfortran).
>

On 7/7/2021 4:31 AM, David Brown wrote:
> On 05/07/2021 19:49, BGB wrote:
>> On 7/4/2021 11:59 PM, Thomas Koenig wrote:
>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>
>>>> Prolog is the perfect tool for Prolog-shaped problems. As is Snobol for
>>>> the Snobol-shaped.
>>>
>>> Some people who don't like C++ say that C++ is the perfect tool
>>> for thumb-shaped problems :-)
>>>
>>
>> Main problems I have with C++ ATM:
>>   Compiler would be too complicated, don't want to bother with this;
>
> C++ compilers are certainly complicated. It's a big language, and it is
> a demanding language for compilers. Parsing is hard, with lots of
> conditional keywords, and you need to be happy with heavy inlining or
> the results will be hopelessly inefficient.
>

Yeah.

There are reasons why I have not been making more effort to try to add
C++ support to BGBCC. I can support a limited subset, but going much
beyond this would be an uphill battle.

I am generally working though towards at least trying to support C
effectively. Programs generally work, though there are corner cases
which still aren't supported effectively.

Eg, recently I had a few bugs which were being an issue and leading to a
program having different behavior in BGBCC vs GCC or Clang.

Eventually, I found a few bugs, among them was things like:
j = 9999U / i;
Where 'i' and 'j' are 'int'.

Where the former value would lose its unsigned status resulting in the
expression being evaluated as 'int' rather than 'unsigned int', which
would lead to different behavior if 'i' was negative.

One issue this caused was that when demos desynced in Doom, the sequence
of events would diverge between compilers.

I had previously found another case where BGBCC, GCC, Clang, and MSVC,
would all desync in slightly different ways, but found out that this was
related to Z_Malloc, in particular some code (somewhere in the engine)
is accessing data past the end of the allocated buffer, but adding 24
bytes of zero padding on the end of every Z_Malloc seems to fix this (*).

Side note that I was already aware of the "REJECT lump size" issue, and
am using a trick similar to several other Doom ports (one allocates a
buffer at the proper size, and then padding out the lump by trying to
fake what the MS-DOS version of Doom would have put there).

*: Though, this does imply that whatever is in the memory that effects
the behavior, itself varies based on the compiler, where presumably if
all the compilers were generating code that were behaviorally
equivalent, this should not happen (well, excluding things like
uninitialized variables or similar), probably would need to sort through
and clean up the storm of warnings I get from GCC and Clang at some point...

I have had fewer issues of this sort in my Heretic and Hexen ports,
which seem not to depend on out-of-bounds memory access for demo
playback behavior.

At present, I still haven't resolved the issue of differing demo desync
behavior in ROTT, but seemingly ROTT has a near endless supply of memory
out-of-bounds bugs.

To get semi-correct demo playback from ROTT, at least in my MSVC build,
had to detect some of these out-of-bound accesses and try to fake the
behavior of what the original logic would have seen on a 32-bit machine.

I haven't yet gotten around to getting ROTT to build with GCC or Clang,
this is still a TODO issue.

>>   Multiple inheritance needlessly complicates stuff;
>
> I'm not a fan of multiple inheritance myself. In particular, inheriting
> data from different places is likely to cause trouble, and multiple
> inheritance of classes with virtual methods is very rarely worth the
> complication and confusion. CRTP, however, can be really neat (for
> compile-time polymorphism). In one project I am working on, I have
> templates for GPIO pins, arranged with inheritance:
>
> template <int gpio_bank, int gpio_pin, bool output = false>
> class GpioInOut :
> public GpioIn<gpio_bank, gpio_pin>,
> public GpioOut<gpio_bank, gpio_pin>
> ...
>
> It works neatly, the source code is clear, it is hard to use incorrectly
> as you can't mix up pins or accidentally drive an input-only pin, and
> the resulting code is as efficient as possible since the compiler has
> all the details of pin numbers, addresses, etc., on hand when compiling
> "green_led.on();".
>
> Multiple inheritance is a powerful tool, and is often used very poorly -
> but it /can/ be used very well.
>

OK.

>>   Templates needlessly complicate stuff;
>
> Templates change the nature of the language significantly. If you still
> think of C as being a language where a function in the source code
> corresponds precisely to a function in the generated assembly, and you
> think of C++ as being like C with extra features, you will not be able
> to handle templates. Of course, it is a long time (perhaps three
> decades) since C has had complete correspondence in functions - but
> often you can pretend it works that way when it is useful.
>

Yeah. I am primarily a C programmer.

Generally this is because either the extra features C++ had added were
not sufficiently compelling, or because something else created
roadblocks that made it effectively unusable (or put constraints on it
that rendered it effectively moot).

> In C++, however, the move has been towards higher level coding.
> Templates generate functions and classes. They let you write more
> general code, with a lot more flexibility.
>
> Again, templates are powerful and can be abused, and template coding can
> certainly be complicated. (It's got much easier in newer C++
> standards.) But to suggest they are "needless" is tantamount to
> admitting you really do not understand the language at all.
>

I understand a subset of C++, namely the subset where one treats it
mostly like C with classes, namespaces, and operator overloading...

Though, one can note that much of the language as it exists in its
present form depends on templates, and if one omits them it mostly
reverts back to a more C-like subset.

There was EC++, which was also such a subset, however EC++ was actually
more limited than I would aim for.

For example, I consider the added complexity of namespaces to be
justifiable (since it has something to offer, and is one of the few C++
features which delivers on the promise of not having any runtime
performance impact).

>>   The C++ standard library and STL is kinda a trash fire;
>
> There is plenty to like, and plenty to dislike in the C++ standard
> library. It contains a great deal of functionality that few people will
> ever need, and that does complicate things. And it suffers from
> backwards compatibility (as does the language) - once something is in
> the language, or the library, it is hard to remove it even if better
> methods have been found.
>

Some of it was older stuff that seemed more like "language feature in
search of a use-case" than because of it making sense to do it that way.

Eg: overloading operators to add new types and make them behave kinda
like built-in types, makes sense. Overloading operators for sake of
doing File IO or formatted printing, ..., yeah...

It is possibly telling that two of its major 'successors' (Java and C#),
either eventually or initially, mostly went back to doing it in a
similar way to C.

>>   ...
>>
>> Too many "features" exist essentially as a way to play whack-a-mole with
>> the consequences of other features.
>> If you leave out multiple inheritance and templates, many of the rest of
>> the language features go "poof" and disappear.
>>
>
> If you leave out templates, the /language/ goes "poof" and disappears.
> All you are left with is C with better structuring and a bit more type
> safety - and you are back to copy-and-paste and macros for anything generic.
>

Well, whether it is most of the language features going poof and
disappearing, or the whole language going poof and disappearing, is a
possible subject of interpretation.

> It's like saying FORTRAN would be simpler without arrays.
>
> (There was an attempt at a C++ subset that simplified and restricted the
> language, aimed as resource-limited systems - "Embedded C++". It was a
> total and utter failure, and no one used it.)
>

I am aware of it.

Ironically, BGBCC can more or less compile EC++ code, though that
doesn't mean that much mainline C++ code will work with it.

Partly this is because EC++ also happens to mostly fall within the
"common superset" of features which contains both C and BS2...

My compiler also allows using some amount of BS2 features from C (as an
extension), but this does lead to some things being a little uglier.

David Brown <david.brown@hesbynett.no> schrieb:

> I don't know enough of the details of modules in C++ to say what I think
> is right or wrong about them.

Which is a bit my point...

[Oracle during compilation process]

> /You/ might not know where, but other people do - the suggestion is for
> the "oracle" running on /your/ computer, accessible only to compilers
> running locally. I believe (again, I don't know the details) the idea
> is to make it possible for different compilers to share the same oracle,

Not according to the talk the way it was given.

(By the way, the person who gave the talk was a gcc maintainer and
member of the C++ standards committee, so he spoke with some authority).

The idea was "We have a hard problem here, let's kick it upstairs and
not worry about it anymore". How is the Oracle to know?

In other words, introducing networking code for no good reason at all.

> but it is all on your own system. There are plenty of languages that
> have centralised repositories on the Internet which are accessible as
> part of build processes - C++ is not one of them.

And that is surely not a good idea for security or reliability
reasons.

> If you program in C, even if you are one of the 0.1% that can claim to
> have a pretty complete understanding of the language, standard library,
> and target and compiler details on the particular implementation you are
> using, you haven't a hope of having a complete knowledge of the OS API's
> for system you are using.

That can be a problem, but the problem is disproportinally larger when
a language has introduced features at the rate that C++ has.

https://dilbert.com/strip/2001-04-14 might also be appropriate.

>
>>> The bigger the language and library, the greater this effect - but it is
>>> not by any means a C++ effect. Basically, you are complaining that C++
>>> is big.
>>
>> It is big, and it is a piecework of questionable features whose
>> interactions are poorly understood.
>>
>>> It's like complaining about the range of shops in a city.
>>
>> That is a false analogy. The problem is that, in a project, people
>> a) use features which they do not understand, or b) have to work
>> with other people's code which uses features they do not understand.
>>
>
> That's a people problem, not a language problem. Can you tell me you
> have never had to look at C code that was incomprehensible?

Again, it is a matter of degree. Sure, I've read the IOCCC code.

Every programming language has this problem, in general, but the degree
varies a lot, and C++'s extensive feature creep (or feature stampede)
makes the problem _much_ worse than for any other programming language.

There was a serious proposal to break backwards compatibility for C++,
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2137r0.html

Let me quote:

# Our goals are focused on _migration_ from one version of C++ to the
# next rather than _compatibility_ between them. This is rooted in
# our experience with evolving software over time more generally and
# a live-at-head model. Any transition, whether based on backward
# compatibility or a migration plan, will require some manual
# intervention despite our best efforts, due to Hyrum’s Law, and
# so we should acknowledge that upgrades require active migrations.

So, apparently the C++ standards committee itsef is no longer able
to keep features in sync between standards, and the C++ development
process values adding new features over stability. Adding new
features as not to break old behavior requires a lot of thought,
so the preferred choice is not to do it and kick the ball to the
user.

Or, to put it less charitably: This is the victory of the feature
stampede over long-term stability.

Anybody who wants to do a long-term software project in C++ should
think twice after reading this.

On 08/07/2021 08:07, Thomas Koenig wrote:
> David Brown <david.brown@hesbynett.no> schrieb:
>
>> I don't know enough of the details of modules in C++ to say what I think
>> is right or wrong about them.
>
> Which is a bit my point...
>
> [Oracle during compilation process]
>
>> /You/ might not know where, but other people do - the suggestion is for
>> the "oracle" running on /your/ computer, accessible only to compilers
>> running locally. I believe (again, I don't know the details) the idea
>> is to make it possible for different compilers to share the same oracle,
>
> Not according to the talk the way it was given.
>
> (By the way, the person who gave the talk was a gcc maintainer and
> member of the C++ standards committee, so he spoke with some authority).
>
> The idea was "We have a hard problem here, let's kick it upstairs and
> not worry about it anymore". How is the Oracle to know?
>

Maybe you got a different impression, but that sounds to me more like
splitting a difficult task into parts, and letting different groups deal
with those parts while agreeing on an interface between them. Then he
concentrated the talk on the parts he was involved in. It does not
sound at all unreasonable to me.

> In other words, introducing networking code for no good reason at all.

Again, so what? When I do my development, the build process probably
involves dozens of programs. Some communicate with files, some with
pipes, and it would not surprise me if unix sockets are also used. Once
I move on to debugging, there are another dozen programs involved from
different places, and I know for sure that some of them communicate with
TCP/IP networking even on the same host computer. Why would I worry
about it? Networking is just a way of communicating, it is not some
kind of alien technology or Pandora's box.

>
>> but it is all on your own system. There are plenty of languages that
>> have centralised repositories on the Internet which are accessible as
>> part of build processes - C++ is not one of them.
>
> And that is surely not a good idea for security or reliability
> reasons.
>

Any time you get stuff from an external source, you have security
concerns. Any time you are dependent on something beyond your control,
you have reliability concerns. For a great many people, it's fine to
get their software from their distro's repositories with "apt" or "yum".
They trust "pip install" for Python modules, and cpan for Perl
software, and whatever Rust, Go, etc., use. Others don't trust them, or
have elaborate control procedures. Neither security nor reliability are
yes/no absolutes, they are trade-offs for convenience.

>> If you program in C, even if you are one of the 0.1% that can claim to
>> have a pretty complete understanding of the language, standard library,
>> and target and compiler details on the particular implementation you are
>> using, you haven't a hope of having a complete knowledge of the OS API's
>> for system you are using.
>
> That can be a problem, but the problem is disproportinally larger when
> a language has introduced features at the rate that C++ has.
>
> https://dilbert.com/strip/2001-04-14 might also be appropriate.
>

There are lots of programming languages in the world, because there are
lots of use-cases where the balance between different features and
requirements is so varied. Some people need big languages, some people
need small ones, some need high-level, some low-level. Some want
languages that are very stable over time, for which C is a good choice.
Some want new and powerful features, for which C++ (or Python, or Go,
or C#, or many others) are better. I don't know the FORTRAN world, but
I am confident that there will be FORTRAN developers who feel the
language peaked with FORTRAN 77 or FORTRAN 90, and all these newfangled
object-oriented and concurrent features pollute it and over-complicate it.

If C++ is too big and complicated for you, or you don't like a language
that gains new features every three years, use something else. There
are plenty of languages to choose from.

>>
>>>> The bigger the language and library, the greater this effect - but it is
>>>> not by any means a C++ effect. Basically, you are complaining that C++
>>>> is big.
>>>
>>> It is big, and it is a piecework of questionable features whose
>>> interactions are poorly understood.
>>>
>>>> It's like complaining about the range of shops in a city.
>>>
>>> That is a false analogy. The problem is that, in a project, people
>>> a) use features which they do not understand, or b) have to work
>>> with other people's code which uses features they do not understand.
>>>
>>
>> That's a people problem, not a language problem. Can you tell me you
>> have never had to look at C code that was incomprehensible?
>
> Again, it is a matter of degree. Sure, I've read the IOCCC code.
>

"With power comes responsibility - that's why we fear it."

"You can write FORTRAN in any language."

Languages with more features, flexibility and power let you write better
code, or worse code. Yes, there are plenty of people who write
horrendous C++ code - but they would write horrendous code in any language.

> Every programming language has this problem, in general, but the degree
> varies a lot, and C++'s extensive feature creep (or feature stampede)
> makes the problem _much_ worse than for any other programming language.
>
> There was a serious proposal to break backwards compatibility for C++,
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2137r0.html
>
> Let me quote:
>
> # Our goals are focused on _migration_ from one version of C++ to the
> # next rather than _compatibility_ between them. This is rooted in
> # our experience with evolving software over time more generally and
> # a live-at-head model. Any transition, whether based on backward
> # compatibility or a migration plan, will require some manual
> # intervention despite our best efforts, due to Hyrum’s Law, and
> # so we should acknowledge that upgrades require active migrations.
>
> So, apparently the C++ standards committee itsef is no longer able
> to keep features in sync between standards, and the C++ development
> process values adding new features over stability. Adding new
> features as not to break old behavior requires a lot of thought,
> so the preferred choice is not to do it and kick the ball to the
> user.
>

That is a proposal from a group of C++ developers, not the position of
the C++ standards committee.

There would be /huge/ potential benefits from being able to break
backwards compatibility. A great deal of the awkwardness and risky
parts of C++ are due to compatibility with earlier versions of the
language, and with C. Of course there are also great costs involved in
breaking compatibility - and you can be confident that it will not be
done in a way that makes older code inaccessible. We are not going to
find that gcc 16 will only compile C++26 and your C++98 .. C++23 code is
no longer usable.

> Or, to put it less charitably: This is the victory of the feature
> stampede over long-term stability.
>
> Anybody who wants to do a long-term software project in C++ should
> think twice after reading this.
>

They will simply think that you don't like C++, and thus haven't looked
at it much. That's fine - life is too short to learn every programming
language.

On 07/07/2021 21:22, BGB wrote:
> On 7/7/2021 4:31 AM, David Brown wrote:
>> On 05/07/2021 19:49, BGB wrote:
>>> On 7/4/2021 11:59 PM, Thomas Koenig wrote:
>>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>>
>>>>> Prolog is the perfect tool for Prolog-shaped problems. As is Snobol
>>>>> for
>>>>> the Snobol-shaped.
>>>>
>>>> Some people who don't like C++ say that C++ is the perfect tool
>>>> for thumb-shaped problems :-)
>>>>
>>>
>>> Main problems I have with C++ ATM:
>>>    Compiler would be too complicated, don't want to bother with this;
>>
>> C++ compilers are certainly complicated.  It's a big language, and it is
>> a demanding language for compilers.  Parsing is hard, with lots of
>> conditional keywords, and you need to be happy with heavy inlining or
>> the results will be hopelessly inefficient.
>>
>
> Yeah.
>
> There are reasons why I have not been making more effort to try to add
> C++ support to BGBCC. I can support a limited subset, but going much
> beyond this would be an uphill battle.
>
>
> I am generally working though towards at least trying to support C
> effectively. Programs generally work, though there are corner cases
> which still aren't supported effectively.
>

For a one-person toolchain, C is more than big enough!

>
> Eg, recently I had a few bugs which were being an issue and leading to a
> program having different behavior in BGBCC vs GCC or Clang.
>
> Eventually, I found a few bugs, among them was things like:
>   j = 9999U / i;
> Where 'i' and 'j' are 'int'.
>
> Where the former value would lose its unsigned status resulting in the
> expression being evaluated as 'int' rather than 'unsigned int', which
> would lead to different behavior if 'i' was negative.
>
>

The rules for implicit conversions and integer promotions are clear
enough in C - it shouldn't be hard to support them correctly. (I don't
entirely agree with the choices for the rules, but that's another matter.)

>
>>>    Multiple inheritance needlessly complicates stuff;
>>
>> I'm not a fan of multiple inheritance myself.  In particular, inheriting
>> data from different places is likely to cause trouble, and multiple
>> inheritance of classes with virtual methods is very rarely worth the
>> complication and confusion.  CRTP, however, can be really neat (for
>> compile-time polymorphism).  In one project I am working on, I have
>> templates for GPIO pins, arranged with inheritance:
>>
>> template <int gpio_bank, int gpio_pin, bool output = false>
>> class GpioInOut :
>>     public GpioIn<gpio_bank, gpio_pin>,
>>     public GpioOut<gpio_bank, gpio_pin>
>> ...
>>
>> It works neatly, the source code is clear, it is hard to use incorrectly
>> as you can't mix up pins or accidentally drive an input-only pin, and
>> the resulting code is as efficient as possible since the compiler has
>> all the details of pin numbers, addresses, etc., on hand when compiling
>> "green_led.on();".
>>
>> Multiple inheritance is a powerful tool, and is often used very poorly -
>> but it /can/ be used very well.
>>
>
> OK.
>
>
>>>    Templates needlessly complicate stuff;
>>
>> Templates change the nature of the language significantly.  If you still
>> think of C as being a language where a function in the source code
>> corresponds precisely to a function in the generated assembly, and you
>> think of C++ as being like C with extra features, you will not be able
>> to handle templates.  Of course, it is a long time (perhaps three
>> decades) since C has had complete correspondence in functions - but
>> often you can pretend it works that way when it is useful.
>>
>
> Yeah. I am primarily a C programmer.
>
> Generally this is because either the extra features C++ had added were
> not sufficiently compelling, or because something else created
> roadblocks that made it effectively unusable (or put constraints on it
> that rendered it effectively moot).
>

There are times when C is a better choice - being simpler, more
explicit, and easier to follow can help. Other times C++ makes it
easier to express what you want, and lets you write code that is safer
and easier to follow. (And of course, almost any reasonable C code will
have the same meaning in C++, with at most minor adjustments.)

>
>> In C++, however, the move has been towards higher level coding.
>> Templates generate functions and classes.  They let you write more
>> general code, with a lot more flexibility.
>>
>> Again, templates are powerful and can be abused, and template coding can
>> certainly be complicated.  (It's got much easier in newer C++
>> standards.)  But to suggest they are "needless" is tantamount to
>> admitting you really do not understand the language at all.
>>
>
> I understand a subset of C++, namely the subset where one treats it
> mostly like C with classes, namespaces, and operator overloading...
>

You can get far with a subset like that. I'd throw references (lvalue
references, not rvalue references), better const, and scoped enums into
that mix as features that are quite simple to understand and where their
functionality and implementation is obvious.

(And you might want to disable exceptions and RTTI - it is standard
practice on small embedded systems and also in game programming.)

>
> Though, one can note that much of the language as it exists in its
> present form depends on templates, and if one omits them it mostly
> reverts back to a more C-like subset.
>

A lot of features of C++ can be viewed as things you need to /make/ the
libraries or frameworks, rather than what you need to /use/ them. For
example, in any situation where in C you would use an array with a size
that is known at compile time, you can use a std::array from C++ to get
some extra features and type-safety with no overhead. You don't have to
be able to write such template classes in order to use them.

>
> There was EC++, which was also such a subset, however EC++ was actually
> more limited than I would aim for.
>
> For example, I consider the added complexity of namespaces to be
> justifiable (since it has something to offer, and is one of the few C++
> features which delivers on the promise of not having any runtime
> performance impact).
>

Most features of C++ have zero or close to zero overhead - compared to
alternative solutions. For example, virtual functions in C++ have
run-time costs, but they are likely to be lower than a C-style system of
pointers to tables of function pointers doing the same thing.

Real-world comparisons between C and C++ suggest the overhead of C++ is
in the region of a percent or two - with plenty of variation depending
on the type of code. (C++ object files will often be very much bigger
when linking and debug information is still there, and exception tables
can take up a lot of space in binaries in some cases.)

>
>>>    The C++ standard library and STL is kinda a trash fire;
>>
>> There is plenty to like, and plenty to dislike in the C++ standard
>> library.  It contains a great deal of functionality that few people will
>> ever need, and that does complicate things.  And it suffers from
>> backwards compatibility (as does the language) - once something is in
>> the language, or the library, it is hard to remove it even if better
>> methods have been found.
>>
>
> Some of it was older stuff that seemed more like "language feature in
> search of a use-case" than because of it making sense to do it that way.
>
>
> Eg: overloading operators to add new types and make them behave kinda
> like built-in types, makes sense. Overloading operators for sake of
> doing File IO or formatted printing, ..., yeah...

I think the cout-style output is a mixed blessing. It is convenient in
some ways, but fails in others. It is vastly superior to printf in type
safety and flexibility in defining output formats for your own types.
It is vastly inferior for translating format strings, and for modifying
the format of number outputs.

>
> It is possibly telling that two of its major 'successors' (Java and C#),
> either eventually or initially, mostly went back to doing it in a
> similar way to C.
>

(There is a new system of formatted output on its way to the C++ library.)

David Brown <david.brown@hesbynett.no> schrieb:

>> The idea was "We have a hard problem here, let's kick it upstairs and
>> not worry about it anymore". How is the Oracle to know?
>>
>
> Maybe you got a different impression, but that sounds to me more like
> splitting a difficult task into parts,

That wasn't the impression I was getting, especially in the absence
of any suggestion of how to do this.

The talk is on youtube (as are my questions), but I doubt you will
want to go through it :-)

> and letting different groups deal
> with those parts while agreeing on an interface between them. Then he
> concentrated the talk on the parts he was involved in. It does not
> sound at all unreasonable to me.

This guy took it upon himself to do the (partial) implementation in gcc,
using a modified elf format.

There is not "other department" as such in gcc development.

>> That can be a problem, but the problem is disproportinally larger when
>> a language has introduced features at the rate that C++ has.
>>
>> https://dilbert.com/strip/2001-04-14 might also be appropriate.
>>
>
> There are lots of programming languages in the world, because there are
> lots of use-cases where the balance between different features and
> requirements is so varied.

There is also the illusion, harbored by too many people, that they
need a certain programming language that is cool, or that this is
what everybody else does.

And this is where the danger lies with C++, especially when it is
used by scientists with little CS experience and background.

Although, I admit it, Python is far worse than C++ in that respect.

[...]

> I am confident that there will be FORTRAN developers who feel the
> language peaked with FORTRAN 77 or FORTRAN 90, and all these newfangled
> object-oriented and concurrent features pollute it and over-complicate it.

> If C++ is too big and complicated for you, or you don't like a language
> that gains new features every three years,

It's the fact that the language is too big and that the features it adds
are not carefully thought out.

>> Every programming language has this problem, in general, but the degree
>> varies a lot, and C++'s extensive feature creep (or feature stampede)
>> makes the problem _much_ worse than for any other programming language.
>>
>> There was a serious proposal to break backwards compatibility for C++,
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2137r0.html
>>
>> Let me quote:
>>
>> # Our goals are focused on _migration_ from one version of C++ to the
>> # next rather than _compatibility_ between them. This is rooted in
>> # our experience with evolving software over time more generally and
>> # a live-at-head model. Any transition, whether based on backward
>> # compatibility or a migration plan, will require some manual
>> # intervention despite our best efforts, due to Hyrum’s Law, and
>> # so we should acknowledge that upgrades require active migrations.
>>
>> So, apparently the C++ standards committee itsef is no longer able
>> to keep features in sync between standards, and the C++ development
>> process values adding new features over stability. Adding new
>> features as not to break old behavior requires a lot of thought,
>> so the preferred choice is not to do it and kick the ball to the
>> user.
>>
>
> That is a proposal from a group of C++ developers, not the position of
> the C++ standards committee.

Comparing the paper's authors with the WG21 membership has two
people in both: Chandler Carruth and Bryce Adelstein Lelbach.

So, it is certainly a position held by members of WG21. If it
will prevail, I don't know.

> There would be /huge/ potential benefits from being able to break
> backwards compatibility.

Such as the ones experienced by the transition from Python 2 to
Python 3 (ok, that was low).

> A great deal of the awkwardness and risky
> parts of C++ are due to compatibility with earlier versions of the
> language, and with C. Of course there are also great costs involved in
> breaking compatibility - and you can be confident that it will not be
> done in a way that makes older code inaccessible. We are not going to
> find that gcc 16 will only compile C++26 and your C++98 .. C++23 code is
> no longer usable.

Maintaining a different feature set for different language versions
is hard (I know from experience). If you make previous versions
incompatible, (worst case: the same syntax means different things),
that is an even wider field for bugs.

>
>> Or, to put it less charitably: This is the victory of the feature
>> stampede over long-term stability.
>>
>> Anybody who wants to do a long-term software project in C++ should
>> think twice after reading this.
>>
>
> They will simply think that you don't like C++, and thus haven't looked
> at it much.

I didn't mean my text, I meant the text at least co-authored by the
WG21 members.

On 7/8/2021 7:13 AM, Thomas Koenig wrote:

snip

> There is also the illusion, harbored by too many people, that they
> need a certain programming language that is cool, or that this is
> what everybody else does.
>
> And this is where the danger lies with C++, especially when it is
> used by scientists with little CS experience and background.
>
> Although, I admit it, Python is far worse than C++ in that respect.

This statement surprises me. What language do you suggest for such people?

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 08/07/2021 16:13, Thomas Koenig wrote:
> David Brown <david.brown@hesbynett.no> schrieb:
>
>>> The idea was "We have a hard problem here, let's kick it upstairs and
>>> not worry about it anymore". How is the Oracle to know?
>>>
>>
>> Maybe you got a different impression, but that sounds to me more like
>> splitting a difficult task into parts,
>
> That wasn't the impression I was getting, especially in the absence
> of any suggestion of how to do this.
>
> The talk is on youtube (as are my questions), but I doubt you will
> want to go through it :-)
>
>> and letting different groups deal
>> with those parts while agreeing on an interface between them. Then he
>> concentrated the talk on the parts he was involved in. It does not
>> sound at all unreasonable to me.
>
> This guy took it upon himself to do the (partial) implementation in gcc,
> using a modified elf format.
>
> There is not "other department" as such in gcc development.
>
>>> That can be a problem, but the problem is disproportinally larger when
>>> a language has introduced features at the rate that C++ has.
>>>
>>> https://dilbert.com/strip/2001-04-14 might also be appropriate.
>>>
>>
>> There are lots of programming languages in the world, because there are
>> lots of use-cases where the balance between different features and
>> requirements is so varied.
>
> There is also the illusion, harbored by too many people, that they
> need a certain programming language that is cool, or that this is
> what everybody else does.
>
> And this is where the danger lies with C++, especially when it is
> used by scientists with little CS experience and background.
>
> Although, I admit it, Python is far worse than C++ in that respect.
>
> [...]
>
>> I am confident that there will be FORTRAN developers who feel the
>> language peaked with FORTRAN 77 or FORTRAN 90, and all these newfangled
>> object-oriented and concurrent features pollute it and over-complicate it.
>
>> If C++ is too big and complicated for you, or you don't like a language
>> that gains new features every three years,
>
> It's the fact that the language is too big and that the features it adds
> are not carefully thought out.
>
>>> Every programming language has this problem, in general, but the degree
>>> varies a lot, and C++'s extensive feature creep (or feature stampede)
>>> makes the problem _much_ worse than for any other programming language.
>>>
>>> There was a serious proposal to break backwards compatibility for C++,
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2137r0.html
>>>
>>> Let me quote:
>>>
>>> # Our goals are focused on _migration_ from one version of C++ to the
>>> # next rather than _compatibility_ between them. This is rooted in
>>> # our experience with evolving software over time more generally and
>>> # a live-at-head model. Any transition, whether based on backward
>>> # compatibility or a migration plan, will require some manual
>>> # intervention despite our best efforts, due to Hyrum’s Law, and
>>> # so we should acknowledge that upgrades require active migrations.
>>>
>>> So, apparently the C++ standards committee itsef is no longer able
>>> to keep features in sync between standards, and the C++ development
>>> process values adding new features over stability. Adding new
>>> features as not to break old behavior requires a lot of thought,
>>> so the preferred choice is not to do it and kick the ball to the
>>> user.
>>>
>>
>> That is a proposal from a group of C++ developers, not the position of
>> the C++ standards committee.
>
> Comparing the paper's authors with the WG21 membership has two
> people in both: Chandler Carruth and Bryce Adelstein Lelbach.
>
> So, it is certainly a position held by members of WG21. If it
> will prevail, I don't know.
>
>
>> There would be /huge/ potential benefits from being able to break
>> backwards compatibility.
>
> Such as the ones experienced by the transition from Python 2 to
> Python 3 (ok, that was low).
>
>> A great deal of the awkwardness and risky
>> parts of C++ are due to compatibility with earlier versions of the
>> language, and with C. Of course there are also great costs involved in
>> breaking compatibility - and you can be confident that it will not be
>> done in a way that makes older code inaccessible. We are not going to
>> find that gcc 16 will only compile C++26 and your C++98 .. C++23 code is
>> no longer usable.
>
> Maintaining a different feature set for different language versions
> is hard (I know from experience). If you make previous versions
> incompatible, (worst case: the same syntax means different things),
> that is an even wider field for bugs.
>
>>
>>> Or, to put it less charitably: This is the victory of the feature
>>> stampede over long-term stability.
>>>
>>> Anybody who wants to do a long-term software project in C++ should
>>> think twice after reading this.
>>>
>>
>> They will simply think that you don't like C++, and thus haven't looked
>> at it much.
>
> I didn't mean my text, I meant the text at least co-authored by the
> WG21 members.
>

Fair enough.

I do agree that C++ is big, that it has been gaining features quickly,
and that for any given programmer or use-case, there is lots in the
language and library that they don't need. And I appreciate that you
are not alone in being concerned that things are moving too fast, and
there can be unintended consequences of changes that seem good at first.

Over all, however, I am finding that with each new version there are
features I want - and that I can happily ignore features that I don't
want. I can look at future ideas (in particular, metaclasses and
throwing exceptions by value) and see good things that I believe will be
very useful. I work in embedded programming, mostly on small systems,
and find I have now moved from C to C++ because I can do things better
in C++. I doubt if I will be moving back. My current project is in
C++17, and I know I will be using features from C++20 in the future - I
expect that will be true of C++23 and beyond.

(And my background is in computer science. I don't use languages or
features because they are "cool" - though I believe you when you say
some people do. A feature has to be useful, and give clearer source
code, safer source code, and efficient results before I will pick it up.)

One thing that might make a difference, I suppose, is that I am in the
happy position of writing my code myself, and relatively rarely having
to deal with too much code from other people.

On Thu, 8 Jul 2021 08:57:42 -0700, Stephen Fuld
<sfuld@alumni.cmu.edu.invalid> wrote:

>On 7/8/2021 7:13 AM, Thomas Koenig wrote:
>
>> There is also the illusion, harbored by too many people, that they
>> need a certain programming language that is cool, or that this is
>> what everybody else does.
>>
>> And this is where the danger lies with C++, especially when it is
>> used by scientists with little CS experience and background.
>>
>> Although, I admit it, Python is far worse than C++ in that respect.
>
>This statement surprises me. What language do you suggest for such people?

A couple of years ago, /I/ would have said Racket. Unfortunately, the
Racket development team now appears determined to change the language
from being Scheme-like to being Python-like ... some nonsense about
"parentheses" and "prefix notation" scaring people.

YMMV,
George

On 7/8/2021 5:02 AM, David Brown wrote:
> On 07/07/2021 21:22, BGB wrote:
>> On 7/7/2021 4:31 AM, David Brown wrote:
>>> On 05/07/2021 19:49, BGB wrote:
>>>> On 7/4/2021 11:59 PM, Thomas Koenig wrote:
>>>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>>>
>>>>>> Prolog is the perfect tool for Prolog-shaped problems. As is Snobol
>>>>>> for
>>>>>> the Snobol-shaped.
>>>>>
>>>>> Some people who don't like C++ say that C++ is the perfect tool
>>>>> for thumb-shaped problems :-)
>>>>>
>>>>
>>>> Main problems I have with C++ ATM:
>>>>    Compiler would be too complicated, don't want to bother with this;
>>>
>>> C++ compilers are certainly complicated.  It's a big language, and it is
>>> a demanding language for compilers.  Parsing is hard, with lots of
>>> conditional keywords, and you need to be happy with heavy inlining or
>>> the results will be hopelessly inefficient.
>>>
>>
>> Yeah.
>>
>> There are reasons why I have not been making more effort to try to add
>> C++ support to BGBCC. I can support a limited subset, but going much
>> beyond this would be an uphill battle.
>>
>>
>> I am generally working though towards at least trying to support C
>> effectively. Programs generally work, though there are corner cases
>> which still aren't supported effectively.
>>
>
> For a one-person toolchain, C is more than big enough!
>
>>
>> Eg, recently I had a few bugs which were being an issue and leading to a
>> program having different behavior in BGBCC vs GCC or Clang.
>>
>> Eventually, I found a few bugs, among them was things like:
>>   j = 9999U / i;
>> Where 'i' and 'j' are 'int'.
>>
>> Where the former value would lose its unsigned status resulting in the
>> expression being evaluated as 'int' rather than 'unsigned int', which
>> would lead to different behavior if 'i' was negative.
>>
>>
>
> The rules for implicit conversions and integer promotions are clear
> enough in C - it shouldn't be hard to support them correctly. (I don't
> entirely agree with the choices for the rules, but that's another matter.)
>

This was due to a compiler bug.

In some paths, it checked that it was dealing with an integer immediate,
but failed to check that it was dealing with an 'unsigned' integer
immediate...

>
>>
>>>>    Multiple inheritance needlessly complicates stuff;
>>>
>>> I'm not a fan of multiple inheritance myself.  In particular, inheriting
>>> data from different places is likely to cause trouble, and multiple
>>> inheritance of classes with virtual methods is very rarely worth the
>>> complication and confusion.  CRTP, however, can be really neat (for
>>> compile-time polymorphism).  In one project I am working on, I have
>>> templates for GPIO pins, arranged with inheritance:
>>>
>>> template <int gpio_bank, int gpio_pin, bool output = false>
>>> class GpioInOut :
>>>     public GpioIn<gpio_bank, gpio_pin>,
>>>     public GpioOut<gpio_bank, gpio_pin>
>>> ...
>>>
>>> It works neatly, the source code is clear, it is hard to use incorrectly
>>> as you can't mix up pins or accidentally drive an input-only pin, and
>>> the resulting code is as efficient as possible since the compiler has
>>> all the details of pin numbers, addresses, etc., on hand when compiling
>>> "green_led.on();".
>>>
>>> Multiple inheritance is a powerful tool, and is often used very poorly -
>>> but it /can/ be used very well.
>>>
>>
>> OK.
>>
>>
>>>>    Templates needlessly complicate stuff;
>>>
>>> Templates change the nature of the language significantly.  If you still
>>> think of C as being a language where a function in the source code
>>> corresponds precisely to a function in the generated assembly, and you
>>> think of C++ as being like C with extra features, you will not be able
>>> to handle templates.  Of course, it is a long time (perhaps three
>>> decades) since C has had complete correspondence in functions - but
>>> often you can pretend it works that way when it is useful.
>>>
>>
>> Yeah. I am primarily a C programmer.
>>
>> Generally this is because either the extra features C++ had added were
>> not sufficiently compelling, or because something else created
>> roadblocks that made it effectively unusable (or put constraints on it
>> that rendered it effectively moot).
>>
>
> There are times when C is a better choice - being simpler, more
> explicit, and easier to follow can help. Other times C++ makes it
> easier to express what you want, and lets you write code that is safer
> and easier to follow. (And of course, almost any reasonable C code will
> have the same meaning in C++, with at most minor adjustments.)
>

Generally true.

Except when for whatever reason C++ is not usable, eg:
No compiler for the target;
Compiler for the target is otherwise non-functional;
One is dealing with FFI tools which only understand C;
...

Variations on these patterns occurring repeatedly have basically meant
that for me, C++ had generally been "less safe" than C, since there were
fewer contexts I could use the code in.

Ironically, this also limits use of my own languages to some extent,
since it means that most code written in them is essentially ephemeral
(usually, tied to a specific project). This is OK for high-level glue
logic, not so much for other things.

>>
>>> In C++, however, the move has been towards higher level coding.
>>> Templates generate functions and classes.  They let you write more
>>> general code, with a lot more flexibility.
>>>
>>> Again, templates are powerful and can be abused, and template coding can
>>> certainly be complicated.  (It's got much easier in newer C++
>>> standards.)  But to suggest they are "needless" is tantamount to
>>> admitting you really do not understand the language at all.
>>>
>>
>> I understand a subset of C++, namely the subset where one treats it
>> mostly like C with classes, namespaces, and operator overloading...
>>
>
> You can get far with a subset like that. I'd throw references (lvalue
> references, not rvalue references), better const, and scoped enums into
> that mix as features that are quite simple to understand and where their
> functionality and implementation is obvious.
>

Yeah, some of these are also useful.

> (And you might want to disable exceptions and RTTI - it is standard
> practice on small embedded systems and also in game programming.)
>

My feeling on these are mixed, both can be useful.

My main issue with exceptions though is people trying to use them for
general control flow rather than for "edge case where something has gone
seriously wrong".

>>
>> Though, one can note that much of the language as it exists in its
>> present form depends on templates, and if one omits them it mostly
>> reverts back to a more C-like subset.
>>
>
> A lot of features of C++ can be viewed as things you need to /make/ the
> libraries or frameworks, rather than what you need to /use/ them. For
> example, in any situation where in C you would use an array with a size
> that is known at compile time, you can use a std::array from C++ to get
> some extra features and type-safety with no overhead. You don't have to
> be able to write such template classes in order to use them.
>

OK.

>>
>> There was EC++, which was also such a subset, however EC++ was actually
>> more limited than I would aim for.
>>
>> For example, I consider the added complexity of namespaces to be
>> justifiable (since it has something to offer, and is one of the few C++
>> features which delivers on the promise of not having any runtime
>> performance impact).
>>
>
> Most features of C++ have zero or close to zero overhead - compared to
> alternative solutions. For example, virtual functions in C++ have
> run-time costs, but they are likely to be lower than a C-style system of
> pointers to tables of function pointers doing the same thing.
>

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
> On 7/8/2021 7:13 AM, Thomas Koenig wrote:
>
> snip
>
>> There is also the illusion, harbored by too many people, that they
>> need a certain programming language that is cool, or that this is
>> what everybody else does.
>>
>> And this is where the danger lies with C++, especially when it is
>> used by scientists with little CS experience and background.
>>
>> Although, I admit it, Python is far worse than C++ in that respect.
>
> This statement surprises me.

Konrad Hinsen explained it better than I can, in

http://blog.khinsen.net/posts/2017/11/16/a-plea-for-stability-in-the-scipy-ecosystem/

His major point is that frequent changes in Python make science
unreproducable, especially the graphics changes.

I recently shared that blog article at the company I work for.
One response was "We make sure that for each project we do,
we use a container with a specified Python version only".

Ugh.

With the paper cited upthread, it seems to me that C++ is headed
the same way.

That ties in with a somewhat heated discussion I had with an IT
guy at the previous company I worked for. He told me that data
expiration in sharepoints of three years were not a problem, because
"who needs three year old data anyway". I tried to explain to him
that physical properties, for example, do not change, and that an
expiration date of three years is rather short if the development
cycle of a process in the industry we were in is five years at best.
He didn't understand.

> What language do you suggest for such people?

The language should have (and I am stealing here from a post
by Jos Bergervoet here, from yesterday)

1) A language evolution based on steady, backward-compatible changes.
2) An unambiguous language definition, maintained by a standardization
committee.
3) A high enough age to be reasonably complete despite the very
slow progress guaranteed by points 1) and 2).
4) A large code base and libraries for most things you need.
5) A compiler included in the public domain gcc compiler suite.
6) An excellent reputation for execution speed.
7) Parallel programming as integrated part of the language.

You can probably guess which language that is when I tell you the
post was made to comp.lang.fortran :-)

On 08/07/2021 21:53, Thomas Koenig wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
>> On 7/8/2021 7:13 AM, Thomas Koenig wrote:
>>

>>> Although, I admit it, Python is far worse than C++ in that respect.
>>
>> This statement surprises me.
>
> Konrad Hinsen explained it better than I can, in
>
> http://blog.khinsen.net/posts/2017/11/16/a-plea-for-stability-in-the-scipy-ecosystem/
>
> His major point is that frequent changes in Python make science
> unreproducable, especially the graphics changes.
>
> I recently shared that blog article at the company I work for.
> One response was "We make sure that for each project we do,
> we use a container with a specified Python version only".
>
> Ugh.
>
> With the paper cited upthread, it seems to me that C++ is headed
> the same way.
>

No, that is not an issue with C++ - nor will it be.

When you have a version of Python installed on your machine, you have
that version. If you have 3.7, and it has an incompatibility with 3.6,
then programs for 3.6 that hit that incompatibility no longer work as
expected. (The Python folks aim for minimal compatibility issues within
a major version, but can have significant changes between 2.x and 3.x.)
Your Linux distribution will typically support one 2.x version and one
3.x version. You can always get hold of older versions, and source is
always available, but it can be very inconvenient - and other packages
and libraries may not be available for particular point versions.

C++ is a compiled language, and in a very different situation. You can
take the latest gcc, pass it the flag "-std=c++98", and that's the
language version you get. Every standard of C and C++ is available.
Most C and C++ compilers follow a similar practice.

And for fussy projects, it's rarely difficult to archive your C or C++
toolchains. My personal record is a touch under 20 years for taking an
old project (in C), re-compiling with the original toolchain and getting
bit-perfect match for the previous build. Then I could make the changes
the customer wanted and re-build. The same will hold for C++ just as
well as for C. (You do have to be a little disciplined to make this
work, keeping the toolchains, specifying exact options in your
makefiles, etc.)

> That ties in with a somewhat heated discussion I had with an IT
> guy at the previous company I worked for. He told me that data
> expiration in sharepoints of three years were not a problem, because
> "who needs three year old data anyway". I tried to explain to him
> that physical properties, for example, do not change, and that an
> expiration date of three years is rather short if the development
> cycle of a process in the industry we were in is five years at best.
> He didn't understand.
>
>> What language do you suggest for such people?
>
> The language should have (and I am stealing here from a post
> by Jos Bergervoet here, from yesterday)
>
> 1) A language evolution based on steady, backward-compatible changes.
> 2) An unambiguous language definition, maintained by a standardization
> committee.
> 3) A high enough age to be reasonably complete despite the very
> slow progress guaranteed by points 1) and 2).
> 4) A large code base and libraries for most things you need.
> 5) A compiler included in the public domain gcc compiler suite.

(gcc is not public domain)

> 6) An excellent reputation for execution speed.
> 7) Parallel programming as integrated part of the language.
>
> You can probably guess which language that is when I tell you the
> post was made to comp.lang.fortran :-)
>

8) Should be at home on punched cards.
9) Requires programmers to wear corduroy trousers, sandals and a greying
beard.

(Sorry, that was unfair - especially since I wear sandals and a greying
beard myself!)

On 7/8/2021 11:02 AM, David Brown wrote:
> On 08/07/2021 16:13, Thomas Koenig wrote:
>> David Brown <david.brown@hesbynett.no> schrieb:
>>
>>>> The idea was "We have a hard problem here, let's kick it upstairs and
>>>> not worry about it anymore". How is the Oracle to know?
>>>>
>>>
>>> Maybe you got a different impression, but that sounds to me more like
>>> splitting a difficult task into parts,
>>
>> That wasn't the impression I was getting, especially in the absence
>> of any suggestion of how to do this.
>>
>> The talk is on youtube (as are my questions), but I doubt you will
>> want to go through it :-)
>>
>>> and letting different groups deal
>>> with those parts while agreeing on an interface between them. Then he
>>> concentrated the talk on the parts he was involved in. It does not
>>> sound at all unreasonable to me.
>>
>> This guy took it upon himself to do the (partial) implementation in gcc,
>> using a modified elf format.
>>
>> There is not "other department" as such in gcc development.
>>
>>>> That can be a problem, but the problem is disproportinally larger when
>>>> a language has introduced features at the rate that C++ has.
>>>>
>>>> https://dilbert.com/strip/2001-04-14 might also be appropriate.
>>>>
>>>
>>> There are lots of programming languages in the world, because there are
>>> lots of use-cases where the balance between different features and
>>> requirements is so varied.
>>
>> There is also the illusion, harbored by too many people, that they
>> need a certain programming language that is cool, or that this is
>> what everybody else does.
>>
>> And this is where the danger lies with C++, especially when it is
>> used by scientists with little CS experience and background.
>>
>> Although, I admit it, Python is far worse than C++ in that respect.
>>
>> [...]
>>
>>> I am confident that there will be FORTRAN developers who feel the
>>> language peaked with FORTRAN 77 or FORTRAN 90, and all these newfangled
>>> object-oriented and concurrent features pollute it and over-complicate it.
>>
>>> If C++ is too big and complicated for you, or you don't like a language
>>> that gains new features every three years,
>>
>> It's the fact that the language is too big and that the features it adds
>> are not carefully thought out.
>>
>>>> Every programming language has this problem, in general, but the degree
>>>> varies a lot, and C++'s extensive feature creep (or feature stampede)
>>>> makes the problem _much_ worse than for any other programming language.
>>>>
>>>> There was a serious proposal to break backwards compatibility for C++,
>>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2137r0.html
>>>>
>>>> Let me quote:
>>>>
>>>> # Our goals are focused on _migration_ from one version of C++ to the
>>>> # next rather than _compatibility_ between them. This is rooted in
>>>> # our experience with evolving software over time more generally and
>>>> # a live-at-head model. Any transition, whether based on backward
>>>> # compatibility or a migration plan, will require some manual
>>>> # intervention despite our best efforts, due to Hyrum’s Law, and
>>>> # so we should acknowledge that upgrades require active migrations.
>>>>
>>>> So, apparently the C++ standards committee itsef is no longer able
>>>> to keep features in sync between standards, and the C++ development
>>>> process values adding new features over stability. Adding new
>>>> features as not to break old behavior requires a lot of thought,
>>>> so the preferred choice is not to do it and kick the ball to the
>>>> user.
>>>>
>>>
>>> That is a proposal from a group of C++ developers, not the position of
>>> the C++ standards committee.
>>
>> Comparing the paper's authors with the WG21 membership has two
>> people in both: Chandler Carruth and Bryce Adelstein Lelbach.
>>
>> So, it is certainly a position held by members of WG21. If it
>> will prevail, I don't know.
>>
>>
>>> There would be /huge/ potential benefits from being able to break
>>> backwards compatibility.
>>
>> Such as the ones experienced by the transition from Python 2 to
>> Python 3 (ok, that was low).
>>
>>> A great deal of the awkwardness and risky
>>> parts of C++ are due to compatibility with earlier versions of the
>>> language, and with C. Of course there are also great costs involved in
>>> breaking compatibility - and you can be confident that it will not be
>>> done in a way that makes older code inaccessible. We are not going to
>>> find that gcc 16 will only compile C++26 and your C++98 .. C++23 code is
>>> no longer usable.
>>
>> Maintaining a different feature set for different language versions
>> is hard (I know from experience). If you make previous versions
>> incompatible, (worst case: the same syntax means different things),
>> that is an even wider field for bugs.
>>
>>>
>>>> Or, to put it less charitably: This is the victory of the feature
>>>> stampede over long-term stability.
>>>>
>>>> Anybody who wants to do a long-term software project in C++ should
>>>> think twice after reading this.
>>>>
>>>
>>> They will simply think that you don't like C++, and thus haven't looked
>>> at it much.
>>
>> I didn't mean my text, I meant the text at least co-authored by the
>> WG21 members.
>>
>
> Fair enough.
>
> I do agree that C++ is big, that it has been gaining features quickly,
> and that for any given programmer or use-case, there is lots in the
> language and library that they don't need. And I appreciate that you
> are not alone in being concerned that things are moving too fast, and
> there can be unintended consequences of changes that seem good at first.
>
> Over all, however, I am finding that with each new version there are
> features I want - and that I can happily ignore features that I don't
> want. I can look at future ideas (in particular, metaclasses and
> throwing exceptions by value) and see good things that I believe will be
> very useful. I work in embedded programming, mostly on small systems,
> and find I have now moved from C to C++ because I can do things better
> in C++. I doubt if I will be moving back. My current project is in
> C++17, and I know I will be using features from C++20 in the future - I
> expect that will be true of C++23 and beyond.
>
> (And my background is in computer science. I don't use languages or
> features because they are "cool" - though I believe you when you say
> some people do. A feature has to be useful, and give clearer source
> code, safer source code, and efficient results before I will pick it up.)
>

The "cult of cool" crowd seems mostly at present to be enamored with Rust...

> One thing that might make a difference, I suppose, is that I am in the
> happy position of writing my code myself, and relatively rarely having
> to deal with too much code from other people.
>

In times I have used other peoples' code, it has usually ended up being
more hassle than it is worth.

Decided not to go into another historical recap...

On 7/6/2021 2:46 PM, MitchAlsup wrote:
> On Tuesday, July 6, 2021 at 1:26:13 PM UTC-5, BGB wrote:
>> On 7/6/2021 11:48 AM, George Neuner wrote:
>>> On Tue, 06 Jul 2021 09:12:51 -0400, Stefan Monnier
>>> <mon...@iro.umontreal.ca> wrote:
>>>
>>>>> Then again, my preferred option is to use interfaces instead, but then
>>>>> people argue that interfaces are just poor man's MI.
>>>>
>>>> The good thing about inheritance is that it gives you subtyping.
>>>> Interfaces give you subtyping but without the bad after taste that you
>>>> get from inheritance.
>>>>
>>>> IOW, interfaces are "MI done right".
>>>
>>> In too many SI languages, interfaces are more annoying than helpful:
>>> far too often with SI the interface functions have to be
>>> re-implemented where in an MI language they would be inheritable.
>>>
>>> Mix-ins are useful, but sometimes you really want inheritance.
>>>
>> Several of the languages which I am aware of with interfaces also allow
>> something like:
>> public interface IFoo {
>> default void someMethod()
>> { ... do something ... }
>> }
>>
>> Where, if the class doesn't provide its own someMethod, it is implicitly
>> added from the interface.
>>
>>
>> A language could use multiple inheritance but make virtual inheritance
>> semantics the default, but this "kinda sucks" as there isn't really a
>> good way to implement it which doesn't carry a performance overhead.
>>
>> Though, a similar strategy to what would normally be used for
>> implementing virtual inheritance can also be used to fake MI on top of a
>> SI object system.
>>
>> This could be managed by the compiler, or one could be like "meh,
>> whatever", and have the programmers do it themselves if they want it.
>>
>>
>>
>> One other possibility is to allow someone to throw a 'delegate' keyword
>> or similar onto an object field, in which case it will be transparently
>> used to resolve fields or methods if they were not found within the
>> containing class.
>>
>> public class Bar {
>> int x;
>> public Bar(int i) { x=i; }
>> }
>> public class Bar {
>> int y;
>> public Bar(int i) { y=i; }
>> }
>>
>> public class Foo {
>> delegate Bar bar;
>> delegate Baz baz;
>> public Foo(int i, int j) {
>> bar=new Bar(i);
>> baz=new Baz(j);
>> }
>> public int sum { get x+y; }
>> }
>>
>> Foo foo = new Foo(3, 4);
>> int v = foo.sum; //calculates 'foo.bar.x + foo.baz.y'
>> int x = foo.x; // behaves like 'foo.bar.x'
> <
> Does anyone else get the impression that this is a better description of
> entering the C Obfuscation Championship that a means for sane
> people to render application programs ?
> <

Hmm...

Some of this is due to the way things interact.

Though, some of this stuff doesn't exist yet in the BGBCC implementation
of BS2 (which is still fairly incomplete vs the BS2VM version). Though,
the BGBCC version has a funky "hybrid C mode" (whereas the BS2VM did
something more akin to P/Invoke in C#).

Eg:
public int sum { get x+y; }
Is shorthand for:
public int sum { get { x+y } }
Is shorthand for:
public int sum { get { return x+y; } }
Is shorthand for (approx):
public int get__sum() { return x+y; }
Is shorthand for (approx):
public int get__sum() { return this.bar.x+this.baz.y; }

Where the presence of a "get__x" method causes attempts to access the
field 'x' to be transformed into a method call (using '__' this way
mostly being reserved for internal use by the compiler).

The property syntax here was borrowed from C#, and there are
additionally rules that if the last line in a block is an expression
with no semicolon, it is treated as an implicit "return", and also that
a function with an expression in place of a block will simply return the
result of evaluating the expression (useful for lambdas).

Note that BS2 'delegate' should not be confused with C# 'delegate',
since what they do is very different.

Though, looking back at a very old spec, the design of an early form of
the original BS language was a bit more "WTF?" (some of the more
questionable design choices had been dropped).

There is also sort of a weird hybrid mode that can be used in BGBCC,
mostly because many of these language features are sort of exposed to C
land via different keywords (since the logic generally still exists in
the compiler).

Some of this is because if they exist for one language, it isn't hard to
expose them for another.

In the past, this sort of thing was useful for "FFI glue", and within an
FFI general sanity regarding language consistency or semantics tends to
go out the window, but one needs code within the FFI region to be able
to access functionality from both languages (and it doesn't matter too
much if the code looks like nasty chewed-up garbage).

Partly also this hybrid mode turns out to be semi-useful at testing
parts of the runtime and similar (where, some amount of the BS2 runtime
support stuff is also written in this hybrid mode).

Though, this sort of "C plus random weird crap" mode, isn't really
recommended "for general use".

Though, one could almost define a language based on these extensions,
maybe call it "C__var" or something (and or create a header which
introduces a bunch of new keywords via preprocessor defines).

On 08/07/2021 21:34, BGB wrote:
> On 7/8/2021 5:02 AM, David Brown wrote:
>> On 07/07/2021 21:22, BGB wrote:
>>> On 7/7/2021 4:31 AM, David Brown wrote:
>>>> On 05/07/2021 19:49, BGB wrote:
>>>>> On 7/4/2021 11:59 PM, Thomas Koenig wrote:
>>>>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>>>>

>>> Yeah. I am primarily a C programmer.
>>>
>>> Generally this is because either the extra features C++ had added were
>>> not sufficiently compelling, or because something else created
>>> roadblocks that made it effectively unusable (or put constraints on it
>>> that rendered it effectively moot).
>>>
>>
>> There are times when C is a better choice - being simpler, more
>> explicit, and easier to follow can help.  Other times C++ makes it
>> easier to express what you want, and lets you write code that is safer
>> and easier to follow.  (And of course, almost any reasonable C code will
>> have the same meaning in C++, with at most minor adjustments.)
>>
>
> Generally true.
>
> Except when for whatever reason C++ is not usable, eg:
>   No compiler for the target;
>   Compiler for the target is otherwise non-functional;
>   One is dealing with FFI tools which only understand C;
>   ...

Of course there can be overriding reasons for choosing a language, or
avoiding a language.

>
> Variations on these patterns occurring repeatedly have basically meant
> that for me, C++ had generally been "less safe" than C, since there were
> fewer contexts I could use the code in.
>
> Ironically, this also limits use of my own languages to some extent,
> since it means that most code written in them is essentially ephemeral
> (usually, tied to a specific project). This is OK for high-level glue
> logic, not so much for other things.
>
>
>>>
>>>> In C++, however, the move has been towards higher level coding.
>>>> Templates generate functions and classes.  They let you write more
>>>> general code, with a lot more flexibility.
>>>>
>>>> Again, templates are powerful and can be abused, and template coding
>>>> can
>>>> certainly be complicated.  (It's got much easier in newer C++
>>>> standards.)  But to suggest they are "needless" is tantamount to
>>>> admitting you really do not understand the language at all.
>>>>
>>>
>>> I understand a subset of C++, namely the subset where one treats it
>>> mostly like C with classes, namespaces, and operator overloading...
>>>
>>
>> You can get far with a subset like that.  I'd throw references (lvalue
>> references, not rvalue references), better const, and scoped enums into
>> that mix as features that are quite simple to understand and where their
>> functionality and implementation is obvious.
>>
>
> Yeah, some of these are also useful.
>
>
>> (And you might want to disable exceptions and RTTI - it is standard
>> practice on small embedded systems and also in game programming.)
>>
>
> My feeling on these are mixed, both can be useful.
>
> My main issue with exceptions though is people trying to use them for
> general control flow rather than for "edge case where something has gone
> seriously wrong".
>

I'm fine with exceptions on big systems - I use them happily in Python.
But on my embedded systems, I don't like things happening behind the
scenes. I don't like big tables for stack unwinding. I don't like
things being able to go wrong. I don't like code that says it will do
something, but might be lying.

To me, a function has a specification - you have a pre-condition that
the user guarantees will be true, and a post-condition that the function
guarantees will be true at the end (and often an invariant that is true
at the start, true at the end, but might be untrue during the function's
execution). If there is a function :

int convert_user_input_to_integer(const char * s);

then the result /will/ be an int. I don't accept that the function
might throw its toys out of the pram because the user entered "foo", or
"9813457895901890234728349238". I am equally happy with :

std::optional<int> try_to_convert_user_input_to_integer(
const char * s);

That can return std::nullopt on bad input. (A struct with a "valid"
bool field and a data field works just as well, but I've found
std::optional to be quite convenient here.)

RTTI I don't use, because I don't see a point in having dynamic typing
in embedded code. (Again, I'm fine with it in Python on a PC.) I want
to know what my types are. If I have a function "foo" that can take one
of several different types, then I have many safe and efficient ways to
do that - template functions, overloads, inheritance, std::variant, etc.

You mentioned the "overhead" of C++. There are only two serious
breaches of the zero-overhead ("you don't pay for what you don't use")
principle in the C++ core language - exceptions, and RTTI. (There are
plenty of parts of the standard library that are a lot bigger than you
might want and end up linking in massive amounts of extra code. The
same applies in C, though its library is a lot smaller. But here I am
talking about the core language.)

>
>>>
>>> Though, one can note that much of the language as it exists in its
>>> present form depends on templates, and if one omits them it mostly
>>> reverts back to a more C-like subset.
>>>
>>
>> A lot of features of C++ can be viewed as things you need to /make/ the
>> libraries or frameworks, rather than what you need to /use/ them.  For
>> example, in any situation where in C you would use an array with a size
>> that is known at compile time, you can use a std::array from C++ to get
>> some extra features and type-safety with no overhead.  You don't have to
>> be able to write such template classes in order to use them.
>>
>
> OK.
>
>>>
>>> There was EC++, which was also such a subset, however EC++ was actually
>>> more limited than I would aim for.
>>>
>>> For example, I consider the added complexity of namespaces to be
>>> justifiable (since it has something to offer, and is one of the few C++
>>> features which delivers on the promise of not having any runtime
>>> performance impact).
>>>
>>
>> Most features of C++ have zero or close to zero overhead - compared to
>> alternative solutions.  For example, virtual functions in C++ have
>> run-time costs, but they are likely to be lower than a C-style system of
>> pointers to tables of function pointers doing the same thing.
>>
>
> The underlying implementation tends to be virtually the same, so it
> shouldn't make that much difference.
>
>
>> Real-world comparisons between C and C++ suggest the overhead of C++ is
>> in the region of a percent or two - with plenty of variation depending
>> on the type of code.  (C++ object files will often be very much bigger
>> when linking and debug information is still there, and exception tables
>> can take up a lot of space in binaries in some cases.)
>>
>
> Yeah. In my case the exception unwind tables use a trick of reusing a
> pointer to the epilog sequence to implement unwinding. The unwind logic
> needs to be able to parse machine code, but it allows reducing the
> amount of space overhead.
>

There are many trade-offs to have here, between code space per function,
code space for the unwinder, and limitations to the code generation. I
dislike that the need to have unwinders can put restrictions on the code
generation - a compiler could generate different code when it knows how
the function epilog will run, compared to having to accept multiple
unexpected jumps and exits.

>
>>>
>>>>>     The C++ standard library and STL is kinda a trash fire;
>>>>
>>>> There is plenty to like, and plenty to dislike in the C++ standard
>>>> library.  It contains a great deal of functionality that few people
>>>> will
>>>> ever need, and that does complicate things.  And it suffers from
>>>> backwards compatibility (as does the language) - once something is in
>>>> the language, or the library, it is hard to remove it even if better
>>>> methods have been found.
>>>>
>>>
>>> Some of it was older stuff that seemed more like "language feature in
>>> search of a use-case" than because of it making sense to do it that way.
>>>
>>>
>>> Eg: overloading operators to add new types and make them behave kinda
>>> like built-in types, makes sense. Overloading operators for sake of
>>> doing File IO or formatted printing, ..., yeah...
>>
>> I think the cout-style output is a mixed blessing.  It is convenient in
>> some ways, but fails in others.  It is vastly superior to printf in type
>> safety and flexibility in defining output formats for your own types.
>> It is vastly inferior for translating format strings, and for modifying
>> the format of number outputs.
>>
>
> There are limitations with printf, granted.
>
> Some are more due to C's particularly weak way of handling variable
> argument lists than due to the general design of its interface though.
>

On 2021-07-09, David Brown wrote:
> On 08/07/2021 21:34, BGB wrote:

[big snip]

>>>> There are possible ways to combat expansion, in theory, but I am not
>>>> sure if they are really allowed or commonly done.
>>>
>>> The most obvious way is that a lot of template functions are quite
>>> small, and thus end up inlined saving space (no function call, no
>>> register movements, saves and restores, more scope for other
>>> optimisations).
>>>

When used correctly (TM), C++ is very well suited for generating tight
code (e.g. for embedded systems etc). I generally like (small) template
functions & classes, since:

* You get type safety (unlike C macros).
* Code is inlined -> zero overhead.
* A lot of work can be moved from run time to compile time.
* You avoid error-prone duplication of boiler-plate code.

In fact I had some C code that I quick-n-dirty translated to C++, and
the generated machine code got both smaller and faster.

>>
>> Not ideal if the compiler lacks support for inlining...
>
> A compiler that can't inline (automatically, as well as when suggested
> by the "inline" qualifier) doesn't count as a modern quality compiler.
> I have had to use such poor compilers in the past for C coding, and have
> been happy to leave them in the past. I would not consider using such a
> limited tool for C programming now, never mind C++ programming. (I
> highly doubt that there are any compilers that support C++ and don't do
> good inlining.)
>
>
> (I still admire the achievement of making a workable C compiler of any
> sort - but I would not use it for real work.)
>

Agree, and agree. It's an awesome achievement, but in order to compare
apples to apples (e.g. benchmark and code generation comparisons to
other architectures) you pretty much need a full featured modern C++
compiler.

/Marcus

On Thu, 8 Jul 2021 19:53:08 -0000 (UTC), Thomas Koenig
<tkoenig@netcologne.de> wrote:

>Konrad Hinsen explained it better than I can, in
>
>http://blog.khinsen.net/posts/2017/11/16/a-plea-for-stability-in-the-scipy-ecosystem/
>
>His major point is that frequent changes in Python make science
>unreproducable, especially the graphics changes.

And now Microsoft has hired Guido and wants him to make Python more
performant ... even if it breaks compatibility (again).

>I recently shared that blog article at the company I work for.
>One response was "We make sure that for each project we do,
>we use a container with a specified Python version only".
>
>Ugh.
>
>With the paper cited upthread, it seems to me that C++ is headed
>the same way.
>
>That ties in with a somewhat heated discussion I had with an IT
>guy at the previous company I worked for. He told me that data
>expiration in sharepoints of three years were not a problem, because
>"who needs three year old data anyway". I tried to explain to him
>that physical properties, for example, do not change, and that an
>expiration date of three years is rather short if the development
>cycle of a process in the industry we were in is five years at best.
>He didn't understand.

That is the problem: (particularly younger) people investigating some
language with potential to become adopters want to see significant
development activity, a steady stream of new features, and redesigned
packaging bearing the words "new & improved" every 6 months.

Mature projects that mostly are in "maintenance" mode now increasingly
are seen to be "stagnant" and not interesting.

>> What language do you suggest for such people?
>
>The language should have (and I am stealing here from a post
>by Jos Bergervoet here, from yesterday)
>
>1) A language evolution based on steady, backward-compatible changes.
>2) An unambiguous language definition, maintained by a standardization
>committee.
>3) A high enough age to be reasonably complete despite the very
>slow progress guaranteed by points 1) and 2).
>4) A large code base and libraries for most things you need.
>5) A compiler included in the public domain gcc compiler suite.
>6) An excellent reputation for execution speed.
>7) Parallel programming as integrated part of the language.
>
>You can probably guess which language that is when I tell you the
>post was made to comp.lang.fortran :-)

On 09/07/2021 15:51, Marcus wrote:
> On 2021-07-09, David Brown wrote:
>> On 08/07/2021 21:34, BGB wrote:
>
> [big snip]
>
>>>>> There are possible ways to combat expansion, in theory, but I am not
>>>>> sure if they are really allowed or commonly done.
>>>>
>>>> The most obvious way is that a lot of template functions are quite
>>>> small, and thus end up inlined saving space (no function call, no
>>>> register movements, saves and restores, more scope for other
>>>> optimisations).
>>>>
>
> When used correctly (TM), C++ is very well suited for generating tight
> code (e.g. for embedded systems etc). I generally like (small) template
> functions & classes, since:
>
> * You get type safety (unlike C macros).
> * Code is inlined -> zero overhead.
> * A lot of work can be moved from run time to compile time.
> * You avoid error-prone duplication of boiler-plate code.
>
> In fact I had some C code that I quick-n-dirty translated to C++, and
> the generated machine code got both smaller and faster.

Agreed.

On 7/9/2021 4:25 AM, David Brown wrote:
> On 08/07/2021 21:34, BGB wrote:
>> On 7/8/2021 5:02 AM, David Brown wrote:
>>> On 07/07/2021 21:22, BGB wrote:
>>>> On 7/7/2021 4:31 AM, David Brown wrote:
>>>>> On 05/07/2021 19:49, BGB wrote:
>>>>>> On 7/4/2021 11:59 PM, Thomas Koenig wrote:
>>>>>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>>>>>
>
>
>>>> Yeah. I am primarily a C programmer.
>>>>
>>>> Generally this is because either the extra features C++ had added were
>>>> not sufficiently compelling, or because something else created
>>>> roadblocks that made it effectively unusable (or put constraints on it
>>>> that rendered it effectively moot).
>>>>
>>>
>>> There are times when C is a better choice - being simpler, more
>>> explicit, and easier to follow can help.  Other times C++ makes it
>>> easier to express what you want, and lets you write code that is safer
>>> and easier to follow.  (And of course, almost any reasonable C code will
>>> have the same meaning in C++, with at most minor adjustments.)
>>>
>>
>> Generally true.
>>
>> Except when for whatever reason C++ is not usable, eg:
>>   No compiler for the target;
>>   Compiler for the target is otherwise non-functional;
>>   One is dealing with FFI tools which only understand C;
>>   ...
>
> Of course there can be overriding reasons for choosing a language, or
> avoiding a language.
>

Yeah.

Back when I was younger, it was a bit hit or miss whether "g++" would
work. Much of the time, one would get an installation where, if trying
to use it, it would just print an error message and die or similar.

By the time the compiler issues were resolved, the issue was more often
things like FFI compatibility issues, ...

>>
>> Variations on these patterns occurring repeatedly have basically meant
>> that for me, C++ had generally been "less safe" than C, since there were
>> fewer contexts I could use the code in.
>>
>> Ironically, this also limits use of my own languages to some extent,
>> since it means that most code written in them is essentially ephemeral
>> (usually, tied to a specific project). This is OK for high-level glue
>> logic, not so much for other things.
>>
>>
>>>>
>>>>> In C++, however, the move has been towards higher level coding.
>>>>> Templates generate functions and classes.  They let you write more
>>>>> general code, with a lot more flexibility.
>>>>>
>>>>> Again, templates are powerful and can be abused, and template coding
>>>>> can
>>>>> certainly be complicated.  (It's got much easier in newer C++
>>>>> standards.)  But to suggest they are "needless" is tantamount to
>>>>> admitting you really do not understand the language at all.
>>>>>
>>>>
>>>> I understand a subset of C++, namely the subset where one treats it
>>>> mostly like C with classes, namespaces, and operator overloading...
>>>>
>>>
>>> You can get far with a subset like that.  I'd throw references (lvalue
>>> references, not rvalue references), better const, and scoped enums into
>>> that mix as features that are quite simple to understand and where their
>>> functionality and implementation is obvious.
>>>
>>
>> Yeah, some of these are also useful.
>>
>>
>>> (And you might want to disable exceptions and RTTI - it is standard
>>> practice on small embedded systems and also in game programming.)
>>>
>>
>> My feeling on these are mixed, both can be useful.
>>
>> My main issue with exceptions though is people trying to use them for
>> general control flow rather than for "edge case where something has gone
>> seriously wrong".
>>
>
> I'm fine with exceptions on big systems - I use them happily in Python.
> But on my embedded systems, I don't like things happening behind the
> scenes. I don't like big tables for stack unwinding. I don't like
> things being able to go wrong. I don't like code that says it will do
> something, but might be lying.
>

The "big tables" thing seems partly an ABI thing.

If the exception unwind table can be bit-packed down to around 8 bytes
per function or so, it isn't too expensive in terms of space overhead.

At least in my case, the '.pdata' section is ~ 3% the size of the
associated '.text' section. Granted, this is with the "reuse the machine
code from the epilog" trick.

Though, they are better if not used.

If one goes the "reuse DWARF debuginfo or similar" route, that is not ideal.

> To me, a function has a specification - you have a pre-condition that
> the user guarantees will be true, and a post-condition that the function
> guarantees will be true at the end (and often an invariant that is true
> at the start, true at the end, but might be untrue during the function's
> execution). If there is a function :
>
> int convert_user_input_to_integer(const char * s);
>
> then the result /will/ be an int. I don't accept that the function
> might throw its toys out of the pram because the user entered "foo", or
> "9813457895901890234728349238". I am equally happy with :
>
> std::optional<int> try_to_convert_user_input_to_integer(
> const char * s);
>
> That can return std::nullopt on bad input. (A struct with a "valid"
> bool field and a data field works just as well, but I've found
> std::optional to be quite convenient here.)
>
>
> RTTI I don't use, because I don't see a point in having dynamic typing
> in embedded code. (Again, I'm fine with it in Python on a PC.) I want
> to know what my types are. If I have a function "foo" that can take one
> of several different types, then I have many safe and efficient ways to
> do that - template functions, overloads, inheritance, std::variant, etc.
>

The space overhead of RTTI style metadata isn't too unreasonable, if
implemented sanely.

In my case, it is ~24 bytes for the ClassInfo header, + 16 bytes per
field or method, with some additional space for strings.

Though, now went and defined a "Small" variant which reduces FieldInfo
to 12 bytes, mostly by using 24-bit RVAs and a 16-bit offset.

The FieldInfo structures are needed mostly so that if one casts a
ClassObj to 'variant', this allows accessing object fields dynamically.

>
> You mentioned the "overhead" of C++. There are only two serious
> breaches of the zero-overhead ("you don't pay for what you don't use")
> principle in the C++ core language - exceptions, and RTTI. (There are
> plenty of parts of the standard library that are a lot bigger than you
> might want and end up linking in massive amounts of extra code. The
> same applies in C, though its library is a lot smaller. But here I am
> talking about the core language.)
>

One doesn't usually push a binary up to 50 or 100 MB or similar just by
using RTTI or exceptions. One can, however, see this effect more often
when someone overuses templates in "Modern C++" style code...

>
>>
>>>>
>>>> Though, one can note that much of the language as it exists in its
>>>> present form depends on templates, and if one omits them it mostly
>>>> reverts back to a more C-like subset.
>>>>
>>>
>>> A lot of features of C++ can be viewed as things you need to /make/ the
>>> libraries or frameworks, rather than what you need to /use/ them.  For
>>> example, in any situation where in C you would use an array with a size
>>> that is known at compile time, you can use a std::array from C++ to get
>>> some extra features and type-safety with no overhead.  You don't have to
>>> be able to write such template classes in order to use them.
>>>
>>
>> OK.
>>
>>>>
>>>> There was EC++, which was also such a subset, however EC++ was actually
>>>> more limited than I would aim for.
>>>>
>>>> For example, I consider the added complexity of namespaces to be
>>>> justifiable (since it has something to offer, and is one of the few C++
>>>> features which delivers on the promise of not having any runtime
>>>> performance impact).
>>>>
>>>
>>> Most features of C++ have zero or close to zero overhead - compared to
>>> alternative solutions.  For example, virtual functions in C++ have
>>> run-time costs, but they are likely to be lower than a C-style system of
>>> pointers to tables of function pointers doing the same thing.
>>>
>>
>> The underlying implementation tends to be virtually the same, so it
>> shouldn't make that much difference.
>>
>>
>>> Real-world comparisons between C and C++ suggest the overhead of C++ is
>>> in the region of a percent or two - with plenty of variation depending
>>> on the type of code.  (C++ object files will often be very much bigger
>>> when linking and debug information is still there, and exception tables
>>> can take up a lot of space in binaries in some cases.)
>>>
>>
>> Yeah. In my case the exception unwind tables use a trick of reusing a
>> pointer to the epilog sequence to implement unwinding. The unwind logic
>> needs to be able to parse machine code, but it allows reducing the
>> amount of space overhead.
>>
>
> There are many trade-offs to have here, between code space per function,
> code space for the unwinder, and limitations to the code generation. I
> dislike that the need to have unwinders can put restrictions on the code
> generation - a compiler could generate different code when it knows how
> the function epilog will run, compared to having to accept multiple
> unexpected jumps and exits.
>

On 09/07/2021 23:07, BGB wrote:
> On 7/9/2021 4:25 AM, David Brown wrote:
>> On 08/07/2021 21:34, BGB wrote:
>>> On 7/8/2021 5:02 AM, David Brown wrote:
>>>> On 07/07/2021 21:22, BGB wrote:

>>>
>>>> (And you might want to disable exceptions and RTTI - it is standard
>>>> practice on small embedded systems and also in game programming.)
>>>>
>>>
>>> My feeling on these are mixed, both can be useful.
>>>
>>> My main issue with exceptions though is people trying to use them for
>>> general control flow rather than for "edge case where something has gone
>>> seriously wrong".
>>>
>>
>> I'm fine with exceptions on big systems - I use them happily in Python.
>>   But on my embedded systems, I don't like things happening behind the
>> scenes.  I don't like big tables for stack unwinding.  I don't like
>> things being able to go wrong.  I don't like code that says it will do
>> something, but might be lying.
>>
>
> The "big tables" thing seems partly an ABI thing.
>
> If the exception unwind table can be bit-packed down to around 8 bytes
> per function or so, it isn't too expensive in terms of space overhead.

Exception tables for functions for small and simple functions are small.
They get big when you have more complicated data structures and classes
with destructors. You need enough tables to be able to deconstruct
everything in the right order, no matter which function call throws an
exception at any point in the code. That can be big and messy,
especially when the aim is to minimise any restrictions on the flow and
efficiency of the code when exceptions are not thrown. So if you have a
loop with function calls inside, and that loop is unrolled four times
for speed, the unwind tables will need to grow to handle that.

>
> At least in my case, the '.pdata' section is ~ 3% the size of the
> associated '.text' section. Granted, this is with the "reuse the machine
> code from the epilog" trick.
>
> Though, they are better if not used.
>
> If one goes the "reuse DWARF debuginfo or similar" route, that is not
> ideal.
>
>
>> To me, a function has a specification - you have a pre-condition that
>> the user guarantees will be true, and a post-condition that the function
>> guarantees will be true at the end (and often an invariant that is true
>> at the start, true at the end, but might be untrue during the function's
>> execution).  If there is a function :
>>
>>     int convert_user_input_to_integer(const char * s);
>>
>> then the result /will/ be an int.  I don't accept that the function
>> might throw its toys out of the pram because the user entered "foo", or
>> "9813457895901890234728349238".  I am equally happy with :
>>
>>     std::optional<int> try_to_convert_user_input_to_integer(
>>             const char * s);
>>
>> That can return std::nullopt on bad input.  (A struct with a "valid"
>> bool field and a data field works just as well, but I've found
>> std::optional to be quite convenient here.)
>>
>>
>> RTTI I don't use, because I don't see a point in having dynamic typing
>> in embedded code.  (Again, I'm fine with it in Python on a PC.)  I want
>> to know what my types are.  If I have a function "foo" that can take one
>> of several different types, then I have many safe and efficient ways to
>> do that - template functions, overloads, inheritance, std::variant, etc.
>>
>
> The space overhead of RTTI style metadata isn't too unreasonable, if
> implemented sanely.
>
> In my case, it is ~24 bytes for the ClassInfo header, + 16 bytes per
> field or method, with some additional space for strings.
>
> Though, now went and defined a "Small" variant which reduces FieldInfo
> to 12 bytes, mostly by using 24-bit RVAs and a 16-bit offset.
>
>
> The FieldInfo structures are needed mostly so that if one casts a
> ClassObj to 'variant', this allows accessing object fields dynamically.
>

I agree that RTTI data is typically not too big - but it is all a waste
for my kind of work (actually, not a lot of code uses RTTI or dynamic
casts, except for exceptions as they require it).

>
>>
>> You mentioned the "overhead" of C++.  There are only two serious
>> breaches of the zero-overhead ("you don't pay for what you don't use")
>> principle in the C++ core language - exceptions, and RTTI.  (There are
>> plenty of parts of the standard library that are a lot bigger than you
>> might want and end up linking in massive amounts of extra code.  The
>> same applies in C, though its library is a lot smaller.  But here I am
>> talking about the core language.)
>>
>
> One doesn't usually push a binary up to 50 or 100 MB or similar just by
> using RTTI or exceptions. One can, however, see this effect more often
> when someone overuses templates in "Modern C++" style code...
>

I live in a world where 100 KB is a fair sized program.

>>>>
>>>> I think the cout-style output is a mixed blessing.  It is convenient in
>>>> some ways, but fails in others.  It is vastly superior to printf in
>>>> type
>>>> safety and flexibility in defining output formats for your own types.
>>>> It is vastly inferior for translating format strings, and for modifying
>>>> the format of number outputs.
>>>>
>>>
>>> There are limitations with printf, granted.
>>>
>>> Some are more due to C's particularly weak way of handling variable
>>> argument lists than due to the general design of its interface though.
>>>
>>
>> printf cannot be extended - that is its main limitation.  Variable
>> argument lists are another big weakness, and a gaping hole in type
>> safety in the language.
>>
>
> In standard C, it can't be extended, but there is little to disallow a C
> library from adding an API extension to allow the program to register
> its own printf specifiers or similar via callbacks.
>
>
> Say, for example, if one could have something like (uses extensions):
>   char *foo_print_v4f(__m128 xi, char *psp)
>   {
>      __vec4f mv;
>      char *temp;
>      temp=tk_ralloc(128);  //temp allocate scratch memory
>      mv=(__vec4f)(xi);
>      sprintf(temp, "#[%f,%f,%f,%f]", mv.x, mv.y, mv.z, mv.w);
>      return(temp);
>   }
>
>   _printf_addspec("X4f", "M128", foo_print_v4f);
>   ...
>   printf("%UX4f;\n", somevec);
>
> Where, say, the first parameter specifies the name of the user specifier
> (indicated via "%U...;"). The second parameter giving the base-type of
> the argument, eg:
>   "I32" / "i": int
>   "I64" / "li": long
>   "I64" / "lli": long long
>   "I128": Int128
>   "M64": __m64
>   "M128": __m128
>   "f": float or double
>   "lf": long double
>
> And the user-defined specifier callback prints the result to a string,
> which is then printed as-if it were "%s".
>

Sure, that kind of thing would be possible. It is no longer printf,
however.

People use a variety of different ways of outputting information -
printf and cout are just the standard ones.

>>>
>>>>>
>>>>> It is possibly telling that two of its major 'successors' (Java and
>>>>> C#),
>>>>> either eventually or initially, mostly went back to doing it in a
>>>>> similar way to C.
>>>>>
>>>>
>>>> (There is a new system of formatted output on its way to the C++
>>>> library.)
>>>>
>>>
>>> If it is essentially a rebranded "printf", that would be amusing...
>>>
>>
>> <https://en.cppreference.com/w/cpp/utility/format/format>
>>
>> No, it is not a copy of printf - but it is an attempt at getting some of
>> the advantages printf has over std::cout into a type-safe and extendable
>> C++ solution.  I haven't used it or examined the details, so I can't say
>> how well it succeeds.
>>
>
> So, you do:
>   using namespace std;  //... standard practice ...
>   cout << format("string...", args...);
>
> When you could do, say:
>   printf("string...", args...);
>

On 7/10/2021 5:13 AM, David Brown wrote:
> On 09/07/2021 23:07, BGB wrote:
>> On 7/9/2021 4:25 AM, David Brown wrote:
>>> On 08/07/2021 21:34, BGB wrote:
>>>> On 7/8/2021 5:02 AM, David Brown wrote:
>>>>> On 07/07/2021 21:22, BGB wrote:
>
>
>>>>
>>>>> (And you might want to disable exceptions and RTTI - it is standard
>>>>> practice on small embedded systems and also in game programming.)
>>>>>
>>>>
>>>> My feeling on these are mixed, both can be useful.
>>>>
>>>> My main issue with exceptions though is people trying to use them for
>>>> general control flow rather than for "edge case where something has gone
>>>> seriously wrong".
>>>>
>>>
>>> I'm fine with exceptions on big systems - I use them happily in Python.
>>>   But on my embedded systems, I don't like things happening behind the
>>> scenes.  I don't like big tables for stack unwinding.  I don't like
>>> things being able to go wrong.  I don't like code that says it will do
>>> something, but might be lying.
>>>
>>
>> The "big tables" thing seems partly an ABI thing.
>>
>> If the exception unwind table can be bit-packed down to around 8 bytes
>> per function or so, it isn't too expensive in terms of space overhead.
>
> Exception tables for functions for small and simple functions are small.
> They get big when you have more complicated data structures and classes
> with destructors. You need enough tables to be able to deconstruct
> everything in the right order, no matter which function call throws an
> exception at any point in the code. That can be big and messy,
> especially when the aim is to minimise any restrictions on the flow and
> efficiency of the code when exceptions are not thrown. So if you have a
> loop with function calls inside, and that loop is unrolled four times
> for speed, the unwind tables will need to grow to handle that.
>

I guess it is maybe easier in an implementation/language where:
class instances are typically always allocated on the heap (*1);
The language doesn't require destructors to be called in any particular
order.

*1: automatic scoped objects would be added to a linked list, and freed
on function return.

Similarly, a language is easier if one can't pass classes by copy either
(eg: if one uses mostly Java-style semantics here), ...

Struct types still leave the potential of introducing more complicated
copy-constructor / destructor semantics though.

>>
>> At least in my case, the '.pdata' section is ~ 3% the size of the
>> associated '.text' section. Granted, this is with the "reuse the machine
>> code from the epilog" trick.
>>
>> Though, they are better if not used.
>>
>> If one goes the "reuse DWARF debuginfo or similar" route, that is not
>> ideal.
>>
>>
>>> To me, a function has a specification - you have a pre-condition that
>>> the user guarantees will be true, and a post-condition that the function
>>> guarantees will be true at the end (and often an invariant that is true
>>> at the start, true at the end, but might be untrue during the function's
>>> execution).  If there is a function :
>>>
>>>     int convert_user_input_to_integer(const char * s);
>>>
>>> then the result /will/ be an int.  I don't accept that the function
>>> might throw its toys out of the pram because the user entered "foo", or
>>> "9813457895901890234728349238".  I am equally happy with :
>>>
>>>     std::optional<int> try_to_convert_user_input_to_integer(
>>>             const char * s);
>>>
>>> That can return std::nullopt on bad input.  (A struct with a "valid"
>>> bool field and a data field works just as well, but I've found
>>> std::optional to be quite convenient here.)
>>>
>>>
>>> RTTI I don't use, because I don't see a point in having dynamic typing
>>> in embedded code.  (Again, I'm fine with it in Python on a PC.)  I want
>>> to know what my types are.  If I have a function "foo" that can take one
>>> of several different types, then I have many safe and efficient ways to
>>> do that - template functions, overloads, inheritance, std::variant, etc.
>>>
>>
>> The space overhead of RTTI style metadata isn't too unreasonable, if
>> implemented sanely.
>>
>> In my case, it is ~24 bytes for the ClassInfo header, + 16 bytes per
>> field or method, with some additional space for strings.
>>
>> Though, now went and defined a "Small" variant which reduces FieldInfo
>> to 12 bytes, mostly by using 24-bit RVAs and a 16-bit offset.
>>
>>
>> The FieldInfo structures are needed mostly so that if one casts a
>> ClassObj to 'variant', this allows accessing object fields dynamically.
>>
>
> I agree that RTTI data is typically not too big - but it is all a waste
> for my kind of work (actually, not a lot of code uses RTTI or dynamic
> casts, except for exceptions as they require it).
>

Potentially. I guess there is the issue of not being able to easily know
which objects will need it, and most probably never will.

I do remember though that this is one area where my ABI diverges
significantly from the IA-64 C++ ABI, as the structures were needlessly
bulky in some ways, expressed things that I didn't need (eg: multiple
inheritance), and lacked some information which I felt was needed (such
as the ability to describe individual object fields or methods).

Eg, one doesn't need full width pointers if these structures can be
referenced using an RVA (typically with a "self pointer" in the
top-level structure being used to find the base-address for the other RVAs).

Then, say, we force alignment for the structure, but then use a
misaligned RVA to encode an RVA24 case (requires the program image to be
less than 16MB, and the class instance to be less than 64K).

Casting a class to a parent class or an interface can be safely done at
compile time with no runtime checks needed.

Casting a parent class back down to a subclass, or a parent class to a
subclass, may require runtime checks (and may potentially fail to
perform the case).

For the language in question, operators like "instanceof" will also
require runtime checks, ...

If one wants to have a generic object serializer or deserializer, this
would also require such metadata.

Say:
public class Serialize {
public void toSerialString(byte[] buffer, int &ofs, object obj);
public object fromSerialString(byte[] buffer, int &ofs);
}

Where, this flattens objects to strings, say:
public package bar.baz {
public class Foo {
int x, y;
transient int z; //not saved
public void doSomething(); //methods are N/A
...
}
public class Bar {
int z;
Foo p;
...
}
}

Then, an instance of Foo might be serialized, say:
{x:3,y:4}:bar/baz/Foo

For more complex objects, they may be walked in a graph, with referenced
objects folded out, say:
#1={x:3,y:4}:bar/baz/Foo
{z:5,p:#1}:bar/baz/Bar

Where both printing and parsing require metadata about the objects'
layout in order to do this.

>>
>>>
>>> You mentioned the "overhead" of C++.  There are only two serious
>>> breaches of the zero-overhead ("you don't pay for what you don't use")
>>> principle in the C++ core language - exceptions, and RTTI.  (There are
>>> plenty of parts of the standard library that are a lot bigger than you
>>> might want and end up linking in massive amounts of extra code.  The
>>> same applies in C, though its library is a lot smaller.  But here I am
>>> talking about the core language.)
>>>
>>
>> One doesn't usually push a binary up to 50 or 100 MB or similar just by
>> using RTTI or exceptions. One can, however, see this effect more often
>> when someone overuses templates in "Modern C++" style code...
>>
>
> I live in a world where 100 KB is a fair sized program.
>

I am mostly dealing with 300K - 800K binaries ATM.

Some of these same programs, when compiled with MSVC, lead to ~ 1-3 MB.

Typically the compiled '.text' section for x86-64 seems to be ~ 1.5x-2x
the size of a '.text' section for BJX2.

On Saturday, July 10, 2021 at 12:22:03 PM UTC-5, BGB wrote:
> On 7/10/2021 5:13 AM, David Brown wrote:
> > On 09/07/2021 23:07, BGB wrote:
> >> On 7/9/2021 4:25 AM, David Brown wrote:
> >>> On 08/07/2021 21:34, BGB wrote:
> >>>> On 7/8/2021 5:02 AM, David Brown wrote:
> >>>>> On 07/07/2021 21:22, BGB wrote:
> >
> >
> >>>>
> >>>>> (And you might want to disable exceptions and RTTI - it is standard
> >>>>> practice on small embedded systems and also in game programming.)
> >>>>>
> >>>>
> >>>> My feeling on these are mixed, both can be useful.
> >>>>
> >>>> My main issue with exceptions though is people trying to use them for
> >>>> general control flow rather than for "edge case where something has gone
> >>>> seriously wrong".
> >>>>
> >>>
> >>> I'm fine with exceptions on big systems - I use them happily in Python.
> >>> But on my embedded systems, I don't like things happening behind the
> >>> scenes. I don't like big tables for stack unwinding. I don't like
> >>> things being able to go wrong. I don't like code that says it will do
> >>> something, but might be lying.
> >>>
> >>
> >> The "big tables" thing seems partly an ABI thing.
> >>
> >> If the exception unwind table can be bit-packed down to around 8 bytes
> >> per function or so, it isn't too expensive in terms of space overhead.
> >
> > Exception tables for functions for small and simple functions are small.
> > They get big when you have more complicated data structures and classes
> > with destructors. You need enough tables to be able to deconstruct
> > everything in the right order, no matter which function call throws an
> > exception at any point in the code. That can be big and messy,
> > especially when the aim is to minimise any restrictions on the flow and
> > efficiency of the code when exceptions are not thrown. So if you have a
> > loop with function calls inside, and that loop is unrolled four times
> > for speed, the unwind tables will need to grow to handle that.
> >
> I guess it is maybe easier in an implementation/language where:
> class instances are typically always allocated on the heap (*1);
> The language doesn't require destructors to be called in any particular
> order.
>
> *1: automatic scoped objects would be added to a linked list, and freed
> on function return.
<
Also freed when stack is walked back on Exception processing (TRY-THROW-
CATCH) But instead of placing the allocated item on the linked list, one should
place the destructor of the linked list.
>
>
> Similarly, a language is easier if one can't pass classes by copy either
> (eg: if one uses mostly Java-style semantics here), ...
>
> Struct types still leave the potential of introducing more complicated
> copy-constructor / destructor semantics though.
> >>
> >> At least in my case, the '.pdata' section is ~ 3% the size of the
> >> associated '.text' section. Granted, this is with the "reuse the machine
> >> code from the epilog" trick.
> >>
> >> Though, they are better if not used.
> >>
> >> If one goes the "reuse DWARF debuginfo or similar" route, that is not
> >> ideal.
> >>
> >>
> >>> To me, a function has a specification - you have a pre-condition that
> >>> the user guarantees will be true, and a post-condition that the function
> >>> guarantees will be true at the end (and often an invariant that is true
> >>> at the start, true at the end, but might be untrue during the function's
> >>> execution). If there is a function :
> >>>
> >>> int convert_user_input_to_integer(const char * s);
> >>>
> >>> then the result /will/ be an int. I don't accept that the function
> >>> might throw its toys out of the pram because the user entered "foo", or
> >>> "9813457895901890234728349238". I am equally happy with :
> >>>
> >>> std::optional<int> try_to_convert_user_input_to_integer(
> >>> const char * s);
> >>>
> >>> That can return std::nullopt on bad input. (A struct with a "valid"
> >>> bool field and a data field works just as well, but I've found
> >>> std::optional to be quite convenient here.)
> >>>
> >>>
> >>> RTTI I don't use, because I don't see a point in having dynamic typing
> >>> in embedded code. (Again, I'm fine with it in Python on a PC.) I want
> >>> to know what my types are. If I have a function "foo" that can take one
> >>> of several different types, then I have many safe and efficient ways to
> >>> do that - template functions, overloads, inheritance, std::variant, etc.
> >>>
> >>
> >> The space overhead of RTTI style metadata isn't too unreasonable, if
> >> implemented sanely.
> >>
> >> In my case, it is ~24 bytes for the ClassInfo header, + 16 bytes per
> >> field or method, with some additional space for strings.
> >>
> >> Though, now went and defined a "Small" variant which reduces FieldInfo
> >> to 12 bytes, mostly by using 24-bit RVAs and a 16-bit offset.
> >>
> >>
> >> The FieldInfo structures are needed mostly so that if one casts a
> >> ClassObj to 'variant', this allows accessing object fields dynamically.
> >>
> >
> > I agree that RTTI data is typically not too big - but it is all a waste
> > for my kind of work (actually, not a lot of code uses RTTI or dynamic
> > casts, except for exceptions as they require it).
> >
> Potentially. I guess there is the issue of not being able to easily know
> which objects will need it, and most probably never will.
>
>
> I do remember though that this is one area where my ABI diverges
> significantly from the IA-64 C++ ABI, as the structures were needlessly
> bulky in some ways, expressed things that I didn't need (eg: multiple
> inheritance), and lacked some information which I felt was needed (such
> as the ability to describe individual object fields or methods).
>
> Eg, one doesn't need full width pointers if these structures can be
> referenced using an RVA (typically with a "self pointer" in the
> top-level structure being used to find the base-address for the other RVAs).
>
>
> Then, say, we force alignment for the structure, but then use a
> misaligned RVA to encode an RVA24 case (requires the program image to be
> less than 16MB, and the class instance to be less than 64K).
>
>
>
> Casting a class to a parent class or an interface can be safely done at
> compile time with no runtime checks needed.
>
> Casting a parent class back down to a subclass, or a parent class to a
> subclass, may require runtime checks (and may potentially fail to
> perform the case).
>
> For the language in question, operators like "instanceof" will also
> require runtime checks, ...
>
>
>
> If one wants to have a generic object serializer or deserializer, this
> would also require such metadata.
>
> Say:
> public class Serialize {
> public void toSerialString(byte[] buffer, int &ofs, object obj);
> public object fromSerialString(byte[] buffer, int &ofs);
> }
>
> Where, this flattens objects to strings, say:
> public package bar.baz {
> public class Foo {
> int x, y;
> transient int z; //not saved
> public void doSomething(); //methods are N/A
> ...
> }
> public class Bar {
> int z;
> Foo p;
> ...
> }
> }
>
> Then, an instance of Foo might be serialized, say:
> {x:3,y:4}:bar/baz/Foo
>
> For more complex objects, they may be walked in a graph, with referenced
> objects folded out, say:
> #1={x:3,y:4}:bar/baz/Foo
> {z:5,p:#1}:bar/baz/Bar
>
>
> Where both printing and parsing require metadata about the objects'
> layout in order to do this.
> >>
> >>>
> >>> You mentioned the "overhead" of C++. There are only two serious
> >>> breaches of the zero-overhead ("you don't pay for what you don't use")
> >>> principle in the C++ core language - exceptions, and RTTI. (There are
> >>> plenty of parts of the standard library that are a lot bigger than you
> >>> might want and end up linking in massive amounts of extra code. The
> >>> same applies in C, though its library is a lot smaller. But here I am
> >>> talking about the core language.)
> >>>
> >>
> >> One doesn't usually push a binary up to 50 or 100 MB or similar just by
> >> using RTTI or exceptions. One can, however, see this effect more often
> >> when someone overuses templates in "Modern C++" style code...
> >>
> >
> > I live in a world where 100 KB is a fair sized program.
> >
> I am mostly dealing with 300K - 800K binaries ATM.
>
>
> Some of these same programs, when compiled with MSVC, lead to ~ 1-3 MB.
>
> Typically the compiled '.text' section for x86-64 seems to be ~ 1.5x-2x
> the size of a '.text' section for BJX2.
>
> Things are generally a lot closer if comparing against i386 or Thumb2.
>
> Typically, Thumb2 is still generally the front-runner on the
> code-density front.
>
> Generally, the programs I am testing with here are primarily C.
>
>
> Some of the programs I have seen doing the whole "Modern C++" thing
> suffer from long build times and huge binaries (10s of MB or more for an
> otherwise moderately small program).
>
> I generally classify stuff like this as "something is horribly wrong here".
>
>
> Even with a mostly C-like style for C++, things still are not ideal. For
> example, Doom 3 is only like 900K lines, but still takes nearly 10
> minutes to recompile from source.
>
> In contrast, Quake 3 Arena can be recompiled in around 25 seconds.
>
>
>
> Though, for smaller programs, if I compile the same program in C or C++
> mode, there is usually negligible difference.
>
> I have made the observation with small programs that, basically, as soon
> as one includes something like "iostream" or similar, compile times are
> hosed.
> >>>>>
> >>>>> I think the cout-style output is a mixed blessing. It is convenient in
> >>>>> some ways, but fails in others. It is vastly superior to printf in
> >>>>> type
> >>>>> safety and flexibility in defining output formats for your own types.
> >>>>> It is vastly inferior for translating format strings, and for modifying
> >>>>> the format of number outputs.
> >>>>>
> >>>>
> >>>> There are limitations with printf, granted.
> >>>>
> >>>> Some are more due to C's particularly weak way of handling variable
> >>>> argument lists than due to the general design of its interface though.
> >>>>
> >>>
> >>> printf cannot be extended - that is its main limitation. Variable
> >>> argument lists are another big weakness, and a gaping hole in type
> >>> safety in the language.
> >>>
> >>
> >> In standard C, it can't be extended, but there is little to disallow a C
> >> library from adding an API extension to allow the program to register
> >> its own printf specifiers or similar via callbacks.
> >>
> >>
> >> Say, for example, if one could have something like (uses extensions):
> >> char *foo_print_v4f(__m128 xi, char *psp)
> >> {
> >> __vec4f mv;
> >> char *temp;
> >> temp=tk_ralloc(128); //temp allocate scratch memory
> >> mv=(__vec4f)(xi);
> >> sprintf(temp, "#[%f,%f,%f,%f]", mv.x, mv.y, mv.z, mv.w);
> >> return(temp);
> >> }
> >>
> >> _printf_addspec("X4f", "M128", foo_print_v4f);
> >> ...
> >> printf("%UX4f;\n", somevec);
> >>
> >> Where, say, the first parameter specifies the name of the user specifier
> >> (indicated via "%U...;"). The second parameter giving the base-type of
> >> the argument, eg:
> >> "I32" / "i": int
> >> "I64" / "li": long
> >> "I64" / "lli": long long
> >> "I128": Int128
> >> "M64": __m64
> >> "M128": __m128
> >> "f": float or double
> >> "lf": long double
> >>
> >> And the user-defined specifier callback prints the result to a string,
> >> which is then printed as-if it were "%s".
> >>
> >
> > Sure, that kind of thing would be possible. It is no longer printf,
> > however.
> >
> > People use a variety of different ways of outputting information -
> > printf and cout are just the standard ones.
> >
> If it still called "printf()", still accepts the original format
> strings, ... I suspect it still counts as "printf()".
>
> Granted, using such an extension would make any code which depends on it
> non-portable, but that is its own issue.
>
>
> It is like, one can add 'malloc' extensions like:
> _msize, _mgettag, _msettag, _mincref, _mdecref, ...
>
> To their malloc allocator, and it is still malloc as far as everything
> else is concerned.
>
> Where, say:
> _mgettag/_msettag get or set a dynamic-type-tag for the object (*1);
> _mincref/_mdecref can adjust an internal reference count, where "free()"
> is called on the object if "_mdecref()" is called on the object and its
> internal refcount <= 0;
> ...
>
> *1: Where, say, the tag is an unsigned 16-bit ID number, normally set to
> 0 for plain "malloc", with 0000..3FFF being reserved for the runtime,
> and 4000..7FFF being available for user code.
>
> Then, say, the runtime region is subdivided, and:
> 0000..0FFF: Used as object type-tags for dynamically-typed objects,
> which are associated with a symbolic name (mapping name->ID number being
> itself done with a runtime call), and may be split into a "static" and
> "dynamic" range (static IDs are fixed at compile time).
>
> ...
> >>>>
> >>>>>>
> >>>>>> It is possibly telling that two of its major 'successors' (Java and
> >>>>>> C#),
> >>>>>> either eventually or initially, mostly went back to doing it in a
> >>>>>> similar way to C.
> >>>>>>
> >>>>>
> >>>>> (There is a new system of formatted output on its way to the C++
> >>>>> library.)
> >>>>>
> >>>>
> >>>> If it is essentially a rebranded "printf", that would be amusing...
> >>>>
> >>>
> >>> <https://en.cppreference.com/w/cpp/utility/format/format>
> >>>
> >>> No, it is not a copy of printf - but it is an attempt at getting some of
> >>> the advantages printf has over std::cout into a type-safe and extendable
> >>> C++ solution. I haven't used it or examined the details, so I can't say
> >>> how well it succeeds.
> >>>
> >>
> >> So, you do:
> >> using namespace std; //... standard practice ...
> >> cout << format("string...", args...);
> >>
> >> When you could do, say:
> >> printf("string...", args...);
> >>
> >
> > As I said, it tries to get some of the advantages of printf, but does so
> > in a C++ manner. The format string is quite different, and it is all
> > type-safe and extendible - the types of the arguments determine how the
> > printing is done, not a little printf-language interpreter.
> >
> OK. It seems otherwise kinda like the C# printing mechanism, but as
> noted I had considered it printf like despite the slightly different
> syntax and handling of argument types.
>
>
> Java later ended up doing something vaguely similar as well, albeit
> sticking a little closer to C's printf in terms of behavior and notation.
>
> Probably because something like:
> System.out.print("Hey ").print(3).print(" ").print(4).print("\n");
>
> Is kinda awful...
> >>
> >>>>
> >>>> But, as noted, since the standard C++ library mostly consists of:
> >>>> Stuff from the C library, just slightly repackaged;
> >>>> A lot of stuff that is, a bit, questionable;
> >>>> Stuff that builds on templates;
> >>>> ...
> >>>>
> >>>> I am prone to mostly ignore its existence.
> >>>>
> >>>> There are OK parts, like "std::string" seems "not awful", ...
> >>>>
> >>>
> >>> That leaves me wondering if you have looked at the C++ standard library
> >>> since the previous century.
> >>>
> >>> I can certainly say that I only use a very small proportion of it in my
> >>> embedded programming - but then, I only use a very small proportion of
> >>> the C standard library in embedded C programming.
> >>>
> >>
> >> I have mostly been ignoring it, since in the rare cases I have reason to
> >> use C++, there is still generally the C library, which I am a lot more
> >> familiar with.
> >>
> >>
> >>>>
> >>>>>>>>
> >>>>>>>> Leaving out templates also eliminates on of the major sources of
> >>>>>>>> massive
> >>>>>>>> code bloat and excessive build times.
> >>>>>>>>
> >>>>>>>
> >>>>>>> Misuse of templates can lead to code bloat, especially with poorer
> >>>>>>> compilers. Good use of templates makes code smaller as the
> >>>>>>> generality
> >>>>>>> is handled
> >>>>>>>
> >>>>>>
> >>>>>> I have usually seen code get bigger.
> >>>>>>
> >>>>>>
> >>>>>> There are possible ways to combat expansion, in theory, but I am not
> >>>>>> sure if they are really allowed or commonly done.
> >>>>>
> >>>>> The most obvious way is that a lot of template functions are quite
> >>>>> small, and thus end up inlined saving space (no function call, no
> >>>>> register movements, saves and restores, more scope for other
> >>>>> optimisations).
> >>>>>
> >>>>
> >>>> Not ideal if the compiler lacks support for inlining...
> >>>
> >>> A compiler that can't inline (automatically, as well as when suggested
> >>> by the "inline" qualifier) doesn't count as a modern quality compiler.
> >>> I have had to use such poor compilers in the past for C coding, and have
> >>> been happy to leave them in the past. I would not consider using such a
> >>> limited tool for C programming now, never mind C++ programming. (I
> >>> highly doubt that there are any compilers that support C++ and don't do
> >>> good inlining.)
> >>>
> >>
> >> Possibly, if anything because the barrier to entry to competently
> >> supporting C++ is a lot higher than is needed for inlining.
> >>
> >
> > That is one way of looking at it, I suppose.
> >
> >
> Inlining is one of those features which isn't too hard in concept, but
> opens a lot of potentially ugly issues in the implementation, different
> ways it could be implemented, and concerns for possible effects on
> semantics which could effect the correct behavior of a program,
> potential for adverse effects on program size, ...
>
>
> In contrast, while a macro is not a function, its behavior is well
> defined, and its handling by an implementation is relatively
> straightforward.
>
> And, if a programmer abuses preprocessor macros and the size of their
> binary explodes as a result, they have no one to blame but themselves...
<
Yet, if they exploit the preprocessor properly, their program gets smaller
and more readable.

On 7/10/2021 12:41 PM, MitchAlsup wrote:
> On Saturday, July 10, 2021 at 12:22:03 PM UTC-5, BGB wrote:
>> On 7/10/2021 5:13 AM, David Brown wrote:
>>> On 09/07/2021 23:07, BGB wrote:
>>>> On 7/9/2021 4:25 AM, David Brown wrote:
>>>>> On 08/07/2021 21:34, BGB wrote:
>>>>>> On 7/8/2021 5:02 AM, David Brown wrote:
>>>>>>> On 07/07/2021 21:22, BGB wrote:
>>>
>>>
>>>>>>
>>>>>>> (And you might want to disable exceptions and RTTI - it is standard
>>>>>>> practice on small embedded systems and also in game programming.)
>>>>>>>
>>>>>>
>>>>>> My feeling on these are mixed, both can be useful.
>>>>>>
>>>>>> My main issue with exceptions though is people trying to use them for
>>>>>> general control flow rather than for "edge case where something has gone
>>>>>> seriously wrong".
>>>>>>
>>>>>
>>>>> I'm fine with exceptions on big systems - I use them happily in Python.
>>>>> But on my embedded systems, I don't like things happening behind the
>>>>> scenes. I don't like big tables for stack unwinding. I don't like
>>>>> things being able to go wrong. I don't like code that says it will do
>>>>> something, but might be lying.
>>>>>
>>>>
>>>> The "big tables" thing seems partly an ABI thing.
>>>>
>>>> If the exception unwind table can be bit-packed down to around 8 bytes
>>>> per function or so, it isn't too expensive in terms of space overhead.
>>>
>>> Exception tables for functions for small and simple functions are small.
>>> They get big when you have more complicated data structures and classes
>>> with destructors. You need enough tables to be able to deconstruct
>>> everything in the right order, no matter which function call throws an
>>> exception at any point in the code. That can be big and messy,
>>> especially when the aim is to minimise any restrictions on the flow and
>>> efficiency of the code when exceptions are not thrown. So if you have a
>>> loop with function calls inside, and that loop is unrolled four times
>>> for speed, the unwind tables will need to grow to handle that.
>>>
>> I guess it is maybe easier in an implementation/language where:
>> class instances are typically always allocated on the heap (*1);
>> The language doesn't require destructors to be called in any particular
>> order.
>>
>> *1: automatic scoped objects would be added to a linked list, and freed
>> on function return.
> <
> Also freed when stack is walked back on Exception processing (TRY-THROW-
> CATCH) But instead of placing the allocated item on the linked list, one should
> place the destructor of the linked list.

This is more-or-less how it is intended to work, just say with the
memory object having a layout like:
next pointer
pointer to 'free()' function or destructor;
payload data.

And, the unwinder logic could see that objects were allocated via the
linked list, and then process it to free or destroy any objects held in
the list.

Otherwise... It would have been simpler to not bother with unwinding and
instead build the exception mechanism around a linked list of
setjmp/longjmp frames or similar (*1).

Though, as noted:
This makes try/catch slower and more expensive in the no-exception case;
This doesn't allow for unwinding in child frames without them (in
effect) introducing their own implicit try/catch blocks;
However, it could be faster to handle a thrown exception.

Doing it with unwinding tables makes "try/catch" blocks cheaper, allows
for unwinding child frames with no additional overhead, ... However,
with the drawback that "throw" is a lot more complicated and is
significantly slower.

*1: Say, for example:
try { ... } catch(Exception e) { ... }
Becomes, effectively something like:
if(!setjmp(eh_frame))
{
eh_frame->eh_chain = __tbr_exception_chain;
__tbr_exception_chain = eh_frame;
...
__tbr_exception_chain = eh_frame->eh_chain;
}else
{
... catch magic ...
}

And:
throw e;
Becomes, effectively:
__tbr_exception_obj = e;
longjmp(__tbr_exception_chain, 1);

>>
>>
>> Similarly, a language is easier if one can't pass classes by copy either
>> (eg: if one uses mostly Java-style semantics here), ...
>>
>> Struct types still leave the potential of introducing more complicated
>> copy-constructor / destructor semantics though.
>>>>
>>>> At least in my case, the '.pdata' section is ~ 3% the size of the
>>>> associated '.text' section. Granted, this is with the "reuse the machine
>>>> code from the epilog" trick.
>>>>
>>>> Though, they are better if not used.
>>>>
>>>> If one goes the "reuse DWARF debuginfo or similar" route, that is not
>>>> ideal.
>>>>
>>>>
>>>>> To me, a function has a specification - you have a pre-condition that
>>>>> the user guarantees will be true, and a post-condition that the function
>>>>> guarantees will be true at the end (and often an invariant that is true
>>>>> at the start, true at the end, but might be untrue during the function's
>>>>> execution). If there is a function :
>>>>>
>>>>> int convert_user_input_to_integer(const char * s);
>>>>>
>>>>> then the result /will/ be an int. I don't accept that the function
>>>>> might throw its toys out of the pram because the user entered "foo", or
>>>>> "9813457895901890234728349238". I am equally happy with :
>>>>>
>>>>> std::optional<int> try_to_convert_user_input_to_integer(
>>>>> const char * s);
>>>>>
>>>>> That can return std::nullopt on bad input. (A struct with a "valid"
>>>>> bool field and a data field works just as well, but I've found
>>>>> std::optional to be quite convenient here.)
>>>>>
>>>>>
>>>>> RTTI I don't use, because I don't see a point in having dynamic typing
>>>>> in embedded code. (Again, I'm fine with it in Python on a PC.) I want
>>>>> to know what my types are. If I have a function "foo" that can take one
>>>>> of several different types, then I have many safe and efficient ways to
>>>>> do that - template functions, overloads, inheritance, std::variant, etc.
>>>>>
>>>>
>>>> The space overhead of RTTI style metadata isn't too unreasonable, if
>>>> implemented sanely.
>>>>
>>>> In my case, it is ~24 bytes for the ClassInfo header, + 16 bytes per
>>>> field or method, with some additional space for strings.
>>>>
>>>> Though, now went and defined a "Small" variant which reduces FieldInfo
>>>> to 12 bytes, mostly by using 24-bit RVAs and a 16-bit offset.
>>>>
>>>>
>>>> The FieldInfo structures are needed mostly so that if one casts a
>>>> ClassObj to 'variant', this allows accessing object fields dynamically.
>>>>
>>>
>>> I agree that RTTI data is typically not too big - but it is all a waste
>>> for my kind of work (actually, not a lot of code uses RTTI or dynamic
>>> casts, except for exceptions as they require it).
>>>
>> Potentially. I guess there is the issue of not being able to easily know
>> which objects will need it, and most probably never will.
>>
>>
>> I do remember though that this is one area where my ABI diverges
>> significantly from the IA-64 C++ ABI, as the structures were needlessly
>> bulky in some ways, expressed things that I didn't need (eg: multiple
>> inheritance), and lacked some information which I felt was needed (such
>> as the ability to describe individual object fields or methods).
>>
>> Eg, one doesn't need full width pointers if these structures can be
>> referenced using an RVA (typically with a "self pointer" in the
>> top-level structure being used to find the base-address for the other RVAs).
>>
>>
>> Then, say, we force alignment for the structure, but then use a
>> misaligned RVA to encode an RVA24 case (requires the program image to be
>> less than 16MB, and the class instance to be less than 64K).
>>
>>
>>
>> Casting a class to a parent class or an interface can be safely done at
>> compile time with no runtime checks needed.
>>
>> Casting a parent class back down to a subclass, or a parent class to a
>> subclass, may require runtime checks (and may potentially fail to
>> perform the case).
>>
>> For the language in question, operators like "instanceof" will also
>> require runtime checks, ...
>>
>>
>>
>> If one wants to have a generic object serializer or deserializer, this
>> would also require such metadata.
>>
>> Say:
>> public class Serialize {
>> public void toSerialString(byte[] buffer, int &ofs, object obj);
>> public object fromSerialString(byte[] buffer, int &ofs);
>> }
>>
>> Where, this flattens objects to strings, say:
>> public package bar.baz {
>> public class Foo {
>> int x, y;
>> transient int z; //not saved
>> public void doSomething(); //methods are N/A
>> ...
>> }
>> public class Bar {
>> int z;
>> Foo p;
>> ...
>> }
>> }
>>
>> Then, an instance of Foo might be serialized, say:
>> {x:3,y:4}:bar/baz/Foo
>>
>> For more complex objects, they may be walked in a graph, with referenced
>> objects folded out, say:
>> #1={x:3,y:4}:bar/baz/Foo
>> {z:5,p:#1}:bar/baz/Bar
>>
>>
>> Where both printing and parsing require metadata about the objects'
>> layout in order to do this.
>>>>
>>>>>
>>>>> You mentioned the "overhead" of C++. There are only two serious
>>>>> breaches of the zero-overhead ("you don't pay for what you don't use")
>>>>> principle in the C++ core language - exceptions, and RTTI. (There are
>>>>> plenty of parts of the standard library that are a lot bigger than you
>>>>> might want and end up linking in massive amounts of extra code. The
>>>>> same applies in C, though its library is a lot smaller. But here I am
>>>>> talking about the core language.)
>>>>>
>>>>
>>>> One doesn't usually push a binary up to 50 or 100 MB or similar just by
>>>> using RTTI or exceptions. One can, however, see this effect more often
>>>> when someone overuses templates in "Modern C++" style code...
>>>>
>>>
>>> I live in a world where 100 KB is a fair sized program.
>>>
>> I am mostly dealing with 300K - 800K binaries ATM.
>>
>>
>> Some of these same programs, when compiled with MSVC, lead to ~ 1-3 MB.
>>
>> Typically the compiled '.text' section for x86-64 seems to be ~ 1.5x-2x
>> the size of a '.text' section for BJX2.
>>
>> Things are generally a lot closer if comparing against i386 or Thumb2.
>>
>> Typically, Thumb2 is still generally the front-runner on the
>> code-density front.
>>
>> Generally, the programs I am testing with here are primarily C.
>>
>>
>> Some of the programs I have seen doing the whole "Modern C++" thing
>> suffer from long build times and huge binaries (10s of MB or more for an
>> otherwise moderately small program).
>>
>> I generally classify stuff like this as "something is horribly wrong here".
>>
>>
>> Even with a mostly C-like style for C++, things still are not ideal. For
>> example, Doom 3 is only like 900K lines, but still takes nearly 10
>> minutes to recompile from source.
>>
>> In contrast, Quake 3 Arena can be recompiled in around 25 seconds.
>>
>>
>>
>> Though, for smaller programs, if I compile the same program in C or C++
>> mode, there is usually negligible difference.
>>
>> I have made the observation with small programs that, basically, as soon
>> as one includes something like "iostream" or similar, compile times are
>> hosed.
>>>>>>>
>>>>>>> I think the cout-style output is a mixed blessing. It is convenient in
>>>>>>> some ways, but fails in others. It is vastly superior to printf in
>>>>>>> type
>>>>>>> safety and flexibility in defining output formats for your own types.
>>>>>>> It is vastly inferior for translating format strings, and for modifying
>>>>>>> the format of number outputs.
>>>>>>>
>>>>>>
>>>>>> There are limitations with printf, granted.
>>>>>>
>>>>>> Some are more due to C's particularly weak way of handling variable
>>>>>> argument lists than due to the general design of its interface though.
>>>>>>
>>>>>
>>>>> printf cannot be extended - that is its main limitation. Variable
>>>>> argument lists are another big weakness, and a gaping hole in type
>>>>> safety in the language.
>>>>>
>>>>
>>>> In standard C, it can't be extended, but there is little to disallow a C
>>>> library from adding an API extension to allow the program to register
>>>> its own printf specifiers or similar via callbacks.
>>>>
>>>>
>>>> Say, for example, if one could have something like (uses extensions):
>>>> char *foo_print_v4f(__m128 xi, char *psp)
>>>> {
>>>> __vec4f mv;
>>>> char *temp;
>>>> temp=tk_ralloc(128); //temp allocate scratch memory
>>>> mv=(__vec4f)(xi);
>>>> sprintf(temp, "#[%f,%f,%f,%f]", mv.x, mv.y, mv.z, mv.w);
>>>> return(temp);
>>>> }
>>>>
>>>> _printf_addspec("X4f", "M128", foo_print_v4f);
>>>> ...
>>>> printf("%UX4f;\n", somevec);
>>>>
>>>> Where, say, the first parameter specifies the name of the user specifier
>>>> (indicated via "%U...;"). The second parameter giving the base-type of
>>>> the argument, eg:
>>>> "I32" / "i": int
>>>> "I64" / "li": long
>>>> "I64" / "lli": long long
>>>> "I128": Int128
>>>> "M64": __m64
>>>> "M128": __m128
>>>> "f": float or double
>>>> "lf": long double
>>>>
>>>> And the user-defined specifier callback prints the result to a string,
>>>> which is then printed as-if it were "%s".
>>>>
>>>
>>> Sure, that kind of thing would be possible. It is no longer printf,
>>> however.
>>>
>>> People use a variety of different ways of outputting information -
>>> printf and cout are just the standard ones.
>>>
>> If it still called "printf()", still accepts the original format
>> strings, ... I suspect it still counts as "printf()".
>>
>> Granted, using such an extension would make any code which depends on it
>> non-portable, but that is its own issue.
>>
>>
>> It is like, one can add 'malloc' extensions like:
>> _msize, _mgettag, _msettag, _mincref, _mdecref, ...
>>
>> To their malloc allocator, and it is still malloc as far as everything
>> else is concerned.
>>
>> Where, say:
>> _mgettag/_msettag get or set a dynamic-type-tag for the object (*1);
>> _mincref/_mdecref can adjust an internal reference count, where "free()"
>> is called on the object if "_mdecref()" is called on the object and its
>> internal refcount <= 0;
>> ...
>>
>> *1: Where, say, the tag is an unsigned 16-bit ID number, normally set to
>> 0 for plain "malloc", with 0000..3FFF being reserved for the runtime,
>> and 4000..7FFF being available for user code.
>>
>> Then, say, the runtime region is subdivided, and:
>> 0000..0FFF: Used as object type-tags for dynamically-typed objects,
>> which are associated with a symbolic name (mapping name->ID number being
>> itself done with a runtime call), and may be split into a "static" and
>> "dynamic" range (static IDs are fixed at compile time).
>>
>> ...
>>>>>>
>>>>>>>>
>>>>>>>> It is possibly telling that two of its major 'successors' (Java and
>>>>>>>> C#),
>>>>>>>> either eventually or initially, mostly went back to doing it in a
>>>>>>>> similar way to C.
>>>>>>>>
>>>>>>>
>>>>>>> (There is a new system of formatted output on its way to the C++
>>>>>>> library.)
>>>>>>>
>>>>>>
>>>>>> If it is essentially a rebranded "printf", that would be amusing...
>>>>>>
>>>>>
>>>>> <https://en.cppreference.com/w/cpp/utility/format/format>
>>>>>
>>>>> No, it is not a copy of printf - but it is an attempt at getting some of
>>>>> the advantages printf has over std::cout into a type-safe and extendable
>>>>> C++ solution. I haven't used it or examined the details, so I can't say
>>>>> how well it succeeds.
>>>>>
>>>>
>>>> So, you do:
>>>> using namespace std; //... standard practice ...
>>>> cout << format("string...", args...);
>>>>
>>>> When you could do, say:
>>>> printf("string...", args...);
>>>>
>>>
>>> As I said, it tries to get some of the advantages of printf, but does so
>>> in a C++ manner. The format string is quite different, and it is all
>>> type-safe and extendible - the types of the arguments determine how the
>>> printing is done, not a little printf-language interpreter.
>>>
>> OK. It seems otherwise kinda like the C# printing mechanism, but as
>> noted I had considered it printf like despite the slightly different
>> syntax and handling of argument types.
>>
>>
>> Java later ended up doing something vaguely similar as well, albeit
>> sticking a little closer to C's printf in terms of behavior and notation.
>>
>> Probably because something like:
>> System.out.print("Hey ").print(3).print(" ").print(4).print("\n");
>>
>> Is kinda awful...
>>>>
>>>>>>
>>>>>> But, as noted, since the standard C++ library mostly consists of:
>>>>>> Stuff from the C library, just slightly repackaged;
>>>>>> A lot of stuff that is, a bit, questionable;
>>>>>> Stuff that builds on templates;
>>>>>> ...
>>>>>>
>>>>>> I am prone to mostly ignore its existence.
>>>>>>
>>>>>> There are OK parts, like "std::string" seems "not awful", ...
>>>>>>
>>>>>
>>>>> That leaves me wondering if you have looked at the C++ standard library
>>>>> since the previous century.
>>>>>
>>>>> I can certainly say that I only use a very small proportion of it in my
>>>>> embedded programming - but then, I only use a very small proportion of
>>>>> the C standard library in embedded C programming.
>>>>>
>>>>
>>>> I have mostly been ignoring it, since in the rare cases I have reason to
>>>> use C++, there is still generally the C library, which I am a lot more
>>>> familiar with.
>>>>
>>>>
>>>>>>
>>>>>>>>>>
>>>>>>>>>> Leaving out templates also eliminates on of the major sources of
>>>>>>>>>> massive
>>>>>>>>>> code bloat and excessive build times.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Misuse of templates can lead to code bloat, especially with poorer
>>>>>>>>> compilers. Good use of templates makes code smaller as the
>>>>>>>>> generality
>>>>>>>>> is handled
>>>>>>>>>
>>>>>>>>
>>>>>>>> I have usually seen code get bigger.
>>>>>>>>
>>>>>>>>
>>>>>>>> There are possible ways to combat expansion, in theory, but I am not
>>>>>>>> sure if they are really allowed or commonly done.
>>>>>>>
>>>>>>> The most obvious way is that a lot of template functions are quite
>>>>>>> small, and thus end up inlined saving space (no function call, no
>>>>>>> register movements, saves and restores, more scope for other
>>>>>>> optimisations).
>>>>>>>
>>>>>>
>>>>>> Not ideal if the compiler lacks support for inlining...
>>>>>
>>>>> A compiler that can't inline (automatically, as well as when suggested
>>>>> by the "inline" qualifier) doesn't count as a modern quality compiler.
>>>>> I have had to use such poor compilers in the past for C coding, and have
>>>>> been happy to leave them in the past. I would not consider using such a
>>>>> limited tool for C programming now, never mind C++ programming. (I
>>>>> highly doubt that there are any compilers that support C++ and don't do
>>>>> good inlining.)
>>>>>
>>>>
>>>> Possibly, if anything because the barrier to entry to competently
>>>> supporting C++ is a lot higher than is needed for inlining.
>>>>
>>>
>>> That is one way of looking at it, I suppose.
>>>
>>>
>> Inlining is one of those features which isn't too hard in concept, but
>> opens a lot of potentially ugly issues in the implementation, different
>> ways it could be implemented, and concerns for possible effects on
>> semantics which could effect the correct behavior of a program,
>> potential for adverse effects on program size, ...
>>
>>
>> In contrast, while a macro is not a function, its behavior is well
>> defined, and its handling by an implementation is relatively
>> straightforward.
>>
>> And, if a programmer abuses preprocessor macros and the size of their
>> binary explodes as a result, they have no one to blame but themselves...
> <
> Yet, if they exploit the preprocessor properly, their program gets smaller
> and more readable.
>

On Saturday, July 10, 2021 at 2:37:20 PM UTC-5, BGB wrote:
> On 7/10/2021 12:41 PM, MitchAlsup wrote:
> > On Saturday, July 10, 2021 at 12:22:03 PM UTC-5, BGB wrote:

> >>
> >> *1: automatic scoped objects would be added to a linked list, and freed
> >> on function return.
> > <
> > Also freed when stack is walked back on Exception processing (TRY-THROW-
> > CATCH) But instead of placing the allocated item on the linked list, one should
> > place the destructor of the linked list.
> This is more-or-less how it is intended to work, just say with the
> memory object having a layout like:
> next pointer
> pointer to 'free()' function or destructor;
> payload data.
>
> And, the unwinder logic could see that objects were allocated via the
> linked list, and then process it to free or destroy any objects held in
> the list.
>
>
>
> Otherwise... It would have been simpler to not bother with unwinding and
> instead build the exception mechanism around a linked list of
> setjmp/longjmp frames or similar (*1).
>
> Though, as noted:
> This makes try/catch slower and more expensive in the no-exception case;
> This doesn't allow for unwinding in child frames without them (in
> effect) introducing their own implicit try/catch blocks;
> However, it could be faster to handle a thrown exception.
>
> Doing it with unwinding tables makes "try/catch" blocks cheaper, allows
> for unwinding child frames with no additional overhead, ... However,
> with the drawback that "throw" is a lot more complicated and is
> significantly slower.
>
>
> *1: Say, for example:
> try { ... } catch(Exception e) { ... }
> Becomes, effectively something like:
> if(!setjmp(eh_frame))
> {
> eh_frame->eh_chain = __tbr_exception_chain;
> __tbr_exception_chain = eh_frame;
> ...
> __tbr_exception_chain = eh_frame->eh_chain;
> }else
> {
> ... catch magic ...
> }
>
> And:
> throw e;
> Becomes, effectively:
> __tbr_exception_obj = e;
> longjmp(__tbr_exception_chain, 1);
<
But you have not performed the destructors or the free's, unless you just made longjump
a lot slower.
<
> >>
> >>
> >> Similarly, a language is easier if one can't pass classes by copy either
> >> (eg: if one uses mostly Java-style semantics here), ...
> >>
<snip>
> >>
> >> In contrast, while a macro is not a function, its behavior is well
> >> defined, and its handling by an implementation is relatively
> >> straightforward.
> >>
> >> And, if a programmer abuses preprocessor macros and the size of their
> >> binary explodes as a result, they have no one to blame but themselves...
> > <
> > Yet, if they exploit the preprocessor properly, their program gets smaller
> > and more readable.
> >
> Yes, possible as well...
>
> It can be noted that, despite my custom languages' relations to
> JavaScript and Java, it still retains the use of a C style preprocessor.
>
>
> I had generally ended up coming to the opinion that preprocessor macros
> ultimately help more than they hurt, and the language is meant partly
> more of a "get stuff done" language than a "try to nanny the programmers
> and force them to 'do the right thing'" language.
>
> Also it still has pointers and similar, so it is possible to use it in a
> C like style as well, though its typesystem is a little more restrictive
> when compared with C.
>
>
> Most of the differences though exist mostly in the frontend, and the
> compiler backend actually doesn't really know or care which front-end
> language it is dealing with.
>
> To some extent, I am trying to keep the language efficient, namely:
> string str = "Some String";
> Actually has a lot more in common with:
> const char *str = "Some String";
>
> Than it does with any high-level "String Object" type.
> And, by extension, are typically NUL terminated (or, in effect, unlike C
> strings they actually use a bidirectional double-ended termination
> scheme), ...

On 7/10/2021 5:41 PM, MitchAlsup wrote:
> On Saturday, July 10, 2021 at 2:37:20 PM UTC-5, BGB wrote:
>> On 7/10/2021 12:41 PM, MitchAlsup wrote:
>>> On Saturday, July 10, 2021 at 12:22:03 PM UTC-5, BGB wrote:
>
>>>>
>>>> *1: automatic scoped objects would be added to a linked list, and freed
>>>> on function return.
>>> <
>>> Also freed when stack is walked back on Exception processing (TRY-THROW-
>>> CATCH) But instead of placing the allocated item on the linked list, one should
>>> place the destructor of the linked list.
>> This is more-or-less how it is intended to work, just say with the
>> memory object having a layout like:
>> next pointer
>> pointer to 'free()' function or destructor;
>> payload data.
>>
>> And, the unwinder logic could see that objects were allocated via the
>> linked list, and then process it to free or destroy any objects held in
>> the list.
>>
As can be noted, the above is what I have been going with thus far.

>>
>> Otherwise... It would have been simpler to not bother with unwinding and
>> instead build the exception mechanism around a linked list of
>> setjmp/longjmp frames or similar (*1).
>>
>> Though, as noted:
>> This makes try/catch slower and more expensive in the no-exception case;
>> This doesn't allow for unwinding in child frames without them (in
>> effect) introducing their own implicit try/catch blocks;
>> However, it could be faster to handle a thrown exception.
>>
>> Doing it with unwinding tables makes "try/catch" blocks cheaper, allows
>> for unwinding child frames with no additional overhead, ... However,
>> with the drawback that "throw" is a lot more complicated and is
>> significantly slower.
>>
>>
>> *1: Say, for example:
>> try { ... } catch(Exception e) { ... }
>> Becomes, effectively something like:
>> if(!setjmp(eh_frame))
>> {
>> eh_frame->eh_chain = __tbr_exception_chain;
>> __tbr_exception_chain = eh_frame;
>> ...
>> __tbr_exception_chain = eh_frame->eh_chain;
>> }else
>> {
>> ... catch magic ...
>> }
>>
>> And:
>> throw e;
>> Becomes, effectively:
>> __tbr_exception_obj = e;
>> longjmp(__tbr_exception_chain, 1);
> <
> But you have not performed the destructors or the free's, unless you just made longjump
> a lot slower.
> <

That is a potential major drawback:
Unwinding could effectively cost an exception handler + rethrow frame
for every stack frame which has destructors which need to be called, ...

I thought about it, and realized this option could potentially suffer a
lot worse in terms of both stack memory usage and code footprint
overhead (so may not be viable in practice).

Then also thought about it, and realized that the unwind logic could be
made simpler and faster if, instead of reusing the main function epilog
with an interpreter, the compiler instead emits a secondary entry point
into the epilog.

This secondary entry point:
Reloads the saved LR;
Moves it to a special register;
Saves the address from the unwind logic where the original LR went;
Branches back into the original epilog.

The epilog logic then functions as-normal, except that control from it
is redirected back into the unwind logic rather than into the original
caller function.

Would require some fairly awkward logic though.
Chances are, in this case, the unwind logic would need to be written in
ASM, and likely use TLS variables or similar for its internal working
state (can't use global variables as GBR would also be in-flux).

Could maybe also require that the ".pdata" table have its entries sorted
by RVA, as this would allow for using binary search.

....

>>>>
>>>>
>>>> Similarly, a language is easier if one can't pass classes by copy either
>>>> (eg: if one uses mostly Java-style semantics here), ...
>>>>
> <snip>
>>>>
>>>> In contrast, while a macro is not a function, its behavior is well
>>>> defined, and its handling by an implementation is relatively
>>>> straightforward.
>>>>
>>>> And, if a programmer abuses preprocessor macros and the size of their
>>>> binary explodes as a result, they have no one to blame but themselves...
>>> <
>>> Yet, if they exploit the preprocessor properly, their program gets smaller
>>> and more readable.
>>>
>> Yes, possible as well...
>>
>> It can be noted that, despite my custom languages' relations to
>> JavaScript and Java, it still retains the use of a C style preprocessor.
>>
>>
>> I had generally ended up coming to the opinion that preprocessor macros
>> ultimately help more than they hurt, and the language is meant partly
>> more of a "get stuff done" language than a "try to nanny the programmers
>> and force them to 'do the right thing'" language.
>>
>> Also it still has pointers and similar, so it is possible to use it in a
>> C like style as well, though its typesystem is a little more restrictive
>> when compared with C.
>>
>>
>> Most of the differences though exist mostly in the frontend, and the
>> compiler backend actually doesn't really know or care which front-end
>> language it is dealing with.
>>
>> To some extent, I am trying to keep the language efficient, namely:
>> string str = "Some String";
>> Actually has a lot more in common with:
>> const char *str = "Some String";
>>
>> Than it does with any high-level "String Object" type.
>> And, by extension, are typically NUL terminated (or, in effect, unlike C
>> strings they actually use a bidirectional double-ended termination
>> scheme), ...