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

[G. Branden Robinson]

Hi, James!

At 2021-08-26T10:22:00-0400, James K. Lowden wrote:
> 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.

The groff code base does indeed hack around its (near) lack of templates
in the files src/include/[ip]table.h.

But apart from that observation I'm not sure how to respond to your
position except to observe that other organizations have not adopted it;
Google has a C++ coding standard that excludes some features, as does
GCC, and ISO C++ has a "Super FAQ" that Stroustrup is involved with
and which addresses this point directly[1].

It seems to work for people.  I admit that groff's in a weird position.
_Most_ of it appears to have solidified around "ARM C++", years before
ISO C++98, and this seems less a product of conscious restraint than a
reflection of what was available.

Because few people are hacking on groff, I'd like to retain what
accessibility it has to C programmers, and not go too nuts with C++
features like templates and (later) lambdas.

> 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.

Fair, although as far as I can tell practically all of groff's casts are
static casts.

> > 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.

I've gotten rid of `a_delete`[2] and its significantly less used sibling
`ad_delete`[3].  Now these parts of the code are at least not
inscrutable to C and C++ programmers alike.

Nobody else has said much, so I guess people are okay with a gradual
abandonment of pre-ISO C++98 compilers.  libgroff, libdriver, and libbib
have me wavering on my proposed boycott of exceptions.  I really really
hate libraries that talk to stderr instead of returning information in
some kind of error type.  All 3 of these libraries do, garrulously.

Regards,
Branden

[1] https://isocpp.org/wiki/faq/coding-standards#coding-std-wars
[2] 
https://git.savannah.gnu.org/cgit/groff.git/commit/?id=61d2307000c457db0604a7833e29ca4ad15884f7
[3] 
https://git.savannah.gnu.org/cgit/groff.git/commit/?id=f078d60b9e76817e4c36ce4788010bb0bfc195ed

signature.asc
Description: PGP signature