c++ C++빌더가 선보일 새로운 기능: 멋진 프리뷰를 확인해보세요!

[김나래]

• 원문제목: What’s Coming for C++Builder: An Amazing Preview
• 원문: https://blogs.embarcadero.com/whats-coming-for-cbuilder-an-amazing-preview/
• 작성자: David Millington (2023.3)

 

A few weeks ago we released RAD Studio and C++Builder 11.3, a quality release that’s been met with wide praise as the best of any recent version. This builds on several releases of 11.x, including our dedicated C++ quality release, 11.1.5. With that quality background, we want to share our plans for the future of C++Builder and C++ within RAD Studio.

몇 주 전 출시한 RAD스튜디오와 C++빌더 11.3이 최근 출시된 버전들 중에 최고의 품질이라는 긍정적인 피드백을 받고 있다는 소식에 매우 기쁘다. 이번 릴리스는 이전에 출시되었던 C++ 전용 버전 11.1.5의 기능을 포함한 11 알렉산드리아의 이전 버전들을 기반으로 하고 있다. RAD스튜디오에 포함되어 있는 C++과 C++빌더의 미래에 대한 우리의 계획을 공유하고자 한다.

We see questions around our plans for C++Builder in multiple areas: support for newer C++ standards like C++20 and C++23; improving the debugger; resolving issues linking large projects; STL quality; productivity like code completion, navigation, and refactoring; and support for other platforms, like Android or Linux.

C++빌더에 대한 우리의 계획에 대한 질문들은 우리도 파악하고 있다. C++20, C++23 등 최신 C++ 표준 지원, 디버거 개선, 대규모의 프로젝트 연결 문제 해소, STL 품질, 그리고 코드 완성, 탐색, 리팩토링과 같은 생산성 부문, 안드로이드나 리눅스 등 플랫폼 지원 등에 대해서 말이다.

 

We are addressing these with two major steps:

이와 같은 문제 해소를 위해 우리는 두 가지 부분에 집중하고 있다:

1. Clang 업그레이드 - 단순히 Clang을 '업그레이드'하는 것이 아니라 '제대로 하기'라는 매우 다른 접근 방식을 취하고 있다.
2. 비주얼 어시스트의 주요 기능을 C++빌더에 통합하기

This, both what we’re doing and the approach to what we’re doing, is very exciting. Read on – not just for what we’re doing, or why, but even screenshots showing it in progress!

우리가 하는 작업과 접근 방식 모두가 매우 흥미롭다. 우리가 무엇을 하고 있는지 뿐만 아니라, 왜 하고 있는지까지. 그리고 진행중인 부분을 확인할 수 있는 스크린샷까지 정리해보았다!

 

목차

Clang 15로의 업그레이드

런타임과 STL

출시 계획

지속적인 최신 상태 유지

Clang 업그레이드 내용 정리

미리보기

비주얼 어시스트 통합

미리보기

최신 Clang, COFF, 그리고 비주얼 어시스트?!

---

 

Clang 15로의 업그레이드

C++Builder’s compilers are based on Clang, extended with our language extensions. The language extensions are for interoperability with Delphi: if you did not know, the two languages can be compiled into the same application, and even have classes in C++ inherit from classes defined in Delphi. C++ can also use and refer to Delphi-implemented code through translated headers, as well as use Delphi-isms like properties.

C++빌더 컴파일러는 Clang을 기반으로 하며, 언어 확장을 통해 더욱 확장되었다. 언어 확장은 델파이와의 상호 운용을 위한 것으로, 이를 통해 두 언어를 동일한 애플리케이션으로 컴파일 할 수 있으며 C++의 클래스가 델파이에 정의된 클래스를 상속할 수도 있다. C++는 번역된 헤더로 델파이로 구현된 코드를 사용하고 참조할 수 있을 뿐 아니라, 프로퍼티와 같은 델파이 고유 기능도 사용할 수 있다.

In 2018, we upgraded to Clang version 5, which provided C++17 support.

2018년, C++17을 지원하는 Clang 버전 5로 업그레이드했다.

Now, we’re upgrading our current Clang, Clang version 5, to Clang 15 – a massive jump in features and C++ compatibility.

현재는 Clang 버전 5에서 Clang 15로 업그레이드하고 있다. 이로써 C++ 호환성과 기능이 대폭 향상될 것이다.

But this is not an upgrade like our previous upgrade (from 3.3 to 5 in 2018), in many ways.

하지만 이번 업그레이드는 여러 측면에서 이전의 업그레이드 (2018년의 3.3에서 5로)와는 다르다.

In the past we’ve always had somewhat of our own way of doing things. For example, we use ELF64 (typically a Unix/Linux object file format) as the object file format on Win64 with DWARF as the debug info format, for various reasons.

과거에는 늘 우리만의 고유한 접근 방식이 있었다. 한 예로, 여러 이유로 Win64의 개체 파일 형식으로는 ELF64 (일반적인 Unix/Linux 개체 파일 형식)를 사용하고, 디버그 정보 형식으로는 DWARF를 사용했었다.

 

C++Builder has its core differences, which are our benefits: Delphi compatibility; the language extensions; the things that let us develop forms and frames and use the VCL and FireMonkey – and those differences are valuable. But our current Clang implementation contains some custom elements with no inherent value, and is slowly becoming a maintenance cost without adding to the overall amazing benefits of C++Builder. We are different from platform conventions for legacy reasons. But if we were to follow platform conventions, it would mean less customisation in our toolchain for us to maintain, fewer custom tools, and significantly increased compatibility for you.

C++빌더에는 차별화되는 핵심적인 기능들이 있다. 델파이 호환성, 언어 확장, VCL과 파이어몽키를 사용해 폼과 프레임을 개발할 수 있도록 하는 기능,  이 모든 것이 C++빌더를 가치있게 만들어주는 차이점이다. 하지만 현재 Clang 구현에는 고유한 가치가 없는 일부 사용자 지정 요소가 포함되어 있으며, C++빌더의 전체적인 놀라운 이점들은 추가하지 못한 채, 유지 관리만 증가시키고 있다. 엠바카데로는 레거시적인 이유로 플랫폼 관점에서는 벗어나 있지만 플랫폼 규정을 준수한다면, 유지 관리해야 할 도구 체인의 사용자 정의는 줄어들고, 호환성은 크게 향상될 것이다.

 

As a result the Clang upgrade is planned not to be an upgrade of our existing compiler with all extra material, but an upgrade of the core key architecture of our compiler. This means we plan to adopt a more platform-standard approach: to emit COFF object files (the ‘native’ or by-convention Windows format); use the PDB format for debugging; use the LLVM linker not ilink; and not only does this mean we can focus on the differences that for us really are key, and we can re-use open source tools and projects, like the LLVM linker. In other words, we are modifying Clang to add our benefits, not moving forward legacy tech into modern Clang.

따라서 Clang 업그레이드는 단순히 기능이 좀 추가된 기존 컴파일러의 업그레이드 수준이 아닌 우리 컴파일러의 핵심 아키텍처 업그레이드인 것이다. 이는 곧 플랫폼 표준 접근 방식을 채택한다는 뜻이기도 하다. COFF 개체 파일('네이티브' 또는 표준 윈도우 형식) 내보내기, 디버깅을 위한 PDB 포맷 사용, ilink 대신 LLVM 링커 사용 등 우리에게 정말 중요한 그 차이점에 집중할 것이며, LLVM 링커와 같은 오픈소스 도구와 프로젝트 재사용도 가능함을 의미한다. 다시 말해서 단순히 레거시 기술을 현대식 Clang으로 옮겨가는 수준이 아니라, Clang을 수정해 우리의 이점을 더한다는 것이다.

 

The bonuses for you are huge: compatibility with many more tools, making it easier to use (for example) other debuggers or analyse core dumps, new technology improving the effectiveness of our linker, and more. You get the high value language and integration technology – the things that make C++Builder C++Builder – with the overall product much more robust, compatible, and modern.

여러분이 누릴 수 있는 혜택은 더욱 커질 것이다. 더 많은 도구와의 호환성, 링커의 효율성을 개선한 새로운 기술, 코어 덤프 분석이나 다른 디버거 사용이 더 쉬워질 수 있다. C++빌더의 뛰어난 가치의 언어와 통합 기술은 물론, 전체적으로 제품이 훨씬 더 강력해지고 호환성은 뛰어나며 최신 버전으로 업그레이드될 것이다.

 

런타임과 STL

A C++ toolchain’s runtime has three layers:

C++도구 체인의 런타임은 다음 세 개의 레이어로 구성되어 있다:

1. C 런타임 - 기본 C 언어 스타일 메소드, C스타일 파일 IO 등을 제공한다.
2. C++ 런타임 - 예외 처리 등 핵심적인 C++ 기능을 제공한다.
3. STL - 위의 두 가지를 모두 사용한다.

Historically we’ve had our own C and C++ runtime. We also provide more than the standard methods for a Windows C runtime, including some POSIX methods. However, these days a C runtime is a standard Windows component built-in to the operating system, so we are investigating using the UCRT – universal C runtime – and adding our custom or extended methods on top of it.

지금까지는 자체 C, C++ 런타임을 사용했다. 그리고 일부 POSIX 메소드를 포함한 윈도우 C 런타임용 표준 메소드보다 더 많이 제공해왔다. 하지만 최근 C 런타임은 운영체제에 내장되어 있는 표준 윈도우 컴포넌트여서, UCRT (범용 C 런타임)를 사용하고 그 위에 사용자 지정 또는 확장 메소드를 추가하는 방향을 모색하고 있다.

Our C++ runtime will most likely remain the same, though we are investigating some options in some areas.

우리의 C++ 런타임은 대체적으로 동일하게 유지될 가능성이 높지만, 일부분에 적용할 몇 가지 옵션을 살펴보고 있다.

Work on the Clang upgrade is in progress today, and has been for some time. Some areas are still in flux, and that includes the STL that we’ll use. 

Clang 업그레이드는 이미 시작되어 계속 진행중이다. 우리가 사용할 STL 등 일부분은 지속 변경 작업중이다.

 

출시 계획

The upgrade is planned initially for Windows 64-bit. This is to target the platform many developers are moving to (64-bit), and to do one Windows platform at a time (tight scope lets us focus on doing one thing well). We plan to move the same technology and approach to Windows 32-bit in a future release.

업그레이드는 우선 윈도우 64비트용으로 계획하고 있다. 이는 많은 개발자들이 옮겨가고 있는 플랫폼인 64비트를 수용하고, 한 번에 하나의 윈도우 플랫폼에 집중하기 위해 내린 결정이다 (범위가 좁으면 한 가지를 잘 완성하는 것에 집중할 수 있기 때문이다). 향후 릴리스에서는 동일한 기술과 접근 방식을 윈도우 32비트에도 적용할 계획이다.

What about other platforms? Moving to other platforms with an older version of Clang, version 5, was not an ideal situation. But moving using a modern, recent version of Clang is much more ideal, and once we have completed the upgrade for Windows we will have the ability to roll out the new compiler to other platforms.

다른 플랫폼 지원은 어떨까? 이전 버전의 Clang, 버전 5를 사용하는 다른 플랫폼으로 이전하는 것은 이상적인 상황이 아니었다. 최신 버전의 Clang을 사용해 이전하는 것이 훨씬 더 바람직하며, 윈도우용 업그레이드를 완료하면, 다른 플랫폼에 새 컴파일러를 배포할 수 있게 될 것이다.

 

지속적인 최신 상태 유지

As well as rolling out to Windows 32-bit and other platforms over the next releases, we also plan to keep Clang up to date. We intend to continually stay up to date and ship a new version of Clang even with every point release.

그 이후 릴리스에서는 윈도우 32비트와 그 외 플랫폼으로 배포하는 것 뿐만 아니라, Clang을 최신 버전으로 유지할 계획을 하고 있다. 모든 포인트 릴리스에서도 지속해서 최신 버전을 유지해 새로운 버전의 Clang을 출시할 계획이다.

Clang and LLVM move fast, and after we release this upgrade, we plan to continually integrate changes from the remote repositories into ours. Unlike Delphi, C++Builder does not try to retain ABI compatibility across point releases, ie we require that you rebuild C++ object files and binaries that you link in each point release (note that Delphi-generated C++-style object files and libraries are stable, it’s just anything created by a C++ compiler.) This gives us freedom to move fast, and in this case moving fast means staying up to date.

Clang과 LLVM은 빠른 속도로 움직이고 있으며, 우리가 업그레이드를 출시한 후에도 원격 저장소의 변경 사항을 우리 저장소에도 계속해서 통합할 계획이다. 델파이와는 달리 C++빌더는 포인트 릴리스 간에 ABI 호환성을 유지하고자 하지는 않는다. 예를 들어, 각 포인트 릴리스에서 링크하는 C++ 개체 파일과 바이너리를 다시 빌드를 할 수도 있다 (참고로 델파이에서 생성된 C++ 스타일 오브젝트 파일과 바이너리는 안정적이며, C++ 컴파일러로 생성한 모든 것들이 그렇다). 이러한 접근 방식을 통해 우리는 신속하게 이동할 수 있으며, 여기에서 빠르게 이동한다는 것은 곧 최신 상태로 유지한다는 뜻이다.

We plan to ship a new version of Clang every single release.

매번 릴리스마다 Clang 새 버전을 지원하는 것이 계획이다.

You will always be using the close-to-leading-edge version of the compiler and toolchain.

이를 통해 여러분은 늘 최첨단에 가까운 컴파일러와 도구 체인을 사용하게 될 것이다.

 

Clang 업그레이드 내용 정리

We’re upgrading Clang to version 15. Rather than bringing legacy tech forward, we’re using platform-standard formats like COFF and PDB; that includes MS-style mangling not Itanium, we’re all-in on ‘What’s normal on Windows is what is normal for C++Builder.’ This lets us use tools like the LLVM linker, replacing ilink completely. This may also let you use other tools, like profilers, which are written to understand formats like PDB. We’re also revising our runtimes; and using a new STL which is much more reliable. Approximate language level support will be C++20 and a lot of C++23. We’re releasing for Win64 first, with Win32 and others to follow. Compatibility with our previous RTLs and toolchains is key. And finally, we’re continually upgrading so you will be able to use a toolchain (compiler, STL, and more) that’s close to the leading edge, modern and high quality, with every version and upgrade of C++Builder.

Clang 버전 15로 업그레이드는 진행중이다. 기존 기술을 그대로 가져오는  대신 COFF와 PDB와 같은 플랫폼 표준 형식을 사용하고 있으며, 여기에는 Itanium이 아닌 MS 스타일의 mangling을 사용해 '윈도우에서 일반적인 것이 곧 C++빌더에서도 일반적인 것'을 목표로 올인하고 있다. 이를 통해 LLVM 링커와 같은 도구를 사용할 수 있으며, ilink를 완전히 대체하게 될 것이다. 또한 PDB와 같은 포맷을 이해할 수 있도록 작성된 프로파일러 등의 다른 도구들을 활용할 수도 있다. 또한 런타임을 수정하며, 훨씬 더 안정적인 새로운 STL을 활용한다. 언어는 C++20과 상당수의 C++23을 지원하는 수준이 될 것이다. 우선 Win64용으로 먼저 출시될 예정이며, Win32와 기타 플랫폼들은 이후에 이어 출시할 계획이다. 이전 RTL과 도구 체인과의 호환성이 가장 핵심이다. 결론적으로, 지속적인 업그레이드를 통해 C++빌더의 모든 버전과 업그레이드로 최첨단에 가까운 현대화된 고품질의 도구체인(컴파일러, STL 등등)을 사용할 수 있게 될 것이다.

This is a hugely exciting move for C++Builder, a solid foundation and approach. Internally, it’s referred to as ‘doing it right’, and it is: we are doing C++Builder right. We hope you’re as excited by these plans and the approach as we are!

이는 탄탄한 기반과 접근 방식을 갖춘 C++빌더에 있어 매우 흥미로운 움직임이다. 내부적으로 '제대로 하기'를 모토로 하고 있으며, 실제로도 C++빌더를 제대로 진행하고 있다. 우리만큼이나 여러분도 우리의 계획과 접근 방식에 많은 기대를 해주길 바란다!

 

미리보기

This work is in-progress, but here are some preview screenshots. We’ve been working on adding the C++Builder language extensions: properties, declspecs, Delphi-style classes and inheritance, closures, and so forth.

현재 진행중이지만, 몇 가지 미리보기 스크린샷을 이 페이지에 오픈한다. C++빌더 언어 확장 기능을 추가하는 작업을 진행중인데 여기에는 속성, declspecs, 델파이 스타일 클래스와 상속, 클로저 등등이 포함된다.

We should caution that this work is early: we have an internal stage we call the ‘one-button app’, which is where you can create and run a VCL application with a button, and click it: at this point you have all the key elements working. We have not got to that stage yet: these screenshots are of command-line applications. However, they are apps using our C++Builder extensions, built with COFF and PDB, and linking against the Delphi runtime. As time progresses we’ll share more, eventually getting to a point where we seek beta testing and feedback!

이 작업이 아직은 초기 단계라는 점을 분명히 해두고 싶다. '원버튼 앱'이라고 부르는 내부 단계가 있는데, 하나의 버튼으로 VCL 애플리케이션을 만들고 실행할 수 있으며, 이 버튼을 클릭하면 모든 핵심 요소가 작동하는 것이다. 다만 아직까지는 그 단계까지 이르지 못했다. 다음의 스크린샷은 커맨드라인 애플리케이션의 화면이다. COFF와 PDB로 구축한 C++빌더 확장을 사용하고, 델파이 런타임에 연결되는 프로그램이다. 시간이 지나면서 더 많은 것들을 공유할 예정이다. 베타 테스트와 피드백을 요청하게 되는 시점에 이르기까지 계속해서 업데이트를 공유하도록 하겠다.

 

Here’s a property test that’s compiled with the our in-progress Clang upgrade:

다음은 현재 진행중인 Clang 업그레이드로 컴파일한 프로퍼티 테스트이다:

Note that it’s generating a PDB file.

참고로 PDB 파일을 생성한다.

 

Here’s another screenshot, this time of debugging inside the IDE:

다음은 IDE 내부에서 디버깅하는 화면이다:

 

Here you can see some key C++Builder-isms being tested: __classid (returning the metaclass), published properties, and Delphi-style classes.

테스트 중인 주요 C++빌더 기능을 살펴볼 수 있다. _classid (메타클래스 반환), 게시된 프로퍼티, 델파이 스타일 클래스를 각각 볼 수 있다.

 

At the bottom in the Events view, you can see the version of LLDB we’re using, version 15. And above that, you can see an internal build of our IDE debugging this C++ code, compiled with a modern Clang, using modern LLDB, in source code using our extensions, with debug info loaded from PDB format.

이벤트(Events) 화면 하단에서, 사용중인 LLDB 버전(버전 15)을 확인할 수 있다. 그 위에는 PDB 형식에서 불러온 디버그 정보를 확인할 수 있으며, 확장 기능을 사용중인 소스 코드에서 최신 LLDB를 사용하는 최신 Clang으로 컴파일한 C++ 코드를 디버깅하는 IDE의 내부 빌드 모습도 볼 수 있다.

 

비주얼 어시스트 통합

The Clang upgrade on its own would be amazing news for C++Builder, but there’s more.

Clang 업그레이드 만으로도 C++빌더에 있어 멋진 뉴스이지만, 더 흥미로운 소식들이 있다.

Several years ago, Idera acquired Visual Assist, a very well-known productivity tool for C++ and C# developers. It provides code completions, refactorings, navigation, and many more features, and is billed as filling in the gaps in Visual Studio: it is very, very fair to say that Visual Assist provides a better C++ experience than using Visual C++. It would be natural, therefore, for us to use it to fill in the gaps in C++Builder too.

몇 년 전, 아이데라(Idera)는 C++, C# 개발자들에게 잘 알려진 생산성 도구인 비주얼 어시스트(Visual Assist)를 인수했다. 코드 완성, 리팩토링, 탐색 등 다양한 기능을 제공하고, 비주얼 스튜디오의 공백을 메울 수 있도록 설계되어 있으며, Visual C++보다 훨씬 더 나은 C++ 경험을 제공한다고 말해도 과언이 아니다. 때문에 C++빌더의 부족한 부분을 메우기 위해 비주얼 어시스트를 사용하는 것은 당연한 일이다.

Visual Assist is a vast product, but there are some key areas that we would like to bring to C++Builder: assisting code completion, adding refactorings, and providing navigation around your code, such as finding references. There are multiple steps for this: Visual Assist has support for C++Builder’s language extensions for (the build that ships to Visual Studio customers does not have this turned on) and we are now working on integrating key VA features. We’re currently working on integration into the RAD Studio IDE itself.

비주얼 어시스트는 방대한 제품이지만, C++빌더에 적용하고자 하는 몇 가지 핵심 영역이 있다. 그 중에는 코드 완성 지원, 리팩토링 추가, 참조 검색과 같은 코드 탐색 기능 제공 등이 있다. 이 프로세스에는 비주얼 어시스트에서 C++빌더 언어 확장을 지원(비주얼 스튜디오 고객들에게 제공되는 빌드에는 이 지원이 활성화되어 있지 않음)하는 작업과 주요 VA 기능을 통합하는 작업 등 여러 단계가 있다. 현재는 RAD스튜디오 IDE 자체에 통합하는 작업을 진행하고 있다.

We plan a rollout that brings the highest value features to you first. The initial release will likely contain just one or two refactorings and navigation – plus, of course, code completion. Over each subsequent release, we’ll integrate more.

가장 가치있는 기능을 우선적으로 제공할 계획이다. 초기 릴리스에서는 한 두가지 정도의 리팩토링과 탐색 기능 그리고 추가로 코드 완성 정도까지 제공될 것이다. 이후 릴리스마다 더 많은 기능을 통합해나갈 계획이다.

 

미리보기

C++빌더에서의 비주얼 어시스트! 전체 크기의 GIF 파일 확인하기

 

In this screen recording, you can see our internal IDE build using our first Visual Assist feature, Find Symbol. This lets you search your codebase, including code like VCL headers outside of your code, and quickly navigate to a symbol’s location. This is a good first feature, because it allows us to test our support for C++ extensions like properties (which are symbols that should show up in this dialog.)

위 화면에서, 첫 번째 비주얼 어시스트의 기능인 심볼 찾기(Find Symbol)를 사용하는 내부 IDE 빌드를 확인할 수 있다. 이 기능을 사용하면, 코드 외부의 VCL 헤더와 같은 코드를 포함해 코드베이스를 검색할 수 있으며, 심볼 위치로 빠르게 이동할 수도 있다. 대화상자에 표시되어야 하는 심볼인 프로퍼티와 같은 C++ 확장 기능 지원에 대한 테스트를 할 수 있어 굉장히 좋은 기능이며, 우선적으로 제공될 것이다.

Note how when typing ‘grid row’ it’s searching through the FMX headers too, and out of 172 matches it selects TCustomGrid.Row as the most likely. When searching only in the current project group, it chooses Grid.Rows. Searching through all 226,236 FireMonkey and local project symbols combined to find the first result takes only 0.7 seconds.

'그리드 행(grid row)'을 입력하면, FMX 헤더까지 모두 확인해 172개의 일치되는 항목 중 가장 가능성이 높은 일치 항목으로 TCustomGrid.Row를 선택한다는 점을 눈여겨볼만 하다. 현재 프로젝트 그룹에서만 검색한다면, Grid.Rows를 선택하게 된다. 전체 226, 236개에 달하는 파이어몽키와 로컬 프로젝트 심볼 전체를 검색해서 최초의 결과를 얻는 데까지 단 0.7초밖에 걸리지 않는다.

 

 

최신 Clang, COFF, 그리고 비주얼 어시스트?!

Clang 업그레이드

매 업데이트 때마다 제공되는 새로운 최신 Clang

완전히 새로운 링커

새로운 STL

COF와 PDB 그리고 이로 인한 상호 운용성

새로운 코드 완성

비주얼 어시스트 C++ 탐색과 리팩토링

이 소식을 전할 수 있게 되어 얼마나 기쁘고, 또 기대되는지 아무리 강조해도 지나치지가 않다. C++빌더 개발자로서 정말 신이 난다!

 

Disclaimer: All new features and improvements discussed in this blog post for future versions of RAD Studio are not committed until completed, and GA released.

고지 사항: 해당 글에서 논의된 향후 RAD스튜디오 버전의 모든 새로운 기능 및 개선 사항들은 완료되어 정식 버전이 출시될 때까지는 확정적인 것이 아님을 밝힌다.