(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 sufficiently complex program.

I could imagine a tool for that purpose, instead of burdening the compiler with such rarely used functionality. More diagnostics could be removed from the compiler, like the detection of unused local variables or units - if that helps to speed up compilation. Separate diagnostic tools could immediately offer means to solve the detected problems interactively, what's not the purpose of an compiler.

DoDi

Basidally, yes.

in a

sufficiently complex program.

At least I want to test such an algorithm to see how it performs.

Regards,
Sven

in a

> sufficiently complex program. I could imagine a tool for that purpose, instead of burdening the

compiler with such rarely used functionality. More diagnostics could be removed from the compiler, like the detection of unused local variables or units - if that helps to speed up compilation. Separate diagnostic tools could immediately offer means to solve the detected problems interactively, what's not the purpose of an compiler.

These diagnostics help the compiler to remove application code it doesn't need to generate. So why should I remove them? Also these diagnostics are quite fast already. Other more costly optimizations are already optional using the -Ox options.

Additionally the cycle detection algorithm wouldn't be run at compiletime anyway, during every reference count decrease.

Regards,
Sven

In our previous episode, Sven Barth said:

My point was a bit that if possible, we need it anyway, even if only as a heaptrc or -C<runtimecheck> option.

In our previous episode, Hans-Peter Diettrich said:

I was not thinking about static, but runtime analysis.

I didn't say anything about compiler at all, I was more thinking RTL.

More diagnostics could be removed from the compiler, like the detection of unused local variables or units - if that helps to speed up compilation

Those are inheritly static. But cycles are afaik not.

Separate diagnostic tools could immediately offer means to solve the detected problems interactively, what's not the purpose of an compiler.

If I read all the happy users on this thread, I believe this feature will be absolutely peachy :-)

So since then this is only needed for extreme cases, such interactivity might be a bit too much :-)

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 I mentioned earlier, I do this explicitly for an object well down my hierarchy. So, it seems to me you still need something like:

-- code --

TRefObject = referenced class(TWhateverBase)
end;

-- end of code --

Date: Mon, 22 Sep 2014 14:54:31 +0200
From:
To:
Subject: Re: [fpc-devel] weak referencing (was Suggestion:.....)

These diagnostics help the compiler to remove application code it doesn't need to generate. So why should I remove them? Also these diagnostics are quite fast already. Other more costly optimizations are already optional using the -Ox options.

Additionally the cycle detection algorithm wouldn't be run at compiletime anyway, during every reference count decrease.

Regards,

Sven

I would strongly recommend against that. Referenced and unreferenced objects are completely different beasts with different behaviours. If you allow that, you get all kinds of problems down the line. E.g. you either have to forbid assigning a TRefObject to a TWhateverBase (which runs counter to a very basic OOP principle), or allow it and then have the programmer deal with the resulting reference counting mess-ups.

Just like Objective-C and C++ classes cannot derive from each other, and just like Delphi-style classes and TP-style objects and objcclass and cppclass cannot derive from each other, so should reference counted and non-reference counted classes not be able to derive from each other. If you want to mix reference counted and non-reference counting functionality, use the existing interface-based pattern instead, or possibly some kind of delegation pattern.

Jonas

From:
To:
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 behaviours. If you allow that, you get all kinds of problems down the line. E.g. you either have to forbid assigning a TRefObject to a TWhateverBase (which runs counter to a very basic OOP principle), or allow it and then have the programmer deal with the resulting reference counting mess-ups. Just like Objective-C and C++ classes cannot derive from each other, and just like Delphi-style classes and TP-style objects and objcclass and cppclass cannot derive from each other, so should reference counted and non-reference counted classes not be able to derive from each other. If you want to mix reference counted and non-reference counting functionality, use the existing interface-based pattern instead, or possibly some kind of delegation pattern.------ Indeed, this is a valid point. By the same logic, TRefObject should be a base object, should not inherit from TObject and its instance references should not be assignable to pointers. I tried to make the last point earlier. If you ask me, implicit ref. counting will not eliminate the mess of managing what one has created by his own will. If you create it, you are its Creator, so you must destroy it :-) But ... as long as TObject stays intact, I am ok with whatever happens. 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 and there are multiple threads. The fact that you can easily protect it does not mean that you will retain parallel efficiency. Thread-syncing should be left to the programmer to optimize. Peter

"Peter Popov" wrote

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 defined a variable locally to your thread's procedure. If you have e.g. two threads and a threadvar of a reference counted class type then thew are basically two possibilities:
- you assign two different instances of that variable's class type (or one of its child classes) to each threadvar "instance"; in that case both class instances will have refcount one (if they aren't referenced anywhere else) and each will be freed when its corresponding thread goes out of scope (if threadvar finalization works correctly, bit that is a different topic)
- you assign the same class instance to both threadvar "instances"; then the reference count will be 2 (if it isn't referenced anywhere else) and the instance will be freed once the last of the two threads finalizes its threadvars.

It's the same for interfaces, strings and arrays. The special handling is only for threadvars in general, but not for the types it holds.

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 seems to me you still need something like:

That's what I suggested in my RFC: have a possibility to declare a class somewhere down the hierarchy as reference counted and provide - using this possibility - a direct reference counted descendant of TObject inside the System unit for convenience reasons.

Regards,
Sven

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 seems to me you still need something like:

objects are completely different beasts with different behaviours. If you allow that, you get all kinds of problems down the line. E.g. you either have to forbid assigning a TRefObject to a TWhateverBase (which runs counter to a very basic OOP principle), or allow it and then have the programmer deal with the resulting reference counting mess-ups.

As written in my RFC I would go the "allow it" route and provide mechanisms to manually access the reference count from a non-reference counted variable (thus being implemented in TObject). Optionally one could add a warning that is off by default that one could use for such cases. This approach is necessary, because we'd otherwise need to introduce overloads for e.g. RTTI functionality in TypInfo or to introduce some compiler magic for them (I don't like either of these two possibilities).

Regards,
Sven

"Peter Popov" wrote

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 and there are multiple threads. The fact that you can easily protect it does not mean that you will retain parallel efficiency. Thread-syncing should be left to the programmer to optimize.

Of course the reference count changing would use atomic operations (in Pascal implemented by the Interlocked* group of functions) just as it is done for strings, arrays and interfaces. Thuse there would be no need to worry about race conditions regarding the reference counting, only for the class logic itself which is the developer's job anyway.

Regards,
Sven

Sven
At the risk of starting a flame war I have been pondering this question since these threads have started:

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

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
-------------------------------------------------------

Because people want new features. There are Delphi programmers that look at FPC and think "It does not support XYZ, so I won't use it", even if it would allow them to target a broader user range. And then there are FPC programmers that look at Delphi (or other languages) and think "I wish FPC would support that" (I'm often part of that latter category ;) ). Also ARC has nothing to do with functional programming languages, afterall Objective C has ARC as well and I wouldn't consider that a functional language ;)

Regards,
Sven

Il 23/09/2014 02:24, John Briggs ha scritto:

Because many of us are scared to death from the idea of adding as a default a "feature" which could break millions of lines of existing code, degrade performance, and create incredible debugging headaches, without bringing any benefit to the overwhelming majority of users.

Giuliano

In our previous episode, Sven Barth said:

Because people want new features. There are Delphi programmers that look at FPC and think "It does not support XYZ, so I won't use it", even if

IMHO a very large percentage of them will just find the next excuse.

More importantly, is it really healthy to focus on new users only? We are not embarcadero that only get money from new licenses.

That's why I'm not going to implement e.g. ARC as Embarcadero did it, but instead listen to input from the community to find a better solution that more users can live with.
Also at least in my opinion it's not only about new features for the sake of feature or to get Delphi developers, but to use the one or other nice library that relies on Delphi 2010+ features; currently these are for me:
- Spring4D (or so) framework
- OmniThreadLibrary
- Thrift

Regards,
Sven

You can do it in the same way as we handle ansistrings with different codepages in the RTL (with a procedure modifier). I really think they should be completely incompatible entities that have nothing to do with each other whatsoever at the language level, since they have to be handled completely differently by the compiler. Just like Objective-C, C++ classes and TP-style objects.

Jonas

IMO, it's very unlikely that this feature will be accepted in FPC in a form that breaks existing code. FPC has always been very strict about keeping backward compatibility. New features are almost always added in a way that don't break existing code.

Nikolay

That's because most people who complaining about the lack of these features, don't do any work to implement them and submit patches.

Nikolay