Features for money ?

[kupferstecher]

@440bx:
Why are you getting that off-topic in "your own" thread?
The discussion about a single specific feature (in a way that it is not just used as an example) gives me the impression, that my scepticism was right and your reguest for "features for money" actually has the aim to push something through, that otherwise would be rejected.

[440bx]

@440bx:
Why are you getting that off-topic in "your own" thread?

There is Marco to thank for that. 

The discussion about a single specific feature (in a way that it is not just used as an example) gives me the impression, that my scepticism was right and your reguest for "features for money" actually has the aim to push something through, that otherwise would be rejected.

I used that feature as an example.  Yes, it is one that I am interested in.  Anyone is more than welcome to provide their own example of features they would be willing to support, since I don't know what those are, I can't use them as examples.

If telling yourself you were "right" makes you feel good, by all means, be my guest.

[Akira1364]

I've posted about it before, but this library / program: https://github.com/neslib/Chet

gives pretty much 100% correct translations of basically any header you throw at it (for which it has its use of libClang to thank, specifically).

The only caveats are that it's designed specifically for Delphi, and also that it does tend to leave in a number of "unrelated" definitions for things (which you'll of course generally want to remove from the "final version" of a given translation.)

I'm currently working on a proper FPC port of it though, as even as-is it's way, way, way better than H2Pas. (No offense meant by that, but really, I don't think anyone has ever claimed H2Pas was "good". It relies on a (port) of a (really outdated) version of, uh, Yacc after all...)

Well, it is a fact that a variant of TStringList based on generics was slower than the non-generic one. And especially if managed types (strings for example) are involved untyped pointers are indeed faster, but I personally favor the increased type safety I get with generics.

Again, I'm not a fan of the general tone of the post you were responding to there, but the "generic TStringList was slower because of generics" thing is absurd.

It was slower almost entirely because the specific implementation of maps in FGL (one of which the generic TStringList used internally) is awful. (I.E. they are in no way, whatsoever, actual hashmaps, amongst various other flaws.)

Were it based around stuff from the current revision of Generics.Collections, it would almost certainly be quite a bit faster.

In general: FPC monomorphizes generics in all cases, thus, they cannot be slower, because they are literally the same thing as a directly equivalent non-generic implementation.

[440bx]

I'm currently working on a proper FPC port of it though,

I'm really looking forward to your port of it.

Do you have some rough idea as to when you might be done with it ?

[Akira1364]

Do you have some rough idea as to when you might be done with it ?

Soonish. Currently the blocker is just that the GUI "frontend" app for it went ahead and used Delphi 10's "TCardPanel", which Lazarus does not implement, making the app rather annoying to translate without destroying the LFM file.

I've gotten a skeleton of it going with the "TDI" Lazarus package, and am currently just carefully trying to make sure I don't break any of the original UI behavior.

[440bx]

Soonish.

Very nice!.

Currently the blocker is just that the GUI "frontend" app for it went ahead and used Delphi 10's "TCardPanel", which Lazarus does not implement, making the app rather annoying to translate without destroying the LFM file.

There is always something... <chuckle>

I've gotten a skeleton of it going with the "TDI" Lazarus package, and am currently just carefully trying to make sure I don't break any of the original UI behavior.

Nice.

Thank you for the update on your progress.

[PascalDragon]

Well, it is a fact that a variant of TStringList based on generics was slower than the non-generic one. And especially if managed types (strings for example) are involved untyped pointers are indeed faster, but I personally favor the increased type safety I get with generics.

Again, I'm not a fan of the general tone of the post you were responding to there, but the "generic TStringList was slower because of generics" thing is absurd.

It was slower almost entirely because the specific implementation of maps in FGL (one of which the generic TStringList used internally) is awful. (I.E. they are in no way, whatsoever, actual hashmaps, amongst various other flaws.)

To be fair: I have never looked at the generic TStringList, thus I hadn't present that it's based on TFPGMap<>. The time when that was implemented and tested was before my time and I was only presented with the results when I asked about the generic TStringList, namely that it's slower than the non-generic one. I had enough items on my ToDo list (and still do), so I simply turned my attention to another points. *shrugs*

In general: FPC monomorphizes generics in all cases, thus, they cannot be slower, because they are literally the same thing as a directly equivalent non-generic implementation.

Now it's you who's generalizing. As always it depends on the implementation. Take a look at TFPGList<>: It's implemented as a descendant of TFPSList and the generic's type handling is done through virtual functions. Compare that to a generic list that implements all in a single class (even if both simply use a dynamic array as implementation). Here the TFPGList<> is slower than this hypothetical generic list due to the virtual call (it might be only a small difference in performance, but it will be there).

But the performance discussion aside, I also stated that I use generics simply due to the type safety they provide. That is IMHO the main reason to use them. I know that there are core developers that don't like generics, but I'm definitely not one of them (after all I developed much of the new functionality since 2.6.4  ).

[marcov]

Do you have some rough idea as to when you might be done with it ?

Soonish. Currently the blocker is just that the GUI "frontend" app for it went ahead and used Delphi 10's "TCardPanel", which Lazarus does not implement, making the app rather annoying to translate without destroying the LFM file.

I've gotten a skeleton of it going with the "TDI" Lazarus package, and am currently just carefully trying to make sure I don't break any of the original UI behavior.

Did you running windows headers through it? Can it handle calling convention macros?