천만 줄의 C++ 코드를 C++10 표준으로 변환한 다음 C++14로 변환한 방법

얼마 전(2016년 가을) 1C:Enterprise 기술 플랫폼의 다음 버전을 개발하는 동안 개발 팀 내에서 새로운 표준 지원에 대한 질문이 제기되었습니다. C ++ 14 우리 코드에서. 우리가 가정한 대로 새로운 표준으로의 전환을 통해 많은 것을 더 우아하고 간단하며 안정적으로 작성할 수 있으며 코드 지원 및 유지 관리가 단순화될 것입니다. 그리고 코드 기반의 규모와 우리 코드의 특정 기능이 아니라면 번역에는 특별한 것이 없는 것 같습니다.

모르는 분들을 위해 설명하자면, 1C:Enterprise는 크로스 플랫폼 비즈니스 애플리케이션의 신속한 개발과 다양한 OS 및 DBMS에서의 실행을 위한 런타임을 위한 환경입니다. 일반적으로 제품에는 다음이 포함됩니다.

• 애플리케이션 서버 클러스터, Windows 및 Linux에서 실행
• 클라이언트, http(s) 또는 자체 바이너리 프로토콜을 통해 서버와 작업하며 Windows, Linux, macOS에서 작동합니다.
• 웹 클라이언트, Chrome, Internet Explorer, Microsoft Edge, Firefox, Safari 브라우저에서 실행(JavaScript로 작성)
• 개발 환경(구성자), Windows, Linux, macOS에서 작동
• 관리 도구 Windows, Linux, macOS에서 실행되는 애플리케이션 서버
• 모바일 클라이언트, http(s)를 통해 서버에 연결, Android, iOS, Windows를 실행하는 모바일 장치에서 작동
• 모바일 플랫폼 — Android, iOS, Windows에서 실행되는 동기화 기능을 갖춘 오프라인 모바일 애플리케이션을 생성하기 위한 프레임워크
• 개발 환경 1C:엔터프라이즈 개발 도구, Java로 작성됨
• 서버 상호작용 시스템

우리는 가능한 한 서로 다른 운영 체제에 대해 동일한 코드를 작성하려고 노력합니다. 서버 코드 기반은 99% 공통이고 클라이언트 코드 기반은 약 95%입니다. 1C:Enterprise 기술 플랫폼은 주로 C++로 작성되었으며 대략적인 코드 특성은 다음과 같습니다.

• 천만 줄의 C++ 코드,
• 14개의 파일,
• 60만개 수업,
• XNUMX만 가지 방법.

그리고 이 모든 것들은 C++14로 번역되어야 했습니다. 오늘은 우리가 이를 어떻게 수행했는지, 그리고 그 과정에서 어떤 일을 겪었는지 알려드리겠습니다.

부인 성명

느린/빠른 작업, 다양한 라이브러리의 표준 클래스 구현으로 인한 대규모 메모리 소비에 대해 아래에 작성된 모든 내용은 한 가지 의미가 있습니다. 이는 미국에 해당됩니다. 표준 구현이 귀하의 작업에 가장 적합할 가능성이 높습니다. 우리는 자체 작업부터 시작했습니다. 고객에게 전형적인 데이터를 가져와 일반적인 시나리오를 실행하고 성능, 소비된 메모리 양 등을 살펴보고 우리와 고객이 그러한 결과에 만족하는지 분석했습니다. . 그리고 그들은 다음에 따라 행동했습니다.

우리가 가졌던 것

처음에는 Microsoft Visual Studio에서 1C:Enterprise 8 플랫폼용 코드를 작성했습니다. 이 프로젝트는 2000년대 초반에 시작되었으며 Windows 전용 버전이 있었습니다. 당연히 그 이후로 코드가 적극적으로 개발되었으며 많은 메커니즘이 완전히 다시 작성되었습니다. 그러나 코드는 1998 표준에 따라 작성되었으며 예를 들어 다음과 같이 컴파일이 성공할 수 있도록 오른쪽 꺾쇠 괄호를 공백으로 구분했습니다.

vector<vector<int> > IntV;

2006년 플랫폼 버전 8.1 출시와 함께 Linux 지원을 시작하고 타사 표준 라이브러리로 전환했습니다. STL포트. 전환 이유 중 하나는 넓은 선으로 작업하는 것이었습니다. 우리 코드에서는 전체적으로 wchar_t 유형을 기반으로 하는 std::wstring을 사용합니다. Windows에서는 크기가 2바이트이고 Linux에서는 기본값이 4바이트입니다. 이로 인해 클라이언트와 서버 간의 바이너리 프로토콜과 다양한 영구 데이터가 호환되지 않게 되었습니다. gcc 옵션을 사용하면 컴파일 중 wchar_t의 크기도 2바이트로 지정할 수 있지만 그러면 컴파일러에서 표준 라이브러리를 사용하는 것을 잊어버릴 수 있습니다. 이는 glibc를 사용하며 이는 4바이트 wchar_t용으로 컴파일됩니다. 다른 이유는 표준 클래스의 더 나은 구현, 해시 테이블 지원, 심지어 우리가 적극적으로 사용했던 컨테이너 내부 이동 의미의 에뮬레이션이었습니다. 그리고 그들이 마지막으로 말했듯이 또 하나의 이유는 현악기 연주였습니다. 우리는 문자열에 대한 우리만의 수업을 갖고 있었습니다. 왜냐면... 우리 소프트웨어의 특성으로 인해 문자열 작업은 매우 광범위하게 사용되며 이는 우리에게 매우 중요합니다.

우리의 문자열은 2000년대 초반에 표현된 문자열 최적화 아이디어를 기반으로 합니다. 안드레이 알렉산드레스쿠. 나중에 Alexandrescu가 Facebook에서 일할 때 그의 제안에 따라 유사한 원리로 작동하는 라인이 Facebook 엔진에 사용되었습니다(라이브러리 참조). 어리 석음).

우리 라인은 두 가지 주요 최적화 기술을 사용했습니다.

1. 짧은 값의 경우 문자열 개체 자체의 내부 버퍼가 사용됩니다(추가 메모리 할당이 필요하지 않음).
2. 다른 모든 경우에는 역학이 사용됩니다. 쓰기 시 복사. 문자열 값은 한 곳에 저장되며 할당/수정 중에 참조 카운터가 사용됩니다.

플랫폼 컴파일 속도를 높이기 위해 STLPort 변형(사용하지 않음)에서 스트림 구현을 제외하여 컴파일 속도가 약 20% 향상되었습니다. 그 후 우리는 제한적으로만 사용해야 했습니다. 상승. Boost는 특히 서비스 API(예: 로깅)에서 스트림을 많이 사용하므로 스트림 사용을 제거하기 위해 이를 수정해야 했습니다. 이로 인해 새로운 Boost 버전으로 마이그레이션하기가 어려워졌습니다.

제 3의 길

C++14 표준으로 전환할 때 우리는 다음 옵션을 고려했습니다.

1. 수정한 STLPort를 C++14 표준으로 업그레이드하세요. 옵션이 너무 어렵네요... STLPort에 대한 지원은 2010년에 중단되었으며 모든 코드를 직접 구축해야 했습니다.
2. C++14와 호환되는 다른 STL 구현으로 전환합니다. 이 구현은 Windows 및 Linux용으로 수행되는 것이 매우 바람직합니다.
3. OS별로 컴파일할 때는 해당 컴파일러에 내장된 라이브러리를 사용하세요.

첫 번째 옵션은 너무 많은 작업으로 인해 완전히 거부되었습니다.

우리는 한동안 두 번째 옵션에 대해 생각해 보았습니다. 후보로 고려됨 libc++, 그러나 당시 Windows에서는 작동하지 않았습니다. libc++를 Windows로 포팅하려면 많은 작업을 수행해야 합니다. 예를 들어 스레드, 스레드 동기화 및 원자성과 관련된 모든 것을 직접 작성해야 합니다. libc++는 이러한 영역에서 사용되기 때문입니다. POSIX API.

그리고 우리는 세 번째 방법을 선택했습니다.

전환

따라서 우리는 STLPort의 사용을 해당 컴파일러의 라이브러리(Windows용 Visual Studio 2015, Linux용 gcc 7, macOS용 clang 8)로 대체해야 했습니다.

다행스럽게도 우리 코드는 주로 지침에 따라 작성되었으며 모든 종류의 기발한 트릭을 사용하지 않았습니다. 따라서 소스의 유형, 클래스, 네임스페이스 및 포함 이름을 대체하는 스크립트의 도움으로 새 라이브러리로의 마이그레이션이 비교적 원활하게 진행되었습니다. 파일. 마이그레이션은 10개 중 000개의 소스 파일에 영향을 미쳤습니다. wchar_t는 char14_t로 대체되었습니다. 우리는 wchar_t의 사용을 포기하기로 결정했습니다. char000_t는 모든 OS에서 16바이트를 사용하며 Windows와 Linux 간의 코드 호환성을 손상시키지 않습니다.

몇 가지 작은 모험이 있었습니다. 예를 들어 STLPort에서 반복자는 암시적으로 요소에 대한 포인터로 캐스팅될 수 있으며 코드의 일부 위치에서는 이것이 사용되었습니다. 새 도서관에서는 더 이상 이를 수행할 수 없었으며 이러한 구절을 수동으로 분석하고 다시 작성해야 했습니다.

따라서 코드 마이그레이션이 완료되고 모든 운영 체제에 대해 코드가 컴파일됩니다. 이제 테스트를 할 시간입니다.

전환 후 테스트에서는 이전 버전의 코드에 비해 성능이 저하되고(일부 장소에서는 최대 20~30%) 메모리 소비가 증가(최대 10~15%)한 것으로 나타났습니다. 이는 특히 표준 문자열의 최적이 아닌 성능 때문이었습니다. 따라서 우리는 약간 수정된 자체 라인을 다시 사용해야 했습니다.

임베디드 라이브러리의 컨테이너 구현에 대한 흥미로운 기능도 공개되었습니다. 즉, 내장 라이브러리의 빈(요소 없음) std::map 및 std::set이 메모리를 할당한다는 것입니다. 그리고 구현 기능으로 인해 코드의 일부 위치에서 이러한 유형의 빈 컨테이너가 상당히 많이 생성됩니다. 표준 메모리 컨테이너는 하나의 루트 요소에 대해 약간 할당되지만 이는 우리에게 매우 중요한 것으로 나타났습니다. 여러 시나리오에서 성능이 크게 떨어지고 메모리 소비가 증가했습니다(STLPort에 비해). 따라서 우리 코드에서는 내장 라이브러리의 이러한 두 가지 유형의 컨테이너를 Boost의 구현으로 대체했습니다. 이러한 컨테이너에는 이 기능이 없었으며 이로 인해 속도 저하 및 메모리 소비 증가 문제가 해결되었습니다.

대규모 프로젝트에서 대규모 변경을 한 후에 흔히 발생하는 것처럼 소스 코드의 첫 번째 반복은 문제 없이 작동하지 않았으며 특히 Windows 구현에서 반복기 디버깅에 대한 지원이 유용했습니다. 우리는 단계적으로 발전하여 2017년 봄(버전 8.3.11 1C:Enterprise)까지 마이그레이션이 완료되었습니다.

결과

C++14 표준으로 전환하는 데 약 6개월이 걸렸습니다. 대부분의 경우 매우 우수한 자격을 갖춘 한 명의 개발자가 프로젝트에 참여했으며 최종 단계에서는 UI, 서버 클러스터, 개발 및 관리 도구 등 특정 영역을 담당하는 팀 대표가 합류했습니다.

전환으로 인해 최신 버전의 표준으로 마이그레이션하는 작업이 크게 단순화되었습니다. 따라서 버전 1C:Enterprise 8.3.14(개발 중, 내년 초 출시 예정)가 이미 표준으로 이전되었습니다. C++17.

마이그레이션 후에는 개발자에게 더 많은 옵션이 제공됩니다. 이전에 STL의 수정된 버전과 하나의 std 네임스페이스가 있었다면 이제 std 네임스페이스, stdx 네임스페이스에 내장 컴파일러 라이브러리의 표준 클래스가 있습니다. 최신 버전의 부스트. 그리고 개발자는 자신의 문제를 해결하는 데 가장 적합한 클래스를 사용합니다.

이동 생성자의 "네이티브" 구현은 개발에도 도움이 됩니다(이동 생성자) 여러 수업에 대해. 클래스에 이동 생성자가 있고 이 클래스가 컨테이너에 배치된 경우 STL은 컨테이너 내부의 요소 복사를 최적화합니다(예: 컨테이너가 확장되어 용량을 변경하고 메모리를 재할당해야 하는 경우).

옥에 티

아마도 마이그레이션으로 인해 가장 불쾌한(그러나 중요하지는 않은) 결과는 규모의 증가에 직면하게 된다는 것입니다. obj 파일, 모든 중간 파일이 포함된 빌드의 전체 결과는 60-70GB를 차지하기 시작했습니다. 이 동작은 생성된 서비스 파일의 크기가 덜 중요해진 최신 표준 라이브러리의 특성으로 인해 발생합니다. 이는 컴파일된 애플리케이션의 작동에 영향을 미치지 않지만 개발 시 많은 불편을 초래하며, 특히 컴파일 시간이 늘어납니다. 빌드 서버와 개발자 컴퓨터의 여유 디스크 공간에 대한 요구 사항도 증가하고 있습니다. 우리 개발자들은 여러 버전의 플랫폼을 동시에 작업하며 수백 기가바이트에 달하는 중간 파일로 인해 작업에 어려움을 겪는 경우가 있습니다. 문제는 불쾌하지만 치명적이지는 않으므로 현재로서는 해결 방법을 연기했습니다. 우리는 이를 해결하기 위한 대안 중 하나로 기술을 고려하고 있습니다. 유니티 빌드 (특히 구글에서는 크롬 브라우저를 개발할 때 사용합니다.)

출처 : habr.com