From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-11-21 12:39:57
From: "William E. Kempf" <wekempf_at_[hidden]>
>
> Peter Dimov said:
> > From: "William E. Kempf" <wekempf_at_[hidden]>
> >> In fact,
> >> in most cases they are user supplied, instead of implementation
> >> supplied.
> >
> > User supplied what() strings? In most cases?
>
> Every standard exception from logic_error or domain_error down are
> constructable only through a constructor that takes a string and sets the
> value to be returned by what(). (User exceptions derived from these are
> obviously open to not follow this lead.)
I see, ambiguous usage of "user". Let's rephrase: in most cases the what()
string is supplied by the throw point, not the catch point, right? I.e.
library authors decide what to return from what(), library users do not.
> > Yes, you hit the nail on the head. "Strict specification of what's
> > returned from what()" is indeed what is needed.
>
> To elaborate on what I meant, the solution I gave required only that
> what() return a unique value for which localized strings can be looked up,
> while Dave's suggestion requires a much more complex specification of what
> may be returned from what() (as in, specific formatting will be required
> so the lookup mechanism can extract the needed data for formatting).
Yes, I understand that. In both cases you need strict specification, either
to build the appropriate string table, or to interpret the what() string.
> >> The main problem I see with this approach is that any existing code
> >> that expects what() to return a human readable (albiet unlocalized)
> >> string will now be getting a string that's not easy to decipher.
> >
> > A string cannot be said to be human readable if it's not localized.
> > Would you consider a string in Bulgarian human-readable?
>
> Certainly, to a Bulgarian.
>
> But what was meant was that I'd prefer to leave what() as is, with
> non-localized but readable strings, and provide a seperate key() for use
> in retrieving a localized message.
I understood that, too. My point was that "non-localized but readable
strings" is meaningless, unless you define what "readable" means. Readable
to a Bulgarian? Readable to at least 26% of the audience? Readable to
whoever we consider important?
Please do understand that I'm just trying to provide some perspective here.
Of course I know what the intuitive meaning of "readable but non-localized"
is - English text. English-speaking countries have earned that right, WRT
computers. Still, an international standard should be, well, international.
There's also the additional problem that the current what(), if left as-is,
does not guarantee, and often does not produce, an useful readable string,
even if we accept the above "readability" definition.
>From a technical point of view, it's obviously easier to just leave what()
as is (i.e. of questionable utility outside of toy programs), introduce
another function, and get it right this time.