Hi,

i've pushed now the remaining parts of the AES/VDI library (and also a few other additions). Another few enhancements will be done soon, but the ObjectGEM library can already be compiled.

I just wanted to share what problems may occur when porting PurePascal code to FreePascal:

- the units are named differently, so for freepascal you also have to import the aes and vdi units, as needed. No big deal.

- Luckily, almost all the compiler switches that PurePascal uses (it only knows about the short directives) are named identical, and have the same meaning. Notable exception is the $Z switch, so have to watch out for this.

- both vdi libraries provide a vdi function that makes it possible to extend the interface in your application. However, in the implementation you can just call it with "vdi", while from an application you have to call it explicitly "vdi.vdi", because the unit has the same name.

- when constructing objects, ObjectGEM uses contructs like new(PGroupBox, init(...)
Such constructs are not supported by FreePascal, you have to assign the result to some variable (i think that is also an incompatibility to TurboPascal)

- in a few places i got some strange warnings. For example the code var tg,mo,jr: word;
tsetdate(((jr-1980) shl 9) or (mo shl 5) or tg);
Gives:
Hint: (4035) Mixing signed expressions and longwords gives a 64bit result

I have no idea why calculations with word (16bit) should give a 64bit result?

- ObjectGEM uses the type "integer" for all vdi/aes parameters. Since that might be some implementation specific size, i started to replace it in a few places by "smallint", and doing a "type smallint = integer;" because PurePascal does not know that type. That turned out to be not so a good idea: although the types are identical, using "smallint" in the interface part and "integer" in the implementation is happily accepted by FreePascal, but PurePascal complains about a mismatch.

- PurePascal does not seem to have a builtin unsigned 32bit integer type,so watch out when doing operations on longints, especially shifts.

Thorsten Otto via fpc-devel schrieb am
Do., 10. Feb. 2022, 13:00:

Assuming PGroupbox is declared as a pointer type to some object type it must either be

GroupBoxPtr := New(PGroupbox, init(...))

Or

New(GroupBoxPtr, init(...))

Anything else does not make sense.

Cause in the variant you mentioned where would the allocated memory be stored?

And yes, FPC is TP compatible here.

- in a few places i got some strange warnings. For example the code

As the m68k port is a 32-bit one all (intermediate) calculations will be done in the native width (which is 32-bit). And if you have a signed/unsigned conflict it will escalate to the next width (which is 64-bit).

As long as you don't use mode Delphi or mode ObjFPC "Integer" is an alias to "SmallInt". And as you don't need any Object Pascal functionality in those units you don't need to enable it.

And for users of the unit it's not relevant. They either need to use the correct type or the compiler will enforce the type conversion when calling functions anyway.

Regards,
Sven

CET Sven Barth wrote

Anything else does not make sense. Cause in the variant you mentioned where would the allocated memory be stored?

I'm not that familiar with ObjectGEM yet, but i think the allocated pointer is stored in some list in the base class.

And yes, FPC is TP compatible here.

Yes, seems so (have checked only the free version 5.5). But PurePascal accepts it.

Thorsten Otto via fpc-devel schrieb am
Do., 10. Feb. 2022, 15:47:

And how does one work with the created instance? How does one release it? Do you have an example for that?

Regards,
Sven

CET Sven Barth wrote

And how does one work with the created instance? How does one release it? Do you have an example for that?

Maybe some examples of ObjectGEM itself, like https://github.com/th-otto/ texel/tree/master/ogem/demo/zeit

I'm quite sure the buttons get properly destroyed when you destroy the dialog, but don't ask me where ;)

Hi,

Remember, this is for GUI stuff. In some cases the code actually uses the new return pointer, for example when you want to interact with the recently added GUI element, but sometimes you can just "fire and forget" it, like injecting an icon. In this case the constructor of the object adds it to some globally maintained object tree, so it's not lost or remain dangling. Then you can access it from there with various utility functions.

This is something quite specific, and I actually wonder if it's a corner case we don't handle or PurePascal's implementation is less restrictive.

Charlie

I've now looked at the original Texel code and it does indeed register the new instance in the passed in parent instance (inside TControl.Init()). So there would only be a memory leak if there wouldn't be a parent, but that is rejected with a FAIL anyway.

So we should fix that NEW() handling then, cause that is indeed a valid usecase...

(Obviously it's upon to user to handle this correctly then, but that's the case with normal allocations as well, so... *shrugs*)

Regards,
Sven

I've seen that now as well now that I was able to look at the code.

This is something quite specific, and I actually wonder if it's a corner case we don't handle or PurePascal's implementation is less restrictive.

It's a valid usecase so I say we should support that as well.

Regards,
Sven