[fpc-devel] TBytes

[Marco van de Voort]

In our previous episode, Martin Schreiber said:
> > If you care, you can do manual management.
> 
> Yup, MSEgui has allocuninitedarray() for the purpose. I don't think it 
> is more "clean" or "secure" than the old ansistring method because it 
> depends on compiler internals.

getmem/freemem ?
 
> > Or pool arrays of byte. (I do
> > this in my Delphi app, where I have a nice generic pool class).
> >
> I like handy tools. Using FPC 2.6 AnsiString as buffer is handy.

IMHO it is an abuse. One could discuss if internal usage is a big problem (I
think that is still bad though, but if you switch typing string to explicit
ansistring, there is no rush), but I think at least public
programming interfaces should be free of such gotchas.

In cases where tbytes behaviour is prohibitive due to performance, one
probably shouldn't be using automated types in the first place.

> > But I don't think TBookmark is very speed-sensitive.
> 
> We don't talk about TBookmark only here. AFAIK all "string as 
> databuffer" is prohibited in future FPC.

In the early 1.9.x days, when I ported Delphi code to FPC, half of the
difficult bugs were related to this kind of abusing internals, specially the
relying on autoconversions (of pchar, arrays of char etc).  But then, pchar
based items were the only overindexable type in Delphi, and that was a must
nack then.  Nowadays, other types are overindexable too, or at least can be
made too, so there is no reason to continue these practices.

Yes, if it is just one person with complete oversight doing it himself, one
can easily get away with it, specially since changes like the D2009 unicode
transition don't happen every day.  But this kind of hidden assumptions is
errorprone if you have multiple persons working on the code, specially if
some don't know the ins and outs of the code 100%, and very long term
increases the number of spots where maintenance must be done significantly.

There have been such cases (and heated discussions) in the past, e.g. when
people abused shortstring, and code stopped working when code was switched
to ansistring because characters were accessed that were not <=length(s). 
Nobody argues that ansistring "should be fixed" for that anymore, and in 5
years nobody will care about this either :-)