4 ms·

Note that the Free Pascal/Lazarus equivalent to VCL is two libraries: FCL and LCL, with the former being part and developed by the developers of Free Pascal and

Note that the Free Pascal/Lazarus equivalent to VCL is two libraries: FCL and LCL, with the former being part and developed by the developers of Free Pascal and the latter being part and developed by the developers of Lazarus (while there is an overlap, they are two different projects with different teams). FCL is also used by other projects (e.g. FPGUI uses FCL but not LCL) and if you install just Free Pascal you only get FCL, not LCL. With that in mind and considering the context i guess you meant LCL. Now, LCL would be very hard to port to C++ because it is really built around Object Pascal features like a rich RTTI with explicitly exported properties, component streaming, "default" accessors, enums, sets, object instance method pointers and other features that C++ does not support at a language level. In C++ Builder the VCL is written in Object Pascal (and it even includes a Pascal compiler and linker), the language has been extended considerably to support Object Pascal-isms (e.g. __published section in classes, __property declarations, __fastcall calling convention that is Delphi-compatible, __delegate types for pointers to object instance methods, etc) and the runtime and library are written with some internal representation in mind (e.g. Pascal sets and strings are exposed to C++ using classes that have the same memory layout as the values the Pascal compiler creates). Of course some of those could be avoided if you do not care about a 1-to-1 port of FCL/LCL and compatibility with it, but still a lot of the functionality comes out of core Object Pascal features (since Borland had full control of the language, they designed both the language and API to complement each other, which is why it feels so weird in C++ Builder). Beyond that, you'd really need an IDE with a visual designer like Lazarus as the entire API is designed to be manipulated in a visual way (e.g. while LCL does provide Qt/Gtk/Java/etc layout managers, they are really an afterthought in case you really want them and layout is mainly handled via anchors which have a dedicated visual editor - similarly the API uses a lot of custom collections that are meant to be edited with collection-specific editors in the IDE). You could use Lazarus for that, but since Lazarus is meant to work with Free Pascal and does a lot of parsing (it essentially keeps the entire codebase, including all units and libraries as parsed nodes in memory) and automatic code editing (e.g. filling in the handler methods when you double click an event handler - or a component which fills the default event handler, navigating around the code, refactoring, removing empty handler methods, etc) you'll need to teach it enough C++ to be similar to writing a C++ compiler. You could avoid the "porting to C++" part and using FCL/LCL directly from C++ in a similar way to what C++ Builder does... but then you'd need to convince some C++ compiler to include C++ Builder-like extensions and Free Pascal's developers to cooperate with said compiler's developers to ensure compatibility. You'd still need the Lazarus-needs-to-learn-C++ par though. You could avoid all the above by making an "LCL inspired" (really, VCL inspired) library which vaguely resembles LCL for those who already know it but sticks with C++'s strengths. It wont be LCL/VCL though and wont take advantage of Lazarus, at which point you might as well make something that avoids the warts that LCL/Lazarus has. Ah btw, did i mention the part where since LCL is essentially a cross-platform VCL reimplementation and VCL was designed only with Windows in mind, it has to implement a small subset of the Windows API for every platform and widgetset it supports? Yeah, are you sure you want to port that part too? Honestly i'd love to see C++ Builder-like support in Lazarus and LCL, but practically i think it would be easier to make a new C++ Builder-like tool from scratch than make Lazarus, LCL, Clang (or GCC) and Free Pascal work together - even if we ignore the social/political side of convincing the developers behind those projects to work with the other projects.

c-smile 8y ago
There is on problem with Lazarus approach. IDE and visual form layout editors require specialized property editors. And amount of code for design time support is significant usually. Yet, data produced by layout editors is not DIFF friendly. Ability to edit UI definitions in text forms is valuable for collaborative work. That's why Delphi/Lazarus is popular among INDIE developers but not in large companies.
- badsectoracula 8y ago
  I'm not sure what you have in mind, Lazarus (and AFAIK Delphi at least since version 7, most likely earlier too) saves the form as a text file which you can diff and i do that all the time when looking at changes in my code before submitting them. In fact the format is very readable and has a syntax like: object ScriptConsole: TScriptConsole Left = 349 Height = 331 Top = 710 Width = 487 ... object Cmd: TEdit Align = alBottom end ... end (this is part of the code from a form of a project of mine called ScriptConsole) It only stores properties changed from their defaults which makes for very compact files and focusing on the stuff you have actually worked on. If anything i find the XML files that other tools (like Qt Designer and wxFormBuilder) use harder to read.
  - c-smile 8y ago
    Ah, missed that one, thanks. Format looks like .frm files of VB6. And that's somehow closer to C++ (than Delphi) as widgets there are COM objects.
int_19h 8y ago
C++ Builder had all those language extensions because it wanted to be binary compatible with Delphi units, including VCL. This is not the goal here. If you don't care about that, most of the things that you've listed can be mapped to modern C++ just fine, with std::string for strings, std::function for function pointers etc. In fact, that's an advantage of starting with a higher-level API - because it has things like properties explicitly, they can be mapped to different languages in different ways, including cases where the mapping is one-to-many - e.g. property to a pair of method overloads in C++. This all could be driven by a code generator, which would also produce the data structures to drive RTTI. Think about WinRT - single ABI and object model, multiple language mappings from JS to VB to C++. Delphi object model is actually somewhat similar to that, and even simpler in some ways (e.g. no refcounting). For a Delphi library mapped to C++, the end result could look a lot like C++/WinRT. IDE support is tricky, yes. You really, really don't want to constantly parse/generate C++, there's just too many corner cases. But if you just take the form designer, it doesn't need to know anything about code - it just needs to understand components and properties, and spit out some representation that a code generator (or even a runtime loader) can turn into an actual object graph. That should suffice for layouts. Event handlers would have to be wired from code, but that's not a big deal. As far as legacy warts, well, the only other framework we currently have that uses native widgets everywhere is wxWidgets, and its design was originally influenced by MFC of all things, so... It would be nice to have a clean ground-up design for modern idiomatic C++, and accounting for all the modern desktop platforms - but it's a huge project, and unlikely to get far because of that. LCL, on the other hand, is already there, and is a proven and maintained codebase. If there's a way to take it and produce a C++ version, or even a C++ bridge to a Pascal implementation (given that FP can statically link, it could all be in a single shared library that exposes a C API, and its clients wouldn't even know that it's written in Pascal).

c-smile 8y ago

There is on problem with Lazarus approach. IDE and visual form layout editors require specialized property editors. And amount of code for design time support is significant usually. Yet, data produced by layout editors is not DIFF friendly. Ability to edit UI definitions in text forms is valuable for collaborative work. That's why Delphi/Lazarus is popular among INDIE developers but not in large companies.

badsectoracula 8y ago
I'm not sure what you have in mind, Lazarus (and AFAIK Delphi at least since version 7, most likely earlier too) saves the form as a text file which you can diff and i do that all the time when looking at changes in my code before submitting them. In fact the format is very readable and has a syntax like: object ScriptConsole: TScriptConsole Left = 349 Height = 331 Top = 710 Width = 487 ... object Cmd: TEdit Align = alBottom end ... end (this is part of the code from a form of a project of mine called ScriptConsole) It only stores properties changed from their defaults which makes for very compact files and focusing on the stuff you have actually worked on. If anything i find the XML files that other tools (like Qt Designer and wxFormBuilder) use harder to read.
- c-smile 8y ago
  Ah, missed that one, thanks. Format looks like .frm files of VB6. And that's somehow closer to C++ (than Delphi) as widgets there are COM objects.

int_19h 8y ago

C++ Builder had all those language extensions because it wanted to be binary compatible with Delphi units, including VCL. This is not the goal here. If you don't care about that, most of the things that you've listed can be mapped to modern C++ just fine, with std::string for strings, std::function for function pointers etc. In fact, that's an advantage of starting with a higher-level API - because it has things like properties explicitly, they can be mapped to different languages in different ways, including cases where the mapping is one-to-many - e.g. property to a pair of method overloads in C++. This all could be driven by a code generator, which would also produce the data structures to drive RTTI. Think about WinRT - single ABI and object model, multiple language mappings from JS to VB to C++. Delphi object model is actually somewhat similar to that, and even simpler in some ways (e.g. no refcounting). For a Delphi library mapped to C++, the end result could look a lot like C++/WinRT. IDE support is tricky, yes. You really, really don't want to constantly parse/generate C++, there's just too many corner cases. But if you just take the form designer, it doesn't need to know anything about code - it just needs to understand components and properties, and spit out some representation that a code generator (or even a runtime loader) can turn into an actual object graph. That should suffice for layouts. Event handlers would have to be wired from code, but that's not a big deal. As far as legacy warts, well, the only other framework we currently have that uses native widgets everywhere is wxWidgets, and its design was originally influenced by MFC of all things, so... It would be nice to have a clean ground-up design for modern idiomatic C++, and accounting for all the modern desktop platforms - but it's a huge project, and unlikely to get far because of that. LCL, on the other hand, is already there, and is a proven and maintained codebase. If there's a way to take it and produce a C++ version, or even a C++ bridge to a Pascal implementation (given that FP can statically link, it could all be in a single shared library that exposes a C API, and its clients wouldn't even know that it's written in Pascal).