Hello,

I have a friend here in Brazil that added the `notify` support to the FGL lists, however he sented it to this Github PR [1].

I'm contacting him to explain how to send it to FPC bugtracker, so you can disconsider this PR at Github. :-)

Thank you!

[1]
https://github.com/fabianosalles/freepascal/commit/1d4cc907c806563c19e682676ac0e6676ae0a82b

"silvioprog" wrote

Hello, I have a friend here in Brazil that added the `notify` support to the FGL

lists, however he sented it to this Github PR [1].

I'm against that. That would negatively impact the performance of these lists.

Regards,
Sven

As I said, please discard this PR, because I'm contacting the member (Fabiano) to use mantis instead of Github, and I received other patch from other guy (Gilson) improving this changes.

"silvioprog" wrote

On Fri, Feb 19, 2016 at 10:24 AM, Sven Barth

FGL lists, however he sented it to this Github PR [1].

> > I'm against that. That would negatively impact the performance of these

lists.

As I said, please discard this PR, because I'm contacting the member

(Fabiano) to use mantis instead of Github, and I received other patch from other guy (Gilson) improving this changes.

It doesn't matter whether it is requested over here or on Mantis. I'm against adding notifications to the generic lists, because that will degrade their performance.

Regards,
Sven

On Fri, Feb 19, 2016 at 4:20 PM, Sven Barth
wrote:
[...]

It doesn't matter whether it is requested over here or on Mantis. I'm against adding notifications to the generic lists, because that will degrade their performance.

Can you send little bit sample showing this degradation? I can inform him to not send the patch because this problem. (I think that him isn't registered here in the list yet)

"silvioprog" wrote

On Fri, Feb 19, 2016 at 4:20 PM, Sven Barth

[...] > It doesn't matter whether it is requested over here or on Mantis. I'm

against adding notifications to the generic lists, because that will degrade their performance.

Can you send little bit sample showing this degradation? I can inform him

to not send the patch because this problem. (I think that him isn't registered here in the list yet)

There's no need for a sample. This degradation is the whole reason why the non-generic classes TFPObjectList and TFPList exist compared to TObjectList and TList which do have notifications.

Regards,
Sven

Sven Barth wrote

There's no need for a sample. This degradation is the whole reason why the non-generic classes TFPObjectList and TFPList exist compared to TObjectList and TList which do have notifications.

I don't use Generics so it doesn't bother me either way. But purely from a software design point of view, it should be quite easy to create a list where notification can be enabled or disabled at runtime - maybe as a parameter to the constructor or via a property. On disabling notification there should be near zero degradation - at least not something noticeable.

Just my 2¢ worth.

Regards,
- Graeme -

Hm, two points.

1. I'm using FGL containers a lot (because I like type-safety given by generics), and I agree that adding a notification mechanism there can slow them down. Mostly at allocation (because a deallocation is already burdened down by having to do Deref() on every item, so it would probably not suffer *so much* with unassigned OnNotify).

2. But this should not stop us from making a "generic container with notification" classes. Maybe as new classes, maybe as a boolean toggle to existing classes (as Graeme nicely suggests).

Right now we only have "with notifications, and not type-safe" containers (TObjectList/TList) and "without notifications, and type-safe using generics" containers (TFPObjectList/TFPList). But these two features (1. notifications and 2. type-safety thanks to generics) should be independent. It makes sense to create a "with notifications, and type-safe using generics" option.

So I would not reject the idea so quickly. But it indeed should be implemented carefully, without slowing down the existing TFPObjectList/TFPList.

Regards,
Michalis

Notifications events already works in Generics.Collections. ;P

"Maciej Izak" wrote

Notifications events already works in Generics.Collections. ;P

Which reminds me that I wanted to work on integrating them...

Regards,
Sven

MSVC does (hence I didn't include it) but all previously listed compilers don't remove the loop.
The time ratio is about
FPC - 100, Delphi 7, Borland C - 50, C# - 25, MSVC - 0.

So my doubts was about extra-code generation for the loops.

Regards,
Serguei

After more than 20 years in software engineering I'm avoiding to use the phrases like "real world program" or I put in quotes the word "real" at least :)

It shows that gcc do the same kind of optimization as MSVC (hence I didn't include it), but other don't.
See my answer to Jonas for more details.

Regards,
Serguei

I agree.
Actually TFPGList has already an overhead vs TList (related tests http://arbinada.com/main/en/node/1411) and it is not a good idea to increase it.
Why not simple create subclass to implement events?

Regards,
Serguei

These latter 2 are not generics based. There was some experimental code which attempted to implement TFPObjectList/TFPList on top of generics, but they were slower than the native implementation. That experiment is unmaintained.

TFPGList is the one you meant, probably.

Michael.

20.02.2016, 02:05, "Sven Barth" :

There's no need for a sample. This degradation is the whole reason why the non-generic classes TFPObjectList and TFPList exist compared to TObjectList and TList which do have notifications. Regards, Sven

/ My previous mail appeared to be in html format. Sorry for that.

Hi

That always keeps me wondering - why neither FPC, no any other mainstream static-type language implements specialization based not only on types, but on compile-time constants as well?

I mean something like

  TGenericList<T,options> = class
    ...
  end;

procedure TGenericList<T,options>.Delete(index:integer);
begin
  if (nnNotifyDelete in options) and Assigned(FOnDelete) then
    FOnDelete(...);
  end;
end;
// usage
type
  TMyList = specialize TGenericList<integer, [nnNotifyAdd, nnNotifyDelete, nnNotifyChange]>;

... that "if (nnNotifyDelete in options) " condition will optimized out by compiler if options lack corresponding enum constant. Of course, FOnDelete property should be omitted as well in ideal case. That might require something like "static if" in D.

I've done that trick for ages using m4 preprocessor and it works really good, why it's still not supported natively by compilers themselves?

Michalis Kamburelis wrote

So I would not reject the idea so quickly. But it indeed should be implemented carefully

And it will take 5-10 minutes to write some unit tests to see exactly what speed penalty would occur. Why guess or assume. Write some unit tests and get the facts! Then go from there.

Regards,
- Graeme -

Ups. Yeah, by "without notifications, and type-safe using generics" containers I meant TFPGList and TFPGObjectList (and other TFPGXxx) from the FGL unit.

Regards,
Michalis

"denisgolovan" wrote

Hi That always keeps me wondering - why neither FPC, no any other mainstream

static-type language implements specialization based not only on types, but on compile-time constants as well?

Then you don't consider C++ as mainstream, do you?

nnNotifyDelete, nnNotifyChange]>;

I had thought about this some time ago and then found a reason why I wouldn't do it... Now if I'd only remember that reason -.-

Regards,
Sven

21.02.2016, 02:59, "Sven Barth" :

Then you don't consider C++ as mainstream, do you? Regards, Sven

Hm. Looks like C++ actually does that and that's great. Unfortunately I stopped using C++ for large projects about 12 years ago, so my C++ template knowledge must be too old :)

I had thought about this some time ago and then found a reason why I wouldn't do it... Now if I'd only remember that reason -.-

Yes, it's interesting to see why. It's wildly useful and gives a lot of power.