C++

描主宇田川浩行K#F85E
下描き希哲6年(2012年)
06月21日 22:30
利承
ライセンス
希哲館普通利承(KULクール
「C++(シープラスプラス)」はプログラミング言語の一つ。 一般に,高性能・多機能・難解の言語とされている。

一覧

=}{*}

C++ を教え、学ぶのをより容易にするために、nullptr キーワードが導入された。」……何か力が抜けた。

=}{*}{*}{*}{*}

=}{*}

もちろん,そういう実験はどんどんやっていいのだが,C++11 に感じた筋の悪さは,それを「C++」だということにしてしまった所にある。だから私は C++11 以降を「++C」と呼んで C++ とは区別している。

=}{*}

結局,言語って「調和」が全てで,何か一つでも過不足があるとそれは簡単に崩れる。C++03 って一見不細工な言語に見えて,あれはあれで現場で使えた結果としての形なので,実は一定の合理性は担保されている。C++11 以降にはそれが無い。ただ「こんなのあったらいいんじゃない?」みたいな机上の空論で仕様を弄り過ぎ,というのが私の感想。

=}{*}

=}{*}

まあ,「いいソフトウェアには10年はかかる」という言葉通りなら,C++11 ですらまだ結果が出る段階ではない。私は C++11 以降の「新機能こそ正義」のような態度に胡散臭いものを感じて追従しなかった。どちらが正解だったのか。

=}{*}

C++ の語彙改良を行い, で文法改良に進む。そこから C の伝統にとらわれない (ディーシグマ,ドグマ)に進む。この計画を CnD(キャンディ,Cμ/Cν and Dσ )と呼ぶ。

=}{*}

=}{*}

の最初の成功は,実は Cμ という名前だったんじゃないかと思う。C のように簡略化し過ぎて結局「C 言語」みたいな書き方をしなければならない言語や C++C のように扱い辛い記号を使っている言語とも違い,簡潔かつ代用字のあるギリシャ文字を使うというのは良いアイデアだったと思う。ちなみに Cμ の次世代言語は (シーニュー)。μ の次が ν。これも完璧。

=}{*}

=}{*}

CC++ のような引括include)は,基本的に「その譜類ファイル)で直接的に必要最小限となる外部譜類を書く」ように意識すると良い。この時,引括している譜類の引括(間接引括)に依存しないことに注意すると,適度に記述の独立性が高まる。

=}{*}

=}{*}

C++auto は,便利そうに思えるのが最初だけでそのうち保守性の悪さに気付くというでしかない……。まあ,C++ の場合,型名が面倒臭すぎることが多いのも悪いのだが。

=}{*}

=}{*}

単純な話,C++ が迷走していくのは,そもそも C++ で何かを作っている人が C++ の仕様策定していないからではないかと思っている。ほとんど机上の空論で仕様が決まっている感じがする。

=}{*}

C++ 最大の過ちは,煩雑ゆえに問題だった指示体ポインター)による記憶管理の問題を,煩雑な高機能指示体の導入で解決しようとしてしまったこと。スマポは明らかに問題をややこしくしている。あれは設計者が悪いのかそもそも設計者がいないのか。

=}{*}

=}{*}

設計思想を貫いているのは「全体最適化」の観点だ。C++スマート ポインターが「複雑さの問題を複雑さで解決しようとする」罠にハマったのに対し,スウィート ポインターは徹底的に記憶管理単純化した。

=}{*}

が最高なのは,スクリプト言語以上の書きやすさと C++速さを兼ね備えているところ。これがなければデルン開発はままならなかった。

=}{*}

hash_map は混乱する可能性があるからと名付けられた std::unordered_map,もし std::mash と名付けられていたら,私はここまで C++命名センスに失望していなかっただろう。

=}{*}

それ以前は,自分で作っておきながらどこか半信半疑みたいなところがあった。そりゃ C++ を改造して独自言語にしてデルンなんて未知の司組システム)を実装する,なんて仕事だからどこに問題があるか分かったもんじゃなかった。実装なのか設計なのか要素技術なのか,そもそも実現不可能なのかとか。

=}{*}

ウェブ開発では捌き手サーバーサイド)の言語の性能は大きな問題ではない,とよく言われるが,これは実装内容がある程度無難なものに限る。実験的な実装を色々試したい場合,交度コード)は混乱してどうしても非効率になってくるので,それを補完してくれる言語性能は重要になる。これがデルン開発C++ 並みの速度に拘った主な理由。

=}{*}

月庭kitetu.com)で使っている虎哲*イチデルン実装)は,言語C++ 互換の FastCGIマルチスレッド実装,プロセス数も調整出来るようにしてあって,PostgreSQL外充て手続きストアドプロシージャ)まで Cμ で開発している。最適化を進めればどこまでも速くなる。

=}{*}

本格的に論組(プログラミング)を始めてからデルンの実装まで約5年。この頃にはすでに C++ を改良した の原型が出来ていた。冷静に考えると驚きの事実だ。

=}{*}

この前「名前空間」の改訳語として「名称空間」を採用したのだが,C++ 用語の中でも悪名高い「無名名前空間」は では「匿名空間」にしておこう。こういうの大事。

=}{*}

ただ,2020年でも遅いし,全面移行が2023年となると,流石にもう手遅れ感が否めない。module で提供されるライブラリが一般化する頃に C++ が求められる言語かというと……10年遅かったと思う。

=}{*}

いまさら C++ をいじりまわすのが良いとは思わないが,引括(インクルード)という極めて原始的な仕組みに依存しているのはやはり問題だ。この点, では魔法引括(マジックインクルード)という機構でかなり合理化を進めたと思う。

=}{*}

最近, でも模従(モジュール)という概念を考えていたのだが,そういえば C++ でも module が導入される頃なんだな。内容は結構違うが。

=}{*}

Linux を,応司(OS)にも仮想機(VM)にもなる C++ の「理想機」(ideal machine)とみなす,というのは極めて洗練された戦略だと思う。

=}{*}

CC++ を学ぶべき理由なんて,私に言わせれば「そこが一番堅い地盤だから」でしかない。じっくり腰を据えて大きなものを開発したいなら,十分な記述能力と実行環境があり,数十年は消えないくらい浸透している言語を選ぶしかない。少なくとも知機の実装を目標とした時,この要求を満たせるのは C++ しかなかった。

=}{*}

ちょっと乱暴に言ってしまうと,多くの人が「豊富で整理された標準ライブラリのある C++」程度のことを求めている自分に気付かず,散々遠回りをしてきたのがここ20年くらいの論組(プログラミング)言語の歴史だと思っている。

=}{*}

C++ の新機能を見ていると,一見どれも便利そうなのだが,それを追加することが本当に一つの言語の体系として,全体的なバランスとして良いことなのか,というのは結構危ういと思う。頭に思い描く「こんなこといいな」って実践してみると意外にいらなかったり,むしろ邪魔になったりするものだし,結局それはこれから10年,20年経って C++ が評価され続けてはじめて正解が分かることで,当然失敗の可能性もある。だからせめて名前は別にするべきだった。

=}{*}

C++98 というのは,C に先進的な機能を取り込むというのが,時代もあって「結果として」市場に受け入れられたものだ。時代が変わっているのに同じ調子で何でもかんでも取り入れても,それが成功するとは限らない,という意味で C++11 以降はやはり「++C」なのだと思う。現に,今の C++ が GoC に比べて魅力的かというと微妙なわけで。

=}{*}

C++11 以降を「C++」として発表してしまったのは過ちだと私は思っていて,個人的には評価よりも変更が早い「早まった C++」という意味で「++C」と呼んでいる。

=}{*}

そういう意味でも,C++ を基礎に網羅的かつ体系的なライブラリを構築しよう,という のアプローチは完璧に正しかったと思う。Java でも本格的なスクリプト言語でも,CC++ で書かれたライブラリを読み込む機能くらいは備えているので,そこを蓄積の軸にするのが一番合理的。

=}{*}

昨日,「std:: を付ける派も付けない派もどちらにも一理あって,それを両立させられないのは C++ の欠陥だ」ということを書いたが,それは社会にも同じことがいえて,多様でみんなが暮らしやすいのが良い,自分達の安全を守ってほしい,それはどちらも正しい。それが両立しないのは現代社会の欠陥なのだから,構造を変えるしかない。

=}{*}

考えてみれば今時の言語なら大したことではないのだが,これが「魔法」なのは,C++ として換配(コンパイル)出来るからだ。

=}{*}

似たようなことを繰り返し言うが,std:: を常に付けた方が間違いがないというのも,いちいち std:: を付けた C++ 交度(コード)は冗長で汚ないというのも,どちらも「まともな感覚」だ。それをトレードオフにしているのは紛れもなく C++ そのものの欠陥だ。

=}{*}

std:: を付けないと紛らわしい,std:: を付けると面倒臭い。実はどちらも間違っていない。つまりこのジレンマから永遠に抜け出せないのが C++ の運命で,残酷かもしれないが,それこそ C++ を捨てるべき理由だと私は思っている。

=}{*}

C++ における std:: 付加問題は,理論上はともかく,実践上は可読性・記述性にかなりの悪影響を及ぼしている問題だと考えてきて, では「通称」という命名規約を導入したりして記述を大きく簡略化することに成功しているのだが,これから語彙が増えていくと名前の衝突は無視できない問題になる。その懸念はこの技術で上手く回避出来そう。

=}{*}

例えば,::foo::std::bar という変数があると ::foo::bar() という函数からは std::bar で参照出来る。誰が作んねんという話ではあるけど。

=}{*}

あと,久しぶりにこの辺の調べものをしていて思い出したのだが,C++std:: を前に付けたところで実は全然厳格じゃない気がする。相対場筋(パス)みたいなものなので……std という文字列自体が予約されていれば問題無いとは思うが。

=}{*}

デルンCMS として実装しようとした時,C++ を基礎に独自言語を作るという発想は誰も理解出来なかった。それが今では,どのスクリプト言語よりもウェブアプリを書きやすい言語になっている。しかも,応司(OS)開発も含めてそのままあらゆる分野に応用出来る。もうこの時点で完全勝利だ。

=}{*}

何度言ったか分からないが,なぜ C++ 仕様策定者は「ポインタでのメモリ管理が煩雑」という問題を「複数のスマート ポインタを上手く使い分ける」という方法で解決出来ると思ったのだろう。

出力論組プログラム虎哲*イチ 1.01
制作・運営:希哲社
© K1-13 (2007-2019) KiTetuSha