<p dir="ltr">Hello all, </p>
<p dir="ltr">Instead of hardcoding stuff into the (amazing) fpc compiler, would it be possible to use generics and operator overloading to create a smart pointer implementation?<br>
This might require some improvements like record constructors/destructors (or initializer/finalizer) and some way to overload the member access operator "." but it might create a more flexible and powerful implementation.<br></p>
<p dir="ltr">Chriss<br>
</p>
<div class="gmail_quote">Στις 20 Σεπ 2014 6:41 μ.μ., ο χρήστης "<a href="mailto:hinstance@yandex.ru">hinstance@yandex.ru</a>" <<a href="mailto:hinstance@yandex.ru">hinstance@yandex.ru</a>> έγραψε:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p>Link to Lazarus forum thread with reference counting discussion: <a href="http://forum.lazarus.freepascal.org/index.php/topic,22231.0.html" target="_blank">http://forum.lazarus.freepascal.org/index.php/topic,22231.0.html</a><br>My opinion: yes, this feature should be implemented.</p><p>And yes it should be optional (either additional root object or local compiler switch), so that existing code could remain unmodified.<br><br><br>20.09.2014, 19:00, "Hans-Peter Diettrich" <<a href="mailto:DrDiettrich1@aol.com" target="_blank">DrDiettrich1@aol.com</a>>:</p><blockquote> Sven Barth schrieb:<br><blockquote> On 20.09.2014 12:36, Hans-Peter Diettrich wrote:<br><blockquote> AFAIK some Delphi XE made TObject itself managed, by reference counting.<br> It would be easy to introduce the same feature in FPC, so that no<br> special base class would be required. Like with extended RTTI a decision<br> should be made, whether managed objects should be enabled or disabled by<br> default. Afterwards automatic management can be turned on or off for<br> every single class or object individually.</blockquote> It's basically easy, yes, but then one has to deal with code like this:</blockquote> [...]<br><blockquote> Which could lead to some unintended side effects if "o" is passed to<br> some other code which keeps the instance around and ".Free" merely<br> decreases the reference count. Of course that would have been a memory<br> leak before and now it's not, but nevertheless it changes behavior.</blockquote> I already mentioned that destructors still are required, but will have<br> an different purpose and usage than before. This would discourage<br> continued use of Destroy(), BeforeDestruction() etc., which should at<br> least be renamed to prevent unconverted legacy code from compiling. This<br> change already will break compatibilitiy, so that consequently all<br> libraries (in detail when dealing with lists containing objects) have to<br> be updated. I was aware of such consequences, but I'm no more sure of<br> the consequences of my idea of simply turning refcounting on or off for<br> specific objects or classes.<br><br> The mere implementation of refcounting for TObject is easy, but the<br> consequences are hell :-(<br><br> DoDi<br><br> _______________________________________________<br> fpc-devel maillist - <a href="mailto:fpc-devel@lists.freepascal.org" target="_blank">fpc-devel@lists.freepascal.org</a><br> <a href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel" target="_blank">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a></blockquote><br>_______________________________________________<br>
fpc-devel maillist - <a href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a><br>
<a href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel" target="_blank">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a><br>
<br></blockquote></div>