At 2023-08-04T03:00:10+0200, Alejandro Colomar wrote: > * src/roff/troff/env.cpp (lengthof): Add macro to calculate the number > of elements in an array. It's named after the proposal to ISO C, > _Lengthof(), which wasn't accepted for C23, but hopefully will be > added in a future revision. [...] > I added it there because I didn't find a "common utilities" header > file. Please suggest a better place.
As I understand it, it is not idiomatic C++ to rely on the preprocessor any more than is necessary--and that means, again AIUI, to interpolate the text of header files and interface with C code. Yes, groff does use the preprocessor intensely in a couple of places. https://git.savannah.gnu.org/cgit/groff.git/tree/src/include/itable.h?h=1.23.0 https://git.savannah.gnu.org/cgit/groff.git/tree/src/include/ptable.h?h=1.23.0 That is because C++ didn't have templates, or they weren't yet mature[1] when James Clark wrote this stuff. And I recognize that "cultivation of robust and flourishing macros" _is_ (or can be) idiomatic C, as Ben Klemens champions. groff is stuck in a very hard place. People have lots of excuses to not hack on it. 1. From C programmers: "Eww! It's in C++!" 2. From C++ programmers (1): "Eww! It's not in C++23 already! How can you not be using all the latest features? What a bunch of losers!" 3. From people generally: "Why care about groff? Or text formatting? I want my Markdown documents in angry fruit salad colors on my JavaScript terminal emulator!" 4. From C++ programmers (2): "Wow, this pre-standard dialect is about as mind-twisting to current practicioners as an exhibit of pre-Typesetter C[1] (attached) is to C programmers." I don't think coders in the first three categories can ever be won over short of a ground-up rewrite. That _would_ be a cool project, and it's one Ralph Corderoy tried to get me to do (possibly so I'd stop posting to this mailing list). But I kind of like working on code that people other than me are actually using. At 2023-08-04T03:00:12+0200, Alejandro Colomar wrote: > * src/roff/troff/env.cpp (is_family_valid): The old code was > eyeball-bleeding. This cuts 6 lines to 3, and each of them is > significantly simpler to read. Remove the comments of how it could > be improved using modern C++, as I don't think it would improve much > vs this C implementation. [...] > I need a new pair of eyeballs. They bleeded so much! Yeah, who's responsible for this crap? 39ffa368dc src/roff/troff/env.cpp (G. Branden Robinson 2023-05-25 05:35:25 -0500 1259) bool is_family_valid(const char *fam) 39ffa368dc src/roff/troff/env.cpp (G. Branden Robinson 2023-05-25 05:35:25 -0500 1260) { 39ffa368dc src/roff/troff/env.cpp (G. Branden Robinson 2023-05-25 05:35:25 -0500 1261) // std::vector<const char *> styles{"R", "I", "B", "BI"}; // C++11 39ffa368dc src/roff/troff/env.cpp (G. Branden Robinson 2023-05-25 05:35:25 -0500 1262) const size_t nstyles = 4; 39ffa368dc src/roff/troff/env.cpp (G. Branden Robinson 2023-05-25 05:35:25 -0500 1263) const char *st[nstyles] = { "R", "I", "B", "BI" }; 39ffa368dc src/roff/troff/env.cpp (G. Branden Robinson 2023-05-25 05:35:25 -0500 1264) std::vector<const char *> styles(st, (st + nstyles)); 39ffa368dc src/roff/troff/env.cpp (G. Branden Robinson 2023-05-25 05:35:25 -0500 1265) // for (auto style : styles) // C++11 39ffa368dc src/roff/troff/env.cpp (G. Branden Robinson 2023-05-25 05:35:25 -0500 1266) std::vector<const char *>::iterator style; 39ffa368dc src/roff/troff/env.cpp (G. Branden Robinson 2023-05-25 05:35:25 -0500 1267) for (style = styles.begin(); style != styles.end(); style++) 39ffa368dc src/roff/troff/env.cpp (G. Branden Robinson 2023-05-25 05:35:25 -0500 1268) if (!check_font(fam, *style)) 39ffa368dc src/roff/troff/env.cpp (G. Branden Robinson 2023-05-25 05:35:25 -0500 1269) return false; 39ffa368dc src/roff/troff/env.cpp (G. Branden Robinson 2023-05-25 05:35:25 -0500 1270) return true; 39ffa368dc src/roff/troff/env.cpp (G. Branden Robinson 2023-05-25 05:35:25 -0500 1271) } This is a relatively new function, and all my fault. I wrote it because validation of font families wasn't being done previously. https://savannah.gnu.org/bugs/index.php?64155 In my defense, I seem to remember modeling it on an example in Lippman's _Essential C++_, which documents C++98. I figured he was an expert. Bad choice? Lippman never updated that book for any later version of C++, and I don't know why. Maybe everybody else decided his code was horrible. Or maybe he got off the C++ train before Scott Meyers did.[2] But I put those C++11 comments in there because the C++98 way of doing things seemed incredibly gross, and I had trouble believing that C++ programmers subjected themselves to it. They did, and they didn't like it, but it took 13 years to get a remedy because, by God, _someone_ had to have "concepts" in the next version of language.[3] Therefore--please take another crack at it without using the preprocessor, if you'd like. Regards, Branden [1] "Still aren't!" <drum fill> [2] https://scottmeyers.blogspot.com/2015/12/good-to-go.html [3] And failed to do so. But I'm sure it pitches brilliantly in any conference room. All you have to do is stand up in front of a whiteboard, put your elbows to your waist while extending your forearms at a 45 degree angle in the plane parallel to the floor, with palms facing up, gravely intone the word "concepts", and take your seat. Boom! Instant buy-in! Steve Jobs himself could not have sold it better.
signature.asc
Description: PGP signature
