lmi
[Top][All Lists]
Advanced

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

Re: [lmi] testing e_yes_or_no values


From: Greg Chicares
Subject: Re: [lmi] testing e_yes_or_no values
Date: Sat, 12 Jul 2008 19:43:23 +0000
User-agent: Thunderbird 2.0.0.14 (Windows/20080421)

On 2008-07-12 17:34Z, Vadim Zeitlin wrote:
> 
>  Are the values of e_yes_or_no type supposed to be handled as boolean
> values? IOW what is the correct way to test for their truthfulness?
[...]
>       e_yes_or_no value;
>       if ( value )
[...or...]
>       if ( value == e_yes )
[...]
>  I'm asking this because the current code in inputs.cpp does
> 
>       if ( value == true )
>               ...
> 
> and this just doesn't seem right to me (and incidentally provokes an MSVC
> warning about comparing int with bool).

I'm working on an urgent matter this weekend, so I can't examine
your patch today. But I thought I should point out that these files:
  inputillus.?pp
  inputs.?pp
  inputstatus.?pp
  xenum*.?pp [eight files]
  xrange*.?pp [five files]
will be deleted within one month at most. Everything they do is
already duplicated in these more modern, less defective files:
  input.?pp
  input_harmonization.cpp
  mc*.?pp
  tn*.?pp
We have two parallel "input" hierarchies, each with its own UDTs,
along with facilities to convert between the legacy version and
the modern one. We can't change one without changing the other and
testing them both; in practice, that means we hesitate to change
either. Soon, however, some important changes must be made, so it
is high time to get rid of the legacy version.

The modern version has fewer type-conversions operators--none,
actually, IIRC. I would say offhand that any implicit conversion
to bool is an error, and shouldn't be relied upon; whereas it is
always correct to compare an enum type to one of its enumerators.
So I'm happy to apply patches that are needed for msvc, even to
code that'll soon be deleted; but we should resist the urge to
refactor this legacy code in cases that all compilers accept.




reply via email to

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