Passing @ for OUT

[leon-ts]

Hi,

Faced a strange problem that I can't figure out. The transported application (from VO to XSharp) exited without any error message. This happened during certain actions in the application interface, so in debug mode I was able to find the exact place in the code where the application stopped working. It was a parameter passing through @, which is described in the function as OUT. After I replaced @ with OUT, the application started working without problems.

The history of the problem is such that in VO it was not possible to set the link type as OUT. VO only has REF. Therefore, after transporting the application from VO to XSharp, in those places in the code where, logically, there should be OUT instead of REF (only return value), I made such replacements. But in calls of such functions and methods I did not replace @ with OUT everywhere. The point is that the compiler does not issue any errors or warnings in this case. Therefore, I just did not see a few places where it was necessary to perform such a replacement.

Having decided to dig deeper into the problem, I wrote a small test:

Code: Select all

FUNCTION OutFunc(num AS INT, str OUT STRING) AS VOID
    str := num:ToString()
    RETURN

FUNCTION Start() AS VOID
    LOCAL str AS STRING
    OutFunc(1, @str)
    RETURN

But it worked fine without causing problems.

So I just have to ask the XSharp developers: @ for OUT might cause any problems? Or is this a valid statement?

Best regards,
Leonid

[Chris]

Hi Leonid,

The problem is that @ in VO is used for both taking the address of a variable and for passing variables by reference, while in .Net those are two completely different things. We have tried to support it in most cases (when you enable the /vo7 compiler option) for both REF and OUT, depending on the context, but it is not possible for it to work in all cases.

It always works when the code is strongly typed and the call is made early bound:

Code: Select all

CLASS Test
STATIC METHOD OutMethod(str OUT STRING) AS VOID
str := "modified"
END CLASS

FUNCTION Start() AS VOID
LOCAL str := "original" AS STRING
Test.OutMethod(@str)
? str // modified
str := "original"
Test.OutMethod(REF str)
? str // modified

For calling untyped methods, you need to use REF for passing values by reference. This is different to VO, but there is no way at all in this case to tell if @ means addressof or "by reference":

Code: Select all

CLASS Test
STATIC METHOD OutMethod(str) CLIPPER
str := "modified"
RETURN NIL
END CLASS

FUNCTION Start() AS VOID
LOCAL str := "original" AS STRING
Test.OutMethod(@str)
? str // original
Test.OutMethod(REF str)
? str // modified

[leon-ts]

Hi Chris,

I got a misunderstanding only about the linking @ with OUT. In this regard, I have a proposal. As you know, there is no OUT in VO. So maybe XSharp doesn't do any compatibility in this case (when the parameter is required as OUT, but a value is passed to it with the @ indication)? After all, such a code from VO cannot come in any way. In this case, I propose to issue a compilation error. After all, otherwise, some strange situations may arise, as I described in the first message in this thread.

Best regards,
Leonid

[leon-ts]

Addition:

Not only that, I also found that OUT allows NULL to be passed into it (albeit with a warning). At the same time, for OUT there are quite legal ones: OUT NULL and VAR _. So maybe it would be correct to disable it (NULL for OUT) and also throw an error (not a warning) during the compilation of such code?

[Chris]

Hi Leonid,

Can you please post the exact code, both the calling code and the called method? It makes a lot of difference depending on if it is early or late bound and typed or untyped.

[leon-ts]

Chris,

The problematic code is gone. As I wrote initially, when I discovered the problem, I fixed it, and later I further modified the transported code from VO-style closer to NET-style. And I also mentioned that with a simple example I was not able to reproduce the problem. In fact, I ran into this code two weeks ago, but I thought it was my mistake (@ instead of OUT). And yesterday I saw in another code that @ with OUT works without problems. Therefore, recalling the previous problem that arose two weeks ago, I decided to clarify on the forum whether this is the correct situation.

Best regards,
Leonid

[leon-ts]

Addition:

But it was definitely typed code. I don't use REF with untyped code even in VO.

[Chris]

Hi Leonid,

OK, thnaks! Normally I think OUT or REF in this case should not make a difference, but maybe there was something in this code that exposed a problem in X# that we are not aware about. Anyway, if you come across something like this again, please let us know!