Hi Alex, At 2025-06-29T19:19:13+0200, Alejandro Colomar wrote: > On Sun, Jun 29, 2025 at 07:07:26PM +0200, Alejandro Colomar wrote: > > > > Here's a patch set for using the gnulib stdcountof-h module, which > > implements the countof() macro, which was standardized for C2y > > recently --together with the _Countof operator which it wraps-- > > (after a proposal of mine; plus a lengthy war for the name). > > Forgot to say: this patch set is a work-in-progress to see if you like > the idea. (I should have used RFC instead of PATCH.)
I'm on the positive side of neutral.
* You're right that sizeof() division is lame.
* We already have an in-tree solution.
HACKING:
* `std::size` is not available in C++98. Use the `array_length`
template function in src/include/lib.h instead of `sizeof` and
dividing. ...
* Migrating existing sizeof() users to array_length() would be a nice
gesture in the direction of consistency, and make it easier to
scriptably migrate to countof() later.
* A standard solution is better than carrying a custom one in the groff
tree. Our job is typography, and this is a long way from that.
* However this custom one is lightweight. The only reason I didn't
already migrate everything to array_length() already is that I
sometimes had problems doing so. I eventually learned what one of the
reasons was, and documented it.
HACKING:
... Types passed to template functions cannot be anonymous in
C++98; in other words, the "tag" of a `struct` or `enum` type must
not be empty.
* Probably better than all of the above, at least in our C++ code, is
migrating to STL containers with iterators. Close to 100% of the
instances of this sizeof() division stuff in the groff tree is simply
to implement the terminating condition in a `for` loop that walks an
array of OO objects.[1]
But that's a heavier lift and not on the near horizon.
At 2025-06-29T19:46:26+0200, Alejandro Colomar wrote:
> Hmmm, from there it seems like we're a couple of days away from the
> next [gnulib] stable branch. Nice! I'll try next week and resend.
I don't want to promise _when_ I'll bump groff to gnulib/stable-202507,
but, yeah, it'll happen.
It'll soon be 2 years since the groff 1.23 release. I'm moving as best
I can. I want to get 1.24.0.rc1 out there.
Regards,
Branden
[1] groff was initially written in the heyday of everyone devising their
own containers because the C++ standard library was even more anemic
than C's was. (Hell, in 1990, even dynamic shared objects were
novel. A lot of C and C++ developers were used to everything
getting statically linked. I seem to remember that some linkers
were so dumb that they didn't even bother to strip unneeded symbols
out of your executables. So a lot of basic conveniences were
derided as "bloat".) Trendy languages like Rust and Go have
rediscovered the joy of static linking, and we have tons more disk
space than we used to, so now every language environment plants a
million leftpad flowers.[2]
[2] https://en.wikipedia.org/wiki/Npm_left-pad_incident
And yes, that episode doesn't _directly_ follow from the
static/dynamic linking issue, but I think that _culturally_, these
phenomena are related. Developers are re-learning and
re-negotiating the boundaries of what a convenient utility library
is. I expect gnulib grapples with this sort of question constantly.
signature.asc
Description: PGP signature
