Re: Comments on lexical_cast

From: Daryle Walker (darylew_at_[hidden])
Date: 2000-11-09 17:36:55

on 11/8/00 4:16 PM, Kevlin Henney at kevlin_at_[hidden] wrote:

> In message <B62F1B92.3B0%darylew_at_[hidden]>, Daryle Walker <darylew_at_[hidden]>
> writes
>> on 11/7/00 8:44 PM, Kevlin Henney at kevlin_at_[hidden] wrote:
>>> My concern with this is that there are too many special cases, a potentially
>>> unbounded list. However, I think this may be a suitable approach for
>>> something that Dave Abrahams mentioned in passing at the Toronto mtg, and is
>>> mentioned briefly in the future directions section of the lexical_cast
>>> documentation: an interpret_cast that makes appropriate dispatch decisions
>>> (eg lexical_cast vs numeric_cast) and provides appropriate specialisations
>>> (as you have outlined).
>> 
>> Why would these cases by a potentially unbounded list?  The four special
>> cases cover all scenarios where at least one of the types is a basic_string
>> type.  When a std::basic_string<> type is involved, you probably don't want
>> the force the use of the std::string for the implementation, since the
>> former has the same operations as latter, and using the former is more
>> direct.
> 
> What I meant by unbounded list, is why restrict ourselves to just
> std::basic_string? I'm inclined to think that lexical_cast should do
> what it does as directly and consistently as possible, and leave the
> specialisations to something else.

I'm restricting the specializations to lexical_cast's that use
std::basic_string because, as far as I know, std::basic_string's of
different types aren't made to work together.  This means that problems will
ensue when trying to work the std::string-based std::stringstream with a
different std::basic_string type.  When only one of the external types is a
std::basic_string, we can get around the problem by using the
std::basic_stringstream with the same CharType and TraitsType as the given
std::basic_string.  We could use other stategies when both external types
are from the std::basic_string family.  Or we can punt the entire issue and
declare that using std::basic_string types besides std::string are
undefined.

One question to help answer this problem: what happens when I print a
std::basic_string<Ch1, Tr1> via a std::basic_ostream<Ch2, Tr2>?  How are the
differing character types and/or trait strategies resolved?

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com