I was looking at the code for Tag property in classes unit and noticed I can't safely use Tag to keep runtime pointers (at least on a 64 bit compile). What is the likelihood of getting tags changed to support universal access under 64/32 bit compiles?

What is the logic behind the shortfall? I suspect just legacy and it could be easily fixed.

Andrew Brunner wrote

I was looking at the code for Tag property in classes unit and noticed I can't safely use Tag to keep runtime pointers (at least on a 64 bit compile). What is the likelihood of getting tags changed to support universal access under 64/32 bit compiles? What is the logic behind the shortfall? I suspect just legacy and it could be easily fixed. _______________________________________________

The logic is that it is bad programming to use an integer to store a pointer. And we don't want to encourage bad programming.

Yes, I know it's easy, and yes I know it's common practice. Neither make it right to do so.

We'll fix the issue as the upcoming Delphi 64-bit - unfortunately - forces us to follow suit.

Michael.

On Nov 22, 2010, at 9:13 AM, wrote

I was going to disagree with that statement. But after considering it some what then would be the likelihood of getting TComponent to have a Data property of pointer???

+6499999999

Never EVER fall into the VB bullshit trap that is the Tag property. Related to that matter, Windows/delphi has a few of these "Data pointers", especially the stuff that is lower-level and is used to invoke the winapi with as a parameter (callbacks anyone?). Always try to stay clear of it as much as possible, because it does encourage and even invite bad programming.

We'll fix the issue as the upcoming Delphi 64-bit - unfortunately - forces us to follow suit.

sad to read this part though...

kind regards,
Dimitri Smits

That's why handles are used for that purpose, and on a 64 bit system handles can have 64 bits as well.

DoDi

That would be my preferred (and already proposed) solution.

Michael.

Handles are equally bad. They are *not* pointers.

You should store a pointer in a variable of pointer type, period.

Michael.

A user cannot know, and should not care, what hides behind a handle.

You should store a pointer in a variable of pointer type, period.

See lParam in messages...

DoDi

Will it also create an additional confusion in design time? I mean, non-RAD compilers possibly only have compile-time context, while Lazarus has also design-time. One example, if the Tag is 64-bit and one set up the environment to cross-compile from 32-bit IDE to 64-bit, he or she even won't be able to change a 64-bit integer property in the designer.

And also speaking of following/not following Delphi, I think Lazarus has two things to have courage not to follow the trend:
- dfm and lfm is not easily interchangeable, so if Lazarus is not going with Delphi with the tag size, there's always could be a warning (highlighting) pointing out to an exceeded Tag value.
- the compiler for a long time had pointer conversion not portable hint/warning so no matter how big Tag is, writing
SomeMyAddr:=pointer(Obj.Tag) already warns the developer.

Hmm, also a little off-topic analogy, AMD was the second until they were first with 64-bit processors. Intel just had to follow. Project this to Pascal ;-)

Max Vlasov

That would not be an issue as Int64 is available under all flavors of FPC.

I don't see the hold up in adding a patch for Data field. There is just one unit to change. What makes this so complicated that it hasn't be accomplished yet???

The task itself is easy. The consequences of this may not be so easy:

TComponent is a basic class. Many many instances are created during the lifetime of an application. Adding a field that adds 4/8 bytes to such a class is something we're not eager to do, since it has potentially a large impact on the memory consumption of existing apps.

Everything has its reasons, as you can see.

Michael.

Components consume much space already, so what's the percentage that a 64 bit type would add to every component, and to the app? And when the Tag type/sice depends on the target, nothing will change unless for 64 bit targets.

DoDi

First we have to agreee about the new type. Int64 could have been choosen already - by Delphi - when this were a reasonable decision.

DoDi

As I understand it , Andrew is talking about adding an additional field 'Data' of type pointer (or better would be TObject) which would exist next to the Tag field.

For Delphi compatibility reasons, the Tag type will be changed to PtrInt.

Michael.

On Nov 23, 2010, at 8:43 AM, Hans-Peter Diettrich

Components consume much space already, so what's the percentage that a 64 bit type would add to every component, and to the app? And when the Tag type/sice depends on the target, nothing will change unless for 64 bit targets.

No. The sizeof(int64) is the same on all platforms/CPUs. Which is 8 bytes. 64bits*1byte/8bits. What data you fill that 8 bytes with is of no concern to the compiler. I is just bad practice to use it as anything other than whole numbers. QWord for unsigned. Int64 for signed.

Ok.

First off tag should be revised to match Delphi.

Second. I need data property on Tcomponent

I propose having an additional directive for this mechanism kind of like the option for using large strings. Components have data property. This way I can just get it into the Laz dialog.

How about that?

For Delphi compatibility reasons, the Tag type will be changed to PtrInt. Michael.

As I understand it, Andrew wants just the existing tag to be changed to 64 bit, Not an additional field.
But PtrInt will do the job.

The Data field suggests something like we have in KOL. But that is there for other reasons: no class ;-)
Is anyone doing anything in converting KOL to 64 on their own? We would be interested and share our efforts, since there is a lot of demand from the community.

Regards,

Thaddy

Andrew Brunner пишет:

If we start adding new properties, directives, keywords etc on every such request, the end result will deserve only placing into trash.
TComponent already allows
a) Using Tag property to store indices into array or other container of data of any type; b) Using Components property to store any number of child components, which are owned, named, can notify and be notified of insertion and deletion.

Regarding the Tag type, the fact we're tied up with that "Delphi compatibility" is quite unfortunate. I wonder how they are going to maintain compatibility between 32 and 64 bit versions.

Regards,
Sergei

They do the same as we:

They introduced something like PtrInt (using of course a different name) and made tag equal to this type.

Instead of biting the bullet and telling people to code properly.

But like most companies, they are a bit of a prostitute in this regard.

Michael.

On Tue, Nov 23, 2010 at 1:20 PM, Michael Van Canneyt <

This is precisely why I asked to create a Data pointer so components can assign extraneous data and associate it with said component.

I see absolutely no legitimate argument as to why TComponent cannot have such a field. Memory is not a problem b/c if memory was a problem one would not be designing using the TComponent descendant. It would most likely be record or class.

This is a legitimate design problem I have. Typcial Tcomponents only represent data. Just like a TListViewItem. Just because Delphi wants to use Tag and we want to use actual data pointer that does not invalidate the team's decision to not expand the FPC platform. But, I'm already starting to automate my own svn changes over here - I'll just have my own version :-)

On Tue, Nov 23, 2010 at 10:28 PM, Andrew Brunner <

Andrew,
Creating TList as a field for storing extra structures and objects and supporting extra data reference using Tag as an index never was a problem for me. Can you tell a single reason not to implement this approach by yourself? Moreover managing the destruction of objects in this case is much easier and straightforward.
Other consideration, if something starts to depend on future decisions of other developers, isn't it easy to create a simple (very simple) workaround :)

Max Vlasov

In the specific problem I have, it is corellating TMenuItem with a particular data pointer object of TForm. Forms can close out of order and re-Index the List I have (as you stated). But there is no clean way for me to reference what was clicked on Sender... Tag or Data is the only clean solution here. Out of order, happening on application thread... Oh, and TMenuItems being is about productivity. What must I create an additional list when I have Tag or Data.

Good.

I've been waiting for some time:

Luiz

On Tue, Nov 23, 2010 at 11:32 PM, Andrew Brunner <

Things become a little more complex in this case, but just a little, [id:pointer] where id is autoincrement. You can have two synchronized lists (TList), one stored ids, another one - corresponding object. Or create a list with a record containing both. I'm from Turbo Pascal era so dynamic "array of" was a kind of novelty some time ago for me and I created an analogue. But this time [array of record id: integrer; ptr: pointer end;] is no longer a problem and you have privilege to use a language already containing such a great dynamic structure :)

I also must say (probably others will confirm) that programming starting turbo pascal gave me once and for good the sense that the design-time objects and data are a great help, but just secondary help, everything solid comes from elsewhere.

Max Vlasov

If you create the menuItem at runtime, you can always use a sub-class, create your own class TMyMenuItem, with a property and field to store the data..

That is what OO is for....

If you create the menuItem at runtime, you can always use a sub-class, create your own class TMyMenuItem, with a property and field to store the data..

No, that's what the Tag feature is for, now that it done right...LOL.

If it had not been for Delphi compatibility,
you would have been waiting forever :-)

Michael.

So it seems that now it's time to add NativeInt type ;-) .

BTW: i'm a fpc only guy and dont care keeping code compilable under Delphi but in the other side i do some porting of Delphi code.

Luiz