xsharp.eu

Robert,

I am very sorry, but it seems to me that you did not read my previous posts )
I wrote there that I edited the code in such a way so that it works in XSharp. And you again give me an example of how to get around this problem )
The screenshot is in the attachment.

Best regards,
Leonid

Hi Leoind.

A couple more quick answers:

1. This is a bug, RETURN [""] should be accepted, will log this, thanks. This already works
LOCAL c AS STRING
c := [""]
RETURN c

3. You can also write this easily with using _Chr(), but specifying the string as a literal:

FUNC tOrdScope(nScope AS DWORD, xVal := e"x0x0" AS USUAL) AS USUAL PASCAL


Will look into some more of your items a little later and will get back to you with more.

Leonid,
Sorry for the confusion. I DID read your post.

But you are not replying to my question:
VOSTRUCT is only in the product to interface with WIN32 API calls. The DATE type (which is actually the XSharp.__Date structure) has no meaning for Win32 API functions. So what are you using this for ?

And the other issue: dereferencing a typed pointer to another type is so "exotic" that we really do not want to allow it out of the box. The (easy) workaround was in my sample code.
This kind of code is normally only necessary when interfacing with WIN32 API code, and in .Net there are usually better and safer solutions for this.

VO was very forgiving, you could cast everything to everything else, such as casting an object to an int and back. We decided NOT to allow that in X# to prevent people from shooting in their own foot.

Robert

Robert,

As for the structures. In VO, structures (as far as I know) were intended not only for interacting with the Win32 API. In VO, I can choose both object-oriented programming and procedural programming. Therefore, the STRUCTURE language design allows me to create structures (typed memory areas) and exchange data using them, for example, transfer them as parameters to functions. An exception to the fields used in them are dynamic data types such as strings and objects, due to the dynamic nature of their addresses in memory (hello GC). Although, if desired, this problem could be resolved using RegisterKid.

By no means do I mind the limitations of VOSTRUCT in XSharp. It’s just that VO code is converted to this structure after xPorter works. Those. I kind of have no choice And it turns out that STRUCTURE is not fully compatible with VOSTRUCT. And I totally agree that using strings and objects in STRUCTURE, even in VO, is a bad idea. And I do not have such code. But the DATE type is completely different (in VO). They are very convenient to exchange in structures. Instead of passing a million parameters to a function, it’s more convenient to describe one structure, write fields in it, and pass only a pointer to this structure.

The same goes for SYMBOL. In VO, it is structurally a DWORD (interaction with atom table). And using SYMBOL in structures in VO is completely safe. This is also confirmed by the structures used in VO RDD. But in XSharp, as I understand it, SYMBOL has become a string?

Best regards,
Leonid

Chris,

Thank you so much for the tip:

Chris wrote: 3. You can also write this easily with using _Chr(), but specifying the string as a literal:
FUNC tOrdScope(nScope AS DWORD, xVal := e"x0x0" AS USUAL) AS USUAL PASCAL

I will use it!

Best regards,
Leonid

Leonid,

1) If you want to use structures in X# for procedural programming I advise to use the normal .Net structures and not VOSTRUCT. You can use all data types that you want in normal structures. So you could change them from the VOSTRUCT syntax to STRUCTURE if you want. Of course you would have to change MEMBER to PUBLIC and add an END STRUCTURE at the end.
The biggest difference is that VOSTRUCT is assumed to be a reference type. So AS <somevostruct> is actually a reference to a VOSTRUCT, where for STRUCTURE AS <somestruct> declares the structure.
For VOSTRUCT we have added the IS syntax to declare a structure on the stack, just like in VO.
Of course you can also use REF <Somestruct> or AS <SomeStruct> PTR to have a reference to a .Net structure.
If you use reflector to look at the generated IL for the VOSTRUCT type you will see that we are automatically converting
to and
to 2) To pass data around like what you describe you can easily use classes in .Net. There is very little overhead. And if you are only passing around 2 or 3 values you can use a .Net structure (see 1). Of course these will be passed by value, unless you explicitely pass them by reference your self.

3) In X# a symbol is still a DWORD, just like in VO. The DWORD is the index into a (global) table where the String that represents the symbol is stored. You can (explicitely) cast the Symbol to a DWORD and back to without problems. If course casting a "random" DWORD to a Symbol could result in an error if the value of the DWORD exceeds the length of the table with strings.
In fact we check for that and will return NULL_SYMBOL for invalid DWORD values.
See https://github.com/X-Sharp/XSharpPublic ... Symbol.prg for the code of the Symbol type (which is a .net structure by the way). The type has one value: There is an explicit converter from DWORD to SYMBOL and BACK: And yes there are also (implicit) converters from Symbol to String and back. I don't like these, but these were introduced in Vulcan so we had to add them as well.
Robert

Robert,

Many thanks for the helpful tips and info!

Best regards,
Leonid

Robert,

I’m examining the code (ILSpy) to understand how I can correctly rewrite the code in XSharp, where there were structures in VO, such as ERRINFO when working with RDD. And I came across this code in the WrapperRDD class:
Maybe this is a mistake?

Best regards,
Leonid

Leonid,

Thanks, that is indeed a mistake.
Fortunately the customer that has used this has overwritten the Open() method in his own subclass so this was never executed...

Robert

Leonid, there's no need to use ILSpy, you can read the X# code directly: https://github.com/X-Sharp/XSharpPublic ... p.Core/RDD