Embarcadero’s cross-platform XE8 RAD Studio targets iOS 8, IoT Embarcadero has released RAD Studio XE8, including Delphi and C++ Builder, with a slew of new features including a 64-bit compiler for Apple’s iOS and support for iOS Universal Apps, including 32-bit and 64-bit in a single binary. Apple requires this for all new iOS apps uploaded to the App Store, so users of earlier versions …
"what Microsoft never quite got with Visual Basic or Visual C++: rapid component-based coding with a visual designer and high-performance native code compilation."
Not really true.
VB 5 and 6 had the option of native compilation, using the same back end as Microsoft's C++. And if you were really hardcore, you could even (with a bit of subterfuge) delve in to the link phase and mess around with the object modules.
-A.
Not really true either. VB 5 and onwards may have been able to compile, but they still needed the support of a run-time library and the EXEs were't even close to C++ performance. Delphi could generate stand-alone EXEs with close to the same levels of performance.
Not really true either.
Delphi also relies on a runtime. The only difference was that this runtime can be embedded within each standalone executable. You could choose to use a shared copy of this runtime, in exactly the same way that VB5/6 did. But with Delphi if you did this then the resulting EXE required not just one but potentially many runtime DLLs, none of which were shipped with the Windows OS out of the box.
I'm not sure I see your point here. Most high level languages rely on library code, even or especially C/C++. Statically linking that code into the source is the most portable option, but takes most space. Putting it in a DLL saves space if you have multiple applications/DLLs that use it. VB goes a step further and requires the library(s) to be registered under COM in order to work. So unless the VB RTL has been installed a VB EXE will fail, and even then it's not even close to C++ performance.
A Delphi program on the other hand can run without installing stuff and at close to C++ performance, but with the ease of VB style visual development. The fact that it can work in a dynamically linked environment is a bonus.
Delphi does not run at "close to C++ performance". Its desktop compiler is ancient, over a million lines of old-style C code with no comments. In addition, much of it still follows Wirth's single-pass compiler design, which is fast but precludes many modern optimizations. In recent benchmarks on items such as the Tiger Hash, Delphi managed to achieve 1/2 of C++'s performance. It beat C# with lots of optimization, but not Java. Similarly, on SciMark Delphi not only scores far below C++, but is beaten by both Java and C#. The desktop compiler doesn't even use bit-shifting for division; in a simple benchmark that involved integer division gcc was 3x faster and even JITted Python was faster! For the record, TinyC, designed to fit on a floppy disk along with a bootable Linux kernel, only has 3 optimizations - one of which being bit-shifting.
This fascination with a single deployable exe has never seemed to exist outside of the Delphi world. I've always been unclear as to why this was important, and worse, for most applications it simply wasn't true. Everyone seems to forget that Delphi's intended niche was as a CRUD interface to databases. For many years this required the use of the Borland Database Engine, or BDE. This was *far* from a minimal dependency. The earliest versions of Delphi shipped with a copy of InstallShield that was capable of installing the BDE. No one at the time bemoaned this fact. It wasn't until .NET appeared and began capturing Delphi's market share did this notion of "not installing stuff" suddenly become the new mantra. Even then, trusting your users to copy your file(s) into the right place and be able to create icons and/or start menu launchers for them is risky and you'd probably still want an installer anyway, in which case runtime library issues become moot anyway.
Delphi doesn't need any runtime in the VB way - it has an "RTL" library just like VC++ has it, but that's just a bunch of standard OS imports, and standard non OS provided basic functions (i.e. memory manager, string manipulation, math functions, etc.), exactly like the msvcr*.dll (and other VC++ runtime dlls) used by VC++, which are not a "runtime engine" like the VB one (much more alike a VM). The generated executable is a plain Win32/64 executable mostly identical to one generated by VC++ (of course, there are some small differences)
Note that today Windows doesn't ship anymore VC++ "runtime" DLLs usable by third party applications with Windows (the ones it ships are private and reserved for the OS), because it was abused (see Raymond Chen's "The Old New Thing" blog for details). Every VC++ application is responsbile to deploy the VC++ "user" runtime (or link it statically in each application)
There are ways to write and compile a Delphi application bypassing the rtl library, as you can do in VC++, but unless you have very good reason to write a very small footprint application, it's a far less productive way of writing Windows applications.
>hey still needed the support of a run-time library
You mean MSVCRT?
Delphi had the advantatage over C that the linker was much smarter, based on the much smarter library architecture, based on the originally different design decisions for C and Pascal.
And I wouldn't agree with the idea that Delphi had only "close to the same levels of performance".Competing compilers from companies like Intel were better than Delphi, they also are and were much better than MSVC and MSVC++.
Modern C compilers have picked some or most of the difference by making the language more Pascal like: C++ was able to go closer to Delphi and Pascal (and FORTRAN) in the compiler and linker design, but it took them a long time to get their, and they've had to do thinks like pseudo byref variables and pseudo keywords to get there.
Until you reach Visual Studio .NET the backend compiler is nowhere near the same. In .NET it is, but it's running on a virtual processor so isn't a native binary or running at binary speed. Performance proof? How about this http://www.sythe.org/programming-general/383073-benchmark-test-vb6-vc6-delphi6-java.html
Apples and oranges. VB's native arrays are very different fruit from C's. If the C++ program were modified to use COM SAFEARRAY instead of a raw block of memory, the results would be comparable. Or if the VB compilation options were set to not perform bounds checking they would be closer (but still not identical).
This is an artefact of the language, not the compiler.
See here for the low down on the common back end:
http://www.brainbell.com/tutors/Visual_Basic/Generating_Code.htm
-A.
That's a bit of a pointless distinction if most computationally heavy work is using arrays and you can't force the VB compiler to give you fast arrays. The link you give doesn't help your case BTW, if you work your way past all the compiler switch info you find this quote : "At The Mandelbrot Set (International) Limited (TMS), when we really need speed-and after we've exhausted all the algorithmic alternatives-we turn to the C compiler.", so they admit that VB isn't as fast as C by a noticeable fraction.
You *can* force the VB compiler to give you fast arrays. It's a compiler option. Usually it's not worth it in application code because a bug resulting in a runtime exception is a much better result than overwriting random memory addresses with garbage, resulting in who knows what weird behaviour before mysteriously crashing. For system code, VB (of any generation) is the wrong language.
In my organisation we recoded all our mathematical optimisation algorithms -- which manipulate large multi-dimensional arrays of double-precision floats -- from Fortran and C into VB after the switch to native-code compiler at VB5. No one noticed any perceptible degradation in performance.
Downvote away, fanbois!
-A.
No, the compiler option is to skip array bounds checking. This makes a small improvement to performance (at the cost of adding risk) and is something you can do in Delphi also. What you can't do is force VB to use raw memory arrays, the lack of which is where the real overhead is.
I used to make a living programming VB (every version since VB3) and can guarantee that if you needed raw performance then VB was not the answer. It was however fast enough for a lot of work, and the visual design GUI was very productive which is what made it useful.
And that's exactly the difference - while truly native compiler can set aside blocks of memory and work on them at CPU speed, languages like VB had to go through layers and layers of intermediate "safe" APIs to protected the developer from firing into its own feet...
Delphi compiler creates true Windows executable without any run-time needed. Moreover, it is a full OO language, and the components, unlike the old VB which required ActiveX and C++ - are native Delphi ones. There's a reason if MS had to hire the Delphi architect to create .NET...
Now you can buy a "database addon" for the Pro allowing to access RDMBS and use ODBC without buying the full Enterprise. Anyway, even with the Pro, third party libraries supporting ODBC will work. An attempt to forbid it by the license terms only some time ago was stopped by the customers' rage...
Kylix was killed years ago, it never gain momentum. It was based on a wrong assumption, that Linux desktop app demand was getting hot. It never happened, and the Linux distro and GUI fragmentation (and often lack of true backward compatibility) didn't help either, for a tool designed to deliver native binary executables, not source code to be compiled.
The right approach would have been to design something to build first server-side applications were Linux was already strong and got stronger, with a simplified GUI - when needed - even if unable to compete with the Windows counterpart.
But those in charge of Delphi were - and still are - unable to move away from the desktop-centric-database-fronted approach that was the successful Delphi 1.0 one. But it was Windows 3.1 epoch - most PC were desktop, servers were a few Netware or Lan Manager/OS/2 1.x ones, or huge Unix boxes. Still today, the multiplatform approach means mostly client-side GUI applications only, although attempts are made to cover more "desktops", including the smartphone ones. But Delphi still offers a very weak server side development support with half-backed, underperforming frameworks.
It's a pity, because the language offers strong and powerful OO features, while being far easier to learn and master than C++ (while C++ *is* verbose as well...), and can deliver fully CPU native compiled code.
But the compiler has been another weak point, and the latest attempt to switch to LLVM and the ARC model, again, a model good for a set of client applications (and not every) but not for heavy multithreaded server side ones, shows there's a lack of understanding that it is true that all the hype may be on "terminals" - be them app on smartphones or web clients, but often, to make them work, there are some powerful workhorse on the server side doing the big dirty job - running on Windows or Linux.
Both Delphi and Lazarus were, and still are, good for server-side development. True, most great libraries were 3rd-party (indy internet controls, were they called?), but the language/compiler supported 3rd-party memory management, full threading support and full OS API access, so, writing heavy-load servers in them was possible.
Are you sure? Write a service in Delphi, and you get something implemented over deprecated Windows NT era APIs only. The standard memory manager doesn't scale well for multithreaded applications. Support for OS native HTTP libraries came only with the latest version - at least, less dependencies on OpenSSL like when using Indy. Indy itself is developed by a few volunteers and is development is not well aligned with Delphi releases, often you got an outdated one, while the last version has breaking changes.
Its remoting framework is a joke, especially from the security perspective - but perfomance also, and there's no built-in support for any cryptographic library, not even the OS standard one. SOAP was implemented partially - of course fashion dictates RESTful apps only now, who cares if VMWare uses SOAP, for example (and up to XE7 there was a 64K limit when importing WSDLs...!) -, and there's no support for any kind of message queues. Also, no support for AD, LDAP, Kerberos, etc.
Compiler optimizations are just a few and often targeting older CPUs.
Try to write an MMC console snap-in, and you have to start from scratch.
Sure, you can fully access the OS APIs so you can do all the plumbing yourself (most third party libraries target UI widgets and database access only...), if you have the skills - but look at the price, especially now that maintenance is mandatory if you want *any* fix including update packs and hotfixes - it's a very expensive tool for what it offers for server side development, especially if you have to write most of the stuff yourself, often running into silly bugs, or buy external libraries, if you can find them, tha market shrunk a lot in the past years.
Actually, they sell a fake Metro, there are skins to make plain Win32 apps to look alike Metro ones - but they still runs only on the Windows desktop, don't run in the WinRT sandbox, and can't take advantage of WinRT APIs and touch input support. AFAIK there's also a tile app you can drive through HTTP (!) to try to make the application somewhat accessible from the Start screen.
Even in the "Land of Fruit" and among "Electronic Sheeps Shepherds" you just get "moslty fake" interfaces, because the UI library doesn't use native components but draws its own imitations. It eases somewhat cross-platform compatibility, but the "user experience" is not exactly identical, and if the OS changes its appearance, the app won't adapt unti a new "skin" is released (and the application updated).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
