D言語はC++17に対してどう優れているのか? (翻訳)
もうすぐC++20が出そうですね、その前に振り返りを兼ねて、Guillaume Piolat氏のHow does D improve on C++17?を翻訳しました。
—
How does D improve on C++17?
警告: この記事は独断的である
C++が進化をつづけ、C++17が登場する中、D言語はまだ妥当な選択肢だろうか? 私の考えはYesであり、強くそう思う。理由をここに述べる。
DUB
Dにはパッケージ管理がある。C++にはコミュニティ内で普及したものがない。 Dでは外部ライブラリの利用が何倍も楽。
No more プリプロセッサ
Dはプリプロセッサが不要。
No more ヘッダーファイル
たとえC++がmoduleを実装し、利用できるようになろうと、後方互換のためにヘッダーファイルは共存し続けるだろう。
(訳注: C++20ではついにmoduleが正式採用された、Piolat氏の指摘通り global module fragment のようなヘッダーを使う後方互換のための機能も入ったりした。)
No more 宣言順序
Dでは宣言順序が問題になることはない。前方宣言や並べ替えなど何も気にする必要はない。
より高速なコンパイル
C++にはコンパイル速度問題がある。例えば言語規格の原理上、プリプロセッサは最低でも3回は余計なソースコードの走査をしないといけない。
C++開発ではコンパイラを待つ膨大な時間を過ごすことができる。
デフォルト初期化
C++プログラムにおける未初期化の変数は些細な見つけにくいバグを作ることができる。Dではすべての変数はデフォルトで初期化され、もし高負荷な初期化を避けたければ、 = void による初期化を使える。
名前の競合バグが起こりえない
同じ識別子を含むモジュールをインポートしたときの名前の競合はコンパイルエラーになる。それゆえうっかり間違ったシンボルを使うことはできない。
No more 配列型からポインタへの暗黙の型変換
これがCとC++の長きにわたる問題である。
レンジ vs イテレータ
レンジはイテレータからみていくつもの 良い点 がある、基本的にイテレーションのためのより良いツールである。
(訳注: C++20でもついにレンジのライブラリが入った https://eel.is/c++draft/ranges)
劇的にシンプルになったムーブとコピーセマンティクス
Dは構造体とクラスがbit copyによってコピー可能と仮定している。さらにいくつか内部ポインタについて制限もあるが、全体的によりシンプルである。
(訳注: ポインタの制限についてはこの辺も参照 https://dlang.org/spec/garbage.html#pointers_and_gc)
unittest ブロック
ビルトインの単体テストはテストを書く障壁を下げる。
ドキュメンテーションコメント
同じくビルトインのドキュメンテーションコメントはドキュメンテーションを書く障壁を下げてくれる。
DのSTLは可読性が高い
Phobos のソースコードは簡単でたびたび勉強になる。
よりシンプルなオブジェクトモデル
C++は多重継承があり複雑なオブジェクトモデルとなる。
alias this を使えば多重継承は絶対に一度も必要にならない。
(訳注: alias this に関しては同氏の解説がくわしい http://p0nce.github.io/d-idioms/#Extend-a-struct-with-alias-this)
合理化されたオペレータオーバーロード
カスタムの数値型をつくるときに必要なオペレータオーバーロードが圧倒的に少ない。
(訳注: C++20では関係演算子に限れば operator<=> による合理的な定義ができる)
++pre と post++ インクリメントが修正された
詳細は こちら
(訳注: Dでは返り値を使わない場合、事後インクリメントがコンパイラにより事前に書き換えられる。オペレータオーバーロードも事前インクリメントだけ定義すれば事後は自動で定義される。)
GC
大半のプログラムでは、GCは生産性を改善してくれる。そうでないプログラムにとっても、 GCはそんなに悪くないし 回避することも可能である。
C++テンプレートの英雄はいらない
より簡単で強力なDのテンプレートによって あらゆる プログラマがメタプログラミングを日常的にできるようになる。 チームにいるかいないかのプログラマ1人に頼ることにはならない。
巨大な言語だが手に取れる
Dの学習は実際トリッキーだが、サブセットから始めることも可能だ。
—
悪いところ
バランスをとって、悪いところもあげよう (再度、独断的なので注意) :
