Using tag as a pointer is plain wrong coding, so this change will not make it.

Moreover, streaming it is pure nonsense: There is no guarantee that your pointer will point to the same object, or indeed whether it will exist at all when the program is run.

The IDE code is simply wrong, and should be fixed properly by creating a TMenuItem descendent that contains a reference to the notebook page, and use that class when constructing the menu.

Michael.

Hans-Peter Diettrich wrote

IMO Tag should become an int64 for all components, to overcome platform and streaming problems.

It has been rejected:
http:/msg05886.html
MSEgui uses a public "tagpo" property in tmsecomponent instead.

Michael Van Canneyt:
"
I've been following the discussion, and the tag property will remain what it is: a 32-bit integer. It was introduced by Delphi to mimic the Tag property which exists in VB, to allow it to be used in case statements. Changing it will probably cause more problems than it will solve. "

Martin

I added bug report about using Tag as Pointers in IDE http://bugs.freepascal.org/view.php?id=17642

For some reason (read-only???) I could not add a note there, so I'll present my ideas here:

IMO Tag should become an int64 for all components, to overcome platform and streaming problems. More properties can be introduced, for best compatibility with existing code (Tag64, TagPtr). These properties could be based on the same int64 field, i.e. r/w part of it, and only that field is streamed. And when we just are extending the type, we also could consider to make it big enough to hold a method reference...

DoDi

OK, I understand. The terrible thing is that I saw using Tag as Pointer in some delphi books.

That's implicate a lot of code with Tag as pointers. Maybe adding non streamed TagPtr:PtrInt will be the best compromise?

Andrzej Kilija?ski

Dnia 16-10-2010 o 12:57:44 Michael Van Canneyt
napisa?(a):

And3mD wrote

OK, I understand. The terrible thing is that I saw using Tag as Pointer in some delphi books.

The authors of these books are advocating wrong things. It is wrong to follow or encourage this practice.
They get away with it because delphi is 32-bit only.

In a cross-platform world, advocating this is simply criminal.

That's implicate a lot of code with Tag as pointers. Maybe adding non streamed TagPtr:PtrInt will be the best compromise?

No. for several reasons:

a) Pascal is a typesafe language.
Using Tag as a Pointer is simply wrong and goes against all Pascal stands for.

b) Adding this adds another 8 bytes to each and every component in memory. Increasing memory usage to encourage wrong programming practice would be very bad practice indeed.

Borland should have done the right thing and add something to TComponent like

   Property CustomData : TObject

or so, as a public property.

Normally I would propose this, but point b) still needs to be taken into account.

Michael.

Property CustomData : TObject or so, as a public property.

Or more flexible:

CstomData: packed record
      case integer of
        0 : (i64: int64);
        1 : (lo32, hi32 : Cardinal);
        2 : (Words : Array[0..3] of Word);
        3 : (Bytes : Array[0..7] of Byte);
        4 : (p : pointer);
        5 : (obj : TObject);
   end;

Benito

You just invented a Variant type.

Best regards,
Paul Ishenin.

Indeed, and the whole point is to have a type-safe solution.

(if a "solution" is needed at all, which still remains to be proved).

Michael.

Yes, but one that needs much less memory than default fpc variant (8 byte vs. 24 byte)
This record is always a better data type than int64 for custom data, but for variant this is not sure.

Benito

Message: 6
Date: Sat, 16 Oct 2010 16:34:01 +0200 (CEST)
From:
Subject: Re: [Lazarus] [fpc-devel] win64 dwarf patch To: Lazarus mailing list
Message-ID:
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

Hardly, It's a variant record and has been around since at least Turbo Pascal 3.0 20 years ago! Variant types include logic to prevent you from performing inappropriate operations on typed data. This contains no logic at all.

Indeed, and the whole point is to have a type-safe solution.

It isn't Type-Safe, it's exactly the opposite. It's a way of fooling the compiler into performing Pointer operations on an array of Char for example. Again, this was possible in TP3, it's called TypeCasting. If we want to access CustomData as a 64 bit integer then use int64(CustomData), everyone (should) know what this does. Either that or declare CustomData as "Variant"

It's a shame that you decry the use of Tag as a pointer and then seem to offer your implicit support to nonsense like this!

I'm not supporting anything. I think tag should remain as it is, for Delphi compatibility.

If you read all my mails, you would have understood that I'm not at all convinced we must offer anything else, so "support to nonsense" ? Far from it.

Michael.

While possible, I don't think it is necessary. This is bad coding that should have cleaned up long ago. Adding a workaround because the bad workaround fails makes no sense. The old workaround should be cleaned up.

Of course there is always a chance that Embarcadero will do something like that when they go 64-bit, but we'll cross that bridge if we get there.

(since even if we add a workaround, there is a chance they will add yet another)

Maybe just add an annotation in TComponent documentation to make this problem clear.

Something like that:

"Tag property is a streamed integer value. Using Tag as pointer storage is bad programing practice and produce a lot of problems in 64 bit compilation (where Tag is still 32bit integer and pointers are 64bit)."

http://lazarus-ccr.sourceforge.net/docs/rtl/classes/tcomponent.tag.html

Greetings
Andrzej And3mD Kilija?ski

Dnia 17-10-2010 o 15:12:19 Marco van de Voort napisa?(a):