[fpc-devel] Breaking change in FPC 2.6.1
Marco van de Voort
marcov at stack.nl
Wed Apr 25 10:28:41 CEST 2012
In our previous episode, Ludo Brands said:
> It broke also lazarus, MDO, rxmemds.
They mostly track 2.7.1 also, so then it should be just a matter of enabling
the right override for 2.6.x too (which is what I had in mind)
> > I first changed it to tbytes (as it is in D2009+), but got
> > some comments that that was very incompatible, and a lot of
> > method signatures would change. So I kept it pchar. (planning
> > to change it to tbytes in trunk eventually)
> If it were pchar we wouldn't have the problems since pchar and string are
> assignment compatible. It is pointer now.
Sorry, mixed up with the trecordbuffer stuff again, which I kept pchar,
which is not "later Delphi" compatible, as Martin Schreiber
clearly exposed in his mail.
The bookmark situation is different. I can't really recall what
the rationale was atm. I assume the main rationale was to simply start with
creating a division between tbookmark and tbookmarkstr.
> Don't know where the comments came from but here we are in a situation where
> most 3rd party datasets had to be adapted to the change to pointer and will
> have to change again to tbytes later on. On top of that the freebookmark
> that a lot of third code had to add to catch up to the change to pointer
> isn't needed anymore for tbytes as it is a managed type. Why not bite the
> bullet immediately and just skip pointer? Avoiding incompatibility clearly
That can be discussed. Specially if sb can confirm that it works.
I can however remember having read that freebookmark is still recommended,
and if I look at the method, it is virtual and allows descendants to do
Probably because one can't trigger and event on freeing of an automated type
(at least not the array based ones, interfaces is a differnet matter)
But I assume that is more for the dataset users that use
tbookmark than for internal use in tdataset implementers.
> On the Delphi forums, similar discussions have been going on: people
> complaining about the different Tbookmark implementations and having to
> change their code. Wish we could have learned from that.
That's why I waited a while with merging, so that initially only 2.7.1 would
be broken, and after a time without complaints, I merged it because then it
is only the matter of connecting that change also with 2.6.1.
> > Freebookmark should have been called already, afaik it is at
> > least since D2006, if not easier, and FPC also implements it
> > quite a while.
> Quote: "TBookmark is an alias of TBytes. This means that TBookmark is
> automatically garbage collected when it goes out of scope. Because TBookmark
> does not need to free memory, the FreeBookmark method is blank for the
> default implementation."
True. But it is virtual, so if your code is agnostic wrt the dataset you
use, or can be layered on top of otther datasets, you should call
freebookmark probably even if it doesn't for the default dataset.
IOW my idea is document and recommendthe way that always works now, not
shortcuts that may be possible for historic reasons.
More information about the fpc-devel