Site icon Embarcadero RAD Studio, Delphi, & C++Builder Blogs

Upgrading C++Builder 12.2: Tip #7, bcc64x tips!

Upgrading to C++Builder 122 Tips Tricks 7 bcc64x
Screenshot Radically Different Why C++Builder 122 Matters webinar

Welcome to a series of tips and tricks for taking advantage of the new Windows 64-bit Modern toolchain in C++Builder / RAD Studio 12.2! This builds on a webinar we did sharing a bunch of useful information on why and how the new C++Builder matters to you, where this was the very end (so go watch the start!)

Tip #7: bcc64x tips

For the final in the series of tips and tricks, let’s look at bcc64x. Bcc64x.exe is the name of the Windows 64bit Modern C++ compiler, on the command line.

Less warnings = faster compile

Yes, really. The more warnings the compiler encounters the slower it compiles. This is a really noticeable effect.

It’s another reason to compile with -Wall, and fix every issue. Don’t let the compiler be interrupted. Just because it doesn’t print a warning doesn’t mean it doesn’t see the warning condition.

Use-after-frees

Do you see a crash where the memory is filled with 0x80 bytes? (Eg, ‘access violation at address 0x000012341234abcd’ and when you look at the memory that it’s pointed to, it looks like 0x80808080?)

This is where memory is used after having been freed. The new RTL’s memory manager marks all freed memory with this byte pattern, not null, and not leaving it as-is. This makes it very easy to spot when something is used when it no longer should be.

Check for uninitialized variables

If you can’t build with -Wall, please at least build with Wuninitialized to catch using variables before they were iniitalised with a value. This will cause a trap to be emitted by the new compiler. (See this blog.) But really, we recommand -Wall. See all the variants of top #4 for all the many reasons why: basically, the compiler finds bugs for you (and they are genuine bugs.)

Using fast parallel compilation via direct compiler invocation

The new parallel compilation system is used by default when you install 12.2 and use the new platform. This is for building in the IDE, and building on the command line with msbuild.

If you want to use it using bcc64x directly, use the –jobs parameter:

[crayon-676268c7d9f60330177227/]

This batches the files (sends lots of source at once: a.cpp, b.cpp, c.cpp, all on the same command line) and then uses jobs to compile all the batched files in parallel. ‘0’ is a value meaning to saturate the CPU. You can pass -1 to almost-but-not-quite saturate, and any positive integer to use up to that many cores.

Testing for the new compiler in code

First, do you need to? We’ve found that any C++ library that works with mingw-llvm or is available on msys2 likely works with bcc64x. Sometimes, you need to remove workarounds, which is in the form of looking for and moving ifdef-s for BORLANDC, because these days the workarounds are for issues that don’t exist and using the workaround can itself cause problems.

So it is unlikely you need to add a test for this compiler in most C++ source.

You may need to add a test for the compiler if you are upgrading, temporarily, such as to have specific code that is compiled when using the new Win64 only.

Either way, if you do need to test for it, this is our recommended test:

[crayon-676268c7d9f6d050036184/]

as in:

[crayon-676268c7d9f76184334092/]

This checks if it’s our compiler, and if it’s based on Clang 15 or newer (meaning this check will continue to work as we update further.)

 

Exit mobile version