Compile problem ov.cc of octave-3.1.51 on cygwin

[Jaroslav Hajek]

On Tue, Jul 29, 2008 at 10:56 PM, John W. Eaton <jwe at bevo.che.wisc.edu> wrote:
> On 29-Jul-2008, Jaroslav Hajek wrote:
>
> | On Tue, Jul 29, 2008 at 10:10 AM, Tatsuro MATSUOKA
> | <tmacchant at yahoo.co.jp> wrote:
> | > Hello Jaroslav Hajek
> | >
> | > With your patch, ov.cc complie problem ov.cc is resolved for cygwin.
> | >
> |
> | Good. John, can you apply this?
>
> Did you see my earlier reply?
>
> https://www.cae.wisc.edu/pipermail/bug-octave/2008-July/006394.html
>
> I asked whether there should maybe be at least a warning for values
> that are out of range.
>
> jwe
>

Sorry, I attributed the question to my suggestion that octave_int<T>
should be convertible to default int. The attached patch adds a
safe_conversion method to octave_int<T> and uses it in
convert_to_int_array. Is this what you meant?
However, caling, for instance, int8_array_value () on an octave_value
object containing a 32-bit int array does not gripe either. Perhaps we
could make the octave_int<T>:: octave_int(const octave_int<U>&)
constructor gripe if data need to be truncated.
In this way, the octave_int<> types would act as "conversion-safe
integers" contrary to the normal, unsafe integers. I think, however,
that a mechanism to avoid multiple gripes from loops would be needed
in such case.

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: octintexc.diff
Type: text/x-patch
Size: 3056 bytes
Desc: not available
Url : https://www.cae.wisc.edu/pipermail/bug-octave/attachments/20080730/bc8811c8/attachment.bin