<p>Am 22.09.2014 16:45 schrieb "Peter Popov" <<a href="mailto:ppopov@hotmail.com">ppopov@hotmail.com</a>>:<br>
><br>
> How will referenced objects behave when referenced by a threadvar. This is an exceptional situation for both dynamic arrays and ansi strings.</p>
<p>There is no need for special handling, afterall a threadvar is (roughly) as if you had defined a variable locally to your thread's procedure. <br>
If you have e.g. two threads and a threadvar of a reference counted class type then thew are basically two possibilities:<br>
- you assign two different instances of that variable's class type (or one of its child classes) to each threadvar "instance"; in that case both class instances will have refcount one (if they aren't referenced anywhere else) and each will be freed when its corresponding thread goes out of scope (if threadvar finalization works correctly, bit that is a different topic)<br>
- you assign the same class instance to both threadvar "instances"; then the reference count will be 2 (if it isn't referenced anywhere else) and the instance will be freed once the last of the two threads finalizes its threadvars.</p>
<p>It's the same for interfaces, strings and arrays. The special handling is only for threadvars in general, but not for the types it holds.</p>
<p>><br>
> Another comment: If referenced objects all derive from a single base, then, the user cannot possibly have another hierarchy, which uses ref. objects. As I mentioned earlier, I do this explicitly for an object well down my hierarchy. So, it seems to me you still need something like:<br>
><br>
> -- code --<br>
><br>
><br>
> TRefObject = referenced class(TWhateverBase)<br>
> end;<br>
><br>
><br>
> -- end of code --</p>
<p>That's what I suggested in my RFC: have a possibility to declare a class somewhere down the hierarchy as reference counted and provide - using this possibility - a direct reference counted descendant of TObject inside the System unit for convenience reasons.</p>
<p>Regards,<br>
Sven</p>