アカウント名:
パスワード:
> この記事のタイトルは「C/C++に死を」だが、原文タイトルにはC++は含まれていない
とはいうが、Cの方はリソースの厳しい組み込み向けなど、他で置き換えられないニーズがまだある。C++の方こそ、それが使われていた用途向けには今ではもっと洗練された言語がある。まあ放っておいても滅びそうだからあまりそういう話題にもならないのだろうけど。
C言語の方は放っておいたら当分は滅びそうにないから「滅びるべき」という話が出てくるんだろうな。
しかし、訳文にC++を勝手に追加した御仁は何の考えあってのことなのだろうか。
リソース制限が理由でCは使えるのにC++が使えないことなんかあるの?
使えないじゃなくて必要が無い。オブジェクト指向ってのはそもそも、大規模で複雑なシステムを大勢で開発するようなケースで便利な方法として考えられたもの。リソース制限が厳しい環境はそもそも大きなプログラムを置けないので、C++を持ち出す必要もない。使ってもいいが。まあC++でC的な書き方もできるなんて屁理屈を捏ねだす奴もいるだろうけど。
まあC++でC的な書き方もできるなんて屁理屈を捏ねだす奴もいるだろうけど。
屁理屈じゃなくて普通に書けるけど。
リソースの制限だって、C/C++ってそんなに変わらないと思う。ライブラリも不要ならリンクの必要なものだけリンクすればいい。
C/C++のメリットって、言語以外の関連知識が充実すればするほど、その辺の開発環境に依存しない使い方が生きてくるところでしょ。
「プログラミング言語C++」なんかを読めばわかりますが、初期のC++に関するStroustrup氏の設計思想としては、「従来のCコードは、C++でもオーバーヘッドなく使える」というベターCとして設計してるんですよね。
今時の肥大化したC++は置いといて、仮想関数とかテンプレートは使わない、その当時のレベルのC++で「クラススコープによる隠蔽と名前空間の分離」ができるだけでも、Cに比べて記述コードは格段に分かりやすくなるし保守しやすくなる。それぐらいならCに比べてオーバーヘッドはありません。
で、たぶん、実際に組み込みでC++を使っている、一番メジャーなプラットフォームは「Arduino」でしょう。Arduinoの開発言語は自称Arduino言語となってますが、その中身はC++(gccベース)で独自のライブラリを載せたものになってます。専用のクラスライブラリを作っただけあって、それなりに省メモリというかオーバーヘッドのないものになってますので、標準的な環境(ATmega328pなど)ではROM(プログラム)32kB・RAM8kBぐらいですが、ROM8KB・RAM512Byteってレベルのマイコンチップでも動かすことができたりします。
#4バイトなintをガンガン使ってるのだけはツッコミを入れたいですが…
標準的な環境(ATmega328pなど)ではROM(プログラム)32kB・RAM8kBぐらいですが、
RAMは2kB [arduino.cc]だぞ。
avrgccのintは2バイト [gnu.org]だし、ライブラリ中ではuint8_tの変数が積極的に使われてるぞ。
# よくIDでこんなトンチンカンな投稿するなあ
あれ？2バイトじゃなかった？
テンプレートも実行時オーバーヘッドなしかつ型安全にマクロを置き換えるためにガンガン使えるのでは
テンプレートをガンガン使うとコードサイズの肥大化著しいので「オーバーヘッドなし」とは言い難い。
さらに不用意にSTL使うと例外を引き連れてくるので時間に厳しい局面ではステップ数見切る根性無く利用を断念。
例外切っても、じゃぁそんときどうなるのよ？を見る手間をかけられず利用を断念。
いやだから、C言語的な書き方をするなら、わざわざC++を持ち出す必要が無いだろうという話だよ。オブジェクト指向を使ったプログラミングをしたいからC++の存在価値があるんだろう。そしてオブジェクト指向と言う点では、今日もっとましな言語がある。
C++の代わりになる言語なんて今でもRustぐらいしかないでしょ。
D言語は？
ROM数kバイト、RAM500バイトみたいな組込みやっててもオブジェクト指向は使いたいよ。もう構造体に関数ポインタならべてディスパッチするのはやりたくない。
静的型付けでGCがなくて今風の構文を押さえた小さい言語があるといいんだけど。
オブジェクト指向って基本的に「他人の作ったものを『安全簡単』に使いまわし」するのに便利な手法じゃないの？小規模なものを自分で1から10まで再利用無しで作る場合は、オブジェクト指向にしたところで大して楽にはならないと思うけど。
過去の自分は十分他人になりえるだろ規模がどんなに小さかろうがオブジェクト指向を利用するよそのほうが楽で簡単だからな
そうか。自分なら「ROM数kバイト、RAM500バイト」に収まるプログラムなど、ソースコード1行1行読みなおした方が話が早い感じだけど。
俺は嫌だな。少しでも楽したいし、早く帰りたいし、無用のトラブルは避けたい。
大規模開発とかいってるけど普段どんな規模のプログラム書いてるのか聞きたいなソースが1000行ポッチ越える程度の個人開発でもはるかに有用200越えるくらいの極小規模でも私なら採用する
ひょっとして、その程度のプログラムから中規模・大規模なのか？
大規模というのはチーム組んで取り掛かるような案件。とても銘々が他人の書いたコードの中身を1行1行読んでいくことなど出来ないというような場合に、オブジェクト指向は役に立つ。
1000行程度の自分で書いたものなら、オブジェクト指向も何も、中身全部細かく把握できてるんじゃないの？とりわけややこしいところにはコメントをつけるくらいで、昔のものを掘り出して使うのにも別に困ったことは無い。クラス設計の手間や無用に汎用化させるための記述の増加など、手間が増えることの悪影響の方が多いように思える。
人の多さなんてOOPにはなんの関係もない困らないだとか、一行一行読むどうこう何て発言がプログラマから出るのが悲しすぎる。
困るとか出来るじゃなくて、便利で効率が良いの何で楽するために努力しないんだ？
クラス設計して記述が増えるコストよりはるかにメリットがあるのチューリング完全なプログラム同士なら出来るなんて当たり前なの
> 大規模というのはチーム組んで取り掛かるような案件。とても銘々が他人の書いたコードの中身を> 1行1行読んでいくことなど出来ないというような場合に、オブジェクト指向は役に立つ。
これがIT土方の限界か。
オブジェクト指向設計に「しない」ほうが手間が増えるんですよ。
> オブジェクト指向って基本的に「他人の作ったものを『安全簡単』に使いまわし」するのに便利な手法じゃないの？
違います。オブジェクト指向は「データと、それを処理する関数群を、一体のもの（オブジェクト）として捉える」ということ。継承もカプセル化も、それに付随するものでしかない。
calc_hoge(hoge);print_hoge(hoge);
とするより、
hoge->calc();hoge->print();
と捉え方を変換しましょうよ、ってだけのこと。だから、規模とかは関係ないのです。
違うのは、 君は「オブジェクト指向とは何か」を説明している。 私は「オブジェクト指向はなぜ必要とされるのか」を説明している。というところだよ。
「他人の作ったものを『安全簡単』に使いまわし」
これが本当に安全ならどんなに楽か・・
些細な改修の話が継承しまくった肥大なobjectという何かの大元にちょっとした間違いがあったせいで工数が莫大に増えた事なんて珍しくない
難易度までカプセル化しやがる
オブジェクト指向をオブジェクト指向が必要とされるところ以外に使っちゃいけない理由もないです。むしろ使ったほうが便利ならば使いましょう。
低品質なコードはオブジェクト指向では救えません。ちゃんとテストしてくださいとしか言いようがありません。
オブジェクト指向だと、オブジェクトを間違った使い方を「させない」ことができるから「安全」なのです。間違った引数を受け取らない。外部からの不正な操作をさせない。これがカプセル化です。
オブジェクト指向が楽と言っている人は、このようなカプセル化はしていないんでしょう。構造化プログラミングをオブジェクトで実現しているだけ。
カプセル化するほうが「楽に」コーディングできるんです。使用したいインスタンスがどんなパラメタを持っているか、パラメタは書き換えていいかどうかなどを使用する側が意識する必要がなくなるのですから。使用する側は、ただインスタンスにメッセージを投げればいいだけです。
publicスコープとprivateスコープの使い分け程度ならば、オブジェクト指向というより、構造化プログラミングの範疇であり、C言語でもよく使われる書き方です。
publicスコープとprivateスコープ
厳密にいえば、public、protected、private はスコープじゃなくて、アクセスコントロールなんだけど。つまり、親のプライベートは見られるけどアクセスできない。
継承による差分プログラミングでオブジェクト指向が注目されたことがありましたが、前世紀中に否定的な結論が出てたと思います。今は設計手法としてオブジェクト指向を活用しているところが多いのではないでしょうか。
えーと、OS載せてないナマのCPUのプログラムを書こうとするとわかりますが、RAMが２Kbyteしかない、malloc から自分で実装しなければならない、ってのを相手にするとよくわかると思いますよ。ついでにROMが４Kbyteとかの制限もｗ
それでも、こうすればC＋＋でも書けるぢゃん、という屁理屈が返ってくるでしょーが、Cを使わなくてC++でないといけない理由、をかんがえてみましょう
えーっと、最近は内蔵メモリも増えてフラッシュも安いので、そう言った開発の延長線上にそのままどっちも数十KB〜1MBくらいのリソースに余裕があるケースの方が増えてるんですよ。そんな場合はmallocやらヒープやらをちゃんと実装して、効率よく実装とデバッグを進めた方が断然ラクですね。もちろんCでも問題ないし、例外・割り込みハンドラのトップハーフはアセンブラだったりしますが、その後はメンテのしやすさ・設計の分かりやすさでC++での実装になりますね。
ここら辺で一番めんどくさいのは、ヒープやライブラリアンの設定などの下回りはC/C++の言語仕様の外の世界の話になってしまって、開発環境ごとにマニュアル読んで個々に実装しなきゃならない事ですね。個人的な印象では、この辺がよく理解出来ないので未だにprintfすら使えない環境だと言い張ってる人が多い感じですね… もうそんな時代じゃ無いんですが…
> どっちも数十KB〜1MBくらいのリソースに余裕があるケースの方が増えてるんですよ。
そういうケースが増えてきたところで、そうでないケースも依然あることには変わりないんだが。
逆に、C++を使わなくてCで書かないといけない理由も無いと思いますけど。
いやまー、RAM2Kbyteでそれ言えるならなんも言いませんわ。え？数メガ搭載してるCPU？だれがそんな話してるの？
RAM2Kbyteで済む内容をC++で書けないとする理由がわかりません。
結構前(20年弱昔)の話なんで今はどうかわからんけど、リソースの制限が厳しい環境だと、専用のコンパイラが用意されてたりするんだけど、そのコンパイラが C++ に対応していないってことが多かったよ。対応していたとしても、例外に対応出来ないとか、template 使えないとか制限があったりしたよ。あれから随分経ったけど、今はどんな感じなんだろか？
わたしたちのC++言語
原文タイトル [techcrunch.com]にはC++は含まれていない
タイトルは "Death to C, ++" なので"C++" は含まれてはないですね
その、「リソースの厳しい組み込み向け」にRustは使えるって話なんだけどね。
要求リソースが二桁違う [hatena.ne.jp]んじゃね？
元タイトルは "Death to C, ++" なので別におかしくはないと思うが、C++ではなく++と書くことでどういうニュアンスになってるのかはよく分からないな。
なお本文では普通にC++にも触れてるしC言語と同じ扱いされてる。
"Death to C" [techcrunch.com]の「続編」という意味で"++"が付いているのでしょう。いずれにしても、本文にはC/C++の代わりにRustを使えと言っているので、タイトルにC++が含まれているかどうかというのは些細な話だと思います。
タレコミでは言及されてないですしタレコミより前に取得されたアーカイブ [archive.fo]でもタイトルは同じなんでhylomのせいでは
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
C++の方こそお役御免では？ (スコア:0)
> この記事のタイトルは「C/C++に死を」だが、原文タイトルにはC++は含まれていない
とはいうが、Cの方はリソースの厳しい組み込み向けなど、他で置き換えられないニーズがまだある。
C++の方こそ、それが使われていた用途向けには今ではもっと洗練された言語がある。
まあ放っておいても滅びそうだからあまりそういう話題にもならないのだろうけど。
C言語の方は放っておいたら当分は滅びそうにないから「滅びるべき」という話が出てくるんだろうな。
しかし、訳文にC++を勝手に追加した御仁は何の考えあってのことなのだろうか。
Re: (スコア:0)
リソース制限が理由でCは使えるのにC++が使えないことなんかあるの?
Re:C++の方こそお役御免では？ (スコア:1)
使えないじゃなくて必要が無い。
オブジェクト指向ってのはそもそも、大規模で複雑なシステムを大勢で開発するようなケースで
便利な方法として考えられたもの。
リソース制限が厳しい環境はそもそも大きなプログラムを置けないので、C++を持ち出す必要もない。使ってもいいが。
まあC++でC的な書き方もできるなんて屁理屈を捏ねだす奴もいるだろうけど。
Re: (スコア:0)
まあC++でC的な書き方もできるなんて屁理屈を捏ねだす奴もいるだろうけど。
屁理屈じゃなくて普通に書けるけど。
リソースの制限だって、C/C++ってそんなに変わらないと思う。
ライブラリも不要ならリンクの必要なものだけリンクすればいい。
C/C++のメリットって、言語以外の関連知識が充実すればするほど、
その辺の開発環境に依存しない使い方が生きてくるところでしょ。
Re:C++の方こそお役御免では？ (スコア:1)
「プログラミング言語C++」なんかを読めばわかりますが、初期のC++に関するStroustrup氏の設計思想としては、「従来のCコードは、C++でもオーバーヘッドなく使える」というベターCとして設計してるんですよね。
今時の肥大化したC++は置いといて、仮想関数とかテンプレートは使わない、その当時のレベルのC++で「クラススコープによる隠蔽と名前空間の分離」ができるだけでも、Cに比べて記述コードは格段に分かりやすくなるし保守しやすくなる。それぐらいならCに比べてオーバーヘッドはありません。
で、たぶん、実際に組み込みでC++を使っている、一番メジャーなプラットフォームは「Arduino」でしょう。
Arduinoの開発言語は自称Arduino言語となってますが、その中身はC++(gccベース)で独自のライブラリを載せたものになってます。
専用のクラスライブラリを作っただけあって、それなりに省メモリというかオーバーヘッドのないものになってますので、
標準的な環境(ATmega328pなど)ではROM(プログラム)32kB・RAM8kBぐらいですが、
ROM8KB・RAM512Byteってレベルのマイコンチップでも動かすことができたりします。
#4バイトなintをガンガン使ってるのだけはツッコミを入れたいですが…
Re: (スコア:0)
標準的な環境(ATmega328pなど)ではROM(プログラム)32kB・RAM8kBぐらいですが、
RAMは2kB [arduino.cc]だぞ。
#4バイトなintをガンガン使ってるのだけはツッコミを入れたいですが…
avrgccのintは2バイト [gnu.org]だし、ライブラリ中ではuint8_tの変数が積極的に使われてるぞ。
# よくIDでこんなトンチンカンな投稿するなあ
Re: (スコア:0)
あれ？2バイトじゃなかった？
Re: (スコア:0)
テンプレートも実行時オーバーヘッドなしかつ型安全にマクロを置き換えるためにガンガン使えるのでは
Re: (スコア:0)
テンプレートをガンガン使うとコードサイズの肥大化著しいので「オーバーヘッドなし」とは言い難い。
Re: (スコア:0)
さらに不用意にSTL使うと例外を引き連れてくるので
時間に厳しい局面ではステップ数見切る根性無く利用を断念。
例外切っても、じゃぁそんときどうなるのよ？を見る手間をかけられず利用を断念。
Re: (スコア:0)
いやだから、C言語的な書き方をするなら、わざわざC++を持ち出す必要が無いだろうという話だよ。
オブジェクト指向を使ったプログラミングをしたいからC++の存在価値があるんだろう。
そしてオブジェクト指向と言う点では、今日もっとましな言語がある。
Re: (スコア:0)
C++の代わりになる言語なんて今でもRustぐらいしかないでしょ。
Re: (スコア:0)
D言語は？
Re: (スコア:0)
ROM数kバイト、RAM500バイトみたいな組込みやっててもオブジェクト指向は使いたいよ。
もう構造体に関数ポインタならべてディスパッチするのはやりたくない。
静的型付けでGCがなくて今風の構文を押さえた小さい言語があるといいんだけど。
Re: (スコア:0)
オブジェクト指向って基本的に「他人の作ったものを『安全簡単』に使いまわし」するのに便利な手法じゃないの？
小規模なものを自分で1から10まで再利用無しで作る場合は、オブジェクト指向にしたところで
大して楽にはならないと思うけど。
Re:C++の方こそお役御免では？ (スコア:1)
過去の自分は十分他人になりえるだろ
規模がどんなに小さかろうがオブジェクト指向を利用するよ
そのほうが楽で簡単だからな
Re: (スコア:0)
そうか。自分なら「ROM数kバイト、RAM500バイト」に収まるプログラムなど、
ソースコード1行1行読みなおした方が話が早い感じだけど。
Re: (スコア:0)
俺は嫌だな。
少しでも楽したいし、早く帰りたいし、無用のトラブルは避けたい。
Re: (スコア:0)
大規模開発とかいってるけど普段どんな規模のプログラム書いてるのか聞きたいな
ソースが1000行ポッチ越える程度の個人開発でもはるかに有用
200越えるくらいの極小規模でも私なら採用する
ひょっとして、その程度のプログラムから中規模・大規模なのか？
Re: (スコア:0)
大規模というのはチーム組んで取り掛かるような案件。とても銘々が他人の書いたコードの中身を
1行1行読んでいくことなど出来ないというような場合に、オブジェクト指向は役に立つ。
1000行程度の自分で書いたものなら、オブジェクト指向も何も、中身全部細かく把握できてるんじゃないの？
とりわけややこしいところにはコメントをつけるくらいで、昔のものを掘り出して使うのにも別に困ったことは無い。
クラス設計の手間や無用に汎用化させるための記述の増加など、手間が増えることの悪影響の方が多いように思える。
Re: (スコア:0)
人の多さなんてOOPにはなんの関係もない
困らないだとか、一行一行読むどうこう何て発言がプログラマから出るのが悲しすぎる。
困るとか出来るじゃなくて、便利で効率が良いの
何で楽するために努力しないんだ？
クラス設計して記述が増えるコストよりはるかにメリットがあるの
チューリング完全なプログラム同士なら出来るなんて当たり前なの
Re: (スコア:0)
> 大規模というのはチーム組んで取り掛かるような案件。とても銘々が他人の書いたコードの中身を
> 1行1行読んでいくことなど出来ないというような場合に、オブジェクト指向は役に立つ。
これがIT土方の限界か。
Re: (スコア:0)
オブジェクト指向設計に「しない」ほうが手間が増えるんですよ。
Re: (スコア:0)
> オブジェクト指向って基本的に「他人の作ったものを『安全簡単』に使いまわし」するのに便利な手法じゃないの？
違います。
オブジェクト指向は「データと、それを処理する関数群を、一体のもの（オブジェクト）として捉える」ということ。
継承もカプセル化も、それに付随するものでしかない。
calc_hoge(hoge);
print_hoge(hoge);
とするより、
hoge->calc();
hoge->print();
と捉え方を変換しましょうよ、ってだけのこと。
だから、規模とかは関係ないのです。
Re: (スコア:0)
違うのは、
君は「オブジェクト指向とは何か」を説明している。
私は「オブジェクト指向はなぜ必要とされるのか」を説明している。
というところだよ。
Re: (スコア:0)
「他人の作ったものを『安全簡単』に使いまわし」
これが本当に安全ならどんなに楽か・・
些細な改修の話が
継承しまくった肥大なobjectという何かの大元に
ちょっとした間違いがあったせいで
工数が莫大に増えた事なんて珍しくない
難易度までカプセル化しやがる
Re: (スコア:0)
オブジェクト指向をオブジェクト指向が必要とされるところ以外に使っちゃいけない理由もないです。
むしろ使ったほうが便利ならば使いましょう。
Re:C++の方こそお役御免では？ (スコア:1)
「他人の作ったものを『安全簡単』に使いまわし」
これが本当に安全ならどんなに楽か・・
低品質なコードはオブジェクト指向では救えません。
ちゃんとテストしてくださいとしか言いようがありません。
オブジェクト指向だと、オブジェクトを間違った使い方を「させない」ことができるから「安全」なのです。
間違った引数を受け取らない。外部からの不正な操作をさせない。これがカプセル化です。
オブジェクト指向が楽と言っている人は、このようなカプセル化はしていないんでしょう。
構造化プログラミングをオブジェクトで実現しているだけ。
Re: (スコア:0)
カプセル化するほうが「楽に」コーディングできるんです。
使用したいインスタンスがどんなパラメタを持っているか、パラメタは書き換えていいかどうかなどを使用する側が意識する必要がなくなるのですから。使用する側は、ただインスタンスにメッセージを投げればいいだけです。
Re:C++の方こそお役御免では？ (スコア:1)
publicスコープとprivateスコープの使い分け程度ならば、
オブジェクト指向というより、構造化プログラミングの範疇であり、
C言語でもよく使われる書き方です。
Re:C++の方こそお役御免では？ (スコア:1)
publicスコープとprivateスコープ
厳密にいえば、public、protected、private はスコープじゃなくて、アクセスコントロールなんだけど。つまり、親のプライベートは見られるけどアクセスできない。
Re: (スコア:0)
継承による差分プログラミングでオブジェクト指向が注目されたことがありましたが、前世紀中に否定的な結論が出てたと思います。
今は設計手法としてオブジェクト指向を活用しているところが多いのではないでしょうか。
Re: (スコア:0)
えーと、OS載せてないナマのCPUのプログラムを書こうとするとわかりますが、RAMが２Kbyteしかない、malloc から自分で実装しなければならない、ってのを相手にするとよくわかると思いますよ。ついでにROMが４Kbyteとかの制限もｗ
それでも、こうすればC＋＋でも書けるぢゃん、という屁理屈が返ってくるでしょーが、Cを使わなくてC++でないといけない理由、をかんがえてみましょう
Re: (スコア:0)
えーっと、最近は内蔵メモリも増えてフラッシュも安いので、そう言った開発の延長線上にそのままどっちも数十KB〜1MBくらいのリソースに余裕があるケースの方が増えてるんですよ。
そんな場合はmallocやらヒープやらをちゃんと実装して、効率よく実装とデバッグを進めた方が断然ラクですね。もちろんCでも問題ないし、例外・割り込みハンドラのトップハーフはアセンブラだったりしますが、その後はメンテのしやすさ・設計の分かりやすさでC++での実装になりますね。
ここら辺で一番めんどくさいのは、ヒープやライブラリアンの設定などの下回りはC/C++の言語仕様の外の世界の話になってしまって、開発環境ごとにマニュアル読んで個々に実装しなきゃならない事ですね。
個人的な印象では、この辺がよく理解出来ないので未だにprintfすら使えない環境だと言い張ってる人が多い感じですね… もうそんな時代じゃ無いんですが…
Re: (スコア:0)
> どっちも数十KB〜1MBくらいのリソースに余裕があるケースの方が増えてるんですよ。
そういうケースが増えてきたところで、そうでないケースも依然あることには変わりないんだが。
Re: (スコア:0)
逆に、C++を使わなくてCで書かないといけない理由も無いと思いますけど。
Re: (スコア:0)
いやまー、RAM2Kbyteでそれ言えるならなんも言いませんわ。
え？数メガ搭載してるCPU？だれがそんな話してるの？
Re: (スコア:0)
RAM2Kbyteで済む内容をC++で書けないとする理由がわかりません。
Re: (スコア:0)
結構前(20年弱昔)の話なんで今はどうかわからんけど、
リソースの制限が厳しい環境だと、専用のコンパイラが用意されてたりするんだけど、
そのコンパイラが C++ に対応していないってことが多かったよ。
対応していたとしても、例外に対応出来ないとか、template 使えないとか制限があったりしたよ。
あれから随分経ったけど、今はどんな感じなんだろか？
Re: (スコア:0)
C を使う環境って、大半がそうでないの？
C++ って潤沢なリソースがないと使えない。
Re: (スコア:0)
わたしたちのC++言語
Re: (スコア:0)
タイトルは "Death to C, ++" なので
"C++" は含まれてはないですね
Re: (スコア:0)
その、「リソースの厳しい組み込み向け」にRustは使えるって話なんだけどね。
Re: (スコア:0)
要求リソースが二桁違う [hatena.ne.jp]んじゃね？
Re: (スコア:0)
元タイトルは "Death to C, ++" なので別におかしくはないと思うが、
C++ではなく++と書くことでどういうニュアンスになってるのかはよく分からないな。
なお本文では普通にC++にも触れてるしC言語と同じ扱いされてる。
Re:C++の方こそお役御免では？ (スコア:1)
"Death to C" [techcrunch.com]の「続編」という意味で"++"が付いているのでしょう。
いずれにしても、本文にはC/C++の代わりにRustを使えと言っているので、
タイトルにC++が含まれているかどうかというのは些細な話だと思います。
Re: (スコア:0)
タレコミでは言及されてないですし
タレコミより前に取得されたアーカイブ [archive.fo]でもタイトルは同じなんで
hylomのせいでは