RAD 3월 31일에 포스트됨 공유하기 3월 31일에 포스트됨 원문제목: What’s Coming for C++Builder: An Amazing Preview 원문: https://blogs.embarcadero.com/whats-coming-for-cbuilder-an-amazing-preview/ 작성자: David Millington (2023.3) (2023년 9월 옮긴이 업데이트: 이 글에 정리된 내용을 이 데모 비디오를 통해 직접 볼 수 있습니다) 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: 이와 같은 문제 해소를 위해 우리는 두 가지 부분에 집중하고 있다: Clang 업그레이드 - 단순히 Clang을 '업그레이드'하는 것이 아니라 '제대로 하기'라는 매우 다른 접근 방식을 취하고 있다. VA(비주얼 어시스트, Visual Assist)의 주요 기능을 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을 기반으로 한다. Clang을 확장하는 작업은 우리의 언어 확장을 통해 처리한다. 이 언어 확장은 델파이와 상호 운용을 목적으로 한다. 몰랐을 수 있겠지만, 델파이와 C++ 두 언어는 같은 애플리케이션 안에 컴파일되어 들어갈 수 있다. 심지어 델파이에서 선언된 클래스를 C++에서 상속받아서 새 클래스를 만들 수도 있다. C++는 델파이에서 구현된 코드를 사용하고 참조할 수 있다. 번역된 헤더(들)을 통하거나 프로퍼티 등 델파이 방식을 사용하면 된다. In 2018, we upgraded to Clang version 5, which provided C++17 support. 2018년, 우리는 Clang 버전 5로 업그레이드하여, C++17을 지원했다. 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. 하지만 이번 업그레이드는 예전 업그레이드 (3.3에서 5로 올렸던 2018년 업그레이드)와는 여러 면에서 다르다. 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과 파이어몽키 프레임워크 사용 등은 매우 요긴하다. 하지만 현재 우리가 구현한 Clang 확장에는 내장된 값이 없는 사용자 정의 요소들 몇 가지가 있고, 그것들로 인해 C++빌더를 전반적으로 크게 향상시키는 것과 무관한 유지 관리 비용이 생겼다. 우리는 레거시 관련 이유 때문에 윈도우 플랫폼 관행과는 방식이달랐다. 하지만, 만약 우리가 플랫폼 관행을 따른다면, 우리가 도구 체인(toolchain)을 관리하기 위한 커스터마이징 작업이 적어지고, 커스터마이징 도구도 적어지고, 호환성은 매우 크게 향상될 것이다. 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++이라는 가치가 매우 높은 언어 그리고 통합된 기술 (즉, C++빌더를 C++빌더답게 해주는 것들)을 제품 전반에 걸쳐서 더 견고하고, 호환성이 높고, 현대식인 환경을 가지게 된다. 런타임과 STL A C++ toolchain’s runtime has three layers: C++도구 체인의 런타임은 다음 세 개의 레이어로 구성되어 있다: C 런타임 - 이것은 기본 C 언어 스타일 메소드, C스타일 파일 IO 등을 제공한다. C++ 런타임 - 이것은 (예외 처리 등) C++의 핵심적인 마법을 제공한다. 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++ 런타임은 우리가 자체적으로 만들 것들이었다. 또한, 윈도우 C 런타임용 표준 메소드보다 더 많은 것들 (예: POSIX 메소드들)을 제공해왔다. 하지만, 요즘에는, 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. 다른 플랫폼 지원은 어떨까? 버전 5라는 이전 버전의 Clang을 가지고 다른 플랫폼들로 옮겨가는 것은 그다지 이상적이지 않았다. 하지만, 현대식인 최신 버전 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의 모든 새 버전을 담아서 제공하는 것을 계속할 것이다. 심지어 마이너 버전(point release)까지도 말이다. 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++빌더에서도 일반적인 것'에 올인하고 있다. 그 덕분에, 우리는 (ilink를 완전히 대체하는) LLVM 링커 등의 기술을 사용할 수 있게 된다. 여러분 역시 다른 도구들을 활용할 수 있게 된다. 예를 들어 PDB 포맷을 이해할 수 있도록 작성되어 있는 프로파일러 등을 쓸 수 있게 된다. 우리는 또한 런타임을 수정하고 있으며, 훨씬 더 안정적인 새 STL을 사용한다. 언어 수준 지원은 대략 C++20이 될 것이며, 상당수의 C++23도 지원할 것이다. 우선 Win64용으로 먼저 출시하고, 이어서 Win32와 기타 플랫폼들로 확대하여 출시할 계획이다. 우리의 이전 RTL 및 도구 체인과의 호환성이 핵심이다. 그리고 마지막으로, 업그레이드하기를 지속하기때문에, 여러분은 최첨단에 가깝고, 현대식이고, 품질이 놓은 도구체인(컴파일러, STL 등등)을 C++빌더의 모든 버전과 업그레이드를 통해 사용할 수 있게 될 것이다. 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++빌더 언어 확장에 추가하고 있는 것들로는 프로퍼티(property), declspecs, 델파이 스타일 클래스(와 상속), 클로저(closure) 등등이 있다. 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 애플리케이션을 만들고 실행하는 것이다. 이 단계에 들어가면 모든 핵심 요소가 작동하는 상태가 되는 것이다. 아직은 그 단계에 가지 못했기때문에, 아래 스크린샷은 커맨드-라인(명령-줄, command-line) 애플리케이션의 화면이다. 하지만, 이 앱들은 C++빌더 확장을 사용하고 있고, COFF와 PDB를 사용해 구축되었다. 그리고 델파이 런타임을 대상으로 링크하고 있다. 시간이 지나면 더 많은 것들을 공유할 예정이다. 베타 테스트와 피드백을 요청하게 되는 시점에 이르기까지 계속해서 업데이트를 공유하도록 하겠다. 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++빌더다운 핵심 기능들이 테스트되고 있는 것을 볼 수 있다. 테스트 중인 주요 C++빌더 기능을 살펴볼 수 있다. _classid (메타클래스를 반환함), 퍼블리쉬된 프로퍼티(published property), 델파이 스타일 클래스를 각각 볼 수 있다. 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)을 확인할 수 있다. 그 위에서는 현대식 Clang으로 컴파일 한 C++ 코드를 내부용 IDE 버전 안에서 디버징하고 있는 것을 볼 수 있다. 최신 LLDB를 사용하고 있으며, 소스 코드 안에서는 우리의 언어 확장(extention)을 사용하고 있고, PDB 포맷으로부터 디버그 정보를 가져오고 있다. 비주얼 어시스트를 통합하기 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# 개발자들에게 잘 알려진 생산성 도구인 VA (비주얼 어시스트, 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 스튜디오 자체 안에 통합하는 작업을 진행하고 있다. 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.) 위 화면 녹화에는 내부용 IDE 버전을 볼 수 있다. 먼저, 처음으로 추가된 비주얼 어시스트의 기능인 심볼 찾기(Find Symbol)를 볼 수 있다. 이 기능을 사용하면, 코드 베이스를 검색할 수 있다. VCL 헤더와 같이 여러분의 코드 바깥에 있는 것들도 찾을 수 있고, 그 심볼이 있는 곳으로 빠르게 이동할 수 있다. 이것을 첫 기능으로 선택한 이유는 프로퍼티(property) 등의 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, 그리고 VA(비주얼 어시스트, Visual Assist)?! Clang 업그레이드하기 새 Clang 업데이트를 매 버전마다 제공 완전히 새로워진 링커 새 STL COF와 PDB, 그리고 이것들이 가져오는 상호 운용성 새 코드 완성 (Code Completion) 비주얼 어시스트 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스튜디오 버전의 모든 새로운 기능 및 개선 사항들은 완료되어 정식 버전이 출시될 때까지는 확정적인 것이 아님을 밝힌다. 인용하기 이 댓글 링크 다른 사이트에 공유하기 더 많은 공유 선택 사항
Kori 9월 17일에 포스트됨 공유하기 9월 17일에 포스트됨 (2023년 9월 옮긴이 업데이트: 이 글에 정리된 내용을 아래 데모 비디오에서 직접 볼 수 있습니다) 인용하기 이 댓글 링크 다른 사이트에 공유하기 더 많은 공유 선택 사항
Recommended Posts
이 토의에 참여하세요
지금 바로 의견을 남길 수 있습니다. 그리고 나서 가입해도 됩니다. 이미 회원이라면, 지금 로그인하고 본인 계정으로 의견을 남기세요.