Recent

Author Topic: delphi and C++ builder community edition is here...  (Read 34870 times)

Thaddy

  • Hero Member
  • *****
  • Posts: 14205
  • Probably until I exterminate Putin.
Re: delphi and C++ builder community edition is here...
« Reply #45 on: July 21, 2018, 08:58:05 am »
Delphi CE doesn't do everything. At least I found 3 major limitations:
1. You can't do remote database (local only).
2. You can't do server side applications.
3. You can't do Linux applications.
Small but important correction:
You can do 1 and 2, but you have to use your own implementation, e.g. something like mORMot, synapse, probably Zeos. It does not work out of the box.
Funny thing is you can even use some FPC code for this....
And components that can not be installed can always be dynamically created.
« Last Edit: July 21, 2018, 09:00:18 am by Thaddy »
Specialize a type, not a var.

krolikbest

  • Full Member
  • ***
  • Posts: 246
Re: delphi and C++ builder community edition is here...
« Reply #46 on: July 21, 2018, 10:34:27 am »
Hi,

at work I've D2005 and XE2. Both Prof ver. I asked myself what allowed me to go further in development taking into account different hardware platforms. Despite the fact that e.g. D2005 I have since very very long time, XE shorter but Lazarus (taking only last few years) helped me to" spring wings" on various platforms e.g. Raspbian, Ubuntu, WinCE. I discovered and still do so beautiful problems ;) and that is the reason why I stay by Lazarus.

cobata

  • New Member
  • *
  • Posts: 49
  • Programmer-analyst
    • COBATA Software - Research, Development, Testing, Consulting
Re: delphi and C++ builder community edition is here...
« Reply #47 on: July 21, 2018, 10:43:51 am »
I searched info what FMX use under the hood as native macOS GUI..., but did not find.
What Delphi/ C++Builder use: Carbon, Cocoa, Qt... or something other...? Could you provide some link?
1-2 years ago, I found that they have the same problems like in Lazarus - for example, the Mac App Store, Sandboxing, ...
Now, I read some posts on Jan 2018, that they have the same problems with the Mac App Store and the 32bit apps, and their plans to have 64bit Mac compiler "late this year"...
COBATA Software - Research, Development, Testing, Consulting
https://www.COBATA.com/

bee

  • Sr. Member
  • ****
  • Posts: 393
Re: delphi and C++ builder community edition is here...
« Reply #48 on: July 21, 2018, 10:47:18 am »
You can do 1 and 2, but you have to use your own implementation, e.g. something like mORMot, synapse, probably Zeos. It does not work out of the box.
You should read my second paragraph. :)
-Bee-

A long time pascal lover.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: delphi and C++ builder community edition is here...
« Reply #49 on: July 21, 2018, 12:29:53 pm »
It depends on the degree of imitation, what Delphi did was suicidal from D8(planned during D7).

Exactly my point. Just copying against a market-leader. IMHO what you suggest is nothing else, with some unsubstantiated buzzwords thrown in (like async) to throw of the scent.

If you want async in FPC, implement async, don't project some vague trajectory to totally different technology (to which the FPC project could take along almost nothing).

Throwing away 20 years investments and starting over is rarely sane.

Quote
While Node.js is using Google's decent V8(possibly others in the future), it's still not native, it avoids this limitation due to strong async mentality and some nice language constructs.

Bytecode languages still run circles around javascript in non-micro benchmarks afaik. The async advantage is purely framework, and can be strived for in every language. Of course you can argue till hell freezes over if you need minor language changes or not, but it actually has very little to do with language.

Quote
Native languages like FPC don't feel any pressure to fuse async into the language itself.

So therefore they must become non-native ? Strange way of reasoning. If you want async in FPC, implement it, basta. (though IMHO it would be wise to build a framework first, and then only design the language extensions based on the experience you build up building the framework)

Quote
Will the world drop the popular thingy ?

PHP was dropped(still strong but less relevant), Ruby was dropped(Node.js imitated it and improved upon), Python reinvented itself to prevent this.

And so will node.js and the current javascript wave. Probably before you have anything sane ready.

« Last Edit: July 21, 2018, 05:17:30 pm by marcov »

Akira1364

  • Hero Member
  • *****
  • Posts: 561
Re: delphi and C++ builder community edition is here...
« Reply #50 on: July 21, 2018, 05:00:49 pm »
Downloaded Delphi CE to play around a little, and it pretty much just reminded me why I rarely use Delphi personally anymore, and why we switched to using Lazarus in production at work. The Delphi IDE just isn't very good. It's quite slow, it uses a lot more memory than it should, it has many, many annoying bugs and quirks (I don't care that you can't find the icon file Mr. Delphi, just compile the application and stop showing me the stupid VRCs!) and the package system is a huge pain to use compared to that of Lazarus.

By which I mean, in Delphi you pretty much always have to manually add things to both the ever-growing "library path" and "browsing path" in the options menu to get anything to work properly. It's also for some reason completely unable to find anything that isn't a Pascal source file by default, so INC, RES, DFM, e.t.c files often end up having to be put in the global BPL folder unless you want to recompile all the required packages every time you build a program.

It doesn't even look nearly as good (running on Windows 10) as trunk Lazarus does. Cheap low-res icons and ugly out-of-place menu bars everywhere...

As far as the questions some people had about how feature-complete Community Edition is though: it is in fact completely identical to the Professional Edition, meaning full optional support for all platforms (Win64, Android, iOS, OSX) except Linux Server, and meaning it includes the complete source code for the Delphi RTL, VCL, FMX, e.t.c frameworks.

Regarding the fact it includes the source, also: more simply put, this means that complete Delphi library source code is now available to literally anyone at all in a free, legal download, whereas before it was only available to those who either pirated Delphi or paid for one of the more expensive licenses. So there is perhaps a somewhat higher chance of future FPC/Lazarus patches including plagiarized code, which is something the devs might want to keep an extra-attentive eye on going forwards.

I searched info what FMX use under the hood as native macOS GUI..., but did not find.

FireMonkey is a completely GPU-based, hardware-accelerated API. It uses DirectX on Windows, and OpenGL on all other platforms.
« Last Edit: July 22, 2018, 02:28:05 am by Akira1364 »

taazz

  • Hero Member
  • *****
  • Posts: 5368
Re: delphi and C++ builder community edition is here...
« Reply #51 on: July 22, 2018, 01:24:03 am »
Quote
Native languages like FPC don't feel any pressure to fuse async into the language itself.

So therefore they must become non-native ? Strange way of reasoning. If you want async in FPC, implement it, basta. (though IMHO it would be wise to build a framework first, and then only design the language extensions based on the experience you build up building the framework)
Can I ask what async mean in this context? multithreading? non blocking? something else?
Good judgement is the result of experience … Experience is the result of bad judgement.

OS : Windows 7 64 bit
Laz: Lazarus 1.4.4 FPC 2.6.4 i386-win32-win32/win64

ASBzone

  • Hero Member
  • *****
  • Posts: 678
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) from BrainWaveCC
Re: delphi and C++ builder community edition is here...
« Reply #52 on: July 22, 2018, 05:08:28 am »
What do you really expect to happen? That people will mass drop the popular thingy the whole world is raving about to flock to your still experimental attempt at imitating it?   Not going to happen! 

Rather it would be wiser to pain a picture for FPC/Lazarus to work in frameworks in step with such solutions. IOW, complement, not replace.

Very true...
-ASB: https://www.BrainWaveCC.com/

Lazarus v2.2.7-ada7a90186 / FPC v3.2.3-706-gaadb53e72c
(Windows 64-bit install w/Win32 and Linux/Arm cross-compiles via FpcUpDeluxe on both instances)

My Systems: Windows 10/11 Pro x64 (Current)

Mr.Madguy

  • Hero Member
  • *****
  • Posts: 844
Re: delphi and C++ builder community edition is here...
« Reply #53 on: July 22, 2018, 11:15:02 am »
Downloaded Delphi CE to play around a little, and it pretty much just reminded me why I rarely use Delphi personally anymore, and why we switched to using Lazarus in production at work. The Delphi IDE just isn't very good. It's quite slow, it uses a lot more memory than it should, it has many, many annoying bugs and quirks (I don't care that you can't find the icon file Mr. Delphi, just compile the application and stop showing me the stupid VRCs!) and the package system is a huge pain to use compared to that of Lazarus.

By which I mean, in Delphi you pretty much always have to manually add things to both the ever-growing "library path" and "browsing path" in the options menu to get anything to work properly. It's also for some reason completely unable to find anything that isn't a Pascal source file by default, so INC, RES, DFM, e.t.c files often end up having to be put in the global BPL folder unless you want to recompile all the required packages every time you build a program.

It doesn't even look nearly as good (running on Windows 10) as trunk Lazarus does. Cheap low-res icons and ugly out-of-place menu bars everywhere...

As far as the questions some people had about how feature-complete Community Edition is though: it is in fact completely identical to the Professional Edition, meaning full optional support for all platforms (Win64, Android, iOS, OSX) except Linux Server, and meaning it includes the complete source code for the Delphi RTL, VCL, FMX, e.t.c frameworks.

Regarding the fact it includes the source, also: more simply put, this means that complete Delphi library source code is now available to literally anyone at all in a free, legal download, whereas before it was only available to those who either pirated Delphi or paid for one of the more expensive licenses. So there is perhaps a somewhat higher chance of future FPC/Lazarus patches including plagiarized code, which is something the devs might want to keep an extra-attentive eye on going forwards.

I searched info what FMX use under the hood as native macOS GUI..., but did not find.

FireMonkey is a completely GPU-based, hardware-accelerated API. It uses DirectX on Windows, and OpenGL on all other platforms.
You can always add all sources to project itself - click on your project in source tree and choose "Add...". Otherwise it's better to use packages. Static ones are simply bunch of DCUs, packed into one file. Same as in Lazarus, but pre-compiled. And dynamic packages are actually great feature, as they're exactly the same, as DLLs, but allow you to share ANY CODE (including classes) - not just procedures/functions. Without it large amounts of shared code would be duplicated and that will cause waste of both disk and memory space. And this is very important for code-heavy projects. Imagine, that you have application with hundreds of plugins, that are implemented via DLLs, and every plugin should use VCL. If you won't use packages - each plugin would have to contain copy of VCL code and may be some other shared code, related to your application, i.e. several megabytes of code. Is it good? No. And unfortunately there is no solution of such problem in Lazarus, so Lazarus is still unsuitable for large applications with complex structure.

Problems, I personally have with Delphi: 1) 32bit IDE, so "Out of memory" errors are very common. And I have to overcomplicate my projects to workaround this problem - split code between many modules. 2) Several compiler bugs, that affect complex code, that cause hard to fix internal compiler errors. For example - problems with interface implementation. Workarounds are usually a little bit clunky, such as using aggregated interfaces. 3) Problem with 64bit packages. Dunno, why this happens, but after redirecting DCP/BPL output to $(Platform)\$(Config) compiler still shows "DCU inside DCP is corrupted" errors, when switching from 32bit to 64bit and back (or Debug vs Release - I don't remember), even if I clearly see, that 32bit (or Debug) files aren't overwritten by 64bit (Release) ones (opposite is true too).

And what I want to say, is that things would be much more easy, if Lazarus would simply have D2009 support, so I would be able to completely migrate to it. But currently I can't, cuz my unit test project uses closures, that aren't supported by FPC, my projects have some Windows-related code and Lazarus has some problems with UTF-8->Unicode conversions - they aren't transparent enough and I'm afraid, that it can cause some unexpected side effects, such as performance penalties and corrupted data. I'm not sure about full generics support. As I know, Lazarus should have it by now.
« Last Edit: July 22, 2018, 12:08:31 pm by Mr.Madguy »
Is it healthy for project not to have regular stable releases?
Just for fun: Code::Blocks, GCC 13 and DOS - is it possible?

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4459
  • I like bugs.
Re: delphi and C++ builder community edition is here...
« Reply #54 on: July 22, 2018, 04:49:27 pm »
... my projects have some Windows-related code and Lazarus has some problems with UTF-8->Unicode conversions - they aren't transparent enough and I'm afraid, that it can cause some unexpected side effects, such as performance penalties and corrupted data.
UTF-8 is part of Unicode, one of its encodings. The issue has been discussed many times, I wonder how you can still have a misunderstanding about it.
Windows uses UTF-16 encoding. Conversion between encodings is lossless, meaning there will be no corrupted data.
LCL-Win32 makes only a reasonable amount of calls to WinAPI, the performance penalty is small. If you make millions such calls in your code, you should use UnicodeString type explicitly. Even then your code is 100% compatible with Delphi.
You can write fully compatible code even if you want to iterate over individual codepoints.
Thus, Unicode is not really an issue!
« Last Edit: July 22, 2018, 04:52:38 pm by JuhaManninen »
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

Mr.Madguy

  • Hero Member
  • *****
  • Posts: 844
Re: delphi and C++ builder community edition is here...
« Reply #55 on: July 22, 2018, 05:33:44 pm »
UTF-8 is part of Unicode, one of its encodings. The issue has been discussed many times, I wonder how you can still have a misunderstanding about it.
Windows uses UTF-16 encoding. Conversion between encodings is lossless, meaning there will be no corrupted data.
LCL-Win32 makes only a reasonable amount of calls to WinAPI, the performance penalty is small. If you make millions such calls in your code, you should use UnicodeString type explicitly. Even then your code is 100% compatible with Delphi.
You can write fully compatible code even if you want to iterate over individual codepoints.
Thus, Unicode is not really an issue!
Everybody tells me, that conversion between UTF-8 and UTF-16 is pretty easy in Lazarus and even automated, while my own experience shows, that I have to use some weird constructions, like PWideChar(UnicodeString(UTF8Decode(X))), to achieve this goal and even in this case I just can't be 100% sure, that everything works correctly and no data corruption happens, i.e. that my program will work for all my users - not just me. Anyway. Currently my target is Windows only and I don't like, that internal string representation differs from external one. I also don't like, that code isn't compatible with Delphi and string processing routines are much more complex for UTF-8. In short. What I need - is free variant of Delphi. Nothing more. Till then Lazarus - is just like C++ for me. Yeah, I can use it to make some small demo projects, but I will never be able to fully migrate to it.

You should understand, that it's all about philosophy. And currently my philosophy doesn't match Lazarus philosophy. I.e., yeah, may be I can make UTF-8 work the same way, as UTF-16, but I just wouldn't like this solution - it would be clunky from my point of view. And if it matches your philosophy, then, ummm, ok. But don't tell me, that Lazarus uses this solution, because it's best possible or something like that.
Is it healthy for project not to have regular stable releases?
Just for fun: Code::Blocks, GCC 13 and DOS - is it possible?

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4459
  • I like bugs.
Re: delphi and C++ builder community edition is here...
« Reply #56 on: July 23, 2018, 12:04:26 am »
Everybody tells me, that conversion between UTF-8 and UTF-16 is pretty easy in Lazarus and even automated, while my own experience shows, that I have to use some weird constructions, like PWideChar(UnicodeString(UTF8Decode(X))), to achieve this goal and even in this case I just can't be 100% sure, that everything works correctly and no data corruption happens ...
For some reason you still live in a pre-Lazarus 1.6 era. UTF8Decode() or other UTF-8 specific functions are not needed any more. The Unicode support is now better and more Delphi compatible than it used to be.
To call a WinAPI function please read this:
 http://wiki.lazarus.freepascal.org/Unicode_Support_in_Lazarus#Calling_API_functions_that_use_WideString_or_UnicodeString
For a PWideChar parameter you need an extra variable of type UnicodeString and an extra assigment. Even then the code will be 100% Delphi compatible. You can maintain such code between FPC/Lazarus and Delphi without IFDEFs or other hacks.

Quote
I also don't like, that code isn't compatible with Delphi ...
All existing code is not compatible with Delphi but you can easily write code that is 100% compatible.
Please read the same wiki page again for details:
 http://wiki.lazarus.freepascal.org/Unicode_Support_in_Lazarus
Check also the unit LazUnicode which provides helper functions and iterators for codepoints and Unicode "characters" using both encodings.

Quote
... and string processing routines are much more complex for UTF-8.
Not really. Both UTF-8 and UTF-16 are variable width encodings and the routines must deal with it.
And why would you care? You just call functions like AnsiUpperCase() or AnsiCompareText(), you don't need to look at their complexity. Besides, the complexity of those functions is not about encodings. The true complexity of Unicode is way beyond encodings.

Quote
In short. What I need - is free variant of Delphi. Nothing more. Till then Lazarus - is just like C++ for me. Yeah, I can use it to make some small demo projects, but I will never be able to fully migrate to it.

You should understand, that it's all about philosophy. And currently my philosophy doesn't match Lazarus philosophy. I.e., yeah, may be I can make UTF-8 work the same way, as UTF-16, but I just wouldn't like this solution - it would be clunky from my point of view.
No, it is about lack of understanding of Unicode and maybe a desperate attempt to reignite yet another war between the encodings.
Lazarus 1.6.0 was released almost 2.5 years ago. Since then it has been possible to write Delphi compatible source code that deals with Unicode, without the UTF-8 specific functions, even the systems use different encodings. Cool, isn't it?

Quote
And if it matches your philosophy, then, ummm, ok. But don't tell me, that Lazarus uses this solution, because it's best possible or something like that.
The Lazarus solution is a hack from FPC's point of view as Lazarus (LazUtils actually) changes the default encoding of AnsiString. Thus it is not the best possible solution.
However UTF-8 encoding is more robust than UTF-16, mostly because people still treat UTF-16 as UCS-2. So, UTF-16 encoding itself would be OK if people used it correctly but they don't. :(

Anyway please forget philosophy when talking about Unicode encodings. A question like "what is the purpose of life" is philosophical. Unicode encodings on the other hand are very pragmatic and trivial. They are easy to get right in any case. Please don't make a fuss about them.
« Last Edit: July 23, 2018, 12:13:55 pm by JuhaManninen »
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

bee

  • Sr. Member
  • ****
  • Posts: 393
Re: delphi and C++ builder community edition is here...
« Reply #57 on: July 23, 2018, 05:31:42 am »
You should understand, that it's all about philosophy. And currently my philosophy doesn't match Lazarus philosophy.

No, it's not about philosophy, far from it. You just want Lazarus to be a free clone of Delphi so you could migrate all of your Delphi projects into Lazarus without any additional efforts. It's so obvious, plain, and simple. While it may advantageous to some people, but I prefer FPC and Lazarus to be better than Delphi and be proud of itself, instead of keep being under the shadow of Delphi, in the name of compatibility. As a long time user of FPC and Lazarus, I don't even care about Delphi compatibility.
-Bee-

A long time pascal lover.

Akira1364

  • Hero Member
  • *****
  • Posts: 561
Re: delphi and C++ builder community edition is here...
« Reply #58 on: July 23, 2018, 05:59:54 am »
You should understand, that it's all about philosophy. And currently my philosophy doesn't match Lazarus philosophy.

No, it's not about philosophy, far from it. You just want Lazarus to be a free clone of Delphi so you could migrate all of your Delphi projects into Lazarus without any additional efforts. It's so obvious, plain, and simple. While it may advantageous to some people, but I prefer FPC and Lazarus to be better than Delphi and be proud of itself, instead of keep being under the shadow of Delphi, in the name of compatibility. As a long time user of FPC and Lazarus, I don't even care about Delphi compatibility.

In fairness to "Mr. Madguy", Delphi compatibility is kind of a big long-term goal of Lazarus (and FPC). One might argue that all of the core developers care too much about Delphi compatibility. The problem is that while Lazarus is in many ways a far better IDE than the Delph IDE, FPC as a language gains nothing by simply lacking capabilities that Delphi as a language has, for no good reason. It just means that it, well, doesn't have them, and is as such unable to compile various useful Delphi libraries that require those capabilities.
« Last Edit: July 23, 2018, 06:01:55 am by Akira1364 »

bee

  • Sr. Member
  • ****
  • Posts: 393
Re: delphi and C++ builder community edition is here...
« Reply #59 on: July 23, 2018, 06:41:32 am »
FPC as a language gains nothing by simply lacking capabilities that Delphi as a language has, for no good reason. It just means that it, well, doesn't have them, and is as such unable to compile various useful Delphi libraries that require those capabilities.

Not literally mimicking Delphi language features doesn't mean FPC isn't capable of offering similar features or even better features. Why should we limit ourselves by Delphi capabilities? Couldn't we think independently and creatively by ourselves to provide better language features in FPC?

Compatibility should be a two-way street which each one respects the other. So far, I see Delphi seems to "dictate" the development of FPC and Lazarus, while on the other hand Delphi treats FPC as if it doesn't exist. I don't see other modern Pascal variants such as Oxygene and SmartPascal are so devoted to Delphi like FPC/Lazarus.

FPC/Lazarus in my opinion is better than Delphi in many aspects. I hate to see anyone think that FPC/Lazarus is just a free clone which trying so hard to be the counterfeit version of Delphi. It's disrespecting the developers and their hard work.
-Bee-

A long time pascal lover.

 

TinyPortal © 2005-2018