On 02/14/2018 09:47 PM, Manuel López-Ibáñez wrote: > On 14 Feb 2018 8:16 pm, "Pedro Alves" <pal...@redhat.com > <mailto:pal...@redhat.com>> wrote: > > Instead of a class that has to have a constructor for every type > you want to pass as plural selector to the _n functions, which > increases coupling, I'd suggest using a conversion function, and > overload that. I.e., something like, in the core diagnostics code: > > static inline unsigned HOST_WIDE_INT > as_plural_form (unsigned HOST_WIDE_INT val) > { > return val; > } > > /* In some tree-diagnostics header. */ > > static inline unsigned HOST_WIDE_INT > as_plural_form (tree t) > { > // extract & return a HWI > } > > /* In some whatever-other-type-diagnostics header. */ > > static inline unsigned HOST_WIDE_INT > as_plural_form (whatever_other_type v) > { > // like above > } > > and then you call error_n and other similar functions like this: > > error_n (loc, u, "%u thing", "%u things", u); > error_n (loc, as_plural_form (u), "%u thing", "%u things", u); > error_n (loc, as_plural_form (t), "%E thing", "%E things", t); > error_n (loc, as_plural_form (i), "%wu thing", "%wu things", i); > > This is similar in spirit to std::to_string, etc. > > > If that's desired, why not simply have GCC::to_uhwi() ? It would likely be > useful in other contexts.
Because of types that (e.g. wide_int specializations) that can store values larger than what fit in uhwi. GCC::to_uhwi's semantics for that aren't clear -- could saturate, could unsigned wrap, could throw/abort/assert, could be undefined. as_plural_form has clear semantics -- it'd return a value that does the right thing for ngettext's N parameter. I.e., it'd do the "n % 1000000 + 1000000" operation as a wide_int still, and before converting/cast the result to uhwi. Thanks, Pedro Alves
