[fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
daniel.mantione at freepascal.org
Mon Sep 4 13:02:46 CEST 2006
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
> 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
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.
More information about the fpc-devel