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