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 1401]

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 103]

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 293]

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 900]

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

[Roger Cigol 103]

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 900]

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?