lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] sequence input editor -- how to get accepted keywords


From: Greg Chicares
Subject: Re: [lmi] sequence input editor -- how to get accepted keywords
Date: Thu, 01 Jul 2010 17:48:11 +0000
User-agent: Thunderbird 2.0.0.24 (Windows/20100228)

On 2010-06-27 11:35Z, Greg Chicares wrote:
> On 2010-06-27 11:02Z, Vaclav Slavik wrote:
>> On Sun, 2010-06-27 at 08:15 +0000, Greg Chicares wrote:
[...]
> in 'datum_string.hpp' and remove the value_cast specialization for
> every class that derives from it, directly or indirectly. Then
> value_cast<> just does the right thing (by invoking stream_cast<>).

Except that it doesn't DTRT for empty strings, and input sequences
can be empty. For example, Input::PremiumHistory represents a vector
with one element for each year that has passed since the policy was
issued; on the date of issue, it is therefore empty, and its input-
sequence string must be an empty string. As 'stream_cast.hpp' says:

///                                    [...] It should be pointed out
/// that conversion from an empty string to another string fails even
/// with the current implementation unless both strings are of exact
/// type std::string (but it works with value_cast).

and here we'd be converting between std::string and the string-like
class datum_string.

[The problem, in this simplified code:
  std::stringstream interpreter;
  interpreter << from;
  interpreter >> result;
  if(!interpreter) throw "Error";
is that an empty 'from' writes zero characters, and that causes the
extractor to fail according to C++2003 21.3.7.9/2a:
  "If the function extracts no characters,
  it calls is.setstate(ios::failbit)"]

It'd be convenient if a specialization like
  template<> Base value_cast<Base,std::string>
could somehow be inherited by derived classes, but it cannot. There are
plenty of options:

 - Specialize value_cast<> for every derived class, as you did. Even if
   it becomes verbose and tedious as derived classes proliferate, it's
   always easy, safe, and effective.

 - Make stream_cast handle empty strings "correctly". I don't see a way
   that's both easy and safe.

 - Apply SFINAE techniques to value_cast<> or to one of its internal
   helpers. It's not hard to write a function template that converts
     std::string <-> {some base class and all its derived classes}
   only. But I don't know a simple and tasteful way to make the special
   cases fail substitution in the default implementation without giving
   it knowledge of every special case. This probably leads to a complete
   redesign of value_cast<>, which is likely to be risky and difficult.

 - Make the new datum_sequence class interconvertible with std::string.
   That would require a conversion function
     operator std::string const&() const
   and a (non-explicit) converting ctor; then value_cast<> would DTRT
   without any modification. But implicit conversions cause surprising
   problems and are much better avoided.

So I think your original approach is what we should follow now.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]