On Fri, 19 Sep 2014, Boian Mitov wrote:
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
On 20/09/14 00:07, Boian Mitov wrote:
---
-Original Message- From: Jonas Maebe
Sent: Friday, September 19, 2014 2:10 PM
To: FPC developers' list
Subject: Re: [fpc-devel] RTTI generating
Why do you take one paragraph out of context
Am 20.09.2014 04:40 schrieb Gennady Agranov gennadyagra...@gmail.com:
Hi,
I do not have clear picture about initialization of local variables - are
they initialized to some default value or not - and is there a way to
assure that every local variable (including record types) is set to some
Am 20.09.2014 05:01 schrieb Den cyr...@gmail.com:
Hi Sven,
What would you say the status on Generic Methods/Functions if you
were to give a status for it?
In my local repository I have global functions/procedures working
(something that Delphi can not ;) ), but methods not yet. Also I
Am 20.09.2014 01:52 schrieb Hans-Peter Diettrich drdiettri...@aol.com:
Boian Mitov schrieb:
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
Am 20.09.2014 00:46 schrieb Boian Mitov mi...@mitov.com:
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.
There wasn't that much work
Hello,
In platforms with managed code (.NET, Java), objects are automatically
freed by the memory manager / garbage collector.
Would not it be interesting to have a similar feature in FPC?
For example, through a root class where its objects are counted by
reference, like the TInterfacedObjects.
On 20.09.2014 06:36, Fabrício Srdic wrote:
Hello,
In platforms with managed code (.NET, Java), objects are automatically
freed by the memory manager / garbage collector.
Would not it be interesting to have a similar feature in FPC?
For example, through a root class where its objects are
I will add quick comment to this discussion: our products heavily rely on
the automated keyword, introduced in Delphi 2. What we use it for is
either to link dynamically GUI elements to particular code, or to do a
particular form of RPC. That is, the gui does not in advance the structure
of the
I am interested.
On Sat, 20 Sep 2014 00:38:26 +0300, Boian Mitov mi...@mitov.com wrote:
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
Fabrício Srdic schrieb:
Hello,
In platforms with managed code (.NET, Java), objects are automatically
freed by the memory manager / garbage collector.
Would not it be interesting to have a similar feature in FPC?
AFAIK some Delphi XE made TObject itself managed, by reference counting.
It
Sven Barth schrieb:
Am 20.09.2014 01:52 schrieb Hans-Peter Diettrich drdiettri...@aol.com
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.
The extended RTTI introduced with Delphi 2010
On 20.09.2014 12:11, Hans-Peter Diettrich wrote:
Sven Barth schrieb:
Am 20.09.2014 01:52 schrieb Hans-Peter Diettrich drdiettri...@aol.com
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.
On 20.09.2014 12:36, Hans-Peter Diettrich wrote:
Fabrício Srdic schrieb:
Hello,
In platforms with managed code (.NET, Java), objects are automatically
freed by the memory manager / garbage collector.
Would not it be interesting to have a similar feature in FPC?
AFAIK some Delphi XE made
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
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
On Sat, 20 Sep 2014 13:52:57 +0300, Sven Barth
pascaldra...@googlemail.com wrote:
On 20.09.2014 12:36, Hans-Peter Diettrich wrote:
Fabrício Srdic schrieb:
On 20.09.2014 13:11, Peter Popov wrote:
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
Please enlighten me why you think it is bad. Give reasons and don't be
like a farmer doesn't eat what he doesn't know (rough
On 09/20/2014 01:42 PM, Sven Barth wrote:
On 20.09.2014 13:11, Peter Popov wrote:
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
Please enlighten me why you think it is bad. Give reasons and don't be
like a farmer
On Sat, 20 Sep 2014, Sven Barth wrote:
On 20.09.2014 13:11, Peter Popov wrote:
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
Please enlighten me why you think it is bad.
Simple:
For one, it will slow down
Hello all,
IMO the best way to implement this is by controlling the TObject behaviour
through a compiler switch, something like enable globally, disable
globally, enable for specific class and in the latter case another
switch should mark the class that should have this behaviour enabled.
This
In our previous episode, Sven Barth said:
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
Please enlighten me why you think it is bad. Give reasons and don't be
like a farmer doesn't eat what he doesn't know
Sven Barth schrieb:
On 20.09.2014 12:36, Hans-Peter Diettrich wrote:
AFAIK some Delphi XE made TObject itself managed, by reference counting.
It would be easy to introduce the same feature in FPC, so that no
special base class would be required. Like with extended RTTI a decision
should be
On Sat, Sep 20, 2014 at 1:52 PM, Sven Barth pascaldra...@googlemail.com
wrote:
It's basically easy, yes, but then one has to deal with code like this:
=== code begin ===
somestrlist.AddObject('Foobar', TObject(42));
=== code end ===
This sort of typecast was usually used to implement
Link to Lazarus forum thread with reference counting discussion: http://forum.lazarus.freepascal.org/index.php/topic,22231.0.htmlMy opinion: yes, this feature should be implemented.And yes it should be optional (either additional root object or local compiler switch), so that existing code could
Am 19.09.2014 um 22:49 schrieb Boian Mitov:
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
Am 20.09.2014 um 08:47 schrieb Michael Van Canneyt:
Personally, I can't wait to see Joost's implementation of extended RTTI and
attributes merged to the
trunk compiler.
Is it finished? I thought it is still work in progress?
___
fpc-devel
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
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
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
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,
On Sat, Sep 20, 2014 at 10:24 AM, Chriss Kalogeropoulos
iz.iznog...@gmail.com wrote:
Hello all,
IMO the best way to implement this is by controlling the TObject behaviour
through a compiler switch, something like enable globally, disable
globally, enable for specific class and in the latter
On Sat, Sep 20, 2014 at 8:02 AM, Chriss Kalogeropoulos
iz.iznog...@gmail.com wrote:
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
Hello all,
Instead of hardcoding stuff into the (amazing) fpc compiler, would it be
possible to use generics and operator overloading to create a smart pointer
implementation?
This might require some improvements like record constructors/destructors
(or initializer/finalizer) and some way to
What about adding support for destructors to (advanced) records (and/or
inhertiance)?
On Sat, Sep 20, 2014 at 6:36 AM, Fabrício Srdic fabricio.sr...@gmail.com
wrote:
Hello,
In platforms with managed code (.NET, Java), objects are automatically
freed by the memory manager / garbage collector.
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:
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
You don't miss anything, we agree. That is why I propose an explicit
implementation either using a compiler switch or generic records (smart
pointer). This way the developer has full control on when the feature is
used or not. The smart pointer approach is more flexible I believe.
Sorry for the
Am 20.09.2014 20:34 schrieb Giuliano Colla giuliano.co...@fastwebnet.it:
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
Am 20.09.2014 20:04 schrieb Boian Mitov mi...@mitov.com:
This is actually a very good idea IMHO!
I would vote for it. Record inheritance is something I miss badly in
Delphi.
If you want inheritance, then use object. Period.
What I do think about though is initializers/finalizers or something
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
Am 20.09.2014 18:05 schrieb Florian Klämpfl flor...@freepascal.org:
Am 20.09.2014 um 08:47 schrieb Michael Van Canneyt:
Personally, I can't wait to see Joost's implementation of extended RTTI
and attributes merged to the
trunk compiler.
Is it finished? I thought it is still work in
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
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
Hi,
I will address multiple previous e-mails on this subject :)
1. FPC does perform reference counting if variable type is interface,
but not if variable type is class that implements interface -
legacy/compatibility reasons?
If you want to do ARC for objects - just remove this limitation
Am 20.09.2014 21:40 schrieb Boian Mitov mi...@mitov.com:
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.
Maybe you could document the binary format of the
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
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
Hi Boian,
I'm easily convinced that you've developed a lot of things using
reference counting. Design is the art of compromise, and possibly in
your class of application that's the best compromise.
But we should never forget that our class of applications isn't the only
possible one in the
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
On Sat, Sep 20, 2014 at 3:43 PM, Boian Mitov mi...@mitov.com wrote:
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
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';
Boian Mitov schrieb:
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
Sven Barth schrieb:
Am 20.09.2014 20:34 schrieb Giuliano Colla
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.
That would work the same way as it does in interfaces,
Giuliano Colla schrieb:
Hi Boian,
I'm easily convinced that you've developed a lot of things using
reference counting. Design is the art of compromise, and possibly in
your class of application that's the best compromise.
But we should never forget that our class of applications isn't the
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
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
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
Boian Mitov schrieb:
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.
The problem arises when an object is destroyed, or even elected for
destruction in _Release, while another
58 matches
Mail list logo
