[Alex, this starting to meander afield from man page issues] At 2021-08-13T14:30:42+0200, Ingo Schwarze wrote: > Hi Branden, > > G. Branden Robinson wrote on Wed, Aug 11, 2021 at 12:58:31AM +1000: > > > (Did I digress some?) > > To digress even more: combining the enigmatic character of TeX error > reporting with the verbosity of C++ error reporting would get you > to the Mariana Trench of usability.
I'm grateful that the groff codebase is written in such an early dialect of C++ that it is (almost) innocent of templates. I've taken a fresh stab at Stroustrup's Third Edition recently because I've long wanted to articulate explicitly, somewhere on the record, just exactly _what_ C++ the code base uses. After 20+ years, C++98 seems safer than the chaotic mess that preceded it, but there's a long list of ISO C++98 features groff _doesn't_ use and which I'm not really anxious to add to it. It doesn't use templates, generics, namespaces, or exceptions. In fact, it doesn't even use the Standard C++ Library much. src/roff/troff/charinfo.h: std::vector<std::pair<int, int> > ranges; src/roff/troff/charinfo.h: std::vector<charinfo *> nested_classes; src/roff/troff/charinfo.h: ranges.push_back(std::pair<int, int>(c, c)); src/roff/troff/charinfo.h: ranges.push_back(std::pair<int, int>(lo, hi)); src/roff/troff/input.cpp: std::vector<std::pair<int, int> >::const_iterator ranges_iter; src/roff/troff/input.cpp: std::vector<charinfo *>::const_iterator nested_iter; ...though even if we got rid of the above, groff code would still link with libstdc++ for the runtime support. I am also skeptical that groff has much need for standard C++'s extended cast operators. 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. groff may be one of the better surviving examples of production code in the world that manifests the "C with Classes" concept in a fairly pure form. I aim to keep it that way, cherry picking only a few things from ISO C++98 that I like because they seem to help with code clarity. 1. The `bool` type; I've already started migrating the code to this. It's no hurdle at all for any C person familiar with C99. 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. So if I understand this issue, we can move all uses of "a_delete", which looks cryptic as hell both to C programmers and to a growing number of younger C++ programmers, to delete[]. I haven't done anything about this yet and won't until I'm certain I understand the issue. Stroustrup wrote a book on the development history of C++ in the '80s and '90s, but I either never acquired a copy or managed not to move it overseas with me. (It was on my to-read list along with hundreds of other books.) While it might be possible to find a calendar date (or geriatric compiler release) manifesting the groff subset of C++ (prior to my boolification efforts), ISO C++98 is something a lot more people know to how to find, code to, and get their compilers to enforce as a dialect. > As an additional data point, the mandoc implementation of man(1) > neither supports the equivalent of troff -d name=string nor man.local > and has no intention to do so in the future. Okay. As discussed earlier, you don't need an MB string anyway, since your parser knows everything it needs to to construct hyperlinks. Regards, Branden
signature.asc
Description: PGP signature
