On 21.09.2014 21:09, Hans-Peter Diettrich wrote:
Sven Barth schrieb:
On 20.09.2014 13:42, Sven Barth wrote:
On 20.09.2014 13:11, Peter Popov wrote:
- to remedy this TObject is extended with non-virtual methods that
allow manual reference counting and would rely on the RTTI data I
mentioned
On 21.09.2014 21:29, Peter Popov wrote:
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).
Huh? Why do you think that? It would just be that variables with a
On 22.09.2014 00:13, Boian Mitov wrote:
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
Am 21.09.2014 06:13, schrieb Jonas Maebe:
On 21/09/14 08:10, Samuel Herzog wrote:
But its not accepted.
*procedure* TFormThreading.Button1Click(Sender: TObject);
*var*
aTask: ITask;
**procedure* *MyTask*;
*begin*
*sleep (3000); // 3 seconds*
*ShowMessage (Hello);*
*
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
On 09/20/2014 01:42 PM, Sven Barth wrote:
a farmer doesn't eat what he doesn't know
Really healthy laughter from Germany,
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 09/21/2014 07:17 PM, Boian Mitov wrote:
In general I would prefer to see this implemented with attributes
rather than with new keywords.
Yet another attribute to class.
This might (re-)trigger thought about a complete rework of of
record-enhancing types and allow for the record and object
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
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
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
Am 22.09.2014 10:54 schrieb Michael Schnell mschn...@lumino.de:
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
Am 22.09.2014 10:38 schrieb Michael Schnell mschn...@lumino.de:
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
Am 22.09.2014 09:47 schrieb Michael Schnell mschn...@lumino.de:
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 ?
On 09/22/2014 11:13 AM, Sven Barth wrote:
Interfaces, strings and arrays already work well in multi threaded
contexts and ARC will use the same mechanisms here, so there is no
need to discuss parallel and ARC together.
Yep. it will work.
But one point speaking against ARC is performance
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
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.
(to Sven)
So the cycle break mechanism is going to be marking potential cycle cases
as weak.
Do you still plan to at least detect cycles for debugging purposes?
Or is the cycle detection itself already too hard?
IOW I'm wondering what will happen (and what to do) if there is a cycle in a
Sven Barth schrieb:
On 21.09.2014 21:09, Hans-Peter Diettrich wrote:
Sven Barth schrieb:
[...]
I'd add a _RefCount field to TObject, regardless of whether it's really
used later; this will fix the field offset - just like the VMT reference
is fixed in TObject, but not in Object types. This
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:
Florian Klämpfl wrote:
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
On 09/22/2014 07:52 AM, Sven Barth 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... -.-
Maybe instead of attribute appropriate base classes could be provided.
E.g. a
Am 22.09.2014 11:57 schrieb Marco van de Voort mar...@stack.nl:
(to Sven)
So the cycle break mechanism is going to be marking potential cycle cases
as weak.
Basidally, yes.
Do you still plan to at least detect cycles for debugging purposes?
Or is the cycle detection itself already too
Sven Barth schrieb:
Am 22.09.2014 09:47 schrieb Michael Schnell mschn...@lumino.de
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
Marco van de Voort schrieb:
(to Sven)
So the cycle break mechanism is going to be marking potential cycle cases
as weak.
Do you still plan to at least detect cycles for debugging purposes?
Or is the cycle detection itself already too hard?
IOW I'm wondering what will happen (and what to do)
Am 22.09.2014 14:19 schrieb Michael Schnell mschn...@lumino.de:
On 09/22/2014 07:52 AM, Sven Barth 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... -.-
Maybe instead of
Am 22.09.2014 12:59 schrieb Hans-Peter Diettrich drdiettri...@aol.com:
Sven Barth schrieb:
On 21.09.2014 21:09, Hans-Peter Diettrich wrote:
Sven Barth schrieb:
[...]
I'd add a _RefCount field to TObject, regardless of whether it's really
used later; this will fix the field offset - just
On 09/22/2014 02:34 PM, Sven Barth wrote:
I already suggested the addition of a TARCObject as a general
reference counted base class in my RFC ;)
So I am proud to have independently recreated your idea :-)
-Michael
___
fpc-devel maillist -
Am 22.09.2014 14:30 schrieb Hans-Peter Diettrich drdiettri...@aol.com:
Sven Barth schrieb:
Am 22.09.2014 09:47 schrieb Michael Schnell mschn...@lumino.de
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
Am 22.09.2014 11:22 schrieb Michael Schnell mschn...@lumino.de:
On 09/22/2014 11:13 AM, Sven Barth wrote:
Interfaces, strings and arrays already work well in multi threaded
contexts and ARC will use the same mechanisms here, so there is no need to
discuss parallel and ARC together.
Yep. it
Am 22.09.2014 14:31 schrieb Hans-Peter Diettrich drdiettri...@aol.com:
Marco van de Voort schrieb:
(to Sven)
So the cycle break mechanism is going to be marking potential cycle cases
as weak.
Do you still plan to at least detect cycles for debugging purposes?
Or is the cycle detection
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
In our previous episode, Sven Barth said:
Do you still plan to at least detect cycles for debugging purposes?
Or is the cycle detection itself already too hard?
IOW I'm wondering what will happen (and what to do) if there is a cycle
in a
sufficiently complex program.
At least I
On 09/22/2014 02:19 PM, Hans-Peter Diettrich wrote:
AFAIK *variant* records (currently) can not be replaced by something else.
I suppose you are right, but maybe appropriate syntax can be introduced
to class definition that might be helpful in certain instances.
-Michael
On 09/22/2014 02:05 PM, Hans-Peter Diettrich wrote:
TMyARCclass = interface(TObject)
IMHO, Sven's idea of introducing a TARCObject base class (triggering
the compiler magic for ref counting) sounds a lot nicer.
-Michael
___
fpc-devel maillist -
In our previous episode, Hans-Peter Diettrich said:
Do you still plan to at least detect cycles for debugging purposes?
Or is the cycle detection itself already too hard?
IOW I'm wondering what will happen (and what to do) if there is a cycle in a
sufficiently complex program.
I
How will referenced objects behave when referenced by a threadvar. This is an
exceptional situation for both dynamic arrays and ansi strings.
Another comment: If referenced objects all derive from a single base, then, the
user cannot possibly have another hierarchy, which uses ref. objects. As
On 22 Sep 2014, at 16:44, Peter Popov wrote:
Another comment: If referenced objects all derive from a single
base, then, the user cannot possibly have another hierarchy, which
uses ref. objects. As I mentioned earlier, I do this explicitly for
an object well down my hierarchy. So, it
From: jonas.ma...@elis.ugent.be
To: fpc-devel@lists.freepascal.org
Date: Mon, 22 Sep 2014 17:11:08 +0200
Subject: Re: [fpc-devel] weak referencing (was Suggestion:.)
I would strongly recommend against that. Referenced and unreferenced objects
are completely different beasts with different
Although TBH what i'd prefer more than the above is language features that
would allow me to implement refcounted objects myself. Stuff like automatic
destruction when a generic variable goes out of scope, etc.
On Mon, Sep 22, 2014 at 5:45 PM, Kostas Michalopoulos
badsectorac...@gmail.com wrote:
I prefer the TARCObject approach too, i don't want anything to be
refcounted unless i *explicitly* ask for it (yes i know some things are
already refcounted and at the past i was bitten by that which is a big
reason why i don't want hidden things to do magic stuff behind my back).
Also i don' want
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
Am 22.09.2014 16:45 schrieb Peter Popov ppo...@hotmail.com:
How will referenced objects behave when referenced by a threadvar. This
is an exceptional situation for both dynamic arrays and ansi strings.
There is no need for special handling, afterall a threadvar is (roughly) as
if you had
Am 22.09.2014 17:11 schrieb Jonas Maebe jonas.ma...@elis.ugent.be:
On 22 Sep 2014, at 16:44, Peter Popov wrote:
Another comment: If referenced objects all derive from a single base,
then, the user cannot possibly have another hierarchy, which uses ref.
objects. As I mentioned earlier, I do
Am 22.09.2014 17:33 schrieb Peter Popov ppo...@hotmail.com:
I will add another comment to the race condition issues: they are easily
avoided by a single line assembly atomic inc/dec. It however will not
resolve performance issues where a certain function assigns classes
references left and right
Am 22.09.2014 18:52 schrieb Boian Mitov mi...@mitov.com:
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
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
Hi Sven,
Yes I knew the problem in the latter approach. However my thinking is that
some features can be derived from others and I believe that this applies
here too.
So by adding these extension to records and the operator overload the
feature can be implemented as a library extension. Also
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
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
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
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
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++
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
Here is example from our implementation:
for AIndex := 0 to Length( AList ) - 1 do
AExecutionTask.Add(
FExecutor.Execute(
TDelegate.CaptureInteger( AIndex,
procedure( ALocalIndex : Integer )
begin
Sleep( 1000 ); // Simulate thread busy
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
On 09/22/2014 08:28 PM, Boian Mitov wrote:
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,
Or on the heap:
==
Type
TMyRecord =
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:
I suggest doing one thing at a time. ARC class first, complex delegates
capturing local context later
In my opinion having ARC class would be a great advantage. As far as I
know this feature was proposed many times in the past. Developers have
been asking for it for years. It just feels right
Hi
recently we ported a code using 4 dimensional variant array to fpc. The
code, originally in Delphi, used VarArrayLock/Unlock to get a handle on
the array and write directly on iy. It turned out that the layout is not
as it is in delphi, and we could not figure out what it was.
The
On 22/09/14 22:17, hinstance wrote:
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.
That's because you can't have circular references between interfaces,
since interfaces don't have fields. Similarly, you
On Mon, 22 Sep 2014 21:34:34 +0300, Boian Mitov mi...@mitov.com 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,
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
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
Am 22.09.2014 22:23 schrieb hinstance hinsta...@yandex.ru:
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
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
Sven Barth schrieb:
Am 22.09.2014 12:59 schrieb Hans-Peter Diettrich drdiettri...@aol.com
That's why I also suggested an compiler option, useful for all people
which care about program size or ARC at all.
The problem with the compiler option is that you'd need to rebuild the
complete
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
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
On Mon, Sep 22, 2014 at 07:21:46PM +0200, Sven Barth wrote:
Am 22.09.2014 17:11 schrieb Jonas Maebe jonas.ma...@elis.ugent.be:
On 22 Sep 2014, at 16:44, Peter Popov wrote:
Another comment: If referenced objects all derive from a single base,
then, the user cannot possibly have another
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
On 22.09.2014 23:37, Boian Mitov wrote:
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
On 23.09.2014 02:24, John Briggs wrote:
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
72 matches
Mail list logo
