ログインしてさらにmixiを楽しもう

コメントを投稿して情報交換!
更新通知を受け取って、最新情報をゲット!

C++最強伝説コミュのでも、やっぱりC++が好き

  • mixiチェック
  • このエントリーをはてなブックマークに追加

最近、C++について深く議論したり考えたりした事
ないけど、以前から思っていることがあるのでトピ
作ってみます。(そもそも何年もプログラム書いて
いない・・・)
私がプログラムを書いていたのは、各社のコンパイ
ラーがまだtemplateをちゃんとサポートしていない
時代からG++がかなり安定してきた2000年頃までで
す。ですので時代遅れの話があったら指摘してもら
えるとありがたいです。

C++自体は結構至らぬところが沢山あるような気が
するけど、私はやっぱりC++が一番好きです。
なぜだろう?自分でコントロールできるからだろう
か?
というわけで、C++好きのコミュで反発買うかもし
れないけど、C++の良くないと思うところをいくつ
か書き連ねてみたいと思います。

(1) Interfaceという概念がない。
・これはJavaの方が優れていると思う点ですけど、
 C++だと抽象クラスを使う事がこれに該当するか
 と思います。
・逆に多重継承は要らないのではないでしょうか?

(2) Templateが複雑
・分かれば何とかなると思いますが、分かるまで
 は大分つらい。Templateを利用したクラスライ
 ブラリは結構スキルが身につかないと作れない
 のではないでしょうか?

(3) stringクラスが貧相
・C++には良いStringクラスがあまり無いような
 気がします。STLのstringクラスも機能が脆弱
 なので自前のクラスライブラリを使っています。
 (といっても自分で作ったものではありません
 が。)
・同じようなところで、正規表現クラスと日付
 クラスも標準的なものがないと思います。
 これらも自前のものを使っています。

(4) Reference Countクラスが無い
・最近の言語はリファーレンスカウントでオブ
 ジェクトで管理しているので安易にコレクション
 クラスでコピーとかを発生させてもオーバヘッド
 がほとんどなく処理する事ができますが、C++に
 はないので、自分でクラスライブラリをを作る
 か、ポインタで扱うかといった事をしないと効率
 的な処理を書けません。

(5) クラスを使う人には便利だけど、クラスを作る
 人には不便
・これは、STLとかを使う事で大分解消されてきて
 いるかと思います。

ここまで書いて何でC++が好きか分かってきました。
自助努力でほとんど解決できる問題ばかりでした。
誰か上記のようなところを解決するようなクラス
ライブラリをご存知でしたら教えてください。

コメント(12)

(1) Interfaceという概念がない。
・これはC++の方が優れていると思う点ですけど、
Java/.NETだとinterfaceを使うことがコレに該当するかと思います。
・逆に多重継承ができないのは非常に不便ではないでしょうか?

(2) Templateが複雑
・分かってしまえばこれほど便利なものはありません。Java/.NETのgenericsなど足元にも及ばぬ高機能。

(3) stringクラスが貧相
どこらへんが貧相なのでしょう?

(4) Reference Countクラスが無い
次期C++には採用されることになってるはず。

(5) クラスを使う人には便利だけど、クラスを作る
 人には不便
どこらへんが不便なのでしょう?
才能が乏しい側に立って発言してみます。
世の中に多いのは、こっち側の人達です。

(1) Interfaceという概念がない。
C++で抽象クラスにすると後任の人が、
抽象クラスに実装やメンバー変数を書き足して
設計を壊してしまう可能性があります。
Java/.NETのinterfaceにすれば、上のような状況は
言語仕様上において起こりません。

多重継承も設計力が在れば効果的でしょう。
設計力がないと無意識にダイヤモンド継承になってしまい
地獄を見ます。

(2) Templateが複雑
分かるまでが長いのです。お客は待ってくれません。

(3) stringクラスが貧相
「貧相」の根拠を予想出来ないな...
メモリ管理と絡むのかな?
STLは全般的にコンパイルエラーの内容が分かりにくいです。

(4) Reference Countクラスが無い
boostにはありましたっけ。
循環参照や相互参照を意識しないとメモリリークに
つながるので、仕事現場で妥当なのはJava/.NETの
メモリ管理方式だと思います。

(5) クラスを使う人には便利だけど、クラスを作る人には不便
まずは設計力が原因なのでJava/.NETでも言えます。

C++固有なのは、ポインタと実体を両方使える仕様。
知識があやふやな人はここでつまずきます。
ポインタのコピーなのか? 実体のコピーなのか? ってね。

こんなもんですかね?
当たってます?

※言語仕様の善し悪しは前提条件を
色々付けないと結論が出ませんね。
> 才能が乏しい側に立って発言してみます。

"才能"ってなんだ? って思う。

> 世の中に多いのは、こっち側の人達です。

その根拠は?

…いや、ケンカ売るつもりはありませんけども (^^

「ややこしいかも知れんけど、やりたいならやらせてあげよう」
てのがC++の基本思想ですし。

難解であることを悪だと言うならその通り、C++は悪です。
boostは良さそうですね。知りませんでした。

(1) Interface
・Interfaceというのと継承というのは意味が違うので
 ちゃんと概念的に分けた方が良いだろうと考えていま
 した。
・多重継承を使うべきという感覚にまだなったことは
 ないです。多重継承を使わざる負えなくなる場合は
 設計に問題があるのではないかと考えるようにして
 います。ちなみにinterface的利用の多重継承は良く
 使います。

(2) Template
・これについては皆さんの意見通りで特にコメントは
 ないです。

(3) string
・STLのstringクラスを想定して貧相な機能と言いました。
・JavaのStringで言うところのtrimとか、toUpperCase
とか、splitとか有りましたっけ?
・正規表現を扱うクラスライブラリが無いのも辛かった
 ですが、boostを使えば問題なさそうですね。

(4) Reference Count
・boost::shared_ptrは期待した機能に該当すると思いま
 す。auto_ptrは複数の参照先からの共有を前提にして
 いないと思いますのでちょっと期待したものと違いま
 す。
・元々この項目は実体コピーのオーバヘッドが無視でき
 ないようなオブジェクトのコンテナへの入れ替え等を
 想定していました。
・次期C++に含まれるというのはboostが採用されるとい
 うことでしょうか?

(5) クラスライブラリを作る人に不便
・これは良く考えたら言語の問題ではないですね。
 どの言語でも同じ議論があるような気がします。
> (1) Interface
>・Interfaceというのと継承というのは意味が違うので
> ちゃんと概念的に分けた方が良いだろうと考えていま
> した。

同意します。interfaceのないC++では抽象ベースクラスで代替できますが、多重継承のないJava/C#ではinterfaceがその代替にはならない(ってことはないが委譲せなならん)てことで。

>・多重継承を使うべきという感覚にまだなったことは
> ないです。多重継承を使わざる負えなくなる場合は
> 設計に問題があるのではないかと考えるようにして
> います。

なんもかんも自分で作るならわざわざ多重継承して地雷を踏むよな真似せんでええけども、既存のクラスを組み合わせるとなると多重継承は有難い。

> (3) string
>・STLのstringクラスを想定して貧相な機能と言いました。
>・JavaのStringで言うところのtrimとか、toUpperCase
> とか、splitとか有りましたっけ?

std::stringはそれ単体でリッチなメソッドを持ってるわけじゃなく、<algorithm>を適宜組み合わせて使うもんじゃないやろか。

>(4) Reference Count
>・次期C++に含まれるというのはboostが採用されるとい
> うことでしょうか?

boostの一部が次期C++のライブラリ候補となっています。
smart_pointerとか正規表現とか。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1745.pdf
なるほど、勉強になりました。
ありがとうございます。
>> (3) string
>>・STLのstringクラスを想定して貧相な機能と言いました。
>>・JavaのStringで言うところのtrimとか、toUpperCase
>> とか、splitとか有りましたっけ?
>
>std::stringはそれ単体でリッチなメソッドを
>持ってるわけじゃなく、<algorithm>を適宜組み合わせて
>使うもんじゃないやろか。
「文字列を操作するから、stringクラスにメソッドがあるだろう」
と連想する人も多いでしょう。

>> 才能が乏しい側に立って発言してみます。
>"才能"ってなんだ? って思う。
応用力とか想像力とかかな...
言語に限らないけど伸びるのが早い人っていますよ。

>> 世の中に多いのは、こっち側の人達です。
>その根拠は?
8:2の法則が根拠かな。
目的に向かって自力で模索出来る人が2割
2割の人に着いていくのが8割
>「文字列を操作するから、stringクラスにメソッドがあるだろう」
> と連想する人も多いでしょう。

そゆことでしょうかね。
stringは'文字列'というより、「終端記号('\0')の定義された要素の並び」の意味合いが強い。

>>"才能"ってなんだ? って思う。
> 応用力とか想像力とかかな...
> 言語に限らないけど伸びるのが早い人っていますよ。

わかります。あるいは'勘'あるいは'筋'かも知れんですね。
プログラミング言語をC言語時代から知っているか、
それともそれ以降から学び始めたのか、
によって視点が違ってくるため、かもしれませんね。

C言語からの流れで来ている人からすると、
現在のC++の仕様ってのは、恐らくごく自然な流れ、
自然な派生系としてあると思うのです。

けれどもハジメテ触れたプログラミング言語がJavaだったりすると
「えー。なんでstringクラスにこの機能ないのー?」
とか
「なんでinterfaceとかreference countとかないの?しょっぱいなぁー・・・。」
ってなる。

一番下のレベル、言語使用としてのレベルに、
そう言った概念が既にあった時代の人間にとって、C++は、
「東京」の如く、スッキリとしていない、
スマートじゃない形に見えるのかもしれません。
ビギナがいきなり始めるにはデカすぎる言語仕様ではあるでしょね。

あたしゃtemplateはおろか多重継承もない黎明期から付き合ってて、少しずつ大きくなってくのを体験してるからどーてことないけども。
インターフェースだの参照カウンタだの,あとはマルチスレッドとか正規表現などが,言語仕様レベルでサポートされていて欲しければ,そういう言語を使えばいいわけですよね。C++を参考にした(らしい)後発の言語たちは,まさにそのための選択肢として存在していて,それらを使えば目的は果たせるわけだし,そういう機能はC++に不要,というか,つけて欲しくないです。C++にそういう機能が付いたら,それはもうC++でなくなっちゃう。やっぱり,Cは構造化アセンブラだと思うし,C++はオブジェクト指向アセンブラだと思います。“バイトやビットやハードウェアの世界”とオブジェクト指向との融合としては,若干“やりすぎ”な感こそあれ,悪くはないんじゃないかと。

C++は複雑すぎるとか,見る人によっては,オブジェクト指向的に美しくないとか言うのかもしれませんが,そもそもの土台であるところの,アセンブリ言語の世界からして,複雑で美しくないわけで,よくもまあ,あんな荒れ地にオブジェクト指向を持ち込んだもんだと,呆れもし,また,敬服さえもします。

近頃の言語は,値型と参照型の扱いの統一性のなさに馴染めなかったりします。Rubyのように全てをオブジェクトにしてしまうという割り切り方もありだとは思いますが,C++の場合は逆で,演算子のオーバーロードやコピーコンストラクタを駆使して,クラスオブジェクトを値型的に扱えるように設計されているあたりが,病的なほどに素晴らしいと思います。

ところで,C#は別の意味でやりすぎで,難解路線まっしぐらな気配を感じます。去年のTechEdで卒倒しそうになりました。C#ってそのうちC++以上に理解しにくい言語になりはしないか心配ですよ。

ログインすると、みんなのコメントがもっと見れるよ

mixiユーザー
ログインしてコメントしよう!

C++最強伝説 更新情報

C++最強伝説のメンバーはこんなコミュニティにも参加しています

星印の数は、共通して参加しているメンバーが多いほど増えます。