Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at