On 02 Apr 2011, at 19:36, Jürgen Hestermann wrote:
> Jonas Maebe schrieb:
> > If you don't want the compiler to interfere with anything you do, do not
> > use automated types such as ansistring, unicodestring, dynamic array and
> > COM-style interfaces. The whole point of these types is that the compiler
> > will do lots of stuff behind your back, because without that the reference
> > counting cannot work.
>
> You are missing the whole point: It is just the problem that some
> ("automated"?) data types are not fully documented! How do I know which type
> behaves how? Do I have to guess it (as I did now)?
There are probably always things that can be added to the documentation, and
you're welcome to file bug reports to suggest that. However, in this case it
appears that you were not fully aware of the documentation on dynamic arrays
that does exist, because it does say that assigning a new value to a dynamic
array variable will decrease its current reference count.
> You are always saying that you cannot do this and that with these and other
> types but there is no clear documentation what exactly you can do and what
> you can *not* do and what the compiler does in the background.
What the compiler does exactly in the background cannot be documented, because
it is implementation-dependent and can change at any time, or differ on
different platforms.
Regarding what you can and cannot do: you cannot do anything that makes it
impossible for the compiler to see that you are taking a copy of or changing
the value of an automated/reference counted type. That includes fillchar, move,
blockread, and any other routine that operates on untyped "var" parameters,
since the type is lost in that case. Similarly, explicit typecasts (e.g., to
pointer) etc and assembler will have the same result.
The compiler can however not give an error if you do that anyway, because
internal helpers for those types in the RTL require such functionality to
perform the actual reference-counting operations (and of course there is much
ugly code in existence that performs all sorts of ugly hacks and that does
happen to and is expected to work).
Jonas_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
