Lazarus
Programming => General => Topic started by: lawman on January 22, 2020, 09:35:15 pm
-
I'm just wondering why...
C++ has soooo much userbase...
but I can't find any free decent RAD IDE for C++ like Lazarus that has GUI and Database components built in??
I've found CodeBlocks C++ which has gui components with wxwidgets, but Lazarus has so much more to make it RAD.
Just find it weird as Lazarus / FPC userbase is a small fraction of C++ userbase.
I've searched everywhere and checked out Ultimate++, Codelite, Codeblocks and a range of others... but Lazarus still seems so much easier to use, like Visual Basic RAD IDE was in the old days.
Am I missing something?
Please advise.
Thanks
-
Am I missing something?
...a few deep pocket corporates and a several decades of active development tool promotion. (specifically the language).
IF Lazarus is too support other languages, specifically on the level of code tools - meaning intelligent understanding of the code, then it could grow the popularity by itself. (not necessary the pascal language)
Most of Lazarus IDE users are Pascal developers, and either don't need to develop a language plugin for the IDE or are using different IDE's for other languages.
-
I'm just wondering why...
C++ has soooo much userbase...
but I can't find any free decent RAD IDE for C++ like Lazarus that has GUI and Database components built in??
Well the only logical conclusion of course is that C++ programmers are lazy :-)
-
Well the only logical conclusion of course is that C++ programmers are lazy :-)
Or the other way around: Pascal programmers have become so lazy that we require full-fledged, advanced IDEs like Lazarus and Delphi ;D :D
Of course, at some point that becomes a "chicken and egg" problem :D :D :D
-
Well the only logical conclusion of course is that C++ programmers are lazy :-)
Or the other way around: Pascal programmers have become so lazy that we require full-fledged, advanced IDEs like Lazarus and Delphi ;D :D
Of course, at some point that becomes a "chicken and egg" problem :D :D :D
If that so, C++ users would stodgily refuse to use VIM because it is too advanced and gotten to bloated and stick to ED. That's not the case. Many C++ IDEs exist, but the integration beyond code editing, navigation is usually poor, and design is even less, staying fancy editors and not much else.
I don't really know why there is not something equivalent.
Some problems are inherently C++, like the need for complex project management since you need more than " CC mainfile" to compile a C++ project. Some are that the free C/C++ compilers are tied to Unix, and thus are often tied to Unixy environments like cygwin and mingw on majority target Windows.
And Windows centric C++ users simply use free VS that allows you to deploy free GUI applications (contrary to Delphi that costs several thousands and the free version of which has license restrictions and is sometimes complex to get)
And to succeed you really need to keep all the noses pointed in the same direction. People always rant on this forum about delphi compatibility, but I think having an example that large groups of people looked up to was a really major, major factor (and TP compatibility before it)
And of course ONE whole Pascal RAD in 25 years might just be a statistical anomaly
-
And of course ONE whole Pascal RAD in 25 years might just be a statistical anomaly
:) :) :)
Bart
-
I've searched everywhere and checked out Ultimate++, Codelite, Codeblocks and a range of others... but Lazarus still seems so much easier to use, like Visual Basic RAD IDE was in the old days.
Am I missing something?
Tools made by the community, for the community. There's something to be said for this.
Having deep pockets is great for getting something out there, and commanding mindshare, but if there isn't a corresponding vision by people who strongly desire to use the resulting end product, then it doesn't necessarily lead to a better product. A more popular one, perhaps, but not necessarily better.
The other advantage is that when Delphi was released, it was lightyears better than other products and rapid design and rapid prototyping. I don't think that this edge has really been lost for ObjectPascal since that time. Other tools have focused on other strengths...
-
And Windows centric C++ users simply use free VS that allows you to deploy free GUI applications (contrary to Delphi that costs several thousands and the free version of which has license restrictions and is sometimes complex to get)
Actually in Visual Studio isn't possible to create GUI/form with native C++ whereas forms are somewhat like C#.
You can make C++ CLI application and add form, but it's managed dialect where you can't use pointers, std.. some unnecessary interface must be created. In addition C++ CLI is abandoned by MS in favor of C# forms. Then another option is using C# application and C++ DLL. All this is overcomplicated and really confusing nonsense, if somebody is using C++ so he want surprisingly code in C++.. also want performance, clarity or other benefits of that language.
Not to mention that forms implementation and form designer looks like an experimental feature moreover with stability similar to Chernobyl reactor than the fixed component of the Visual Studio (which, on the contrary, I quite like).
-
Simple, C++ is not used for RAD development, thats why there is no real RAD IDE for it. Same is also true for example for Python. Pascal as a language was steered into the RAD direction by borland, it also heavily inspired .Not and Java which is why there are RAD tools available for these languages too.
C is a language developed for one reason, kernel development, which is the pure opposite of RAD, looking at C++, there is QT with the QT-Creator, which tends more into the RAD direction, but as with C, the main niche C++ occupies is not rad development, which is somewhat understandable, because the language design of C++, it's strength and weaknesses, are not so well suited for RAD as for example C# or Pascal. For example, there is no concept of Method pointers in C++, there are only function pointers to this call functions.
The design of a language has profound implications on what it's strength and weaknesses are. C++ has by design some base complexity, so the rapid in RAD is already off the table.
Also C and C++ have a "difficult" relationship with IDEs in general, because of the very different tooling available. With using an IDE you are binding yourself to what this IDE can understand. Now let's say you have a C++ project for Windows, Linux and macOS. For windows you use MSVC++ compiler and the corresponding debugger. On Linux you might use GCC and GDB and for Apple you will use the Apple version of Clang with LLDB.
To handle this clusterfuck of a buildsystem you started of with makefiles but soon realized that this is not enough so you either write a configure script using Bash, generate one using Autoconf, or if you are a little less old fashioned use CMake.
So if you wanted to use an IDE, this IDE needs to be capable of parsing this buildsystem and somehow find out how you configured your project (search paths, defines, etc.) and also make smart changes to this when you configure your project. But as your buildsystem is a literally a turing complete scripting language, this is simply computationally impossible, so long story short, such an IDE can not exist.
So if you have an "IDE" it can't really integrate the most important part of your "Development Environment", i.e. the buildsystem and project configuration. So whats the point of having an IDE. So all you are left with is an editor that is configurable to your C++ project (like using clang-completion and stuff), and this already exists, Emacs, Vim, VSCode, there is nothing an IDE could do better than a good editor for such projects.
That said, there are C++ IDEs, but if you use them everyone in your team needs to use them (because a general buildsystem is of the table) which of course has other implications. License restrictions, personal preferences, and simply cross plattform availability. Visual Studio or XCode are great, but only work on a single machine. CLion is good but is proprietary software.
For Java this is solved by having widespread support for simple and unified buildsystems like maven which are well thought through. And languages like Javascript or Rust have their own management tools like npm or cargo which are shipped with the language environment. Similarly this is for Pascal, there are basically two relevant pascal compilers (Delphi and FPC) with each having one IDE that is the defacto standard for them (Delphi and Lazarus). If you don't have much choice, there is no need for such a clusterfuck like C++ has
When I started using C++ and C, I was using a mac, so what I did was I've imported the project into XCode, and configured the XCOde project as the CMake file configures the project for building on Linux (I actually compiled it on a Linux buildserver). The XCode files where added to the gitignore and everything worked fine, I could use all of XCodes functions. But I've always had to sync up XCode with CMake if any changes where done, and the initial effort is huge. So with the next project I simply decided to only use Vim, now I am using emacs with Spacemacs, and I never regretted that decision to switch from IDEs to simple editors. They are great for C++, and there is no feature that IDEs have that is worth the effort I've had before.
Also there is something to the fact that I can simply download a C++ project, fire up vim or emacs (evan via ssh on a totally different pc) and build it with one simple make (or cmake build).
If I want to contribute to a Java project that doesn't use maven, I first need to get the correct IDE for this, which resulted in at one time, me having 3 Java IDEs installed at once on my machine.
-
Lazarus and FPC have come so far over the years
Bloating in other similar IDE's have made them difficult to use.
Pascal should reign and any move to bring in a broader user base would, in my opinion, be better spent in expanding the Node.js capability in the IDE.
A fit all approach leads to bloating and reduced productivilty
-
And Windows centric C++ users simply use free VS that allows you to deploy free GUI applications (contrary to Delphi that costs several thousands and the free version of which has license restrictions and is sometimes complex to get)
Actually in Visual Studio isn't possible to create GUI/form with native C++ whereas forms are somewhat like C#.
Ever used MFC? I mean, it's not RAD in the Delphi/Lazarus sense, but it allows you to visually design your GUI and it's relatively easy to add event handlers.
For example, there is no concept of Method pointers in C++, there are only function pointers to this call functions.
Of course C++ does have method pointers (https://isocpp.org/wiki/faq/pointers-to-members). At work I've even used them a few occasions. :) They are however clumsy to use and nowhere as nice and flexible as method pointers in Object Pascal.
Also C and C++ have a "difficult" relationship with IDEs in general, because of the very different tooling available. With using an IDE you are binding yourself to what this IDE can understand. Now let's say you have a C++ project for Windows, Linux and macOS. For windows you use MSVC++ compiler and the corresponding debugger. On Linux you might use GCC and GDB and for Apple you will use the Apple version of Clang with LLDB.
To handle this clusterfuck of a buildsystem you started of with makefiles but soon realized that this is not enough so you either write a configure script using Bash, generate one using Autoconf, or if you are a little less old fashioned use CMake.
So if you wanted to use an IDE, this IDE needs to be capable of parsing this buildsystem and somehow find out how you configured your project (search paths, defines, etc.) and also make smart changes to this when you configure your project. But as your buildsystem is a literally a turing complete scripting language, this is simply computationally impossible, so long story short, such an IDE can not exist.
MSBuild is an additional alternative to CMake that nowadays is even cross platform.
-
Of course C++ does have method pointers (https://isocpp.org/wiki/faq/pointers-to-members). At work I've even used them a few occasions. :) They are however clumsy to use and nowhere as nice and flexible as method pointers in Object Pascal.
The answer to the second question (needing also the object) could be considered to prove it doesn't ;-)
-
Of course C++ does have method pointers (https://isocpp.org/wiki/faq/pointers-to-members). At work I've even used them a few occasions. :) They are however clumsy to use and nowhere as nice and flexible as method pointers in Object Pascal.
I don't consider that method pointers, but rather a workaround using classical function pointers to make up for this :)
-
Ever used MFC? I mean, it's not RAD in the Delphi/Lazarus sense, but it allows you to visually design your GUI and it's relatively easy to add event handlers.
You're right. It's still in VS 2019 and updated. Although it looks like you need a lot of books on winapi, coding could be much easier with modern C++ features.
It's interesting how many concepts MS has tried without clear result.
-
It's interesting how many concepts MS has tried without clear result.
One of the main things about C++ is, it isn't and never will be a Microsoft language. Most of the things MS does with C++ will never become "mainstream" because a huge chunk of C++ developers (I would even go so far and say most C++ developers) don't target windows (or better, don't explicitly target windows). C++ is very much used in server software, which is predominantly *nix based. A lot of applications are nowadays also build using the LLVM infrastructure, which by design is cross platform, so MS never really got a foot in the door with C++.
If you want to use the WinAPI in the most convinient way possible, you should use .Not. If you want to write interactive GUI applications for Windows, C# is the language for you. Even the C++ CLI interface which allows you to use .Not is not really used by C++ community, because using C++ to write a .Not GUI application is so much more effort than using C# and you don't gain anything from it.
C++ has it's niche in the "bare metal" programming area, servers, game engines, embedded systems, simulations, etc. Everything where you need a good performance and you have to work with complex datastructures.
For most GUI applications performance is not relevant (because the reaction time of the user is orders of magnitude higher than the reaction time of the computer), and even if you need high performance computations, it is usually easier to only write these algorithms in C++ and do all the GUI stuff with another language.
-
Well the only logical conclusion of course is that C++ programmers are lazy :-)
Not quite... But they are wasting time because of the language... They have to work harder in fact...
-
Well the only logical conclusion of course is that C++ programmers are lazy :-)
Not quite... But they are wasting time because of the language... They have to work harder in fact...
But something would be visible by now. And as said, even MFC can't touch VCL/LCL.
-
Not quite... But they are wasting time because of the language... They have to work harder in fact...
Depends on what you are doing, I often had the point where, while developing with pascal, I wished I was doing this bit in C++ because it would be so much easier. A simple example: HashMaps, std::unordered_map<key, value> works on a binary level for every type out of the box, as well as having specialized implementations for all standard library types like strings. You can also easiely define custom hash functions for your type at your type while you can also have custom hash functions used only for this one map and everywhere else the standard hash is used.
This is something you can't even build in Pascal because FPC generics are much weaker than C++ templates
-
For most GUI applications performance is not relevant (because the reaction time of the user is orders of magnitude higher than the reaction time of the computer), and even if you need high performance computations, it is usually easier to only write these algorithms in C++ and do all the GUI stuff with another language.
Aren't those GUI frameworks like Qt programmed in C++? There is difference between using scripting language for easier work in GUI designer, for styles or whatever while you're still coding in C++ in relatively monolithic structure (but yes, it's already falling apart in contrast of FPC/Lazarus) vs using C# which means second language with different concept. I completely do not understand what has prevented large companies at least from keeping one way.
One of the main things about C++ is, it isn't and never will be a Microsoft language.
Microsoft directly develops C#, they have full control there. It's better? Let's make UI in eeee.. Net.. uhm.... stand.. ee.. .Net Framework? Or newly and partly in .Net Core (which is different from Framework)? Or maybe Mono, UWP, WPF, WTF, Xamarin, Silverlight, ASP.NET/Core/CoreMVC/.. webforms, Entity Framework.. or wait until november there will be new .Net 5.0 which "takes best from all this" except half of the concepts will be forgotten and or implemented again in semi-finished phase at least until new direction. There can be no question that the user just simply starts Visual Studio and just makes an GUI application.
-
Aren't those GUI frameworks like Qt programmed in C++? There is difference between using scripting language for easier work in GUI designer, for styles or whatever while you're still coding in C++ in relatively monolithic structure (but yes, it's already falling apart in contrast of FPC/Lazarus) vs using C# which means second language with different concept. I completely do not understand what has prevented large companies at least from keeping one way.
Of the big cross plattform frameworks, QT is written in C++, mainly for C++ (and therefore requires C++ to C wrappers for using in other languages), and GTK as the name (gimp toolkit) was written for gimp, which is a C program, so GTK is written in C.
These have especially been established because you can use them with any other language (for example you can even use GTK with C#). Then there are the platform dependend Frameworks like .Not with .Not Windows Forms and WPF, Java with JavaFx and Apple with Cocoa (Android sure has it's own thing, but I don't know the name about that).
But what these libraries are written in doesn't matter much regarding whats their best usage. .Not is surely internally written in C++, but still C++ is pretty much the worst language to use it. That said, there is QT with the QT creator for C++, which comes pretty close to the type of RAD development we know from Lazarus. You have QTCreator as your IDE, with a pretty WYSIWYG editor, the event system is pretty weird (basically the event function is defined by name, so button1 will always call button1_on_click or something like that, which is really weird), but there are these tools. But as I said, this is not the C++ main niche. And without any demand there is not much development.
One of the main things about C++ is, it isn't and never will be a Microsoft language.
Microsoft directly develops C#, they have full control there. It's better? Let's make UI in eeee.. Net.. uhm.... stand.. ee.. .Net Framework? Or newly and partly in .Net Core (which is different from Framework)? Or maybe Mono, UWP, WPF, WTF, Xamarin, Silverlight, ASP.NET/Core/CoreMVC/.. webforms, Entity Framework.. or wait until november there will be new .Net 5.0 which "takes best from all this" except half of the concepts will be forgotten and or implemented again in semi-finished phase at least until new direction. There can be no question that the user just simply starts Visual Studio and just makes an GUI application.
.Not is basically pretty simple, it started out as the idea: "Lets make Java but better", then the demand for cross platform availability increased (which was first met by mono, which is an open source clone of .Not and had at first nothing to do with MS) they decided to also support this, but as many of .Not features where directly representative of WinAPI features, they couldn't just port .Not, and rather than that put out .Not Core.
WPF was developed in an effort to make "pretty" application development easy by basically having DirectX rendered forms (similar to firemonkey for delphi, even though the reasoning behind it is different) which allows for much more complex graphics. Xamarin is an IDE containing a cross plattform gui framework they bought (before that it was a totally separate project, so not the idea of MS) which now basically is the Mobile version of .Not, ASP.Net is a language, MVC is the micrsoft LibC and entity framework is a framework for Databases. And Silverlight was a mistake.
I mean sure they did a lot of stuff, but Microsoft is a large company, and most of it (except for Silverlight) was a success. I mean if you want to use C# you simply download visual Studio and can start of. You want to have more graphical opportunities (which makes it also more complicated), Simply use WPF. If you want to make an (cross plattform) application that does not requires system API specifics (like GUIs), use .Not Core, if you need a web application, use ASP.Net. You want all of .Not but cross plattform and maybe not by MS, use Mono. You want to create a mobile app, use Xamarin.
Btw, I really don't like .Not, and haven't been following it since 2014 or so, but still I know and understand their Concepts and products
I mean they made it such that a formerly Windows only Java Clone, is now one of the most important Programming languages around. Meanwhile VC++ is still only considered "just another C++ compiler"
-
It's interesting how many concepts MS has tried without clear result.
One of the main things about C++ is, it isn't and never will be a Microsoft language. Most of the things MS does with C++ will never become "mainstream" because a huge chunk of C++ developers (I would even go so far and say most C++ developers) don't target windows (or better, don't explicitly target windows).
Microsoft has a member in the ISO C++ Comittee (https://isocpp.org/wiki/faq/wg21). Thus they can at least influence decisions even if there are many others who would block approaches that aren't cross platform.
If you want to use the WinAPI in the most convinient way possible, you should use .Not.
Are you calling .Net ".Not" on purpose?
This is something you can't even build in Pascal because FPC generics are much weaker than C++ templates
FPC's generics simply have different design goals than C++'s templates.
-
Microsoft has a member in the ISO C++ Comittee (https://isocpp.org/wiki/faq/wg21). Thus they can at least influence decisions even if there are many others who would block approaches that aren't cross platform.
Sure, and as one of the biggest companies using C++ (I would say the Windows, DirectX, .Not, etc. code base isnt so small), as well as compiler developers I think they can contribute a lot to it, but this was more about their "single handed" approaches where they tried to implement their vision into VisualC++, which never really found tracktion because it is not compatible
Are you calling .Net ".Not" on purpose?
Kinda, I don't even know anymore how and why I started doing it (it was somewhen during the time I was using it extensively) now it just became a habit of mine. But there once where a purpose to it
FPC's generics simply have different design goals than C++'s templates.
Yes, this is pretty much I am saying, different language design allow for different constructs and make different things easier and other things harder. C++ templates are for example turing complete and allows for having complicated logic solved out at compile time which allows for some pretty neat things, but in turn give you horrendous error messages. Different tools fit different jobs.
-
Microsoft has a member in the ISO C++ Comittee (https://isocpp.org/wiki/faq/wg21). Thus they can at least influence decisions even if there are many others who would block approaches that aren't cross platform.
Sure, and as one of the biggest companies using C++ (I would say the Windows, DirectX, .Not, etc. code base isnt so small), as well as compiler developers I think they can contribute a lot to it, but this was more about their "single handed" approaches where they tried to implement their vision into VisualC++, which never really found tracktion because it is not compatible
I think it simply got no traction because no majority player pushed it. MS was all about VB, and then the focus went to .NET. Apple had various languages (C,Pascal) for Classic MacOS and then went to Objective C and then Swift.
Possibly because they didn't want to deal with the Standards committee for every little thing, or risk being branded Standardsbreakers if they jumped the gun.
So that leaves QT and KDE, and the classic candidate KDevelop.
One could argue QT Creator tried to jump into that gap, the lack of native focus for Desktop apps.
-
I mean if you want to use C# you simply download visual Studio and can start of.
Yes, I made .Net Framework library, application and also Windows Forms application, all default templates which are preferably offered. Then I found Core fits better for my purposes. I changed library project for supporting both (interesting) and application into Core. After few months there was on blog post from MS dev: "Hey, whats up, look at newly released Core forms build somehow over XY, which is based on YZ and it "works"!". That was clear choice, I couldn't resist. Of course forms were not compatible.
I wonder if .Net 5.0 is the light at the end of the tunnel where developers leave Framework, Mono and other things and will work on a single C# platform, although the universal cross platform GUI is still not happening. If C++ needs C# for forms, then C# needs what?
-
Cross plattform GUI applications are not trivial.
If you want to do it native, like Lazarus tries to do, you need to support many different APIs that might not be that compatible (just look at the Cocoa LCL implementation). Also this effectively means that you (considering you want to support GTK, QT, WinAPI and Cocoa) need to support 4 different projects. I mean look at Lazarus as an example, it handles it really great, but still GTK2 is fully supported, but the framework is pretty much dead (I think even XFCE is switching from GTK 2 to 3), but GTK3 is still a WIP while GTK 4 release is already on the horizon. QT 4 and QT 5 and Windows forms are fully supported, and while I haven't used lazarus on OSX for a while, back then Cocoa was nearly not usable, and from what I have seen so far, it still has some quirks that inhibit full LCL compatibility. And support for Mobile Plattforms is AFAIK nearly not existent (using LCL forms)
The other option is to draw it yourself like Firemonkey or Java, which works, but does not feel native (you can nearly always tell if something is a java application).
But the question is, why bother if such things already exist? I mean you can use GTK# the GTK wrapper for .Not (and Core). And basically let the GTK team figure out how to make this cross plattform available (which they seem to do pretty well). AFAIK the Xamarin.Forms designer can also work with them, giving you all the RAD tools you know and love for cross plattform GUI developmen.
If C++ needs C# for forms, then C# needs what?
C++ does not need C# for Forms, it needs a Framework, this could either be .Not, QT, WxWidgets, GTK, whatever. There are a lot of such tools available, but, as I said, they don't have so much traction because C++ is simply not used for RAD GUI development.
Similarly, if you take a python programmer, he probably never wrote a single GUI in Python, on the other hand, a Swift programmer probably only writes GUI applications.
I mean not everyone needs to write GUIs, and tools are chosen to fit the problem, there is no tool that fits every problem. I for example haven't written a GUI application in the past 2 years, similarly my usage of Pascal and Lazarus has declined in the past 2 years, because other tools simply fitted better (for example I use a lot of python for small computational scripts like statistics). If I had to write a GUI application, C++ would be one of the last languages I would use, while when writing for my avr, it's pretty much my goto language.
-
i've been using wxwidgets for a while , it has many nice features (its docking feature is much better than lazarus ),
of course you would write more code than lazarus but this is not a problem .
about database there is many frameworks (e.g SOCI) which could be integrated with wxwidgets , but alot of code is required ;)
-
This is something you can't even build in Pascal because FPC generics are much weaker than C++ templates
Weaker? Do you work in teams? It is a headache working with C++ templates, just because there is too much freedom. This is just a slight remark from someone who knows both languages inside out.
Yes, ++ is a template, probably... :D ;D >:(
-
Weaker? Do you work in teams? It is a headache working with C++ templates, just because there is too much freedom. This is just a slight remark from someone who knows both languages inside out.
Yes, ++ is a template, probably... :D ;D >:(
Yes weaker, in the language theorethical sense pascal generics have much weaker expressive capabilities.
This is not ment to judge them, its just a fact that c++ templates are much more expressive
But if would judge them, I must confess that fpc generics drive me absolutely mad, they have a tone of weird limitations, and even if you circumvent all of them you will simply recieve fpc internal error xxx or "fpc raised an internal exception", which of you are lucky is gone when making a clean build and if zou are unluck completely stop you from implementing your idea (and of course thin only happens in complicated code so you cant create a minimal working example with less than 4k lines of code)...
This gets a little off topic, but ive founs that generics for anything other then simple things sucg as containers or calling static functions, are basically completely unusable. If you have something more complex (so at around 10-15 generic classes being interconnected) you will either run into fpcs limitations (the design) or into a bug in fpc, whicg you cant report because your minimal working example is a whole project of several thousands od lines, where removing obly one function makes the bug disappear
-
Are you calling .Net ".Not" on purpose?
Kinda, I don't even know anymore how and why I started doing it (it was somewhen during the time I was using it extensively) now it just became a habit of mine. But there once where a purpose to it
May I please ask you to refrain from doing that at least on this forum? In my opinion that is just as childish as calling Microsoft "M$" or (in German) people calling "Windows" "Windoof" ("doof" = "stupid").
But if would judge them, I must confess that fpc generics drive me absolutely mad, they have a tone of weird limitations, and even if you circumvent all of them you will simply recieve fpc internal error xxx or "fpc raised an internal exception", which of you are lucky is gone when making a clean build and if zou are unluck completely stop you from implementing your idea (and of course thin only happens in complicated code so you cant create a minimal working example with less than 4k lines of code)...
This gets a little off topic, but ive founs that generics for anything other then simple things sucg as containers or calling static functions, are basically completely unusable. If you have something more complex (so at around 10-15 generic classes being interconnected) you will either run into fpcs limitations (the design) or into a bug in fpc, whicg you cant report because your minimal working example is a whole project of several thousands od lines, where removing obly one function makes the bug disappear
Generics are both a rather complex feature and a work in progress feature. There's bound to be problems. I try to solve them as good as I can, but there's only so much I can do (and then there's also Delphi compatibility I need to pay attention to). Right now for example I'm trying to solve one problem and it turns out that I need to solve a bunch of others at the same time to keep everything working... %)