Cost benefit analysis of moving project from Classic compiler to Clang

[Lachlan Gemmell 33]

We're a Delphi development company but we've inherited a C++ Builder project that we're now responsible for maintaining.

 

The rough stats of the main application project are

• Rad Studio Berlin, classic compiler
• approx 500K C++ lines,
• 200+ forms,
• 100+ QuickReports,
• Quite a lot of very long files 10K+ lines
• Lots of very long functions 1K to 5K lines
• Compile and link time is about 10 minutes
• The precompiled header wizard fails on the project
• Twine compile fails on the project

 

There's also a bunch of support BPLs (largest about 60K lines) and the application is built with runtime packages. We can't get it to link with runtime packages turned off but that's a question for another day.

 

As Delphi programmers who haven't really touched C++ in decades this code base is extremely easy to read. It reminds me very much of the C++ I was taught at university in the early 90s. Swap curly brackets for begin/end and there is barely anything in there we don't immediately understand.

 

I'd say it's unlikely that we would want to start using advanced C++ language features until much further down the line. At the moment we're just trying not to upset the apple cart.

 

We will in the near future move from Berlin to Alexandria and then attempt to stay no more than a version behind from then on.

 

We are yet to even give it a try but should we attempt a move to the Clang compiler?

 

I guess the primary thing we're really looking for is a way to improve compile times. Is Clang faster than Classic?

 

Are there other major benefits to Clang that as Delphi programmers we're just not aware of?

 

If you would recommend switching to Clang, how difficult a process is it likely to be give that our C++ knowledge is not all that great.

[David P 3]

In my experience:

 

Clang produces faster code

Classic is faster to compile

Clang gives better warnings/error messages.

Clang is more standards compliant I believe.

Clang is the future for BCB

 

Compilation speed: Use either Twine Compile, or use Clang Batch compilation to improve compilation speed.

 

Making our code compile using clang was fairly simple as the warnings/errors given are very helpful.

[GoEk 0]

On 4/17/2023 at 2:05 AM, Lachlan Gemmell said:

 .... 100+ QuickReports, ....

Unfortunately Quickreport is not really maintained anymore, last version of supported RAD Studio is Rio. Apparently one of their founders passed in 2019:

 

https://www.quickreport.co.uk/sad-news/

Edited April 19, 2023 by GoEk

[Remy Lebeau 1636]

On 4/17/2023 at 7:54 AM, David P said:

Clang produces faster code

Classic is faster to compile

Clang gives better warnings/error messages.

Clang is more standards compliant I believe.

Clang is the future for BCB

The RTL/VCL/FMX frameworks are much better supported in Classic, but spotty at best in Clang.

Edited April 19, 2023 by Remy Lebeau

[Roger Cigol 134]

My experience is that for legacy projects, unless you have a really good reason to change (ie a major new requirement where you'd like to use modern C++ code constructs) then stick with Classic. I still use Classic for significant (to my customers) projects. It does build much faster than the clang compiler. I most definitely wouldn't dream of using clang without the benefit of TwineCompile because the build times would become unmanagable. I wonder why you can't get TwineCompile to work with your classic compiler? I use TwineCompile for all projects and wouldn't want to be without it. I've never had a problem with a classic compiled project working/not working with TwineCompile. {too many negatives: I mean: Classic compiler projects always work with TwineCompile for me).

[Lachlan Gemmell 33]

Thanks for the feedback gents, it sounds like this particular project is best suited to stay with the classic compiler for the foreseeable future.

 

As Delphi programmers we've worked with similarly sized and structured Delphi projects that take around 20 seconds to do a full build. With a current build time of around 10 minutes for this C++ project I can't even conceive of doing anything that would increase the build times even further.

 

QuickReport no longer being supported isn't an issue as it was shipped with full source so we can move it to the later IDEs as we need to.

 

As to why TwineCompile and the pre-compiled header wizards fail on this project, my guess is that the "uniqueness" of how the code has been structured in some places may be defeating them. We're gradually replacing that "uniqueness" with some more straightforward code and perhaps one day in the future those tools will run successfully.

[Lajos Juhász 325]

On 4/26/2023 at 2:40 AM, Lachlan Gemmell said:

QuickReport no longer being supported isn't an issue as it was shipped with full source so we can move it to the later IDEs as we need to.

It's an issue due to it's high dpi problems.

[Lachlan Gemmell 33]

2 hours ago, Lajos Juhász said:

It's an issue due to it's high dpi problems.

Thanks for the heads up. We're in a controlled environment with high DPI screens for the users being a distant reality but it's good to know about the issues before they happen.

[Fr0sT.Brutal 904]

Is it such a significant difference between those compilers from the point of source code?

[Roger Cigol 134]

Yes: Classic compiler has no support for any modern C++ language features. Once you use Clang it is hard to go back to Classic limitations.

[Fr0sT.Brutal 904]

But are there any incompatibilities between them? Why the question in topic even appeared, why not just write portable code and switch compilers any time?

[Michaell 3]

On 4/17/2023 at 2:05 AM, Lachlan Gemmell said:

...

1) We are yet to even give it a try but should we attempt a move to the Clang compiler?

2) I guess the primary thing we're really looking for is a way to improve compile times. Is Clang faster than Classic?

For the audience which is finding this old topic here my experience:

regarding 1): If you have no good reason to switch the compiler: Don't do it, it will cost you weeks of work and at the end you will have a big disadvantage at 2). 

regarding 2): please see this information

[Roger Cigol 134]

On 7/30/2025 at 8:59 AM, Michaell said:

If you have no good reason to switch the compiler:

I agree entirely with @Michaell

 

However there actually are often good reasons to switch, common ones are any of:

 

a) you want to write 64bit applications

b) you want to use any of the modern C++ features (for example the use of "auto" is often really useful (aka essential) for templates)

c) you want to use any modern C++ library (most up to date versions of libraries fail to compile on "Classic")

d) you employ a young C++ programmer who finds it frustrating to work with "Classic", having got used to working with modern C++ constructs available.

 

For any project with a long term future there is likely to come a time where you will want to change to Clang. The compilation time is a real pain! But you learn to structure

your code such that a full build of all files is not required so often. (There is also the "module" approach coming to C++ bit by bit which is claimed to speed up compilation,

but that is very definitely another topic!).

I have moved most of my main projects across to Clang. I have one more commercial project to migrate and am just waiting for the right moment (which is related more to

commercial and administrative considerations rather than technical ones).

[Gord P 17]

On 8/4/2025 at 2:42 AM, Roger Cigol said:

However there actually are often good reasons to switch, common ones are any of:

 

a) you want to write 64bit applications

b) you want to use any of the modern C++ features (for example the use of "auto" is often really useful (aka essential) for templates)

c) you want to use any modern C++ library (most up to date versions of libraries fail to compile on "Classic")

 

Presently I don't need 64 bits, but I would like b or c.  I put in a request to have the modern tool chain accessible to 32 bit projects so there is one less thing I have to work through while sorting the new tool chain out.  I don't think Embarcadero is interested in doing that, but you never know.

 

Edit:  It is ironic that their own IDE is 32 bits and that they are just now experimenting with the 64 bit version yet they expect all their users to be totally in the 64 bit camp.

Edited Wednesday at 10:15 PM by Gord P

[Lajos Juhász 325]

8 hours ago, Gord P said:

Edit:  It is ironic that their own IDE is 32 bits and that they are just now experimenting with the 64 bit version yet they expect all their users to be totally in the 64 bit camp.

 

I strongly believe that the move to 64 bit IDE was forced due to the fact that more and more database engines allowed only 64 bit access. On the other hand this could be enable to debug a 64 bit Delphi code.