Boost logo

Boost :

From: Daryle Walker (darylew_at_[hidden])
Date: 2001-08-26 00:21:29


on 8/24/01 11:46 AM, Fernando Cacciola at fcacciola_at_[hidden] wrote:

> ----- Original Message -----
> From: <helmut.zeisel_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Friday, August 24, 2001 4:38 AM
> Subject: [boost] Re: Unlimited integer: conversion to built-in int?
>
>
>> --- In boost_at_y..., Jens Maurer <Jens.Maurer_at_g...> wrote:
>>> helmut.zeisel_at_a... wrote:
>>>> A user of my big_int implementation asked me if I could add implicit
>>>> conversion to less precise integral types.
>>>
>>> No.
>>>
>>
>> I agree.
>>
>> In the meanwhile I realized that he actually needs a conversion to bool,
>> which is false for zero and true for non-zero,
>>
>> i.e., he wants to write code like
>>
>> unlimited n;
>> ...
>> while(n) {...}
>>
>> This sounds reasonable to me.
>
> Not to me. An integer number doesn't have, IMHO, a generally defined mapping
> to true/false. When we didn't have a bool type, we used to rely on the fact
> that the boolean expression (n) evaluated as (n!=0), therefore we get used to
> write (n) ,(!n) instead of (n!=0),(n==0). I think that such a shortcut is
> appropriate only for objects with a well defined true/false mapping, such as
> pointers, but not for true numbers (numeric values having mathematical
> meaning).
>
> For example, chances are that the above predicate should have been (n>0)
> instead of (n!=0). Alternatively, writing explicitly (n!=0) can help to make
> sure that the loop body must reach that condition properly (such as
> decrement/increment one by one only)

You need a Boolean conversion if the test variable is declared in the "if"
(or "while") statement. I used this trick in the "int_read.zip" package I
just uploaded.

// "integer_entry" has a conversion to "void const *"
if ( integer_entry ie = read_integer(cin) )
{
    //...
}

Of course, this trick may be a shortcut to a bad idea....

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk