Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
The behaviour you are counting on is a side effect of an optimisation, not a behaviour by design. Oh, btw: fpc 2.2.2rc1 behaves with -O2 like delphi :) Without -O2 like 2.2.0 :) Add: I just realized that Peter implemented this some time ago in a in most cases (!) delphi compatible behaviour. My refactoring and optimization of the function return assignment handling is only available in 2.3.1. The change is too intrusive to backport it to 2.2.x. So far it works just great. Can we hope for a separated switch for this specific optimization ;-) . I am running 2.2.2 now. It is good that it works for you now, but like Jonas already wrote. It is just pure luck and you rely on optimizations. Something that should not be done, because some optimizations make debugging hard. In 2.2.2 there is a bit of function result reuse optimization, but it is limited. In 2.3.1 the handling is rewritten and made more generic. This rewrite affects too much code to be ever backported to 2.2.x Peter ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Boian Mitov wrote: I mean -O2 probably affects number of optimizations. I just hope there will be switches for turning off specific optimizations selectively. Please use a separate thread for new questions. See the -O switch help in 'fpc -h' how to turn on/off optimizations. Peter ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Hi Peter, Thank you! It works when the optimization is off. I was thanking for making it work, when the optimization is off. I do not rely on optimization. I am already looking to implement a mechanism to guard against the problems introduced by the optimization, and hope to have code that will behave properly even when it is on. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Peter Vreman [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Sunday, June 22, 2008 1:43 PM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 It is good that it works for you now, but like Jonas already wrote. It is just pure luck and you rely on optimizations. Something that should not be done, because some optimizations make debugging hard. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
On 22 Jun 2008, at 23:30, Boian Mitov wrote: I mean it was not working when the optimization was on. They did not have option to turn the optimization off. No, it can only work when the optimization is on in FPC. To recap: a) in both FPC and Delphi, temps (regardless of their type) are never automatically finalized immediately after their last use, so they can retain references for a while b) Delphi optimizes (possibly regardless of its optimization switch state) assignments of (reference counted) function results to local variables which cannot escape the current scope so that no temps are used (and hence no invisible references are created) c) FPC also optimizes these assignments as of 2.2.2, but under a few less circumstances than Delphi (see the example I posted with the nested functions) d) in case of global variables or local variables which escape the current scope, both Delphi and FPC create temps which hold invisible references until these temps are reused for another purpose or go out of scope (per rule a). Your programs are coded with the assumption that this optimization is always performed, which a) is wrong for both Delphi and FPC in case global variables or local variables accessed outside their defining scope are used (as has been demonstrated using various programs posted to this mailing list) b) is wrong for FPC = 2.2.0 c) is wrong for all current FPC versions in a few cases where the compiler can theoretically know that a local variable is not used outside its defining scope, but where it does not know that at this time You keep however arguing that it is some mysterious optimization in FPC which causes the difference in behaviour (while it's actually a lack of a particular optimization that causes it), and that Delphi always does what you want (which it doesn't, as has been demonstrated using the example programs posted to this list). Please understand that it is extremely tiring and frustrating to discuss in this way, because it gives the impression that you simply do not care about what causes the problem and/or simply are not listening to what we are trying to say. So let me repeat one last time: Delphi optimizes assignments of reference counted function results to local variables which provably do not escape their defining scope so that they do not need a temp. FPC does this now also in most, but not all cases. Delphi, just like FPC, never automatically finalizes temps immediately after every statement in which they were used. And while Delphi's optimization results in the behaviour you want for the code that you have written (and possibly the same behaviour which is explicitly defined in a number of other languages), it is pure luck that it does and it will have guaranteed different behaviour if you use global variables or local variables which can escape their defining scope. FPC does not guarantee to perform exactly the same optimizations as Delphi and therefore may also have different behaviour in a number of cases. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Hi Jonas, Thank you! I am already thinking of a permanent work around that will fix that regardless of the optimization or not. I think that by changing the Lock to be interface and doing few other tricks I may be able to achieve that, so the dependency on the way it works will not exist any more ;-) . With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Jonas Maebe [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Sunday, June 22, 2008 2:52 PM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 No, it can only work when the optimization is on in FPC. To recap: ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
The behaviour you are counting on is a side effect of an optimisation, not a behaviour by design. Oh, btw: fpc 2.2.2rc1 behaves with -O2 like delphi :) Without -O2 like 2.2.0 :) Add: I just realized that Peter implemented this some time ago in a in most cases (!) delphi compatible behaviour. My refactoring and optimization of the function return assignment handling is only available in 2.3.1. The change is too intrusive to backport it to 2.2.x. Peter ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Hi Peter, Thank you! So far it works just great. Can we hope for a separated switch for this specific optimization ;-) . I am running 2.2.2 now. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Peter Vreman [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Friday, June 20, 2008 2:42 PM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 The behaviour you are counting on is a side effect of an optimisation, not a behaviour by design. Oh, btw: fpc 2.2.2rc1 behaves with -O2 like delphi :) Without -O2 like 2.2.0 :) Add: I just realized that Peter implemented this some time ago in a in most cases (!) delphi compatible behaviour. My refactoring and optimization of the function return assignment handling is only available in 2.3.1. The change is too intrusive to backport it to 2.2.x. Peter ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
I mean -O2 probably affects number of optimizations. I just hope there will be switches for turning off specific optimizations selectively. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Boian Mitov [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Friday, June 20, 2008 2:58 PM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 Hi Peter, Thank you! So far it works just great. Can we hope for a separated switch for this specific optimization ;-) . I am running 2.2.2 now. With best regards, Boian Mitov ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
While on the discussion, are there any plans for Semaphore and Mutex in the libraries in the future? I will be writing my own implementations using the Events, but just curious if in the future they are planned to be offered. I have seen Semaphore used in the TThread implementation, but they are not available outside the unit, so I assume they are too platform specific. I think I can make implementation by using only events, critical sections and counters. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Boian Mitov [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Friday, June 20, 2008 2:58 PM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 Hi Peter, Thank you! So far it works just great. Can we hope for a separated switch for this specific optimization ;-) . I am running 2.2.2 now. With best regards, Boian Mitov Mitov Software http://www.mitov.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
On 19 Jun 2008, at 13:10, Boian Mitov wrote: It appears that this bug has been fixed. Where I can get a patch for this? This is a very high priority bug for us, and we are glad that it has already been addressed :-) . I am very eager to test the fix. Please read the comments to http://bugs.freepascal.org/view.php?id=9472 There was/is no bug in the compiler and therefore nothing has been fixed. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Hi Jonas, Thank you! I don't understand. 0011503 is a major failure. Is it in the compiler or in some library? This code: Atest := TTest.Create(); Atest := NIL; will release properly the reference at assignment to NIL this code does not: Atest := TestFunc(); Atest := NIL; This is a huge problem. This code must work the same way in both cases but it does not. We are porting a huge library of over 4 million lines of code from Delphi. This is a major show stopper. I can probably take a look in the compiler as it will be much easier and faster for us to fix the compiler to be Delphi compatible rather than rewriting the libraries. They rely heavily on interfaces and the correct reference counting. Rewriting this even if desirable will delay the project with at least a year at best. By definition when there are no active references to an interface it must be released. This is a total failure of the functionality. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Jonas Maebe [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 4:15 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 On 19 Jun 2008, at 13:10, Boian Mitov wrote: It appears that this bug has been fixed. Where I can get a patch for this? This is a very high priority bug for us, and we are glad that it has already been addressed :-) . I am very eager to test the fix. Please read the comments to http://bugs.freepascal.org/view.php?id=9472 There was/is no bug in the compiler and therefore nothing has been fixed. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
On 19 Jun 2008, at 13:21, Boian Mitov wrote: Thank you! I don't understand. 0011503 is a major failure. Is it in the compiler or in some library? Please read the comments to http://bugs.freepascal.org/view.php? id=9472. The whole issue is discussed there in great detail. This is a huge problem. This code must work the same way in both cases but it does not. We are porting a huge library of over 4 million lines of code from Delphi. This is a major show stopper. I can probably take a look in the compiler as it will be much easier and faster for us to fix the compiler to be Delphi compatible rather than rewriting the libraries. They rely heavily on interfaces and the correct reference counting. Rewriting this even if desirable will delay the project with at least a year at best. By definition when there are no active references to an interface it must be released. This is a total failure of the functionality. There are active references, namely in an invisible temp. When this invisible temp is destroyed (at the function exit), the interface is freed. It is wrong to assume that implicit temps which still contain references to interfaces (or ansistrings, or any other reference counted type) can never exist, because this is an implementation detail over which the compiler has full control. This can also happen in Delphi under certain circumstances by the way (namely if it cannot guarantee that optimising the interface assignment is safe without using a temp). The purpose of automatic reference counting is simply that memory management is automated. It is not to guarantee the same semantics as what you would get in a manual reference counting scheme where you are in full control of when and where reference counts are increased and decreased. In principle, a periodic mark and sweep would also still be correct behaviour. Newer versions of FPC optimise assignments of function results more aggressively so you will more often get reference counting behaviour like in Delphi, but we do not guarantee in any way that it will be 100% identical. We only emulate the Delphi language, not the implementation details of the Delphi compiler or code generator. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Hi Jonas, This functionality works in all versions of Delphi 5-2007. We support them all, and we have done so for years. We have no problems to compile with such optimizations turned off. We need proper reference counting. We have over 300 Delphi components in 5 released and 3 libraries under current development, spreading over 4 million lines of code. We are looking to port it to Linux, and other platforms. The Lazarus looks like the natural solution. We have no problems creating a clone of it, or developing alternative compiler from scratch. We plan to allow C++ users to also use the library, as we provide C++/MFC and .NET component wrappers to our customers. If we need to we can simply fix the compiler for our needs and sell only compiled C++ supporting versions, or if you agree to allow some override to the behavior we can support the Lazarus and free Pascal too. We believe that as one of the biggest component vendors in the world, our support for Lazarus will help the project a lot. However for that we crucially need this problem fixed. CodeGear has done fixes for us in the past, in order to help us continue to support the platform, as they have done for other vendors, and we are very, very grateful for that, and have help them (convert) many of our .NET customers. We will be equally grateful for any help you can offer in our attempts to support Lazarus. We believe this will only help the community, and the popularity of the product. I have downloaded the source, and I will see if we can tweak it and add some compiler option to support this somehow. You can take a look at our currently available products here : www.mitov.com , and yes, we are working to make all this available in Lazarus ;-) . With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Jonas Maebe [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 4:39 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 On 19 Jun 2008, at 13:21, Boian Mitov wrote: Thank you! I don't understand. 0011503 is a major failure. Is it in the compiler or in some library? Please read the comments to http://bugs.freepascal.org/view.php? id=9472. The whole issue is discussed there in great detail. This is a huge problem. This code must work the same way in both cases but it does not. We are porting a huge library of over 4 million lines of code from Delphi. This is a major show stopper. I can probably take a look in the compiler as it will be much easier and faster for us to fix the compiler to be Delphi compatible rather than rewriting the libraries. They rely heavily on interfaces and the correct reference counting. Rewriting this even if desirable will delay the project with at least a year at best. By definition when there are no active references to an interface it must be released. This is a total failure of the functionality. There are active references, namely in an invisible temp. When this invisible temp is destroyed (at the function exit), the interface is freed. It is wrong to assume that implicit temps which still contain references to interfaces (or ansistrings, or any other reference counted type) can never exist, because this is an implementation detail over which the compiler has full control. This can also happen in Delphi under certain circumstances by the way (namely if it cannot guarantee that optimising the interface assignment is safe without using a temp). The purpose of automatic reference counting is simply that memory management is automated. It is not to guarantee the same semantics as what you would get in a manual reference counting scheme where you are in full control of when and where reference counts are increased and decreased. In principle, a periodic mark and sweep would also still be correct behaviour. Newer versions of FPC optimise assignments of function results more aggressively so you will more often get reference counting behaviour like in Delphi, but we do not guarantee in any way that it will be 100% identical. We only emulate the Delphi language, not the implementation details of the Delphi compiler or code generator. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
On Thu, 19 Jun 2008, Boian Mitov wrote: Hi Jonas, This functionality works in all versions of Delphi 5-2007. We support them all, and we have done so for years. We have no problems to compile with such optimizations turned off. We need proper reference counting. We have over 300 Delphi components in 5 released and 3 libraries under current development, spreading over 4 million lines of code. We are looking to port it to Linux, and other platforms. The Lazarus looks like the natural solution. We have no problems creating a clone of it, or developing alternative compiler from scratch. We plan to allow C++ users to also use the library, as we provide C++/MFC and .NET component wrappers to our customers. If we need to we can simply fix the compiler for our needs and sell only compiled C++ supporting versions, or if you agree to allow some override to the behavior we can support the Lazarus and free Pascal too. We believe that as one of the biggest component vendors in the world, our support for Lazarus will help the project a lot. However for that we crucially need this problem fixed. CodeGear has done fixes for us in the past, in order to help us continue to support the platform, as they have done for other vendors, and we are very, very grateful for that, and have help them (convert) many of our .NET customers. We will be equally grateful for any help you can offer in our attempts to support Lazarus. We believe this will only help the community, and the popularity of the product. I have downloaded the source, and I will see if we can tweak it and add some compiler option to support this somehow. You can take a look at our currently available products here : www.mitov.com , and yes, we are working to make all this available in Lazarus ;-) . It should IMHO not be too hard to make a switch -Osomething which forces immediate release of temps. That should ensure Delphi compatible behaviour - possibly at the cost of some performance. If you can provide a patch to implement such a switch, I'm pretty confident it will be included. But Jonas is correct in his statement that you are relying on some implementation detail which you should not rely on. That it works for you in Delphi is pure luck, and the right thing to do is to review your code. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Hi Michael, Thank you! I will be looking into the code, and see if I can add the functionality with some switch. We may redo the code, however it will probably take well over a year for fully rewriting it all, and it may not be necessarily a smart thing. Delphi unlike C++ does not have any form of function or block enclosement, and the interfaces are the closest thing to functional enclosement we have, aside from the error prone try/finally pair. If we lose it, we lose a major development tool :-( . It surely downgrades the Pascal language a notch. I hope however that sometime in the future we will finally have a real functional enclosement in Pascal, but who know ;-) . With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Michael Van Canneyt [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 5:00 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 It should IMHO not be too hard to make a switch -Osomething which forces immediate release of temps. That should ensure Delphi compatible behaviour - possibly at the cost of some performance. If you can provide a patch to implement such a switch, I'm pretty confident it will be included. But Jonas is correct in his statement that you are relying on some implementation detail which you should not rely on. That it works for you in Delphi is pure luck, and the right thing to do is to review your code. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Boian Mitov schrieb: I have downloaded the source, and I will see if we can tweak it and add some compiler option to support this somehow. If it would be that easy, we would have done it. It's simply a matter of the design of compiler/rtl how ref. counting is done. We must draw a border somewhere. The next step would be that people expect that procedures use only the registers delphi uses regardless of the calling conventions. Feel free to submit a patch if you can create one which don't break other stuff, we will gladly accept it, but I fear this is not easy. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
PS: It will help me a lot if you guys can at least pint me to what files I should be looking for to change the behavior of the temp ;-) . With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Michael Van Canneyt [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 5:00 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 If you can provide a patch to implement such a switch, I'm pretty confident it will be included. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
On 19 Jun 2008, at 13:53, Boian Mitov wrote: This functionality works in all versions of Delphi 5-2007. We support them all, and we have done so for years. We have no problems to compile with such optimizations turned off. One final time: please read the comments to http://bugs.freepascal.org/view.php?id=9472 . It's not an optimisation which needs to be turned off. On the contrary, you are depending on a particular optimisation to be performed (namely skipping the use of temporary function results when assigning the result of a function returning an interface to certain classes of local variables). The effects of this behaviour can also be emulated by clearing all temps immediately after their use, as Michael indicates, in which case you obviously get slower and much more bloated code (and make the compiler code itself also more complex). I repeat: there is absolutely nothing wrong with using a temporary function result in such situations, and depending on it not being used is an error in your code. Your program will also break under Delphi e.g. when you assign the interface result of a nested functions to a local variable and also access this variable from the nested function. You also have not explained why it is so crucial that the interfaces are immediately released. We need proper reference counting. There is proper reference counting: there are no memory leaks. That's really all that automatic reference counting guarantees. You may also want to have a look at http://wiki.freepascal.org/Code_Conversion_Guide#Semantical_differences for a couple more implementation differences between Delphi and FPC. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Boian Mitov schrieb: PS: It will help me a lot if you guys can at least pint me to what files I should be looking for to change the behavior of the temp ;-) . See my other mail, this requires not only a simple change in a few files. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Gee... Isn't it the reason we all love C++ ;-) . There all those things are standardized by the ANSI, and return variable temp must be alive only for the duration of the statement if you want to call your compiler ANSI ;-) . Then again, don't we all hate the lack of support for singletons in C++ :-D . There is no such thing as a perfect language... We will figure out a way out of this ;-) . With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Florian Klaempfl [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 5:10 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 If it would be that easy, we would have done it. It's simply a matter of the design of compiler/rtl how ref. counting is done. We must draw a border somewhere. The next step would be that people expect that procedures use only the registers delphi uses regardless of the calling conventions. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Thank you Florian, if needed, I will get couple of people to help me on this one. I appreciate your help! With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Florian Klaempfl [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 5:14 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 Boian Mitov schrieb: PS: It will help me a lot if you guys can at least pint me to what files I should be looking for to change the behavior of the temp ;-) . See my other mail, this requires not only a simple change in a few files. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
On Thu, 19 Jun 2008, Boian Mitov wrote: Hi Michael, Thank you! I will be looking into the code, and see if I can add the functionality with some switch. We may redo the code, however it will probably take well over a year for fully rewriting it all, and it may not be necessarily a smart thing. Delphi unlike C++ does not have any form of function or block enclosement, and the interfaces are the closest thing to functional enclosement we have, aside from the error prone try/finally pair. If we lose it, we lose a major development tool :-( . It surely downgrades the Pascal language a notch. I hope however that sometime in the future we will finally have a real functional enclosement in Pascal, but who know ;-) . I can see that you really want this feature, this is for sure. However, nowhere you write WHY you need this feature; The behaviour you seem to expect is wrong by definition. As stated: There are *no* leaks. The memory is freed at procedure exit; This is just a little later than what you expect. (you expect it right after the :=Nil;) So WHY do you expect/need this behaviour ? What architectural decision makes this necessary ? I am asking this because I find it hard to believe that you would write conciously code which really depends on this feature. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Jonas Maebe schrieb: On 19 Jun 2008, at 13:53, Boian Mitov wrote: This functionality works in all versions of Delphi 5-2007. We support them all, and we have done so for years. We have no problems to compile with such optimizations turned off. One final time: please read the comments to http://bugs.freepascal.org/view.php?id=9472. It's not an optimisation which needs to be turned off. On the contrary, you are depending on a particular optimisation to be performed (namely skipping the use of temporary function results when assigning the result of a function returning an interface to certain classes of local variables). The effects of this behaviour can also be emulated by clearing all temps immediately after their use, To do this correct, you need however an implicit try ... finally statement around the clearing. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Here is a code sniped that sows just one example of the problem: This is a very simple example of how important the order really is: We have even more crucial problems related with this. This is just a simple one: destructor TALBasicAudioOut.Destroy(); var WriteLock : IOWLockSection; begin WriteLock := FLock.StopLock(); FInputPin.Free(); FEnablePin.Free(); FMasterPumping.Free(); WriteLock := NIL; FLock.Free(); inherited; end; You can see that the WriteLock MUST be released before the FLock.Free();, otherwise you will have access violation, and this is a destructor, so the options are limited. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Michael Van Canneyt [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 5:16 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 On Thu, 19 Jun 2008, Boian Mitov wrote: Hi Michael, Thank you! I will be looking into the code, and see if I can add the functionality with some switch. We may redo the code, however it will probably take well over a year for fully rewriting it all, and it may not be necessarily a smart thing. Delphi unlike C++ does not have any form of function or block enclosement, and the interfaces are the closest thing to functional enclosement we have, aside from the error prone try/finally pair. If we lose it, we lose a major development tool :-( . It surely downgrades the Pascal language a notch. I hope however that sometime in the future we will finally have a real functional enclosement in Pascal, but who know ;-) . I can see that you really want this feature, this is for sure. However, nowhere you write WHY you need this feature; The behaviour you seem to expect is wrong by definition. As stated: There are *no* leaks. The memory is freed at procedure exit; This is just a little later than what you expect. (you expect it right after the :=Nil;) So WHY do you expect/need this behaviour ? What architectural decision makes this necessary ? I am asking this because I find it hard to believe that you would write conciously code which really depends on this feature. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Gee... Isn't it the reason we all love C++ ;-) . There all those things are standardized by the ANSI, and return variable temp must be alive only for the duration of the statement if you want to call your compiler ANSI ;-) . Then again, don't we all hate the lack of support for singletons in C++ :-D . There is no such thing as a perfect language... We will figure out a way out of this ;-) . Do you have pg numbers in Strousstrup? (I've 2nd ed) I'd be interested to read how standards describes such things. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
I will dig for it. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Marco van de Voort [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 5:29 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 Do you have pg numbers in Strousstrup? (I've 2nd ed) I'd be interested to read how standards describes such things. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Michael Van Canneyt schreef: On Thu, 19 Jun 2008, Boian Mitov wrote: Here is a code sniped that sows just one example of the problem: This is a very simple example of how important the order really is: We have even more crucial problems related with this. This is just a simple one: destructor TALBasicAudioOut.Destroy(); var WriteLock : IOWLockSection; begin WriteLock := FLock.StopLock(); FInputPin.Free(); FEnablePin.Free(); FMasterPumping.Free(); WriteLock := NIL; FLock.Free(); inherited; end; You can see that the WriteLock MUST be released before the FLock.Free();, Maybe Jonas or Florian can comment on this. When you said function blocks, it made me think of nested procedures. So I think you write it like: destructor TALBasicAudioOut.Destroy(); procedure DoWriteProtectedThings; var WriteLock : IOWLockSection; begin WriteLock := FLock.StopLock(); FInputPin.Free(); FEnablePin.Free(); FMasterPumping.Free(); end; begin DoWriteProtectedThings; FLock.Free(); inherited; end; Then you have made it clear that after WriteLock has to be cleared before freeing the lock. Of course it still fails if a periodic mark and sweep would be used by the compiler. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
I will see to ping somebody on the ANSI comity for this one. It takes forever to dig it out ;-) . I will let you know. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Boian Mitov [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 5:37 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 I will dig for it. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Marco van de Voort [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 5:29 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 Do you have pg numbers in Strousstrup? (I've 2nd ed) I'd be interested to read how standards describes such things. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
I will see to ping somebody on the ANSI comity for this one. It takes forever to dig it out ;-) . I will let you know. Thanks. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Boian Mitov schrieb: Here is a code sniped that sows just one example of the problem: This is a very simple example of how important the order really is: Unfortunatly, I can quote only from the german delphi help: Wenn Sie die Referenzzählung nutzen wollen, dürfen Sie das Objekt nur als Schnittstellenreferenz verwalten. It says, if you want to use the reference counting, you might store the class only as interface reference. I guess FLock is no interface? Further, how is in delphi ensured that WriteLock:=Nil; doesn't release FLock? We have even more crucial problems related with this. This is just a simple one: destructor TALBasicAudioOut.Destroy(); var WriteLock : IOWLockSection; begin WriteLock := FLock.StopLock(); FInputPin.Free(); FEnablePin.Free(); FMasterPumping.Free(); WriteLock := NIL; FLock.Free(); inherited; end; You can see that the WriteLock MUST be released before the FLock.Free();, The .Free is probably the error here. If FLock inherits from TInterfacedObject, calling release is the way to go. otherwise you will have access violation, and this is a destructor, so the options are limited. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Michael Van Canneyt [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 5:16 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 On Thu, 19 Jun 2008, Boian Mitov wrote: Hi Michael, Thank you! I will be looking into the code, and see if I can add the functionality with some switch. We may redo the code, however it will probably take well over a year for fully rewriting it all, and it may not be necessarily a smart thing. Delphi unlike C++ does not have any form of function or block enclosement, and the interfaces are the closest thing to functional enclosement we have, aside from the error prone try/finally pair. If we lose it, we lose a major development tool :-( . It surely downgrades the Pascal language a notch. I hope however that sometime in the future we will finally have a real functional enclosement in Pascal, but who know ;-) . I can see that you really want this feature, this is for sure. However, nowhere you write WHY you need this feature; The behaviour you seem to expect is wrong by definition. As stated: There are *no* leaks. The memory is freed at procedure exit; This is just a little later than what you expect. (you expect it right after the :=Nil;) So WHY do you expect/need this behaviour ? What architectural decision makes this necessary ? I am asking this because I find it hard to believe that you would write conciously code which really depends on this feature. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
On 19 Jun 2008, at 14:36, Michael Van Canneyt wrote: On Thu, 19 Jun 2008, Boian Mitov wrote: Here is a code sniped that sows just one example of the problem: This is a very simple example of how important the order really is: We have even more crucial problems related with this. This is just a simple one: destructor TALBasicAudioOut.Destroy(); var WriteLock : IOWLockSection; begin WriteLock := FLock.StopLock(); FInputPin.Free(); FEnablePin.Free(); FMasterPumping.Free(); WriteLock := NIL; FLock.Free(); inherited; end; You can see that the WriteLock MUST be released before the FLock.Free();, Maybe Jonas or Florian can comment on this. Reference counting only guarantees that a) an instance will not be freed as long as any references to it exist b) an instance will be freed automatically after the last reference disappears It does not guarantee/define a) at which point in the code exactly an instance will be freed b) the actual mechanism used for reclaiming the memory (a simple free when the reference count hits zero, mark and sweep, ...) It is therefore not a substitute for managing other kinds of resources which require predictable freeing points. The above example is conceptually identical to several of the examples given in the comments to http://bugs.freepascal.org/view.php?id=9472 It's similar to how you cannot use the Finalize method in Java to perform resource management, because it will only be called when the garbage collector reaps your instance and not necessarily immediately when the last reference to an instance is gone. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Hi Florian, FLock is not interface. There is no error with the FLock. WriteLock is interface, and I have to destroy it before I destroy the FLock. The order of destruction is obviously crucial. The error is the fact that WriteLock referenced object is not released when WriteLock is assigned to NIL. I have found a number of work arounds for this, but some will not work in more complex scenarious :-( . As I mentioned this is a very simple case where the bug is obvious. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Florian Klaempfl [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 5:54 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 Boian Mitov schrieb: Here is a code sniped that sows just one example of the problem: This is a very simple example of how important the order really is: Unfortunatly, I can quote only from the german delphi help: Wenn Sie die Referenzzählung nutzen wollen, dürfen Sie das Objekt nur als Schnittstellenreferenz verwalten. It says, if you want to use the reference counting, you might store the class only as interface reference. I guess FLock is no interface? Further, how is in delphi ensured that WriteLock:=Nil; doesn't release FLock? We have even more crucial problems related with this. This is just a simple one: destructor TALBasicAudioOut.Destroy(); var WriteLock : IOWLockSection; begin WriteLock := FLock.StopLock(); FInputPin.Free(); FEnablePin.Free(); FMasterPumping.Free(); WriteLock := NIL; FLock.Free(); inherited; end; You can see that the WriteLock MUST be released before the FLock.Free();, The .Free is probably the error here. If FLock inherits from TInterfacedObject, calling release is the way to go. otherwise you will have access violation, and this is a destructor, so the options are limited. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Michael Van Canneyt [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 5:16 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 On Thu, 19 Jun 2008, Boian Mitov wrote: Hi Michael, Thank you! I will be looking into the code, and see if I can add the functionality with some switch. We may redo the code, however it will probably take well over a year for fully rewriting it all, and it may not be necessarily a smart thing. Delphi unlike C++ does not have any form of function or block enclosement, and the interfaces are the closest thing to functional enclosement we have, aside from the error prone try/finally pair. If we lose it, we lose a major development tool :-( . It surely downgrades the Pascal language a notch. I hope however that sometime in the future we will finally have a real functional enclosement in Pascal, but who know ;-) . I can see that you really want this feature, this is for sure. However, nowhere you write WHY you need this feature; The behaviour you seem to expect is wrong by definition. As stated: There are *no* leaks. The memory is freed at procedure exit; This is just a little later than what you expect. (you expect it right after the :=Nil;) So WHY do you expect/need this behaviour ? What architectural decision makes this necessary ? I am asking this because I find it hard to believe that you would write conciously code which really depends on this feature. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
This is not very precise. You are referring to garbage collection in general. Reference counting as it used to be defined in the original COM specification for DLL and statically linked objects specifically states that the object will be destroyed as soon as the last reference to it is lost. The non deterministic garbage collector is the exact reason we don't have stable Java programs, and they al tend to leak, and crash the systems. There is no Garbage collection per say for resources, and there is no function enclosement either. .NET has number of ugly language extensions patches to work around that in C#, but this is a whole different story. To be able to work with resources we have to have a tight control over their lifespan. otherwise we are in a grave danger of crashes. We can surely revert to the old days of doing that with functional programming, as Java developers tend to do, but that has all the disadvantages and dangers of functional programming. OOP is supposed to assist us in writing safe code, not endanger us. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Jonas Maebe [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 5:55 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 Reference counting only guarantees that a) an instance will not be freed as long as any references to it exist b) an instance will be freed automatically after the last reference disappears It does not guarantee/define a) at which point in the code exactly an instance will be freed b) the actual mechanism used for reclaiming the memory (a simple free when the reference count hits zero, mark and sweep, ...) It is therefore not a substitute for managing other kinds of resources which require predictable freeing points. The above example is conceptually identical to several of the examples given in the comments to http://bugs.freepascal.org/view.php?id=9472 It's similar to how you cannot use the Finalize method in Java to perform resource management, because it will only be called when the garbage collector reaps your instance and not necessarily immediately when the last reference to an instance is gone. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
On Thu, 19 Jun 2008, Boian Mitov wrote: This is not very precise. You are referring to garbage collection in general. Reference counting as it used to be defined in the original COM specification for DLL and statically linked objects specifically states that the object will be destroyed as soon as the last reference to it is lost. That is exactly what is implemented. Just there is an invisible - to you - reference. You mix explicit with implicit memory management (Flock.Free). The Delphi help warns explicitly against this. (see Using reference counting) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Boian Mitov schrieb: Hi Florian, FLock is not interface. There is no error with the FLock. To which instance is WriteLock an interface? FLock? WriteLock is interface, and I have to destroy it before I destroy the FLock. The order of destruction is obviously crucial. The error is the fact that WriteLock referenced object is not released when WriteLock is assigned to NIL. I have found a number of work arounds for this, but some will not work in more complex scenarious :-( . As I mentioned this is a very simple case where the bug is obvious. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Michael, I never call Free() on interfaced object. I surely know that if I have used interfaces for the last 10 years or so ;-) . What I need is a way to make sure that all the references are gone. This is the first non garbage collected compiler that has prevented me from releasing all the references so far. Delphi, the C++ COM libraries VB etc. they all have behaved in a predictable way. Lazarus is the first surprise for me ;-) . There is always a first time however. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Michael Van Canneyt [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 6:14 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 The Delphi help warns explicitly against this. (see Using reference counting) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Hi Marco, I have found it :-) This is one of the draft, but that part has hardly changed: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf Page 244 Item 3 describes the lifespan of a temporary object in expression (rvalue life span): 3 When an implementation introduces a temporary object of a class that has a non-trivial constructor (12.1, 12.8), it shall ensure that a constructor is called for the temporary object. Similarly, the destructor shall be called for a temporary with a non-trivial destructor (12.4). Temporary objects are destroyed as the last step in evaluating the full-expression (1.9) that (lexically) contains the point where they were created. This is true even if that evaluation ends in throwing an exception. The value computations and side effects of destroying a temporary object are associated only with the full-expression, not with any specific subexpression. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Marco van de Voort [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 5:54 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 I will see to ping somebody on the ANSI comity for this one. It takes forever to dig it out ;-) . I will let you know. Thanks. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Boian Mitov schrieb: Michael, I never call Free() on interfaced object. I surely know that if I have used interfaces for the last 10 years or so ;-) . See my other mail. You do a WriteLock:=FLock.StopLock(); call. Every interface is associated with a class instance. With which class instance is WriteLock associated? What I need is a way to make sure that all the references are gone. This is the first non garbage collected compiler that has prevented me from releasing all the references so far. Delphi, the C++ COM libraries VB etc. they all have behaved in a predictable way. Lazarus is the first surprise for me ;-) . There is always a first time however. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Michael Van Canneyt [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 6:14 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 The Delphi help warns explicitly against this. (see Using reference counting) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
function TOWLock.StopLock() : IOWLockSection; begin Result := TOWSimpleStopLockSection.Create( Self ); end; This is a completely different object. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Florian Klaempfl [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 6:27 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 Boian Mitov schrieb: Michael, I never call Free() on interfaced object. I surely know that if I have used interfaces for the last 10 years or so ;-) . See my other mail. You do a WriteLock:=FLock.StopLock(); call. Every interface is associated with a class instance. With which class instance is WriteLock associated? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
No,
function TOWLock.StopLock() : IOWLockSection;
{$ENDIF}
begin
Result := TOWSimpleStopLockSection.Create( Self );
end;
With best regards,
Boian Mitov
Mitov Software
http://www.mitov.com
- Original Message -
From: Florian Klaempfl [EMAIL PROTECTED]
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Thursday, June 19, 2008 6:16 AM
Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Boian Mitov schrieb:
Hi Florian,
FLock is not interface. There is no error with the FLock.
To which instance is WriteLock an interface? FLock?
WriteLock is interface, and I have to destroy it before I destroy the
FLock. The order of destruction is obviously crucial.
The error is the fact that WriteLock referenced object is not released
when WriteLock is assigned to NIL. I have found a number of work arounds
for this, but some will not work in more complex scenarious :-( . As I
mentioned this is a very simple case where the bug is obvious.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Hi Marco,
You are wrong. They mean expression not block!
This is one block with 3 expressions:
{
a = 3 + 4;
b = 5 + 3;
c = 3 + 7;
}
If an temporary variable is created it must be destroyed before the ;
symbol, not at the end of the block!
This is vary good as it prevent any optimization to break your code ;-) .
You know exactly where the destructor will be called on any ANSI C++
compiler in the world. This is the reason C++ remains my favorite language
regardless of the many issues it has. It is 100% defined, and you know 100%
what it will do ;-) .
With best regards,
Boian Mitov
Mitov Software
http://www.mitov.com
- Original Message -
From: Marco van de Voort [EMAIL PROTECTED]
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Thursday, June 19, 2008 6:31 AM
Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Page 244
Item 3 describes the lifespan of a temporary object in expression (rvalue
life span):
Ah, but this is a compiler generated object as result value. I'm still
surprised btw that they omit this possible optimization (e.g. destruction
with the frame), but that is probably related with the need to have the
compiler always honor nested { } blocks.
Anyway, that is something else then a explicitely declared interface
reference as we have here, so one needs a different example.
What comes close to an interface in behaviour in C++, smart pointers?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Boian Mitov schrieb: Hi Marco, You are wrong. They mean expression not block! This path of the discussion is useless. As soon as you make WriteLock a global/static var, delphi behaves the same as fpc: it creates a temp. ref. which is only cleaned at procedure exit. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Hi Florian, Thank you! This is false! In Delphi the interface is released immediately. Before you make such statement I advise you to verify the Delphi behavior. I can ensure you that D5, 6, 7, 2005, 2006, 2007 as well as BCB 5, 6, 2006, and 2007 will release the object before the end of the block. FPC behaves completely different way. As the best of my understanding they have implemented the TMP the same way as it is described in the ANSI C++ standard, but if you wish I can ask them. I will be meeting the CodeGear guys next week, and I can chat with them on that. The information I provided was for the ANSI standard as the guy was interested how they have defined it ;-) . With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Florian Klaempfl [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 6:42 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 Boian Mitov schrieb: Hi Marco, You are wrong. They mean expression not block! This path of the discussion is useless. As soon as you make WriteLock a global/static var, delphi behaves the same as fpc: it creates a temp. ref. which is only cleaned at procedure exit. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
On 19 Jun 2008, at 15:20, Boian Mitov wrote: never call Free() on interfaced object. I surely know that if I have used interfaces for the last 10 years or so ;-) . What I need is a way to make sure that all the references are gone. This is the first non garbage collected compiler that has prevented me from releasing all the references so far. Delphi, the C++ COM libraries VB etc. they all have behaved in a predictable way. Delphi doesn't, look at this example: *** uses SysUtils; type imyintf = interface function getrefcount: longint; end; tmyclass = class(tinterfacedobject,imyintf) function getrefcount: longint; end; function tmyclass.getrefcount: longint; begin result:=refcount; end; procedure test; var i: imyintf; function test2: imyintf; begin result:=tmyclass.create; writeln(i.getrefcount); end; begin i:=tmyclass.create; i:=test2; writeln(i.getrefcount); end; begin test; end. *** The output is (when compiled with Kylix 3): refcount of i in test2: 1 refcount of i after calling test2: 2 If you comment out the writeln in test2, then the result is: refcount of i after calling test2: 1 The reason is that if you access i inside test2, then Delphi cannot perform the optimisation of skipping the temp, and it also only frees the temp at the end of the function. The behaviour you are counting on is a side effect of an optimisation, not a behaviour by design. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Boian Mitov schrieb:
Hi Florian,
Thank you!
This is false! In Delphi the interface is released immediately.
No.
Before
you make such statement I advise you to verify the Delphi behavior.
I did so because I discussed this behaviour several times before. Just
compare the output of and explain me your theory about it:
type
tclass1 = class(TInterfacedObject)
destructor destroy;override;
end;
destructor tclass1.destroy;
begin
writeln('destroyed');
inherited;
end;
function f : IInterface;
begin
f:=tclass1.create;
end;
var
i : IInterface;
procedure p;
begin
i:=f;
i:=nil;
writeln('exiting');
end;
begin
p;
writeln('back');
end.
and
type
tclass1 = class(TInterfacedObject)
destructor destroy;override;
end;
destructor tclass1.destroy;
begin
writeln('destroyed');
inherited;
end;
function f : IInterface;
begin
f:=tclass1.create;
end;
procedure p;
var
i : IInterface;
begin
i:=f;
i:=nil;
writeln('exiting');
end;
begin
p;
writeln('back');
end.
I
can ensure you that D5, 6, 7, 2005, 2006, 2007 as well as BCB 5, 6,
2006, and 2007 will release the object before the end of the block.
No.
FPC
behaves completely different way. As the best of my understanding they
have implemented the TMP the same way as it is described in the ANSI C++
standard, but if you wish I can ask them. I will be meeting the CodeGear
guys next week, and I can chat with them on that.
The information I provided was for the ANSI standard as the guy was
interested how they have defined it ;-) .
With best regards,
Boian Mitov
Mitov Software
http://www.mitov.com
- Original Message - From: Florian Klaempfl
[EMAIL PROTECTED]
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Thursday, June 19, 2008 6:42 AM
Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Boian Mitov schrieb:
Hi Marco,
You are wrong. They mean expression not block!
This path of the discussion is useless. As soon as you make WriteLock
a global/static var, delphi behaves the same as fpc: it creates a
temp. ref. which is only cleaned at procedure exit.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Florian Klaempfl schrieb: Jonas Maebe schrieb: The behaviour you are counting on is a side effect of an optimisation, not a behaviour by design. Oh, btw: fpc 2.2.2rc1 behaves with -O2 like delphi :) Without -O2 like 2.2.0 :) Add: I just realized that Peter implemented this some time ago in a in most cases (!) delphi compatible behaviour. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Hi Jonas, Delphi seems to be a fairly good player in terms of this behavior. I have been using interfaces for many years, and they have worked as expected. You can verify this with the code snipped from the bug report. I am excited however by the last Florian post. I will have to figure out how to configure the Lazarus packages, and how to upgrade to rc 1 etc if needed, but it is very promising :-) . With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Jonas Maebe [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 6:51 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 Delphi doesn't, look at this example: ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
On 19 Jun 2008, at 16:06, Florian Klaempfl wrote: Florian Klaempfl schrieb: Jonas Maebe schrieb: The behaviour you are counting on is a side effect of an optimisation, not a behaviour by design. Oh, btw: fpc 2.2.2rc1 behaves with -O2 like delphi :) Without -O2 like 2.2.0 :) Add: I just realized that Peter implemented this some time ago in a in most cases (!) delphi compatible behaviour. Indeed: e.g., if you compile the example I posted with the writeln in test2 commented out, then Delphi will write out 1 as refcount later on and FPC still 2. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Boian Mitov schrieb: Thank you! I will see to get the 2.2.2rc1 and compile with the switch :-) . I will validate if it behaves the same way and will let you know :-) . I am very excited that there could be a ready solution :-) . I still recommend that you think about changing your design, see Jonas' and my mail why. In our opinion your code works by accident. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
I understand and appreciate your input. If needed I will tweak some places of the library. This is not problem. We have done some other changes as well. As long as in most cases it works well we are happy ;-) . Porting all of our products will take months of work and effort, but we are committed. When we have it ported I will make sure you guys get a full source code commercial licenses ;-) . With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Florian Klaempfl [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 7:06 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 Florian Klaempfl schrieb: Jonas Maebe schrieb: The behaviour you are counting on is a side effect of an optimisation, not a behaviour by design. Oh, btw: fpc 2.2.2rc1 behaves with -O2 like delphi :) Without -O2 like 2.2.0 :) Add: I just realized that Peter implemented this some time ago in a in most cases (!) delphi compatible behaviour. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Hmm... Florian, I seem to be finding only downloads for 2.2.0 . Where I can get 2.2.2rc1 ? With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Florian Klaempfl [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 7:09 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 Boian Mitov schrieb: Thank you! I will see to get the 2.2.2rc1 and compile with the switch :-) . I will validate if it behaves the same way and will let you know :-) . I am very excited that there could be a ready solution :-) . I still recommend that you think about changing your design, see Jonas' and my mail why. In our opinion your code works by accident. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
On Thu, 19 Jun 2008, Boian Mitov wrote: Hmm... Florian, I seem to be finding only downloads for 2.2.0 . Where I can get 2.2.2rc1 ? See download link on www.freepascal.org main page, first (english) news item. Michael. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Florian Klaempfl [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 7:09 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 Boian Mitov schrieb: Thank you! I will see to get the 2.2.2rc1 and compile with the switch :-) . I will validate if it behaves the same way and will let you know -) :. I am very excited that there could be a ready solution :-) . I still recommend that you think about changing your design, see Jonas' and my mail why. In our opinion your code works by accident. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
The FTP server seems really slow to respond. Do you want me to setup an FTP account for you guys on one of my servers, so you can upload in the future Beta stuff there for easier access for everybody? With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Michael Van Canneyt [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 7:35 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 On Thu, 19 Jun 2008, Boian Mitov wrote: Hmm... Florian, I seem to be finding only downloads for 2.2.0 . Where I can get 2.2.2rc1 ? See download link on www.freepascal.org main page, first (english) news item. Michael. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Florian Klaempfl [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 7:09 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 Boian Mitov schrieb: Thank you! I will see to get the 2.2.2rc1 and compile with the switch :-) . I will validate if it behaves the same way and will let you know -) :. I am very excited that there could be a ready solution :-) . I still recommend that you think about changing your design, see Jonas' and my mail why. In our opinion your code works by accident. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
On Thu, 19 Jun 2008, Boian Mitov wrote: The FTP server seems really slow to respond. Do you want me to setup an FTP account for you guys on one of my servers, so you can upload in the future Beta stuff there for easier access for everybody? There are many mirrors; The main site just points to the main one, you can simply pick any mirror and browse through the FTP site. But a new mirror is always welcome. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Hi Michael, Finally the server responded. This file is not on the mirrors :-( . It is only on the FTP. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Michael Van Canneyt [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 8:16 AM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 On Thu, 19 Jun 2008, Boian Mitov wrote: The FTP server seems really slow to respond. Do you want me to setup an FTP account for you guys on one of my servers, so you can upload in the future Beta stuff there for easier access for everybody? There are many mirrors; The main site just points to the main one, you can simply pick any mirror and browse through the FTP site. But a new mirror is always welcome. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
On Thu, 19 Jun 2008, Boian Mitov wrote: Hi Michael, Finally the server responded. This file is not on the mirrors :-( . It is only on the FTP. Strange, I would think that the FTP mirrors picked it up by now ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Hi Michael, Maybe I was looking at the wrong place. I was looking at SourceForge initially, and saw 2.2.0 files only. I am still learning where the FreePascal files and resources are, so it could be my fault. Maybe they ware picking it and that is why it took me 50 minutes just to open the FTP directory ;-) . With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Michael Van Canneyt [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 19, 2008 12:41 PM Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472 Strange, I would think that the FTP mirrors picked it up by now ? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
