Yesterday, we released RAD Studio 10.2.3!  Over the next week, we'll be blogging about some of the new features.  Today I'd like to look at the introduction of rename refactoring for C++.

What is refactoring?

Over time, code grows and changes.  You need to maintain it: in fact, one sign of a good programmer is keeping the codebase clean: well organised, well separated with clean interfaces between segments.  Refactoring is the process of rearranging code to move or restructure it to keep it well organised.

You can do all this manually.  But much of this can be automated.

Rename Refactoring

One useful automatable refactoring is renaming elements in your code: methods, variables, types and so forth.  Perhaps you come across a misnamed variable while looking for something else: a clean coder will rename it, there and then, always keeping code accurate.  Or, perhaps your code has grown, and your Foo class needs to be split up: you might start by renaming it FooAbstract before creating a couple of subclasses and moving methods into them. For all of these, you can manually search and replace, but you may get false positives - not all Foo-s refer to the same class.

Better is to have IDE tooling that is aware of the language and rename all references. It does the work for you, and you know it is correct because the items that are identified to be renamed are done so through language- and project-aware analysis.

This is exactly what we've implemented in RAD Studio 10.2.3.

Rename Refactoring in 10.2.3

In 10.2.3, you can right-click on an identifier (method, type, variable, etc) in the editor and in the popup menu that appears, select Refactor > Rename.

Then, in the dialog that appears, enter a new name:

Check the 'Preview changed before applying' checkbox to have a look at the changed it will make before applying them. Or, if you wish, uncheck this and it will rename immediately.  If you leave it checked, you'll see the Apply Patch pane appear:

Scroll through the list and check what it plans to change.  You can click the cube refactoring icon on the toolbar to apply the rename.

Either way, if you preview the changes first or uncheck the checkbox and apply immediately when clicking Ok, the rename will be applied!

Technical info

In 10.2.3, we have the core of a new C++ language analysis and database in the IDE. This is based around Clang, and so your project should be using the Clang compilers. This builds an AST cache for your project(s). In this release, it's used only for rename refactoring, and is updated only when you invoke rename refactoring. That means the first time you rename something that is shard by multiple files (ie not a local variable, but a common class, say) it will build the cache, but thereafter it will only need to build the changed files since last time.

You can rename any common identifier, like class or other type names, fields, methods, and variables. There are a few caveats, such as not being able to rename inside a macro that is disabled (an #ifdef that is not defined) - this is because it uses the compiler itself. This guarantees correctness, and means that renaming only sees what the compiler sees.

Renaming works at the project level.

We're focusing on improving the IDE's tooling in several ways. Rename refactoring is just the first step!



Reduce development time and get to market faster with RAD Studio, Delphi, or C++Builder. Design. Code. Compile. Deploy.

Start Free Trial   Free Delphi Community Edition   Free C++Builder Community Edition   Upgrade Today  

  • I'm thinking that contains some good example(s) to start with. 27 april 2017 I have posted one that shows Clang being really slow, and its being very quiet there since then. Just retried building that very same example in version 10.2.3 and Clang now seems to be even slower? Clang builds that specific example project in 61.2 seconds, against a really speedy build of 3.8 seconds of BCC.
  • Fantastic! This was a big missing piece of the puzzle in C++ Builder, especially with larger projects. I look forward to trying it out!
  • I'll send you an email. The login for the support form doesn't work (using either username or email address). The password reset form also never sends a reset link. My current password works for the forums and Jira without issue.
  • That's great - thankyou! Best way is to file a support request, and then you can share the files with Support. Any difficulties, please contact me - firstname dot lastname at
  • I now have an example project I can share privately that compiles (on my machine) in 15s using bcc32 and 2m6s using bcc64. Who should I contact and how should I contact them?
  • I hope to be able to put together a sample for you later today. We have observed the speed issue with all our projects that we changed to bcc64 or bcc32c. The example times I gave in my previous comment were from a project I selected because it's one for which we still have the Win64 platform active. It's by no means our largest project file.
  • Hi Tobin, "...but it's not hard to see... one of our base libraries." I think this is the issue: it's not hard to see for code that demonstrates it. But we need to know what that code is. If you can share an example with us, that would be very much appreciated! Please see if you can :)
  • I'll see if I can get permission to share an example with you but it's not hard to see. Taking one of our base libraries on my machine as an example: bcc32 takes 18s from clean to build, bcc32c takes 2m32s, and bcc64 takes 2m29s. That's almost 8.5 times longer. Building our complete ecosystem (~410 project files) takes around 45m with bcc32 on my machine. Even without needing to rebuild everything often an increase to six hours is totally unacceptable. We already run builds of the different project files in parallel so the usual suggestions of using Twine or some other 3rd party tool don't help. I don't expect Clang compilation to ever be as fast as bcc32 but it's unusable for us currently. I'm amazed if anyone with a significantly sized project will tolerate it. As it is we've put our efforts to migrate off bcc32 on hold on the assumption that this issue would be improved. I'm getting the impression that this may not happen.
  • We spent a long time in 10.2.0 profiling the Clang compiler, and found only one rare area it was unusually slow. We do still see reports of slowness, but we need code samples that show the situation. If you see this, please see if you can create a sample project that shows it and attach it to a QP.
  • "... your project should be using the Clang compilers" Has RSP-16827 been fixed? In 10.2.2 the Clang compilers are unusable. If new features rely on them then the new features are unusable too.