Benoît Minisini ha scritto:
>> Benoît Minisini ha scritto:
>>
>>>> Hi!
>>>> There's minor bug.
>>>> Overflow with concatenate operator causes wrong error message.
>>>> You can reproduce the bug with this code:
>>>>
>>>> Dim ii As Integer
>>>> Dim jj As Integer
>>>>
>>>> For ii = 9 To 0 Step -1
>>>> jj&= ii<--- Wanted Integer got String instead.
>>>> Next
>>>>
>>>> Gambas 3 rev 2879 @ Ubuntu 9.10 64bit
>>>>
>>>> Jussi
>>>>
>>> I'd like to know what you expected exactly from that code, and what you
>>> think the error message should be!
>>>
>>> For information, the previous code is equivalent to:
>>>
>>> Dim ii As Integer
>>> Dim jj As Integer
>>>
>>> For ii = 9 To 0 Step -1
>>>
>>> jj = CInt(CStr(jj)& CStr(ii))
>>>
>>> Next
>>>
>>> The error message comes from CInt(). When its argument cannot be
>>> converted to an integer, it just says that there is a type mismatch (you
>>> forgot to tell that) and that its argument is not an integer.
>>>
>> I think that Jussi is right. Even the form you are using shows that the
>> "&" operator is used with an integer to the left, and so, the "&" is
>> meaningless. This is even more true with the C-style operator "&="
>> which, by definition, must not cast the operand to the left.
>>
>> In other words, I would say that automatic type conversion must be
>> performed only when reading values, and never when writing.
>>
>> Regards,
>> Doriano
>>
>>
>
> I admit that the error message is misleading. It is a generic error message
> raised by the internal interpreter conversion that converts anything to
> anything.
>
> I could have made more detailed error messages, but:
>
> - They are many many possible fail cases, so many many possible error
> messages, and I'm not sure I can guess them all.
>
> - When you convert something, you usually just want the conversion to
> succeed.
> In the few cases you want to know exactly why the conversion has failed, you
> can do the analyze by yourself.
>
> And for your remark about casting: why not converting when writing? Do you
> want the interpreter to raise an error instead? As in both cases you have to
> check the datatype you are processing, and that usually what you want is
> automatic conversion (otherwise, why using a string operator like '&' with
> integer arguments?), I decided to automatically convert datatypes as much as
> possible.
>
The problem is not very clear to me, but the following should be right:
gambas uses operators to cast its operands; if it was not so, then why
use "&" instead "+" to concatenate strings? But, when you use notations
like "+=", you have a variable on the left (an L-Value), not a value you
can cast... now, if the user writes something that can not work, like:
sString$ /= 3
the compiler should detect this. As Jussi says, this is a minor issue,
because even if the compiler does not notice, the interpreter will - as
soon the user checks the program. But this kind of check would be
responsibility of the compiler, not the interpreter.
About the "why not converting while writing"... it could be a good idea,
but "sString$ /= 3" what should do? Probably take the integer value
stored in sString$, divide by three, convert again in string, and store
the result back in sString$... but then why the code from Jussi raises
an error? Shouldn't it work instead?
Regards,
Doriano
------------------------------------------------------------------------------
_______________________________________________
Gambas-user mailing list
Gambas-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gambas-user
