Modern C++ and Delphi

[David Champion 48]

With the new standards for C++ and modernisation of the compiler; C++11, C++17 and C++20... the language is becoming more developer friendly.

I am beginning to wonder if this is becoming a viable alternative to Delphi for some project types. 

 

I have the requirement to implement some scientific type applications and it will be much easier to convince management to use C++ than Delphi.

For myself I can leverage the familiarity of VCL libraries whilst I improve and extend my C++ language skills.

 

Are there any other developers who think the same or have moved in this direction?  I'd value an opinion.

 

 

 

Edited September 28, 2019 by David Champion

[David Heffernan 2353]

Why would you be drawn to Embarcadero C++ tools? If you are going to consider C++ then you have a much wider range of options. 

[Dalija Prasnikar 1404]

C++ Builder still has a long way to go to catch up with Delphi and probably even more to catch up with other C++ based tools.

 

If you still feel like it would be better to use C++ Builder, go to QP and check all the bugs listed under C++ Compiler and C++ RTL to see if there are any serious showstoppers for you. 

[David Champion 48]

Thanks for replying. 

 

Delphi and VCL is where I have most experience so the idea that occurred to me was to use my VCL experience to reduce the amount of effort in producing the GUI applications.

Some of the existing code is already written in Microsoft Visual C++ and HT Basic.

 

So my pitch to management would be to put it all in C++Builder and eliminate HTBasic as a supported IDE/language; presenting it as a simplification.

Even if I just re-developed the HT Basic code in C++Builder that would likely make the project easier to handle. 

 

But my general observation is that C++ is becoming less arcane and easier to handle, if you follow best practice and community guidelines.

 

The reason I'm reaching out is to see if there is any sympathy in the Delphi community for modern C++.

 

 

 

 

 

[Ruslan 6]

If the question is about of language choice, than I would recommend (as I do for my projects):

• first of all I would prefer python for scientific calculations and operations, but I don't like it because of its script language and I couldn't compile it in a lib/dll/exe, even if I do use it in some projects
• than, if the choice for scientific calculations and operations was not in favor of python, I would chose C++, it could be used to build DLLs for later use
• and last but not least, I prefer Delphi for visual/database/networking applications programming, here I can use my DLLs created in C++

What I wanted to say is that you should not stop looking in one direction, there is no just one solution for developing a project, its up to you what to chose, but need to think before and model your project before all.

[David Champion 48]

6 minutes ago, Ruslan said:

If the question is about of language choice, than I would recommend (as I do for my projects)

 

Yes, thats a great approach. I believe too that Python compliments Delphi well. It is a pervasive and capable dynamic language.

[stijnsanders 37]

I've heard about projects that would use Delphi for all user-facing interfaces like forms and configuration tools, but have all the deep-down stuff done by DLL's written in C++ that the Delphi front-end uses to make stuff work.

[David Schwartz 430]

5 hours ago, stijnsanders said:

I've heard about projects that would use Delphi for all user-facing interfaces like forms and configuration tools, but have all the deep-down stuff done by DLL's written in C++ that the Delphi front-end uses to make stuff work.

I'd go a step further and suggest implementing the UI stuff in Delphi and move the business logic into microservices. DLLs can't be moved off of the machine, but microservices can be run anywhere -- locally or moved to another machine somewhere (assuming it handles the OS needs). And you can implement microservices in whatever language you want. You could start by migrating the existing C++ and HT Basic (if that's possible) into the microservice bundle, then rewrite them any time you want later on.

 

I spent 15 years working with c and c++, but when I compare the same app implemented in both Delphi and c++ Builder, the c++ source code is invariably 2x-3x the size of the .pas code. It's just horribly verbose, which is totally ironic because most people's biggest criticism of both c and c++ is that it's often so terse as to be almost cryptic to read! Maybe some features of the latest iterations of c++ will help, but I wouldn't hold my breath. 

 

If you look at the evolution of c++, there were originally all sorts of implied namespaces for things. It's as if there were a bunch of Pascal's 'with' statements sprinkled around all of the header files. At least in Pascal/Delphi, you tend to have the benefit of a 'with' statement in close proximity to where it's used, not hidden in header files.

What I am most struck with in the evolution of c++ is how the standards folks have been sussing out all of these implied namespaces and are now requiring them to be listed explicitly. So you end up with namespace qualifiers littering the code landscape, yet offering no particular benefit in the most common use cases. NOT using them is certainly possible, but then you're right back to having implied 'with' statements throughout your code.

 

This seems to be the source of so much bloat in the c++ source files vs. Delphi.

 

You don't need to use 'with' statements in Pascal, but it sure does help to make the code a whole lot more readable in many cases.

 

Also, the way property designations are managed by the compiler in Delphi makes them very natural to read and write. In c++ they're more like having to wear galoshes over your boots while the Delphi expressions are more like lightweight flip-flops.

 

IMHO, C++ is great for lots of things, but not interfacing with UIs or the VCL.

[Bob Devine 12]

For GUI work I still think Delphi/Object Pascal is best (especially with tools like TMS FNC components and pas2js available), but for my data analysis code I'm more often using Nim-based DLLs these days (https://nim-lang.org/).  Python-type syntax and generates C at the back end.  I was never a great fan of the significant indentation style but I've got used to it.  If the interop is approached as using a C DLL, with the associated care over types, I've found interfacing with Delphi to be pretty straightforward.  Would be cool to see it as RAD Studio's 3rd language - there's at least one other Nim user who's been looking at interop - see https://github.com/AdrianV/nimbackend and https://github.com/AdrianV/nimcb.

[David Champion 48]

14 hours ago, David Schwartz said:

IMHO, C++ is great for lots of things, but not interfacing with UIs or the VCL.

 

There are some great points you have made coming from your 15 years experience in C++. Much appreciated.

 

 

[Remy Lebeau 1436]

On 9/28/2019 at 1:03 PM, David Schwartz said:

IMHO, C++ is great for lots of things, but not interfacing with UIs or the VCL.

That hasn't been my experience in my 20+ years using (almost exclusively) C++Builder.

[David Schwartz 430]

On 9/29/2019 at 6:26 PM, Remy Lebeau said:

That hasn't been my experience in my 20+ years using (almost exclusively) C++Builder.

My beef is that it's too verbose compared with Delphi. Not that it doesn't work. But if that's your exclusive experience, then of course that's what you're going to say.

 

There are some things about C++ that I sorely miss in Delphi, but I've learned to get past them.

 

But looking over the draft of the latest C++20 std proposal, mostly what I see is the need for more and more namespace qualifiers (somenamespace::dothis(xyz) constructs) that just clutter things up.

 

C++ will never have a 'with' statement, although it sorely needs it for just this reason. (And yes, it can be easily misused and abused, the same way people can set the color of a STOP button to Green and the color of a GO button to Red, and all sorts of other things that can be done if you don't apply a little common sense to them. Please don't go there!)

Edited October 3, 2019 by David Schwartz

[David Heffernan 2353]

27 minutes ago, David Schwartz said:

C++ will never have a 'with' statement, although it sorely needs it for just this reason. 

C++ already has using

Edited October 3, 2019 by David Heffernan

[Fr0sT.Brutal 900]

C has inline var declaration which is much better/safer than "with"

[Guest]

Strange discussion. I went from CBasic to C/C++. Then, when OWL was replaced with VCL, after too many years i started implementing VCL-based stuff. I then realised that not being able to trace into all the various 3rd party code was stupid. So i went from C++(Builder) to OP. And i like 🙂. Not because of better language readability (a point, though) but because the best 3rd peaty stuff is coded in OP and not C++.

Edited October 3, 2019 by Guest
Added the last sentence

[Fr0sT.Brutal 900]

Yep, Builder always was a poor child compared to Delphi.

[David Schwartz 430]

On 10/3/2019 at 12:30 AM, David Heffernan said:

C++ already has using

I didn't know that. 🙂

[David Schwartz 430]

On 10/3/2019 at 7:11 AM, Fr0sT.Brutal said:

C has inline var declaration which is much better/safer than "with"

C++ has had inline var declarations forever, that's true; although I disagree with your conclusion, mainly because I never saw them used much that way when I worked with C++. I even tried using them occasionally; I found them quite clunky to use except for relatively long lists of operations on the same base object. (It has been many years since, but the code I've glanced over still doesn't show that people use what you're suggesting.)

 

Delphi now has inline var declarations too, and I bet they won't replace with statements, or end up making code any shorter for people who are allergic to with statements.

Edited October 6, 2019 by David Schwartz

[dummzeuch 1517]

Do Delphi inline variable declarations actually work by now? I remember various bug reports on them and decided not to use them until that code is stable.

 

And then I forgot about them...

Edited October 6, 2019 by dummzeuch

[David Hoyle 68]

In-line variables work in Delphi except for a few corner cases where you have to define the type as well as the assignment (think creating interfaced objects), its the IDE's Error Insight, Code Completion, etc that don't understand them and can make life difficult.

[Stefan Glienke 2019]

15 hours ago, David Hoyle said:

In-line variables work in Delphi except for a few corner cases where you have to define the type as well as the assignment (think creating interfaced objects), its the IDE's Error Insight, Code Completion, etc that don't understand them and can make life difficult.

IOW: no, they still don't work

[David Heffernan 2353]

21 hours ago, David Schwartz said:

C++ has had inline var declarations forever, that's true; although I disagree with your conclusion, mainly because I never saw them used much that way when I worked with C++. I even tried using them occasionally; I found them quite clunky to use except for relatively long lists of operations on the same base object.

Given that you weren't aware of using, it seems that you may not be fluent and experienced with C++. Are you sure you are best placed to be offering critiques of the language?

 

Certainly my experience of using local variables in C++ differs greatly from yours. It is incredibly valuable in my experience to declare local variables at the point of use and with a narrow scope. 

[David Schwartz 430]

22 hours ago, David Heffernan said:

Given that you weren't aware of using, it seems that you may not be fluent and experienced with C++. Are you sure you are best placed to be offering critiques of the language?

 

Certainly my experience of using local variables in C++ differs greatly from yours. It is incredibly valuable in my experience to declare local variables at the point of use and with a narrow scope. 

Fair point, but it's more a matter of "when" and "where"...

 

I began using C in 1985, learned C++ about a year later and used it heavily from 1987 thru about 2000. Delphi was released in 1995 and it replaced C++ in my daily work by 2000.

 

I used C/C++ at the time b/c I was doing embedded real-time system programming. Work in business apps, mostly under Windows, was taking off in the 90's, and it became far easier to find Delphi work than C/C++ work.

 

Now it's getting hard to find ANY work b/c potential employers want to see 3+ years of immediate hands-on experience with whatever tools they happen to be using. (I remember seeing an ad for a job about 6 months after Apple published their iOS API that stated "must have at least 3 years experience working in iOS".) It's possible to learn pretty much anything, but you can't magically conjure up OTJ experience for them. 🙂

 

The last bunch of C code I looked at was some open-source stuff that was written in a way to simulate what C++ did, but in the author's words, "to avoid the overhead that C++ imposes at run-time". So instead, you had to write tons of highly stylized code to pretend you were working with classes.

 

The last bunch of C++ code I looked at was well over a decade old and was about as "vanilla" as you could get. It hardly even implemented any of the idioms from that famous "C++ Idioms" book. Not a whole lot of consistency across any of the class designs.

 

There was also a Delphi gig I had around 2004 where I was asked to maintain some code written by a guy steeped in C++; it was an unbelievably large and convoluted class library in Delphi that was extremely hard to figure out even with C++ expertise.

 

Ditto for Delphi. In fact, all of the Delphi gigs I've had in the past 10 years were all maintaining D6/D7 code. Sadly the main reason a couple of them migrated to newer versions of Delphi was because the IT people there forced them to upgrade SQL Server and they needed to upgrade some libs they used with it that were only available in newer versions of Delphi.

 

So aside from the fact that I try to keep up with the latest Delphi features myself, it's not due to any actual employment / OTJ needs.

 

As an aside, there was a time I was working on learning Java. It's very similar to C/C++ in my mind, and Java 8 had just been introduced. I ran into a curious problem. I'd see job reqs that just specified "Java" (no version#) and libs like Spring. When I'd inquire more deeply, I'd find out they were almost all using Java 5. I talked with a VP of software at InfusionSoft at a job fair about this and asked, "When are you moving to Java 7?" and he admitted their entire platform was based on Java 5 and they had a few guys working on Java 6, but it would be at least 2 years before they could switch because they'd have to completely rearchitect their entire platform first. Meanwhile, he said they were hiring as many Java (?) developers as fast as they could.

 

State Farm moved their world development HQ to Phoenix and they have been hiring Java devs like crazy. All Java 5 at the time I inquired, but they don't say that in any of the job reqs I've seen.

 

I was particularly interested in the functional aspects added to Java 7, and not one place I talked with said they're using them (or even Java 7 itself).

 

Kind of the same way none of the Delphi projects I've worked on use Interface units for anything other than those mandated by OCX. The last place I was at, my colleagues complained about my use of functional code stuff in Delphi using a library that made it much easier. It sure did simplify the code and make it a lot easier to read, but they just weren't interested.

 

So I'm glad to hear there are places that actually keep up with new languages features and idiomatic uses. That's not what I've encountered over the past 25 years in this field, and not for lack of trying. I've found places that use the latest versions of Delphi, for example, but almost none of the features introduced since D2010. Trying to introduce them starts pushing upstream against fears rooted in the harm refactoring can have vs. stability. Very little new code is being written, and when it does happen, they want you to follow existing coding practices so future maintainers don't have to deal with a variety of coding styles.

 

That sort of attitude is hardly language-specific in my experience.

 

As the old saying goes, YMMV.

 

Edited October 8, 2019 by David Schwartz

[Stefan Glienke 2019]

2 hours ago, David Schwartz said:

I've found places that use the latest versions of Delphi, for example, but almost none of the features introduced since D2010. Trying to introduce them starts pushing upstream against fears rooted in the harm refactoring can have vs. stability. Very little new code is being written, and when it does happen, they want you to follow existing coding practices so future maintainers don't have to deal with a variety of coding styles.

 

That sort of attitude is hardly language-specific in my experience.

FWIW in Delphi that fear is often caused by the fact that new features often don't work for years and are poorly designed so they affect some important aspects negatively such as compile speed or runtime performance which often you encounter way later when you already extensively use them (latest example: inline variables). Many other languages have a plethora of incredibly smart people designing things for years with enough time to thoroughly test and ensure they are zero or minimal overhead.

Edited October 8, 2019 by Stefan Glienke

[David Schwartz 430]

Much of this is true, and I'd like to say it's Delphi-specific. But when you suggest redesigning an app by moving the business logic to so-called micro-service APIs, they cringe.

 

Then someone comes along and suggests doing something analogous using Microsoft's latest stuff and their ears perk up as if they'd never heard it before. And they don't even seem to notice when 2-3 zeros are added to the total cost.

 

I've never seen a "migration" from a large stable Delphi app to a full .NET web-service app succeed. At least, not in the time I was working at these places, and they all were scheduled to be complete during my tenure by had barely made headway by the time I left. 

 

I just don't get it. It's actually pretty straightforward to migrate business logic out of a Delphi app incrementally, and improve the testability dramatically along the way. But Management always seems to jump on the Microsoft bandwagon that restarts everything from scratch with a whole new design.