C++26のDIS投票が完了、海外エンジニア「もう複雑すぎる」
姉妹サイトの新着
海外の技術者向けサイトHacker Newsで、C++26規格のDIS(Draft International Standard、国際規格原案)投票が完了したという話題が盛り上がった。この投票は新機能「contracts」などを含む仕様をほぼ固める重要な手続きだが、スレでは本題そのものより「C++はもう複雑すぎる」という嘆きが先に広がった。元C++コンパイラ開発者が音を上げたという声や、有名な解説書の著者すら最新仕様を追えていないという話も出て、Rustを代替に挙げる声と、現場では今もC++とJavaが主流だと冷静に返す声が交錯した。
C++26のDIS投票結果について
出典: train-it.eu / 元記事はこちら
C++はおそらく史上最大かつ最も複雑な言語だ。自分はC++コンパイラの開発者だったが、それでも言語の変化についていくのが大変だった。一般のユーザーにどうやって追いつけというのか。
15年前からすでに複雑だった(テンプレートメタプログラミングとか)。今はどうなってるのか想像もつかない。
優れた組織は、使える機能を制限するスタイルガイドを用意している。
C++の有名な解説書シリーズの著者すら、『もう無理』と早々に諦めている。落とし穴や注意点、機能同士の厄介な相互作用のリストが長すぎるからだ。
今のC++はもう『フランケンシュタイン』としか言いようがない。互換性を保ちながら新機能を入れようとするのは本当に大変で、たぶん『正しいやり方』ではないんだと思う。
フランケンシュタインは科学者の名前だぞ。いろんなものの寄せ集めだったのは彼が作った『怪物』の方だ。
だからこそ世界は今、C++よりRustを好意的に見ている。
今回のcontracts設計は、セミコロンを使うGudstedt案と違って良い。PRE()とPOST()というマクロを使えば、C++26より前の環境では空にするだけで簡単に後方互換性を保てるからだ。contracts_assertは静的にもランタイムにもできて、コンパイラが判断してくれる。これは明示的なstatic/assertより優れていて、そっちは不要だったりコストが高かったりする。
Redditなどで、今回の件について政治色のない分かりやすい説明を探したが見つからなかった。ただ、david_chisnallによるcontractsへの良い批判記事は見つけた。
『DIS』って何の略?
DISはDraft International Standard(国際規格原案)の略で、正式な規格になる前にISOの各国代表が投票する、ほぼ最終版の草案のことだ。ちなみにLEWGはライブラリ進化ワーキンググループ。
Draft International Standardのことだ。今回の投票は、現行の提案を草案規格に格上げするためのものだった。
『Draft International Standard』の略だけど、ISOの手続きを知らないとそれ自体にはあまり意味がない。『AES』の代わりに『Advanced Encryption Standard』と書くようなもので、『文書』や『暗号』といった大まかな分類を示すだけで、それ以上の説明にはなっていない。
旧王はまだ健闘しているが、エージェント駆動の用途にはRustの方がやはり向いている。
めちゃくちゃだな。新規プロジェクトでC++をあえて選ぶ理由(強気の根拠)を誰か教えてくれ。
直さなければならないセキュリティ問題が永遠に尽きないから、委託の仕事が途切れない。パッシブインカムを得る一番簡単な方法の一つだよ。
『modulesを使っているC++ライブラリなんて見つからないよ』とあるが、実は意外と結構あって、有名なものもいくつか含まれている。
『答えは、できるだけ多くの機能を言語に追加することだった』とあるが、Javaが多機能な言語にシェアを奪われているのは良いことだ。Oracle管理下のJavaの歴史や、Rust・Go・C#がある今、JRE系の言語にはもう関わりたくない。
それは良いことだ。肥大化したJVM系の製品も減るということだから。
そんな話が通用するのはHacker Newsだけだ。現実の世界ではJavaとC++がどこにでもあって、Rustを使っている人なんていない。
『みんなが本当に求めている機能』というが、それは一体何なのか。委員会以外の『みんな』が合意していると決めつけていないか。個人的には『エディション』方式が良いと思う。過去の失敗に縛られずに、メモリ安全なC++の後継を作れるはずだ。
みんなが本当に求めているのは<meta>機能だ。
それはもうある。Rustという名前だ。
C++をやっているなら、機能を実装するのはC++委員会の責任ではないと知っているはずだ。
Cの問題点は、境界チェック、プリプロセッサの小技や_Genericを使ったジェネリックコード、より型安全な列挙型、sizeof計算なしのヒープ確保、自動的なリソース解放といった、C++がすでに代替手段を提供している部分だ。だからC++を最小限に使うのがいい。
細かい指摘で悪いが、『ossification(骨化)』はここでの使い方とは逆の意味だ。これは既存の構造や慣行がそのまま凝り固まることを指す言葉で、実際の骨化現象、つまり柔らかい軟骨が硬い骨になる現象に由来している。
ありがとう!
非常に複雑な言語だけど、マイナーな機能を使う理由はあまり見当たらない。自分はC++を書くとき、実質的にRAIIとテンプレートを使った『C言語』を書いているだけなので、普通ではないのかもしれない。たとえばC++20以降ではSFINAEを避けられるようになった。これは自分にとって常にC++テンプレートの一番醜い部分だった。C++20のconceptsでメタプログラミングの必要性がほとんど簡素化された。
boostのライブラリを読むのはbrainfuckを読んでいるようなものだった。実際、標準ライブラリのソースの大半もそんな感じだった。C++をやめてから15年間考えたこともなかったが、それ以来これより読みにくい言語に出会っていない。マクロ多用のLispくらいかもしれない。
テンプレートメタプログラミングは、Cで同じことをやろうとすると非常に面倒な、多くの効率化にとって欠かせないものだ。
それがScott Meyersのことを言っているなら、それは作り話だ。
他サイトの新着
それで君の論点が崩れるわけではないけど、C++11は自分にとって大きな前進で、それまでよりずっと便利でモダンに感じられた。C++14は基本的に、本来C++11に入っているべきだったものを追加・修正しただけだ。
自分もC++11は好きだ(入門書もC++11のものだった。そう、あの『モダンC++11』の本だ)。でもプロジェクトによってはC++14が必要だったり、C++98を使わされたりする。韓国で『渡り歩くプログラマー』をしているが、C++をやってくれと言われて現場に行くと、バージョンが多すぎて本当につらい。
でも『a Frankenstein』は、『a Picasso』のように彼の作品を指す言い方にもなり得る。
『a』を付けると複数あることになる。それはピカソには当てはまるが、フランケンシュタインには当てはまらない。それに、『a Picasso』を作れるのはピカソ本人だけで、他は全部偽物か盗作だ。
今使いたいマイコンのほとんど(主にARMやRISC-V、苦労したければXtensaやAVR)では、普通にRustを使える。それ以外の変わり種(PICとか)でRustが選べない場合も、選択肢がないわけではない。普通にCを選べばいい。
『Qtを使えばいい』とあるが、Qtを使うのはC++の上に新しい言語層を学ぶようなものじゃないか。メタコンパイラやシグナル/スロットの仕組みがあって、QStringのような独自クラス群まで持っていて、std::stringの代わりに使うことになる。
それだ。このサイトの議論は、この事実をいつも見落としている。自分は企業の顧客にバージョン管理の導入を必死で説得しているところなのに、ここではみんなRustの話をしている。まるで別の星に住んでいるみたいだ。
残念ながらそれ(Rust)はC++の多くの機能を欠いていて、本当の後継にはなっていない。C++の後継たりうる言語は、C++の機能を全部サポートすべきだと思う。
『ルーブ・ゴールドバーグ・マシンを作れるのはルーブ・ゴールドバーグ本人だけ』ってことか?
この話題の背景と論点
この投票はISO(国際標準化機構)がC++26を正式な規格として発行する前段階のもので、DIS(Draft International Standard)に進んだことは言語の大枠がほぼ固まったことを意味する。ただし発行までにはなお手続きが残り、ここで「C++26が確定した」わけではない。スレで割れたのは、委員会主導で機能を増やし続けるやり方への評価だ。複雑さを嘆く声やRust支持が目立つ一方、「Hacker Newsの外、つまり現場ではC++とJavaが圧倒的多数派でRustはほとんど使われていない」という指摘もあり、オンラインの空気と現場実態のギャップが浮き出た。なお脱線した「フランケンシュタイン」の言葉遊びは、contracts機能自体とは無関係な脇道の議論である。
※本記事は海外掲示板 Hacker News のスレッド「The result of the C++26 DIS ballot」から抜粋し、編集部で日本語に意訳したものです。訳文の責任は当サイトにあります。
この記事のリアクション
まだコメントはありません。