Hi Joseph, On Thu, Aug 08, 2024 at 05:31:05PM GMT, Joseph Myers wrote: > On Thu, 8 Aug 2024, Alejandro Colomar wrote: > > > How about having __lengthof__ behave like sizeof, but deprecate it in > > sizeof too? > > Deprecation would be a matter for WG14.
Yep; I wouldn't add it to -Wall unless WG14 decides to deprecate it first. But if it does, that could be the path. For lengthof, I think keeping it like sizeof would be the simplest, as an implementer. And users will probably not care too much. And if WG14 decides to deprecate it from sizeof, they can also deprecate it from lengthof at the same time. > I think the code base (code on the host is generally in C++) should be > readable to people who know C++ (C++11 is the documented requirement for > building GCC - we're very conservative about adopting new language > versions, to facilitate bootstrapping on a wide range of systems) as it > is, not a playground for trying out new language features. We have enough > GCC-specific versions of standard features as it is (e.g. the GCC-specific > vectors designed to interoperate with GCC's garbage collection), using a > new feature that doesn't add expressivity and isn't in any standard C++ > version doesn't seem like a good idea to me. > > Actual bugs should of course be fixed. But certainly standard features > are preferable to something specific to GCC, and existing macros in GCC > such as ARRAY_SIZE that people are at least familiar with are preferable > to introducing a new language feature. ARRAY_SIZE() is very rarely used. From what I've seen, most of the existing code uses the raw sizeof division, and there's a non-negligible amount of typos in those. I suggest that someone at least converts most or all calls to ARRAY_SIZE(), so that it can later easily be changed to lengthof(). I can provide my patch as a draft, so that it's just adding some include and s/__lengthof__/ARRAY_SIZE/, plus some whitespace and parens fixes. > > *If* the feature were adopted into C++26, we could then consider if > existing macros should be renamed to look more like the future language > feature. > > Target code is at least always compiled with the same version of GCC, but > it still shouldn't be a playground for new language features; that doesn't > help readability, backporting patches to versions without the features, > etc. It will serve me as a huge test suite anyway; so it's worth it even if just for myself. And it will uncover bugs. :) Thanks! Have a lovely day! Alex -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
