[fpc-devel] weak referencing (was Suggestion:.....)

Peter Popov ppopov at hotmail.com
Mon Sep 22 16:44:59 CEST 2014


How will referenced objects behave when referenced by a threadvar. This is an exceptional situation for both dynamic arrays and ansi strings.


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:

-- code --


TRefObject = referenced class(TWhateverBase)
end;


-- end of code --



Date: Mon, 22 Sep 2014 14:54:31 +0200
From: pascaldragon at googlemail.com
To: fpc-devel at lists.freepascal.org
Subject: Re: [fpc-devel] weak referencing (was Suggestion:.....)

Am 22.09.2014 14:31 schrieb "Hans-Peter Diettrich" <DrDiettrich1 at aol.com>:

>

> Marco van de Voort schrieb:

>

>> (to Sven)

>>

>> So the cycle break mechanism is going to be marking potential cycle cases

>> as weak.

>>

>> Do you still plan to at least detect cycles for debugging purposes?

>>

>> Or is the cycle detection itself already too hard?

>>

>> IOW I'm wondering what will happen (and what to do) if there is a cycle in a

>> sufficiently complex program.

>

>

> I could imagine a tool for that purpose, instead of burdening the compiler with such rarely used functionality. More diagnostics could be removed from the compiler, like the detection of unused local variables or units - if that helps to speed up compilation. Separate diagnostic tools could immediately offer means to solve the detected problems interactively, what's not the purpose of an compiler.

These diagnostics help the compiler to remove application code it doesn't need to generate. So why should I remove them? Also these diagnostics are quite fast already. Other more costly optimizations are already optional using the -Ox options.

Additionally the cycle detection algorithm wouldn't be run at compiletime anyway, but at runtime. Namely during every reference count decrease.

Regards,

Sven


_______________________________________________
fpc-devel maillist  -  fpc-devel at lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20140922/7d2efc3b/attachment.html>


More information about the fpc-devel mailing list