C++

描主宇田川浩行K#F85E
下描き希哲6年(2012年)
06月21日 22:30
利承
ライセンス
希哲館普通利承(KULクール
「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