Re: groff's C++ dialect (was: Plan 9 man added a new macro for man page references)

[James K. Lowden]

On Sat, 14 Aug 2021 01:57:49 +1000
"G. Branden Robinson" <g.branden.robinson@gmail.com> wrote:

> A tradition, acquired at tremendous cost, has grown up
> around C++ over the past couple of decades that a project in the
> language is unmanageable and unmaintainable if you don't
> articulate--and stick to--the subset of it that you aim to use.

That tradition, if that's what it is, is as old as C++ itself.  Every
migration I've ever seen from C to C++ included a long a pointless
discussion about using only features X and never features Y.  A
favorite member of both X and Y is <string>.  

C++ is a gigantic, multiparadigmatic language.  The temptation is to
find some subset that's understandable.  That effort is ultimately
futile, because every feature exists on purpose, for a reason, and
meets some need.  If you think groff doesn't need templates or
exceptions, I'm not going to argue, except to say that when those
features could be used, you'll use another (perhaps more familar)
method instead.  

> I am also skeptical that groff has much need for standard C++'s
> extended cast operators.  

These were invented because regular expressions.  It's impossible to
scan C source code for casts; the "noisier" form made them easier to
find. Also, by making them more precise the programmer could do a
better job of conveying intent, and the compiler a better job of
checking it.  

> 2. I _think_ this weird "a_delete" thing we often see is a hack people
>    had to implement back in the day, before the language implemented
>    destructors for array types.  

I don't know what "a_delete" is, not being familar with the source
code.  I do know there was never a time before the language implemented
delete[].  It's described in my pre-ANSI copy of the C++ Annotated
Reference Manual.  

Depending on use and implementation, it's sometimes possible to call
delete where delete[] is correct: if the implementation maintains the
array as "just a pointer", and the array elements have no destructor.
I recently corrected a library that took many such liberties, and
evidently used to work, but more recently manifested memory leaks and
violations.  

--jkl