fbpx

To cast or not to cast

  • Wolfgang Riedmann
  • Wolfgang Riedmann's Avatar Topic Author
  • Offline
More
2 months 14 hours ago #1 by Wolfgang Riedmann
To cast or not to cast was created by Wolfgang Riedmann
Hi Robert,

I think a forum message is better suited to answer to your post.

I have done now a search in my largest VO project for all occurrences of _cast and found only 1.649 of them <g>.
Most of them are in the VO Class libraries code and in the bBrowser, and the others in code to enhances ListViews or interface to MAPI, and some of them adress the return value of PCALL().

Personally, I would mark all casts with usuals as errors, so we should look at them and correct the code.
IMHO it is better to fix code than to have some code that don't works and we don't know why.
Casts to typed values, and specially to value types are relatively safe. Casts to typed reference values are to check because in .NET they could give undesired (or wrong) results.

These are a few samples how _cast is used in my code:
MAPILogon( dword( _cast, HWND_DESKTOP ), null_ptr, null_ptr, 0, 0, @nSession )
sMAPI.pFreeBuffer    := GetProcAddress( hLib , PSZ( _CAST , "MAPIFreeBuffer" ) )
MemFree( PTR ( _CAST, pszCaption ) )
SendMessage( self:Handle(), CB_GETITEMHEIGHT, Word( _Cast, -1 ), 20 )
ListView_SetItem(hHandle, LONG(_CAST, strucItem))

Much of this code is very old, and often taken from other sources, but in VO applications it works for many years now.
Wolfgang

Please Log in or Create an account to join the conversation.

  • Wolfgang Riedmann
  • Wolfgang Riedmann's Avatar Topic Author
  • Offline
More
2 months 14 hours ago #2 by Wolfgang Riedmann
Replied by Wolfgang Riedmann on topic To cast or not to cast
Hi Robert,

another thing: casting to pointers in legacy 32 bit code may be ok, but will not be ok in a 64 bit world.

Therefore I would change the compiler behavior dependent on the compiler mode: ok for x86, compiler error for x64 or AnyCPU.

Wolfgang

Please Log in or Create an account to join the conversation.

More
2 months 10 hours ago #3 by Chris Pyrgas
Replied by Chris Pyrgas on topic To cast or not to cast
I like the idea of throwing an error on using _CAST with USUALs. But maybe not with integer numeric types (and LOGIC probably), because there's probably a lot of existing code that uses that and it is safe to use it in VO, so in order to make it easier to directly port code, I think it's better to allow it.

In any case, all <integer type>(_CAST, uUsual) conversions (because they are not really casts in .Net) do already work in X# in a VO compatible way, except for SHORTINT. I think it's better to make SHORTINT work, too, and report a warning about those conversions that they will not work in other platforms (although it is not very likely to run a VO ported app in a different platform :))

And maybe throw an error for any other type, like FLOAT, STRING etc.

XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

More
2 months 6 hours ago #4 by Karl-Heinz Rauscher
Replied by Karl-Heinz Rauscher on topic To cast or not to cast
I would vote for a warning if the compiler detects _cast problems, similar like he already does in this case:

PTR( _CAST , cText )

warning XS9068: The compiler generated an automatic conversion to PSZ. This may create a memory leak in your application. Please use String2Psz() to let the compiler manage the lifetime of the PSZ or use StringAlloc() and manage the lifetime of the PSZ yourself.

regards
Karl-Heinz

Please Log in or Create an account to join the conversation.

More
1 month 4 weeks ago #5 by Karl-Heinz Rauscher
Replied by Karl-Heinz Rauscher on topic To cast or not to cast
Inspired by this thread I´ve looked at the integer() function. I've noticed that Integer() returns negative numbers as soon the integer is greater than int32.maxvalue. But this happens also if such integers are assigned to usuals or floats.

All VO results are as expected:

LOCAL u AS USUAL
LOCAL f AS FLOAT

u := Integer ( 2147483647 + 1 )
f := Integer ( 2147483647 + 1 )
? u // 2147483648
? f // 2147483648
?
u := Integer ( 2147483647.00 + 1 )
f := Integer ( 2147483647.00 + 1 )
? u // 2147483648
? f // 2147483648
?
u := 2147483647 + 1
f := 2147483647 + 1
? u // 2147483648
? f // 2147483648
?
u := 2147483647.00 + 1
f := 2147483647.00 + 1
? u // 2147483648,00
? f // 2147483648,00
?

X# results:
LOCAL u AS USUAL                     
LOCAL f AS FLOAT
LOCAL iNum AS INT 

  iNum := 1  
  
  // 2147483647 == max int  
  
 
  u := integer ( 2147483647 + iNum ) //integer
  f := integer ( 2147483647 + iNum ) //integer
 
  ? u  // -2147483648   iNum = 1
  ? f  // -2147483648   iNum = 1
  ?
  
  u := integer ( 2147483647d + iNum )  // float
  f := integer ( 2147483647d + iNum )  // float
  
  ? u  // 2147483648   iNum = 1  ok
  ? f  // 2147483648   iNum = 1  ok
  ? 

   u := 2147483647 + iNum    //integer
   f := 2147483647 + iNum    //integer

   ? u  // -2147483648   iNum = 1
   ? f  // -2147483648   iNum = 1
   ?
   
   u := 2147483647d + iNum  // float
   f := 2147483647d + iNum  // float
   
   ? u  // 2147483648,00   iNum = 1   ok
   ? f  // 2147483648,00   iNum = 1   ok    
   ?

regards
Karl-Heinz

Please Log in or Create an account to join the conversation.

More
1 month 3 weeks ago #6 by Chris Pyrgas
Replied by Chris Pyrgas on topic To cast or not to cast
Hi Karl-Heinz,

Sorry for the delay and thanks for the report, problem confirmed and logged!

Does not seem related to the Integer() function, though, but it's a compiler problem treating the expression "2147483647 + 1" as an int (which overflows), instead of using a larger numeric type before assigning it to the USUAL or FLOAT var, Robert will look into it.

Chris

XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.