float result on cint(udt cast

[dafhi]

bug?

Code: Select all

type mytype
  declare operator cast as single
  dim as long dummy
end type

operator mytype.cast as single
  return rnd
end operator


dim as mytype   my_t

for i as long = 1 to 9
? cint(my_t)
next

[exagonx]

bug?

Code: Select all

type mytype
  declare operator cast as single
  dim as long dummy
end type

operator mytype.cast as single
  return rnd
end operator


dim as mytype   my_t

for i as long = 1 to 9
? cint(my_t)
next

This is what appair

Code: Select all

 0.3300996
 0.3290385
 0.5324828
 0.759945
 0.6424803
 0.6527108
 0.2956116
 0.9701146
 0.9696021

I dont know what you want do but its no bug

FreeBASIC 1.09 (on Windows 10 64 Bit)

[fxm]

Indeed, in this case cint is passing which is a bug in my opinion:

Code: Select all

type mytype
  declare operator cast as single
  dim as long dummy
end type

operator mytype.cast as single
  dim as double d = rnd
  ? cast(single, d),
  return d
end operator


dim as mytype   my_t

for i as long = 1 to 9
? cint(my_t)
next

It should either very smartly return an integer, or return an error if the automatic conversion by cast is not accepted (which I think should be the normal case since the cint keyword parameter is not declared with one precisely typed parameter):

A workaround for now is to explicit the conversion:

Code: Select all

type mytype
  declare operator cast as single
  dim as long dummy
end type

operator mytype.cast as single
  return rnd
end operator


dim as mytype   my_t

for i as long = 1 to 9
? cint(cast(single,my_t))
next

[fxm]

In case of casting to string when overloading the cast operator, an error is well provided for the automatic (non explicit) conversion:

Code: Select all

type mytype
  declare operator cast as string
  dim as long dummy
end type

operator mytype.cast as string
  return str(2*rnd)
end operator


dim as mytype   my_t

for i as long = 1 to 9
? cint(my_t)  '' NOK
'? cint(cast(string, my_t))  '' OK
next

• C:\...\FBIde0.4.6r4_fbc1.10.0\FBIDETEMP.bas(14) error 20: Type mismatch, before ')' in '? cint(my_t)'

[exagonx]

In case of conversion to string by overloading the cast operator, an error is well provided for the automatic (non explicit) conversion:

Code: Select all

type mytype
  declare operator cast as string
  dim as long dummy
end type

operator mytype.cast as string
  return str(2*rnd)
end operator


dim as mytype   my_t

for i as long = 1 to 9
? cint(my_t)  '' NOK
'? cint(cast(string, my_t))  '' OK
next

• C:\...\FBIde0.4.6r4_fbc1.10.0\FBIDETEMP.bas(14) error 20: Type mismatch, before ')' in '? cint(my_t)'

No it is not a BUG, Print (?) Shows what is specified and CINT () even if it does the conversion is ignored by PRINT, to force the display of the converted content it is necessary to keep the data in a variable of the requested type.

Code: Select all

dim as mytype   my_t
dim as integer x 


for i as long = 1 to 9

x = cint(my_t)

print x
next

[fxm]

No it is not a BUG, Print (?) Shows what is specified and CINT () even if it does the conversion is ignored by PRINT, to force the display of the converted content it is necessary to keep the data in a variable of the requested type.

I do not agree.
cint is declared to always return an integer.

By adding 'dim as integer x:x=.....', you add a final implicit conversion to the closest integer.

Same bug (IMHO) for all conversion keywords to integral types and floating point types, from an overloaded cast operator member applying on a numeric type.

[exagonx]

No it is not a BUG, Print (?) Shows what is specified and CINT () even if it does the conversion is ignored by PRINT, to force the display of the converted content it is necessary to keep the data in a variable of the requested type.

I do not agree.
cint is declared to always return an integer.

By adding 'dim as integer x:x=.....', you add a final implicit conversion to the closest integer.

Same bug (IMHO) for all conversion keywords to integral types and floating point types, from an overloaded cast operator member applying on a numeric type.

Well then we have to see if it's a known bug or if we need to report it.

@fxm Forgive my ignorance I was convinced it should work like this

[fxm]

As usual, I am waiting for CoderJeff's first feedback before filling in a bug report.

[dafhi]

oh great im not crazy (late reply sry .. OS issue)
my udt borrowed from is 'multi-instance' RNG with an int output

[fxm]

As usual, I am waiting for CoderJeff's first feedback before filling in a bug report.

Jeff, probably a bug (see above):
CINT (and other conversion keywords) fails (no conversion) when its argument comes from an implicit overloaded cast operator member returning a numeric type

[dafhi]

i'll log it on sf

[fxm]

i'll log it on sf

Thanks for your bug report:
#952 CINT (and other conversion keywords) fails

[coderJeff]

This is an interesting one because it is both a bug and possible a missing feature - depending on how strict the rules should be.

The bug is that CINT(UDT) goes and checks to see if UDT has an OPERATOR CAST that CINT can use, but then fails to convert to actually to the conversion to INTEGER.

A possible bug is if CINT(UDT) should be allowed to be a reduction of CINT(CSNG(UDT)) when the UDT does not have an operator cast() as integer defined? And if it that is allowed then should CAST(INTEGER, UDT) also be allowed to be a reduction of CAST(INTEGER, CAST( SINGLE, UDT ) )?

Maybe first step is to at least error out on missing casting operators in the UDT. And once that's working can be more relaxed about conversions.

For example, if the UDT has OPERATOR CAST for SINGLE and BYTE, but code calls CINT(UDT) it doesn't make much sense to me to find a closest match and return an INTEGER without complaint.