Re: [fpc-devel] State of extended RTTI
Hi All, We have developed an advanced RTTI API that replaces the Embarcadero RTTI API and provides much more powerful and easy to use when accessing the RTTI. We developed it as we ware running into huge number of issues and bugs when trying to use the Embarcadero implementation, and we needed stable, robust and very easy to use implementation, since we have started to rely very heavily on the new RTTI in our development. It also offers additional functionalities not currently available in the Embarcadero extended RTTI, as well as we are doing some work around for critical bugs in the Delphi RTTI unit. If there is interest in adding extended RTTI support in FPC, i am willing to donate the API, and its implementation to the effort if it is deemed a good fit. Who is working on the RTTI at the moment? I can send him/her/them the RTTI unit for evaluation. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Maciej Izak Sent: Monday, February 18, 2013 9:04 AM To: FPC developers' list Subject: Re: [fpc-devel] State of extended RTTI Can I help? Info about good implementation of TValue - http://www.cromis.net/blog/2013/02/tanyvalue-an-attempt-to-make-the-best-variable-data-container/ Has FPC some equivalent of invoke from rtti.pas (dynamically invoking a methods and procedures/functions)? If not - I have my own basic implementation (for stdcall, register and cdecl) based on PascalScript calling engine. Regards, HNB 2013/2/10 Sven Barth : On 10.02.2013 14:19, Maciej Izak wrote: Hi, What is the state of Extended RTTI (like in Delphi 2010 and up)? You can read in the comment by Sven "One of the developers has started to implement class attributes and I’m rather sure that the enhanced RTTI will come sooner or later as well" http://www.deltics.co.nz/blog/?p=1129 How's he doing? Class attributes is still being worked on in a branch (by Joost). I personally plan to work on generics the next time (fixing bugs and adding support for generic methods). After that I plan to tackle extended RTTI if no one implements it before me. Regards, Sven ___ 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] State of extended RTTI
Hi Sven, It is an abstraction API that on the low side is 100% compatible with the Delphi API, as it uses it to access the information, but on the user side presents extremely easy to use API. It is probably better than anything available in the world at the moment, and light years ahead of both the Microsoft .NET RTTI API and the Embarcadero RTTI API. Being abstraction layer it also can be hooked on anything you have on the back end without breaking the code. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Sven Barth Sent: Monday, February 18, 2013 11:37 AM To: fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] State of extended RTTI On 18.02.2013 20:30, Boian Mitov wrote: How compatible to Delphi's API is your API? If it is not compatible, then it would not be of much use to us. Please note that we would in any case only use the API itself, as we might not implement the binary layout of the RTTI necessarily the same as Delphi did. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] State of extended RTTI
Hi Leonardo, At the moment we are only replacing some of the buggy parts of the catching in the Emb. RTTI. We are also working to get it to perform faster than the Delphi RTTI by implementing our own caching mechanisms. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Leonardo M. Ramé Sent: Monday, February 18, 2013 11:39 AM To: FPC developers' list Subject: Re: [fpc-devel] State of extended RTTI Hi Boian, did you have to modify/patch the compiler, or it is implemented as a set of classes?. Leonardo M. Ramé http://leonardorame.blogspot.com ___ 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] State of extended RTTI
As example this enumerates all attributes of certain type for any public or published member (function, field, or property) for a component: for LMember in TRTRtti.GetType( Component.ClassType() ).GetMembers( [mvPublic, mvPublished] ) do for LAtrribute in LMember.GetAttributes( TMyCustomAttributeType, True ) do You can see how much can be achieved with almost no code :-D and this is just the tip of the iceberg ;-) . It supports filtering with lambdas, and in general is designed in the principles of functional programming, so you can as example filter like this: AAttributes := TRTRtti.GetType( Component.ClassType() ).GetCustomAttributes( TVLCommonFilterHostedPreviewAttribute, True ); for AAttribute in AAttributes do if( AAttribute is TLPComponentEditorAttribute ) then begin AAttrItem := GComponentEditorAttributeList.Find( function( AItem : IComponentEditorAttributeItem ) : Boolean var AAttributes : IRTAttributes; AAttributeClass : TCustomAttributeClass; begin AAttributeClass := AItem.GetInstance().AttributeClass; AAttributes := TRTRtti.GetType( Component.ClassType() ).GetCustomAttributes( TLPSuppressAttributeAttribute, True ); if( AAttributes.Find( function ( ASupressAttribute : TCustomAttribute ) : Boolean begin Result := ( AAttributeClass = TLPSuppressAttributeAttribute( ASupressAttribute ).Attribute ); end ) <> NIL ) then Exit( False ); Result := ( AAttribute is AAttributeClass ); end ); Exit( AAttrItem.GetInstance().ComponentEditor.Create( Component, Designer )); end; This actually is a real piece of code from a place we use the new RTTI ;-) With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Boian Mitov Sent: Monday, February 18, 2013 11:49 AM To: FPC developers' list Subject: Re: [fpc-devel] State of extended RTTI Hi Sven, It is an abstraction API that on the low side is 100% compatible with the Delphi API, as it uses it to access the information, but on the user side presents extremely easy to use API. It is probably better than anything available in the world at the moment, and light years ahead of both the Microsoft .NET RTTI API and the Embarcadero RTTI API. Being abstraction layer it also can be hooked on anything you have on the back end without breaking the code. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Sven Barth Sent: Monday, February 18, 2013 11:37 AM To: fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] State of extended RTTI On 18.02.2013 20:30, Boian Mitov wrote: How compatible to Delphi's API is your API? If it is not compatible, then it would not be of much use to us. Please note that we would in any case only use the API itself, as we might not implement the binary layout of the RTTI necessarily the same as Delphi did. ___ 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] State of extended RTTI
I think they (FPC) have added their own implementation. Haven’t looked in more details, but saw some code posted, and I think they had a different implementation than Emb., using the lambda keyword. In any case at some point it will have to be adopted one way or another, as it helps tremendously in reducing and improving the code. We decided to ditch support for any version of Delphi older than XE2 mainly because of the enormous power of the Lambdas, and the bugs in the XE implementation (a lot of internal compiler errors). With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: Kostas Michalopoulos Sent: Tuesday, February 19, 2013 5:36 AM To: FPC developers' list Subject: Re: [fpc-devel] State of extended RTTI AFAIK FPC doesn't support lambdas (yet?) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] State of extended RTTI
Hi Sven, Thank you! I actually find "anonymous method" more verbose than "lambda" in a sentence :-D . Then the FPC is really way behind almost any other language :-( . Even C++ added native anonymous methods in C++11, and other languages have had them for many years :-( . I can't even imagine my development without them in Delphi any more, I mean they really revolutionized my code, and allowed me to do things I have never imagined before. Together with Attributes, and the new RTTI this is the biggest revolution in Delphi, and transforms it into totally different language. Now I can get something done with 4-5 lines of code which otherwise would have required hundreds of lines and declaration of a whole bunch of additional support classes and code. I mean this is a whole new ballgame altogether! It is even bigger than the Object Oriented programming was when it was introduced! With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Sven Barth Sent: Tuesday, February 19, 2013 1:18 PM To: fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] State of extended RTTI On 19.02.2013 18:05, Boian Mitov wrote: No, FPC does currently not support anonymous functions (please don't call them Lambdas... at least not with that verbose syntax ;) ). We have a branch where an independant developer started to work on them, but development there has stalled. What you might have seen recently on this list was a discussion about a potential improvement of the syntax (less verbose for simpler cases). Regards, Sven ___ 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] Delphi anonymous methods
Hi Vasiliy, Just some additional info in case you are not aware. Delphi implements the anonymous methods as interfaces, and that is how it keeps them alive. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Vasiliy Kevroletin Sent: Saturday, March 02, 2013 9:08 PM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods Now I can answer my question myself. *Local variables of anonymous method are located on stack*. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Strongly disagree. Anonymous methods are a critical feature of any mother language, and allow vast improvements of the code and the readability. I recently started rewriting our libraries with anonymous methods and that alone allowed for cutting over 2 lines of code, while adding vast number of new features. Any language that does not support anonymous methods is just a joke IMHO. If you have never developed with them, (as was I), you never know what you have been missing. They are actually more important than having object oriented support IMHO. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From what I can see, anonymous methods are just like the above code... allowing a declaration of a procedure/method in-line inside a code block where in shouldn't belong. It is very, very un-Pascal like. The end result is unreadable code, probably hard to debug etc. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Yes, really! Then again this is over 4 mln mines of code after all. :-D Thank you for letting me know what closure is :-D . Can you imagine, me being component vendor for over 16 years and not knowing what closure is :-D. Anonymous methods lead to a different way of thinking altogether and allow you to do things that you can't even imagine with closures ;-) . And they make the code infinitely easier to read, especially if like me this is a huge codebase ;-) . After all we sell well over 400 components not to mention some of our other Delphi based products ;-) . Sure, if you have small code you can do just fine with closures, as I have for many years, then again I did just fine without having classes, and objects in the old days, and also did fine in the older days in Assembler :-D . So according to this logic, we really should be doing everything in machine code (as I actually did briefly 24 years ago :-D ), who needs new features such as those whatmacallit... ohhh yeahh... "compilers" :-D . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Martin Sent: Sunday, March 03, 2013 7:38 PM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods On 04/03/2013 01:47, Boian Mitov wrote: Really, just by dropping the names? Or did you mean, you did all that by using closures? Closures, do not need to be written/declared in the middle of other code (in-line) ___ 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] Delphi anonymous methods
Actually the biggest benefit was that it now allows me to design parallel execution code of complexity I was not able to design otherwise. I am just starting to scratch the surface. Hell... I have not even started really using the anonymous methods yet :-D . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Martin Sent: Sunday, March 03, 2013 7:38 PM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods On 04/03/2013 01:47, Boian Mitov wrote: Really, just by dropping the names? Or did you mean, you did all that by using closures? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
100% agree "revolutionary" is a very good word to describe it indeed! :-) . I remember people asking in the old days, why we need objects. Those ware old school Pascal people claiming that they can do just fine with records, and who needs classes :-D . They ware so un Pascal ! :-D . I am not kidding, I really new such people personally :-D . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Alexander Klenin Sent: Sunday, March 03, 2013 7:59 PM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods These are all "revolutionary" features that were introduced to the language at various stages of its development -- some at the inception, some later. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Here is example: Parallel execution with selection of executor: for i := 0 to AMaxScaleIndex - 1 do begin APerIterationLocations.Add( TRTDynamicList.Create() ); AExecutionTask.Add( AExecutor.Execute( procedure() begin ProcessOne( levelScale[ i ], img, hitThreshold, winStride, padding, APerIterationLocations[ i ] ); end )); end; In this case, not only you save declaration, you save the need to write a whole new class just for the task. This code reduced well over 30 lines of code alone. I have a lot of other examples as well ;-) . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Martin Sent: Sunday, March 03, 2013 8:42 PM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods On 04/03/2013 03:49, Boian Mitov wrote: Well I give you the benefit of the doubt, and believe you. But that does not help me, because I still do not know which case you are talking about So for my benefit, please enlighten me with an example. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
One thing for sure, I probably will very much never need to declare TThread inherited classes. I can use a single anonymous method for that, thanks to the ability of the anonymous method to capture local and member variables. This is something not doable with closure as it has fixed number of parameters ;-) . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Boian Mitov Sent: Sunday, March 03, 2013 8:54 PM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods Here is example: Parallel execution with selection of executor: for i := 0 to AMaxScaleIndex - 1 do begin APerIterationLocations.Add( TRTDynamicList.Create() ); AExecutionTask.Add( AExecutor.Execute( procedure() begin ProcessOne( levelScale[ i ], img, hitThreshold, winStride, padding, APerIterationLocations[ i ] ); end )); end; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Here is another even simpler example: AItem := GComponentEditorList.Find( function( AItem : IComponentEditorItem ) : Boolean begin Result := ( AComponent is AItem.GetInstance().ComponentClass ); end ); In this case you will either need additional member class variable (It will increase the memory usage), or you will need to declare a whole class just to achieve what I do with one line of code :-) . Sweet! :-) With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Martin Sent: Sunday, March 03, 2013 8:42 PM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods On 04/03/2013 03:49, Boian Mitov wrote: Yes, really! Then again this is over 4 mln mines of code after all. :-D Thank you for letting me know what closure is :-D . Can you imagine, me being component vendor for over 16 years and not knowing what closure is :-D. Did I? Wow, I didn't know I did. Didn't mean to neither. I was just checking, if you accidentally used the wrong word. (Happens to everyone, even the very best / so no judgement implied) Anonymous methods lead to a different way of thinking altogether and allow you to do things that you can't even imagine with closures ;-) . And they make the code infinitely easier to read, especially if like me this is a huge codebase ;-) . After all we sell well over 400 components not to mention some of our other Delphi based products ;-) . Sure, if you have small code you can do just fine with closures, as I have for many years, then again I did just fine without having classes, and objects in the old days, and also did fine in the older days in Assembler :-D . So according to this logic, we really should be doing everything in machine code (as I actually did briefly 24 years ago :-D ), who needs new features such as those whatmacallit... ohhh yeahh... "compilers" :-D . Well I give you the benefit of the doubt, and believe you. But that does not help me, because I still do not know which case you are talking about So for my benefit, please enlighten me with an example. From your above statement, I take, that you already used closures, and that the big improvements really happened of a result of anonymous methods. Just to be save, let me state the obvious: We are talking of dropping the function name; and introducing the ability, to declare the function anywhere within the code (probably the latter being the important). That are the 2 only things, that anonymous methods do offer? (OR am I missing anything?) If so then I do not see how they save 2 lines? - The name is part of the declaration line, SO it should not affect the line count at all). Unless you always write the name on a separate line (which I would consider a very special case) - the place of declaration also does not change the line count. -Original Message- From: Martin Sent: Sunday, March 03, 2013 7:38 PM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods On 04/03/2013 01:47, Boian Mitov wrote: Really, just by dropping the names? Or did you mean, you did all that by using closures? Closures, do not need to be written/declared in the middle of other code (in-line) ___ 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] Delphi anonymous methods
Or even more drastic example like this one: AAttributes := TRTRtti.GetType( Component.ClassType() ).GetCustomAttributes( TVLCommonFilterHostedPreviewAttribute, True ); for AAttribute in AAttributes do if( AAttribute is TLPComponentEditorAttribute ) then begin AAttrItem := GComponentEditorAttributeList.Find( function( AItem : IComponentEditorAttributeItem ) : Boolean var AAttributes : IRTAttributes; AAttributeClass : TCustomAttributeClass; begin AAttributeClass := AItem.GetInstance().AttributeClass; AAttributes := TRTRtti.GetType( Component.ClassType() ).GetCustomAttributes( TLPSuppressAttribute, True ); if( AAttributes.Find( function ( ASupressAttribute : TCustomAttribute ) : Boolean begin Result := ( AAttributeClass = TLPSuppressAttribute( ASupressAttribute ).Attribute ); end ) <> NIL ) then Exit( False ); Result := ( AAttribute is AAttributeClass ); end ); Exit( AAttrItem.GetInstance().ComponentEditor.Create( Component, Designer )); end; Try to write this without anonymous methods ;-) :-D . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Martin Sent: Sunday, March 03, 2013 8:42 PM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods On 04/03/2013 03:49, Boian Mitov wrote: Yes, really! Then again this is over 4 mln mines of code after all. :-D Thank you for letting me know what closure is :-D . Can you imagine, me being component vendor for over 16 years and not knowing what closure is :-D. Did I? Wow, I didn't know I did. Didn't mean to neither. I was just checking, if you accidentally used the wrong word. (Happens to everyone, even the very best / so no judgement implied) Anonymous methods lead to a different way of thinking altogether and allow you to do things that you can't even imagine with closures ;-) . And they make the code infinitely easier to read, especially if like me this is a huge codebase ;-) . After all we sell well over 400 components not to mention some of our other Delphi based products ;-) . Sure, if you have small code you can do just fine with closures, as I have for many years, then again I did just fine without having classes, and objects in the old days, and also did fine in the older days in Assembler :-D . So according to this logic, we really should be doing everything in machine code (as I actually did briefly 24 years ago :-D ), who needs new features such as those whatmacallit... ohhh yeahh... "compilers" :-D . Well I give you the benefit of the doubt, and believe you. But that does not help me, because I still do not know which case you are talking about So for my benefit, please enlighten me with an example. From your above statement, I take, that you already used closures, and that the big improvements really happened of a result of anonymous methods. Just to be save, let me state the obvious: We are talking of dropping the function name; and introducing the ability, to declare the function anywhere within the code (probably the latter being the important). That are the 2 only things, that anonymous methods do offer? (OR am I missing anything?) If so then I do not see how they save 2 lines? - The name is part of the declaration line, SO it should not affect the line count at all). Unless you always write the name on a separate line (which I would consider a very special case) - the place of declaration also does not change the line count. -Original Message- From: Martin Sent: Sunday, March 03, 2013 7:38 PM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods On 04/03/2013 01:47, Boian Mitov wrote: Really, just by dropping the names? Or did you mean, you did all that by using closures? Closures, do not need to be written/declared in the middle of other code (in-line) ___ 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] Delphi anonymous methods
What people don't usually realize is that an anonymous method indeed is internally expanded to a full blown object of unique class, with member variables and all. Indeed I use the anonymous methods to effectively declare a new class and make instance of it right in place with only couple of lines of code. In most cases anonymous methods effectively eliminate the need to declare new class for certain purpose. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Boian Mitov Sent: Sunday, March 03, 2013 9:06 PM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods Here is another even simpler example: AItem := GComponentEditorList.Find( function( AItem : IComponentEditorItem ) : Boolean begin Result := ( AComponent is AItem.GetInstance().ComponentClass ); end ); In this case you will either need additional member class variable (It will increase the memory usage), or you will need to declare a whole class just to achieve what I do with one line of code :-) . Sweet! :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Thank you! I am sorry, got overexcited. I like the lambda proposal, but on the other hand, I have to use Delphi (at least for now). The "advantage" of the Delphi implementation is that it uses "familiar" "Pascal like" syntax, but I am sure we can get used to the "lambda" syntax. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Alexander Klenin Sent: Sunday, March 03, 2013 9:11 PM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods On Mon, Mar 4, 2013 at 4:06 PM, Boian Mitov wrote: Note that with proposed "lambda" syntax this will be even shorter: AItem := GComponentEditorList.Find( lambda TComponentEditorListFilter as AComponent is AItem.GetInstance().ComponentClass; ); P. S. Boian, could you please stop top-posting and splitting your thoughts into so many emails? It will make discussion much easier to follow. -- Alexander S. Klenin ___ 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] Delphi anonymous methods
It may be a good idea to analyze the current Delphi implementation. In essence the anonymous method expands to a class and interface. The interface Execute method has the parameters of the anonymous function. and the corresponding interface has the Execute method. The class contains all the variables that are captured from the current context, and the constructor of the class does the capture. The class is reference counted trough the interface, and is disposed when all references are released. There are some interesting side effects and benefits from the implementation, and there are fear number of articles about that on the web. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Alexander Klenin Sent: Sunday, March 03, 2013 9:57 PM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods On Mon, Mar 4, 2013 at 2:38 PM, Martin wrote: Nevertheless, I agree what the implementation plan can be detailed even further: 1) Anonymous procedures *without* closures -- basically, just another syntax for nested procedures. This is an important step for several reasons: ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Ye, by writing 20 times more code for the same. What here I can do with 3 lines, otherwise needs declaration of a new class, new interface and new instance of the class. So what I can do here i 15 seconds would take me 1 hour to do traditionally. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Martin Sent: Monday, March 04, 2013 3:35 AM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods On 04/03/2013 06:06, Boian Mitov wrote: All fine and good. But all that can be done with a *named* closure too ___ 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] Delphi anonymous methods
Thank you Michael, This is a good advise :-) . I guess I really should stop using Delphi in the future :-) . I am surely not using FPC and staying with Delphi for now, but I appreciate your advise. Having less people use the language is the way to go :-D . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Michael Van Canneyt Sent: Monday, March 04, 2013 4:23 AM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods IMHO this is a pefectly acceptable solution. Adds only a modifier (modifiers are not keywords) and offers all advantages of closures. No need for 'anonymous' procedures, which are very unpascal-ish. People who want that should not be using Pascal to begin with. 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] Delphi anonymous methods
I actually somewhat agree with that, except it is less readable since you can't follow the code flow in place but have to scroll up to see what will happen (in for each as example.) Other than being more difficult to read it is otherwise the same. If you can also pass pointers to it that exist after the function is exited, then it is virtually equivalent. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Michael Van Canneyt Sent: Monday, March 04, 2013 9:03 AM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods On Mon, 4 Mar 2013, Boian Mitov wrote: This is not correct. For anonymous functions you do not need to declare a new class. Just name a local method. That means move a line, and put a name in front of it. No more, no less. 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] Delphi anonymous methods
Actually you are right indeed. I would spill a secret now. I have actually been working on a new language for a while, although it indeed will not only have anonymous methods, but will not have methods altogether, since it is a non procedural and non functional language, and can't even be called "programming" language, but that is a different story ;-) . I am really bound of the limitations of the existing languages, and need to find a drastic solution to progress further ;-) . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Michael Van Canneyt Sent: Monday, March 04, 2013 4:23 AM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods People who want that should not be using Pascal to begin with. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
No need Michael, Thank you :-) . I am actually a master in it, as you can probably guess from our products :-D . Indeed this new language is a "witchcraft", since it will not even have classes, structures, or even statements :-D . It is a totally new concept ;-) . But it will take few years to develop. I have hired couple of developers to do some of the initial work. We will see how it will go ;-) . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Michael Van Canneyt Sent: Monday, March 04, 2013 9:19 AM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods There is a course in witchcraft here in the neighbourhood, shall I send you the details so you can inscribe ? Sounds like just the thing :-) 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] Delphi anonymous methods
Hi Michael,
Thank you!
I actually have more experience in C++ than in Delphi. I have been using
Delphi only for ~15 years, where my active C++ experience dates back to
1990, and I actively develop in C++ and C# on daily basis as well (All of
our products support C++ and C#).
I have made some attempts in the past to support Lazarus, and offer our
products for it, but due to vast number of bugs and limitations in it, I
have all but given up.
I still hope that one day I may offer our components to the lazars/FPC
community, but that seems to be just a fantasy :-D . I am actually dropping
support for FPC in the latest OpenWire implementation again due to
incompatibilities and lack of Delphi features (in this case attributes).
It is ok, I don't use Lazarus (spare a brief attempt few years ago to port
the libraries), and I probably will never use it, especially after your
recommendation :-) , nor will probably most of my customers, and there are
fear number of them ;-) .
I have recently started to remove the {$IFDEF FPC} parts from the source
code, since the chance to port to FPC seems less and less possible.
With best regards,
Boian Mitov
---
Mitov Software
www.mitov.com
---
-Original Message-
From: Michael Van Canneyt
Sent: Monday, March 04, 2013 9:11 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods
If you want to drop FPC for because it forces you to move a line and
have to type a name in front of it, then yes, I think you are not on your
place working with pascal.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Then why do you think I am wasting my time writing all this? I really want to support Lazarus, but that is not even remotely possible today. I have well over 4 mln. lines of code and I need to support Delphi and C++ Builder with it. I will surely not abandon my current customer base just to rewrite everything for Lazarus only, and since Lazarus does not support DLL based packages, I will have to stop supporting my C++ and .NET customers as well. In essence I will have to kill my business just to support Lazarus. That would be foolish business decision, both for me and my employees, and customers. However if ever Lazarus gets attributes, extended RTTI, anonymous methods and dynamic packages at least in Windows, then I surely will invest more time and money in it (I spent a lot of time and money on it few years ago, before giving up.). I know how to take a risk, but I also know when it is foolish to take the risk. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Michael Van Canneyt Sent: Monday, March 04, 2013 11:12 AM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods On Mon, 4 Mar 2013, Boian Mitov wrote: But I seriously doubt that this has to do with missing anonymous functions in a delphi-compatible form. I also doubt that adding anonymous functions would make you change your mind. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Correct :-) . Now back to running it ;-) . Cheers! See what I am cooking next: http://www.mitov.com/OpenWireIDE.zip Enjoy! :-D With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Michael Van Canneyt Sent: Monday, March 04, 2013 12:41 PM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods On Mon, 4 Mar 2013, Boian Mitov wrote: Do not get me wrong, I do not ask you to change your decision or your code. You have a business to run, and this should be your primary concern. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
I actually looked at it few years ago. I also bought one of the Digital Mars CDs and still have it. It was at the time garbage collected, and this is a major No No in my book ;-) . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: Roberto P. Sent: Monday, March 04, 2013 2:06 PM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods FPC is really an exciting and always improving language/project, but IMHO if you stretch out too much from the Pascal origin and "general frame", then people will eventually get lost and abandone it. By the way, given your tastes, you might want to have a look a the D language. It's my favorite second choice :-) R#___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Cool :-). BTW: When you implement it, please consider making it available for attributes! The Delphi version really sucks in this :-( . I have not been able to do things like: [TComponentDialog( procedure( AInstance : TComponent) begin TMyComponnt( AInstance ).ShowDialog(); end ] TMyComponnt = class( TComponent ) public procedure ShowDialog(); end; This could have eliminated a full source file, and replaced it with 3 lines :-( . I really hate the half baked attribute and anonymous methods in Delphi :-( . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: Sven Barth Sent: Monday, March 04, 2013 2:19 PM To: fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] Delphi anonymous methods We'll implement features of Delphi anyway for compatibility. So why not use the implementation of it, provide some nice Pascal-style syntax for it and allow FPC users to usr the feature in non-Delphi modes as well. :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
I have never attempted to use it in wine. It is at current for Windows only, and is a prerelease. Here are however couple of very old snapshots. They are ~2 months old and miss a lot of new features, but will give you idea. http://www.mitov.com/OpenWireIDENewRunning.png http://www.mitov.com/OpenWireIDENew1.png Plan to release it in Beta in the next 2-3 weeks. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Michael Van Canneyt Sent: Monday, March 04, 2013 1:39 PM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods home: >wine OpenWireIDE.exe ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Agree :-) . A native Linux version is planned. It will be however done with either Lazarus or Delphi if its Linux version becomes available next year, or our own non Pascal compiler in the next couple of years if that one gets ready. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Michael Van Canneyt Sent: Monday, March 04, 2013 11:51 PM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods A pity. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Hi Henry, Interesting that you consider me a Delphi fanboy :-D . I don't like it much, but I surely love the anonymous methods :-D . I love the C++11 implementation of anonymous methods more however, but I hate the lack of extensive RTTI in C++ (and FPC). I am hard to please, and no fan of any specific language. I hate them, and love them equally with only one exception, well maybe 2. I highly dislike Java, and I hate Scheme! :-D . And BTW: I hate my products too, so that is why I keep working to improve them all the time :-D, they are never good enough for me! I am equal opportunity hater! With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Henry Vermaak Sent: Tuesday, March 05, 2013 2:05 AM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods And with the attitude of, e.g. Boian, we see that it's simply too hard to please hard-core delphi fanboys. They're all "take" and no "give". I look forward to the day when the fpc developers will realise that playing eternal catch-up is never going to work. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Hmm... you are running on the assumptions that humans are parsers. I for one do analyze the logic not the sequence, maybe because I usually write code for parallel execution. Humans do not think and follow code as computers, and often code that is easy to parse is difficult to follow by human IMHO. Otherwise we all would have been writing in Assembler ;-) . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Alexander Klenin Sent: Tuesday, March 05, 2013 3:30 AM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods It is hard to parse for humans as well as for the compiler. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
I equally love and hate the tools (spare Scheme and Java) :-D . So hence the smiling faces. I needed the performance boos and speed of development they are giving me. The development before that was way too slow :-( . I have increased the productivity multiple times by doing that. I also did more insane things to do that, like writing my own Design time API on top of the Delphi one. This virtually eliminated the need to develop design time editors, as I do it with just adding few attributes now. Second, I am financing the development of our own proprietary development language, and in few years may port everything to it. I also have the option to pay some developers to add the necessary features to FPC if it comes to that :-D . So I am not short on options :-P . I am insane, but not "that" insane :-D . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Henry Vermaak Sent: Tuesday, March 05, 2013 2:20 PM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods You sure have a lot of smiley faces for a person so full of hate :) In all seriousness, what were you thinking when you used all the latest features of a language that's closed source? I can understand that it makes your code better (arguably, perhaps), but you've locked yourself into the Delphi world now, and it's unlikely that freepascal will ever satisfy you if you chase after the latest features, since it will take too long to implement and stabilise. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI generating
On Fri, 19 Sep 2014, Adriaan van Os wrote: Your remarks seem to imply that you think RTTI can be used to inspect any aspect of an object. It was/is not meant for that. <<< Quite incorrect. All languages with modern RTTI allow for full object inspection, and that includes Delphi 2010 and higher, C#, and even VB has it. The fact is that FPC is just stuck in the last century, and the lack of any even remotely decent RTTI in it makes it unsuitable for any modern development. Our code nowadays relies nearly 100% on advanced RTTI, and it was one of the major factors, we decided to discontinue any attempts to support Lazarus. If the Lazarus goal is to be just what D7 was ~12 or so years ago, fine, but then easier goal is to be just what Turbo Pascal was in the late 80s or even easier goal, just be an assembler. The world has moved since 2000, and FPC seems to be downright stuck technology wise IMHO :-( . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Michael Van Canneyt Sent: Friday, September 19, 2014 3:44 AM To: FPC developers' list Subject: Re: [fpc-devel] RTTI generating On Fri, 19 Sep 2014, Adriaan van Os wrote: Your remarks seem to imply that you think RTTI can be used to inspect any aspect of an object. It was/is not meant for that. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI generating
Hi Jonas, I am sorry if I have misinterpreted the meaning of the message. I am just terribly frustrated with the overall state of the FPC :-( . I even offered to donate our enhanced RTTI API to the FPC community with very little interest so far :-( . I really want FPC/Lazarus to become a real competitor to the rest of the development environments. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Jonas Maebe Sent: Friday, September 19, 2014 2:10 PM To: FPC developers' list Subject: Re: [fpc-devel] RTTI generating On 19/09/14 22:49, Boian Mitov wrote: On Fri, 19 Sep 2014, Adriaan van Os wrote: Your remarks seem to imply that you think RTTI can be used to inspect any aspect of an object. It was/is not meant for that. <<< Quite incorrect. All languages with modern RTTI allow for full object inspection, and that includes Delphi 2010 and higher, C#, and even VB has it. The fact is that FPC is just stuck in the last century, Why do you take one paragraph out of context and base a whole rant on that which ignores the other information from the original message? Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI generating
Hi Silvio, That was not the case when I checked last time ~3-4 months ago :-( . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: silvioprog Sent: Friday, September 19, 2014 2:14 PM To: FPC developers' list Subject: Re: [fpc-devel] RTTI generating On Fri, Sep 19, 2014 at 5:49 PM, Boian Mitov wrote: I may be wrong, but if I'm not mistaken, the new Delphi XE RTTI is being implemented in FPC. My dream is see a project like DORM (https://delphi-orm.googlecode.com/files/dorm_introduction.pdf) implemented with FPC. :-) -- Silvio Clécio My public projects - github.com/silvioprog ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI generating
Hmm I read the original message again, and I see it exactly in the same way. It simply seems to state that the RTTI in FPC is what it is, because at the time when they looked at Delphi ( D7 ? ), it was how the RTTI was done. A lot has changed since then however in Delphi, and FPC seems to have moved very little, so I don't see how I have misinterpreted it. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Jonas Maebe Sent: Friday, September 19, 2014 2:10 PM To: FPC developers' list Subject: Re: [fpc-devel] RTTI generating On 19/09/14 22:49, Boian Mitov wrote: Why do you take one paragraph out of context and base a whole rant on that which ignores the other information from the original message? Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI generating
Me too! With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Ralf Quint Sent: Friday, September 19, 2014 2:50 PM To: fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] RTTI generating On 9/19/2014 2:38 PM, Boian Mitov wrote: I really want to become FPC/Lazarus a really stable, reliable development, across multiple platforms, without constantly trying to run along the other "kool kids on the block"... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI generating
Hi Sven, Thank you! This is all great news. I perfectly understand, and I also support some open source projects. However the dynamic packages have been in the works for at least 5-6 years if I recall. If the product does not catch up on at least some of those items, it simply will become irrelevant :-( . It will be a shame after all the great effort that has already gone into it if. I am extremely overworked myself, but I am looking into any option to help it. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: Sven Barth Sent: Friday, September 19, 2014 3:19 PM To: FPC developers' list Subject: Re: [fpc-devel] RTTI generating Am 19.09.2014 23:39 schrieb "Boian Mitov" : > I even offered to donate our enhanced RTTI API to the FPC community with very > little interest so far :-( . Your API would be welcome, but it's of no use when we don't yet generate the data your API relies on. And implementing that takes a sufficient amount of free time. Don't forget that we work on FPC on our free time without being paid for it (mostly at least). And then the extended RTTI isn't the only thing that wants to be implemented. Just a short list of those: - dynamic packages (working on that) - generic methods and functions (working on that) - attributes (being worked at) and extended RTTI - invoke (needs generic methods for TValue) - anonymous functions (being worked at or not... Don't know the current state) - Vector Pascal support - the new array initializers from XE7 - interface delegation to classes - usable cppclass support Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI generating
Hi Hans,
I am sorry to disagree with you.
The attributes in particular allow you to do real magic, and reduce your
code by at least 4 times, and speed up your development up to 10 times.
We have done that in Delphi.
I actually did a session in the PasCon few days on that.
Here is example:
TMyInterfacedClass1 = class;
[CreateType( typeinfo( TMyInterfacedClass1 ))] // Specifies the default
creation type as TMyInterfacedClass1
IMyInterface = interface
['{EB12CEBD-42C3-4259-AE2C-70267B67F454}']
function GetValue() : String;
end;
TMyInterfacedClass1 = class( TBasicInterfacedObject, IMyInterface )
public
function GetValue() : String;
end;
TMyInterfacedClass2 = class( TBasicInterfacedObject, IMyInterface )
public
function GetValue() : String;
end;
TMyNestedClass = class( TBasicObject )
protected
[Default( True )] // FValue1 will be initialized with True
FValue1 : Boolean;
[Default( 11.5 )] // FValue2 will be initialized with 11.5
FValue2 : Real;
[AutoManage( TMyInterfacedClass2 )] // FInterfaceValue will be created as
TMyInterfacedClass2
FInterfaceValue : IMyInterface;
public
property Value1 : Boolean read FValue1;
property Value2 : Real read FValue2;
property InterfaceValue : IMyInterface read FInterfaceValue;
end;
TMyClass = class( TBasicObject )
protected
[Default( 100 )] // FValue1 will be initialized with 100
FValue1 : Integer;
[Default( 'Helo World!' )]
FValue2 : String; // FValue1 will be initialized with 'Helo World!'
[AutoManage] // FNested will be automatically created and destroyed
FNested : TMyNestedClass;
[AutoManage( TStringList )] // FStrings will be automatically created as
TStringList and destroyed
// [AutoDestroy] // - If AutoDestroy is used instead of AutoManage, the
object will not be created but will be automatically destroyed!
FStrings : TStrings;
[AutoManage] // FNested will be automatically created as TStringArrayList
FStringArrayList : IStringArrayList;
[AutoManage] // FInterfaceValue will be created as TMyInterfacedClass1
FInterfaceValue : IMyInterface;
public
property Value1 : Integer read FValue1;
property Value2 : Stringread FValue2;
property Nested : TMyNestedClassread FNested;
property Strings : TStrings read FStrings;
property StringArrayList : IStringArrayList read FStringArrayList;
property InterfaceValue : IMyInterface read FInterfaceValue;
end;
As you can see all the management of all the classes and interfaces is done
without the need of even one line of code.
No constructors, no destructors, nothing.
This alone cuts vast amounts of code.
This however only scratches the surface of the RTTI power. You have no idea
about some of the other possibilities ;-) .
The RTTI does not only work with properties and fields, but with functions
as well, allowing easy implementation of RPC and network distributed
execution.
It is a whole ball game.
Frankly some of the arguments you provide ware the same I have heard 20
years ago when I programmed in C++ and people ware telling me I should be
doing it in Assembler.
They simply had no idea what power OOP had as example, as you probably have
no idea what is the real power of modern RTTI when properly used.
I am at the same time huge fan of strong typed languages. The advanced RTTI
does not really mean the code should and will not be strongly typed. Indeed
I have done my own RTTI API which is stronger typed than the one Delphi
provides.
With best regards,
Boian Mitov
---
Mitov Software
www.mitov.com
---
-Original Message-
From: Hans-Peter Diettrich
Sent: Friday, September 19, 2014 4:28 PM
To: FPC developers' list
Subject: Re: [fpc-devel] RTTI generating
Boian Mitov schrieb:
It's up to the coder to make all properties etc. published, when he
*intends* to ever use RTTI on them. That't the way to tell the compiler
what to do.
Inside a program there exists no distinct "brave object inspector" and
"unauthorized object garbler" - both can be implemented by using RTTI.
If you don't like safe types and other restrictions, which exist in
Pascal for good reasons, then choose any unsafe language to implement
whatever mess you like :-]
DoDi
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI generating
Hi Silvio, Please contact me at mi...@mitov.com, and I will send it to you. It is for XE4 and higher only however since older XE versions have some compiler issues. It is a new API design from the ground up, making everything extremely easy to do, fixing some hierarchy design bugs in the Emb. version, and adding some missing information. We will release it in few weeks as a free download, working on the documentation and the demos at the moment. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: silvioprog Sent: Friday, September 19, 2014 8:41 PM To: FPC developers' list Subject: Re: [fpc-devel] RTTI generating On Fri, Sep 19, 2014 at 9:08 PM, Boian Mitov wrote: I was very curious to see your RTTI API. :-) -- Silvio Clécio My public projects - github.com/silvioprog ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Hi Chriss, Personally I favor reference counted objects. While there are interfaces as you pointed, and in Delphi you can even use smart pointers now, there is still a lot of cases when you need to use objects, and have to manually free them. In single threaded environment that is not such an issue, but in parallel and heavily multithreaded environments, reference counting is a life saver. Just for that at the moment we have to declare gazillions of additional interfaces which slows the development considerably. After all even after we switched to the new RTTI, generics, and attributes, we barely succeeded to reduce our code from 4 mln lines of code to ~800K and it still is time consuming to maintain :-( . Anything that can reduce the code base further and speed up our development is important for us, as I would guess for anyone else. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: Chriss Kalogeropoulos Sent: Saturday, September 20, 2014 4:02 AM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects Hi all, Why would anyone want something like that? Both languages have interfaces that can be used for auto reference counting and they also provide us with a very powerful abstraction mechanism. This also adds overhead on the performance (and locking calls) which might be important in some cases like embedded devices. The fact that embarcadero added this feature unconditionally is a huge mistake IMHO unless they needed it for some compatibility reasons with java for android or iOS or just marketing, I don't know. If someone knows any other reason please post it on the list. It's the same bad decision they made with the zero based strings, at least the used a switch for that. The only gain I can see from that is that with objects someone can use reference counting and still benefit from some aggressive optimisation like inlining which is not possible for interfaces. The same with simple properties that they need getter and setter methods in interfaces that cannot be optimized but in objects it might be possible or they can access the data member directly. In my opinion this is a very small gain compared to the huge change in the language semantics that you propose. Chriss ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Hi Peter, I strongly disagree... I think there is a great value in a reference counted object, especially if we can enable/disable that with virtual method or even better attribute ;-) . Then you will have it any way you want :-) . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Peter Popov Sent: Saturday, September 20, 2014 4:11 AM To: fpc-devel@lists.freepascal.org ; Sven Barth Subject: Re: [fpc-devel] Suggestion: reference counted objects Please do not reference count TObject. This is a uniquely bad and unnecessary idea. I will switch to ANSI C if you guys do it Peter ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
I would propose either a virtual method or attribute that enables disables this. Indeed in our code we have adopted a pattern that implements both: TMyObject = class public function HasSomeFunctionality() : Boolean; virtual; end; function TMyObject.HasSomeFunctionality() : Boolean; begin Result TypeInfo().HasAttribute( SomeFunctionalityAttribute ); end; This way you can override the virtual method or just change/supress the attribute (In Mitov.TypeInfo advanced RTTI we have added the option to suppress attributes etc. ;-) ) Or the attribute can be boolean and use it as On/Off . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Ewald Sent: Saturday, September 20, 2014 5:15 AM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects On 09/20/2014 01:42 PM, Sven Barth wrote: What would be handy is a seperate root class that is always refcounted, something like TRefcountedObject or something. On the other hand some directive that makes this class refcounted would also be a good solution IMO (something that works for refcounting in the same way as $M does for RTTI). Just my 5 cents. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
BTW: Rumor has it that Emb. is working to introduce Ref Counting on all versions of the compiler. At the moment all of their mobile versions use it. At the same time we have ported large portion of our code to it, and it took ~1 month of work on and off. It is actually surprisingly easy, although our code always has been designed to be well structured in terms of that, and we have been using mostly interfaces for a decade already, so other code may be a different case. As for slowing down code that may very well be offset by other design benefits, but that is a whole different conversation ;-) . I can easily prove that it may speed up your code in some cases by factor of 100, by allowing you easily to add hash tables or other fast search methods that ware more difficult to manage without the ref counting as example ;-) . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Michael Van Canneyt Sent: Saturday, September 20, 2014 5:25 AM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects On Sat, 20 Sep 2014, Sven Barth wrote: Secondly, there is lots of code that stores objects in lists of pointers and vice versa. Checking such existing code for side effects by the sudden introduction of TObject may take ages. So reference counting TObject by default is IMHO out of the question. I am not against a reference counted class (the idea exists since ages). But the solution is IMHO to invent a new attribute or whatever, to allow people to make an arbitrary class (and it's descendents) reference counted. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
This is actually a very good idea IMHO! I would vote for it. Record inheritance is something I miss badly in Delphi. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: August Oktobar Sent: Saturday, September 20, 2014 10:48 AM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects What about adding support for destructors to (advanced) records (and/or inhertiance)? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Hi Giuliano, All of our libraries, are heavily multithreaded, and use exclusively reference counting with interfaces, as well as lazy evaluation nested object reference counting for performance. We have been doing this for over 11 years with great success, and we continue to expand the functionality. Not only is it doable, but it is nearly impossible to do really complex heavily distributed threading without it. Trust me, I have been doing multithreading since the days we had to implement it in interrupt cascades in 6502/6800 8 bit processors 30 years ago ;-) . I know what it takes to do it in assembler, C, C++, Delphi, with and without OOP, as well as with and without ref. canting ;-) . I have done them all... With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: Giuliano Colla Sent: Saturday, September 20, 2014 11:33 AM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects Il 20/09/2014 19:20, Boian Mitov ha scritto: Hi Chriss, Personally I favor reference counted objects. While there are interfaces as you pointed, and in Delphi you can even use smart pointers now, there is still a lot of cases when you need to use objects, and have to manually free them. In single threaded environment that is not such an issue, but in parallel and heavily multithreaded environments, reference counting is a life saver. Can you explain how reference counting can be safely implemented in a parallel multithreaded environment, without heavily affecting performance? A mere increment or decrement of count means to get a lock and to release a lock on that object. Application code can know what is thread safe and what is not, and use lock only when appropriate. A general mechanism to be reliable should take into account all possibilities. If it does, it will block threads even when unnecessary. If it doesn't, it will be unsafe. What do I miss? Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI generating
If the compiler information is generated, I can work on the API to access it. I think I can easily port my API to do that, and can contribute the version to the open source project. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: Sven Barth Sent: Saturday, September 20, 2014 12:32 PM To: FPC developers' list Subject: Re: [fpc-devel] RTTI generating Am 20.09.2014 18:05 schrieb "Florian Klämpfl" : It depends what you define as finished: it currently provides only class attributes, but not attributes for other constructs nor the extended RTTI, but basic structures that are needed for it. That's basically how far Joost wanted to get it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
PS. Forgot the mention the anonymous methods – a real revolution when you do multithreading or parallel processing. Anything else looks like joke next to them... You can see some of my examples from interview in the Blaise Pascal Magazine http://www.blaisepascal.eu/. Also did a session on it at PasCon in Holland, and will do also in Milan and in CodeRage, so you can see and judge for your self, and BTW anonymous method storage is ref counted also ;-) . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: Boian Mitov Sent: Saturday, September 20, 2014 12:27 PM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects All of our libraries, are heavily multithreaded, and use exclusively reference counting with interfaces, as well as lazy evaluation nested object reference counting for performance. We have been doing this for over 11 years with great success, and we continue to expand the functionality. Not only is it doable, but it is nearly impossible to do really complex heavily distributed threading without it. Trust me, I have been doing multithreading since the days we had to implement it in interrupt cascades in 6502/6800 8 bit processors 30 years ago ;-) . I know what it takes to do it in assembler, C, C++, Delphi, with and without OOP, as well as with and without ref. canting ;-) . I have done them all... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI generating
Hi Sven, Please if you have done the RTTI work, please contact me at mi...@mitov.com, and we can discuss what I can do. Otherwise please put me in touch with whomever is working on it, so we can collaborate. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: Sven Barth Sent: Saturday, September 20, 2014 2:05 PM To: FPC developers' list Subject: Re: [fpc-devel] RTTI generating Maybe you could document the binary format of the extended RTTI data. That would IMHO currently help more than the API. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
The short story is that any approach has issues. The component container approach has issue of a single ownership with the easy loss of pointers. The ref counting has the danger of circular references. The GC has the non deterministic behavior (Actually I proposed a deterministic/semideterministic GC algorithm ~8 years ago or so, but that is a different story). The point is that even with GC the developer is still required to carefully manage resources, and GC tends to make it even more complex. From all the the above approaches the ARC with optional Weak pointers is the easiest to manage and the one that tends to lead to the least problems IMHO . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Gennady Agranov Sent: Saturday, September 20, 2014 1:54 PM To: fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] Suggestion: reference counted objects I will address multiple previous e-mails on this subject :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Hi Giuliano, Funny that you mentioned it. Industrial automation, and process control are one of our specialties ;-) . Actually this is my major. However I am somewhat unusual in that I have implemented in my career almost every class of application you can name, with a large number of different technologies. Yes, I have implemented process control applications 20 years ago without ref.counting and I implement them today with it, and I can assure the later makes it easier and actually faster at the end (less overhead). Even our current line or products covers large variety of areas – we have video, audio, DSP processing components, computer vision, Artificial Intelligence, Boolean logic/hardware simulations, and much more, and we are in about to release process control library – OPC, PID, Relay controllers etc. Aside from that I used to have my own HW company ~30 years ago, and have done a lot of HW designs many surprisingly still in use. I think I have (for good or bad) a unique overview over the full spectrum of technologies, and intimate experience with most of them. In reality I am very dissatisfied with them all... but that is a different story, and I am working to hopefully address that in the future ;-) . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: Giuliano Colla Sent: Saturday, September 20, 2014 3:19 PM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects I might, for example, tell you that my company has been successfully implementing since more than 30 years a class of applications for the control of industrial processes, with hundreds of threads running simultaneously in a multi-CPU environment, with thread synchronization in the sub-millisecond range (with time it has improved down to the sub-microsecond area, with the evolution both of hardware and software tools), where reference counting simply doesn't apply, because of the specific nature of the problems. All the required resources must be created at startup, and they can only be destroyed when the process is stopped, at the end of the day in some cases, at the end of the week or for the annual vacations in others. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Hmm the last time I checked this was anonymous methods... Are you sure I was talking closures? FThread1.Process( procedure() var ANewText1 : String; begin Sleep( 500 ); // Simulate thread busy doing time consuming task ANewText1 := AText + ' + Thread1'; FThread2.Process( procedure() var ANewText2 : String; begin Sleep( 500 ); // Simulate thread busy doing time consuming task ANewText2 := ANewText1 + ' + Thread2'; FThread3.Process( procedure() var ANewText3 : String; begin Sleep( 500 ); // Simulate thread busy doing time consuming task ANewText3 := ANewText2 + ' + Thread3'; FThread4.Process( procedure() var ANewText4 : String; begin Sleep( 500 ); // Simulate thread busy doing time consuming task ANewText4 := ANewText3 + ' + Thread4'; MainThreadExecute( False , procedure() begin Memo1.Lines.Add( 'Ended Processing: ' + ACounter.ToString() + ' - Result:' ); Memo1.Lines.Add( ANewText4 ); Memo1.Lines.Add( '' ); Dec( FInProccessingCount ); Label1.Caption := 'In processing pipeline = ' + FInProccessingCount.ToString(); end ); end ); end ); end ); end ); This is a 4 stage pipeline with asynchronous main thread printing. I dare somebody to implement it in less than 5-6 times more code with traditional methods, and while matching the performance... With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: Dmitry Boyarintsev Sent: Saturday, September 20, 2014 7:46 PM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects To be more accurate.. You're talking about "closures". The difference between closures and anonymous functions is explained here: http://en.wikipedia.org/wiki/Closure_(computer_programming)#History_and_etymology the second paragraph. thanks, Dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
PS. And at least in Delphi they are implemented as interface and ref. counted... With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: Boian Mitov Sent: Saturday, September 20, 2014 7:55 PM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects Hmm the last time I checked this was anonymous methods... Are you sure I was talking closures? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
That is easy. it gets incremented when it gets assigned. The running threads have no way of accessing it if there is no reference (assignment) already in place. Indeed that is how it works in Delphi, and BTW: that is how Strings work in Delphi and FPC the last time I checked ;-) . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Hans-Peter Diettrich Sent: Saturday, September 20, 2014 8:34 PM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects Sven Barth schrieb: Am 20.09.2014 20:34 schrieb "Giuliano Colla" As I understand Interlocked Inc/Dec funtionality, it only protects the update of the reference counter against interrupts, but not the tests required before/after this update. As a precaution a RefCount should at least be incremented as soon as there exists a *chance*, that the reference is used/copied in some piece of currently active code (thread...). DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Unless you implement something like the semi-deterministic GC that I proposed few years ago, weak pointers are the only solution for avoiding circular reference deadlock in ARC as far as I know. They are simply necessary evil, and a small one base on my current experience with them. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Hans-Peter Diettrich Sent: Saturday, September 20, 2014 8:14 PM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects Boian Mitov schrieb: ACK - except for Weak references. Weak references turn the conservative memory management into an aggresive/optimistic one, with unpredictable consequences. IMO Weak references should be reserved for users who accept possible consequential problems, but should never be used in standard libraries. At least I'd suggest to make weak references subject to an compiler switch, so that every user has a chance to disable them in case of trouble. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
I actually do not use FPC any more due to the lack of many advanced features. I use Delphi. I hope however that will change. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Hans-Peter Diettrich Sent: Saturday, September 20, 2014 8:51 PM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects Giuliano Colla schrieb: It's good to know that FPC allows to implement and manage more complex parallel processing, if I understand you and Boian correctly? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Hans, There is no such problem. We run many hundreds of threads sharing and passing interface data for 11 years already, and in the last 2 years doing it with Anonymous methods as well. I can assure you it works 100%. There is no problem. And since we are component vendor, it also works for all of our customers as well. So far there has not been a single bug report on anything like this. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Hans-Peter Diettrich Sent: Saturday, September 20, 2014 10:22 PM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects The problem arises when an object is destroyed, or even elected for destruction in _Release, while another thread starts using the same instance. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
The biggest problem is when to initiate the detection and still maintain some form of determinism. That was the algorithm I proposed a while back, but it was not without a drawbacks. It would have affected performance. There is not really a silver bullet for this as far as I know. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: Sven Barth Sent: Sunday, September 21, 2014 12:33 AM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects Am 21.09.2014 06:11 schrieb "Boian Mitov" : > > Unless you implement something like the semi-deterministic GC that I proposed > few years ago, weak pointers are the only solution for avoiding circular > reference deadlock in ARC as far as I know. They are simply necessary evil, > and a small one base on my current experience with them. There are cycle detection algorithms that could be used upon a decrease of a reference count. Biggest problem is that they would be quite expensive (regarding performance) in case of complex object instance "graphs" like the LCL/VCL. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Question about Syntax: I there a reason for this design?
Hi Sam,
You can watch my CodeRage session last year explaining the huge advantages of
the first syntax.
That being said, I consider it a design bug that local functions can’t be
passed as anonymous methods in Delphi. There is no reason for that not to be
done, except that they did not bother.
I hope if FPC implements anonymous methods, that they will also allow local
functions to be passed, and outdo Delphi :-) .
With best regards,
Boian Mitov
---
Mitov Software
www.mitov.com
---
From: Samuel Herzog
Sent: Saturday, September 20, 2014 11:10 PM
To: FPC developers' list
Subject: [fpc-devel] Question about Syntax: I there a reason for this design?
I was looking at the following example in DXE7
http://delphiaball.co.uk/
procedure TFormThreading.Button1Click(Sender: TObject);
var
aTask: ITask;
begin
// not a thread safe snippet
aTask := TTask.Create (procedure ()
begin
sleep (3000); // 3 seconds
ShowMessage ('Hello');
end);
aTask.Start;
end;
I dislike this syntax and tried to write it this way because I think it's
better readable code.
But it's not accepted.
procedure TFormThreading.Button1Click(Sender: TObject);
var
aTask: ITask;
procedure MyTask;
begin
sleep (3000); // 3 seconds
ShowMessage ('Hello');
endbegin
// not a thread safe snippet
aTask := TTask.Create(MyTask);
aTask.Start;
end;I just wonder if there is a valuable reason to do it why my example is not
allowed or would it be easy to make this available in free-pascal?
Thank you.
Sam
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Question about Syntax: I there a reason for this design?
I used to think the same way, until I actually started to use anonymous methods, and I realized what a full I used to be. The simplest difference is that you can return anonymous method as a result of your function and it will preserve all the captured context. Local methods can't do that. Furthermore local methods will not work when passed as parameter to another thread, as they lose context when the owner function exits. You can watch my session on CodeRage last year explaining most of that, and I will be doing some sessions this year on multithreading, and parallel processing where even more will be shown both at ITDevCon and hopefully CodeRage. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Jonas Maebe Sent: Sunday, September 21, 2014 3:13 AM To: FPC developers' list Subject: Re: [fpc-devel] Question about Syntax: I there a reason for this design? On 21/09/14 08:10, Samuel Herzog wrote: As you observed, anonymous methods and nested routines are essentially identical other than the syntax, and I agree the latter generally also result in better readable code. Therefore I'm still inclined to implement it somehow (at least for C-blocks, as already partially implemented in http://svn.freepascal.org/svn/fpc/branches/blocks/), because it seems a shame not to use an existing, perfectly suited language construct and instead force everyone to use a new one. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Absolutely! Interfaces have been used in threading for decades already in may languages. I have also never heard of anyone having issues with them. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Sven Barth Sent: Sunday, September 21, 2014 3:41 AM To: fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] Suggestion: reference counted objects On 21.09.2014 05:34, Hans-Peter Diettrich wrote: No, why should it? It works pretty well with interfaces, strings and arrays (let's put aside modifying the latter two, because COW is not needed here). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Every memory management system has a manual part, even the M$/Java GC has element of it (the dreadful Disposable pattern to name one). There is a huge difference however. ARC requires in general less coding for the same result. Less code in general is cheaper to develop, debug, read and maintain. It is a simple business formula actually (and as businessman I need to calculate this). There is also the old saying "What is the only line of code where you can't have a bug?" with the obvious answer - "The one you don't write." ;-) . So on the balance sheet ARC is a cheaper and in general easier to maintain form of manual memory management, and my experience with it (Mainly interfaces - almost everything we do is interfaced nowadays), confirms that 100%. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Marco van de Voort Sent: Sunday, September 21, 2014 3:58 AM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects In our previous episode, Hans-Peter Diettrich said: IMO Weak references should be reserved for users who accept possible consequential problems, but should never be used in standard libraries. At least I'd suggest to make weak references subject to an compiler switch, so that every user has a chance to disable them in case of trouble. IMHO weak references trade one manual memory system in for a different manual memory system. The hard part of manual memory systems, figuring out how a complex dynamic structure deallocates (that is usually tackled by having a bit of design and thought go into it), remains. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
In general I would prefer to see this implemented with attributes rather than with new keywords. For god shake, we already have more keywords in this language than it is healthy. We should be extremely cautions when adding new ones. That is one of the beauty of the attributes. They can eliminate a large number of keywords, and expand the language dynamically (trough the library not trough the compiler). If you implement it with attributes, there is almost no need for any big changes in the compiler at least in the parsing side. Adding new keyword will probably propagate all the way to the tokenizer. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Sven Barth Sent: Sunday, September 21, 2014 4:12 AM To: fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] Suggestion: reference counted objects === code begin === type TARCObject = class refcounted(TObject) end; === code end === === code begin === type TSomeClass = class(TARCObject) // ... Owner: TSomeClass weak; // ... end; === code end === ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Question about Syntax: I there a reason for this design?
Hi Jonas,
I actually agree that it is a nice feature, and I want to have it both in
Delphi and FPC :-) .
I prefer the anonymous method syntax as it means less typing, and typing is
expensive, however there are cases when I really would love to capture local
function. I had few of them already.
The problem is even bigger. You can't even call a local function from
anonymous method doe to the same capturing issue :-( . This really should
have been addressed in Delphi.
With best regards,
Boian Mitov
---
Mitov Software
www.mitov.com
---
-Original Message-
From: Jonas Maebe
Sent: Sunday, September 21, 2014 10:23 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Question about Syntax: I there a reason for this
design?
[Jonas: anonymous methods and local functions could use the same syntax]
I'm talking about syntax, not behaviour. When assigning a local function
to an anonymous method ("reference to ..."), the context will have to be
captured in exactly the same way as when specifying an inline nested
function (aka anonymous method) that requires context. A nested function
and a "reference to..." are different types, so a type conversion would
have to be inserted by the compiler anyway (a bit similar to how
assigning a method to a "procedure of object" works, which also captures
context, be it in a much simpler way).
You could still first keep the context on the stack for quick access by
the parent function and later add indirection if necessary (in case it
can escape the life of the parent function), as handled by e.g. C blocks.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
So why are you not programming in Assembler? The arguments you provide are the same that ware provided against higher level languages, adding OOP, adding anonymous methods, just to name few. I spent 2 years streamlining all of our code - 4 mln. lines of code to use the latest language features, and in the following year we had a 10x boost in development performance, so it immediately paid off, and now we have 800K code instead of 4 mln. With the old code we ware running out of steam just to maintain it. The new code just largely takes care of itself. Rewriting code is actually a good thing, and I do rewrite cycles in the company every 3-4 years, sometimes for some pars even more often. Every time the code improves as does the performance, and quality. If ARC forces you to review some code, that actually is a good thing. You will need to retest it after the changes, but if you have good unit or functional testing should not be big issue, and if you don’t will be a good chance to add it, or to at least make sure the code really behaves. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Peter Popov Sent: Sunday, September 21, 2014 11:13 AM To: fpc-devel@lists.freepascal.org ; Sven Barth Subject: Re: [fpc-devel] Suggestion: reference counted objects In summary, if it is already there, why force it on all, change the language and create a mess? Engouh? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Ahh... the schizophrenic nature of Object Pascal :-D, I never understood why interface and class should be different at first place, considering that interface is practically nothing more than pure abstract class with ref. counting. Why the separated syntax etc. is beyond me... Surely helps with the language keyword pollution With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: Gennady Agranov Sent: Sunday, September 21, 2014 11:15 AM To: fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] Suggestion: reference counted objects Coming from Java I could not even comprehend at the beginning that if variable type is interface - it is reference counted, but if variable type is a class that implements interface - it is not ?! Regards, Gena ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
This is not true. Ref pointer is exactly the same size as non ref pointer. the counter is in the instance not in the pointer to the instance ;-) . You can study the interface implementations or the String implementations they are done the same way. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Peter Popov Sent: Sunday, September 21, 2014 12:29 PM To: fpc-devel@lists.freepascal.org ; Sven Barth Subject: Re: [fpc-devel] Suggestion: reference counted objects Sven, based on your comments a bizarre thought came to me. Currently, class instances are pointers. What you propose will somehow create a special pointer type (referenced class). Should this be done, I have a request: create a 4 byte "compressed" class reference which expands into an 8 byte pointer type prior to usage: 1. Most architectures align data. 2. 64 bit comps align pointers on 8 byte boundaries, meaning that the 3 leftmost bits are 0. 3. You could store a class pointer as a 4 byte integer and, prior to usage, expand it to 8 bytes a leftshift 3. In this way you will have 64GB of data available to your program and your pointers will occupy twice less. If, for example one uses large amount of pointers, this could be ... aesthetically pleasing ... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
I mean in terms of cost to write the lines of code. And later to review and manage it. It all adds up to a lot at the end. I have to find ways to pay for it every month :-( . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Marco van de Voort Sent: Sunday, September 21, 2014 12:36 PM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects I work with Delphi professionally too, and I don't really notice allocation as time costs. It's negiable. Occasionally (in the six months magnitude) I run the app through fastmm, but that time is general cleanup, so even not entirely the cost of memory management. I can't find any basis for your allegations in my work. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
In general you can have good and bad designs with and without ARC/weak pointers/ or sweep GC. From all of the above, and I have done them all for years, the ARC is the easiest to manage, and the one with the least side effects. What you was does not differ from the issues of lost pointers in non ARC. In essence you normally work with only Weak pointers, so if you let say like them so much now, I don’t see a reason to hate them in ARC ;-) . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Hans-Peter Diettrich Sent: Sunday, September 21, 2014 10:14 AM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects And this is what the user of such a structure (standard libraries...) does not always know. He may be unable to determine the reason for some runtime error in his code, when an object was destroyed automagically where it should still be alive. The user can debug (and fix) ordinary (owner/owned) patterns, implemented in high level code, but not table-driven (RTTI) or otherwise hidden (intrinsic) management procedures. While the user can change the owner of an object at runtime, he cannot change a weak reference into a strong one, without recompilation of at least the unit containing that declaration, and without figuring out the consequences of such an change. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Yes! With best regards, Boian Mitov --- Mitov Software www.mitov.com --- Is it really sufficient to protect refcounter changes by Interlocked Inc/Dec, to prevent race conditions while obtaining object references? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
We probably should if possible keep pointers just pointers (Ref counted pointer is same a non ref counted as we discussed so same size). Otherwise we may end up adding bits for the Moon Phases or something in it. Even if we add ARC we should do it as simple as possible and without increasing the size of the pointers (After all Delphi already has done it, and their ref counted pointers are still 4 bytes for 32 bit processes). With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Nikolai Zhubr Sent: Sunday, September 21, 2014 2:59 PM To: fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] Suggestion: reference counted objects 22.09.2014 0:28, Peter Popov: Besides, thinking about a magnificent brand new pointer type, and as long as certain performance penalties can be tolerated, one might want to also consider providing some path for heap defragmentation, for the sake of completeness (Not that I know how to properly do it, but still my $0.02). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Attributes are actually one of the biggest revolutions in computing IMHO. Pascal has one of the oldest, and lets admit it not the prettiest syntax. If we want to keep something in as un-pretty shape, we surely can, but should it be a goal? Adding new keywords to any language pollutes the language, and is widely considered to be a bad practice. It should be avoided whenever possible IMHO. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Sven Barth Sent: Sunday, September 21, 2014 10:52 PM To: fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] Suggestion: reference counted objects On 21.09.2014 19:17, Boian Mitov wrote: I openly *hate* the attribute syntax. It's just not Pascal and simply copied from their .Net compiler, because hey, other .Net compilers do that just like that... -.- Also considering that the trunk compiler currently does not have support for attributes (let's put aside that branch for now) it is definitely easier to add a new keyword, because the compiler is built in a way to allow the easy addition of new keywords. Additionally using attributes would mean that one would need to add detection for special attributes. And that's more annoying stuff then a keyword is. Additionally this can be added more safely to other modes (e.g. macpas, which supports classes as well) than the attributes can. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Because it requires writing a lot more code, just to get the Ref. Count, and as I stated in another mail, you don't have direct field access. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Michael Schnell Sent: Monday, September 22, 2014 12:47 AM To: fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] Suggestion: reference counted objects AFAIR there already were several debates on ARC Objects that seem do be a "modern" language feature but in Pascal language they are considered to provide lots of pitfalls. Why not use "interface" to add ref-counting to an object ? This seems to work nicely even though the name "interface" in not "speaking" on that behalf. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
If you have anonymous methods, you don’t need parallel loops, as I have demonstrated in my sessions. We use anonymous method parallel loop, and parallel recursion easily, and with greater flexibility than any language modification can achieve. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: Michael Schnell Sent: Monday, September 22, 2014 1:37 AM To: fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] Suggestion: reference counted objects On 09/20/2014 08:33 PM, Giuliano Colla wrote: Can you explain how reference counting can be safely implemented in a parallel multithreaded environment, without heavily affecting performance? *Very* good point ! IMHO a by far more advantageous feature to be added than ref-counted objects would be RTL support and Syntax candy for "parallel Loops", and the necessary support stuff like "Future variables" (or similar thingies). All new mid-level hardware now has art least four cores and hence performance would benefit from such features in may projects. So maybe "ARC" and "parallel" paradigms should be discussed together so that no mutual problems are introduced. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Question about Syntax: I there a reason for this design?
But it can be encapsulated in the anonymous object of anonymous method as it is done with local (stack) variables already in Delphi. Anonymous methods can and do use local variables, and are regularly returned as result or passed to other threads. That is the power of anonymous methods. I covered that in great detail in my last CodeRage session on functional programming. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: Michael Schnell Sent: Monday, September 22, 2014 1:54 AM To: fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] Question about Syntax: I there a reason for this design? On 09/21/2014 06:36 PM, Boian Mitov wrote: I consider it a design bug that local functions can’t be passed as anonymous methods in Delphi. There is no reason for that not to be done, except that they did not bother. ??? Local functions can use local variables of the outer function. Same are logically undefined outside the outer function and technically stack based. Hence a local function can't be passed anywhere. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
In general, records and classes are inherently the same thing (and in C++ are indeed practically interchangeable). The only real difference in Delphi/FPC is that records are instantiated in the stack, the objects in the heap, and the artificial restriction on record inheritance. Now adding the option classes/objects to be instantiated in stack is a risky one, however having record hierarchies poses very little risk. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: Michael Schnell Sent: Monday, September 22, 2014 2:03 AM To: fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] Suggestion: reference counted objects On 09/20/2014 08:04 PM, Boian Mitov wrote: This is actually a very good idea IMHO! I would vote for it. Record inheritance is something I miss badly in Delphi. As said in a previous mail: why have "Record" ad all, if you want things like inheritance (and "active" properties, ...) Maybe multiple brands of type if "class" would be more straight forward (making "record" just an alias for portability) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Strongly disagree... For multithreading and parallel processing ARC is lifesaver. I have been using it trough interfaces for 10 years already, and once I rewrote the old code to use ARC it was a huge performance boost, and it keeps getting better. Doing parallel processing without ARC is practically suicidal IMHO. I have also done a large number of sessions covering only some of the aspects of this in a number of conferences, but even those bits and pieces will give you idea of what ARC can do for parallel processing. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Michael Schnell Sent: Monday, September 22, 2014 2:21 AM To: fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] Suggestion: reference counted objects On 09/22/2014 11:13 AM, Sven Barth wrote: But one point speaking against ARC is performance possible degradation, This of course is critical when trying to improve performance by using multiple cores in parallel. As the ref counting needs atomic operation, this is especially critical, because same are even more expensive when the variables are accessed by multiple cores (and hence reside in multiple caches). OTOH ARC might be "interesting" (but supposedly not really advantageous) with parallel processing for creating thread-local objects in certain cases. Adding even more confusion to developing multithreaded projects :-( . ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Then the best option is Assembler. There you really know what you are doing. In ARC I also know perfectly what I am doing. It may be con for some, but surely not for me ;-) . Honestly if you don’t know what you are doing when using ARC, I doubt a bit, you really know what you are doing otherwise either ;-) . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Michael Schnell Sent: Monday, September 22, 2014 2:22 AM To: fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] Suggestion: reference counted objects On 09/22/2014 11:15 AM, Sven Barth wrote: Because you'll need to declare an interface for each class you want to have reference counted so that you can access its methods, properties, etc. Con: more typing Pro: you know what you are doing. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
As I already stated, those are the same arguments that I have heard 30 years ago when people ware asking me why I would use C instead of doing it like them in Assembler. later, why I would use C++ classes, when we has sructures in C++. Why use virtual methods, in C++ instead of using the EC++ without them to “save space”? ... I think history has at least so far always been on the side of my arguments ;-) . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: Michael Schnell Sent: Monday, September 22, 2014 5:09 AM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects On 09/22/2014 11:54 AM, Peter Popov wrote: > > Because you'll need to declare an interface for each class you want to > > have reference counted so that you can access its methods, properties, > > etc. > > > Con: more typing > Pro: you know what you are doing. I cannot agree more. Another con: Nobody will search for the term "interface" when he wants reference counting :-( -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
I am not big fan of the compiler handling parallel loops, as it will limit any flexibility in implementation. A library based functionality with shared executors is a better design, and it allows not only for parallel loops but also for easy parallel recursions and many other combined(iterative/recursive) constructs. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Michael Schnell Sent: Monday, September 22, 2014 5:58 AM To: fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] Suggestion: reference counted objects On 09/22/2014 02:51 PM, Sven Barth wrote: Then you should also not use interfaces, strings and arrays, because they use the same mechanisms. Yep. The advanced developer should know what he is doing. What us confusing there? Of course I do know the pitfalls. If fpc would provide a syntax for "parallel loop" and "future variables" e.g. similar to what Prism offers, even more inexperienced users will be inclined to use (invisible) threads. I suppose it's not possible to avoid the "confusion" that is introduced by this, but it should be limited as much as possible. (No idea how.) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Here is example from our implementation: for AIndex := 0 to Length( AList ) - 1 do AExecutionTask.Add( FExecutor.Execute( TDelegate.Capture( AIndex, procedure( ALocalIndex : Integer ) begin Sleep( 1000 ); // Simulate thread busy doing time consuming task AList[ ALocalIndex ] := ALocalIndex * 2; end ) ) ); AExecutionTask.WaitFor(); Notice the need for TDelegate :-( This is due to the fact that Delphi unlike C++11 does not allow the option to capture local context my value, and captures everything by reference :-( . This is something to be considered when implementing anonymous methods or lambdas in FPC, especially for multithreading and parallel execution. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Michael Schnell Sent: Monday, September 22, 2014 5:58 AM To: fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] Suggestion: reference counted objects On 09/22/2014 02:51 PM, Sven Barth wrote: Then you should also not use interfaces, strings and arrays, because they use the same mechanisms. Yep. The advanced developer should know what he is doing. What us confusing there? Of course I do know the pitfalls. If fpc would provide a syntax for "parallel loop" and "future variables" e.g. similar to what Prism offers, even more inexperienced users will be inclined to use (invisible) threads. I suppose it's not possible to avoid the "confusion" that is introduced by this, but it should be limited as much as possible. (No idea how.) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
BTW: Please note that since you can keep adding executions to the task, it can be done in nested loops, as well as in function calls thus doing fully fledged parallelization. The executor also can be single thread, unlimited threads, self balancing, or limited pool depending on the specific instance, so a very fine control can be exercised over the execution, as well as it can be changed dynamically by code, thus sometime executing the code with one executor and other times with another, based on the specific needs. Adding simple parallel loop lacks any of this power, and only serves very specific cases. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Boian Mitov Sent: Monday, September 22, 2014 11:54 AM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects Here is example from our implementation: for AIndex := 0 to Length( AList ) - 1 do AExecutionTask.Add( FExecutor.Execute( TDelegate.Capture( AIndex, procedure( ALocalIndex : Integer ) begin Sleep( 1000 ); // Simulate thread busy doing time consuming task AList[ ALocalIndex ] := ALocalIndex * 2; end ) ) ); AExecutionTask.WaitFor(); With best regards, Boian Mitov --- Mitov Software www.mitov.com --- ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
I know ;-) . I meant the default behavior. Very much anything can be accessed and instantiated trough pointers :-) . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: Ewald Sent: Monday, September 22, 2014 1:09 PM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects `a` will be on the stack, not on the heap. I you allocate them using `New`, they will be on the heap. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
The thing is that we have weak references for COM – standard pointer ;-) ARC without optional weak pointers leads to guaranteed memory leak. Simple example: Parent calls with children, and child with pointer to parent. If the pointer to parent is not weak, the objects will never be freed. In COM we work around that with non interface pointers, (effectively weak pointers ;-) ). With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: hinstance Sent: Monday, September 22, 2014 1:17 PM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects I am not even sure if weak reference feature is necessary. We don't have weak references for COM interfaces, and it still works so far. Well, of course, if we had weak references as well, it would be a useful feature perhaps, but considering just how many times ARC class was proposed before, I lost hope that it will be ever implemented at all quite a while ago ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
If you are experienced in parallel processing, you should know the answer. This is a huge topic, and I have done number of sessions on some aspects of it, but here will give you a small example (again this is just a small example). You have a data object that needs to be processed by 600 threads, and when they all have consumed(finished with it) it, it needs to be disposed. With ref counting you create the object send it to all threads, each thread has its own reference to the object. When they all release the references the object is destroyed. Even this very simple (again I don’t even involve pipelining or other threading nesting here) is much more difficult to implement without ref counting, and extremely error prone in traditional approaches. In our case we pass objects between hundreds of threads performing variety of processing between them. Without Ref. Counting (in this case with interfaces), we would simply would not have been able to do that... You can see our solutions here - www.mitov.com, and you can easily see the complexity of the parallel processing that takes place. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Peter Popov Sent: Monday, September 22, 2014 1:32 PM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects On Mon, 22 Sep 2014 21:34:34 +0300, Boian Mitov wrote: Strongly disagree... For multithreading and parallel processing ARC is lifesaver. I have been using it trough interfaces for 10 years already, and once I rewrote the old code to use ARC it was a huge performance boost, and it keeps getting better. What on earth has reference counting got to do with writing efficient multi-threaded code? You obviously confuse parallel performance, which reference counting will obviously degrade, with making some particular coding style easier. And sure, if your threads don't use shared resources they will be very parallel indeed. If your argument is that by writing less code you have more time to refactor code, therefore you write better algorithms, and they run better - then this would be a valid point for your situation. However, one size does not fit all. I am not going to re-profile code because suddenly assignments will not only incur a (possibly virtual) function call but also lock other threads even if for a cycle or two. Not to mention cache misses because every time you assign a pointer its value must be fetched from memory and incremented, therefore messing around with data which was supposed to be in the cache. And screw other threads' caches. To put it differently, ARC will seriously degrade applications which fill the memory bus bandwidth, multi-threaded or otherwise. For such pieces of code it should not be used. Peter ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Actually, although on first glance different, anonymous methods are done as reference counted objects in Delphi, (well technically trough interfaces.), so since the anonymous method storage by definition has to be kept alive trough reference counting or similar approach, the topic is not that detached from this one. PS: Why they call them anonymous methods when they are actually anonymous interfaced objects is something I always wondered about :-D . I guess mainly because of the syntax, not the content. i.e. name it based on the cover not the book :-D . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: Sven Barth Sent: Monday, September 22, 2014 2:25 PM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects Am 22.09.2014 22:23 schrieb "hinstance" : > > I suggest doing one thing at a time. ARC class first, complex delegates > capturing local context later Considering that those are two different features that don't have anything to do with each other their development doesn't need to be serialized, but can happen in parallel ;) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Because TObject always has virtual table as example, and you can't use anything inherited from it to map into communication header. Structures on another hand by default start from empty hierarchy, and do not have Virtual Table pointer so I can create a structure and send it to a socket for transmission or map an received array into structure for easy access. Unfortunately headers tend to have hierarchies ;-) , shich makes it a bit challenging to map them into Delphi records, or use the same function to process inherited record as example ;-) . I know there are some not that pretty works around this, but that is what they are - ugly, and sometime dangerous(ahem... unsafe casting) work arounds. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Hans-Peter Diettrich Sent: Monday, September 22, 2014 4:58 PM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects Boian Mitov schrieb: In general, records and classes are inherently the same thing (and in C++ are indeed practically interchangeable). This model might have been the reason for introducing Object at all, for compatibility with CBuilder. The only real difference in Delphi/FPC is that records are instantiated in the stack, the objects in the heap, Like records, Objects can reside in either the stack, heap or even static memory. and the artificial restriction on record inheritance. Why inherit when you can't override virtual methods? I convert my Records into Objects, when I want to extend an record. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] weak referencing (was Suggestion:.....)
Because none of those is a strong typed language. Each language has weak and strong points. Pascal is semi strong typed language, and as such is very well declarative style oriented. Functional programming however merges very well with strong typed declarations actually getting us closer to the holly grail for pure declarative programming. Those other languages you mentioned don’t do that. The closest to perfection nowadays is probably C++11 but it also is not without flows, mainly practically total lack of RTTI. What I am saying is that Delphi, C++ with C++11, Java, and C# have all been inching toward the goal of a perfect language, while FPC has not. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: John Briggs Sent: Monday, September 22, 2014 5:24 PM To: FPC developers' list Subject: Re: [fpc-devel] weak referencing (was Suggestion:.) Why has there been so many messages on this list debating the pros and cons of reference counting objects? The beauty of the Pascal language is in its structure ie: procedures,functions,OOP. Why does it need to be a functional programming language as well when there are Haskell, Lisp, Scheme and other functional languages that have already done the hard work. John ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Correct. I am only mentioning it as it is related to reference counted objects albeit trough interface. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Sven Barth Sent: Monday, September 22, 2014 10:49 PM To: fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] Suggestion: reference counted objects They are however only accessed through the implicitely generated interface and not through some object instance and thus the class ARC is not involved in any way, only the reference counting of interfaces and that already works. ;) Afterall anonymous functions were introduced before the class ARC :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Hi Giuliano, I was not talking hypothetical example. All of our products use this technology. Again, what you are telling me is some suggestion for probable solution, but even when you do it, you immediately add additional code and containers (list) just to support it due to the lack of ref counting. This immediately allows me to argue that your solution will use more memory and will be slower as it needs additional containers and support code altogether. So you basically are reconfirming yet again the advantages of using ref. counting. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Giuliano Colla Sent: Tuesday, September 23, 2014 2:11 AM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects Il 22/09/2014 23:04, Boian Mitov ha scritto: However you attempt to apply reference counting in this scheme, you'll realize that either it doesn't work at all, or it forces you to add a considerable amount of code, whose purpose would be only to fool reference counting, and artificially increase or decrease reference count. The same applies to your example, if it happens that when creating your data object you don't know which threads will consume it, because threads are created dynamically (captors activated and deactivated, options enabled/disabled, users connecting and disconnecting, etc). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Hi Sven,
There is no one list.
We have N number o data sources of many different types. The data from each
source is processed in a pipeline of threads that cane be reconfigured at any
time.
New sources and new data types can be added during the runtime by the customers.
The data from different pipelines can be merged split, sent over network and
anything in between.
This is 100% universal high performance high troghput graph parallel processing
of very much any type of data solution. You can learn more by looking at the
OpenWire Studio as example, (free download), but all the solutions are working
this way.
Any other approach has limitations, and indeed more overhead (i.e. additional
lists and code just to maintain the data)
With best regards,
Boian Mitov
---
Mitov Software
www.mitov.com
---
From: Sven Barth
Sent: Tuesday, September 23, 2014 6:06 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Suggestion: reference counted objects
Am 23.09.2014 11:11 schrieb "Giuliano Colla" :
> You have a number of threads creating thousands of data objects, which should
> be processed by "consumer" threads. Creating threads are unaware of how data
> will be used (it may depend on active options, and it follows the golden rule
> of "reusable code") so they can't send those objects anywhere. Therefore
> pointers to those objects are inserted in a list.
>
> A "consumer" thread can either process a data object, and then dispose of it,
> or leave it in the list for further processing, or move it to a different
> list, again depending on the selected options.
> This scheme can apply to quite a number of applications, from data collected
> in a real-time process to data-base transactions, etc.
>
> However you attempt to apply reference counting in this scheme, you'll
> realize that either it doesn't work at all, or it forces you to add a
> considerable amount of code, whose purpose would be only to fool reference
> counting, and artificially increase or decrease reference count.
I don't see where you would need to play around with the reference count in
your example. Following assumptions: the list only takes reference counted
objects (currently this would be interfaces, with the class-ARC that would be
object instances).
Now the producers add workitems to the list and may or may not keep an own
reference to that workitem (so refcount is - simplified - either 1 or 2).
A consumer now takes one object from the list, processes it, and either
discards it ("obj := Nil;") or reinserts it in the list. If it discards it then
either the object is now freed, if the producer did not keep a reference or
it's not if it did. If the consumer puts it back in the list, then the refcount
it still either 1 or 2 depending on what the producer did.
So I don't see where you'd need to manually fiddle around with the reference
count here.
If you'd of course mix reference and non-reference counted workitems then you'd
need to handle this, but then you should maybe overthink your implementation...
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
It used to be compatible, however since we rewrote it to use anonymous methods, and attributes (And reduced the code to 1/4 of the original size in the process) ~2 years ago, the new versions are not any more Lazarus compatible :-( . I have reflected that in the Wikipedia OpenWire page. I hope one day OpenWire will again be Lazarus/FPC compatible. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: silvioprog Sent: Tuesday, September 23, 2014 9:22 AM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects Is OpenWire compatible with FPC? -- Silvio Clécio My public projects - github.com/silvioprog ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
If you read the history: June 12, 2013 | 6.0 | Dropped Lazarus support due to lack of language features. It is not compatible any more :-( . Hope this will change. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: silvioprog Sent: Tuesday, September 23, 2014 9:37 AM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects On Tue, Sep 23, 2014 at 1:22 PM, silvioprog wrote: Is OpenWire compatible with FPC? Oops, yes. :-) http://en.wikipedia.org/wiki/OpenWire_(library) -- Silvio Clécio My public projects - github.com/silvioprog ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
np :-). The point is that no matter ref counting or a separated list+support code, you need additional overhead to maintain the objects. Arguably ref. counting is the one with the smaller overhead in this case, so even in his example ref. counting is already the better option. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: Sven Barth Sent: Tuesday, September 23, 2014 10:04 AM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects Am 23.09.2014 18:11 schrieb "Boian Mitov" : > There is no one list. I was solely referring to Guiliano's example, not yours. ;) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Yes, our solutions are among the most advanced that currently exist, and are on the cutting edge by any mean. Most of the technologies are developed by us to solve problems traditionally considered unsolvable ;-) . This is what keeps us in business ;-) . Most people do not understand how we can do what we do, but there is no magic. It is all very well developed (I dear to say), and at the end very simple code (Took many years to get it that simple :-D ). With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Giuliano Colla Sent: Tuesday, September 23, 2014 10:26 AM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects Il 23/09/2014 18:00, Boian Mitov ha scritto: Maybe I'm simple minded but I still have some pain understanding how a producer thread may manage to send an object to a one or more consumer threads which a) are unknown to it, and b) may not yet exist. Again not an hypothetical case. Just a different application frame. Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
This is a valid point. The only downside is that the object will every time do a deep copy versus a shallow (pointer only) copy. Deep copy is very, very expensive operation. Adding ref. counting to objects is probably equivalent of one interlocked assembly instruction, so a very small difference, probably not even measurable. Copy of a large object can take a large memory transfer, and will also reserve memory for each copy, thus significantly increasing memory. While both approaches have something going for them, they are not total subside for each other. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: August Oktobar Sent: Tuesday, September 23, 2014 10:35 AM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects To somebody (probably Sven): In FPC there is concept of stack based objects (object) that behave like classes (with inheritance)? Why not just extend this object with support for constructors and destructors, and there is no need for the ARC? On Mon, Sep 22, 2014 at 2:05 PM, Hans-Peter Diettrich wrote: Sven Barth schrieb: Am 22.09.2014 09:47 schrieb "Michael Schnell" Why not use "interface" to add ref-counting to an object ? This seems to work nicely even though the name "interface" in not "speaking" on that behalf. Because you'll need to declare an interface for each class you want to have reference counted so that you can access its methods, properties, etc. This overhead could be eliminated by another syntax extension, like TMyARCclass = interface(TObject) where the Compiler could allow for implementations of the declared methods just as for TMyARCclass = class(TObject) bridging the gap between traditional (strictly declarative) interfaces and classes (including implementations), with or without ARC. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Hi Pieter, I think I explained very clear. 1. Each reference assignment involves an atomic operation which, if used often enough will cause threads to wait and waste cycles. Correct you will lose ~3 assembly instructions (Interlocked increment/decrement-exchange, and conditional) It will happen only when you create a new reference which happens rather rarely. The impact will be less that 0.0001% of performance and probably many orders smaller On the other hand without this you already mentioned that you will need to create a list containing all the buffers. What is the performance impact on adding, removing from the list? What about the support code? I think your arguments are turning against you here. 2. Each reference assignment involves pulling the value referenced by a pointer and incrementing/decrementing it. In the process you will mess up with the cache of the current thread: data which was supposed to be in the cache for real work will be invalidated because of the ARC operation. The cache is a cache, the counter is part of the object you access, as long as you will be accessing the object (trough the pointer) it will need to be loaded into the cache, so I don't see any impact. 3. Already explained in 2. 4. Arc does not require virtual functions, however here is another misconception. Contrary to popular belief, on most processors virtual functions are executed faster than traditional functions. I can explain you the reasons for that on assembly, and cache level, but I think you can do your own research. Now, it is good that you managed to reduce your code by a factor of 4. Clearly this is not due to availability of ARC. Clearly what you do is not the only thing that programming languages are used for. So, the implication that we will all somehow benefit likewise if ARC is introduced is simply ludicrous. Everyone is entitled to their opinion. I share mine, and I share my experience, and I even share some of my code as open source. Others seem to prefer to just throw some imaginary arguments, not based on real experimental work. If you have done some benchmarks between ARC and non ARC based threading as we have done, you can share them, and you can have something to back up some of the claims you make. I have a lot of code and products to back my claims, so I am not just talking hot air, but a real concrete code, products and expertise. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Peter Popov Sent: Tuesday, September 23, 2014 12:51 PM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects Boian, since you keep on repeating the false argument that reference counting will somehow speed up parallel performance, I will restate the obvious: using reference counting will decrease parallel performance for the following obvious reasons: 1. Each reference assignment involves an atomic operation which, if used often enough will cause threads to wait and waste cycles. 2. Each reference assignment involves pulling the value referenced by a pointer and incrementing/decrementing it. In the process you will mess up with the cache of the current thread: data which was supposed to be in the cache for real work will be invalidated because of the ARC operation. 3. The cache of other threads will be similarly affected, even if the atomic operation does not involve other threads 4. ARC operations will likely involve virtual functions, which have overhead and do cause pointer running. In summary, in memory intensive code, where the bus bandwidth is fully utilized, ARC is a serious problem because of 2-4. In CPU intensive code 1 is a problem. Now, it is good that you managed to reduce your code by a factor of 4. Clearly this is not due to availability of ARC. Clearly what you do is not the only thing that programming languages are used for. So, the implication that we will all somehow benefit likewise if ARC is introduced is simply ludicrous. Peter On Tue, 23 Sep 2014 20:43:28 +0300, Boian Mitov wrote: Yes, our solutions are among the most advanced that currently exist, and are on the cutting edge by any mean. Most of the technologies are developed by us to solve problems traditionally considered unsolvable ;-) . This is what keeps us in business ;-) . Most people do not understand how we can do what we do, but there is no magic. It is all very well developed (I dear to say), and at the end very simple code (Took many years to get it that simple :-D ). With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Giuliano Colla Sent: Tuesday, September 23, 2014 10:26 AM To: FPC developers' list Subject: Re: [fpc-devel] Sugges
Re: [fpc-devel] Suggestion: reference counted objects
Yeah he does not seem to understand ARC that well :-( . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- From: Sven Barth Sent: Tuesday, September 23, 2014 2:17 PM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects Am 23.09.2014 21:52 schrieb "Peter Popov" : > 4. ARC operations will likely involve virtual functions, which have > overhead and do cause pointer running. There's no need for virtual methods for ARC. At least not in the design I envisioned for my RFC. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
This conversation is really getting nowhere, but you are right for one thing, when more virtual functions are used, which is becoming fairly common (At least for destructors etc.), the VMT tends to stay in the cache, and since VMT functions are smaller than full address functions the execution tends to be slightly faster on average :-) . So it seems you have figured out this common misconception properly. Now you only need to learn enough to realize some other misconceptions you have, but you already have a lot of information from a lot of people in the thread, so it will probably not be long :-) . With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Peter Popov Sent: Tuesday, September 23, 2014 3:54 PM To: FPC developers' list Subject: Re: [fpc-devel] Suggestion: reference counted objects Please, explain. The fundamental problem with virtual functions is pointer running. If your VMT reference is in the cache, sure, calling is fast. If object 1 execs a virtual to get object 2 who executes a virtual to get object 3 ... etc than you have a major problem. What are you going to do, keep all VMTs for all objects in the cache? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
