C++は難しすぎ 難易度:2

理解できないわけないだろ！
デザパタも知らずにC++使いの質を下げるC厨には げんあり

前スレ達
難易度:1 http://pc2.2ch.net/tech/kako/1058/10586/1058675178.html
難易度:2 1http://pc2.2ch.net/test/read.cgi/tech/1063323615/

24歳ですべて悟りました。
天才だから。

難易度が上がっていないという驚愕の事実。

スレ建ては難しすぎ

十数年前はチーズバーガーが１個２３０円だった。
それが、ついこの間まで１個８８円で売っていた。
これはつまり、その気になれば１個８８円で売れたモノを２３０円で売ってた訳だ。
その昔に１個２３０円で食ってたオレに言わせれば全く腹の立つ話だ。

>>5
MZ-5500 の拡張メモリボード (256KByte) を
\72,000 で買った俺にしては（ｒｙ

チーズバーガーもメモリも十年前は今とは段違いにコストがかかったんだよ。

>>7
メモリは間違いなくそうだが、チーズバーガーのコストはあまり変わってなさそう。

>>8
品種改良による大量生産、輸送コストの削減。
加工食品の調達コスト削減、等々。

>>9
中国産農産物の輸入拡大。多分これが一番大きい。

「げんあり」は継承したんだ…

吉牛が290で食えたときには(ry

>>3 >>4
出勤直前で焦っていた。
正直すまんかった。

　 ∧＿∧
　（　´∀｀）

>>8
１０年前の牛肉１００％ ＞ 牛から食える肉を切り出したものが１００％
現在の牛肉１００％ ＞ 牛は１００％肉として使う

>>13
つかそれ以前に

　　糞　ス　レ　勃　て　て　ん　じ　ゃ　ね　え　よ　脳　挫　傷　！

例えば、C++をオブジェクト指向の入門に使用すると、まず突き当たるのはその言語仕様の複雑さです。
C++は手続き指向の言語であるCとの互換性を保つことを強いられたので、オブジェクト指向の本質とは
あまり関係のない部分が多く言語仕様に入り込み、習得のし難い言語になってしまっています。
(このように手続き指向をオブジェクト指向に拡張し、両者の概念の混在する言語をハイブリッド系OO言語
といいます)。またC++のようなハイブリッド系言語は、手続き指向でのプログラム作成が全く問題なく行え
てしまうので、「C++を使用しているが、オブジェクト指向になっていない(ただのCプログラミングをしている)」
ということが起こってしまいます。

更に、なんとかC++を使いオブジェクト指向の考えでプログラミングできるようになったとしても、言語の性質上、
メモリ管理の問題が常につきまとうことになります。もともとオブジェクト指向は、システムにまつわる問題を抽
象的に捉えられるところに利点があり、メモリ管理といった低レベルの部分はなるべく気にせずに、アプリケー
ションドメインといった上位の概念に注目したいはずです。C++ではメモリ管理をみずから行わなければならな
いため、アプリケーションに本質的な処理と、単なるメモリ管理の処理が入り交じり、

コード自体を非常にわか
りにくくする側面があります。また人間の手によるメモリ管理は、必ずといっていいほどメモリリーク現象を引き
起こします。このために、「あまり多くのオブジェクトを用意しないようにしよう」という考えが働くようになり、設計
上は分離されていたはずのクラスが実装時に安易に合成され、奇麗なオブジェクト指向設計をくずしてしまうこ
ともあります。

一方Javaはどうでしょうか。Javaはかなり奇麗にオブジェクト指向の考えを実現しているといえますが、
数値や配列などの「基本データ型」はオブジェクトではありません。そのために「全てを統一的にオブジェ
クトとして扱えるはず」というオブジェクト指向の原則に合致せず、やはり不自然なコードを書かねばなら
ない場面がでてきます。
例としてJavaでは、「何でも入れてしまえる順番つきの入れ物」を表すのに、Vectorというクラスが用意
されています。このVectorに物をいれるときに、基本データ型が混ざっていると以下のようなコードを強
いられます。

いいこと言うね〜　禿同だよ

>>18
出たなデザインパターン。プロジェクトの中で３人知ってる人間がいたら良い方だよ。
残りの雑魚は家に帰っても酒呑むかＴＶ見てるかくらいの奴だし。
勤勉な奴は一握りだぞ？２０代でそういうやつは極小。３０代で技術しか取り柄のない奴が
逃げ道としてデザインパターンなんかを習得してる。悪いってわけじゃないけど、
３０代が技術にすがるって、見ていて悲しくなるよね。

>>18
そ　こ　で

C#

だ！

感じて デジャヴ

>17-18
いまどき Vector型 は使わないね。
なんかのコピペかな。

それに必ずしも「完全に」オブジェクト化してれば
いいもんっていうものでもないよ。
原始型はラップすればいいだけだし。

Integer int1 = new Integer(123);
Integer int2 = new Integer(456);
int1.add(int2.getValue());

なんてやるより

int i1 = 123;
int i2 = 456;
i1 += i2;

ってやった方が楽だし分かり易いでしょ？

>>22
だから、３０歳過ぎて、社会の政治的な要因に太刀打ちできるような
立場になってからもデザインパターンみたいな一技術で重宝されるような
人物に対して「逃げ道だよな」って言ってるの。２０代の奴がやりたくてもできないような
ところで自分をアピールする術を持ってないのかって。
中堅者のやることっていったら、２０代の奴が仕事をしやすいように、いろいろと根回しすることだろ？
年齢重ねても、やることが２０代の延長だったら会社に居る意味ねーよ。
スパゲティコードだとか、その辺は中堅社員が口出すことじゃねーって。
むしろ、２０代の奴が気付いて、中堅社員に意見をＵＰして、それから中堅社員が根回しするのが理想。
要は、いい歳こいて低レベルな話してんじゃねーよって。もっと抽象的になれってことだ。

>>24
何で俺にｗ

>24
俺か？ｗ
まだ２７なんだけどな。

つーかデザインパターン云々いってる
話はどこからきたわけ？？

>>25-26
前スレのコピペだよ。
単なるあげ荒氏だから反応するな。

>>21
プップップ
残念ながら>>17-18のコメントはSmalltalk解説サイトの前文なのだ(藁
VB厨のようなM$の奴隷の雑魚どもが使う言語C#ごときに出る幕は無い(藁

>>18
>また人間の手によるメモリ管理は、必ずといっていいほどメモリリーク現象を
　　　　　　　　　　　　　　　　　　　　　　￣￣￣￣￣￣￣￣￣
>引き起こします。

書いた奴が、自分の間抜けっぷりを隠す為に
一般化しようとしているとしか思えない。

メモリリークを強調するのって
新言語をC++と比較するときの常套手段だよね。
Cならいざ知らず、C++を然るべき使い方すれば
メモリリークなんて滅多に起こさないと思うが。

ポインタに相当するものがあるなら、必ずメモリリークするよ

メモリリークするようなコードを書いちゃう人は、
どんなに管理手法を凝らしてもリークさせちゃう。

たとえばGCなんてその注意をほんのちょっと減らすだけでしかない。
にもかかわらず大げさに取り上げたがるのは、
表面的なところにとらわれてるか、初心者かのどっちかだろうねえ。

>>29
> >>18
> >また人間の手によるメモリ管理は、必ずといっていいほどメモリリーク現象を
> 　　　　　　　　　　　　　　　　　　　　　　￣￣￣￣￣￣￣￣￣
> >引き起こします。
>
> 書いた奴が、自分の間抜けっぷりを隠す為に
> 一般化しようとしているとしか思えない。
ではお前は間抜けなことをせずに間違いを一切犯さずに
超超！超！超！超！超！！大規模アプリ開発で
ポインタ演算をべらぼーに徹底的に使い切ってコーディングできるか？

お前には無理だ。それは、お前が人間だからだ。

>>30
それがしかるべき使い方をする香具師がほとんどいないんだからねえ。

速度を強調するにはどうしても避けられない問題につきあたるわけよ

> 超超！超！超！超！超！！大規模アプリ開発で
> ポインタ演算をべらぼーに徹底的に使い切ってコーディングできるか？

できるよ。

規模が大きかろうが小さかろうが、
しかるべきサイズのモジュールやコンポーネントに分割して開発するだろ。

この「しかるべきサイズ」の条件として、「ポインタが安全に使える」
というのがあるだけの話。さらに言うなら、条件の一つでしかないし、
それほど重要じゃない。

C#はいまだにポインタ型が使えるんだが、
あれはどぅだ？

っていうかおまえらC++じゃなくてCのポインタをイメージ
してないか？Cのポインタは怖い。キャストとか特に。
C++だとauto_ptrやクラスでラップできるしね。

で、普段C++な俺がCでWinドライバ作成してるわけだが、
緊張感が違うな(w

>>36
こわがりすぎー

>>27
いや、分かってるがﾜﾛﾀ

メモリーリークってJavaだってたいしてかわらんだろ？
使えるだけ使いまくって足りなくなったらいらない
メモリを開放してるんだから。

まぁ、要するにJavaはメモリ食い杉。

GCがあったってリークさせるやつはさせるさ。

リークを完全になくすには例外安全を貫く必要がある。
過剰な例外安全の保証を行うと、性能面でのC++のメリットがなくなる。
そのあたりのトレードオフの存在が、C++のいいところでもあり悪いところでもある。

>>36
緊張感が違えば十分だが
Cのソースのメンテの場合などは
あきらめでいっぱいになる事もある。

C++は列挙型なんて時代遅れのものがついてる欠陥品

おまえらマジでC言語のポインタで挫折したの？

abc.exeという実行ファイルがあったとして
この実行ファイルの引数がどうなっているか調べる方法はありますでしょうか？
もしくはそれがわかるソフトでもかまいません。
よろしくお願いします。

リファレンス(T&)渡しを的確に使用している奴はいるのか。
ポインタ渡しを使った場合と効果は同じだけど、
引数で渡すデータを変更しない場合は、リファレンスを使い、
値を変更する場合はポインタを使うようにしているのだが、
それ以外で適切な使い方を知っている猛者はご教授願いたい。
（コピーコンストラクタやoperator関数の引数ってのはなしで。）

>>45
中学生。

>>45
たとえばあるオブジェクトを指すクラスを作るときで、
そのオブジェクトをコンストラクタ以外では指定できないようにしたいとき、
参照型のメンバ変数とすることがとても有効な場合がある。

適切、かどうかは判断しがたいが
templateをぽちぽちいじるようになれば、リファレンスは避けて通れなくなる。
いちいちポインタを要求するtemplateってのは使いづらいからね。

>>45
More Effective C++でも嫁

>>45
>引数で渡すデータを変更しない場合は、リファレンスを使い、

変更するかしないかはconstの有無で判断するもんだと思う。
ポインタでもリファレンスでも。

てかこのスレの住民は(>>48以外？)モダーン本も読んでないのか？

TypeTraitsで適切な引数型を自動的に検索できるのは
参照型のシンタックスがコピー渡しと同じだからだろうが。

テンプレート関係の勉強をしようにも、
頭が悪いので理解できない。

初心者用の本だとスタッククラスに対して、
int型やchar型をテンプレート引数にとる簡単な例ばかりで、
応用例は、ほとんど載ってない。

標準ライブラリとテンプレートのからみを説明している本は、
中級者以上の本ばかりなので、難しくて理解できない。
（特にsetやlistテンプレートの実装部分とかの説明が理解不能）

この辺のからみについて、何かわかりやすい本or
最適な勉強法はあるのでしょうか。

>>52
ttp://www.amazon.co.jp/exec/obidos/ASIN/0201734842/
試しにこれ読んでみれ。

俺はlistやhashtableを実装(再発明)したよ。
lokiやboostのコードを読み漁りながらだったんだけど、
type traitsやfunctionalなんかが中心だったかなあ。
カナーリ勉強になったよ。

「JavaプログラマーのためのC++」ってないかね。
JavaのStringやVectorと対比させてSTLを教えてほしい。
newとdeleteの管理をちゃんとやるための設計のしかたとか。

newとdeleteの管理すらできないうちからSTLに手を出したりするから
C++がわからなくなる。
テンプレート(機能)は鬼門なので他が十分に理解できるまでとっておく。
STL(ライブラリ)はもっと鬼門なのでテンプレートが十分に理解できるまでとっておく。

あとは車輪の再発明はC++の学習には欠かせない要素。
自分で作ってはじめて理解できる。それがC++。

読む→試す→作る→だから身につく

どこかで見たことあるモンクだと思ったら…


そんなにこわがることないのにー ;-p

>>56
STL(あるいはその再発明)を使わなけりゃ例外安全な
deleteの管理なんて出来ないだろうが。

>>59
そんなことはないない

出来ないというか、やる気はせんな。

>>59
auto_ptrはSTLじゃありませんが何か？

やっぱり安全なdeleteの管理はできそうもないな。
なぜならauto_ptrはSTLだからね。

GNU関係のプログラム書いてたら99%はANSI Cだから素のポインタ操作も
最初は苦しむが慣れたら明確かつ究極的なインタフェースとして使えるよ。
サーバ系で一リクエストに何千回も処理する箇所があればオブジェクト指向系
の糞重い&メモリ食いな処理は命取りになる。
そういう時にポインタでデータをきちきちに詰める。
1バイト単位できっちり。
JAVAやC#みたいなインタプリタと違って最適化やVMも必要ないから
十分なパフォーマンスが得れる。
だが熟成には何年何ヶ月と要するよね。
適材適所があるわけだから一概にC++はダメって言い切るのはどうなのかな？

C# はインタープリタじゃないわけだが。
Java も最近 JIT 方式のものがあったりするし。

揚げ足取りスマソ。

やっぱし　テンプレートは理解しておいた方がいいのかなぁ。
難しい..

>>66
最低限、STL のコンテナが使えれば OK だと思う。
それが出来たら Modern C++ Design でも読みつつ Loki の内容理解とか。

>67
了解。頑張ります。

.NET自体がおおざっぱに捉えてインタプリタだと思うんだが。

>>69
修行が足りん 出直してこい

>>70
C#とかJAVAって386コード吐けるんですか？

>>71
JIT コンパイルで検索しる。

>>67
テンプレートは
template< typename T >くらいなら分かるけど、
template< int n >とか見てボカーンでした。

あと、
template<class T> class shared_ptr
{
（略）
template<class Y>
explicit shared_ptr(Y * p): px(p), pn(p, checked_deleter<Y>()) // Y must be complete
{
detail::sp_enable_shared_from_this(p, p, pn);
}

も全然理解できません。
template<class Y>って・・・・
shared_ptrってTのポインタを抱えるクラスだと思うけど
どうしてYが出てくるのやら・・・

いい解説ページか本はないでしょうか。

それどころか、Modern C++ Designの表紙をめくったところで

template<int m1, int l1, int t1, int m2, int l2, int t2>
Physical<m1+m2, l1+l2, t1+t2> operator*(Physical<m1,l1,t1> lhs
　　　　　　　　　　　　　　　　　　　　　Physical<m2,l2,t2> rhs )
{
　　return Physical<m1+m2, l1+l2, t1+t2>::unit*lhs.value()*rhs.value();
}

がいったいなんのことやら、と。

＞いい解説ページか本
Modern C++ design しかない！

>>74
そのテンプレートはModern本を読み進めて行かなければ
ほぼ理解不能だと思われる。
loki風のテンプレートの用法に慣れちゃえば
極めて普段どおりのやり方になるので、まずはModernの読破を。

>>73
shared_ptr の コンストラクタにある、template< class Y > は、

shared_ptr< void* >( new Object() ); とかやっても
きちんと Object のデストラクタを呼び出すための仕掛け。

大雑把に書くと以下のようなコード。

struct deleter_base
{
　virtual void destroy() = 0;
　virtual ~deleter_base(){}
};
template< class T > struct deleter : public deleter_base
{
　deleter( T * p ) : p_(p)
　void destroy() { checked_delete( p_ ); }
　T * p_;
};
struct shared_count
{
　template< typename Y >
　shared_count( Y * p ) : pd_( new deleter<Y>( p ) ) ... { ... }
　// カウンタが 0 を示したときに pd_->destroy を呼ぶような処理
　//　これで、Y は正しく delete される。
　deleter_base * pd_;
};

みたいなの。

templateをしっかり学習したければHaskellを
覚える事をお勧めする。

>>77
TypeListを処理するのに再帰を使用するとかが
関数型言語っぽいっていう理解はＯＫ？
その他、あれば解説よろしく

>>78
アダプタとか関数オブジェクト廻りの技術が関数型っぽい。
あと演算子のオーバーロードも関連も型クラスとの関連が。
後、boostとかだとそのままずばりlambdaがある。

まだ勉強中なんでツッコミ歓迎。

C++のtemplateとかoperatorって>>73,76みたいな
「きちんと面倒見るためにはそこまでしなきゃ(考えなきゃ)いけないのかよ」
ていうのが実務上嫌いなんだが、反面そこが趣味的には面白かったりする。
やっぱり簡単な使い方以外のC++はヲタク用言語という感じがぬぐえない。

で、ちょっと質問。
ランダムアクセス可能なiteratorで出力を加工することは可能かどうか。

template< class T > my_iterator {
private: T * current;
public: T & operator*(){ return *current; }
};

関係の無いところを端折ると上のように書いているんだが、例えば

public: T & operator*(){ return 1 + *current; }

は戻り値がT&だから出来ない。かといって戻り値をTにすると代入が出来ない気がする。

>>80
すぐ考え付くのは、

template <class T> my_iterator {
private:
    T * currrent;
    struct T_ref {
        T_ref(T &r) : ref(r){}
        operator T() {return ref + 1;}
        template <typename U>
        T_ref &operator=(const U &u) {ref = u; return *this;}
        T &ref;
    };
public:
    T &operator*() {return T_ref(*current);}
};

色々問題がありそうだが。

>>81
operator T()なんて使い方が出来るのか。サンクス。
ただ加工に使う「+ 1」の値がmy_iteratorに入ってると
T_refのメンバにmy_iteratorへの参照も入れなくちゃいけなくて複雑になりそうだな。

そもそも加工をoperatorに頼っちゃいけないのだろうか。

プロキシオブジェクト使わないと厄介なところだな。
「参照じゃないと書き換えられない」みたいな問題は
More Effective C++（だっけ）の二重配列クラスの実装なんか
まさしく参考になると思う。

>>76
補足すると、継承したクラスのポインタに対応するため｡
>>80
boost::transform_iteratorがおすすめ。
自分で書きたければ、
T& operator*()と
T operator*() constを定義する方法もあると思う｡

>>76
補足すると、継承したクラスのポインタに対応するため｡
>>80
boost::transform_iteratorがおすすめ。
自分で書きたければ、
T& operator*()と
T operator*() constを定義する方法もあると思う｡

http://hp.vector.co.jp/authors/VA000092/jokes/strup.html

「C++は難しすぎ」 byコンパイラメーカ一同

コンパイラ屋さんってC++コンパイラを書くときに言語は何を使ってるんですかね？
Cなのかな？C++なのかな？
Cだと大変そうですね。

最初のC++はCに変換するプログラムで、Cで書かれていたそうだ。
最初のCはアセンブラで書いたそうだ。
最初のアセンブラは機械語で書かれた。バイトコードに直すのは人力でやった。

最近の商用のは知らんが、ほとんどCで書かれているんじゃないか？

“yacc”とか“コンパイラコンパイラ”でぐぐれ。

まともなエラー処理を書こうと思ったらyaccじゃ無理だろ。

まあ、yaccはあくまでコンパイラ作成を支援するものだし。

じゃあなんでコンパイラ・コンパイラなんて大仰な名前がついてるんだ？

http://pc2.2ch.net/test/read.cgi/tech/1070089173/

続きはこちらでどうぞ。

>>75,76,77

急に忙しくなってレスが遅れましたが、参考になりました。
ありがとうございます。

ｸﾞｺﾞｺﾞｺﾞｺﾞｺﾞ!!!

いまこそ、プログラマ革命を起こすときだ！
（亜ぼーんする愚か者には核ミサイル無量大数本分の死を！）

　〜　自称C++厨の化けの皮をはがせ！運動展開中！　〜　
(本当は自称C++厨なんてたいしたことがない、上辺だけなのだ！　真実を見よ！)
大半のC++厨はインチキ詐欺師の卑怯者！
オブジェクト指向も知らなければデザインパターンも知らない悪い奴である。
しかも悪名高いウォータフォール信者と来た！　許せん！　今こそ正義の一撃を！
大半のC++厨は汚いコードを書いてチームをわざと混乱させメンテナンスの手間を増大させる悪魔なのだ！
大半のC++厨は自己保守的で官僚的で革新性が無く
自分のスキルの程度を誤魔化すためにわざとソースコードを読みにくくしているのだ！
(こいつらはわざと読みにくくすれば他人が解読するのにに手間がかかるので
凄いと思いこまれると勘違いしている馬鹿どもなのだ)

こんな卑怯者が許されるか！

蓋を開けてみればただのＣ言語しかできないとんでもない低脳である。

こんな悪魔のような給料泥棒なやつが金をもらっていることは絶対に許されるべきではない！
即刻減給するかクビにしてやるべきである！

このような卑怯なC++厨の行為は宣戦布告と見なさなければならない行為であり
大義名分を持って即刻解雇すべきである！

自称C++厨の化けの皮をはがせ！　自称C++厨の化けの皮をはがせ！
自称C++厨の化けの皮をはがせ！　自称C++厨の化けの皮をはがせ！
自称C++厨の化けの皮をはがせ！　自称C++厨の化けの皮をはがせ！


正義は勝つ！悪の枢軸・自称C++プログラマをこの世から抹殺せよ！

>>96
暴れるのはマ板だけにしとけ知的障害者。

>>96
ただのＣ言語すらできないヒトは どうすればいいですか？

>>98
それは俺様のことか？

>>98
(ﾟДﾟ)

>>99
そうだ

>>96
おまえもHaskelとかScheme勉強しろよ。

HaskelやSchemeを勉強しても仕事の役に立つとは思えない

デザインパターン勉強しても仕事の役立つとはおもえない。

Modern C++ Designが仕事の役に立つとは思えない。

仕事が俺の役に立つとは思えない。

松戸ナルドがおいしいとは思えない。

松戸にもマクドナルドがあったのか

イノセンス、それは　いのき

土佐、それは高知

北関東の県が必要だとは思えない。

>>110
群馬 栃木 茨城というわかりやすい駄目トリオがなくなると、
神奈川 埼玉 千葉のどんぐりの背くらべトリオによる
No2争いが激化する。

横浜＞神奈川
ディズニーランド＞千葉
さいたま＞埼玉

>>107
あるよ。まんまえに。いってみ

テムプレートってどういうときに使うんでつか？
難しすぎて頭がおかしくなります。
たとえば１から１００まで足すプログラムに使いませんよね？

使えますが

#include <iostream>
template <int n> struct Sum {
enum { X = Sum<n-1>::X + n };
};

template<> struct Sum<1> {
enum { X = 1 };
};

int main()
{
std::cout << Sum<100>::X;
return 0;
}

>>2
15歳ですべて悟った俺は変人でしょうか

テンプレートを使いこなしたかったら Modern C++ Design を読むべし、そうしなければ全く始まらない。
テンプレートはOOその他従来のパラダイムのように、プログラムを書くための物ではない(もちろん使えるが、そういうやり方は古いやり方)
Modernなテンプレートプログラムとは、プログラムを生成するプログラムを書くのだ。
例えばデザインパターンのパターンを見て、そのパターンを実装するのが従来のやり方。
テンプレートを使う場合は、そのパターンを生成するプログラムを書くのだ。
一つ上のステージからプログラムを見下ろす様にプログラムをするんだ。

>>115-116
それは１から１００まで足すプログラムというより、
１から１００まで足してある数値を取り出すプログラムでは？

実行時に足すかコンパイル時に足すかの違いでしかない。

コンパイラに足させるプログラム

template<int i> class sum
{
public:
int operator() {
return i + sum<i - 1>()();
}
};

template<> class sum<1>
{
public:
int operator() {
return 1;
}
};

じゃあこうすれば良いのか

>>122
オプティマイズがかかったらやっぱりコンパイル時に足していそうだな(藁

オプティマイズは考えなくていいんじゃないか？
設定やコンパイラによっても違うし。

コンパイル時に計算させるか、実行時に計算させるかの意図がコードに現れてればいいんじゃないかな。

どうしてもというのなら

template<int i> class sum
{
volatile int v;
public:
sum() : v(i) { }
int operator() {
return v + sum<v - 1>()();
}
};

sum<i - 1>()();

こうじゃなきゃだめだな

おまいら >>114 の質問に答えてないよ。

「使いませんよね？」と聞いているのに、「使える」という答えはおかしい。
いつもそうゆうコードを書くかどうかを聞いているので、可能不可能を聞いているのではない。

漏れの答えは、そんなことには多分使わない。

どうでもいいけど、
int operator() {
の宣言は、
int operator()() {
でないとコンパイル通らなくないか？

勘違いだったらｽﾏｿ

yes

>>127
どう使うかって事にもよるね、例えばその計算結果から型を選択するとかいった処理なら
テンプレートを使うしかないし・・・
最近はJavaやC#の場合、リフレクションとかもあるので無茶な事をすれば実行時にもできるかもしれんが、余りやりたくは無いねぇ。

リフレクションいいよね。

Ｃ＋＋で実現したいんだけど、どっかに参考になるコードないかなぁ。

むかーしリフレクションっぽいコードをC++で書いた。
お前のコードじゃねえだろどこで派食ったといわれて結構へこんだ。
まああれだ、スマートに書くか効率良く書くかの二者択一になるからやめとけ。

C++厨のレベルの低さが垣間見えるスレですね

これからなんだよ、まだこれからこのスレはすんげぇ面白くなるんだよきっと。
きっと1さんがこのスレを優良スレにしてくれるんだよ。
1さんがこのスレを名スレにしてくれるんだよ。
1さんが素晴らしいネタを提供してくれるんだよ。
だからみんな、これからの1さんの書き込みを楽しみにしようよ。
これからこれからこれからこれからまだまだまだまだ…

1さんって俺じゃねーか。おまえらまだスレの連番付け間違えた事チマチマ恨んでるのか？
でもせっかくだから盛り上げていくか？

>>133
а≧○иξ⊃ＸγΘ△Φ？

>>135
a=＄д゜【＠（）πr2+3.14

>>136
Пкδ＼Δν⊃∃ю！

>>114
『Effective C++』の41項参照。

例えばWin32の各種ハンドル型をデストラクタでクローズするラッパクラスを作るときに使った。
型は違う（HANDLE・HINTERNET・SC_HANDLEなど）。でも処理は同じ（最後にクローズする）。

『Modern C++ Design』の書き方を許してくれる職場は少ないと思う。
理解できる人間がいなくてメンテナンス性が下がるため。（理解さえできていれば本当は上がってるんだけどね。）
そういうときは仕方ないので宣言マクロ／実装マクロにする。それなら理解できる人も多い。

あとは標準ライブラリのコレクションを使えないときに（車輪を再発明するために）使った。
このときはメモリの動的確保をしないという制限があった。
（Allocatorを書く方法もあるが、上と同じ理由でそれが許されることは少ないと思う。）

>Allocatorを書く方法もあるが、上と同じ理由でそれが許されることは少ない
随分厳しいですな

もうちょっと分りやすい構造になればいいんですがね > template
漏れはもう boost から戻れない体になってしまいました。

三大悪の枢軸国の紹介
　C++帝國(北朝鮮)　← C++厨代表の正体は、何と！　金正日だった！
　VB帝國(イラン)　←　VB厨代表はイランに潜伏していいた！
　Perl帝國(イラク)　← Perl厨代表フセインがついに逮捕された！

>>140
C++が分らなくて火病でも起こしたか？

Java帝国(オウム) ← Java厨代表は何と！地図夫(趣味:ソフマップ通い)だった！

鯖削除は難しすぎ

Modern C++ Designって簡単なことしか書いてないのにね。
それを難しいというのはよほどの馬鹿なんだろうね。
そんな馬鹿がソフトウェア開発にたずさわるのは社会的な悪だね。
医者だと無免許医は摘発されるのに
自動車だと無免許運転は摘発されるのに
プログラマーだけ低能でもやっていけるというのが諸悪の根源。

C++難しいとかいう脳障害の低能は
そもそもプログラミングに向いてないんだから
とっとと転職しろっつーの。

＞プログラマーだけ低能でもやっていけるというのが諸悪の根源。
大工よりまし。

>>144
> 医者だと無免許医は摘発されるのに
> 自動車だと無免許運転は摘発されるのに
ま、低能が免許持ちまくりなんだけどな、どっちも。

確かに免許制にして一定水準以上の者でないと開発に関われないとしてもいいかな。

その方が学ぶ側も採用する側も分かりやすくていいと思う。

>>146
なんなら私が手術してあげましょうか？

C++は難しくないけどC++厨はオナニーしすぎ

またわけのわかんないレスが来たな

難しいかどうかなんて問題じゃないんだ。
問題は出来るか出来ないかだろ？
ま、簡単だと言ってる奴ほど実は何も出来ない
というのはよくあるけどな。

ペーパードライバーならぬペーパープログラマーだな

呼んだ？

普通、電気系のエンジニアはソフト"も"書けるがソフト屋はソフト"しか"書けないんだろ？
ちゃんちゃらおかしいね。それでもエンジニアか？あぁ？
ソフトぐらい文系あがりのねぇちゃんでも書くぜ。
人生の敗北者が下る職業
タクシー運転手，塾の講師，ソフト屋
だろ？

↓アビバ資格者

>>154 は、あまり難しいコードを見たことがないそうです。

ここで俺の登場！！！

と言われても…どちら様？

そのおかたをどなたとこころえる！？

1ですね。

http://page4.auctions.yahoo.co.jp/jp/auction/d47227135

OL５０人

難しいプログラムならバカでも書ける。
いかにサボり、楽をするために間単に書くかが私の人生のスタンスと一致していてすばらしい。

>>147
学生さん？
現場じゃそんな子と逝ってられませんよ？

C++はメモリ管理機構がないからムズカシイとかよく言われるけど、
言語側が暗黙のうちにGC用意してくれるよりもライブラリとして用意されるべきなんじゃないかな
と最近思うんだけどどうなんだろ。
影でこそこそ処理されると気持ち悪い。

ライブラリとして、だと
「わざわざ使わないといけない」だから
面倒な人間は何をしてくれるか予想がつかない。

つかjava使ってて思ったのが

＿|￣|○　＜　頼むから、俺にメモリ解放処理をさせてくれ

だった。

これからコンパイル後がどうなるかなんて何も考えずに、やらせたい処理だけ
便利なAPI使って記述すればいいって時代が到来するんだろうな。
低レベルな処理なんて組み込みだけ・・なんてことになるのかなぁ。
C++でﾊｧﾊｧする奴にとってはツマラナイ世界かも。

メモリ管理を自分でしないと気持ち悪いって人はあれかな、
実生活でもマメに掃除とかする香具師？

俺みたいに部屋は散らかし放題で
極限まで汚れたら渋々掃除するタイプはダメだ。
取ったメモリの解放まで面倒見てらんねえ。

>>169
漏れの場合，部屋は散らかりまくりだがヒープは絶対片付ける．

俺は後々片付けるのが嫌で
物理的な参考書とか資料とか極力本棚から持ち出さない人。

散らかっているかどうかよりもむしろ、物の位置や処遇が
「自分の手の内に入って」いないと気が済まないかどうか、に近い気が。

>>165
＞影でこそこそ処理されると気持ち悪い。
高級言語は、多かれ少なかれどこか影でこそこそやってます。
本当にそれが嫌なら、アセンブラで組めｗ

>>173
そうとも限らないだろ。

>>174
どういうところが限らないんですか？
内容無しの反論なら誰でも出来ます。

>>175
＞高級言語は、多かれ少なかれどこか影でこそこそやってます。
証明できないからじゃない？

>>175
「高級言語では」何が「影でこそこそ」に当たるの？

たとえばa = b + c * d; が
tmp = c * d;
a = b + tmp;
とかに分解される事？

マクロアセンブラでも、
ラベルがアドレスに展開されたりする事は
影でこそこそに当たらないの？

たとえば、Cでは何が影でこそこそしてる？Pascalでは？
どっちも高級言語じゃないのか、スマンな。

>>177
GCの話じゃねーのか？

言語が高級になればなるほど、コンピュータがやってくれることが増えるってだけだろ。
コンピュータは元から人間の手間を省く道具。だからそれは自然なこと。
それが嫌いならアセンブラ（よりも機械語のほうがいいか？）を使えってことだろ。

>>178-179
影でこそこそが気持ち悪いって言う人間に
考えもなしにアセンブラで組めなんていう煽りを何のするなということだ。
177で正論ぶってるから、更に気になっただけだ。

×考えもなしにアセンブラで組めなんていう煽りを何のするなということだ。
○何の考えもなしにアセンブラで組めなんていう煽りをするなということだ。

編集ミスった。

×177
○175

、、、orz

アセンブラは全く知らないんだけどメモリ解放はどうするの？
やはりプログラマによる手動解放？

>>183
mallocに相当するコード自分で買い解け

brkとかHeapAllocとかOS提供のAPIを呼ぶ
あとは、cのライブラリをリンクするとか。

C++を覚えるっつーか、使いこなすレベルになるころには
管理職をやらされるのが日本のコンピューター業界。
そして新人は今日もまたメモリリークしまくりのコードを量産する。

>>186
年取ると新しい考え方を受け入れられくなったり、徹夜の仕事
がとても続けられなくなるからそれでいいのよ。

>>187
若い頃から徹夜仕事しなかったし、この歳になっても睡眠時間3時間ですが何か。
あーでも、役職はついてるし部下もいるなぁ。

>>188
過労死すんなよｗ

過労死しそうな人が出るほど C++は難しすぎ

>>190
激しく同意

c++の何が難しいのかがわからない。
難しいこともできるって話じゃないのか？

俺的にはVBの方が難しい（めんどい）ような
あと、パールとかはキャストがきもい。

Perlのキャスト？

俺も、Javaや、VBのほうが、よっぽど難しい。

>>193
いや、だいぶ前にちょろっとやっただけだからうろ覚えだが、
c++なら明示的にキャストして、キャストできないようならコンパイル時にエラーでるしょ？
パールって何でもかんでも、暗黙的に型変換してるイメージあって、怖い。

perlがCGIの筆頭であり続けるのは、そのきもいキャストのおかげなのだが。

perlに型はありませんよ

コード中に型宣言が無いだけで実行時にはどの言語には型判断されてるでしょ
バリアント型ってそういうもんだと思われ

×言語には
○言語でも

なぜそこでVB?

バリアント型ってVBだけか？jsとかのvarもそれだろ？

いや、そのキモイキャストがいやだってだけ・・・。筆頭であろうが気にしない。

実行時判断っていうのが怖いわけで、例外とかめんどくさ。

俺が個人的にVB嫌いなのは、ポインタ取得とかめんどくさいから。
あと、まぁ、なんか色々めんどくさい。とc++になれてるとそう思う。

>>201
その気になればC++だってValiantクラスとか作れるだろう
class Valiant
{
public
　operator (int)();
　operator (char)();
　operator (short)();
　operator (long)();
　operator (long long)();
　operator (float)();
　operator (double)();
　operator (long double)();
　operator (char *)();
　operator (wchar_t *)();
・・・

>>203
boost::anyとかあるけどね。
ATL系とかでも。

でもboost::anyの場合、
代入するときはともかく、値を取得するときは明示的にキャストして
失敗したら例外送出だからなぁ。
なんつか、この明示的にって段階踏まないといやなわけでして。

boost::variant

>>205
そういや、それもあったなぁ。
いまだ使ったこと無いが。
なんに使うと効率てきなのかいまいちわからん。
ビジターパターンに使えるっていうが、ビジターパターン自体まだ使ったこと無いや。

C++が難しくないなんて言えるなんてすごいな。
今までVB,C,C++,Dehphi,Java,PHPなどで業務アプリを作って来たけど、
一番生産性が低いと感じたのはC++だった。
もちろん、それなりに習熟すれば生産性はあがるのだろが、
習熟するまでの時間がかかりすぎる感がある。
今の職場では多分俺が一番C++に詳しいけど、C++をマスターしたなんてとても言えないし、
積極的にC++を採用したいか？と聞かれれば可能な限り他言語を選択したい。
C++マンセーになる理由が俺には解らん。。。

>>207
WindowsのServiceアプリ組むときなんかはC系の言語が一番便利なわけで
人によってはCでそのまま組むよりもC++の方が開発時効率が上がる
少なくとも私はそう
CよりもC++の方が一度に考えなければいけない要素が少なくて済む

>>207
C++以前にCに十分習熟していないせいだと思うよ

生産性の低い言語＝習熟しにくいだからな
熟練者が生産性高いよって言ってもサンプルにはならへんのが実情
個人的にはDに一番期待している

つーか、業務系なんてどの言語で書いたって同じだろ。
C++のメリットが活きるのは寧ろ制御系だからな。

てか、俺的イメージだが、
ｃ++からｃを省いたようなもんがJAVAって感じだが・・・。
VBで生産性あがるっていっても、簡単なもんだけでしょ？めんどいことになるとできなそうだし。
デルファイはいじったことないなぁ、簡単らしいって話はきくが。
PHPもまだないなぁ。

俺はｃ++2年ほどやったが、
後は、
アセンブラ、
ロケール、
メモリアロケータ、
modern c++ design 読んで、
デザパタ極めて、
マルチスレッドも極めるくらいかねぇ。
って先なげぇ。
まぁ、一部ｃ++以外にもつかえるが・・・。

ISO C++の規格策定にかかわっている人にとっても、C++は難しいらしい。
現行の規格に内在するバグというか不都合な点がバラバラ出てきている。
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html

C++もＪａｖａも使ってる俺からすればJavaの方が圧倒的に簡単。
両者比較してJavaのほうが難しいなんていってる奴はオブジェクト指向理解して無いだろ（ﾌﾟﾌﾟﾌﾟｯ
せっかくC++コンパイラ使ってるのにＣみたいな書き方ばっかりする宝の持ち腐れオオバカや郎なんだろうな（ｗｗｗ

>>214
誰も「Javaのほうが難しい」なんていってないと思うが。

Javaしか出来ないJava厨の思考回路は意味不明過ぎて難しい

Cしか出来ないJavaを使った事のないような時代遅れの無能親父の煽りはもう沢山

Javaしかできない連中はただいま大量生産中です。
正直言ってヤバいっすね。

ほとんどｃ++しかできないです。
まぁ他の覚えるのはそれほど苦労はしないけど。使わんからすぐ忘れる。

次の本命はD言語だな
メモリリークを起こさない上に任意のタイミングでGCできる優れもの
２ｃｈブラウザもDで作れば無駄にメモリ取らずに済むよ

>メモリリークを起こさない上に任意のタイミングでGCできる優れもの
大抵のGCはメモリリーク起こさないし、任意のタイミングでコレクトできると思うんだけど

>２ｃｈブラウザもDで作れば無駄にメモリ取らずに済むよ
なんで？

>>221
>>メモリリークを起こさない上に任意のタイミングでGCできる優れもの
>大抵のGCはメモリリーク起こさないし、任意のタイミングでコレクトできると思うんだけど
ランタイムなしでそれを実現できるのさ

>>２ｃｈブラウザもDで作れば無駄にメモリ取らずに済むよ
>なんで？
２ｃｈブラウザは起動初期の倍近くのメモリリークが起こってるからね

>>222
ランタイムなしでそれを実現出来るから何？

2chブラウザって沢山あるけど、そもそもどの2chブラウザなの？

>>223
ランタイムが無いって事は早いって事じゃん！
ちなみに俺にブラウザはLive2ch、最強だぜ

Live2ch って VB製じゃなかったか？
速さとか軽さとかを追求したものではないだろう……。

というかVBランタイムってGC無いんだと今知ったのは内緒ｗ

ネイティブでGC作る言語は強力だとは思うが
資産が無い上にMSがC#発表したばかりでのってくるとも思えないのが痛い

おまいら、自分のケツぐらい自分でふけよ。
その内、下の世話までM$におながいすることになるぞ。

てーか、GCいらない。
メモリ取得、解放するときの動作早くしろ。
自分でメモリアロケータをカスタマイズしなくても、
コンパイラオプションの設定で超高速で動くようにしてくれ。

GC使ったほうが長時間安定した速度で動くから、
非GC環境が速いとも言い切れないらしいよ

今ホットゾヌ２使っているけど、メモリリークひどすぎ。Delphiなんだけどなぁ。
スレをどんどん見ていくとあっという間に５００ＭＢほどに未使用メモリが膨れあがる。
正直一番気に入っているので、C#で書き直して(　ﾟдﾟ)ﾎｽｨ…。

>>230
できれば根拠が知りたい。

>>232
良く>>230の言っている意味がわからんが、非GC環境で「メモリリーク」が
どんどん起こったとして、メインメモリを食いつぶしてスワップ起きまくりに
なるから遅くなる、とかそういう次元の話なのだろうか。

メモリリークは非GC環境に限った話じゃないんだが。

>>232-233

http://www.kmonos.net/alang/d/
より

C/C++ プログラマは明示的なメモリ確保と解放に慣れていて、
ガベージコレクタの効率や利点については懐疑的なようです。
私は、 一からガベージコレクションを念頭に置いて書いたプロジェクトと、
既存のプロジェクトを GC を使うように方向転換した経験のどちらも持っていますが：

ガベージコレクトされたプログラムの方が高速です。 これは直感に反するかもしれませんが、その理由は：

●明示的なメモリ管理の際によく使われる手法は、参照カウントです。
代入があるたびにカウントを増やしたり減らしたリソースを挿入するのは、 速度低下の原因になっています。
スマートポインタクラスでラップしても、 速度的な解決にはなりません。（
またいずれにせよ、 循環参照を削除できない参照カウント方式は、 一般的な解決策ではありません。）
●オブジェクトによって獲得されたリソースの解放には、 デストラクタが使用されます。
多くのクラスでは、このリソースとは 割り当てられたメモリのことです。
GCを使えば、 ほとんどのデストラクタが空になり、完全に削除してしまえます。
●メモリ管理のためのデストラクタは、 オブジェクトがスタックに置かれたときに影響が顕著になります。
例外が発生したときに、全てのスタックフレームでデストラクタが呼び出され、 メモリを解放するような仕組みが必要となるのです。
もしデストラクタが関係しなければ、例外を処理する特別なスタックフレームを 設定する必要がなくなり、コードは高速に実行されます。
●メモリ管理に必要なコードは全てを合わせるとちょっとした量になります。
大きなプログラムになるほど、キャッシュに入らない部分が増え、 ページングが多く発生し、 プログラムが遅くなります。
●GCは、メモリが残り少なくなってきたときのみ実行されます。
メモリに余裕があれば、プログラムは全速力で実行され、 メモリ解放に一切時間を取られません。
●モダンなGCは、過去の遅いものより遙かに発展しています。 世代型のコピーGCには、 昔のマーク＆スイープアルゴリズムの非効率さはありません。
●モダンなGCはヒープの詰め直しを行います。 これによってプログラムが活発に参照するページの数を減らし、 キャッシュヒット率を高め、 スワップ回数が減ります。
●GCを使うプログラムは、メモリリークの積み重ねで次第にパフォーマンスが悪化、 という事態に縁がありません。

> ●GCを使うプログラムは、メモリリークの積み重ねで次第にパフォーマンスが悪化、
> という事態に縁がありません。

これはウソだな

まあ、突っ込みたいのはわかるがメモリリークになる可能性は低くなっていると言う事でいいんじゃねーの？

>>235
提示してくれたページ、GC周りをさらっと目を通した。ありがとう。
●スマートポインタは使いたいケースに応じて選ぶことができるから、
　参照カウントだけと比べるのはどうかなぁと思う。
●デストラクタが空になるのはスマートポインタでも同様。
●例外に関しては同意。
●メモリが少なくなって来た時にごっそりメモリ解放するんだと
　むしろその一瞬非常に不安定になるのではないか。（これは欠点に書いてあったな）

自分は例外バンバン投げたいのでデストラクタが重くならないなら
それはありがたい。
ただ、Dって面白そうだね。autoを使ってscopedに解放もできちゃうようだし。
きめ細やかな言語だと感じた。GCの話題から外れてゴメン。

まあ、スタイルにも依るんでしょうけど。
●明示的なメモリ管理の際によく使われる手法は、参照カウント...
shared_ptrってそんなに頻繁にコピーってする？
俺は所有権のはっきりしないリソース（ファイル・ハンドル等）の管理に
使うことが多く、参照カウンタが変化するのってタスク相当の粒度の
オブジェクト間の構成を初期化するときぐらい。

●またいずれにせよ、 循環参照...
上記のような使い方をする場合は、保持するオブジェクトと
保持されるオブジェクトの関係が階層的になり、参照がループすることは
無い。むしろGC導入によるdtor呼び出し遅延のほうが俺的には大問題。

●メモリ管理のためのデストラクタは、 オブジェクトがスタックに...
俺の場合、Appレベルでは例外って殆ど使わないし。

つうか、GCスレってないのね。

>>240
「コンパイラ・スクリプトエンジン」相談室が失速気味なので
良かったら使ってやってください。

ttp://pc5.2ch.net/test/read.cgi/tech/1070089173/

>>239
>●デストラクタが空になるのはスマートポインタでも同様。

同様じゃないよ。C++だと書かなくてよくなるだけで、実際はコンパイラが生成してる。
GCがあると、「完全に」削除できる。

脳内コンパイラｷﾀ------

？

>>242
dtorに書いてなくても暗黙的にメンバ変数のdtorが呼ばれるつう
意味ならその通りだけど。
ていうか、236の2番目のはどういうメリットなんだろう。
記述忘れてメモリリークって意味ではauto_ptr/shared_ptrで書けば
ありえないし。まともなC++erならメンバにauto_ptr等を含んだ
オブジェクトを頻繁に（例えばsortの比較関数オブジェクト内で）
生成・破棄するようなコードはかかないだろうし。

サイズが減ってキャッシュが云々ってのもいまいち説得力に欠ける。

>>242
オブジェクトのデストラクタは空
スマートポインタのデストラクタは空でない
ということがいいたいのだろう

オブジェクト内にスマートポインタをもつなら
結局オブジェクトのデストラクタも空でなくなるが

>>242
デストラクタについては、
1. ソース上書かなくて良くなる
2. スコープが切れた瞬間に呼び出されるわけではなくなるから例外が効率良くなる
と言っているように見えた。だから1についてスマートポインタと同様と書いたんだが、
文意は違ったのかもな。でも、把握した事実は変わらないと思う。

完全に削除って表現が微妙だな。デストラクタが呼ばれなくなるわけじゃなくて
呼ばれるタイミングがスコープから抜けるタイミングではなくて、GCのタイミングになるよ
という意味だよね。

…C++から離れてる。そろそろやめたほうが良さそうだ。名無しに戻ります。

>>235
一般論としてGC付のが速いって言うなら
理屈はいいから実際のベンチ出せといいたい。

>>248
お前もGC無しの方が早いというならベンチ出せコラ

つか、どういうベンチプログラムならうまく計れるんだコレ

オブジェクトの生成と破棄（スコープアウト）をひたすら繰り返すベンチだな

計るんならゴミ回収遅延によるシステム全体の
ディスクキャッシュ効率の低下も考慮しとけって。

>●GCは、メモリが残り少なくなってきたときのみ実行されます。
>メモリに余裕があれば、プログラムは全速力で実行され、 メモリ解放に一切時間を取られません。

これを素直に読むと
GC有りのプログラムを多数常駐させると互いにメモリ圧迫しあって
パフォーマンスががた落ちになりそうに聞こえるわけですが

言語とは関係ないとはいえ、現実的に
メモリが不足しがちだとOSまで不安定になるしねぇ。

あとDのコンパイラの最適化ってどの程度やってるの？
もともとコンパイラ屋だから能力的にはできるんだろうけど
言語仕様決めてライブラリガリガリ書いてその上最適化もやるって無理っぽくない？

・メモリが不足したらGCが走る
・メモリが不足するとOSが不安定になる
ということは、これに
・論理メモリよりも物理メモリの方が小さい
をプラスすると
・GCが走るときはOSが不安定なとき
・OSが不安定になるまでGCが走らない
ってなことになるんじゃないかしら？

コンパイラ屋だけど、実際GCの方が総合的には速いと思う、
コンパイラ側が全部管理できればオプティマイザに特別なアプローチが出来るからね。
ただC++には似合わないと思う、最小限の機能強化でGCはライブラリにして今流のtemplateでエレガントに実装すべきだ！
と主張してみたかったりもする。
C/C++は、組み込みから汎用までいかなる環境にも耐えられる言語であって欲しいです。
言語本体は最小限の機能のみをもつ機械語翻訳機がいい。

ところでDはGCを自作で置き換えるとかできるのかな？
日に日に強力になってきているDに興味が沸きつつある今日この頃。

Cは恥かしすぎ

>>256
>総合的には速いと思う
GCの最適化で？それともコードの実行時最適化？

もっともC++でもそういう総合的に早くするって考えは
あるよね。例えばvectorにpush_backする時にサイズを
２倍ずつ増やすとか。C++erでもそういうトレードオフを
理解しないでSTLとか使ってる奴っているだろうし。

vectorが完全に連続したメモリを確保するのに対して、
dequeがブロック単位でしか連続したメモリを確保しない事を知らない香具師が多すぎ

突然なんだ？

で、ベンチはまだか?

>>259
バッファ用のバイト配列をvectorで確保すると
知らない人間は面食らうよね

C++の難しさって殆んどtemplateが占めてんじゃねーの？

と思ったら>>144みたいなのも居るのね。。。

vector v(x);
read(&v[0]);
なんてやるなら、素直にscoped_arrayや、
それが許されないならコピペや自作で対応した方が
見た目にも易しいし。

>>264
同意しかねる。
その用法はvectorの設計コンセプトに合致するものであり、何の不満も無いよ。

同じく同意しかねる。ただ不満はある。
C++の言語が難しくて聖書のようにあげられる代表的な数冊の本を
読破理解しないと使いこなせないような言語になっちゃうのは
見た目に直感的じゃないからと思う。

でも全体としての言語仕様の大きさはともかく、
すぐ上で挙げられている「テンプレート」や「STL」といった個々の要素に関しては、
習うより慣れろを地で行ってると思うよ。本はリファレンス的に使えばそれで。

C++の難しさは言語仕様よりも使用方法のノウハウの難しさのような気がする
個々はたいした事はないのに組み合わさったときの威力は大きく、それを利用するためだと思う。
template <typename H,typename T> struct TypeList
{
typedef H head ;
typedef T tail ;
} ;
と書かれれば、これがどんな定義なのかはC++をちょっと知っていれば判るが
これをどう活用するのかとなると急に難しくなる。
分りやすい書籍を作るのに従来通りの言語仕様の本とライブラリの本だけでは補えない部分があるのに
その部分を上手く解説した本はあまり無い気がする。

>>268
それ、発想が Lisp 的なんよね。
Lisp 知ってる人からすると、そのコードも見ただけで何がしたいかすぐ分かる。
template を使ったメタプログラミングって関数型言語と似てるらしくて、
Lisp 的表現が良く使われる。

実際のコードは逐次処理的にかいてTypeList等で
それらのコードを組み合わせる構造を記述して
GenScatterHierarchy等で実際にコードを組み合わせて
実装を生成する。

関数型言語だと構造だけでなく実際に実行されるコードも
関数型っぽく記述しなきゃいけないってのが、慣れてない人間
にとっては厳しい。

そういう意味でC++でのMPっての有難いんだよな。

馬鹿は馬鹿なりの使い方すればいいし、
頭いい奴は頭いいなりの使い方すればいい
ってだけの話なんじゃないの？

>>271
両者が一緒にいるときはどうしたらいいのでしょう。

一番はバカにコードを書かせないで頭いいヤツに全部かかせることかな。

そっちの方が早く、優秀なモノが出来るだろう。

根幹にあたる部分を、頭いい奴にザッと作らせる。
頭悪い奴には、ただひたすらそれを使うか、応用する部分を作らせる。

プログラミングに限った話じゃないがナ。

>>272
ベアプログラミングで鍛えるべし。
勉強するきないやつなら、いじめるべし。

ネタふり
C++のグローバル変数初期化タイミングは難しすぎ。

dynamic initilizationなグローバル変数にいたっては
main前に呼ばれることすら保証されてない。
dynamic initilizationなグローバル変数の初期化の
スレッド安全性とか考えると頭痛くなる。

また、main前の初期化順序もある程度は制御したい。
翻訳単位のモジュール性を向上させる意味でも。

こればっかりはjavaが羨ましいよ...。

グローバル変数使うなよ

データメンバ　≒　グローバル変数

Cをやってきた人はC++が出来ないと嘆く人が多いですよね？
自分はC++から入ったんでCの理解はさほど困らなかったんですが、
教授でもそういう人が居ますよ。駄文失礼しました。

出来ないんじゃなくてやる気が無いだけだろ。
CとJavaがあればC++いらないし。

>>279
多い？そんなに聞かないけど。。
プログラムスタイルの違いに始め戸惑うだけじゃない？

>>281
現場では意外に多いよ。テンプレートや継承を勉強せずにいきなりソース見るから理解できるわけもないんだけど。

>>276
そういうのは処理系依存になる事も多いね
#pragma で明示的に指示できる処理系もあるよ
組み込み向けでは、コンパイラメーカーにリクエストだすと機能追加してくれる事もあるし
判り難い標準仕様よりも、そっちに頼っていたりする事が多いです。

>>283
確かに、処理系依存では有るけど・・・。

言語内でそういうのを保証しようとするとstaticなlocal変数とか
利用する羽目になるけど、スレッド安全性とかコストとかの問題も
あるし。main先頭でいちいちリソース初期化等の処理を書くってのも
モジュール性の観点から考えるといまいちな気がするしなぁ。

>>279
C++よりもCのほうが難しいだろう。
C++なら簡単にできたことがCだといくつかの要素に還元せねばならず、
しかも全部横並びの関数になるため凝集度が低くなってしまう。
あとからメンテするのが大変。
C++を極めた人間のC++ソースと
Cを極めた人間のCのソースなら
前者のほうが分かりすい。

>>285
ソースの分かりやすさと言語の難しさは違うと思われ。

>>282
ヴァカみたいにテンプレートや継承使いまくってるタコソースなんか見る気がしないということでは ?

>>285
C++で本格的にプログラムを書いた事が一度もありませんね？

>>288
煽っているつもりだろうが、それはむしろ逆だろ、本格的に書けばC++の方がやさしい
C++の言語仕様は厄介だから、ちょこっと書く分には難しい。
変な煽りはヤメレ

>>289
別に、C++でも、C風に書くこともできる

おじさんはextern "C" {}のトリコ

Ｃ＋＋の仕様準拠率がもっとも高いコンパイラって、
現時点では何になるのでしょうか？
もしかしたらスレ違いかもしれないけど、
これだけ「難しい言語」だと
仕様に準拠するのも大変そうだなぁということで…。

準拠度そのものを比較したってのは知らないけど、
Boostのレギュレーションテストは参考になるね。
ttp://boost.sourceforge.net/regression-logs/

本格論議はよくわかんないけど、std::map なんかがやっぱり便利だから、
よく初心者の勉強用に用いられる「単語の出現頻度を調べよ」みたいな
プログラムは、C の場合より著しく簡単になるよね・・・

>>282
それはソース云々より設計がタコ
どんな言語で書いてもタコはタコ
まC++はタコさ加減が露呈しやすい言語ではあるが
VBなんかだとみんなタコだからカモフラージュになるしな
タコじゃないほうが浮いて目立って困る

295=タコじゃないつもりのタコ

いきなり設計云々が出てくる辺りがとっても蛸。

>>287と>>282を間違えたあたりがタコorz

言語仕様がタコなC++の時代は終わった
これからはtemplateを使う必要がないJavaの時代です

>>299
ｳｾﾞｰあげんなﾎﾞｹ　程度の低い釣りは秋田

>>293
やっぱりboostなんて使えないってことかな。

>>301 意味がわかりません。

>>302
移植性が低いってことでは

boost が使えなくて泪目で boost なんて必要ないんだぁぁぁっ
て事ですな。

>>299
>templateを使う必要がないJavaの時代です
1.4でがんばってね。

現場だと継承、テンプレート一切使わないってこと多いな。
テンプレートなんてそんな難しいか？
boostはともかく、STLと簡単なテンプレートぐらいなら誰でも理解できるだろ？
テンプレートが難しいってのは、一部の天才が作った
ジェネリックプログラムとかのこと？

サイズが10倍になるのでプロの現場では使われません。

テンプレートが難しいんじゃなくて、テンプレートを使って書かれたコードに、
テンプレートパラメータの名前省略されたものが多かったり
traitsとかpolicyに分解されてコードが細切れの散り散りだったり
その上、#ifdef等で切り刻まれていて全体像を把握しづらいコードが多いというだけのこと。

そりゃぁセンスのない奴が書けばテンプレートに限らずね。

>>307
仮令10倍であっても作業効率が上がるのであればプロだからこそ使いますが。
#サイズ云々する現場なんて寧ろ限られるって。

DinkumwareのSTLはセンスの無い奴が書いたのか？

C++の仕様はセンスの無い奴が書いた

>>310
コンパイル時のリソース消費を少しでも軽減するためらしい。
あとは、真似防止か。

Loki を理解するよりも、STL のソースを読むほうが難しいと思う。

実装によるだろ（ｒｙ

>>313
じゃあ、M$版の奴。

C++使えると豪語する奴=本当はCしかできない低脳
http://pc5.2ch.net/test/read.cgi/prog/1094445966/

漏れはC++よりもVBが難しい

C#やっとけ。嫌ならDやっとけ。嫌なら(ry

Ruby!!!!!!!!!!!!!

C++って使いどころがない。
for_eachとかいつ使うんだこんなの、forの劣化版でしかない。

例の「ほげ言語のパラドックス」の意味がよくわかるねｗ

>>302
inline

>>320
お前、あれだろ。車を「こんなの地球温暖化の原因になるだろ」って難癖つけて
乗らないだろ。

車と地球温暖化って？
なに言っての、このボンクラ
どこかで聞きかじったのかしらん？ｗ

車と地球温暖化の二つの単語から
「聞きかじった」とかいう発想が出てくるのが凄いｗ

「なに言っての」のあたりといい、かなり必死なようで。
理由はわからんが。げらげら

↑またまた新手の厨が出現ｗ

>>325ってきっと、偉そうなこと言っときながら、GUIなPCしか触ったことないんでしょうね。
DOS時代を知らないんだな、こういう香具師。

悔しいからって二つも書かなくていいぞ、324ｗ

C++は使いまくりだろ。俺はCの方がよく使うけど。
一番使うとこがないのはRubyとJava。

言うまでも無いけど、仕事によって使用頻度が違ってくるからなあ。
普通は使わない言語の方が多いだろ。
逆に、まんべんなく使用するとなったら、それ部署たらいまわしにさ（ｒｙ

Java言語仕様も包含してC+++ つーのはどう？

えーい、こうなったら、VBやDelphiも許してしまう
てんこもり言語「C+++++」のお出ましだ！



・・・もうマニアしか使えねぇな

class C+++++: public C++, public Java, public VB, public Delphi, protected C#;

最強言語Ruby!!!!!!!!!!!!!!!

class 最強言語: public C+++++, private Ruby;

>>332-334
　 (ﾟДﾟ );;; ＜ｽｹﾞｪ・・・

private Rubyという言葉に笑った。
言いえて妙

C++って、何でもできるのがいいよね。
ビットフィールドとか共用体をCから引き継いでるから
エンベディッドのきつい環境でも、メモリを節約しつつ
ある程度見やすく書けるし。
メンバ関数ポインタを配列に突っ込んだりやりたい放題。

一人で組むんなら最高の言語だよ。

>>337
>一人で組むんなら
人数が何か関係してるのか？

>>338
多人数で組むなら、あんまりトリッキーなコードは書けないじゃん。
それならJavaでも大差ない。

俺、最近<boost/preprocessor.hpp>の利用による繰り返し処理を勉強中何だけど
もしかして、これって、perlなどの言語でちょちょいと書いて、出力して、コピペ
したほが可読性の面からもいいんじゃないかと気づいてしまったんだけど
まだまだ理解が足りないというかとなのかな。

C++ってそんなに難しいか？
STLが超便利でCなんてやってらんない体になってしまった

>>341
幸せな時期だね。

286上のQuick C、MASMの時代からC、C++一筋で趣味、仕事でやってきて
他の言語はいらないとまじめに思ってたんだが・・・最近、C#をCつながりで
やってみるかと覗いてみたら・・・もうC++の時代は終わりかもしれんな。
C++を身につけた人間があえて乗り換える必要はないが、新人にC++を教えたり
薦めたりする気はなくなったよ。これからやる人はC#やった方が良いな。
.NET→WinFXと進んでいこうとするならなおさらだな。

http://www.square-enix.co.jp/shop/goods/images/series_cre4_06.gif
小さすぎて見えんがな('Д`)

112 名前：名前が無い＠ただの名無しのようだ ：04/09/09 21:07 ID:s4msPAUO
http://www.ffcompendium.com/EspMon/necron9-b.jpg
http://www.ffcompendium.com/EspMon/necron9-a.jpg

>>343
C#は絶対にC＋＋は超えらんないと思うよ
C#って実質Windowsでしかつかえねーじゃん
WindowsでもDLL内の関数なりクラスを使うとなると
面倒だし・・・
挙げだすと枚挙に暇がない
WindowsではVC++&MFCこれ最強
ま　ち　が　い　な　い！

オトトイ、キ・ヤ・ガ・レ！

Windows + C言語のみでMFCも使わずWin32APIネイティブ。
自分でWinProcからMSGをディスパッチしる！　＜これ最強。

>>345
> C#は絶対にC＋＋は超えらんないと思うよ

それはそうなんだ、言語の汎用性という意味からするとあなたの言ってる事は
非常に正しいんだ。

> C#って実質Windowsでしかつかえねーじゃん

これもまさしくそうなんだ。

でも、仕事って、まぁ俺の場合はそうなんだけど、９割方Win絡みなんだよね。
でもって、次の世代のWindowsが06年に出るかどうかは別として何時か、近い
将来は必ず出るんだよね。で、そのWindowsからはWin32Apiはネイティブじゃなくて
WinFXでエミュレートされるんだよね。となると、これから始める人があえてwin32api
に精通する必要はなくなるんだよなぁ。むしろ、今は.NETのクラスライブラリの使い方
に精通した方が良いと言える。

> WindowsではVC++&MFCこれ最強
> ま　ち　が　い　な　い！

現行ではね。Win32Apiがその存在意義を失うであろう、ここ２〜３年の間わって話し
だよな。OSのネイティブAPIがWinFXのクラスライブラリになれば話しはがらっと変わるよ。

まぁ、ハードに近い分野をMSがどうやってクラスライブラリにのっけてくるか、お手並み
拝見だけど、.NETの最適化も1.1→2.0βで大幅に進んでるからね。画像処理のコードを
1.1と2.0βで同じようにコンパイルしたら5倍ほど速度アップしてた。1.1上で約16秒
要してた処理がコンパイルし直すだけで3秒程で終わるようになってたからね。

ただ、間口を広げるという観点からは他のプラットフォームでも使えるC&C++を知っとく
ってのは悪くないとは思うけどね。

じゃあ、その画像処理処理コードをC++で書き直してみたら？
C#がC++を凌げない答えがそこにあるから。

>>348
> まぁ、ハードに近い分野をMSがどうやってクラスライブラリにのっけてくるか、お手並み
> 拝見だけど、.NETの最適化も1.1→2.0βで大幅に進んでるからね。画像処理のコードを
> 1.1と2.0βで同じようにコンパイルしたら5倍ほど速度アップしてた。1.1上で約16秒
> 要してた処理がコンパイルし直すだけで3秒程で終わるようになってたからね。

ま、まじっすかそれ？

>>349
やりましたよ。C++だと.3秒で終わりました。テスト用に作ってる
画像処理用ライブラリなんですけどね。巨大なサイズのビットマップを
読み込んでフィルタ処理するって奴です。
現行だとC++の方が10倍程速いですね。しかしですね、ここが大きな問題
なんですが、C#でもbitmapクラスを使わずにそのままメモリに展開して
ポインタ使ってアクセスすると.4秒程度で終わってしまうんですね。ファイル
読み込みにはもちろん.NETのクラスライブラリを使用してます。
個人的にはC#でunsafeなコードを書くのは邪道だとは思うんですが、やろうと
思えば問題ないって話ですね。dll呼び出しするほど手間でもないですし。
インラインアセンブラ使うような感じですね。となると話しはややこしくなってきます。
C#に対するC++の現行での利点は、
・ポインタを駆使出来る。
・win32apiへのアクセスが容易である。
・ネイティブコードを吐ける。
とまぁ既存のライブラリ資産の問題を抜きにすればこんなところです。後ろの２つは
ここ２〜３年で利点でもなんでもなくなってしまう訳です。で、１つ目に関してもボトル
ネックとなるような肝い部分ではC#でも問題なく使用出来る、となればほとんど差は
なくなってしまうんですね。やはり考え込んでしまいますね。ただ、プロジェクトの規模
が非常に大きくなってきた時のGCの挙動というのがどの程度パフォーマンスに影響を
与えるのか現時点では読めません。コードでの工夫のしようはありますが、最終的には
VM任せですから。まぁこのあたりもMSが最適化していくような気はしますが。
一つはっきりしときたいのは私はC++を否定するつもりは毛頭ありません。ただ、スレタイ
にもあるとおり「C++は難しすぎ」と感じる人がいるのだとすれば無理して今から覚える
必要は、Win上での開発を念頭に置いているのなら、ないんじゃないかなと思っただけです。

>>350
ほんとです。ソースはそのままコンパイルやり直しただけでその程度のパフォーマンスの
向上が見られました。βがとれた時はそれなりに期待しても良いのかなという気にはなり
ましたね。

俺はc#がVBSのような運命を辿るような気がして成らないんだけど・・・

> C#に対するC++の現行での利点は、
> ・ポインタを駆使出来る。
> ・win32apiへのアクセスが容易である。
> ・ネイティブコードを吐ける。

C#はどれもできるぞう。
ところで、最初のはあんまりうれしくないなあ。

Ｒｕｂｙ最強言語
Ｒｕｂｙ！！！！！
Ｒｕｂｙ ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞ Ｃω

>>353
脊髄反射？

ポインタ使える事は >>351 も知ってるようだぞ？
ポインタは確かにアレなんだけど、本流になるには絶対必要だと思うね・・・残念ながら。

Native 呼び出しはモノによっては結構面倒。単にアクセスの容易さだけなら C++ のが当然上だよ。
確かに普通の Win32 API はそれほど面倒なのに突き当たった事はないけど、
COM だとラッパー作るのが大変なの多いね。TLB とか無い場合は。
もちろん JNI みたいなのよりは全然マシだけど。

それから、C# で直接ネイティブコードは吐けないんじゃない？
インストールしたマシン上で変換はできるけど。

まぁ何にせよ楽なのはC#だわな。
別に両方使えれば問題ないさね。適材適所。

>>355
本流ってよくわからんが、洗練されたC++コードにはポインタは登場しないよ。
ポインタが飛び交うなら、それはC++の顔をしたCだと思う。

っつうか355みたいなのは若い（よね？）ならいいけど
年くってたらヤバいと思いなされ。

>>358
何か言いたいならはっきり言えよ

>>357
それはおまいがC++が書けないからだよ　ｗ

>>357

すまん。自分はポインタつかいまくり。
スタックに積むオブジェクトとヒープに確保する
オブジェクトは明確に区別している。

それでヒープに確保するためのオブジェクトはどうしても
ポインタになる。スマートポインタはつかっているけど
生のポインタのほうが適切だと思う場所もあるので
それで生のポインタをつかっている。

>>361
> 生のポインタのほうが適切だと思う場所もあるので

そういう場所がほとんどなくなるのが、最近のC++のやりかただと思うのよ。

特殊な例を特長なんかにしないほうがいいよ。

>>362
どうやって？

自分の場合、ヒープに確保するタイプのインスタンスは
以下のような管理の使い分けをしている。
(依存、関連、集約、コンポジションぐらいは理解しているよね)

[依存]

ケース1 :
あるメソッドローカルでつかわれるインスタンスで
メソッドをぬけるとインスタンスが不要になる場合。
auto_ptrかscoped_ptrをつかう。

ケース2 :
あるメソッドの引数として渡されるインスタンス。
渡されたインスタンスはそのメソッドの中でしかつかわれない。
この場合は生ポインタ。理由はインスタンスの寿命にメソッドは
関知しないためスマートポインタにする意味がない。

[単項関連]

ケース1 :
格納するクラスがインスタンスの寿命の管理をしないといけない場合。
この場合はauto_ptrかscoped_ptrかshared_ptr。

ケース2 :
格納するクラスがインスタンスの寿命に関知しない場合。
この場合は生ポインタかweak_ptr。

[集約]
基本的な方針は単項関連と同じ。集約のコンテナにはSTLコンテナ
をつかい、スマートポインタをつかう場合にはshared_ptr
(これじゃないとコンテナに格納できないから)をつかう。

[コンポジション]
問答無用にSTLコンテナ+shared_ptr。

こんな感じ。依存のケース2のような場合はスマートポインタを
つかう意味がないし、別に特別なケースでもなくてよくあるんだけど。

洗練されたC++の流儀とは、boostを使う事だったようです。
最近使えるようになったんでしょうね、うれしくてたまらないみたいです。

↑Boost分かってない香具師の僻みｷﾀ━━━━━(ﾟ∀ﾟ)━━━━━!!

標準がしょぼいせいでいろんなもんが乱立する事態になってる

なんたらptrとかほにゃららptrとか確かにウザィよね。
ライブラリレベルでやるもんじゃねえよ。

>>367
と言う事にしたいのですね。

自分の場合とか言いながら、長々と何を言うかと期待すれば
boost入門ページの最初の方に書いてある事を書いてみただけ。
ヤレヤレ

そんな事はboostの名前を知ってるような人間は誰でも（活用しているかはともかく）承知している事で、
それでもあえて生ポインタを使っているケースは多々あるのに、それを否定するだけの説得力（代案）が
先の文章には無い。

とりあえず否定だけしてみて自分の意見は無い香具師ｷﾀ━━━━━(ﾟ∀ﾟ)━━━━━!!

だからスマートポインタ最大限に利用したとしても
生ポインタをつかうケースがあるって例をあげてみた
んだけど。

>そんな事はboostの名前を知ってるような人間は誰でも
>（活用しているかはともかく）承知している事で、
>それでもあえて生ポインタを使っているケースは多々あるのに、
>それを否定するだけの説得力（代案）が先の文章には無い。
361の発言みれって。自分も生ポインタつかいまくりだって。

>>372
使いまくったらダメだろｗ

>>364
依存のケース２で生ポインタ使ってるところは参照が適切だと思うが、いかがか？

話の途中で悪いが、今の「ポインタを使いまくる」の意味は、
自力でnew/deleteしまくるって意味だよな？

>>375 ちがうだろう。

void******** (********a)(void******** (********)(void********));
なんて普通に使ってますが、何か？

>>374
ヒープに確保するオブジェクト限定の話なので、生ポインタです。
個人的にヒープに確保したインスタンスの参照をとるのは
抵抗があるかな。

たしかにスタックに積むオブジェクトや構造体ならむしろ参照の
ほうが望ましいと思います。

>>378
その抵抗には何か根拠がある？
まるで意味の無い区別だと思うが。

ヒープ上の（動的）オブジェクトを引数に取る関数と
スタック上の（自動）オブジェクトを引数に取る関数とで
オーバーロードでもするつもりか？

いつのまにかスレタイに沿った話題になってる

>>375
「生の」な。

生のポインタを渡したり、受け取ったり、コピーしたり、
インクリメントしたり、引き算したり、足し算したりすることかなあ。
そういうCみたいなコードはさすがにメンテするのも疲れる。

それはおまいが`使えない'香具師だからだYo

む、「Cみたいな」は禁句か？

>>382
話についていけないお馬鹿さんが
無視して書き込まなくてもいいのでは? ;-)

無視して書き込む? ;-)

つーかね、
システムコールがiteratorに移行しない以上、
ポインタ（アドレス渡し）は永遠に不滅です。

システムコールなんてwrapされる最たるもんだろ

主パスの処理にシステムコールが出てきたりするなら、C以前だなそりゃ

>>379

設計の段階でヒープに確保するオブジェクトとスタックに積む
オブジェクトは「明確に区別している」ので、同じクラスの
インスタンスがヒープに確保されたりスタック積んだりとまちまちに
なることはないので、オーバーロードする必要はない。
クラスによってヒープに確保かスタックに積むかが決定している。

ヒープに確保するオブジェクトの例をあげればポリフォーリズムが
必要なクラス、スタックに積むクラスは通貨型やベクトル型、
複素数型、クォーターニオンなど。

C++ではオブジェクトをヒープで確保することを強制できないので
とりあえずコピーコンストラクタや代入演算子をprivate属性に
するぐらいはやっているが、最終的にはドキュメントに書いている。

Compositeパターンのように子ノードの削除の責任が親ノードにある
場合、delete演算子かスマートポインタで破棄するんですが、
これがスタックにつまれていると親ノードの都合で削除できない
ので問題になる。こういうのは仕様できっちりきめるしか
回避方法がないのはC++の欠点だと思っている。

...というか、こういうガイドラインって一般的ではないのかな。
とりあえずつかいわけとしてはC#の値型と参照型に近い
感じなんですが。

>>388
> 設計の段階でヒープに確保するオブジェクトとスタックに積む
> オブジェクトは「明確に区別している」ので、同じクラスの

クラスを使う側のローカルな操作なら自分の決定を前提とできるだろうけど、
クラスや関連関数を提供する側では、どちらに確保されるかと言う前提は持てないだろう。

> ヒープに確保するオブジェクトの例をあげればポリフォーリズムが

"polymorphism" な。

> C++ではオブジェクトをヒープで確保することを強制できないので

コンストラクタを protected にして、ヒープに確保するstaticな
生成関数を用意すればできるよ。

> これがスタックにつまれていると親ノードの都合で削除できない
> ので問題になる。こういうのは仕様できっちりきめるしか
> 回避方法がないのはC++の欠点だと思っている。

他の言語なら仕様でキッチリ決めないで回避できるの？

> ...というか、こういうガイドラインって一般的ではないのかな。
> とりあえずつかいわけとしてはC#の値型と参照型に近い

C#は詳しくないけど、それを表したいなら、
　C#:値型 → C++:メンバを並べたクラス型
　C#:参照型 → C++:実装へのスマートポインタひとつをメンバに持つクラス型
こんな感じの対応付けにならないか？

>"polymorphism" な。
すんまそん。typoです。マジで恥ずかしい。

>コンストラクタを protected にして、ヒープに確保するstaticな
>生成関数を用意すればできるよ。
そういえばそうだった。忘れていました。

C#だと構造体は必ずスタックにつまれる(ボキシングするとヒープに
移るけど)し、クラスはヒープに確保される。まあC#の場合はも
ともとGCがあるからインスタンスの破棄のことは考えなくていいんだけど。

>C#:参照型 → C++:実装へのスマートポインタひとつをメンバに持つクラス型
これって俗にいうHandle-Bodyだよね。これも設計ポリシーによってはアリですね。
昔の(今は知らん)xerces-cもそうだったような覚えがある。

横槍ですが...

>>388
>Compositeパターンのように子ノードの削除の責任が親ノードに
>ある場合
むしろ私の場合は、Compositeパターンによる関連性と寿命管理を
分離する設計が殆どです。Compositeパターンにより関連付けられた
オブジェクト群を利用するオブジェクトと同じ寿命を持った
オブジェクトを用意し、それに保持させるって感じです。

そういった意味では、ライブラリがクライアントの用意するオブジェクト
の寿命を管理する設計よりも、ライブラリはあくまでもそのオブジェクト間の
関連性だけを利用するようにし、その関連性の利用期間を外部に通知できる
ようなインターフェースを用意します。オブジェクトの寿命が本質的に
あいまいな場合のみshared_ptrを使いますが、稀なような気がします。

>むしろ私の場合は、Compositeパターンによる関連性と寿命管理を
>分離する設計が殆どです。Compositeパターンにより関連付けられた
>オブジェクト群を利用するオブジェクトと同じ寿命を持った
>オブジェクトを用意し、それに保持させるって感じです
イメージとしてはFlyweightのようなオブジェクトプールを
つかうって感じでしょうか?ちがったらすみません。
一応、GoFの本を確認したところ「component を削除するのは誰か」
という段落で「通常は親ノードが子ノードを削除するのが最もよい」
とは書いてありますが、そうでなければいけないとは書いてないですし、
例外のケースもあげられています。

>あいまいな場合のみshared_ptrを使いますが、稀なような気がします。
個人的にもshared_ptrをガーベージコレクションのかわりに
つかうことは殆どないです。thisポインタ問題(shred_ptrの
thisポインタはスマートポインタで管理されていない。
一応回避策はありますが)や循環参照でメモリリークが
発生したりするので意外とつかいにくいです。むしろ
コンテナに入れることができる唯一のスマートポインタ
というつかいかたが多いです。

クライアントが生成したインスタンスをライブラリ側で
寿命を管理する必要があるかどうかは議論の余地がありますね。

とりあえず、俺に責任は無い。

C++でポリモーフィズムを使う時って、ヒープに実態確保して、ポインタ使うしかないの？

スタックに確保して参照を使うのもアリです。

で、361よ。
> 個人的にヒープに確保したインスタンスの参照をとるのは
> 抵抗があるかな。
これは具体的な根拠があるわけじゃない、ってこと？

ヒープに確保したインスタンスを参照にすると削除するときに&演算子で
ポインタに戻してやらないといけないのと、スマートポインタをつかう
ことも多いので、参照をつかっているところとスマートポインタを
つかっているところで表記がまちまちになって好きじゃない。
一貫性のある表記が好きという個人的な好みの問題。でも本当に
わざわざヒープに確保したインスタンスを参照にする人って
いるの?

ポリモーフィズムは別にスタックに確保したオブジェクトでも
できるけど、スタックに確保しちゃうとインスタンスの寿命の
管理の自由度が下がる。それにスタックに確保しちゃうと
Factoryメソッドのようなメソッド内部で生成したインスタンス
をメソッドの外部に提供するときにコピーコンストラクタが
必要になるのでそういうときに困る。例えばオブジェクトが
ビットマップのような巨大なデータをもつ場合、コピーコン
ストラクトのコストは大きいし、コピーコンストラクタを
書くのが難しいオブジェクトもある。なので必要のない
コピーコンストラクタはprivateにして使用禁止にして
つかわないようにしている。巨大なデータを持つオブジェクトは
前にもいった人がいるようにHandle-Bodyなんかでもいい
(実際にHandle-Bodyをつかっていたり、文字列クラスなんかは
CopyOnWriteをつかっている実装も多い)が、自分はHandle-Bodyを
つかうスタイルではない。これもスタイルの問題。

>>398
どこを縦読みすればいいのですか？

ポリフォーリズムをポリホと略すスレはここです

|　　ポリフォーリズム の検索結果のうち 日本語のページ 約 7 件中 1 - 3 件目 (0.54 秒)

あるからびっくりだ。

全部同一人物？

>>400
モーフィングとフォーミングを勘違いするなら分かるけど
フォーリングと勘違いするというのは飛んでるなと思う。
3カウント入れちゃうよ

だからマジtypoだって...。まだいりじるのか...。
本気で恥ずかしいんだからいじめんなよ。

>>いりじる
いじるの間違いだ。またtypo。もう嫌...。

ていうか、ポリフォーリズムをモリモｰフィズムと間違えるのって恥ずかしすぎ。

イリジウムのことね

はずかしすぎ。
アンテナでかすぎ。

どうtypoったらそうなるのか分からん

typoだけに突っ込んでいる人は、
そうやって話をはぐらかそうとしている
厨房なので無視するべし。

>>394
なんか、どちらかに誤解があるようだな。
>>364の [依存]ケース2 で言っていることは、
たとえば「あるメソッド」foo について、
　foo(T*);
というふうに引数の型として生ポインタを使うということじゃないの？
それに対して、
　foo(T&);
のほうが適切ではないかと言う突っ込みを>>374で入れている。
これは引数の型の話で、確保したインスタンスを
保持するための型は関係ないと思うんだけど、
漏れが>>364を誤読しているの？

レスアンカー間違えた。
>>411 は >>398 宛てね。

>>414

何度も同じようなことを書いてすまんけど、
1.クラス設計時にヒープかスタックか決めている
2.ヒープに確保するオブジェクトは常に(スマートポインタを含めた)
ポインタとしてつかいたい
3.参照をつかわないのは参照とポインタが混ざって表記の揺れに
なるからという好みの問題
別に参照をつかっちゃまずいっていう決定的な理由はない。
設計ポリシーとしてメソッドの引数は一貫して参照をつかうの
であればそれはそれでいいんじゃないでしょうか?っていうか俺が
文句いうことじゃないけど。

逆にちょっと質問。setterのようなあるインスタンスを引数の値とって
それをインスタンス変数に保持するメソッドで、かつ削除の権限が
そのsetterを持つインスタンスにある場合、これも参照で渡すの?
そうだとするとどこかの段階で参照からポインタに変換しないと
削除できないような気がするんですが。それともこの場合は
特別にポインタで渡すんでしょうか?

すまんレスの先が411だった。

質問の意図は指摘しているところで参照をつかうと、
setterうんぬんのケースと一貫性を保とうとすると
無理がある場所がでるんじゃないかってことです。

>>413
最初に突っ込みいれた箇所（>>364の[依存]ケース2）では
「渡されたインスタンスはそのメソッドの中でしかつかわれない」状況となっている。
「インスタンス変数に保持するメソッド」なら状況が違うんじゃないの？
これらの異なる二つの状況の間で一貫性なんてあるはずがない。

生ポインタ使う場所の例として挙げられた箇所に
参照のほうが適切だと突っ込みいれたのに、
スマートポインタ使う場所を挙げて反論されても困る。

> 削除の権限が そのsetterを持つインスタンスにある場合
どういう状況だかよく分からんが、std::auto_ptrみたいなものを
作ろうとしてるなら、素直にコピーを作成したオブジェクトが責任を持って
オブジェクトを破壊すべきだ。
参照渡しされたものを受け取った側で破壊するのは、分かりづらい。

とりあえずスマートポインタ勉強してから出直せ。

漏れはリアルタイム画像処理をよくやるんだけど、
画像のピクセルデータにアクセスするときはなんとなく生ポインタ使っちゃうな。

あったり無かったりするものを引数にしたいとき、T* 型の引数にして 0 渡すと
「無し」みたいなこともたまにやるし。C# や Java のライブラリでも null 渡せる
メソッドは結構あるから、実装面ではポインタ型の使いどころはそこそこあるん
じゃねーの？

まあ、あれだ

参照渡しでもポインタ渡しでもコピー渡しでもなんでもいいけど、
参照剥しをするのは控えた方がいいな。

あとでdeleteするオブジェクトはポインタで保持しとけ。

>参照渡しされたものを受け取った側で破壊するのは、分かりづらい。
からポインタつかえっていってんだろ。

>「渡されたインスタンスはそのメソッドの中でしかつかわれない」状況となっている。
>「インスタンス変数に保持するメソッド」なら状況が違うんじゃないの？
>これらの異なる二つの状況の間で一貫性なんてあるはずがない。
状況が違うから一貫性がなくてもよいという判断なら別にいい。
自分はポインタにすると2つの状況で整合がとれるから好きなだけだ。

メソッドの引数はポインタうんぬんという話はヒープに確保した
インスタンスに限定の話だ。しかもコーディングスタイルの問題
だから人のことはとやかくいうつもりはない。

ヒープに確保したインスタンスの参照剥がしが好きじゃないといったら
根拠を求められるし、好きじゃない理由をいったらなぜか参照剥がしは
わかりずらいっていう謎のつっこみが入るし、わけがわかりません。

いったい自分にどうしてもらいたいんだろう。

>>411
foo を書いていて引数にnull 値のようなものを許したいとき、
foo(T*) にするか、foo(T&) にして T::Null を提供するかっていうと、
漏れはメンドクサイから大抵前者だけど。

＞ポリホ
もうちっと日本語勉強しろよ

>>419
>いったい自分にどうしてもらいたいんだろう。
いじられ役に徹してくだちい。

とりあえずＣ＋＋ではヒープではなく「フリーストア」って呼ぶんじゃなかったっけ？
まぁ、データメンバを「メンバ変数って呼んじゃダメなの？」くらいの勢いだけど。

int* a,b; と int* a; int* b; って違うんだな・・・

>>424

いや、それは違いすぎだから…。
両方ポインタにするなら

int* a, *b;

じゃないとね。
だけどこういう書き方になるから型の後にアスタを付けるスタイルは好きではない。

int *a, *b;

のほうが美しいじゃん。好みの問題かもしれないけど。

>>424
所詮C++はC言語のころの呪縛から逃れられてないのよ。

>>425
int* a;
int* b;
と2行に分けることを推奨。

>>426
＞所詮C++はC言語のころの呪縛から逃れられてないのよ。

だがそれが(・∀・)ｲｲ!!
というか、仕様変更するとコンパイルエラーが発生するレガシーコードが
混在してしまう可能性があるから仕方ないっしょ。








・・・レガシーという単語を使いたかっただけだ。気にしないでくれ。orz

int* をtypedefして違う名前を与える
さらにはintを変えられるようにtemplate化

C言語の型とは何か。

typedef int *iptr;
int *は ptr->int
iptrも ptr->int
int *[]はarray->ptr->int
int (*)();はptr->function as int
int *();はfunction as ptr->int
struct { int a,b;} *;はptr->struct{int a;int b;}


構造が同じなら互換性があると言う。

iptr a;
int *b;
a = b; // ok

しかし
struct { int x,y;} a;
struct { int x,y;} b;
b = a; // error '=' : 互換性のない型が含まれています。


これはいったい、どうしたことか。

>>429
b=a;
が
b.x=a.x;
b.y=a.y;
と同義であるとはいえない。
直感的にはそうであるが。
同義であるなら同義であるとoperator=なりで
コンパイラに教えなきゃわからん。

>>429
struct A { int x,y;} a;
struct B { int x,y;} b;

名前を省略しただけの扱いなんだろ。
別々の構造体で、たまたまメンバの並びが同じになっただけで代入ができたら困る。

C++スレでC虫臭い話を続けるな

>>424-425
こんな解決法もある。
typedef int *PINT;
PINT a, b;

それ終わってる。
とっくに。

>>429
基本的に別の型に代入はできない。当たり前だけど。Java だって C# だってそうでしょ。
typedef は単なる別名で、新しい型を作る訳では無いって、仕様で決まってますから。

メンバの並びが同じな別々の構造体を作る必要性はあるのか？

あたりまえ

>>436
「今はたまたま同じメンバだけど、将来的には拡張されるかも知れない」
ってことはありそう泣きガス

>>438
その場合、直接代入できる必然性はないよね。

>>439
ふむ。そりゃそうだ。

ふと思ったんだけど、構造体やクラスの（データ）メンバを
while文のようなループ文でくるくる回しながら順番に取れたら便利かも？
名前とか個数とかデータ型を意識せずにクルクル…。
そういうのってうまいこと出来ないかな？

>>441
意味が判らない

>>441
型の違うデータメンバのいったい何が取得したいのか？ ってことだね。
たとえば各メンバの文字列表現が取得したいのなら
そのような関数を用意すればすむ。

うっ、わかりにくかったか…。orz　例えば擬似的なコードを書いてしまうと…。

struct TEST_STRUCT
{
　int mInt;
　long mLong;
　char mChar[255 + 1];
};

void main()
{
　vector<VARIANTのような型> dstArray;
　　　　　^^^^^^^^^^^^^^^^^^^^^
　TEST_STRUCT srcData; //適当に初期化済みの状態とする
　int i = 0;
　while( 1 )
　{
　　dstArray.push_back( srcData.○[ i ] );
　　i++;　　　　　　　　　　　　　　　　^^^^^^
　}
}

こんな感じで、データメンバを「名前ではない方法」でアクセスできれば、
結構便利な使い方ができそうだなぁと思ったのでつ。
「○[ i ]」の部分って必ずデータメンバの名前で指定しなければならないから…。

dstArray.push_back( srcData.mInt );
dstArray.push_back( srcData.mLong );

…のように一つ一つ全部指定しなきゃいけないし、型に「VARIANTのような型」が無い以上、
そういうやり方すら出来ないではないでつか…。
関数にしても結局はすべて名前で指定しなければならないし…。

>>444

しまった、ループの脱出条件を書いてないから無限ループケテ〜イだ…。orz
まぁ、その辺は突っ込み入れないでちょ。

>>444
offsetof

使った事無いけど。多分。

>>444
つーか

TEST_STRUCT srcData[] = ...;

for( int i = 0; i < ...; i++ )
    dstArray.push_back( srcData[i] );

じゃなくて？

>>444
実体でなくポインタを維持すればいいなら、
std::vector<void *>dstArray;
dstArray.push_back(reinterpret_cast<void *>(&srcData.mInt));
dstArray.push_back(reinterpret_cast<void *>(&srcData.mLong));
dstArray.push_back(reinterpret_cast<void *>(srcData.mChr));
構造体のメンバの列挙は誰かがやらないといけないからねぇ。
static const unsigned sOffsets[] = {
offsetof(TEST_STRUCT, mInt),
offsetof(TEST_STRUCT, mLong),
offsetof(TEST_STRUCT, mChr),
};
for (unsigned i = 0; i < sizeof(sOffsets) / sizeof(*sOffsets); ++i) {
dstArray.push_back(reinterpret_cast<void *>(reinterpret_cast<char *>(&srcData) + sOffsets[i]));
}
これでもなんとかなるかな。

>>446
「offsetof」なんて初めて聞いた！
…と思ったらひょっとしてC++の言語仕様にはないものですよね？
ぐぐってみたらどうやら「.NET Framework」なのかな？

>>448
ふむふむ、ポインタを駆使すれば結構なことが出来そうですね。
しかしなんていうか難しいというかちょっぴり複雑に…。(^^;

基本的に私もメンバを一つ一つ指定することになんの抵抗も無かったんですが、
最近職場でBorlandC++Builderに慣れた同僚が、

「構造体のメンバって一つ一つ名前でアクセスしないといけないんですかねぇ？
　面倒くさいですねぇ」

…などと話していたので、興味を持った次第でつ。
これができるとどういうメリットがあるかという話ですが、
（C++Builderの話限定になってしまうのですが）
ＤＢの不特定なテーブルから、フィールド名を指定せずに
不特定の構造体のメンバにデータを突っ込めるため、
プログラムの汎用性が高まるということらしいです。

offsetofを知らないだけならともかく(それも問題だが)、C#って・・・
絞り込みも出来ない、googleのトップしか見ないで、２番目は無視する人かね

>>449
offsetofなんて、Cでもマクロで簡単に書ける代物なんだけど。
標準ヘッダを探してみることもできないのかな?

うわ〜ん、そんなにいじめるなぁ〜。ヽ(`Д´)ﾉ
簡単にできるというのがいいのだよ。
めんどっちいのはイヤ。

しかし、とりあえずoffsetofというマクロが
標準的に用意されてることを教えていただき、
ありがとうございますた。m(_ _ )m

クラスのメンバを、別々に、同じベクタに入れる意味がわからん

最近書き込みがないね。

重複スレだからな。

C言語とJavaとRuby使って，そこそこ書きました．
次はC++にチャレンジするかと，プログラミング言語C++を買ってきました．
難しいです．何書いてるのかわかりません．
俺の頭が悪いのが原因でしょうが，C++の難しさに挫けそうです

ヽ（冫、）ノｽﾞｺｰｯ
何処が難しいか言ってみて。
十分習得出来る知識あるように見えるけど…

>>458
>十分習得出来る知識あるように見えるけど…
んな事が >>457 読んで解るのか！ESPer でつか？

>>459
Yep

>>457
CからC++に移ったばかりの人
for (int i = 0; i < 10; i++) {
v[i] = 1;
}

C++を使い慣れてきた人
for (std::vector<int>::iterator it = v.begin(); it != v.end(); it++) {
*it = 1;
}

C++が「使える」と言えるレベルの人
std::fill(v.begin(), v.end(), 1);

これでやっと中級に入門です。先は長いです。くじけそうです。

C++のことがある程度わかってくると、++、--は前置にするもんです。

運置

>>462 どうして？

>>464
前置の方がコピーのコストがかからないから

>>465 どうして？

>>466
More Effective C++の項目6を嫁

>>467
読んでみた。ありがとう。
インライン展開されるような場合は別に気にしなくていいね。

>>461
それ見てC++の方がタイプ量多い割にたいしたこと出来ない。
Cの方が1000万倍マシと悟った。

>>469
それはちょっと勘違いだ。
C++ は C より便利だよ。

>>467
んじゃ、これから
Effective ++C
と書くことにしちくりマンボ

>>471
山田君、座布団一枚持ってっちゃって

>>468
テンプレートでの汎用プログラミングのために常に
前置にしておくと後々組み込み型をクラスにしたくなった
とき修正量が減る。

>>473
組み込み型かクラスかは別に関係ないような？

>>474
クラスだとテンポラリオブジェクトが生成されるよ。
インライン展開されてもね。

思ったよりレスが…ありがとうございます．

>>458
最初は俺も楽勝だろーとか思っていたのですが，何故か頭が受け付けません．

>>461
今の俺の書き方だと，モロ最初の書き方ですね…

>>461
C++を究めた人はアセンブリに戻る。

>>477
そういう内容のメガデモ作品があったな

>>461の二番目みたいに、全く抽象化されてもいないのに
無理やりイテレータ使う意義って、全くないように思えるんだが

インポラリ

>>457
> C++の難しさに挫けそうです
「プログラミング言語C++」の難しさに挫けそうなだけだろ。

>>479
そんなことはない。
少なくともコンテナを差し替えられる。

そんなこといったら、最初の書き方ならば
vectorを配列にさしかえれるという利点があるなｗ

>>483
vectorを配列に差し替えても、あまり嬉しくはないだろう。

速くなるやん

>>485
そういう用途なら、boost::arrayがあるから利点とはならない。

boost::rangeでcontainerとbuilt-in arrayが汎用に扱えるようにもなったしね

後からコンテナを差し替えやすいってのが利点。

コンテナの差し替えなんかするのか？ホントか？

テンプレート引数で型を受け取るときに、
どのコンテナでもOKなのは、確かに意義があるといえるが

前述の例はそういうわけでは全くないし、
正直、三つある例のどの書き方でも、優劣はないと思うが

前述の例だけみればたしかにどれでもいいレベルの話だけど、
意識の持ち方のことを言ってるんじゃないの？
できるだけSTLコンテナやSTLアルゴリズムを使おうという。

しっかし、組み込み型(intとかdoubleとか)のコンテナならSTLのアルゴリズムは
教科書通りに使えるんだが、クラスになると途端に使い物にならなくなるのは
どういうこと?
STLの範囲で済ます場合、メンバ関数ならアダプタでなんとかなるが、メンバ変数は
叙述関数・関数オブジェクトを用意しなければならない。
正直、boost::bindやboost::lambdaが無かったらやってられないよ。
でもこれも一長一短で、boost::lambdaは動かないコンパイラもあるし(bcc32)、
boost::bindは遅いし。

> boost::bindは遅いし。
なんで？

>>492
なんでだろう? 俺が聞きたいよ。
アセンブリコード見たけどよく分からん。あまり最適化されてない様子。
lambdaは早いんだけどな。
単純なlambda式なら、イテレータをループで回すより早かったりする。

>>493
テストコード出せる？

boostの一部のライブラリを見てると、素直にC++にクロージャを足した
新しい言語を作って使えよと言いたくなる。

boost使ってる時点で負け組み

>>496
何を使うと勝ち組みになれるの？
boost のめざそうとしているものを使わなくてもいいってこと？

>>495
C++Builder言語

C++が難しいのは、テンプレートのがポリモルフィズムより速いからだと思う。

http://pc5.2ch.net/tech/kako/1058/10586/1058675178.html
http://pc5.2ch.net/test/read.cgi/tech/1063323615/

>>495
templateの良し悪しはともかくとして、
言語のコアとしてそういった概念のシンタックスを
持つのではなく、メタプログラミングによって後から
追加できるのっていいなと思うけど。

このスレ見てるとげんなりしてくるなｗ

>>501
同感、クロージャーなどを突っ込むよりtemplate機能をもっと整理して
この種の機能はライブラリとして実装してもらいたい。
クロージャー以外にもデザパタ一式ガベコレ一式程度は自働ジェネレートできるくらいがいい。
言語のコアはあくまでシンプルで高速な物がいい。

VC++で計算した数値を引数で表示したいんですが、printfで表示されません。だからMessageBoxを使って表示したいんですがエラーがでます。どうしたらいいんでしょうか？どなたか分かる人教えてください。

( ﾟДﾟ)ﾎﾟｶｰﾝ

505うぜーよ！！
知らないならくるな！！！
消えちまえーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

>>504
とりあえず、現状のソース見せて。

質問した本人はそのスレ全てを覚えてるとは思えないが…(笑)

「ファイアーエムブレム」は難しすぎ
http://game.2ch.net/poke/kako/1020/10203/1020340325.html
Linuxは難しすぎ
http://pc.2ch.net/linux/kako/1025/10252/1025263879.html
三連複は難しすぎ
http://cocoa.2ch.net/keiba/kako/1025/10252/1025257025.html
メモ帳は難しすぎ
http://pc5.2ch.net/test/read.cgi/win/1101205340/

C++はSTLと継承を使いこなし始めた辺りが
生産性・理解向上の分水嶺だった記憶がある。

>504
ConsoleとWinアプリは違うから。
デバイスコンテキストをキーワードに勉強しる。

あとこの手の質問はVC++のスレ・・・って適当なの無いな今は　MFC限定しか

>>511
★初心者にVisual C++を教えるスレ★ Part16

C++には、他に類を見ない自由と絶対的な○○が与えられている。

C++の機能限定版とか無いの？

>>514
例外、クラス、関数オーバーロードや
デフォルト引数などの機能を取り除いた
C というものがあります。

>>514
EC++なんてものもある。
http://ja.wikipedia.org/wiki/Embedded_C_Plus_Plus

>>516
だがしかし、はっきり言ってウンコだ。

>>516
例外処理が省かれてるのが最大の問題だな。

>>518

テンプレートも名前空間もない。
実際にEC++環境があったのでコーディングしてみたことがあるけど、
全然C++らしくない。

まああくまでもembeddedだからねえ。

時々、ECMAScript をバイナリに落とすことが出来ればと考えることがある。

obj = new Object;
obj["Method"] = function( a, b )
{
　echo("OK");
}

obj.Method(); // OK

441 がやりたいことも、プロトタイプ取得で簡単OK

漏れの考えはこうだ！

>461 様の例で「ＣからＣ＋＋に移ったばかりの人」の書き方は
いかにも効率が悪そうな印象を受けるけど、
漏れが「仕事で」プログラムを作るなら、
迷わずこのやり方を取る。
（かなり馬鹿にされるだろうけど…。）

そして趣味で（個人的な事情で）プログラムを作るなら、
「Ｃ＋＋を使い慣れてきた人」や「Ｃ＋＋が『使える』というレベルの人」のような
書き方ができるように努力するだろう。

なぜなら仕事でプログラムを作り、それを他の技術者に引き継ぐ場合、
単純な書き方がもっとも無駄な手間を省くからだ。

そして多くの場合、理解しにくいバグの発生を予め抑制することができる。
また、改修を加えるときや、
不幸にしてプラットフォームの異なる環境へ移植する場合にも、
少ないコストで作業を終えることができるであろう。

スレ違いで申し訳ないけど、
引継ぎ作業によるコストって、
プログラムの書き方で随分変わるんですよ。

「凄いＣ＋＋技術者」の書いたプログラムを引き継いだ場合、
「凄くないＣ＋＋技術者の私」が改修を加えるのは大変なんですよ。

>>522
ごく普通なC++プログラマな私からすれば、他人のソースを引き継いだときに
ループが書いてあったらそれだけで要注意項目になります。
std::fillならそのまま読み飛ばせる分だけ、引き継ぎコストは抑えられるわけですな。
構造体も然り。初期化処理をその構造体を利用する側でやらなければいけないよりは
コンストラクタを書いておいてくれたほうがよっぽど確実。
まぁ、「凄くないC++技術者=C++をベターCとしてしか使えない技術者」というなら別ですが。

ようするに522が凄いC++技術者になればいいだけ。

なんで一時オブジェクトは非const参照に変換できないんだ
template<typename E, typename T, typename A, typename Value>
inline std::basic_string<E, T, A>& ToString(std::basic_string<E, T, A>& rstr, Value t) {
　　return rstr = static_cast<std::basic_ostringstream<E, T, A>&>(std::basic_ostringstream<E, T, A>() << t).str();
} //static_castしないとエラーを吐く。これはコンパイラのせいだと思う。
#define ToStr0(t) ToString(std::string(), t)

template<typename E, typename T, typename A, typename Value>
inline std::basic_string<E, T, A>& ToString(std::basic_string<E, T, A>* pstr, Value t) {
　　return *pstr = static_cast<std::basic_ostringstream<E, T, A>&>(std::basic_ostringstream<E, T, A>() << t).str();
}
#define ToStr1(t) ToString(&std::string(), t)

int main() {
　　cout << ToStr0(5) << endl;　　//エラー：一致するものが見つからない
　　cout << ToStr1(.125) << endl; //OK
　　return 0;
}
って書こうと思ったんだよ。
そしたらふと思いついてこうしたら動くんだよ。
#define ToStr0(t) ToString((std::string&)std::string(), t)
頼むからこんなのキャスト無しでも適当にやってくれよ。

そもそもオブジェクトを値渡しで返そうとするとインライン展開できない
ってのがなけりゃこんなことで悩む必要は無かったんだよ＞Borland

それはインライン展開しない方がいいと思うが。

つうか、boost::lexcal_castとか素直に使った方がええんじゃないの？

>>526
lexcal_cast.hppをインクルードするとエラーになってしまうもんで。

>>525
> //static_castしないとエラーを吐く。これはコンパイラのせいだと思う。

ostream に対する operator << の戻り値は ostream& だから、
コンパイラに依らずエラーになるはず。
一時オブジェクトで処理しようとしているのが間違い。

>>523
for ( xxx i = foo.begin(); i != foo.end(); ++i.) {
　nannka(*i, arg1, arg2, arg3);
　kannka(*i, arg4, arg5);
｝

こんなのは、NGで
一回しか使わんつまんねえファンクタわざわざ宣言して
for_eachなりつかわんとNGなんだよな？

アンタがそうゆう主義なのはかまわんが
それがごく普通かねえ？

つうか、実務経験なさそうなふいんき

>525
形式的には、一時オブジェクトは右辺値なので非 const 参照に変換できない。

非 const 参照→呼び出された側で変更される
＋
一時オブジェクト→もともと定数だった可能性がある / すぐに破棄される
＝定数のものを変更しようとしている / 変更された値が破棄される
ということでデフォルト安全側に倒してるんじゃないでしょうか。

>>529
んにゃ、一々ファンクタ書くまでもない処理ならループでもいいんでない?
ただ、ファンクタもいらんような単純な処理まで一々ループを書くなって話。
適切な比較オペレータを持っているクラスだというのに一々findループを書く神経は疑うってことね。
まぁ、>529の例ならファンクタ書かれるよりはループで書かれた方がよっぽどまし。
更に言えば、for (int i = 0; i < foo.size(); i++) なんて書かれるよりずっとまし。

そこでlambdaですよﾜﾗ

>>531
しょーもないことにこだわってるあたり覚えたての学生とみた（遠い目

「まし」とか繰り返して、さも自分にはもっといい案があるかのように匂わせておいて
結局そのまま書かずに退散するのが「らしい」ですよね ;-)

んー、ないよ〜
単にどっちがいいかって書いただけだし。
ファンクタを作らなくてもalgorithmのfind使えるケースで自分でループ書くのや
iterator使わずに制御変数でループを回すのが要注意だって話で。
>529の例ならそれでなんも問題ないんでない?
#そもそも私自身がファンクタ作るの苦手だw

C++よりMLの方がいいよ。

まあバランスが大事だよな

Ｃ＋＋はすさまじく肥大化した言語。しかし、慣れると機能が多くて便利なのも事実だったりする。
シンプルといわれていたJAVAもバージョンが新しくなるにつれて肥大化が進んでいる。
Ｃ＃はＣ＋＋から機能を削ったとはいえ、機能を付け加えているから最初から肥大化している。
機能が多い言語は必ず肥大化し、複雑になってしまう。

シンプルで初心者に優しいけど「不便な言語」よりは、複雑で便利な言語のほうが良いと思が、
複雑な言語は初心者には優しくない。

初心者にやさしい「複雑な言語」があれば望ましいけど、それは無理かもしれない。

>>538
(行き着く先は)自然言語。
そして曖昧さと冗長性が増える罠。

シーピーピー　シーピーピー　シーピーピー　シーピーピー
シーピーピー　シーピーピー　シーピーピー　シーピーピー
ろ　く　な　も　ん　じ　ゃ　ね　ー

負け犬?

int n;
n.~int();
これがコンパイルを通ってしまうのに驚いた。
こんな関数にint型の値を渡してもコンパイルが通ったからまさかと思ってやってみたら通った。
template <class T>
void Destroy(T& t)
{
　　t.~T();
}

>>542
VS.net2003だと下のテンプレ関数のみ通った。
n.~int();は error C2059: 構文エラー : ''<L_TYPE_ambig>'' って出る。

テンプレートじゃなくても通るのが正しいような気がする。

>>538
今ならまだＤ言語のライブラリは少ない…貧弱

C++もなにかしようと思ったら機能が貧弱だよ
GCもないし、拡張工事をせざるを得ない
良くも悪くもCなんだな

>>546
そうだね、あせんぶらにもGCつければべんりだね（わら

>>546
そうじゃなくて、君の頭じゃC++は無理なんだよ。

何見当違いの煽りをしてるんだか。

javaは.closeを書かせておいてGCがあると
主張するのは無理がある。同期のコードなんてCそのものだ。
そういえばGenericsもプリプロセッサで実装しているし
assertの実装は失笑である。javaは新しいCなのだろう。
DはRAIIというのがあるようだ

C++はむずかしいので、機械語で書いてます。

>551
俺にはそっちの方がムズい…

BCBのヘルプに
「alloca 関数の使用はあまりお勧めできません。」
って書いて有るんですけど、そうなんですか？

>>553
スタックを食い潰すし、移植性に乏しいからでは?

C99ならVariable Length Arraysを使ったほうが良いかと。

C++ならstd::auto_ptrを使ったほうが良いかと。

仮想関数を使えばswitch-caseの嵐から抜けられるわけで、個人的にはそれだけで大満足です。

>557
だね。場合分けをすることなしに、異なる振る舞いを事前に記述して、コンパイラ任せにできる
有利性、というか。

でも、その有利性を理解できない層というのも確実にあって、それは何かっつーと、
仮想関数という概念、というか言語仕様を知らない層なんだよね。C++はもちろん、
Javaも知らないという層。switch-caseで、あり得る場合分けが全部ソース上に
明記してあった方が判りやすいしデバッグしやすいじゃん、と主張してきそうな、
えてしてそういう層が実装仕様を決めやがるんだよなあ。おっとこれはグチだな。すまん。
誰か強力に布教してくんねーかな。俺はもー疲れた。

>>558
無理。そういう層は大抵「学習意欲」＜「日々の仕事をこなすこと」だから。

switch-case の代わりとしての仮想関数なら C でも出来るわけで。

>>560
だからどうした？

C++儲のおいらでも560には半分同意。
switchの代わりなら構造体+関数ポインタでも
それほど労力がふえるとも思えない。
勿論、仮想関数の方が楽なのは事実だけど。

むしろ、Cで困るのはコンストラク・デストラクタ・templateがない事。
auto_ptrを見ても分かるようにデストラクタが非仮想であっても、
templateと組み合わせればものすごく便利になる。
これが無い故に生成と破棄がセットになったリソースを複数作る
処理で、生成失敗時の破棄処理を書いてるとうんざりする。

要するに、リソースリークを避けるための下らない労力、プログラムの本質
から大きく外れたロジックやコードがCでは多くを占めてしまうってこったよな。
文字列やリストなんて単純なものも、Cでは悩みの種だ。

まあメモリリーク回避だけならGC使う手もあるがなー。
GC使えるような環境なら今時Cなんて使うなよという話もあるが。

この速度ならぬるぽ

>564
ｶﾞｯ!
ちゅーかまたお前かっ！

sageてぬるぽもなかろうに
それよか、こんな過疎スレで
sageぬるぽに3分でｶﾞｯした565の方が神

int main()
{
  std::locale::global(std::locale("japanese"));
  _bstr_t bs(L"ほげ");
  std::wcout << bs << std::endl; //static_cast<const wchar_t *>(bs)とすれば無問題。
  return 0;
}

VC7.1だとbsはconst wchar_t *か悪くてwchar_t *へ変換されるかと思いきゃ、
なぜかこれに解決される。せめてconst wchar_t *とであいまいにしてくれよ。
template<class _Elem, class _Traits> inline
  basic_ostream<_Elem, _Traits>& __cdecl operator<<(
  basic_ostream<_Elem, _Traits>& _Ostr, const char *_Val)

今更だけどブロック内での関数宣言を廃止し、全て変数宣言と見なすという仕様にすれば良かったのにと思う。

>>568
そのメリットは？

>>569
コンストラクタ呼び出しで作った一時オブジェクトでローカル変数を直接初期化できる。

struct S0 { S0(); };
struct S1 { S1(S0 zero); };

int main()
{
　S1 x(S0()); // 現行の規格では関数宣言
　...
}

>570
S1 x = S0(); で回避できると思うけど、いちいち気にするのがいやってこと？

>>571
その書き方だと暗黙の変換とコピーコンストラクタが必要になる。
S1を↓のようにするとコンパイルできない。
struct S1 { explicit S1(S0 zero); };
struct S1 { S1(S0 zero); private: S1(S1 const&); };

>>569
ブロック内で関数宣言する奴なんて見かけない。みんなヘッダをインクルードする。
570みたいなコードは誰もが最初変数宣言だと思ってはまる。
それだったら全部変数宣言にするほうが、わかりやすいんじゃないかと考えた。

たとえば「ブロック内では関数宣言をしたければexternを付ける必要がある。
externなしで関数・変数宣言どちらともとれるときは変数宣言」とでもすればよかったのにと思う。

>>573
Cとの互換性を最優先した結果、なんだろうなあ。

>>570
S1 x((S0()));

()の2バイト分も面倒か？

対処法の有無はこの話題には関係無いだろう。

>576
その対処法によって、570のいう、
> コンストラクタ呼び出しで作った一時オブジェクトでローカル変数を直接初期化できる。
ことができない(実際にはできる)という、現行規格への不満が解消されるのだから関係ある。

まぁ570が、一時オブジェクトをローカル変数のコンストラクタに渡す文法を知らなかっただけのようだが。

知ってたよ。

一見変数宣言に見えてしまうややこしさを問題としてるという論点に気付かない>>577を暖かく見守る俺が579ゲットですよ

結局568の主張は、
とくに機能的な違いはないけど、今の文法は見た目がわかりにくいから、
ブロック内での関数宣言を廃止し、全て変数宣言と見なすという仕様にすれば良かったのに
ってことなのね。

ぱっと見のわかりやすさは重要だと思うけど、もう二重に括弧つける癖がついたんで、どうでもいいかなと思う。
>579 サンキュー。これからも暖かく見守ってください。

このスレの人たちは英文をバリバリに読めるのか？
俺全然読めない。

英語しかなければ読むけど、ちょっと下手という程度なら日本語に喜んで飛びつきますが何か。
規格だってISOではなくJISの訳を読むし。

キチガイ翻訳はお断りだが

>>583
じゃお前が翻訳してくれ

それが出来りゃ原書読むわい

糞　ス　レ　勃　て　て　ん　じ　ゃ　ね　え　よ　脳　挫　傷　！

>>586
今頃何言ってんの？m9(ry

ﾌﾟｷﾞｬ（ｒｙ

OSのベータ版を市販するやり方は
どこにもマネできないくらい最強

JavaScriptは難しすぎ
http://pc8.2ch.net/test/read.cgi/hp/1132400636/

ポインタと参照を混ぜるとややこしいから、ポインタで統一してるんだけど
参照しか使えない場合もあるしなんなんだよ！！

俺はなるべく参照を使って、仕方ない時だけポインタを使う

あっそうかスマートポインタ使えばいいんだって使ってるプロジェクト
見たことねえorz

もっともっと難しくなって構わないから早く来いC++0x。
なんてこのスレで言うとぼこぼこにされそうだ。

C#に慣れてきたらC++触るのﾃﾗダルくなってきた…
つーか、同じVisualStudioなのにエディタの出来があからさまにVC#＞＞＞＞＞＞VCなのは何の嫌がらせだよ

>>595
(ﾟ∀ﾟ)人(ﾟ∀ﾟ)ﾅｶｰﾏ

>>595
Ｃ＃はＭ＄が作った言語だからＪａｖａ、Ｄｅｌｐｈｉ潰しをしながら
普及のために本気にならんといかんのだよ
Ｃ＋＋についてはＭ＄の都合におかまいなく拡張されたりするから
ほんとはサポートすんのヤなの
だけどＣ＃がコケた時の保険のつもりで一応サポートしとくの
これが戦略。わかる？
ほんとはＣ＃、ＶＢで世界を支配したいの
あとはオマケ

>>597
2バイト文字使うなら
せめて♯を使えよと。

エディタはEmacs系を使えばいいのだ、勝手に補間するVSの親切エディタとは手を切れ、
あれは人を堕落させる。

>>595
言語仕様が複雑でC#よりﾏﾝﾄﾞｸｾからじゃないかなあ。

>>595
なんか、MSはC#を無理やり推し進めている感じだしね。
FXではWIN32 API呼ぶのにオーバーヘッドがあるようだし・・・

つーかアプリのパフォーマンスにAPIのオーバーヘッドなんざ
ほとんど関係ないと思うが。処理の9割以上は自分のコード
の中だろ？

だから、３０歳過ぎて、社会の政治的な要因に太刀打ちできるような
立場になってからもデザインパターンみたいな一技術で重宝されるような
人物に対して「逃げ道だよな」って言ってるの。２０代の奴がやりたくてもできないような
ところで自分をアピールする術を持ってないのかって。
中堅者のやることっていったら、２０代の奴が仕事をしやすいように、いろいろと根回しすることだろ？
年齢重ねても、やることが２０代の延長だったら会社に居る意味ねーよ。
スパゲティコードだとか、その辺は中堅社員が口出すことじゃねーって。
むしろ、２０代の奴が気付いて、中堅社員に意見をＵＰして、それから中堅社員が根回しするのが理想。
要は、いい歳こいて低レベルな話してんじゃねーよって。もっと抽象的になれってことだ。

>>603
> だから

まで読んだ。

>>603
日本語でおｋ

日頃誰にも吐き出せず溜め込んでいたモノを一気に吐き出したようだが、
そうやって長年熟成させてきた割には深みゼロなのが哀しいね。
まぁ、この程度の頭だから、誰にも認められずストレス溜めてるんだな。

>>603
デジャブか。
どっかでみたレスだ。

>>606
では君が深みのある話をしてくれ。ぜひ読みたい

>>608
「では」の使い所が変ですね。

>>603
> 「で

まで読んだ。

普通に603より609のほうが深いのが悲惨だなｗ

>>609
ではどうすれば正しいのか教えてくれ

その使い方は正しい。>>608は変。

>>613
どう変なのか説明よろ

繋がりがまるでない。

>>614
批判に対して「じゃあお前がやってみろ」というのは
反論にも何にもなってないわけですが、
小学生くらいだと別におかしいとは思わないようですね。

お前らもっと生産的なことに労力を使うように汁。

C++を使いはじめて10年以上になるが、
これまでC++をC++として使える奴って未だ見た事がない。
このスレでC++を絶賛している奴は本当にC++を使いこなしているのか疑問。

2chだし、ピンキリいると思うよ。

そもそも何を持ってC++をC++として使っているというのかが曖昧。

2chでなくてもピンキリ
ttp://sourceforge.jp/softwaremap/trove_list.php?form_cat=165

>>618
おまいの周囲の連中のレベルなんか知ったこっちゃないが
>このスレでC++を絶賛している奴は
「絶賛」する奴 (いたっけ？) は信用するな。
見た目だけで「あいついい女だよな」っつってる奴は
その女と付き合ってるわけではない。

そもそもオブジェクト指向が難しすぎ
gotoを使って何が悪いんだ

>>623
それはない。

>623
オブジェクト指向とgoto不要論を同じレベルで論じるなよ

>>595
>つーか、同じVisualStudioなのにエディタの出来があからさまにVC#＞＞＞＞＞＞VCなのは何の嫌がらせだよ
だよな

C++の標準化委員会は冒険的に過ぎるところがある。
C++がこれだけ強力な言語になったのは彼らの力だけど、
いろいろと取り返しの付かない失敗をしている。
slice_arrayで大恥をかき、exportや<cNNN>ヘッダで実装者を悩ませ、
言語仕様の穴を利用してauto_ptrを実装してしまう。
koenig lookupなんかは、ライブラリの設計ミスを言語仕様側で
取り繕おうとして傷口を広げた例だね。
もう少しやる気の無い連中、あるいは後方互換性にこだわらない連中が
標準化をやっていればこんなに難しい言語にはならなかっただろうに。

で、C++のどこが難しいんだ？
クラスが分からないのか？

>>627
概ね頷けるところだが、
> koenig lookupなんかは、ライブラリの設計ミスを言語仕様側で
> 取り繕おうとして傷口を広げた例だね。
これだけ、聞いた事が無い話だった。
何のこと？

>>627
>後方互換性にこだわらない
ここ同意

後方互換性は、言語使用の複雑さの原因であることは確かなんだが
普及の速度には大きく貢献してるだろうから、単純に否定できないと思うんだ。

まぁ、実際に携わってみれば誰もが苦しむところだろうな。

>>631
まあそうなんだけど、予約語の使いまわしが
初学者を混乱させてんじゃないかな、と。

ケーニヒがなかったら
a + 1 // OK a.operator+(1)
1 + a // NG
my_namespace::operator+(1,a) // OKだが書いてられるか

D&Eを読めば嫌と言うほど互換性確保に努めてきた様子がひしひしと伝わってくる。

初学者のためにOSのカーネルがコンパイルできなくなるなんて
許されないからな

>>629 >>634
operatorやswapをこんな感じにしておけばKoenig lookupは要らなかった。
lessを提供すればless_equalも勝手に実装してくれるとか、
そういう仕組みを作ることもできる。

namespace std {
    ...
    namespace hooks {
        template <class T1, class T2>
        struct plus_traits;

        template <class T>
        struct plus_traits<std::complex<T>, std::complex<T> > {
            typedef std::complex<T> result_type;

            static std::complex<T>
            plus(const std::complex<T> &a1, const std::complex<T> &a2)
            { ... }
        }
    }
}

template <class T1, class T2>
std::hooks::plus_traits<T1, T2>::result_type
operator+(const T1 &a1, const T2 &a2)
{ return std::hooks::plus_traits<T1, T2>::plus(a1, a2); }

>>637
それだと operator+ を定義していないクラスに + を使おうとしたとき、
plus_trais についてのエラーメッセージが出るよね？それもなんかおかしくね？

>>637
わざわざstd::huck::plus_traitsに持っていく意味がわからない。

>>638-639
std::hooksに含まれているテンプレートを部分特殊化してくれって意味。
オーバーロード解決に相当する処理をテンプレートで実装する必要があるから、
現行C++の機能だけで完全に実現できるかは分からんけど、
必要ならコンパイラにいくつか機能を追加すればいい。

>>640
コンパイラに koenig lookup を追加すればいいってことだな。

>>640
その意味はわかるけど意図が判らない。
直接operator +を特殊化すればよいのではないかと思った。

>>637
これはこれで一時期は真剣に考察されていた案ですけれど，
結局「分かりにくい」ということで一度標準委員会で否決されているんですよね．
swap の場合ですけれど．

特にデフォルトがない hook の場合，特殊化に基づく hook の提供は
exact match を要求する，つまり特殊化したい型それぞれに
いちいち全部特殊化を用意しなければならない
（これは base-derived や cv-qualification まで含めて厳密にやらないといけない）
のに対して， ADL による hook は loose match で済む，
例えば base に対する特殊化が derived に自動的に適用されるような
直感的なあり方に一応適合します．
この議論は関数テンプレートの部分特殊化 (FTPS) が導入されても
基本的な議論の流れに大きな変化はないでしょう．
（というか，クラステンプレートの静的メンバ関数を用いるそもそもの動機は，
FTPS が現行規格で存在しないことの workaround だったはずです）

もちろん ADL による hook の提供の場合も，一般に挙動が非常に予測しにくい，
つまり，名前空間お構いなしでありとあらゆる名前空間を潜在的にぶち破る
凶悪な特性を持ちえることと，一般に汎用プログラミング特有の構文指向な面が
強く出る （hook がどう定義されているか （signature-oriented） ではなくて
hook をどう呼び出したか (syntax-oriented) に意味が左右されやすい）
という非常に大きな欠点を抱えるのも確かです．

>>637
より踏み込んだ議論として，そもそも hook の所有権・所在の
あり方に関する議論もあります．

特殊化に基づく hook の提供の場合，特定の名前空間に hook の所在が
固定されますが，それはそもそも正しいのか？
全く関係の無いサードパティが提供するヘッダとプライマリテンプレートに依存し，
その名前空間を開けて hook を提供しなければならなくなる状況も想定され，
それは本当に正しいのか？という疑問です．
そういう意味では ADL による hook があらゆる名前空間を
潜在的にぶち破る特性を逆手にとって，
「大域の ADL hook 用名前空間 （global ADL namespace） に hook をおく」と
考えることも， hook の所在の中立性という観点からは
あるいは悪くないともいえます．

少なくとも「ライブラリ設計の欠点とその補完としての ADL」という観点は
少し視野が狭すぎるような気がします．

>>642
operator+ には特殊化するべきプライマリテンプレートがそもそもないです．
また，関数テンプレートの部分特殊化が現行規格に存在しないために，
一般にクラステンプレートに対して関数テンプレートを特殊化することができない，
という事情もあります．クラステンプレートの静的メンバ関数を
わざわざ持ち出すのは，関数テンプレートの部分特殊化の
エミュレーションのためだと思ってもらえれば良いかと思います．

>>643-644
> ADL による hook は loose match で済む，
こいつの解決策だけど、
案1: オーバーロードを追加するとき、新しい名前を導入したとみなさないで
部分特殊化と同様に扱えるような構文を導入する
lazyoverload operator+;
namespace std {
    ...
    namespace hooks {
        lazyoverload swap;

        template <class T, class Alloc> void
        swap(std::vector<T, Alloc> &a1, std::vector<T, Alloc> &a2)
        { a1.swap(a2); }
    }
}
template <class T> std::complex<T>
operator+(const std::complex<T> &a1, const std::complex<T> &a2)
{ ... }
コンパイラから見ればKoenig lookupとほとんど同じ機能だから、
実装は不可能ではないはず。

案2: typeofなどの機能を導入してオーバーロード解決の機構を
テンプレートから活用できるようにする
template <class U>
struct plus_traits<std::complex<int>, U> {
    static std::complex<int>
    plus(const std::complex<int> &a1, int a2)
    { ... }
    static std::complex<double>
    plus(const std::complex<int> &a1, double a2)
    { ... }

    typedef typeof(plus(const std::complex<int> &, U)) result_type;
};
実現性がどの程度なのかは分からんけど、可能ならテンプレートの力はかなり増す。

>>646
>>643さんが指摘されてる、クラステンプレートの部分特殊化による手法の問題は、
class Aに対してstd::hooks::???_traits<A>を実装したとして、
その後AのサブクラスであるB,C,...Zを作成した際に
全く同じstd::hooks::???_traits<B>, ... std::hooks::???_traits<Z>を
実装しなければならないということだと思うのですが。
この点、ADLの場合は基底クラスを引数にとる関数一つで用は足ります。

派生クラスと基底クラスの関係は、
オーバーロード解決では考慮されますが（部分）特殊化の解決では考慮されません。

>>643のコードを見る限り、operator+(T,T)の部分特殊化として
operator(const complex<T>&, const complex<T>&)を定義しているようですが、
これでは、>>643で言及された問題は解決できません。

ただし、ADLがない世界を仮定して、更にlazyoverload云々を無視して
普通のオーバーロードだと考えれば、>>643の問題はないように思います。
これは、hook用名前空間を１ヶ所用意して、
特殊な動作は全部そこに書く/書かせるということと同じでしょう。
もちろん名前空間の内部が第三者によって手を加えられる（特殊化ではなく）という問題はありますが。

>>648
普通のオーバーロードだとこれが動かない。
template <class T>
std::complex<T> operator+(std::complex<T> a1, std::complex<T> a2);

namespace std {
    template <class T>
    struct plus : public std::binary_function<T, T, T> {
        T operator()(const T &a1, const T &a2) const
        { return a1 + a2; }
    };
}

template <class T>
std::valarray<T> operator+(std::valarray<T> a1, std::valarray<T> a2);

>>649
std::plus::operator()内のa1+a2のことを言っていると思いますが、
いまいちよくわからないので、推測しながら答えます。

まず、complexのoperator+が、
plus内部から解決されないことを問題にしているのであれば、
>ADLがない世界を仮定して、
ということです。
もう少し補足すると、ADLがない結果として、
std名前空間内にoperator+がないことも仮定しています。

また、valarrayのoperator+が最後に定義されていることから、
two phase lookupを問題にしているとも推測できますが、
それでも特に問題がないのではないでしょうか？

どこを問題にしてるかを明らかにしてもらえれば、
より有意義に議論できると思います。

よく考えてみたら、ADLがない場合には
two phase lookupの挙動が変わりそうな気がしてきましたが
そこまでは考えていませんでした。

>>650
plusからはcomplexのoperator+は見えるけどvalarrayのoperator+は見えない。
646で書いたlazyoverloadというのはoperator+を全部見てくれという意味。

>>652
一応確認しておきますが、通常のC++における>>649のコードの問題点は、
両方のoperator+がstd名前空間内にないことですよね？
>>649の"ような"コードでは、complexのoperator+もstd::plus::operator()からは呼ばれませんし、
（>>649のコード単体ではcomplexのoperator+は呼ばれますが、
　std::basic_string等のoperator+がstd名前空間内に定義されてしまうと呼ばれなくなる）
逆に、両方のoperator+がstd名前空間内にあれば、両方ともplusから呼ばれます。

で、本題に戻りますが、>>643で指摘された問題点と
lazyoverloadには何の関連があるのでしょうか？
今の段階では、
> ADL による hook は loose match で済む，
という部分を勘違いされているように思えます。

あと、
>lazyoverloadlazyoverloadというのはoperator+を全部見てくれという意味。
の全部というのは、名前空間を無視して全部ということでしょうか？

>>653
>>643の問題を普通のC++で解決するのが大変or不可能であることは認識している。
で、その解決策として部分特殊化でなくオーバーロードでhookを実現
できるようにする(>>646)か、メタプログラミング向けの機能を追加する(>>647)
ことを考えた。
> >lazyoverloadlazyoverloadというのはoperator+を全部見てくれという意味。
> の全部というのは、名前空間を無視して全部ということでしょうか？
lazyoverload宣言をした名前空間の中だけ。解決したいのは次の問題。
namespace nnn {
    int fff(int) { return 0; }
    template <class T> int good() { return fff(T()); }
    template <class T> int bad() { return nnn::fff(T()); }
    int fff(char) { return 1; }
}
と定義されているとき、nnn::good<char>()は1を返すけどnnn:bad<char>()は
0を返してしまう。テンプレートを定義した時点で見える関数だけでなく、
インスタンス化した時点で見える関数を全部候補にしてくれ、というのが
lazyoverloadの意味。

>>654
標準準拠のコンパイラでは、
そのコードでは、nnn::good<char>()も0を返すはずです。
というのは、point of instantiationの文脈で名前解決を行うためには、
unqualifiedな関数呼び出しで（これはOK）、かつADLを介する必要があります。
しかし、charにはassociated namespaceがないため、ADLが行われません。
その結果、point of definitionの文脈で名前解決が行われます。

というのを昔、>>643の中の人（多分）にどこかのスレッドで教えてもらった記憶があります。

ちなみに、>>643に対する一つの解決法として
現在、boost.rangeなどで使われているものがあります。
lazyoverloadによる結果と違うのは、
fundamental type用のフックが定義できるかどうかということでしょうか。

>>655
>現在、boost.rangeなどで使われているものがあります。
>lazyoverloadによる結果と違うのは、
>fundamental type用のフックが定義できるかどうかということでしょうか。

あと、フック関数の定義される場所が
１ヶ所の名前空間になるか(lazyoverload)
複数の名前空間にまたがるか(boost.range)ということでも違いますね。

>>655
> そのコードでは、nnn::good<char>()も0を返すはずです。
これですね。勉強になりました。
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#197
> fundamental type用のフックが定義できるかどうかということでしょうか。
ADLが利用できて、operator以外であれば、フックにダミーの引数を入れて
無理矢理ADLをやらせる手がありますね。
namespace hooks {
    struct hack;
}
template <T> int really_good() { return fff(hooks::hack(), T()); }
struct hooks {
    int fff(hack, int) { return 0; }
    int fff(hack, char) { return 1; }
}
struct abc {
    struct A {};
    int fff(hooks::hack, A) { return 2; }
}

lazyoverload を持ち出している方の動機は一応理解できているつもりです．
ですが， lazyoverload という提案はあくまで今手に入る
言語の仕様ではないので，これに関する議論は少し避けさせてもらいます．
提案自体に対しても，特に後方互換性の点で色々あら捜しはできるかとも
思いますけれど，それも指摘したところであまり実になるとは思わないので，
もうちょっと一般的なことをつらつら書かせてもらいたいと思います．

hook をある名前空間に集約するべきか，あるいは
あらゆる名前空間（associated namespace）に散在させるべきかは
一般に非常に難しい問題だと思います．
例えば swap という hook を考えたとき（これは現行規格の文言では
ADL 経由で発見される hook であるとは明示されていませんが），
swap という操作は問題ドメインをほとんど限らない非常に一般的な操作・概念で，
1つの名前空間に集約する方向性はそれほど正しいとは思えない．
どちらかというと各ユーザ定義型の associated namespace においておくほうが
おそらく正しい． std 名前空間に集約するという方策もある意味中立性が高いので，
std 名前空間に swap という hook を集約してしまう考え方もあるかとは思いますが，
そうした場合，今度はそれまで考慮されてこなかった新しい hook が登場してきた
場合に，その hook をどこに集約するべきなのかという問題が常についてまわります．

もちろん ADL による hook でも問題はあります．
先の swap を ADL 経由の hook とする場合，あらゆる名前空間において
"swap" という名前の非メンバ関数の意味を潜在的に予約してしまいます，
これのため，あらゆるドメインで "swap" という名前に対する共通のコンセンサス
（つまり2つのオブジェクトの状態を交換するという操作の名前であるという共通認識）
が取れるという（楽観的な）前提が必要になります．
実際， swap に対する将来的な規格の方向性は現在のところこの立場のようですが，
一方でこの話を金融関連のドメインで仕事をしている方たちにしたところ，
「swap という言葉は金融関連のドメインではまったく違う意味で使われる
（ので swap という名前に共通のコンセンサスが取れるという認識は甘い）」
と異論がきてしまった，という話もあったようです．
swap という非常に一般的と思われる名前1つでこの状況ですから，
おそらくある名前を全ての名前空間で潜在的に予約してしまう ADL hook のあり方は
一般には非常に受け入れがたい．
現在， Boost.Range などで導入されている ADL hook の名前では，
この問題を避けるため，マクロの名前規則を髣髴とさせる
boost_ なんて prefix が付いています．
しかしこれでは ADL による hook の大きな利点であった
「hook の所在の中立性」をかなり殺してしまっています．
実際，この観点から名前を boost_begin じゃなくて range_begin にしたら？
という議論も見受けられます．

ライブラリ設計を考える上でユーザの使い勝手は非常に重要で，
そして hook をユーザにどう提供させるかはまさにライブラリの
インタフェース設計そのもので，ユーザの使い勝手に直結する部分だと思います．
今ここで議論されている方々は造詣が深く，
hook の提供における問題点を把握され整理されておられるので，
>>646 >>647 >>657 といった手法も自然に受け入れられ，
各々の手法の長短も理解されておられますが，
世間一般の大多数から見れば非常に理解しづらい難解な問題であり，
ライブラリ利用者の立場でこれらの手法を利用して
hook を提供しようとする場合，大多数はいわゆるバッドノウハウ，要するに
「関心のある問題の解決に直結しない，不必要に難しい手法と知識」
としか評価してくれないかと思います．
そしてこれはそのままライブラリ全体の評価に直結すると思います．
こういった，特にライブラリを利用する上でのバッドノウハウは
うまく隠蔽できるならばそれに越したことはないかと思います．
ADL hook はもちろん色々な問題は抱えますが， 利用者の立場から見れば，
他の手法と比較しても，次善策としてはある程度妥協できるレベルに
あるんじゃないでしょうか？

Boost.Serialization では，アーカイブのバージョンを指定する引数に
>>657 で示されているような hack を巧妙に隠蔽することで，
two-phase lookup での問題を解決しつつ， hook のためのオーバーロードを
boost::serialization 名前空間に集約させることに成功していますが
（ライブラリ作者の名前から Ramey trick とか呼ばれることもあります），
あのレベルに到達して初めてライブラリのインタフェースとしては
成功と言えるのではないかと思っています．
もちろん，あの手法は非常に特殊な状況で偶発的に成功した例だと思いますので，
汎用性が全く欠けていて応用が利かないのですが……．

個人的にはこれらの問題は C++ の言語規格あるいは
C++ のライブラリ設計を原因とする固有の問題だとは思っておらず，
（C++ の）汎用プログラミングにおいて非常に重要で魅力的な特性である
"non-intrusiveness" を成立させつつ，なおかつ hook をどう提供するか，
を考える上でかなり本質的な問題だと思っています．
将来的な言語機能の追加も視野に入れてよいならば，例えば
コンセプトに基づく特殊化・オーバーロードといった C++0x での
機能追加があるいは問題解決の1つの糸口になるのではないかと
個人的には思っています．

ドラゴンボールにたとえてもう一回プリーズ

神様、宇宙人、人造人間、とさらに強い敵を出すために世界観が滅茶苦茶。
技もどんどんインフレになっていき、何が強くて何がよわいのか、序列や使い方
が良くわからん。つまりドラゴンボール状態。
C++ is Dragon Ballというのは、アメリカのカンファレンスで良く聞くジョークでも
ある。

（拍手）

よく聞くのかよ

毎日な

『ゴクウが教えるC++』という書籍では、継承を説明するのに、サイヤ人←スーパーサイヤ人と
いう誰でも思いつきそうな例で説明されているらしい。

例えで説明してもらわなくても、シンプルなソースと実行結果があれば概念なんて直ぐわかっちゃうのに。
例えての説明で一番分かってもらえるのは、既に知っている人なんだけどな。
しかもC++はあまり難しくないと言う罠。

C++の難しさはbetterCとしても使えてしまうところじゃないか？
結局のところ、それでもかなりのことが行えるので、それで満足してしまって
C++の本域や可能性を見失ってしまう。
まぁ、STLにしてもほかのBoot（？）にしてもこれらを使いこなせるようになる前に
大概のことは楽にやってのけられるし、
これらを学んでも実践にどこまで投入していいか？の問題もある。

あと、Cの影響力が強すぎてC時代の財産とかが未だに尾を引いているのかもしれない。
（周りの人間との統合性とかを考えるとやっぱり　Better　Cぐらいが一番能率がいいのかもしれないし。）

>>669
休刊直前くらいのCマガにそれと同じこと書かれてたな。

C++がドラゴンボールというのは、なんとか仙人とか何とか王様とか変な権威ありそうな
奴がいろいろ御託を並べるが、実は何か奥が深い物があるわけではない、という点でも
似てるな。

MFCで自作簡易レンダリングエンジンって出来ませんか。（IEに依存しない）
何方か方法おしえて＞＞＞

>>672
マルチ氏ね

Javaは引数の参照渡しができない
とんでもない駄作

>>674
そーゆーこはJava厨が沢山居そうなスレにageで書き込みなさい。

C++のマニピュレータはどこもマネしないくらい最強

あれ使ったことない
難しいというか・・・鬱陶しいというか・・・

アレはどっちかっていうと単にインターフェイス的にもパフォーマンス的にも
駄作(というか失敗作？)だから、みんなにそっぽ向かれただけ。printfマンセー！

まああれはあれで、使いようによっては有用で便利なんだが

vector<int> vec_int;
　・・・中略
cout << vec_int / "," % 3 << endl;

たとえばこれで、vec_intの中身全部を
一行に３要素ずつ（ % 3）、カンマで区切って（ / "," ）
出力なんてことをやったりできる

ああ↑はあくまで、こういうマニュピュレータを自分で定義したら、という話ね。

そもそもstd::endlもマニピュレータだということを知らない人がかなり多い

ライブラリに優劣があるのは仕方ない
iostreamは行き過ぎた抽象というやつかな
ファイルなんかランダムアクセスでいいんだよバカやろう
的なのが提案されてる

ともかくいまさらbindを取り込むDは不憫

streamの名前の通りに素直に考えた設計だと思うけどね。
iostreamの出力をiostreamで読み込む。これは簡単。
問題は既存のファイルや人が読みやすいファイルがstreamとして扱いやすいかということだろうよ。

iostreamは真似しちゃいけない設計の見本のような気がする。

後のSTLともあまり噛み合ってないからな・・・。

>>679
>カンマで区切って（ / "," ）
「<<」、「>>」で感性がマヒしてると、こういう
変態的な演算子を定義しちゃうようになるんでしょうか。

templateとBoostで麻痺してるせいか
この程度は、きわめて直感的でわかりやすいと
自分では感じるんだが

まああれだ、素人はだまってろ

まあでも他人と共同で書くときには控えようかなと思うよ、俺は。

俺も、なんか気づいてみたら趣味で書いてる時と、仕事で書いてる時のコードに
とても同じ人物が書いたとは思えないようなギャップが発生している。






・・・ゴメン、本当は仕事で書いてるコードも基礎部分が極端にトリッキーなコードになってる。

C++にclassって必要なの？
structで充分だろ

>>690
そう思うなら使わなければよろしいのでは?

CとC++じゃ明らかに生産性が違うよ

えっ、そうなんですか、つまり　生産性は C >> C++と

C++は再利用性が高くてメンテナンスも容易
オブジェクトを組み合わせるだけでほとんど完成する

C++は１ヶ月も見てないととたんに忘れるな･･･

スクリプト言語からC++に戻ってくると、
通常型とポインタと参照があることに安心する。

あるあるｗｗｗｗ

>>694
ツリ?＿

>>690
十分といえば十分ですね
まったく同じ子とできるわけだから

コンテナクラスの継承ﾏﾝﾄﾞｸｾ

std::vectorとかか？
あれは継承するような存在ではないから面倒で当然だ。

>>684
具体的には?
istreamとostreamがiosを仮想継承して
iostreamがistreamとostreamを多重継承しているところとか?

>> と << の気持ち悪いオーバーロードとかもかな。

マニピュレータを新しく作るにしても
istream, ostream, iosを修正しなくてもできるの?

>>704
できるよ。
やりかたよくわからないけど。

わからんのに言うなーー

C++の印象：
一貫性より無節操さかな。その無節操なところが難解にさせてるね。
無節操だと思うところは、オブジェクト指向にしても、ジェネリック
プログラミングにしても同じ統一した法則の元で成り立ってないわけで
それが複雑怪奇にさせているという指摘。

オブジェクト指向にジェネリック系の考えを入れてプログラミングを
すればわかるけど、よほど注意深く作っていかないとスパゲティになっ
てしまう。それだけバグ取りが難解になり易い弱点を持ってるね。
バグ取りだけじゃなくて、コーディングに時間がかかるね。効率的な
作成はまず不可能だと考えていいよ。javaでも最近テンプレート的な
動きがあるようだけど、あれは自滅の方向かもしれませんよ。

要するに余計なところばかりに神経を使って作らないといけなくなる
事がC++の問題点だと思うね。慣れたから大丈夫というレベルを超え
ちゃってるんで。

>>707
直行してる概念を組み合わせても混乱は無いはずなんだが。
オマエのプログラムがスパゲッティになったのを誰かのせいに
したいだけに見えるぜ。

>>708
???

インターフェイス実装目的以外での継承禁止

707は物事を組み合わせること自体を複雑怪奇になると表現しているように思う。
極論すればいい意味でプログラミングそのものの否定に結びつきそうな感じがする。

C++は10年以上昔から存在し、かつ互換性も保ってきたのだから
文法が煩雑になるのは仕方ない。しかしそれだけ昔からあるのに
未だ高級言語の最前線に居り能力を認められているのは驚くべき事だ。

むしろテンプレートが導入されたときから始まったと言っても過言ではない。
そのテンプレートが出てきたのもARMが出版された1990年頃。
それ以前から構想していたのだろうし、つい最近出てきたようで随分前からあるもんだな。

708は相手にする価値がないと判断したから???としたが。

>>711
組み合わせたら複雑怪奇になるのは当然だが、言いたいのはその組み合わせの
ところがぐちゃぐちゃになってる。

テンプレとオブジェクト指向をまじめに組み合わせて作ってみればわかると思
うけど、かなり先の見通しが出来ない限りスパゲティになるのさ。熟孝がどう
しても必要になってくる。スパゲティにしないように工夫して作るのは結構大
変。この辺がわかってない奴がC++で組むと遅いものしか出来ない。実力差がで
易い言語だともいえるが。

また、必要悪なのかもしれないが仮想関数もスパゲティにしている原因だ。あ
れは極力使わないように工夫する必要がある。

テンプレの発想は凄く良いものだがね。

>>714
原因と結果の因果関係が何も説明されてないから、「ふーん」としか思えない。

ダメなプログラマはどんな言語を使ってもスパゲッティを作るし、
優秀なプログラマはどんな言語を使っても良いコードを書く。
それだけのことだろ。

C++は自由度の高さと抽象化のレベルのバランスがちょうどいいんだよね。あれだけ抽象的なプログラムが書けながら低レイヤーでの処理がはっきり見えてくる言語は他にないな。抽象化をしながらそれでいてブラックボックスが限りなく少ないんだよ。自分は好き。

オブジェクト指向とテンプレートを組み合わせるとスパゲッティになるという主張は全く意味が分からない。設計が下手なんだな。

>>716
下手なんだなじゃなくて、慣れてないとうまくいかないよって話だよ。
慣れていたって、ジェネリックにする為の穴はかなり作ってしまい易い。
そこは熟孝なしに作れないところで生産性を損なうんだよね。その熟
孝の方向が作ろうとするものよりその周辺にばかり気をかける比率が
高いの。これがテンプレのライブラリの難しくする場所でもある。ボ
トムアップ的な思想だけではうまく作れないものなの。トップダウン
的な発想をしつつトップダウンな作り方が求められるからね。

オブジェクトごとに算術オペレータとかも丁寧に作っていかないといけ
なくなったりしますから、どうしても助長なプログラムになってしまう
し、見通しが複雑になり易い。traits技術とか切り抜ける方法はいくら
でもあるけど、実際に作ろうとするものよりその周辺ばかりに注意しな
きゃいけなくなって、制作のテンポも悪いよ。

C++は自由度は高いけど、複雑なルールに基づいているだけに難しくなる。
わからないのは頭だけで考えているからだよ。実際にテンプレートライブ
ラリを設計してみたらいい。いろんな注意点に気がつく事になるよ。

他の言語との比較は荒れるもとなので意図的に控えてるけどね。

トップダウン
的な発想をしつつトップダウンな作り方が求められるからね
→
トップダウン
的な発想をしつつボトムアップな作り方が求められるからね

代数的なクラスでもない限り演算子オーバーロードは使わないと思うが

> 他の言語との比較は荒れるもとなので意図的に控えてるけどね。

一連の書き込みから、どうも何か煽っているように見えてたんだけど、
荒れるのは嫌なのね。いったい何がしたいの？

>>717
traits技術を駆使してテンプレートライブラリを設計して
いろんな注意点に気がついてしまったか

まずその注意点を書くべきだぞ

汎用的なコードを書こうと思ったらいろいろ気をつけなきゃいけなくなるのは
あたりまえなのにねぇ。

>>719
stringを含めたクラスでクラス同士の足し算利用するようなことは
十分使えるものなんだが。そんなところまで意図して書いている。
かけ算までは利用する事はあまりないと思うがね。
やはり実際に作ってみないとわかりにくいのかもしれないね。実際に
テンプレートクラスを１から作ってご覧。

>>720
何がしたいの？ってこのスレのタイトルに対しての見解を書いてるだけ
だよ。仮に、C++賞賛スレならばこんな事は書かない。辛口なこと？は
十分受け入れられるスレだと判断したからだ。

同じルールの元で、いろんなパラダイムを持ってきたのではなくて、
つぎはぎの仕方が複雑になってるからだと言ってるわけ、その例が、
オブジェクト指向とテンプレートの掛け合わせの問題を出しているだけ。

C++ではいろんな事は確かに出来るけど、複雑なルールの元で作られて
るために、保守点検も含めていろんな事が難しくなる。それが、C++人
気が廃れてきた原因だろうね。

なんていうか、新しく覚えた手法は全部使わないと気がすまない病気なんじゃないだろうか？
ある程度知識欲のあるプログラマなら一度はかかる病だと思ってるけど。

必要なプログラムだけ書いてればいいんだよ。新しい機能を思いついても、
明らかな必要性がない限りやらないほうがいい。 YGANI ってやつ？

批判精神に富んだ青年に
traits技術を駆使してテンプレートライブラリを設計して
いろんな注意点に気がついてしまわせたC++は
魅力的な言語だと言うことだな

>>723
> オブジェクト指向とテンプレートの掛け合わせの問題を出しているだけ。

最初っから言われてるけど、さっぱり因果関係がわからん。
人に伝えるつもりなら「やってみれ」とかで済まさずに説明してくれ。
説明する気が無いなら長文 age ウザイからチラシの裏にでも書いててくれ。

例えばBoostとか見てみ。何も複雑なことないでしょ？
言語機能を把握しきれなくて複雑に感じるというのなら納得。しかしオブジェクト指向、ジェネリックプログラミングはむしろ構造を素直に記述するために上手く働いてると思うんだけど。さらにテンプレートは最適化にも貢献してる。
同じことCで書こうとしたら大変だよ。

ごめんなさい
boostのソース見てて発狂しました

>>723が"具体的な"例を持ってくるまで待とうじゃないか

まあ文法がひどいというのは納得。ただ機能面で同等なことしようと思ったらC++と大して変わらない言語になるんじゃない？コンパイラ任せの部分が増えると書くのが楽になっても機能面でのマイナスが多少はでるよね。

コンパイラより賢い人間がいるかぎりC++のような言語はなくならないんじゃないかな。

言語仕様でなるべくスパゲッティにならないよう努力してもいいんでない？
C++は悪い意味で好きなように書け過ぎると思うんだ。

Javaの多重継承できないとか
Pythonのインデントみたいな試みは是非はともかく嫌いじゃない

C++は凡人のための言語じゃないと思うんだよね.
研究心のある人が使えばいいのさ.
大きな自由度を残しておく事で,そこから新しい可能性を見つける事ができるんだよ.
Boostのライブラリとか見てるとすごく思うけど,C++はいろんな新しい考え方を生み出す実験台としての役割がすごく大きいと思う.
書いている人の好奇心を煽るとてもいい言語だと思うけどな.

実際にアプリケーションを書く言語として適しているかということとはまた別だけれどもね.

C++の開発動機に"Better C"がある以上、Cとは可能な限り互換性を
保たねばならず、従ってC時代由来のアナクロニズムは除去できない。
ifブロックを中括弧なしで書けないようには出来ないわけだ。

他の新しい言語と比べると酷い言語のように見えるけど、
実際のところ禿が掲げた理念を大前提として考えれば、
今のC++は可能な範囲で望み得る、かなり良いものだと思う。

そもそもC++は大規模オブジェクト指向言語の元祖であって、
新しいパラダイムを開拓しつつも互換性を重視する立場からは古い仕様を変えられない、
そう考えると今までのC++が何か大きな間違いを犯したとは思えない。
C++のこういう点が気に入らないなら素直にDでも使うべきなんだろうと思うよ。

>>733
C++を嫌って自由度を追いかけたら、DかLispに行き着くだろうな。
Dもネイティブコンパイラを持ってるようなLispも速度的には速いですから。

>>1
ってよりか、C++で書かれたソフトってやたら重くね？
オブジェクト指向って重いの？

何も考えないと重くなる。
でもC++自体は重くならずに済むよう努力したほう。
そうでなければC++が普及することは有り得なかったと禿は言っている。

C++が重いんじゃなくって、C++のフレームワークにクソ重いのが多いんでないの？
MFCとかQtとか

STLを使うと実行速度が10倍に？！

Cで書けば、フリーウェアでソースも公開してて
Win標準装備のコピーより何倍も早いfastcopyは
さらに早くなるのか！？
ソース見る限り俺は作った人に「すごいよ、あんたすごいよ」
って言いたくなるソースで、ま、結局のところ頭の良い人
はC++で何か作ろうとするとき頭の中にクラスの設計図が
自ずと浮かび上がってくるんだろうな。

C++でもATLでウインドウ制御すれば瞬発力があるソフトが書けるの。
MFCなどを使うと一呼吸動作が遅くなる。

だから言語の問題じゃない。

ちょっとしたデータ変換ツールを作ってみたら、CでもC++でも殆ど同じアセンブラコードになった。
C++の方がテンプレート関数のお蔭でソース自体は短いのだが。

>>741
禿もCがC++の最大の敵と言っているくらいだし、
Cと同じように書けばCと同じ機械語になるのは当然。

一呼吸とか変なこといってんなよ

何が変なのかさっぱり。
MFC擁護のバイトか何かですか？

言葉が変なんだよ。きっと。

templateを使った時にコンパイラの吐くエラーがカオスにな

Cの方がトータルでみて生産性高いと感じる俺は
まだまだC++を使いこなせていない

>>747
C++から入った身としては、そういうことがいえるほどCを使いこなせている人が居ることに驚く（強意表現だが）
すくなくとも、普通に使ってる分には、C++ のほうが適当に作ってても修正とか聞くし、
真面目にやるときも設計の目処が立ちやすいし、少ないコードで楽に進められるし、名前問題含め使い勝っていいと思うのだが、
参考までに、どんな所がCの方が生産性が高いのか教えて欲しい。

俺の感性に合うっていうのかな。
Cでゴリゴリ書いてると魂磨いてるって感じ。

たまにCを使うと、変数宣言がブロックの先頭でしかできないのが苦痛。
地味なところでは、for (int i = 0;とかbool型などがないのも嫌になる。

せめてC99を使いたい。

誰だ勝手に答えているのはｗ

>>748
自分の場合、某悪評スクリプト言語からCに入ったので
関数主体で構造化できるってだけで感動しているレベル。
グローバル変数メインでサブルーチンで直接値を操作するのが
当たり前だったもんで…
とてもじゃないけどCを使いこなせているとすら言えない

C++の（というかオブジェクト指向の）クラスとかインスタンスという概念は
面白いとは思うけどオブジェクト単位でデータと関数がまとまっているよりは
命名規則（型ではなく用途で）をしっかりつけたグローバルな変数と関数を
一元管理した方が把握しやすいっていうか楽に感じる。
オブジェクトで分けるよりはシーンで分けた方が直感的というか。

趣味プログラマとしてはメソッド使わなきゃ属性にアクセスできないみたいな
データの隠避にも大した利点に感じない。
そんな間違いすることあるのか？って思ってしまう。

まぁスクリプト言語に浸りきった弊害なのと
C++をひとにみせても恥ずかしくないレベルまで習得するのが面倒なだけやけど。
constとかstringとか楽なところだけ使いつつスクリプト時代のようにダラダラと
手続き型で書いている。
Cの方がってよりも手続き型の方がって話だ。すまんす

データの隠避は複数人での開発では特に重要
1人だとありがたみを感じないのも無理はないと思う

一月前の俺と今の俺は他人

データ隠蔽とかはブロックごとにファイル分けて
構造体に突っ込むことでまだなんとかなるけど
テンプレートのアルゴリズムはもうCではやる気が起きなくなるな。

>>751
それ、全部C++でもできることじゃん。
要は、「Cの方が高い」じゃなくて、「C++である必要が無い」だな。

まずnamespaceから

まずC風に軽く組んで、
「ここの機能まとめたら分かりやすくなるかも」見たいな感じで
徐々にOOP「風」に組み直していくやり方でいっぱいおっぱいですよ

自分も早く再利用可能なクラスをいっぱい作って
実際のプログラムは部品をドッキングさせるだけで良いみたいな状態になりたい

結構気合い入れて「俺ライブラリ」を作るんだけど、
なかなかうまくいかないねえ、こう、なんというか、
「近未来の自分にすんげーフィットする汎用性と機能のバランス」ってやつは。

各種文字列クラスとの相互変換テンプレートだらけで
俺ライブラリは統一性が無い。文字コード含めてわけかわらんよ。
比較関数だけでも20種類はある。

難しいとは思わないけど
無駄に複雑
馬鹿みたい

馬鹿みたいというか
馬鹿が複雑に書いてるんだ
でもビャーンのハゲは髪だと思う

禿はインタブーで「わざと複雑にした」っつってる死ね

頭の悪い奴には使いこなせない言語だよな、ホント。

でもこの「頭の悪い奴には使いこなせない」の意味を、頭の悪い奴は理解できない。
そして見当違いの方向に怒り出すｗ

こないだ仕事でJava使わされたけど
あまりの遅さと自由度の低さに愕然とした

やっぱ自分ひとりで組むのならC++だな

Javaのgenericにはしょんぼりした記憶があるな
C++的なものを求めるのが間違っているんだけどさ・・・

boostがやばすぎるぐらいに便利だからなぁ・・・
逆にC++より簡単な言語ってないんじゃね？って思えてくる

boostって何がそんなに良いの？
導入すっかな

std::for_each(r.begin(), r.end(), f);がboost::for_each(r, f);と書けるようになったり、
std::bind1st. bind2ndより見た目わかりやすいbindが書けたり、正規表現ができたり。

>>768
少なくとも言語マニアの素養がある椰子には
boost::lambda, boost::function　→関数型パラダイム
boost::mpl, boost::preprocessor　→メタプログラミング
boost::spirit　→構文解析
あたりは垂涎もの。使ってるとJavaとかC#ですら塵に思えてくる

そんなの無くても不自由しねえよって人でも
スマートポインタとかは確実に有用

lexical_castやpolymorphic_downcast、numeric_cast、noncopyableあたりも地味に便利

うむ
ありがとう
何を言ってるのかさっぱりな漏れにはまだ早いことは良くわかった。
ようやっとSTL使い始めたばかり

コンパイル遅すぎなんだよ糞が

何のための分割コンパイルだ、プリコンパイルヘッダだ

速度なんてボチボチ、イラネな世界になってきたから
Rubyとかで良いんでない

最近は専門用語が増えすぎ。
あーぎゅめんとでぃぺんでんとねーむるっくあっぷ
かりおすりーりかーりんぐてんぷれーと
えんぷてぃーべーすおぷてぃまいぜーしょん
えたーなるふぉーすぶりざーど

クトゥルーさげ

いあ いあ はすたあ！

全部の機能を使うのはたいへん

C++のどこがBetterCなんだ
むしろWorseCだ

ローカル変数宣言がブロックの先頭に縛られないこと
特にforなどで変数宣言できること

inline関数
constで定数宣言できること

強力な型安全性の保障（ベターCとして使うならvoid*から他のポインタ型への暗黙の変換まで禁じられるのはきついが）

>>781
最後以外は C99 で十分だな。

改めて C99 と比べると、
- restrict
- __VA_ARGS__
- stdint
- 複合型リテラル
- 要素指定の初期化
とか、いろいろ抜けてるので十分 WorseC と呼ぶに値する。

>>780
使う人間のレベルによっては、変わるかもしれないな。

仕様としてC99が充分だとしても
C99のコンパイラ自体がまだまだ普及してないというのが、一番の大問題。

gccにicc、Sunのccもc99に対応していて、これでも普及していないと言い張るとはDozerはこれだから……
つーか、M$儲というべきか?

で、「世間一般の人」の中で、そのDozerとやらの割合はどれほどですか？

今はもう、理系の大学のプログラミング言語の課程ですら
Windowsを使う方がずっと多いでしょ。
昔の人はSunとかで覚えたんだろうけど。

世間一般の人はプログラミングなんてせんなぁ。

gccもiccもWindows版があることを知らないのでは?

で、そのMingw等で作られたアプリケーションの比率はどのくらい？
もちろん、VBやdelphi等を除いた、C/C++の中での比較で良いけど。

>>788
「世間一般の人が使っているOS」をコンパイルするコンパイラや
「そのOS上で動くアプリケーション」をコンパイルするコンパイラは
C99に対応してますか？

一般じゃない人(大学の教養課程は一般の人は通らないのですね)は、
betterCのコードをコンパイルする時に
「多数のアプリケーションが使っているC++コンパイラ」を避けて
「該当する環境ではかなりマイナーなC99コンパイラ」を使うべきというわけですね？

俺は>>781の中では、最後の型安全保障が一番重要だと思うのだけど

>>785
君が海胆糞erか犬糞erか知らんが、職業マは
そんなもんだけで喰っていけるわけじゃない。

媚びへつらいと責任転嫁で喰うのが一般的。

C99ってconstが定数になるの？

>>793
Windowsで、VisualStudio使ってiccでコンパイルしてますが何か。

お前が何をしていようが、誰も何も思うことなんて無いよ。どうでもいい存在だもの。

visual studioからgccとかicc使うような環境作れるんですか？

gccはともかく、iccはリンカがないからVisualStudioと連携させざるを得ない。
ついでに言えば、誰もやりたがらないだけでgccもVisualStudioから使える。
#つーか、まさかVisualStudioがコンパイラだと思ってないよね。

>>797
その割にはずいぶんとご執心で。

あれ、Win上のiccってプラグインだよね。
で、もしかして、コンパイラに対するアドオンじゃなくて完全に入れ替えちゃうわけ？
gccが使えるってんなら、gccはその通りだろうけど。
つまり、インテリセンスとかのIDEのメリットって奴が活かせなくなっちゃうわけ？
(だって文法変わるしpragmaやifdefだって変わってくるし)


ていうか、必死にgccを主張して頑張ってる人は
「C99とC++のどちらか」といわれた場合にC99を選択するのかね。
俺は100%間違いなくC++の方を選ぶけど。
OSSなんかで移植性優先でC89ってのはいくらでも見つかるけど
C99のメリットなんてどの程度あるのかね。

いや、頑張ってずっと「betterCとして使うなら、そんなことはC99でも出来るからC++は要らない」
と言ってるくらいだから、C++を避けてC99にする方がメリットがあると思ってるんだろうけどさ。

あ、どんなメリットがあるかなんて、別に書かなくていいよ。
「大多数の人にはC++(のbetterCな点)で充分」なことは判りきってるんだから。

いや、俺だって、「C99だったら楽なのに」と思うことはあるよ。
配列の要素数が定数じゃなくていい、なんてのは(std::vectorを使う)俺には必要ないけど
可変長構造体が公式に認められたこととか、
あと、<stdint.h>はあったら随分楽になるとは思う。
(もちろん、多くの非C99環境でも、<inttypes.h>があるから大抵は足りるけど
標準Cでは非公式だから、無い環境のことを考えて#ifdefを使った自前ヘッダを用意しなきゃいけない)

でも、それでもC++のメリットに比べたら、C99のメリットなんて微々たるもの。
その上「C++が使える環境(処理系)」が「C99が使える環境(処理系)」よりずっと多いのだから
「C99でも出来るからC++は要らない」なんて、俺にはとても言えないね。

> 必死にgccを主張して頑張ってる人
> 頑張ってずっと「（略）C99でも出来るからC++は要らない」と言ってる

妄想乙

>>803
>>782

>>784以降の人も、同一人物か同じ意見の人でしょ。
Windowsがどうのと言ってる人。

>>804
やっぱり妄想乙。行間に何か見えてしまう人なんだろうか。

煽っている人の方は単発でピンポイントで突っ込んでるだけなのに、
一人でそれを真に受けて顔真っ赤にして反論しちゃってるんだろうな。

じゃああげようよ

いや、俺には>>785みたいな負け惜しみというか捨て台詞というのが笑えるんですけど。
現実をあえて無視して、必死になってとりつくろってるし。

C99の、普及していないという最大の欠点を指摘されてよほど悲しかったのか
何故かWindows批判までして、でもWindowsでも使えると反論してみたり。

それが信者というもの

>>806
というより、誰が誰なのか決め打ちでもの言ってる奴はどれも妄想にしか見えん。

C99 マクロ (http://sourceforge.net/projects/chaos-pp)
vs
C++98 template (Boost.MPL)

この戦いは壮絶なものになる
もはや何言語なのか分からない

>>813
ライブラリ名の時点ですでにカオスなんだが・・・

ドキュメントのビルドの仕方が分からなくて手つけてないぜ…

難しすぎる。
JAVAの方が生産性高いらしい。

なぁ、みんなはhttp://warp.povusers.org/FunctionParser/fparser28.zip
にあるFunctionParserのソースを見ただけで、「ここが、こうなって、ああなって」
みたいに、読み解きほぐせるの？
俺全然読みとけねぇ。

再帰降下型パーサだな。
実行部分はスタックマシン。
これはもうパターンみたいなもんで、自分で一回作ったことがあればほぼおんなじ構造だから大体わかる。

>>816
1行目はただの感想だろうからいいが、
らしいなんて憶測でモノを語るなよ。

「らしい」は憶測ではなく伝聞を表す表現ではないか、というのが一つと、
憶測がまずいのは、それが事実のように書かれた場合であって、事実を語っているわけではないことが
明らかに文面からわかる場合は、別に語ったっていいんじゃないか、ってのが一つ。

横から失礼。
「らしい」は伝聞じゃなくて推量を表す表現だよ。
推量の基になった外部情報が伝聞という事はあり得るけれども。

憶測でも自分の偏見でもここで語る分には何の遠慮も考慮もいらないと思う。
ここは「そういう場」であるんじゃないかな。

つまり、ぬるぽOKという事ですね？

ちょｗナニこの超展開
流石マ板
書いたときの意図は伝聞らしい

>>824
＞JAVAの方が生産性高いらしい。
伝聞の助動詞は「そうだ」だよ。
→JAVAの方が生産性高いそうだ。

＞書いたときの意図は伝聞らしい
自分自身の意図を推量する事は無いんだから「らしい」は使えないよ。

んなこたーない。使えるらしい。

いやらしい

推量でも伝聞でもいいが、理由も続けないと有益な議論にならないじゃん。
2chでそんなことを期待するほうがあほですかそうですか。

自分が何もしないのに場が勝手に有益になるのを期待するのは確かにあほだね。
でもそれって2chに限らないよ。

一般論としてJAVAの方が習得が容易だといわれているんだから
JAVAの方が生産性が高いって話
まぁ後からでた言語の方が生産性高いのは当然だろうけど

統計取ったのか？とか突っ込まれる悪寒

>>824
＞流石マ板
オイ

ごめん
マ、ム、は回転させると同じだからよく間違えるんだ。
母の胎内のようだ

>>830
> 統計

「"言語名" 人材募集」でググったのが統計になるらしいぞ。
２ちゃんで見たから間違いない。

C++は難しくない。ややこしくて複雑なだけ。
その複雑さを理解してだけで得意になってる馬鹿もいるし

刃物は危なくない。切れたり刺さったりするだけ。

*気を付ければ*

もちろん安全装置だっていろいろあります。

C++何年も使ってたのに1年ブランクあるとと書けないな
Cならそんなことないのに

C++に不足してるのは名前付き引数だな。
オプション引数の順番いちいち覚えなきゃいけないとか、
テンプレート持ってる割に古臭い。
boostのいびつさと言ったら。

それね、検討されたらしいんだ。
でも、新しいパラダイムが来るわけでもより型安全になるわけでもないとか、
関数を引数名の分だけ呼ぶ側と呼ばれる側の束縛が強くなるとか
そもそもそれが欲しくなるほど引数が多いなんて下手な証とか、
反対意見が多くて却下されたという過去があるんだ。

参照：D&E 6.5.1 キーワード引数

その割にはC99にはあったような気が……

名前付き初期化子のこと？配列と構造体限定でよければ確かにある。

↑アホ

↑ニンニク

名前付き引数？
仮引数に変数名つけるじゃん

と思ったら順番関係なくなるのか
それはいいな

Python使ってるとキーワード引数の便利さはよくわかる。
C++でもクラステンプレートのPolicyとかでは出来るのにね。

boost.paramいやなんでもない

boostってまだ標準ちゃうしなぁ

テンプレートのチューリング完全性が意図したものではなく
のちに発見されたものだというのがC++の複雑さを如実にあらわしてる

その複雑さの果ても解明されようとしているが
C++0xが新たなカオスを持ち込んでくれる

好き物プログラマーとしてはたまらないね

templateでエラーの嵐に襲われて思いついたsage

I am the bone of my type-parameter. 体は型で出来ている
Class is my body, and tyepname is my blood. 血潮はclassで 心はtypename
I have created over a thousand compile-errors. 幾たびのコンパイルエラーを超えて不敗
Unaware of export. ただ一度のexportはなく
Nor aware of inline. ただ一度のinlineもなし
Withstood pain to create many templates. プログラマはここに孤り
waiting for compiler's error エラーを前にキーを叩く
I have no regrets. This is the only template. ならば我がtemplateに意味は不要ず
My whole life was "unlimited type parameters" この体は無限の型で出来ていた


いくぞコンパイラ――――エラーメッセージの貯蔵は十分か

タイプミスマッチや型候補なしのエラーの嵐は、conceptが導入されれば緩和される。

C++を難解にしてるのは、めったに使わない機能や、
よく知らずに使うと危険な機能がいっぱいあるから。

それらの機能をなくしてしまえば、いい言語になるのじゃない？

・・・あっ、それがJavaか・・・

Java厨こんなところろにまで出張乙

C++を難解にしてるのは、めったに使わない機能や、
よく知らずに使うと危険な機能がいっぱいあるから。

それらの機能をなくしてしまえば、いい言語になるのじゃない？

・・・あっ、それがC#か・・・

C#厨こんなところにまで出張乙ｗ

C++を難解にしてるのは、めったに使わない機能や、
よく知らずに使うと危険な機能がいっぱいあるから。

それらの機能をなくしてしまえば、いい言語になるのじゃない？

・・・あっ、それがCか・・・

C厨こんなところにまで出張乙ｗ

C++を難解にしてるのは、めったに使わない機能や、
よく知らずに使うと危険な機能がいっぱいあるから。

それらの機能をなくしてしまえば、いい言語になるのじゃない？

・・・あっ、それがDか・・・

D厨こんなところにまで出張乙ｗ

2chを難解にしてるのは、めったに使わない機能や、
よく知らずに使うと危険な機能がいっぱいあるから。

それらの機能をなくしてしまえば、いい言語になるのじゃない？

・・・あっ、それが1chか・・・

ニコ厨こんなところにまで出張乙ｗ

もはやなにがなにやら

>>860
Dは逆だろｗ

>>860
そういう言語を目指してたはずのJAVAやC#は同じ道を歩んでるしな
よほどなオプソ開発者でもない限り、大幅仕様変更や削減は難しいからねぇ・・・

オマンコを難解にしてるのは、めったに使わない大陰唇や、
よく知らずに使うと危険なクリトリスがいっぱいあるから。

それらの機能をなくしてしまえば、いいオマンコになるのじゃない？

・・・あっ、それがアヌスか・・・

アヌス厨こんなところにまで出張乙ｗ

なんなんだ

純粋に言語としては
C++が際立ってJavaやC#より難しいとは
もう言えないんじゃないか
DにいたってはもうC++より難しいのではｗ

JavaやC#は、大規模な標準ライブラリが付属してるから簡単に感じるんだな
C++だと、標準ライブラリの提供する機能が少なすぎる

設計は美しいんだがな。STLとか。

C++もBoostが（ゆっくりとだけど）
よその言語が持っているようなものを（ようやく）用意し始めている。
スレッドとかシリアライぜーションとかネットワークとか。

XML読み書きも欲しいな。

domやsaxならいっぱいあるだろ

拡張可能な暗号化・ハッシュ・圧縮インフラが標準で欲しいな

C++のめったに使わない機能ってなんだろう
virtual継承とかprotected継承ぐらい？

export
asm
template template
valarray
ダイグラフ

asmは結構使ってるなぁ
俺のレベルって低いんだなｗ

asmはCPUをハードウェアレベルでいじりたい時に使うよな

>>874
C++にstream入出力ライブラリは標準でないの？

VC++なんで__asmです。

template template は使えない期間が長過ぎたんで道具箱に入ってなかった
でも明日から使うよ

template templateは結構枯れている印象

Cとの互換性だのメモリ管理だのは実のところ難しくない。Objective-Cを見よ。
俺から見たC++の難しいところ。
(1)例外安全
例外処理はどんな言語でも難しいが、GCもfinallyも無いから気を使う場面が多くなる。
(2)オーバーロードと関数template
暗黙の型変換が必要な命令型言語の世界に型推論を持ち込んだら複雑になって当たり前。
(3)iostreamの細かいところ
ああいうstatefulで多彩なエラー処理が必要なクラスライブラリは、
規格をごりごり書くより参照実装を出す方が実際的だと思う。

>>874
それらの機能は時代とともに変化するし、ターゲットによって最適な手段が異なるので
C++のように幅広く利用される物に標準として搭載するのはいかがなものか、と思う。

ハッシュは採用されるだろ

>>874が言ってるのはたぶんMD5とかSHA-1のような暗号的ハッシュ関数のことだと思う。

ライブラリ化するのはポリシークラスや関数オブジェクトをパラメータ化すれば容易いし、
拡張も容易だろうけど、時代の趨勢に標準が追いつかなそうだな

C++みたいに組み込みからサーバまで使われるようなものに、
ハッシュや暗号化のようなコスト、耐久性にいろいろとバラエティの取れるものを標準搭載してもなぁ、って気はする。

個人的には、フリー以上ホスト未満の分類をもう1つか2つ増やしてもいいと思う。

CRC、zlibくらいはあってもいいんじゃないかという気は

ライブラリを独立した規格にすればいいのにと思う。

というかそういう声が多かったからBoostができたんじゃないかと

そしてTR1へ

言語の細かいとこにあまり神経使いたくないね。
設計とかテストとか神経を使う重要なとこは他に一杯あるんだから。
重要でないが細かいとこに注意を向けるあまり肝心のことが抜けてるってのは
ありすぎるほどある。
思い当たるだろ。
たぶん、個人の注意力の総量は一定なんだろう。
あるとこに注意を向ければ別のとこがおろそかになる。
それだったら重要度の高い部分に優先的に注意を向けたほうがいい。
しかし C++ だとこれが出来にくい。
言語に落とし穴が多いからいやでも注意しなければならない。

>>894
抽象的過ぎてわからん

>>894
落とし穴というのは適切な比喩でないな。道路脇の崖とでもいうべき。
道に慣れてる人間にとっては危険でもなんでもない。

初心者的な疑問なんだけど、
クラスとかからメンバを呼び出すときに
.を使ったり->を使ったりするのって、具体的にどんな理由で２種類あるんでしょうか？

->を使うところをすべて.で済ますようなことをすると、ソース的にありえないところが出てきたりするのですか？

class foo {public: void memFunc();}があるとして、foo * bar = new fooしたときに
bar->memFunc()する代わりに(*bar).memFunc()することに何の躊躇いもないならば、
どうぞご自由にアロー演算子を使うことをおやめくださいませ。

struct A foo;
foo.val1 = 1;
strct B * bar;
bar->val2 = 2; // 初期化していないポインタへの演算ざけどそこらへんは気にせずに・・・

>>897
ポインタかそうでないか

そうじゃなくて、なぜ実体／参照は.で、ポインタは->なのか、ポインタにも.でアクセスできる文法にしなかった理由は何なのか、ということじゃないかな。

それはつまり
class Foo = new Foo();
という文法を認めろ、ということか・・・

何書いてんだ俺ｗ酔っ払いすぎだｗｗｗ

ｆoo f = new foo();　という文法を認めろ、ということか・・・

に訂正＿|￣|○

T1 p；のとき *p がT2&を返すような実装をしてると
p.aの意味が不明になるでわかるかな

>>904
演算子オーバーロードできるC++で破綻するのはわかるんだけど、.演算子と->演算子はCからあるよね。

Dでは左辺がポインタでもそうでなくても常に . 択一だったはず。
文法上はそれでも成り立つのはわかる。
でもなんでCでは区別するのかという答えは出てこないけどな。

演算子をそう定義したから、としか言えないのかな。
ドット演算子はポインタでない変数のメンバを参照するもの、という定義があって、
これをポインタ変数に適用しようとすると、dereference operatorの機能も入るから、
演算子を同一としてはいけない、と。
ドット演算子を「変数のメンバを参照するもの」と定義すれば、ポインタでもそれ以外でも
使えるようになるけど、Cではそれをしなかった。

そう考えるとC++のoperator overloadingって結構変態的な機能なんだね。

そうだなCでだと、p.a.a と p.a の区別をどうするか
って言えばわかるかな

あんまり自信ないけど
要は誤って別の型にキャスト->ウヒャ
を嫌ったんじゃないかと言う気がする

当時のコンピュータとコンパイラの性能とあわせて
コスト的に違うものだという意識が働いてたんじゃないのかね。
a = aa.bb.cc.dd と
a = aa->bb->cc->dd じゃ
生成されるコードが全然違うからね。

と思ったが、配列とポインタの扱いを考えると違うか。
a->bが(*a).bという記法の省略であるというのはどこでも説明されているけど。

つーかメンバのポインタだけ -> なんて記号使っておきながら
なんで他のポインタはアスタリスクだらけなんだろうか

>>910
古い本には「ポインタを何回たぐる」といった表現が頻繁に出てきて、
間接アドレッシングのコストが強く意識されていた様子が読み取れる。
だから.と->でのコストの違いは大きな要因だったと思うよ。
ましてstructやunionは入れ子にしてaa.bb.cc.ddみたいに
アクセスするのが前提っぽい設計だし。

Cの基本は値渡し。
構造体と配列は値渡しができないのでポインタ渡し。
そこで、構造体と配列については簡易にアクセスできる演算子を作った。

とか言ってみる。

＞構造体と配列は値渡しができないのでポインタ渡し。
？？？

>>914
配列は値渡しできないだろ。
K&R時代は構造体も値渡しできなかったよ。

いや、配列はわかってるよ。構造体もできない時代があったのか・・・失礼。
VBでbyvalで渡せなくて「なんだこの糞言語は！」って思ったこともあったなぁ・・・

正確には「配列の先頭アドレスを値渡し」だな
配列の中身は参照渡しに見えるけどな

むしろ、Cは全てにおいて値を渡す
その値は変数の中身だったり（変数や配列を参照する）アドレスだったりする
と考えるのが正確ではないか

>>918
その程度のことをもっともらしく語るなw
構造体、配列はその中身を渡したくても渡せなかった。
本当は中身を渡したくても、不本意ながらアドレスを渡すしかなかった。
だから[]や->を作ったと言うことでしょ。

その意味では、「全てにおいて値を渡す」ってのは低レベルの言語では極当たり前の話だよね。
プロセッサにおいて、何がしかの値以外のものを渡すって概念がないんだから。

でもこの基本中の基本が理解できなくて、
ポインタを覚えようとしている初心者は発狂する
解説書が悪いんだが

typedef class foo{
.....
}bar;

bar *ptr;

ptr=new bar();

(*ptr).some_member=1;
(*ptr).some_methode();

とかしても、正常にコンパイル出来て走るのに
型宣言の時
ptr -> bar;
という書式で宣言できないのは、もしかするとちょっと問題かも知れませんね。型　変数という宣言時の並びを遵守してないという文句は <-も
認めて
bar <- ptr;
というようにするわけです。
そうすれば、ポインタは２通りの表記法(* ->)が使えるということに
なって表記上の柔軟性が増加するわけです。*表現は算術演算の*と
まぎわらしい場合があって多用されるとウザい場合が確かにありますね。

>>922
->の意味わかってる？ｗ

昔、Cﾏｶﾞだったか、operator < とoperator -を定義してop<-methodを実装するよーな
話があったような・・・

=>と->があって+>が無いのはおかしい

と一瞬思ったがそもそも=>なんて無かった

op>-.-<qo;

・（中黒）やx（ｴｯｸｽ）ってオペラントにはならんよな
内積と外積をですね。あと|A|とか

そもそも中黒はASCIIに無いだろ

C/C++で使われない記号ってある？
キーボードをざっと見渡して$と@はソース上には出てこないかなと思ったけど・・・

->
=|>
===||>

だんだん貫通力が上がっていくぞ！

>>929
@は使う