[boost] Re: Re: Re: Re: Numeric conversions lib comments

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-03-26 16:07:20

"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:004101c41369$2ca8cb90$1d00a8c0_at_pdimov2...
> Jonathan Turkanis wrote:
> >
> > However, if you accept that comparisons criteria are alway
contextual,
> > I think you must conclude that the comparison operators <, <=,
etc.
> > are completely useless. On the contrary, I like the ability to
have a
> > default comparison criteria that works a good deal of the time;
>
> Agree.
>
> > as long as it's provided, it should be customizable.
>
> Disagree. Your own logic doesn't support this conclusion: a default
> comparison works most of the time, therefore, it doesn't need to be
> customizable, because you could only customize it to _not work_ most
of the
> time.

Here's what I had in mind: for a particular application you might find
that 'most of the time' you need a non-standard comparison criterion.
It might make sense to let it be the default, so you can use the much
cleaner operator notation.

> And for the string case, the downside to encoding a comparison in
the type
> is that you'll now spend a lot of time converting strings (because
most
> libraries - correctly - accept an ordinary std::string, regardless
of what
> comparisons they might make underneath, or they'd expose
implementation
> details in the interface.)

You can expose the string as a typedef, to avoid bothering library
users with custom comparison policies. Most of the interoperability
concerns could be addressed by relaxing the requirement that
traits_type match extacly in basic_string member functions which take
basic_strings as arguments -- at least for those which don't involve
comparison.

> Nobody uses anything but std::string and std::wstring. ;-)

I've been waiting to meet the 'japan_char' I've read so much about;
still haven't seen it. ;-)

Jonathan