C++ 標準ライブラリには何を入れるべきか?

これは Guy Davidson の記事「Battery not included:whatshould go in the C++ standard library?」への返信です。

ここ数年、C++ 標準にグラフィックスライブラリを含める動きがありました。 cairo.Or SDL のようなものです。現在の形式の提案はこちら

現在の状態では、ライブラリの提案は、事前に割り当てられたサーフェスにいくつかの形状を描くことができ、画像をある程度サポートしています。もちろん、テキストを追加するプロジェクトもあり、おそらくマウス/キーボード処理の形式で何らかの入力があります.

図書館の第一の目的は教育であるように思われる。子供たちが画面上にかなりのまばたきピクシーを表示するのはクールでばかげているという議論が提唱されています。もちろん、それ以上のことを行うライブラリはすでに存在しますが、C++ にはまともな慣用的なパッケージマネージャがないため、もちろん、一部の著名な委員会メンバーによって、C++ 標準はすぐに使用できる 2D グラフィックスライブラリを提供する必要があるという結論に達しました。 .

これは追求すべきではない道であり、そうするのはせいぜい時間の無駄だと思います.理由を教えてください。

しかし、まず、説明が必要です

ガイ・デビッドソンと他の人々は、この提案に膨大な労力と時間とエネルギーを注ぎ込んできました。その提案を急いで標準化することを推し進めている人々は、私よりもはるかに専門家です。

私は C++ には何も貢献していないので、以下は 1 人の意見にすぎません。

また、その特定の図書館について否定的な意見を持っていないことも明確にしたいと思います。私の問題は、この時点で C++ 標準の任意のペイントライブラリである 2D ペイントライブラリを含めることです。

誤解されないことを願っています

とにかく、始めましょう。

C++ 標準ライブラリはライブラリではありません

C++ 標準とはまさにそれです。C++ とは何か、およびその動作方法を可能な限り詳細かつ明確な方法で説明する、明確に指定されたドキュメントです。目標は、その仕様を実装することで、誰でも自分で C++ コンパイラを実装できるようにすることです。ただし、仕様が十分に具体的でないか、実装が適切でないか、独断で実装されていることが起こります。そのため、さまざまな C++ コンパイラは、実装ごとに動作にわずかな違いが生じることになります。実装を行う人々と仕様を行う人々が互いに話し合うのを忘れたために、まったく実装できない場合があります。

現在、その仕様の大部分は、すべての準拠コンパイラに同梱されているライブラリである Standard TemplateLibrary について説明しています。

その仕様には少なくとも 5 つの実装が存在し、同じ数のエンティティによって維持されています。オープンソースのものもあれば、そうでないものもあります。それらはそれぞれ、プラットフォームとシステムの選択されたサブセットで動作します。また、C++ プログラムの最下部にあるとしても、他のライブラリと同様にバグの影響を受けます。

この文脈では、C++ 標準ライブラリに何を含めるべきか、または含めるべきでないかは非常に重要な問題です。コンパイラに標準でバンドルされているものは何ですか?ほとんどの人が C++ で生産的になるために必要なものは何ですか?

ガイの記事では、自分が持つことができるポジションについて説明しています。たぶん何も必要ありませんか？たぶん、いくつかの語彙タイプが必要ですか？多分コンテナ？そうでないかもしれない？ファイルシステムのサポートは必要ですか?ソケット? json ? xml ? RPGメイキングツール? SQL ? html? javascript vm ? 2D グラフィック ? 3D グラフィック ?石鹸？IPC？窓？ $\pi$ を定義する必要がありますか? websockets はどうですか? ftp? ssh? VR ? AR ?クリプト? ssl ?ssl は必要ですが、他の暗号は必要ありませんか?ディープラーニング？音？ 3D サウンド?ビデオデコーディング? gif ?

明らかに、線を引く必要があります。

どこか?

どこ?

.Net を見てみましょう。またはジャバ。 STL が言及されている場合、C++ と Java を比較するのが通例です。 Javaはクールですよね？基本的に、ソケットと HTTP と暗号とすべてを備えています。

しかし、Java はほとんどの場合、単一のエンティティによって維持されます。そのため、Oracle の誰かが Java にソケットが必要であると判断し、それを実装しました。内部レビューがあり、現在 Java にはソケットがあります。後で、Google は同じ API を使用するソケットを持ちたいと考え、「事前に」と言う前に、90 億ドルの訴訟を起こされます。

一方、C++ 仕様は、投票が行われ、すべての機能、すべてのメソッドについて過半数のコンセンサスが得られるまで、長く苦痛なプロセスを経ます。 data と呼ぶべきか ?get ? 「ブルームバーグでは、data を使用した経験があります。ブルームバーグで働いている人はこう言います。「タイプ get を使用する方が高速であることに気付きました onEBCDIC キーボード」は、IBM の担当者に異議を唱えます。「そして、300 万行のコードベースがあります」

どのモデルが最適かという意見はありません。慈悲深い独裁は明らかに、独裁者が慈悲深い場合にのみ機能します。

しかし、民主主義は優れたグラフィックライブラリの誕生にはふさわしくないと主張します。

委員会のリソースは限られています

睡眠不足の提案書作成者が汗を流したとしても、仕事の大部分と投票は、1 週間にわたる四半期ごとの会議で行われ、人々は増え続ける提案書の山に目を通します。委員会が透明性を高めることを学ぶにつれて、より多くの人が貢献し、参加者の仕事が増えます。その仕事にはほとんどお金がかかりません。せいぜい、誰かがフロリダのビーチ、スイスの緑の丘、または会議が行われるハワイのプールへの飛行機のチケットを支払うことを望むことができます.伝えられるところによると、あなたはビーチも丘もプールも見たことがないでしょう.

リソースも時間も限られているため、提案を分類し、優先順位を付け、さらには破棄する必要があります。ソートと優先順位付けがどのように行われるかを説明するための ISOC++ 試行の指示。

質問は次のようになります:委員会は 2D グラフィックスライブラリに取り組む時間を割くことができますか?それは優先事項ですか?

図面の形状に限定された現在の形式では、提案は約 150 ページの長さです。これは、次の会議に提出された最大の提案の 1 つです。

大きくなるしかありません。「小さくてシンプルなグラフィックライブラリ」の複雑さに終わりはありません。その提案に費やされる 1 秒ごとの費用が他の作業に費やされることはありません。もちろん、人々は興味のある提案について議論し、議論は並行して行われます。まだ。 200,000 人の C++ 開発者ごとに、これらの会議に 1 人が出席する可能性があります。

三角形を描いてみましょう

2D グラフィックスは、標準化プロセスが得意とするものとは正反対です。標準化はすべて形式主義に関するものなので、形式的なもの、数学、アルゴリズムを記述するのに最適です。現実が乱雑になるほど、それを紙に書いて、その紙が何十年にもわたって真実の情報源として機能することを説明するのが難しくなります.

きれいなピクセルで遊ぶために最初に必要なことは、「表面」を取得することです。ピクセルが描画されるキャンバス。

surface を持っていることを願っています寸法を指定すると、ペイントするキャンバスが得られるクラスです。

ちょっと待って。ほとんどのデスクトップシステムでは、サーフェスが必要な場合は、ウィンドウに配置する必要があります。ウィンドウにはタイトルがあるのが通例なので、おそらくグラフィックス API でそれを処理する必要がありますよね?

また、ウィンドウにアイコンを付けたいと思うでしょう。アイコンはほとんどのシステム上のファイルであり、その形式はシステム固有です。ただし、パスではなく、パスに対応する名前の場合もあります。

一部のデスクトップオペレーティングシステムでは、プログラムの実行中にウィンドウのサイズが変わることがあります。

ウィンドウを別の解像度を持つ別の画面に移動できる場合があります。そして、真のピクセルよりも大きい仮想ピクセルがあるこの奇妙な新しい画面がありますか?画像などをレンダリングする場合を除き、顧客は自分の画面がどれほど鮮明かを自慢するために割増料金を支払ったため、小さな鮮明なピクセルのすべてのパワーを確実に使用する必要があります。

あそこにいるあの女性が嫉妬したので、彼女は 40 ビット/ピクセルのテレビを買いました。違いはよくわかりませんが、彼女が 5,000 ドルを無駄にしたと言うつもりですか?

そして、あなたのポケットにはスクリーンがあり、それはあらゆる方向に回転し、表面はすべて不安定です.ただし、ウィンドウがないため、タイトルもアイコンもありません。

今何時ですか？なんてこった、画面もあるけどとても小さい…本を読みに行って、できるだけ少しリフレッシュする必要があり、それは黒だけですか?

世界はクレイジーですよね？ Linuxに固執しましょう。 Linux では X11 と呼ばれるものがあり、これにサーフェスを要求します... 申し訳ありませんが、論文を書いている間、X11 は非推奨になり、今は Wayland を使用する必要があります... フレームバッファが必要な場合を除きますか? opengl を使用して高速化できます。または埋め込まれたopengl。まったく別のことですが、実際には、Vulkan はこれらの両方よりも高速です。ああ、このシステムでは、自分でウィンドウを描画することをお勧めします。CSD と SSD についての論争が何年も続いており、どちらの側にも立つことはできません。

また、CSD をお持ちの場合は、ウィンドウを適切にドラッグできることを確認してください。それらを必ず処理してください。ちゃんと。ウィンドウをドラッグすると、少し透明になるはずです。ウィンドウの合成についてご存知ですか?

さて、あなたは絵を描くのは複雑かもしれないと自分に言い聞かせ始めます。実装者、コンパイラ作成者、およびライブラリベンダーに、すべてのがらくたを処理させてください。したがって、どこでも機能する API を提供すると、まったく何も処理されません。つまり、どこでも機能しないということです。

現在、コンパイラの作成者は少し腹を立てています。彼らが人生で望んでいたのは、コンパイラを書くことだけでした。彼らは、GDI がどのように機能するかを理解しようとしています。さらに、Microsoft はおそらく描画フレームワークの提供にあまり関心がなく、むしろユーザーに WinRT xml ベースのツールを使用させています。一方、GCC 関係者はまだ std::thread を持とうとしています。 Windows で動作します。

Clang の人々は、「動かない」というバグ報告を受け取ります。人々は、STL がどこでも完璧に一貫して機能することを期待しています。

問題ない。グラフィックスライブラリをオプションにします。そのため、標準ではない標準ライブラリのビットがあります。それらが実装された場合、すべてのプラットフォームでまったく同じように動作するとは限りません。そのため、標準ツールを使用して記述されたコードは移植できません。そのため、レポジトリに STL のコピーと、乱雑なビルドスクリプトを用意する必要があります。振り出しに戻ります。

多分私たちはどこかを台無しにしましたか？インターネット上に存在するものを見てみましょう。人々はディスプレイを持っているので、必ずディスプレイ用のライブラリを作成しますよね?

Qt は非常に人気があることがわかりました。ただし、三角形を表示するだけではありません。 1995年にリリースされました。糸、糸、たくさんのものがあります。それ以来、人々は本当に良いものを思いつきませんでしたか?

wxWidgets はさらに古いものです。文字列やスレッドなど、グラフィックライブラリには関係のないものがたくさんあります。 GTK はまったく同じものです。

しかし、C++ の目標は、SDL などとより一致しています。 1995年にリリースされ、スレッドとストリングスと奇妙なものがあります. Allegro、1990 年にリリース。同じもの

あなたは他の言語を見ます。確かにRustコミュニティにはawesomepaintingフレームワークがありますよね?それとも囲碁の人？彼らは Qt や SDL などのラッパーを書いていることが判明しました。まるで、ゼロから始めるのは複雑だと思われるようなものです。

20 年後、すべてのプラットフォームで三角形を描くことができます。すべての定義について。

それはかなりの成果なので、あなたの喜びを世界と共有したいと考えています。人々は主に言語を使用してコミュニケーションをとっています [要出典] ので、画面にいくつかの単語を表示しようとしていますが、三角形からそこに移動するのはどれくらい難しいでしょうか?

void draw_text(std::point2d, std::string);

世界中の人々が使用するすべての文字を記述する「Unicode」と呼ばれる標準があることを学びます。たくさんの手紙。 Unicode 規格は、あなたが 5 年間取り組んできた提案の約 10 倍のサイズです。幸いなことに、ほとんどのプログラミング言語は、少なくとも Unicode の一部をサポートしています。 C++ を除く。まあ、それはさておき、オーケーレットにしましょう。

したがって、テキストはフォントを使用してレンダリングされます。多くの場合、フォントはシステムにインストールされています。フォントが何であるかを示すフォントデータベースと呼ばれるものがあります。システムにフォントデータベースがない場合を除きます。またはフォントがありません。またはシステムなし。人々は独自のフォントを使用することも好みます.

フォントは、フォーマットが標準のファイルです。競合する規格は 5 つほどあります。

フォントファイルには、グリフテーブル、PNG、SVG、仮想マシンで実行されるスクリプト、およびそれらすべての組み合わせを含めることができます。一部のフォントには色がありますが、すべての人が色を好むわけではありません。あなたの子供たちは色が好きです。 🐈を送ってくれました。猫のサポートを追加しますよね?

サブピクセルレンダリングについて学習します。特許侵害で数か月刑務所に入れられます。その時間を使って、百科事典で合字について学ぶことができると思います。あなたは開発者であることを後悔し始め、修道士としての新しいキャリアを考える.

フォントのレンダリングには多くの数学が関係しているので、AL-Khwarizmi と呼ばれる死んだ男が書いた数学の本を手に取ります。すべてが右から左に書かれていることがわかります。それはどのように機能しますか?

では、オプションの 2D グラフィックスライブラリには、オプションのテキストサポートが必要なのではないでしょうか?

トロントでの次の委員会 (ハワイはずっと前に海に沈みました) で、誰かが、ネットワークと大量の入力を使用して複雑なグラフィックアプリケーションを作成し、スパゲッティコードを回避して、何らかのイベントループとおそらく何らかのスレッドを使用しようとしています。入力サポートがないため、明らかに理論上の問題です。キーボードのキーに名前を付ける方法については、合意に達しませんでした.

イベントループ、メッセージパッシングシステム、および Unicodestring 型を提供する、現在バージョン 8.0 になっている Qt のような既存のすべてのフレームワークを思い出してください。彼らは何かを企んでいたのかもしれません。

この間ずっと、人々は Qt を使い続けました。人々はQtを知っているために雇われました。彼らはそれを学校のプロジェクトで使用しました。もちろん、標準に追加された C++ リフレクション機能が Qt のコードジェネレーターを置き換えるには十分ではなかったため、Qt は依然として最悪です。しかし、人々はそれがひどいことを気にしません。 QML を使用している人。またはエレクトロン。

🐅が表示されていないので、2018 年に戻りましょう。

とにかく、委員会は他にすべきことはありますか?

考慮されるためには、提案を作成して提出する必要があり、図書館の提案が存在するのは、誰かがそれに多くの労力を費やしたからです.

ただし、現在、C++ には

スレッディングのサポートが不十分 (コルーチンを使用するエグゼキュータまたは機能がない)
起動プロセスのサポートなし
Unicode をサポートしていません
貧弱な I/O 機能
現地の施設が貧弱
動的に読み込まれたライブラリはサポートされていません
HTTP サポートなし
暗号関連なし

もちろん、リストは続きます。 C++ ライブラリの適切な候補はわかりませんが、委員会自体によると、ライブラリの提案はすべきです

多くの人に役立つ
頻繁に変更されない安定した API を使用する
実際の経験とフィードバックを得る。これが、ほとんどの C++ ライブラリがブーストライブラリとして誕生した理由です。

提案は、十分に有用でないか、十分にテストされていないという理由で、最初から却下されることがよくあります。 STL の安定性に関する人々の期待を考えると、これは妥当ですが、これらの基準は一貫して適用されるべきです。

そしてもちろん、何年にもわたる作業の後でまだパイプラインにある多くの言語機能があり、純粋なライブラリの追加はブーストなどによってポリフィルできるため、それらはライブラリ機能よりも優先されるべきです.

教育の議論

そのライブラリを含めることについて提唱された議論の 1 つは、それによって C++ がより教育しやすくなり、人々がグラフィックスベースのプロジェクトにより関心を持つようになるというものです。
私は、C++ をより教育しやすいものにするという目標に共感し、完全に同意します。ただし、特定の機能を確実に教育しやすくすることと、教室で使用することを主な目的として主要な機能を言語に追加することには違いがあります。

教えやすさとは、使いやすく、誤用しにくく、概念とその実装の間の適切なマッピングを意味し、一般的に大多数のユーザーの期待に応じて動作します。新機能で求められる品質。

一部の機能は、上級ユーザー、ライブラリ作成者、および専門家を対象としていることも予想されます。

ただし、C++ の「教育に適した部分」は、別のセットではなく、専門的な設定で使用される機能のサブセットであるべきです。

Qt (たとえば) の使用方法を学ぶことは、教育目的に特化したものではなく、プロとしてのキャリアで使用できるスキルであるため、私は望んでいます.

また、範囲が狭すぎるライブラリは、言語に対するイメージを悪くする可能性があると思います。絵文字や GIF を描画したり、ゲームパッドを使用したりできないと言われたら、C++ は十分に強力ではないと考えて、C#、Java、JavaScript、Swift などの別の言語に切り替える可能性があります。コードが「現代的」でなくても、彼らの設計 (Qt、SDL) を実装するのに十分な強力なテスト済みのフレームワークを使用すると、C++ で何ができるか、何ができるかをよりよく理解できるようになります。

言い換えれば、人々がおもちゃのライブラリを紹介されたら、C++ はおもちゃの言語だと思うのではないかと心配しています.

それに加えて、「教えること」をより適切に定義する必要があります。

中学生の話ですか？もしそうなら、彼らに C++ を教えることは良い考えですか?場合によっては、Python、Javascript、Lua の方が適していて、選択肢を把握しやすいです。大丈夫だと思います。

私たちは大学CS 101について話しているのですか？この場合、システム、ライブラリ、およびパッケージ管理の構築を学生に紹介することがおそらく望ましいでしょう。ツールは重要です。私の経験では、多くの若手開発者は自分のツールの使い方を知りません。人々がエコシステムを知り、教えられることも重要です。 Qt、ブースト、wxwidgets、SDL…

「サードパーティライブラリを使用するのは難しいため、標準ライブラリが必要です」という議論

ほとんどの人がそれに同意すると思います。 C++ プロジェクトにライブラリを含めることは、しばしば苦痛を伴う悪い経験です。 2dgraphic ライブラリに多くのリソースを投資しても、この問題は解決しません。存在する、または存在するであろうすべてのライブラリが標準に組み込まれない限り、どこで止めればよいでしょうか?

申し訳ありませんが、自然に改善することはありません。それは不可能です。どのような種類のパッケージマネージャーでも、信頼できることが一番の要件です。必ずしも良いものである必要はありません。しかし、個々のエンティティがこの問題に対処するために残されるまで、私たちは無数の互換性のない半支援ツールを使い続けるでしょう。委員会の権限が必ずしも言語の定義の外にまで及ぶとは限らず、したがってパッケージ管理の問題が解決できない可能性があることを理解しています。しかし、C++ が取り組まなければならない大きな課題は、UI ではなくツールです。

委員会が特権を拡大することなくツールの改善を支援できる方法があることに注意してください。特に:

プリプロセッサのすべての合理的な使用に取って代わる方法を見つける (そのためには、リフレクション/コードインジェクションに関する作業が非常に重要です)
移植可能な C++ ABI の定義 (N4028)
ポータブルモジュール表現の定義

確かに、これらの作業は 2D API ほど魅力的ではないかもしれませんが、より基本的なものであり、さらに重要なことに、委員会から独立して行うことはできません.

物事は何とか前進するはずです。

P0939 と P0267 を見た後、関連分野での作業を希望することを共有したいと思いました。もちろん、私は望んでいる以上のことをしているわけではなく、誰かにインスピレーションを与えることしかできません!しかし、私はあなたがそれらの分野で重要だと思うことに興味があります!

ユニコードの雄牛の角を取ります

C++ に Unicode がない理由を理解しているので、私はそれを提案しませんでしたが、2D グラフィックスを真剣に検討しているのであれば、適切な Unicode サポートが絶対に必要です。

最初のステップは char8_t です紙。もちろんそれだけでは十分ではありませんが、必要です。
Unicode 文字列を正規化、比較、サニタイズ、変換し、文字数をカウントする一連のアルゴリズムが必要です。範囲ベースの何かがうまく機能する可能性があります
文字のクラス、正規表現... ICU ほど多くの機能は必要ないかもしれませんが、いくつかは必要です。それは <unicode> かもしれません適切な Unicode サポートが、P0939 で概説されている制約に沿った目標であるかどうかはわかりませんが、GUI、データベース、(Web) サーバー、コンソールアプリケーションなど、ユーザーの入力/出力を扱うすべてのアプリケーションにとって有益です。 /li>

語彙タイプの Unicode 文字列を修飾できるかどうかはわかりませんが、世界の言語を処理することは確かに誰もが必要とすることであり、それを行うための普遍的で慣用的なツールがあればより簡単になるでしょう.

ジオメトリプリミティブを標準に追加

p0267 で導入された語彙タイプを抽出し、グラフィックとは別にそれらを標準化することは興味深いかもしれません。 point_2d のような型、 matrix_2d (そして最終的に point_3d 、 matrix_3d ) はグラフィックスに役立ちますが、科学計算、プロット操作など、他の用途にも使用できます。これらは、広く使用されている解析的ジオメトリ計算を実行するための一連のメソッドを伴う可能性があります。そのすべてが <geometry> に収まる可能性がありますヘッダー。

これが有益である理由は複数あります

これは、ペイントやサーフェスを扱うすべてのライブラリに必要なものですSDL_Point 、 QPoint 、 wxPoint あるタイプから別のタイプへの変換は面倒で、エラーが発生しやすいです。これらのフレームワークはすべて、同じ座標系で同じ言語を話すことでメリットが得られます。これは語彙型の定義です。
時の試練に耐えることが保証されています。数学は新しいテクノロジートレンドの影響を受けないため、API は何十年も安定しています。
同じ理由で、コンセンサスに達するのはおそらく簡単ですが、基本的な数学を自転車に乗せるのは難しいです。

既存のグラフィックライブラリの改善にご協力ください

Qt、wxWwidgets SDL、およびその他のグラフィックスフレームワークを改善するために、委員会は何ができるでしょうか?多くのフレームワークは、大規模で侵襲的なマクロの使用またはコードジェネレーターによって生成されるボイラープレートコードに依存していることが判明しました。リフレクションとコードインジェクションは、これらのフレームワークのモダナイゼーションと改善の基本であり、これは基本的に、純粋にライブラリ作業よりも優先されるべき言語機能です。

Graphics の提案を独自に成長させましょう

おそらく、別のグラフィックスフレームワークが必要になるでしょう。そうでなければ、私は誰と言えますか?しかし、既存のフレームワークは 20 年間、戦闘でテストされてきました。 2D グラフィックスは、今後数年間で、独立したライブラリまたはブーストライブラリとして繁栄し、成長する可能性があると思います。最も重要なことは、同じものを 5 つ以上実装するのではなく、さまざまなプラットフォームで動作する単一の実装を提供できることです。

テキストレンダリング、入力、イベント、バックエンド、スレッドモデルを自由に試すことができます…

私は、この提案とパッケージ管理の問題が何かを必要としていると感じていますそれは ISO でなくても権威があり、それが何かわかりません