(9)
{希哲13年7月12日}{あれ}{希哲13年7月12日のツイスト}{++C}{ツイスト}{C++11}{C++}=}(7)

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

2019-07-13 00:10
=}
{++C}{C++}=}(2)
{希哲13年3月24日のツイスト}{希哲13年3月24日}{++C}{ツイスト}{C++}=}(5)

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

2019-03-25 00:11
=}
{希哲13年3月24日のツイスト}{希哲13年3月24日}{++C}{ツイスト}{C++}=}(5)

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

2019-03-25 00:00
=}
{希哲13年3月24日のツイスト}{希哲13年3月24日}{++C}{ツイスト}{C++}=}(5)

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

2019-03-24 23:52
=}
{++C}{C++}=}(2)
{++C}{希哲12年4月28日のツイスト}{希哲12年4月28日}{ツイスト}=}(4)

私は,C++03 以前と C++11 以後は別言語として扱うべき,と言っているのだが,やはり情報錯綜の原因になっているので,この前冗談混じりに使った「++C」を「早まった C++」の意で C++11 以後の別称として使ってみることにした。

2018-04-28 01:34
=}
{++C}=}(1)
{数値リテラルの桁区切り文字}{桁区切り文字}{++C}{C++ における桁区切り}{桁区切り}{新 C++ 批判}{新 C++}{技術}{公開}{C++}=}(10)

近年,迷走著しい論組〈プログラミング〉言語 C++数値リテラルの桁区切り記号が追加されている。新 C++ には長所も多いが,全体として C++ を破壊しているという印象が拭えない。その端的な兆候をこの桁区切り問題に見ることが出来る。

そもそも,言語に桁区切り記号を導入する必要などまったく無い。可読性のため,というが区切り方を間違えればかえって混乱を招くし,入力の手間も生じる。そんなことはエディタ側で対策すれば良い。例えば,数値の特定の桁に下線を入れて表示するという方法も考えられる。これなら環境側での調整も効くし,入力の手間を増やさず可読性を向上させることが出来る。

には「標準規約」という概念があり,その一部「表示規約」として推奨するコードの表示方法を定めているため,こうした対策を導入しやすい。

この手の標準仕様の追加は,容易に後戻り出来ないため慎重になってなり過ぎることはない。このひどい案を排除出来なかったというだけで,標準化委員会の機能不全を感じざるを得ない。

2016-10-11 14:35
=}