10 万行の C++ コードをどのように C++14 標準に (その後 C++17 に) 変換したか

少し前（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で書かれた
• Сервер インタラクションシステム

私たちは、できる限り異なる OS に対して同じコードを記述するようにしています。サーバーのコード ベースは 99% 共通で、クライアントのコード ベースは約 95% です。 1C:Enterprise テクノロジー プラットフォームは主に C++ で記述されており、コードのおおよその特徴は次のとおりです。

• 10万行のC++コード、
• 14ファイル、
• 60万クラス、
• 50 万通りの方法。

そして、これらすべてを C++14 に翻訳する必要がありました。今日は、私たちがそれをどのように実行したか、そしてその過程で何に遭遇したかをお話しします。

免責事項

以下に記載されている、さまざまなライブラリの標準クラスの実装の遅い/速い動作、メモリ消費が少ない (または少ない) ことはすべて、1 つのことを意味します。これは私たちにとって真実です。標準的な実装がニーズに最も適している可能性は十分にあります。私たちは、まず自分たちのタスクから始めました。つまり、クライアントの典型的なデータを取得し、それに対して典型的なシナリオを実行し、パフォーマンスや消費されたメモリの量などを調べ、私たちとクライアントがその結果に満足しているかどうかを分析しました。そして彼らはそれに応じて行動した。

私たちが持っていたもの

当初、1C:Enterprise 8 プラットフォームのコードは Microsoft Visual Studio で作成しました。プロジェクトは 2000 年代初頭に始まり、バージョンは 1 つしかありませんでした。 Windows当然ながら、その後コードは急速に進化し、多くのメカニズムが完全に書き直されました。しかし、コードは1998年の標準に準拠して記述されており、例えば、コンパイルを確実に成功させるために、以下のように右山括弧をスペースで区切っていました。

vector<vector<int> > IntV;

2006年、プラットフォームバージョン8.1のリリースに伴い、サポートを開始しました。 Linux サードパーティ製の標準ライブラリに切り替えた STLポート切り替えの理由の一つは、幅の広い文字列を扱うためでした。私たちのコードでは、wchar_t 型に基づいた std::wstring を全体を通して使用しています。そのサイズは Windows 2バイト、そして Linux デフォルトは 4 バイトです。これにより、クライアントとサーバー間のバイナリ プロトコルやさまざまな永続データに互換性の問題が生じました。gcc オプションを使用すると、コンパイル時に wchar_t のサイズを 2 バイトに強制できますが、コンパイラの標準ライブラリは glibc を使用するため、使用できなくなります。glibc は 4 バイトの wchar_t 用にコンパイルされているからです。その他の理由としては、標準クラスのより高品質な実装、ハッシュ テーブルのサポート、さらにはコンテナ移動セマンティクスのエミュレーション（これは積極的に使用しました）などがありました。そして最後に、文字列のパフォーマンスも重要な要素でした。当社では、ソフトウェアで文字列操作を多用しており、これは当社にとって非常に重要であるため、独自の文字列クラスを用意しました。

私たちの文字列は、2000 年代初頭に提案された文字列最適化のアイデアに基づいています。 アンドレイ・アレクサンドレスク。その後、アレクサンドルスクがFacebookで働いていたとき、彼は同様の原理で動作する文字列がFacebookエンジンで使用されていることを示唆しました（ライブラリを参照）。 愚行).

当社の製品ラインでは、主に 2 つの最適化テクノロジを採用しています。

1. 短い値の場合、文字列オブジェクト自体の内部バッファが使用されます (追加のメモリ割り当ては必要ありません)。
2. その他すべてには、メカニクスが使用されます。 コピーオンライト。文字列値は 1 か所に保存され、割り当て/変更時に参照カウンターが使用されます。

プラットフォームのコンパイルを高速化するために、STLPort 実装からストリーム実装 (使用しなかった) を削除しました。これにより、コンパイル速度が約 20% 向上しました。その後、制限された方法で使用しなければなりませんでした。 ブースト。 Boost は、特にサービス API (ログ記録など) でストリームを多用するため、ストリームを使用しないように変更する必要がありました。その結果、Boost の新しいバージョンへのアップグレードが困難になりました。

第三の方法

C++14 標準に移行する際、次のオプションを検討しました。

1. 変更された STLPort を C++14 標準にアップグレードします。 STLPort のサポートは 2010 年に廃止されたため、このオプションは非常に困難であり、すべてのコードを自分で再構築する必要があったでしょう。
2. C++14 と互換性のある別の STL 実装に切り替えます。この実装が以下の条件を満たしていることが強く望まれます。 Windows и Linux.
3. 各 OS 用にコンパイルする場合は、対応するコンパイラに組み込まれているライブラリを使用します。

最初の選択肢は、作業量が多すぎるためすぐに却下されました。

私たちはしばらくの間、2 番目の選択肢について考えました。候補として検討された libc ++しかし、当時彼は Windowslibc++を移植するには Windowsそうすれば、多くの作業を行う必要が出てきます。たとえば、libc++ が使用していたスレッド、スレッド同期、アトミック性に関連するすべてを自分たちで記述する必要があります。 POSIX API.

そして私たちは3番目の道を選びました。

Переход

そのため、STLPort の使用を対応するコンパイラ (Visual Studio 2015 など) のライブラリに置き換える必要がありました。 Windows、gcc 7 用 Linuxclang 8 用 macOS).

幸いなことに、私たちのコードはほとんどガイドラインに従って書かれており、巧妙なトリックは使用していなかったため、新しいライブラリへの移行は比較的スムーズに進みました。ソースファイル内の型、クラス、名前空間、インクルードの名前を置き換えるスクリプトを使用しました。移行は14,000個のソースファイルのうち10,000個に影響を与えました。wchar_tはchar16_tに置き換えられました。char16_tはすべてのオペレーティングシステムで2バイトしか占有せず、コードの互換性に影響を与えないため、wchar_tの使用を中止することにしました。 Windows и Linux.

小さな冒険がいくつかありました。たとえば、STLPort では、反復子を要素へのポインターに暗黙的にキャストすることができ、コード内のいくつかの場所でこれが使用されました。新しいライブラリではこれを行うことができなくなり、これらの場所を手動で分析して書き直す必要がありました。

したがって、コードの移行は完了し、コードはすべての OS 用にコンパイルされます。テストの時間です。

移行後のテストでは、古いバージョンのコードと比較して、パフォーマンスの低下 (場所によっては最大 20 ～ 30%) とメモリ消費の増加 (最大 10 ～ 15%) が見られました。これは特に、標準文字列の最適でない操作が原因でした。そのため、私たちは再び、わずかに修正した独自のラインを使用する必要がありました。

組み込みライブラリ内のコンテナの実装の興味深い機能も明らかになりました。組み込みライブラリの空の (要素なしの) std::map と std::set がメモリを割り当てます。また、実装機能により、コードのいくつかの場所では、このタイプの空のコンテナーがかなり多く作成されます。標準のメモリ コンテナーは、1 つのルート要素に対して少し割り当てますが、私たちにとってはこれが重要であることが判明しました。多くのシナリオで、パフォーマンスが著しく低下し、メモリ消費量が増加しました (STLPort と比較して)。そこで、コード内の組み込みライブラリのこれら 2 種類のコンテナーを、この機能を持たない Boost の実装に置き換え、速度低下とメモリ消費量の増加の問題を解決しました。

大規模プロジェクトで大規模な変更を行った後によくあることですが、ソースコードの最初のイテレーションには問題がなかったわけではなく、特にデバッグイテレータのサポートに問題がありました。 Windows-実装。私たちは段階的に進め、2017年春（1C:Enterpriseのバージョン8.3.11）までに移行が完了しました。

結果

C++14 標準への切り替えには約 6 か月かかりました。ほとんどの場合、XNUMX 人の (ただし非常に優秀な) 開発者がプロ​​ジェクトに取り組み、最終段階で、UI、サーバー クラスター、開発および管理ツールなどの特定の領域を担当するチームの代表者が参加しました。

この移行により、最新バージョンの標準への移行作業が大幅に簡素化されました。したがって、バージョン1C:Enterprise 8.3.14（開発中、来年初めにリリース予定）はすでに標準に翻訳されています。 C++17.

移行後、開発者にはより多くの選択肢が与えられます。以前は、独自に修正した STL バージョンと 1 つの名前空間 std がありましたが、現在は名前空間 std に組み込みコンパイラ ライブラリの標準クラスがあり、名前空間 stdx にタスク用に最適化された文字列とコンテナーがあり、boost には最新バージョンの boost があります。そして開発者は、問題の解決に最適なクラスを使用します。

移動コンストラクタのネイティブ実装は開発にも役立ちます（移動コンストラクタ) をいくつかのクラスに提供します。クラスに移動コンストラクターがあり、このクラスがコンテナー内に配置されている場合、STL はコンテナー内の要素のコピーを最適化します (たとえば、コンテナーが拡張され、容量を変更する必要があり、メモリを再割り当てする必要がある場合など)。

軟膏の中を飛ぶ

おそらく、移住の最も不快な（しかし重大ではない）結果は、私たちが直面する量の増加である。 obj ファイル、すべての中間ファイルを含む完全なビルド結果が 60～70 GB を占めるようになりました。この動作は、生成されるサービス ファイルの量に対する重要性が薄れてきた最新の標準ライブラリの特殊性に関連しています。これはコンパイルされたアプリケーションの動作には影響しませんが、開発において多くの不便を引き起こし、特にコンパイル時間が長くなります。ビルド サーバーと開発者マシン上の空きディスク領域に対する要件も増加しています。当社の開発者は、プラットフォームの複数のバージョンを並行して作業しており、数百ギガバイトの中間ファイルによって作業に支障が生じることがあります。この問題は不快ではあるものの、重大なものではないため、当面は解決を延期します。その解決策の一つとして、私たちはテクノロジーを検討しています ユニティビルド (特に、Google は Chrome ブラウザの開発時にこれを使用します)。

出所： habr.com