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で書かれています
• Сервер インタラクションシステム

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

• 10 万行の C++ コード、
• 14ファイル、
• 60万クラス、
• XNUMX万通りのメソッド。

そして、これらすべてを C++14 に変換する必要がありました。 今日は、これをどのように行ったか、そしてその過程で何が起こったかについて説明します。

免責事項

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

私たちが持っていたもの

最初に、Microsoft Visual Studio で 1C:Enterprise 8 プラットフォームのコードを作成しました。 このプロジェクトは 2000 年代初頭に始まり、Windows のみのバージョンがありました。 当然のことながら、それ以来コードは積極的に開発され、多くのメカニズムが完全に書き直されました。 ただし、コードは 1998 年の標準に従って記述されており、たとえば、次のようにコンパイルが成功するように、右山括弧はスペースで区切られています。

vector<vector<int> > IntV;

2006 年、プラットフォーム バージョン 8.1 のリリースに伴い、Linux のサポートを開始し、サードパーティの標準ライブラリに切り替えました。 STLポート。 移行の理由の 2 つは、幅の広いラインで作業するためでした。 私たちのコードでは、wchar_t 型に基づく std::wstring を全体的に使用します。 Windows のサイズは 4 バイト、Linux のデフォルトは 2 バイトです。 これにより、クライアントとサーバーの間のバイナリ プロトコルやさまざまな永続データに互換性がなくなりました。 gcc オプションを使用すると、コンパイル中の wchar_t のサイズも 4 バイトに指定できますが、その場合、コンパイラからの標準ライブラリの使用を忘れることができます。 glibc を使用し、XNUMX バイトの wchar_t 用にコンパイルされます。 その他の理由としては、標準クラスの実装が改善されたこと、ハッシュ テーブルのサポート、さらにはコンテナ内での移動のセマンティクスのエミュレーションが積極的に使用されたことが挙げられます。 そしてもう一つの理由は、彼らが最後に言うように、弦のパフォーマンスでした。 私たちは文字列用の独自のクラスを持っていました。 当社のソフトウェアの特性により、文字列操作は非常に広く使用されており、これは当社にとって非常に重要です。

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

私たちの製品ラインでは、次の XNUMX つの主要な最適化テクノロジーが使用されました。

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

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

第三の方法

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

1. 変更した STLPort を C++14 標準にアップグレードします。 この選択肢は非常に難しいので... STLPort のサポートは 2010 年に廃止されたため、すべてのコードを自分たちで構築する必要がありました。
2. C++14 と互換性のある別の STL 実装に移行します。 この実装は Windows と Linux 用であることが非常に望ましいです。
3. OSごとにコンパイルする場合は、対応するコンパイラに組み込まれているライブラリを使用してください。

最初のオプションは、作業が多すぎるため完全に拒否されました。

私たちはしばらくの間、XNUMX 番目のオプションについて考えました。 候補として考えられる libc ++、しかし当時はWindowsでは動作しませんでした。 libc++ を Windows に移植するには、多くの作業を行う必要があります。たとえば、libc++ はこれらの領域で使用されるため、スレッド、スレッド同期、アトミック性に関係するすべてを自分で作成する必要があります。 POSIX API.

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

Переход

そのため、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 がメモリを割り当てます。 また、実装機能により、コード内のいくつかの場所で、このタイプの空のコンテナが大量に作成されます。 標準メモリ コンテナは XNUMX つのルート要素に対して少し割り当てられますが、私たちにとってこれは重要であることが判明しました。多くのシナリオで、パフォーマンスが大幅に低下し、メモリ消費量が増加しました (STLPort と比較して)。 したがって、私たちのコードでは、組み込みライブラリのこれら XNUMX 種類のコンテナを Boost の実装に置き換えました。これらのコンテナにはこの機能がありませんでした。これにより、速度低下とメモリ消費量の増加の問題が解決されました。

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

結果

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

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

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

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

軟膏の中を飛ぶ

おそらく、移行の最も不快な (ただし重大ではない) 結果は、ボリュームの増加に直面することです。 objファイルそして、すべての中間ファイルを含むビルドの完全な結果は 60 ～ 70 GB を消費し始めました。 この動作は、生成されるサービス ファイルのサイズがそれほど重要ではなくなっている、最新の標準ライブラリの特性によるものです。 これはコンパイルされたアプリケーションの動作には影響しませんが、開発中に多くの不都合が生じ、特にコンパイル時間が増加します。 ビルド サーバーと開発者マシン上の空きディスク領域の要件も増加しています。 当社の開発者はプラットフォームの複数のバージョンを並行して開発しており、数百ギガバイトの中間ファイルによって作業が困難になることがあります。 この問題は不快ではありますが、重大ではないため、今のところ解決を延期しています。 それを解決する選択肢の一つとしてテクノロジーを検討しています ユニティビルド (特に、Google は Chrome ブラウザの開発時にこれを使用します)。

出所： habr.com