Re: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
Am Mittwoch, 6. September 2006 11:05 schrieb Michael Van Canneyt: > On Wed, 6 Sep 2006, Ale Katona wrote: > > The problem here is that if you introduce a changing type to Tag, > > you're going to break streaming of the components between various > > platforms. However I think simplest would be to simply make the tag > > something huge for years to come, like Int64. > > > > The idea with hidden union is nice tho. But you'll need to know how > > to stream it precisely and there's also endianness to take care of > > then. > > 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. > > In casu: > > Typecasting 'Tag' to a pointer is a non-portable, ugly hack and we > should not encourage such hacks. > > If you want to store objects, use a TCollection, and store > TCollectionItem.ID in the component tag. ID is a unique identifier, > even when elements are added and removed from the collection. > > Slightly more work, but clean and portable. > > Michael. In many situations, the collection would be overkill, so I'd also opt for the new public property "UserData : pointer" or better "TagPtr : pointer". This would make it harder to create code, that also compiles with delphi, but that doesn't bother me ;-) Anyway, if one needs to compile with delphi, one could continue to use pointer(tag), as delphi is 32-bit only anyway ... This way the user has the choice to write code that compiles with fpc32+delphi or fpc32+fpc64 regards Burkhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
Michael Van Canneyt wrote: > If you want to store objects, use a TCollection, and store > TCollectionItem.ID in the component tag. ID is a unique identifier, even > when elements are added and removed from the collection. > > Slightly more work, but clean and portable. And much slower. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
On Wed, 6 Sep 2006, Ale Katona wrote: The problem here is that if you introduce a changing type to Tag, you're going to break streaming of the components between various platforms. However I think simplest would be to simply make the tag something huge for years to come, like Int64. The idea with hidden union is nice tho. But you'll need to know how to stream it precisely and there's also endianness to take care of then. 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. In casu: Typecasting 'Tag' to a pointer is a non-portable, ugly hack and we should not encourage such hacks. If you want to store objects, use a TCollection, and store TCollectionItem.ID in the component tag. ID is a unique identifier, even when elements are added and removed from the collection. Slightly more work, but clean and portable. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
The problem here is that if you introduce a changing type to Tag, you're going to break streaming of the components between various platforms. However I think simplest would be to simply make the tag something huge for years to come, like Int64. The idea with hidden union is nice tho. But you'll need to know how to stream it precisely and there's also endianness to take care of then. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
Michael Van Canneyt wrote: I don't consider storing a pointer in the tag is broken code, it was considered the accepted way to maintain a pointer to your custom data from a standard control and there is often no simple alternative. Accepted only because there was no other way. The only correct way is to introduce an additional field 'UserData', of type Pointer. I think this is an excellent solution. Casting Tags to pointer is/was bad practice anyway. The Tag can still be used for association of user data with a component, but then as an index to a lookup table which holds the actual pointer. That is a portable solution (though it requires a little more memory and code). So adding a UserData field will be helpful. If we really want to save memory usage, we can even let a UserData (public) property and the Tag (published) property use the same field. Tag will then be an interface to the lowest 32 bits of a pointer field, which is simply stored/read in a whole by UserData. But this is of course a hack which is more likely to confuse programmers and cause problems in the future, so I wouldn't particularly recommend it... Regards, Bram Kuijvenhoven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
Daniël Mantione wrote: In 16 bit days it was considered acceptable to typecast pointers into records and just increase their offset. However, it was not portable. Making your code portable requires some effort. This kind of code is just one example of things you should not do in portable code. If Borland had intended this as a pointer , they would have declared it as a pointer. Of course there is a simple solution, derive a class and add fields to taste. For non visual components it's simple, but for LCL/Visual components it's a bit more complicated if you plan to use them with the GUI designer: you will have to write a package and then install it. In other cases are worse. Look at the TPage example (which in fact was the motivation to suggest this modification since i want a place to store a pointer in it): i would have to write a TPage descendant and also modify the Lazarus IDE to use it when designing the GUI. Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
> ...which makes it impossible to use streams for anything derived from > Tcomponent, which is really a lot. I don't think we should break this > feature to allow broken code to work. BTW even borland themselves seemed to promote its use for storing pointers from delphi 3 help: "Tag has no predefined meaning to Delphi. The Tag property is provided for the convenience of storing additional integer value or pointer information for special needs in an application. For example, use the Tag property when implementing case statements with a component." ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
On Mon, 04 Sep 2006 13:16:11 +0200 Vincent Snijders <[EMAIL PROTECTED]> wrote: > Daniël Mantione schreef: > > > > Op Mon, 4 Sep 2006, schreef Vincent Snijders: > > > >> Daniël Mantione schreef: > >>> Op Mon, 4 Sep 2006, schreef Mattias Gaertner: > >>> > Me2. > > Just one disadvantage: > The Tag is published. > If someone stores a 64bit value and the component is stored, > the stream can not be read under 32bit anymore. > >>> ...which makes it impossible to use streams for anything derived > >>> from Tcomponent, which is really a lot. I don't think we should > >>> break this feature to allow broken code to work. > >> Really a lot? Can you give examples where numbers > maxint are > >> streamed? > > > > Even if you stream a zero it breaks. > > > > Then Lazarus uses an advanced streaming mechanism, which looks at the > size of the value and decides to 1, 2, 4 or 8 bytes for an int64, > when streaming a form. > > I thought this was more or less standard behaviour. It is. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
Marc Weustink wrote: Michael Van Canneyt wrote: On Mon, 4 Sep 2006, peter green wrote: Me2. Just one disadvantage: The Tag is published. If someone stores a 64bit value and the component is stored, the stream can not be read under 32bit anymore. ...which makes it impossible to use streams for anything derived from Tcomponent, which is really a lot. I don't think we should break this feature to allow broken code to work. ahh the joys of conflicting requirements, I don't consider storing a pointer in the tag is broken code, it was considered the accepted way to maintain a pointer to your custom data from a standard control and there is often no simple alternative. Accepted only because there was no other way. The only correct way is to introduce an additional field 'UserData', of type Pointer. A pointer cannot be stored anyway at design-time, so it does not need to be published. Remains the decision where you introduce this pointer: TComponent, TControl. IMHO, you should introduce TLCLComponent, add it there, and descend all LCL components from that. TLCLComponent is already exists (it's only not committed yet. Adding a UserData to it is maybe an idea. THis will work for most compoenents, except DB components for instance. Whoops, as Vincent reminded me, it is already there (I confused it with another uncommitted class) Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
Michael Van Canneyt wrote: On Mon, 4 Sep 2006, peter green wrote: Me2. Just one disadvantage: The Tag is published. If someone stores a 64bit value and the component is stored, the stream can not be read under 32bit anymore. ...which makes it impossible to use streams for anything derived from Tcomponent, which is really a lot. I don't think we should break this feature to allow broken code to work. ahh the joys of conflicting requirements, I don't consider storing a pointer in the tag is broken code, it was considered the accepted way to maintain a pointer to your custom data from a standard control and there is often no simple alternative. Accepted only because there was no other way. The only correct way is to introduce an additional field 'UserData', of type Pointer. A pointer cannot be stored anyway at design-time, so it does not need to be published. Remains the decision where you introduce this pointer: TComponent, TControl. IMHO, you should introduce TLCLComponent, add it there, and descend all LCL components from that. TLCLComponent is already exists (it's only not committed yet. Adding a UserData to it is maybe an idea. THis will work for most compoenents, except DB components for instance. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
Daniël Mantione schreef: Op Mon, 4 Sep 2006, schreef Vincent Snijders: Daniël Mantione schreef: Op Mon, 4 Sep 2006, schreef Mattias Gaertner: Me2. Just one disadvantage: The Tag is published. If someone stores a 64bit value and the component is stored, the stream can not be read under 32bit anymore. ...which makes it impossible to use streams for anything derived from Tcomponent, which is really a lot. I don't think we should break this feature to allow broken code to work. Really a lot? Can you give examples where numbers > maxint are streamed? Even if you stream a zero it breaks. Then Lazarus uses an advanced streaming mechanism, which looks at the size of the value and decides to 1, 2, 4 or 8 bytes for an int64, when streaming a form. I thought this was more or less standard behaviour. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
On Mon, 4 Sep 2006, peter green wrote: Me2. Just one disadvantage: The Tag is published. If someone stores a 64bit value and the component is stored, the stream can not be read under 32bit anymore. ...which makes it impossible to use streams for anything derived from Tcomponent, which is really a lot. I don't think we should break this feature to allow broken code to work. ahh the joys of conflicting requirements, I don't consider storing a pointer in the tag is broken code, it was considered the accepted way to maintain a pointer to your custom data from a standard control and there is often no simple alternative. Accepted only because there was no other way. The only correct way is to introduce an additional field 'UserData', of type Pointer. A pointer cannot be stored anyway at design-time, so it does not need to be published. Remains the decision where you introduce this pointer: TComponent, TControl. IMHO, you should introduce TLCLComponent, add it there, and descend all LCL components from that. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
Op Mon, 4 Sep 2006, schreef Vincent Snijders: > Daniël Mantione schreef: > > > > Op Mon, 4 Sep 2006, schreef Mattias Gaertner: > > > > > Me2. > > > > > > Just one disadvantage: > > > The Tag is published. > > > If someone stores a 64bit value and the component is stored, > > > the stream can not be read under 32bit anymore. > > > > ...which makes it impossible to use streams for anything derived from > > Tcomponent, which is really a lot. I don't think we should break this > > feature to allow broken code to work. > > Really a lot? Can you give examples where numbers > maxint are streamed? Even if you stream a zero it breaks. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
Op Mon, 4 Sep 2006, schreef peter green: > > > > > > Me2. > > > > > > Just one disadvantage: > > > The Tag is published. > > > If someone stores a 64bit value and the component is stored, > > > the stream can not be read under 32bit anymore. > > > > ...which makes it impossible to use streams for anything derived from > > Tcomponent, which is really a lot. I don't think we should break this > > feature to allow broken code to work. > ahh the joys of conflicting requirements, > > I don't consider storing a pointer in the tag is broken code, it was > considered the accepted way to maintain a pointer to your custom data from a > standard control and there is often no simple alternative. In 16 bit days it was considered acceptable to typecast pointers into records and just increase their offset. However, it was not portable. Making your code portable requires some effort. This kind of code is just one example of things you should not do in portable code. If Borland had intended this as a pointer , they would have declared it as a pointer. Of course there is a simple solution, derive a class and add fields to taste. > how does streaming of components work? would it be possible to make tag able > to accomodate a pointer while only writing the least significant 32 bits to > a stream? Yes, this could be an acceptable solution, since you can never stream pointers anyway. However, I am still worried about a slippery slope. There exists many data types with longints in them and we simply cannot declare them all longint just because someone might store a pointer in it. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
> > > Me2. > > > > Just one disadvantage: > > The Tag is published. > > If someone stores a 64bit value and the component is stored, > > the stream can not be read under 32bit anymore. > > ...which makes it impossible to use streams for anything derived from > Tcomponent, which is really a lot. I don't think we should break this > feature to allow broken code to work. ahh the joys of conflicting requirements, I don't consider storing a pointer in the tag is broken code, it was considered the accepted way to maintain a pointer to your custom data from a standard control and there is often no simple alternative. how does streaming of components work? would it be possible to make tag able to accomodate a pointer while only writing the least significant 32 bits to a stream? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
On Mon, 04 Sep 2006 11:56:06 +0200 Vincent Snijders <[EMAIL PROTECTED]> wrote: > Daniël Mantione schreef: > > > > Op Mon, 4 Sep 2006, schreef Mattias Gaertner: > > > >> Me2. > >> > >> Just one disadvantage: > >> The Tag is published. > >> If someone stores a 64bit value and the component is stored, > >> the stream can not be read under 32bit anymore. > > > > ...which makes it impossible to use streams for anything derived > > from Tcomponent, which is really a lot. I don't think we should > > break this feature to allow broken code to work. > > Really a lot? Can you give examples where numbers > maxint are > streamed? I agree with Luiz, that there is a lot more code using tag as storage for a pointer, than code streaming big numbers. So for compatibility it should be PtrInt. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
Daniël Mantione schreef: Op Mon, 4 Sep 2006, schreef Mattias Gaertner: Me2. Just one disadvantage: The Tag is published. If someone stores a 64bit value and the component is stored, the stream can not be read under 32bit anymore. ...which makes it impossible to use streams for anything derived from Tcomponent, which is really a lot. I don't think we should break this feature to allow broken code to work. Really a lot? Can you give examples where numbers > maxint are streamed? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
Op Mon, 4 Sep 2006, schreef Mattias Gaertner: > Me2. > > Just one disadvantage: > The Tag is published. > If someone stores a 64bit value and the component is stored, > the stream can not be read under 32bit anymore. ...which makes it impossible to use streams for anything derived from Tcomponent, which is really a lot. I don't think we should break this feature to allow broken code to work. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
On Mon, 4 Sep 2006 07:13:53 +0200 Martin Schreiber <[EMAIL PROTECTED]> wrote: > On Monday 04 September 2006 02.55, Luiz Americo wrote: > > I'd like to propose change TComponent.Tag type from longint to > > PtrInt. I know it's not a good programing practice, but sometimes > > this property can be used to hold pointers. > > In 32bit there's not many problems since pointer and longint have > > the same size, but the thing changes in 64 bit. > > The choice of PtrInt has the benefit of not modifying nothing in > > 32bit, while in 64bit you getting a integer of the same size of > > pointers. > > > > What do you think? > > > > Agreed. Me2. Just one disadvantage: The Tag is published. If someone stores a 64bit value and the component is stored, the stream can not be read under 32bit anymore. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
On Monday 04 September 2006 02.55, Luiz Americo wrote: > I'd like to propose change TComponent.Tag type from longint to PtrInt. > I know it's not a good programing practice, but sometimes this property > can be used to hold pointers. > In 32bit there's not many problems since pointer and longint have the > same size, but the thing changes in 64 bit. > The choice of PtrInt has the benefit of not modifying nothing in 32bit, > while in 64bit you getting a integer of the same size of pointers. > > What do you think? > Agreed. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
> I'd like to propose change TComponent.Tag type from longint to PtrInt. > I know it's not a good programing practice, but sometimes this property > can be used to hold pointers. > In 32bit there's not many problems since pointer and longint have the > same size, but the thing changes in 64 bit. > The choice of PtrInt has the benefit of not modifying nothing in 32bit, > while in 64bit you getting a integer of the same size of pointers. > > What do you think? do it, this was a very common use of tag in lots of delphi code and i can't see any problems with having it as a 64 bit type. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
