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 :-) _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
