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