03/12/18 06:52
理解できないわけないだろ！
デザパタも知らずにC++使いの質を下げるC厨には げんあり
前スレ達
難易度:1 URLﾘﾝｸ(pc2.2ch.net)
難易度:2 1ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
03/12/18 07:37
24歳ですべて悟りました。
天才だから。
3:デフォルトの名無しさん
03/12/18 07:41
難易度が上がっていないという驚愕の事実。
4:デフォルトの名無しさん
03/12/18 09:12
スレ建ては難しすぎ
5:デフォルトの名無しさん
03/12/18 09:20
十数年前はチーズバーガーが１個２３０円だった。
それが、ついこの間まで１個８８円で売っていた。
これはつまり、その気になれば１個８８円で売れたモノを２３０円で売ってた訳だ。
その昔に１個２３０円で食ってたオレに言わせれば全く腹の立つ話だ。
6:デフォルトの名無しさん
03/12/18 09:26
>>5
MZ-5500 の拡張メモリボード (256KByte) を
\72,000 で買った俺にしては（ｒｙ
7:デフォルトの名無しさん
03/12/18 09:30
チーズバーガーもメモリも十年前は今とは段違いにコストがかかったんだよ。
8:デフォルトの名無しさん
03/12/18 10:24
>>7
メモリは間違いなくそうだが、チーズバーガーのコストはあまり変わってなさそう。
9:デフォルトの名無しさん
03/12/18 10:53
>>8
品種改良による大量生産、輸送コストの削減。
加工食品の調達コスト削減、等々。
10:デフォルトの名無しさん
03/12/18 11:08
>>9
中国産農産物の輸入拡大。多分これが一番大きい。
11:デフォルトの名無しさん
03/12/18 16:00
「げんあり」は継承したんだ…
12:デフォルトの名無しさん
03/12/18 18:10
吉牛が290で食えたときには(ry
13:1
03/12/18 22:02
>>3 >>4
出勤直前で焦っていた。
正直すまんかった。
14:デフォルトの名無しさん
03/12/18 22:07
∧＿∧
（ ´∀｀）
15:デフォルトの名無しさん
03/12/18 22:21
>>8
１０年前の牛肉１００％ ＞ 牛から食える肉を切り出したものが１００％
現在の牛肉１００％ ＞ 牛は１００％肉として使う
16:デフォルトの名無しさん
03/12/18 22:58
>>13
つかそれ以前に
糞 ス レ 勃 て て ん じ ゃ ね え よ 脳 挫 傷 ！
17:デフォルトの名無しさん
03/12/18 23:22
例えば、C++をオブジェクト指向の入門に使用すると、まず突き当たるのはその言語仕様の複雑さです。
C++は手続き指向の言語であるCとの互換性を保つことを強いられたので、オブジェクト指向の本質とは
あまり関係のない部分が多く言語仕様に入り込み、習得のし難い言語になってしまっています。
(このように手続き指向をオブジェクト指向に拡張し、両者の概念の混在する言語をハイブリッド系OO言語
といいます)。またC++のようなハイブリッド系言語は、手続き指向でのプログラム作成が全く問題なく行え
てしまうので、「C++を使用しているが、オブジェクト指向になっていない(ただのCプログラミングをしている)」
ということが起こってしまいます。
更に、なんとかC++を使いオブジェクト指向の考えでプログラミングできるようになったとしても、言語の性質上、
メモリ管理の問題が常につきまとうことになります。もともとオブジェクト指向は、システムにまつわる問題を抽
象的に捉えられるところに利点があり、メモリ管理といった低レベルの部分はなるべく気にせずに、アプリケー
ションドメインといった上位の概念に注目したいはずです。C++ではメモリ管理をみずから行わなければならな
いため、アプリケーションに本質的な処理と、単なるメモリ管理の処理が入り交じり、
18:デフォルトの名無しさん
03/12/18 23:23
コード自体を非常にわか
りにくくする側面があります。また人間の手によるメモリ管理は、必ずといっていいほどメモリリーク現象を引き
起こします。このために、「あまり多くのオブジェクトを用意しないようにしよう」という考えが働くようになり、設計
上は分離されていたはずのクラスが実装時に安易に合成され、奇麗なオブジェクト指向設計をくずしてしまうこ
ともあります。
一方Javaはどうでしょうか。Javaはかなり奇麗にオブジェクト指向の考えを実現しているといえますが、
数値や配列などの「基本データ型」はオブジェクトではありません。そのために「全てを統一的にオブジェ
クトとして扱えるはず」というオブジェクト指向の原則に合致せず、やはり不自然なコードを書かねばなら
ない場面がでてきます。
例としてJavaでは、「何でも入れてしまえる順番つきの入れ物」を表すのに、Vectorというクラスが用意
されています。このVectorに物をいれるときに、基本データ型が混ざっていると以下のようなコードを強
いられます。
19:デフォルトの名無しさん
03/12/19 00:12
いいこと言うね～ 禿同だよ
20:デフォルトの名無しさん
03/12/19 00:45
>>18
出たなデザインパターン。プロジェクトの中で３人知ってる人間がいたら良い方だよ。
残りの雑魚は家に帰っても酒呑むかＴＶ見てるかくらいの奴だし。
勤勉な奴は一握りだぞ？２０代でそういうやつは極小。３０代で技術しか取り柄のない奴が
逃げ道としてデザインパターンなんかを習得してる。悪いってわけじゃないけど、
３０代が技術にすがるって、見ていて悲しくなるよね。
21:デフォルトの名無しさん
03/12/19 00:46
>>18
そ こ で
C#
だ！
22:デフォルトの名無しさん
03/12/19 00:46
感じて デジャヴ
23:デフォルトの名無しさん
03/12/19 01:17
>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;
ってやった方が楽だし分かり易いでしょ？
24:デフォルトの名無しさん
03/12/19 01:28
>>22
だから、３０歳過ぎて、社会の政治的な要因に太刀打ちできるような
立場になってからもデザインパターンみたいな一技術で重宝されるような
人物に対して「逃げ道だよな」って言ってるの。２０代の奴がやりたくてもできないような
ところで自分をアピールする術を持ってないのかって。
中堅者のやることっていったら、２０代の奴が仕事をしやすいように、いろいろと根回しすることだろ？
年齢重ねても、やることが２０代の延長だったら会社に居る意味ねーよ。
スパゲティコードだとか、その辺は中堅社員が口出すことじゃねーって。
むしろ、２０代の奴が気付いて、中堅社員に意見をＵＰして、それから中堅社員が根回しするのが理想。
要は、いい歳こいて低レベルな話してんじゃねーよって。もっと抽象的になれってことだ。
25:22
03/12/19 01:45
>>24
何で俺にｗ
26:23
03/12/19 02:07
>24
俺か？ｗ
まだ２７なんだけどな。
つーかデザインパターン云々いってる
話はどこからきたわけ？？
27:デフォルトの名無しさん
03/12/19 02:16
>>25-26
前スレのコピペだよ。
単なるあげ荒氏だから反応するな。
28:デフォルトの名無しさん
03/12/19 09:48
>>21
プップップ
残念ながら>>17-18のコメントはSmalltalk解説サイトの前文なのだ(藁
VB厨のようなM$の奴隷の雑魚どもが使う言語C#ごときに出る幕は無い(藁
29:デフォルトの名無しさん
03/12/19 10:15
>>18
>また人間の手によるメモリ管理は、必ずといっていいほどメモリリーク現象を
￣￣￣￣￣￣￣￣￣
>引き起こします。
書いた奴が、自分の間抜けっぷりを隠す為に
一般化しようとしているとしか思えない。
30:デフォルトの名無しさん
03/12/19 13:26
メモリリークを強調するのって
新言語をC++と比較するときの常套手段だよね。
Cならいざ知らず、C++を然るべき使い方すれば
メモリリークなんて滅多に起こさないと思うが。
31:デフォルトの名無しさん
03/12/19 14:13
ポインタに相当するものがあるなら、必ずメモリリークするよ
メモリリークするようなコードを書いちゃう人は、
どんなに管理手法を凝らしてもリークさせちゃう。
たとえばGCなんてその注意をほんのちょっと減らすだけでしかない。
にもかかわらず大げさに取り上げたがるのは、
表面的なところにとらわれてるか、初心者かのどっちかだろうねえ。
32:デフォルトの名無しさん
03/12/19 14:35
>>29
> >>18
> >また人間の手によるメモリ管理は、必ずといっていいほどメモリリーク現象を
> ￣￣￣￣￣￣￣￣￣
> >引き起こします。
>
> 書いた奴が、自分の間抜けっぷりを隠す為に
> 一般化しようとしているとしか思えない。
ではお前は間抜けなことをせずに間違いを一切犯さずに
超超！超！超！超！超！！大規模アプリ開発で
ポインタ演算をべらぼーに徹底的に使い切ってコーディングできるか？
お前には無理だ。それは、お前が人間だからだ。
33:デフォルトの名無しさん
03/12/19 14:37
>>30
それがしかるべき使い方をする香具師がほとんどいないんだからねえ。
速度を強調するにはどうしても避けられない問題につきあたるわけよ
34:デフォルトの名無しさん
03/12/19 14:54
> 超超！超！超！超！超！！大規模アプリ開発で
> ポインタ演算をべらぼーに徹底的に使い切ってコーディングできるか？
できるよ。
規模が大きかろうが小さかろうが、
しかるべきサイズのモジュールやコンポーネントに分割して開発するだろ。
この「しかるべきサイズ」の条件として、「ポインタが安全に使える」
というのがあるだけの話。さらに言うなら、条件の一つでしかないし、
それほど重要じゃない。
35:いちゆ
03/12/19 15:02
C#はいまだにポインタ型が使えるんだが、
あれはどぅだ？
36:デフォルトの名無しさん
03/12/19 17:17
っていうかおまえらC++じゃなくてCのポインタをイメージ
してないか？Cのポインタは怖い。キャストとか特に。
C++だとauto_ptrやクラスでラップできるしね。
で、普段C++な俺がCでWinドライバ作成してるわけだが、
緊張感が違うな(w
37:Kusakabe Youchien
03/12/19 17:49
>>36
こわがりすぎー
38:デフォルトの名無しさん
03/12/19 18:06
>>27
いや、分かってるがﾜﾛﾀ
39:デフォルトの名無しさん
03/12/19 21:05
メモリーリークってJavaだってたいしてかわらんだろ？
使えるだけ使いまくって足りなくなったらいらない
メモリを開放してるんだから。
まぁ、要するにJavaはメモリ食い杉。
40:sage
03/12/19 21:21
GCがあったってリークさせるやつはさせるさ。
リークを完全になくすには例外安全を貫く必要がある。
過剰な例外安全の保証を行うと、性能面でのC++のメリットがなくなる。
そのあたりのトレードオフの存在が、C++のいいところでもあり悪いところでもある。
41:デフォルトの名無しさん
03/12/20 11:31
>>36
緊張感が違えば十分だが
Cのソースのメンテの場合などは
あきらめでいっぱいになる事もある。
42:Java最強
03/12/29 20:19
C++は列挙型なんて時代遅れのものがついてる欠陥品
43:デフォルトの名無しさん
03/12/29 22:05
おまえらマジでC言語のポインタで挫折したの？
44:デフォルトの名無しさん
03/12/29 22:19
abc.exeという実行ファイルがあったとして
この実行ファイルの引数がどうなっているか調べる方法はありますでしょうか？
もしくはそれがわかるソフトでもかまいません。
よろしくお願いします。
45:デフォルトの名無しさん
03/12/29 22:29
リファレンス(T&)渡しを的確に使用している奴はいるのか。
ポインタ渡しを使った場合と効果は同じだけど、
引数で渡すデータを変更しない場合は、リファレンスを使い、
値を変更する場合はポインタを使うようにしているのだが、
それ以外で適切な使い方を知っている猛者はご教授願いたい。
（コピーコンストラクタやoperator関数の引数ってのはなしで。）
46:デフォルトの名無しさん
03/12/29 22:33
>>45
中学生。
47:デフォルトの名無しさん
03/12/30 01:29
>>45
たとえばあるオブジェクトを指すクラスを作るときで、
そのオブジェクトをコンストラクタ以外では指定できないようにしたいとき、
参照型のメンバ変数とすることがとても有効な場合がある。
48:sage
03/12/30 02:47
適切、かどうかは判断しがたいが
templateをぽちぽちいじるようになれば、リファレンスは避けて通れなくなる。
いちいちポインタを要求するtemplateってのは使いづらいからね。
49:デフォルトの名無しさん
03/12/30 03:56
>>45
More Effective C++でも嫁
50:デフォルトの名無しさん
03/12/30 06:42
>>45
>引数で渡すデータを変更しない場合は、リファレンスを使い、
変更するかしないかはconstの有無で判断するもんだと思う。
ポインタでもリファレンスでも。
51:デフォルトの名無しさん
04/01/03 22:52
てかこのスレの住民は(>>48以外？)モダーン本も読んでないのか？
TypeTraitsで適切な引数型を自動的に検索できるのは
参照型のシンタックスがコピー渡しと同じだからだろうが。
52:デフォルトの名無しさん
04/01/04 00:44
テンプレート関係の勉強をしようにも、
頭が悪いので理解できない。
初心者用の本だとスタッククラスに対して、
int型やchar型をテンプレート引数にとる簡単な例ばかりで、
応用例は、ほとんど載ってない。
標準ライブラリとテンプレートのからみを説明している本は、
中級者以上の本ばかりなので、難しくて理解できない。
（特にsetやlistテンプレートの実装部分とかの説明が理解不能）
この辺のからみについて、何かわかりやすい本or
最適な勉強法はあるのでしょうか。
53:デフォルトの名無しさん
04/01/04 01:07
>>52
URLﾘﾝｸ(www.amazon.co.jp)
試しにこれ読んでみれ。
54:デフォルトの名無しさん
04/01/04 01:09
俺はlistやhashtableを実装(再発明)したよ。
lokiやboostのコードを読み漁りながらだったんだけど、
type traitsやfunctionalなんかが中心だったかなあ。
カナーリ勉強になったよ。
55:デフォルトの名無しさん
04/01/04 02:46
「JavaプログラマーのためのC++」ってないかね。
JavaのStringやVectorと対比させてSTLを教えてほしい。
newとdeleteの管理をちゃんとやるための設計のしかたとか。
56:デフォルトの名無しさん
04/01/04 10:46
newとdeleteの管理すらできないうちからSTLに手を出したりするから
C++がわからなくなる。
テンプレート(機能)は鬼門なので他が十分に理解できるまでとっておく。
STL(ライブラリ)はもっと鬼門なのでテンプレートが十分に理解できるまでとっておく。
あとは車輪の再発明はC++の学習には欠かせない要素。
自分で作ってはじめて理解できる。それがC++。
57:デフォルトの名無しさん
04/01/04 21:51
読む→試す→作る→だから身につく
58:デフォルトの名無しさん
04/01/05 01:15
どこかで見たことあるモンクだと思ったら…
そんなにこわがることないのにー ;-p
59:デフォルトの名無しさん
04/01/06 11:58
>>56
STL(あるいはその再発明)を使わなけりゃ例外安全な
deleteの管理なんて出来ないだろうが。
60:sage
04/01/06 22:48
>>59
そんなことはないない
61:デフォルトの名無しさん
04/01/07 02:13
出来ないというか、やる気はせんな。
62:デフォルトの名無しさん
04/01/11 21:41
>>59
auto_ptrはSTLじゃありませんが何か？
63:デフォルトの名無しさん
04/01/11 21:46
やっぱり安全なdeleteの管理はできそうもないな。
なぜならauto_ptrはSTLだからね。
64:デフォルトの名無しさん
04/01/12 00:25
GNU関係のプログラム書いてたら99%はANSI Cだから素のポインタ操作も
最初は苦しむが慣れたら明確かつ究極的なインタフェースとして使えるよ。
サーバ系で一リクエストに何千回も処理する箇所があればオブジェクト指向系
の糞重い&メモリ食いな処理は命取りになる。
そういう時にポインタでデータをきちきちに詰める。
1バイト単位できっちり。
JAVAやC#みたいなインタプリタと違って最適化やVMも必要ないから
十分なパフォーマンスが得れる。
だが熟成には何年何ヶ月と要するよね。
適材適所があるわけだから一概にC++はダメって言い切るのはどうなのかな？
65:デフォルトの名無しさん
04/01/12 00:52
C# はインタープリタじゃないわけだが。
Java も最近 JIT 方式のものがあったりするし。
揚げ足取りスマソ。
66:デフォルトの名無しさん
04/01/12 01:12
やっぱし テンプレートは理解しておいた方がいいのかなぁ。
難しい..
67:デフォルトの名無しさん
04/01/12 01:16
>>66
最低限、STL のコンテナが使えれば OK だと思う。
それが出来たら Modern C++ Design でも読みつつ Loki の内容理解とか。
68:デフォルトの名無しさん
04/01/12 01:17
>67
了解。頑張ります。
69:デフォルトの名無しさん
04/01/12 01:21
.NET自体がおおざっぱに捉えてインタプリタだと思うんだが。
70:デフォルトの名無しさん
04/01/12 01:24
>>69
修行が足りん 出直してこい
71:デフォルトの名無しさん
04/01/12 01:25
>>70
C#とかJAVAって386コード吐けるんですか？
72:デフォルトの名無しさん
04/01/12 01:41
>>71
JIT コンパイルで検索しる。
73:デフォルトの名無しさん
04/01/12 04:25
>>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が出てくるのやら・・・
いい解説ページか本はないでしょうか。
74:デフォルトの名無しさん
04/01/12 04:29
それどころか、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();
}
がいったいなんのことやら、と。
75:デフォルトの名無しさん
04/01/12 07:46
＞いい解説ページか本
Modern C++ design しかない！
>>74
そのテンプレートはModern本を読み進めて行かなければ
ほぼ理解不能だと思われる。
loki風のテンプレートの用法に慣れちゃえば
極めて普段どおりのやり方になるので、まずはModernの読破を。
76:デフォルトの名無しさん
04/01/12 15:57
>>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_;
};
みたいなの。
77:デフォルトの名無しさん
04/01/13 23:13
templateをしっかり学習したければHaskellを
覚える事をお勧めする。
78:デフォルトの名無しさん
04/01/14 09:57
>>77
TypeListを処理するのに再帰を使用するとかが
関数型言語っぽいっていう理解はＯＫ？
その他、あれば解説よろしく
79:デフォルトの名無しさん
04/01/14 13:50
>>78
アダプタとか関数オブジェクト廻りの技術が関数型っぽい。
あと演算子のオーバーロードも関連も型クラスとの関連が。
後、boostとかだとそのままずばりlambdaがある。
80:デフォルトの名無しさん
04/01/16 18:07
まだ勉強中なんでツッコミ歓迎。
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にすると代入が出来ない気がする。
81:デフォルトの名無しさん
04/01/16 18:20
>>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);}
};
色々問題がありそうだが。
82:デフォルトの名無しさん
04/01/16 18:52
>>81
operator T()なんて使い方が出来るのか。サンクス。
ただ加工に使う「+ 1」の値がmy_iteratorに入ってると
T_refのメンバにmy_iteratorへの参照も入れなくちゃいけなくて複雑になりそうだな。
そもそも加工をoperatorに頼っちゃいけないのだろうか。
83:デフォルトの名無しさん
04/01/17 00:29
プロキシオブジェクト使わないと厄介なところだな。
「参照じゃないと書き換えられない」みたいな問題は
More Effective C++（だっけ）の二重配列クラスの実装なんか
まさしく参考になると思う。
84:hiraoka
04/01/20 02:12
>>76
補足すると、継承したクラスのポインタに対応するため｡
>>80
boost::transform_iteratorがおすすめ。
自分で書きたければ、
T& operator*()と
T operator*() constを定義する方法もあると思う｡
85:hiraoka
04/01/20 02:13
>>76
補足すると、継承したクラスのポインタに対応するため｡
>>80
boost::transform_iteratorがおすすめ。
自分で書きたければ、
T& operator*()と
T operator*() constを定義する方法もあると思う｡
86:デフォルトの名無しさん
04/01/20 04:48
URLﾘﾝｸ(hp.vector.co.jp)
87:デフォルトの名無しさん
04/01/21 00:27
「C++は難しすぎ」 byコンパイラメーカ一同
88:デフォルトの名無しさん
04/01/21 18:41
コンパイラ屋さんってC++コンパイラを書くときに言語は何を使ってるんですかね？
Cなのかな？C++なのかな？
Cだと大変そうですね。
89:デフォルトの名無しさん
04/01/21 21:58
最初のC++はCに変換するプログラムで、Cで書かれていたそうだ。
最初のCはアセンブラで書いたそうだ。
最初のアセンブラは機械語で書かれた。バイトコードに直すのは人力でやった。
最近の商用のは知らんが、ほとんどCで書かれているんじゃないか？
90:デフォルトの名無しさん
04/01/22 00:47
“yacc”とか“コンパイラコンパイラ”でぐぐれ。
91:デフォルトの名無しさん
04/01/22 07:03
まともなエラー処理を書こうと思ったらyaccじゃ無理だろ。
92:デフォルトの名無しさん
04/01/22 16:16
まあ、yaccはあくまでコンパイラ作成を支援するものだし。
93:デフォルトの名無しさん
04/01/22 16:34
じゃあなんでコンパイラ・コンパイラなんて大仰な名前がついてるんだ？
94:デフォルトの名無しさん
04/01/22 17:45
ｽﾚﾘﾝｸ(tech板)
続きはこちらでどうぞ。
95:73
04/02/01 17:05
>>75,76,77
急に忙しくなってレスが遅れましたが、参考になりました。
ありがとうございます。
96:自称C++厨をクビにせよう運動
04/02/09 10:20
ｸﾞｺﾞｺﾞｺﾞｺﾞｺﾞ!!!
いまこそ、プログラマ革命を起こすときだ！
（亜ぼーんする愚か者には核ミサイル無量大数本分の死を！）
～ 自称C++厨の化けの皮をはがせ！運動展開中！ ～
(本当は自称C++厨なんてたいしたことがない、上辺だけなのだ！ 真実を見よ！)
大半のC++厨はインチキ詐欺師の卑怯者！
オブジェクト指向も知らなければデザインパターンも知らない悪い奴である。
しかも悪名高いウォータフォール信者と来た！ 許せん！ 今こそ正義の一撃を！
大半のC++厨は汚いコードを書いてチームをわざと混乱させメンテナンスの手間を増大させる悪魔なのだ！
大半のC++厨は自己保守的で官僚的で革新性が無く
自分のスキルの程度を誤魔化すためにわざとソースコードを読みにくくしているのだ！
(こいつらはわざと読みにくくすれば他人が解読するのにに手間がかかるので
凄いと思いこまれると勘違いしている馬鹿どもなのだ)
こんな卑怯者が許されるか！
蓋を開けてみればただのＣ言語しかできないとんでもない低脳である。
こんな悪魔のような給料泥棒なやつが金をもらっていることは絶対に許されるべきではない！
即刻減給するかクビにしてやるべきである！
このような卑怯なC++厨の行為は宣戦布告と見なさなければならない行為であり
大義名分を持って即刻解雇すべきである！
自称C++厨の化けの皮をはがせ！ 自称C++厨の化けの皮をはがせ！
自称C++厨の化けの皮をはがせ！ 自称C++厨の化けの皮をはがせ！
自称C++厨の化けの皮をはがせ！ 自称C++厨の化けの皮をはがせ！
正義は勝つ！悪の枢軸・自称C++プログラマをこの世から抹殺せよ！
97:デフォルトの名無しさん
04/02/09 11:08
>>96
暴れるのはマ板だけにしとけ知的障害者。
98:デフォルトの名無しさん
04/02/09 19:38
>>96
ただのＣ言語すらできないヒトは どうすればいいですか？
99:デフォルトの名無しさん
04/02/09 19:42
>>98
それは俺様のことか？
100:デフォルトの名無しさん
04/02/09 19:50
>>98
(ﾟДﾟ)
>>99
そうだ
101:デフォルトの名無しさん
04/02/10 01:39
>>96
おまえもHaskelとかScheme勉強しろよ。
102:デフォルトの名無しさん
04/02/10 02:20
HaskelやSchemeを勉強しても仕事の役に立つとは思えない
103:デフォルトの名無しさん
04/02/10 02:39
デザインパターン勉強しても仕事の役立つとはおもえない。
104:デフォルトの名無しさん
04/02/10 02:49
Modern C++ Designが仕事の役に立つとは思えない。
105:デフォルトの名無しさん
04/02/10 03:04
仕事が俺の役に立つとは思えない。
106:デフォルトの名無しさん
04/02/11 18:52
松戸ナルドがおいしいとは思えない。
107:デフォルトの名無しさん
04/02/11 18:55
松戸にもマクドナルドがあったのか
108:デフォルトの名無しさん
04/02/11 20:55
イノセンス、それは いのき
109:デフォルトの名無しさん
04/02/11 23:34
土佐、それは高知
110:デフォルトの名無しさん
04/02/12 00:50
北関東の県が必要だとは思えない。
111:デフォルトの名無しさん
04/02/12 12:15
>>110
群馬 栃木 茨城というわかりやすい駄目トリオがなくなると、
神奈川 埼玉 千葉のどんぐりの背くらべトリオによる
No2争いが激化する。
112:デフォルトの名無しさん
04/02/12 13:35
横浜＞神奈川
ディズニーランド＞千葉
さいたま＞埼玉
113:デフォルトの名無しさん
04/02/15 22:15
>>107
あるよ。まんまえに。いってみ
114:デフォルトの名無しさん
04/02/22 21:06
テムプレートってどういうときに使うんでつか？
難しすぎて頭がおかしくなります。
たとえば１から１００まで足すプログラムに使いませんよね？
115:デフォルトの名無しさん
04/02/22 21:14
使えますが
116:デフォルトの名無しさん
04/02/22 21:18
#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;
}
117:デフォルトの名無しさん
04/02/22 21:19
>>2
15歳ですべて悟った俺は変人でしょうか
118:デフォルトの名無しさん
04/02/22 21:47
テンプレートを使いこなしたかったら Modern C++ Design を読むべし、そうしなければ全く始まらない。
テンプレートはOOその他従来のパラダイムのように、プログラムを書くための物ではない(もちろん使えるが、そういうやり方は古いやり方)
Modernなテンプレートプログラムとは、プログラムを生成するプログラムを書くのだ。
例えばデザインパターンのパターンを見て、そのパターンを実装するのが従来のやり方。
テンプレートを使う場合は、そのパターンを生成するプログラムを書くのだ。
一つ上のステージからプログラムを見下ろす様にプログラムをするんだ。
119:名無し募集中。。。
04/02/22 22:01
>>115-116
それは１から１００まで足すプログラムというより、
１から１００まで足してある数値を取り出すプログラムでは？
120:デフォルトの名無しさん
04/02/22 22:17
実行時に足すかコンパイル時に足すかの違いでしかない。
121:デフォルトの名無しさん
04/02/22 22:30
コンパイラに足させるプログラム
122:デフォルトの名無しさん
04/02/22 22:37
template<int i> class sum
{
public:
int operator() {
return i + sum<i - 1>()();
}
};
template<> class sum<1>
{
public:
int operator() {
return 1;
}
};
じゃあこうすれば良いのか
123:デフォルトの名無しさん
04/02/22 22:55
>>122
オプティマイズがかかったらやっぱりコンパイル時に足していそうだな(藁
124:デフォルトの名無しさん
04/02/22 23:22
オプティマイズは考えなくていいんじゃないか？
設定やコンパイラによっても違うし。
コンパイル時に計算させるか、実行時に計算させるかの意図がコードに現れてればいいんじゃないかな。
125:デフォルトの名無しさん
04/02/22 23:31
どうしてもというのなら
template<int i> class sum
{
volatile int v;
public:
sum() : v(i) { }
int operator() {
return v + sum<v - 1>()();
}
};
126:デフォルトの名無しさん
04/02/22 23:32
sum<i - 1>()();
こうじゃなきゃだめだな
127:デフォルトの名無しさん
04/02/22 23:35
おまいら >>114 の質問に答えてないよ。
「使いませんよね？」と聞いているのに、「使える」という答えはおかしい。
いつもそうゆうコードを書くかどうかを聞いているので、可能不可能を聞いているのではない。
漏れの答えは、そんなことには多分使わない。
128:デフォルトの名無しさん
04/02/23 00:28
どうでもいいけど、
int operator() {
の宣言は、
int operator()() {
でないとコンパイル通らなくないか？
勘違いだったらｽﾏｿ
129:デフォルトの名無しさん
04/02/23 00:34
yes
130:デフォルトの名無しさん
04/02/23 00:40
>>127
どう使うかって事にもよるね、例えばその計算結果から型を選択するとかいった処理なら
テンプレートを使うしかないし・・・
最近はJavaやC#の場合、リフレクションとかもあるので無茶な事をすれば実行時にもできるかもしれんが、余りやりたくは無いねぇ。
131:デフォルトの名無しさん
04/02/23 00:45
リフレクションいいよね。
Ｃ＋＋で実現したいんだけど、どっかに参考になるコードないかなぁ。
132:デフォルトの名無しさん
04/02/23 08:37
むかーしリフレクションっぽいコードをC++で書いた。
お前のコードじゃねえだろどこで派食ったといわれて結構へこんだ。
まああれだ、スマートに書くか効率良く書くかの二者択一になるからやめとけ。
133:デフォルトの名無しさん
04/03/01 13:32
C++厨のレベルの低さが垣間見えるスレですね
134:デフォルトの名無しさん
04/03/03 18:26
これからなんだよ、まだこれからこのスレはすんげぇ面白くなるんだよきっと。
きっと1さんがこのスレを優良スレにしてくれるんだよ。
1さんがこのスレを名スレにしてくれるんだよ。
1さんが素晴らしいネタを提供してくれるんだよ。
だからみんな、これからの1さんの書き込みを楽しみにしようよ。
これからこれからこれからこれからまだまだまだまだ…
135:デフォルトの名無しさん
04/03/04 18:37
1さんって俺じゃねーか。おまえらまだスレの連番付け間違えた事チマチマ恨んでるのか？
でもせっかくだから盛り上げていくか？
>>133
а≧○иξ⊃ＸγΘ△Φ？
136:デフォルトの名無しさん
04/03/04 19:09
>>135
a=＄д゜【＠（）πr2+3.14
137:デフォルトの名無しさん
04/03/05 23:13
>>136
Пкδ＼Δν⊃∃ю！
138:デフォルトの名無しさん
04/03/06 02:10
>>114
『Effective C++』の41項参照。
例えばWin32の各種ハンドル型をデストラクタでクローズするラッパクラスを作るときに使った。
型は違う（HANDLE・HINTERNET・SC_HANDLEなど）。でも処理は同じ（最後にクローズする）。
『Modern C++ Design』の書き方を許してくれる職場は少ないと思う。
理解できる人間がいなくてメンテナンス性が下がるため。（理解さえできていれば本当は上がってるんだけどね。）
そういうときは仕方ないので宣言マクロ／実装マクロにする。それなら理解できる人も多い。
あとは標準ライブラリのコレクションを使えないときに（車輪を再発明するために）使った。
このときはメモリの動的確保をしないという制限があった。
（Allocatorを書く方法もあるが、上と同じ理由でそれが許されることは少ないと思う。）
139:デフォルトの名無しさん
04/03/07 20:04
>Allocatorを書く方法もあるが、上と同じ理由でそれが許されることは少ない
随分厳しいですな
もうちょっと分りやすい構造になればいいんですがね > template
漏れはもう boost から戻れない体になってしまいました。
140:デフォルトの名無しさん
04/03/15 11:12
三大悪の枢軸国の紹介
C++帝國(北朝鮮) ← C++厨代表の正体は、何と！ 金正日だった！
VB帝國(イラン) ← VB厨代表はイランに潜伏していいた！
Perl帝國(イラク) ← Perl厨代表フセインがついに逮捕された！
141:デフォルトの名無しさん
04/03/15 13:59
>>140
C++が分らなくて火病でも起こしたか？
142:デフォルトの名無しさん
04/03/18 16:38
Java帝国(オウム) ← Java厨代表は何と！地図夫(趣味:ソフマップ通い)だった！
143:デフォルトの名無しさん
04/03/29 19:49
鯖削除は難しすぎ
144:デフォルトの名無しさん
04/04/02 08:21
Modern C++ Designって簡単なことしか書いてないのにね。
それを難しいというのはよほどの馬鹿なんだろうね。
そんな馬鹿がソフトウェア開発にたずさわるのは社会的な悪だね。
医者だと無免許医は摘発されるのに
自動車だと無免許運転は摘発されるのに
プログラマーだけ低能でもやっていけるというのが諸悪の根源。
C++難しいとかいう脳障害の低能は
そもそもプログラミングに向いてないんだから
とっとと転職しろっつーの。
145:デフォルトの名無しさん
04/04/02 09:01
＞プログラマーだけ低能でもやっていけるというのが諸悪の根源。
大工よりまし。
146:デフォルトの名無しさん
04/04/02 09:32
>>144
> 医者だと無免許医は摘発されるのに
> 自動車だと無免許運転は摘発されるのに
ま、低能が免許持ちまくりなんだけどな、どっちも。
147:デフォルトの名無しさん
04/04/02 10:18
確かに免許制にして一定水準以上の者でないと開発に関われないとしてもいいかな。
その方が学ぶ側も採用する側も分かりやすくていいと思う。
148:デフォルトの名無しさん
04/04/02 11:27
>>146
なんなら私が手術してあげましょうか？
149:デフォルトの名無しさん
04/04/02 21:40
C++は難しくないけどC++厨はオナニーしすぎ
150:デフォルトの名無しさん
04/04/02 22:37
またわけのわかんないレスが来たな
151:デフォルトの名無しさん
04/04/03 15:52
難しいかどうかなんて問題じゃないんだ。
問題は出来るか出来ないかだろ？
ま、簡単だと言ってる奴ほど実は何も出来ない
というのはよくあるけどな。
152:デフォルトの名無しさん
04/04/04 08:53
ペーパードライバーならぬペーパープログラマーだな
153:ラインプリンタ
04/04/04 09:23
呼んだ？
154:デフォルトの名無しさん
04/04/21 05:09
普通、電気系のエンジニアはソフト"も"書けるがソフト屋はソフト"しか"書けないんだろ？
ちゃんちゃらおかしいね。それでもエンジニアか？あぁ？
ソフトぐらい文系あがりのねぇちゃんでも書くぜ。
人生の敗北者が下る職業
タクシー運転手，塾の講師，ソフト屋
だろ？
155:デフォルトの名無しさん
04/04/21 05:31
↓アビバ資格者
156:デフォルトの名無しさん
04/04/21 09:59
>>154 は、あまり難しいコードを見たことがないそうです。
157:デフォルトの名無しさん
04/04/21 20:12
ここで俺の登場！！！
158:デフォルトの名無しさん
04/04/22 11:48
と言われても…どちら様？
159:デフォルトの名無しさん
04/04/22 16:38
そのおかたをどなたとこころえる！？
160:デフォルトの名無しさん
04/04/23 20:30
1ですね。
161:デフォルトの名無しさん
04/04/28 22:53
URLﾘﾝｸ(page4.auctions.yahoo.co.jp)
162:デフォルトの名無しさん
04/04/28 23:06
OL５０人
163:デフォルトの名無しさん
04/04/28 23:10
難しいプログラムならバカでも書ける。
いかにサボり、楽をするために間単に書くかが私の人生のスタンスと一致していてすばらしい。
164:デフォルトの名無しさん
04/04/29 23:48
>>147
学生さん？
現場じゃそんな子と逝ってられませんよ？
165:デフォルトの名無しさん
04/04/30 14:35
C++はメモリ管理機構がないからムズカシイとかよく言われるけど、
言語側が暗黙のうちにGC用意してくれるよりもライブラリとして用意されるべきなんじゃないかな
と最近思うんだけどどうなんだろ。
影でこそこそ処理されると気持ち悪い。
166:デフォルトの名無しさん
04/04/30 15:05
ライブラリとして、だと
「わざわざ使わないといけない」だから
面倒な人間は何をしてくれるか予想がつかない。
167:デフォルトの名無しさん
04/04/30 18:00
つかjava使ってて思ったのが
＿|￣|○ ＜ 頼むから、俺にメモリ解放処理をさせてくれ
だった。
168:デフォルトの名無しさん
04/05/01 02:28
これからコンパイル後がどうなるかなんて何も考えずに、やらせたい処理だけ
便利なAPI使って記述すればいいって時代が到来するんだろうな。
低レベルな処理なんて組み込みだけ・・なんてことになるのかなぁ。
C++でﾊｧﾊｧする奴にとってはツマラナイ世界かも。
169:デフォルトの名無しさん
04/05/01 10:41
メモリ管理を自分でしないと気持ち悪いって人はあれかな、
実生活でもマメに掃除とかする香具師？
俺みたいに部屋は散らかし放題で
極限まで汚れたら渋々掃除するタイプはダメだ。
取ったメモリの解放まで面倒見てらんねえ。
170:デフォルトの名無しさん
04/05/01 10:58
>>169
漏れの場合，部屋は散らかりまくりだがヒープは絶対片付ける．
171:デフォルトの名無しさん
04/05/01 11:27
俺は後々片付けるのが嫌で
物理的な参考書とか資料とか極力本棚から持ち出さない人。
172:デフォルトの名無しさん
04/05/01 16:38
散らかっているかどうかよりもむしろ、物の位置や処遇が
「自分の手の内に入って」いないと気が済まないかどうか、に近い気が。
173:デフォルトの名無しさん
04/05/01 20:15
>>165
＞影でこそこそ処理されると気持ち悪い。
高級言語は、多かれ少なかれどこか影でこそこそやってます。
本当にそれが嫌なら、アセンブラで組めｗ
174:デフォルトの名無しさん
04/05/01 21:20
>>173
そうとも限らないだろ。
175:デフォルトの名無しさん
04/05/01 22:03
>>174
どういうところが限らないんですか？
内容無しの反論なら誰でも出来ます。
176:デフォルトの名無しさん
04/05/01 23:49
>>175
＞高級言語は、多かれ少なかれどこか影でこそこそやってます。
証明できないからじゃない？
177:デフォルトの名無しさん
04/05/02 00:51
>>175
「高級言語では」何が「影でこそこそ」に当たるの？
たとえばa = b + c * d; が
tmp = c * d;
a = b + tmp;
とかに分解される事？
マクロアセンブラでも、
ラベルがアドレスに展開されたりする事は
影でこそこそに当たらないの？
たとえば、Cでは何が影でこそこそしてる？Pascalでは？
どっちも高級言語じゃないのか、スマンな。
178:デフォルトの名無しさん
04/05/02 01:04
>>177
GCの話じゃねーのか？
179:デフォルトの名無しさん
04/05/02 02:50
言語が高級になればなるほど、コンピュータがやってくれることが増えるってだけだろ。
コンピュータは元から人間の手間を省く道具。だからそれは自然なこと。
それが嫌いならアセンブラ（よりも機械語のほうがいいか？）を使えってことだろ。
180:デフォルトの名無しさん
04/05/02 05:06
>>178-179
影でこそこそが気持ち悪いって言う人間に
考えもなしにアセンブラで組めなんていう煽りを何のするなということだ。
177で正論ぶってるから、更に気になっただけだ。
181:デフォルトの名無しさん
04/05/02 05:07
×考えもなしにアセンブラで組めなんていう煽りを何のするなということだ。
○何の考えもなしにアセンブラで組めなんていう煽りをするなということだ。
編集ミスった。
182:デフォルトの名無しさん
04/05/02 05:07
×177
○175
、、、orz
183:デフォルトの名無しさん
04/05/02 11:50
アセンブラは全く知らないんだけどメモリ解放はどうするの？
やはりプログラマによる手動解放？
184:デフォルトの名無しさん
04/05/02 12:51
>>183
mallocに相当するコード自分で買い解け
185:デフォルトの名無しさん
04/05/02 14:25
brkとかHeapAllocとかOS提供のAPIを呼ぶ
あとは、cのライブラリをリンクするとか。
186:デフォルトの名無しさん
04/05/03 23:09
C++を覚えるっつーか、使いこなすレベルになるころには
管理職をやらされるのが日本のコンピューター業界。
そして新人は今日もまたメモリリークしまくりのコードを量産する。
187:デフォルトの名無しさん
04/05/03 23:15
>>186
年取ると新しい考え方を受け入れられくなったり、徹夜の仕事
がとても続けられなくなるからそれでいいのよ。
188:デフォルトの名無しさん
04/05/04 09:42
>>187
若い頃から徹夜仕事しなかったし、この歳になっても睡眠時間3時間ですが何か。
あーでも、役職はついてるし部下もいるなぁ。
189:デフォルトの名無しさん
04/05/04 11:47
>>188
過労死すんなよｗ
190:デフォルトの名無しさん
04/06/12 19:50
過労死しそうな人が出るほど C++は難しすぎ
191:デフォルトの名無しさん
04/06/15 06:24
>>190
激しく同意
192:デフォルトの名無しさん
04/06/18 14:54
c++の何が難しいのかがわからない。
難しいこともできるって話じゃないのか？
俺的にはVBの方が難しい（めんどい）ような
あと、パールとかはキャストがきもい。
193:デフォルトの名無しさん
04/06/18 15:26
Perlのキャスト？
194:デフォルトの名無しさん
04/06/18 18:52
俺も、Javaや、VBのほうが、よっぽど難しい。
195:192
04/06/18 21:30
>>193
いや、だいぶ前にちょろっとやっただけだからうろ覚えだが、
c++なら明示的にキャストして、キャストできないようならコンパイル時にエラーでるしょ？
パールって何でもかんでも、暗黙的に型変換してるイメージあって、怖い。
196:デフォルトの名無しさん
04/06/18 21:37
perlがCGIの筆頭であり続けるのは、そのきもいキャストのおかげなのだが。
197:デフォルトの名無しさん
04/06/18 21:39
perlに型はありませんよ
198:デフォルトの名無しさん
04/06/18 21:43
コード中に型宣言が無いだけで実行時にはどの言語には型判断されてるでしょ
バリアント型ってそういうもんだと思われ
199:デフォルトの名無しさん
04/06/18 21:45
×言語には
○言語でも
200:デフォルトの名無しさん
04/06/18 21:49
なぜそこでVB?
201:デフォルトの名無しさん
04/06/18 21:50
バリアント型ってVBだけか？jsとかのvarもそれだろ？
202:192
04/06/18 22:10
いや、そのキモイキャストがいやだってだけ・・・。筆頭であろうが気にしない。
実行時判断っていうのが怖いわけで、例外とかめんどくさ。
俺が個人的にVB嫌いなのは、ポインタ取得とかめんどくさいから。
あと、まぁ、なんか色々めんどくさい。とc++になれてるとそう思う。
203:デフォルトの名無しさん
04/06/18 22:11
>>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 *)();
・・・
204:192
04/06/18 22:17
>>203
boost::anyとかあるけどね。
ATL系とかでも。
でもboost::anyの場合、
代入するときはともかく、値を取得するときは明示的にキャストして
失敗したら例外送出だからなぁ。
なんつか、この明示的にって段階踏まないといやなわけでして。
205:デフォルトの名無しさん
04/06/18 23:59
boost::variant
206:192
04/06/19 00:10
>>205
そういや、それもあったなぁ。
いまだ使ったこと無いが。
なんに使うと効率てきなのかいまいちわからん。
ビジターパターンに使えるっていうが、ビジターパターン自体まだ使ったこと無いや。
207:デフォルトの名無しさん
04/06/19 00:15
C++が難しくないなんて言えるなんてすごいな。
今までVB,C,C++,Dehphi,Java,PHPなどで業務アプリを作って来たけど、
一番生産性が低いと感じたのはC++だった。
もちろん、それなりに習熟すれば生産性はあがるのだろが、
習熟するまでの時間がかかりすぎる感がある。
今の職場では多分俺が一番C++に詳しいけど、C++をマスターしたなんてとても言えないし、
積極的にC++を採用したいか？と聞かれれば可能な限り他言語を選択したい。
C++マンセーになる理由が俺には解らん。。。
208:デフォルトの名無しさん
04/06/19 00:27
>>207
WindowsのServiceアプリ組むときなんかはC系の言語が一番便利なわけで
人によってはCでそのまま組むよりもC++の方が開発時効率が上がる
少なくとも私はそう
CよりもC++の方が一度に考えなければいけない要素が少なくて済む
209:デフォルトの名無しさん
04/06/19 01:10
>>207
C++以前にCに十分習熟していないせいだと思うよ
210:デフォルトの名無しさん
04/06/19 01:26
生産性の低い言語＝習熟しにくいだからな
熟練者が生産性高いよって言ってもサンプルにはならへんのが実情
個人的にはDに一番期待している
211:デフォルトの名無しさん
04/06/19 01:31
つーか、業務系なんてどの言語で書いたって同じだろ。
C++のメリットが活きるのは寧ろ制御系だからな。
212:デフォルトの名無しさん
04/06/19 01:36
てか、俺的イメージだが、
ｃ++からｃを省いたようなもんがJAVAって感じだが・・・。
VBで生産性あがるっていっても、簡単なもんだけでしょ？めんどいことになるとできなそうだし。
デルファイはいじったことないなぁ、簡単らしいって話はきくが。
PHPもまだないなぁ。
俺はｃ++2年ほどやったが、
後は、
アセンブラ、
ロケール、
メモリアロケータ、
modern c++ design 読んで、
デザパタ極めて、
マルチスレッドも極めるくらいかねぇ。
って先なげぇ。
まぁ、一部ｃ++以外にもつかえるが・・・。
213:デフォルトの名無しさん
04/06/19 20:53
ISO C++の規格策定にかかわっている人にとっても、C++は難しいらしい。
現行の規格に内在するバグというか不都合な点がバラバラ出てきている。
URLﾘﾝｸ(www.open-std.org)
URLﾘﾝｸ(www.open-std.org)
214:デフォルトの名無しさん
04/06/20 11:10
C++もＪａｖａも使ってる俺からすればJavaの方が圧倒的に簡単。
両者比較してJavaのほうが難しいなんていってる奴はオブジェクト指向理解して無いだろ（ﾌﾟﾌﾟﾌﾟｯ
せっかくC++コンパイラ使ってるのにＣみたいな書き方ばっかりする宝の持ち腐れオオバカや郎なんだろうな（ｗｗｗ
215:デフォルトの名無しさん
04/06/20 12:00
>>214
誰も「Javaのほうが難しい」なんていってないと思うが。
216:デフォルトの名無しさん
04/06/20 12:07
Javaしか出来ないJava厨の思考回路は意味不明過ぎて難しい
217:デフォルトの名無しさん
04/06/20 17:25
Cしか出来ないJavaを使った事のないような時代遅れの無能親父の煽りはもう沢山
218:デフォルトの名無しさん
04/06/20 20:40
Javaしかできない連中はただいま大量生産中です。
正直言ってヤバいっすね。
219:デフォルトの名無しさん
04/06/20 21:02
ほとんどｃ++しかできないです。
まぁ他の覚えるのはそれほど苦労はしないけど。使わんからすぐ忘れる。
220:デフォルトの名無しさん
04/06/20 21:05
次の本命はD言語だな
メモリリークを起こさない上に任意のタイミングでGCできる優れもの
２ｃｈブラウザもDで作れば無駄にメモリ取らずに済むよ
221:デフォルトの名無しさん
04/06/20 21:23
>メモリリークを起こさない上に任意のタイミングでGCできる優れもの
大抵のGCはメモリリーク起こさないし、任意のタイミングでコレクトできると思うんだけど
>２ｃｈブラウザもDで作れば無駄にメモリ取らずに済むよ
なんで？
222:デフォルトの名無しさん
04/06/20 21:37
>>221
>>メモリリークを起こさない上に任意のタイミングでGCできる優れもの
>大抵のGCはメモリリーク起こさないし、任意のタイミングでコレクトできると思うんだけど
ランタイムなしでそれを実現できるのさ
>>２ｃｈブラウザもDで作れば無駄にメモリ取らずに済むよ
>なんで？
２ｃｈブラウザは起動初期の倍近くのメモリリークが起こってるからね
223:デフォルトの名無しさん
04/06/20 21:45
>>222
ランタイムなしでそれを実現出来るから何？
2chブラウザって沢山あるけど、そもそもどの2chブラウザなの？
224:デフォルトの名無しさん
04/06/20 22:03
>>223
ランタイムが無いって事は早いって事じゃん！
ちなみに俺にブラウザはLive2ch、最強だぜ
225:デフォルトの名無しさん
04/06/20 22:17
Live2ch って VB製じゃなかったか？
速さとか軽さとかを追求したものではないだろう……。
226:デフォルトの名無しさん
04/06/20 22:22
というかVBランタイムってGC無いんだと今知ったのは内緒ｗ
227:デフォルトの名無しさん
04/06/20 22:29
ネイティブでGC作る言語は強力だとは思うが
資産が無い上にMSがC#発表したばかりでのってくるとも思えないのが痛い
228:デフォルトの名無しさん
04/06/20 22:38
おまいら、自分のケツぐらい自分でふけよ。
その内、下の世話までM$におながいすることになるぞ。
229:デフォルトの名無しさん
04/06/20 23:09
てーか、GCいらない。
メモリ取得、解放するときの動作早くしろ。
自分でメモリアロケータをカスタマイズしなくても、
コンパイラオプションの設定で超高速で動くようにしてくれ。
230:デフォルトの名無しさん
04/06/20 23:20
GC使ったほうが長時間安定した速度で動くから、
非GC環境が速いとも言い切れないらしいよ
231:デフォルトの名無しさん
04/06/21 00:12
今ホットゾヌ２使っているけど、メモリリークひどすぎ。Delphiなんだけどなぁ。
スレをどんどん見ていくとあっという間に５００ＭＢほどに未使用メモリが膨れあがる。
正直一番気に入っているので、C#で書き直して( ﾟдﾟ)ﾎｽｨ…。
232:デフォルトの名無しさん
04/06/21 00:21
>>230
できれば根拠が知りたい。
233:デフォルトの名無しさん
04/06/21 00:55
>>232
良く>>230の言っている意味がわからんが、非GC環境で「メモリリーク」が
どんどん起こったとして、メインメモリを食いつぶしてスワップ起きまくりに
なるから遅くなる、とかそういう次元の話なのだろうか。
234:デフォルトの名無しさん
04/06/21 01:07
メモリリークは非GC環境に限った話じゃないんだが。
235:デフォルトの名無しさん
04/06/21 01:25
>>232-233
URLﾘﾝｸ(www.kmonos.net)
より
C/C++ プログラマは明示的なメモリ確保と解放に慣れていて、
ガベージコレクタの効率や利点については懐疑的なようです。
私は、 一からガベージコレクションを念頭に置いて書いたプロジェクトと、
既存のプロジェクトを GC を使うように方向転換した経験のどちらも持っていますが：
ガベージコレクトされたプログラムの方が高速です。 これは直感に反するかもしれませんが、その理由は：
236:デフォルトの名無しさん
04/06/21 01:25
●明示的なメモリ管理の際によく使われる手法は、参照カウントです。
代入があるたびにカウントを増やしたり減らしたリソースを挿入するのは、 速度低下の原因になっています。
スマートポインタクラスでラップしても、 速度的な解決にはなりません。（
またいずれにせよ、 循環参照を削除できない参照カウント方式は、 一般的な解決策ではありません。）
●オブジェクトによって獲得されたリソースの解放には、 デストラクタが使用されます。
多くのクラスでは、このリソースとは 割り当てられたメモリのことです。
GCを使えば、 ほとんどのデストラクタが空になり、完全に削除してしまえます。
●メモリ管理のためのデストラクタは、 オブジェクトがスタックに置かれたときに影響が顕著になります。
例外が発生したときに、全てのスタックフレームでデストラクタが呼び出され、 メモリを解放するような仕組みが必要となるのです。
もしデストラクタが関係しなければ、例外を処理する特別なスタックフレームを 設定する必要がなくなり、コードは高速に実行されます。
●メモリ管理に必要なコードは全てを合わせるとちょっとした量になります。
大きなプログラムになるほど、キャッシュに入らない部分が増え、 ページングが多く発生し、 プログラムが遅くなります。
●GCは、メモリが残り少なくなってきたときのみ実行されます。
メモリに余裕があれば、プログラムは全速力で実行され、 メモリ解放に一切時間を取られません。
●モダンなGCは、過去の遅いものより遙かに発展しています。 世代型のコピーGCには、 昔のマーク＆スイープアルゴリズムの非効率さはありません。
●モダンなGCはヒープの詰め直しを行います。 これによってプログラムが活発に参照するページの数を減らし、 キャッシュヒット率を高め、 スワップ回数が減ります。
●GCを使うプログラムは、メモリリークの積み重ねで次第にパフォーマンスが悪化、 という事態に縁がありません。
237:デフォルトの名無しさん
04/06/21 09:34
> ●GCを使うプログラムは、メモリリークの積み重ねで次第にパフォーマンスが悪化、
> という事態に縁がありません。
これはウソだな
238:初期不良
04/06/21 10:07
まあ、突っ込みたいのはわかるがメモリリークになる可能性は低くなっていると言う事でいいんじゃねーの？
239:232
04/06/21 10:57
>>235
提示してくれたページ、GC周りをさらっと目を通した。ありがとう。
●スマートポインタは使いたいケースに応じて選ぶことができるから、
参照カウントだけと比べるのはどうかなぁと思う。
●デストラクタが空になるのはスマートポインタでも同様。
●例外に関しては同意。
●メモリが少なくなって来た時にごっそりメモリ解放するんだと
むしろその一瞬非常に不安定になるのではないか。（これは欠点に書いてあったな）
自分は例外バンバン投げたいのでデストラクタが重くならないなら
それはありがたい。
ただ、Dって面白そうだね。autoを使ってscopedに解放もできちゃうようだし。
きめ細やかな言語だと感じた。GCの話題から外れてゴメン。
240:デフォルトの名無しさん
04/06/21 12:00
まあ、スタイルにも依るんでしょうけど。
●明示的なメモリ管理の際によく使われる手法は、参照カウント...
shared_ptrってそんなに頻繁にコピーってする？
俺は所有権のはっきりしないリソース（ファイル・ハンドル等）の管理に
使うことが多く、参照カウンタが変化するのってタスク相当の粒度の
オブジェクト間の構成を初期化するときぐらい。
●またいずれにせよ、 循環参照...
上記のような使い方をする場合は、保持するオブジェクトと
保持されるオブジェクトの関係が階層的になり、参照がループすることは
無い。むしろGC導入によるdtor呼び出し遅延のほうが俺的には大問題。
●メモリ管理のためのデストラクタは、 オブジェクトがスタックに...
俺の場合、Appレベルでは例外って殆ど使わないし。
つうか、GCスレってないのね。
241:デフォルトの名無しさん
04/06/21 18:54
>>240
「コンパイラ・スクリプトエンジン」相談室が失速気味なので
良かったら使ってやってください。
ｽﾚﾘﾝｸ(tech板)
242:デフォルトの名無しさん
04/06/21 20:27
>>239
>●デストラクタが空になるのはスマートポインタでも同様。
同様じゃないよ。C++だと書かなくてよくなるだけで、実際はコンパイラが生成してる。
GCがあると、「完全に」削除できる。
243:デフォルトの名無しさん
04/06/21 20:40
脳内コンパイラｷﾀ------
244:デフォルトの名無しさん
04/06/21 20:47
？
245:デフォルトの名無しさん
04/06/21 21:33
>>242
dtorに書いてなくても暗黙的にメンバ変数のdtorが呼ばれるつう
意味ならその通りだけど。
ていうか、236の2番目のはどういうメリットなんだろう。
記述忘れてメモリリークって意味ではauto_ptr/shared_ptrで書けば
ありえないし。まともなC++erならメンバにauto_ptr等を含んだ
オブジェクトを頻繁に（例えばsortの比較関数オブジェクト内で）
生成・破棄するようなコードはかかないだろうし。
サイズが減ってキャッシュが云々ってのもいまいち説得力に欠ける。
246:デフォルトの名無しさん
04/06/21 22:00
>>242
オブジェクトのデストラクタは空
スマートポインタのデストラクタは空でない
ということがいいたいのだろう
オブジェクト内にスマートポインタをもつなら
結局オブジェクトのデストラクタも空でなくなるが
247:232
04/06/21 22:06
>>242
デストラクタについては、
1. ソース上書かなくて良くなる
2. スコープが切れた瞬間に呼び出されるわけではなくなるから例外が効率良くなる
と言っているように見えた。だから1についてスマートポインタと同様と書いたんだが、
文意は違ったのかもな。でも、把握した事実は変わらないと思う。
完全に削除って表現が微妙だな。デストラクタが呼ばれなくなるわけじゃなくて
呼ばれるタイミングがスコープから抜けるタイミングではなくて、GCのタイミングになるよ
という意味だよね。
…C++から離れてる。そろそろやめたほうが良さそうだ。名無しに戻ります。
248:デフォルトの名無しさん
04/06/21 22:50
>>235
一般論としてGC付のが速いって言うなら
理屈はいいから実際のベンチ出せといいたい。
249:デフォルトの名無しさん
04/06/21 23:15
>>248
お前もGC無しの方が早いというならベンチ出せコラ
つか、どういうベンチプログラムならうまく計れるんだコレ
250:デフォルトの名無しさん
04/06/21 23:17
オブジェクトの生成と破棄（スコープアウト）をひたすら繰り返すベンチだな
251:デフォルトの名無しさん
04/06/21 23:20
計るんならゴミ回収遅延によるシステム全体の
ディスクキャッシュ効率の低下も考慮しとけって。
252:デフォルトの名無しさん
04/06/21 23:24
>●GCは、メモリが残り少なくなってきたときのみ実行されます。
>メモリに余裕があれば、プログラムは全速力で実行され、 メモリ解放に一切時間を取られません。
これを素直に読むと
GC有りのプログラムを多数常駐させると互いにメモリ圧迫しあって
パフォーマンスががた落ちになりそうに聞こえるわけですが
253:デフォルトの名無しさん
04/06/21 23:27
言語とは関係ないとはいえ、現実的に
メモリが不足しがちだとOSまで不安定になるしねぇ。
254:デフォルトの名無しさん
04/06/21 23:30
あとDのコンパイラの最適化ってどの程度やってるの？
もともとコンパイラ屋だから能力的にはできるんだろうけど
言語仕様決めてライブラリガリガリ書いてその上最適化もやるって無理っぽくない？
255:デフォルトの名無しさん
04/06/22 01:47
・メモリが不足したらGCが走る
・メモリが不足するとOSが不安定になる
ということは、これに
・論理メモリよりも物理メモリの方が小さい
をプラスすると
・GCが走るときはOSが不安定なとき
・OSが不安定になるまでGCが走らない
ってなことになるんじゃないかしら？
256:デフォルトの名無しさん
04/06/22 01:59
コンパイラ屋だけど、実際GCの方が総合的には速いと思う、
コンパイラ側が全部管理できればオプティマイザに特別なアプローチが出来るからね。
ただC++には似合わないと思う、最小限の機能強化でGCはライブラリにして今流のtemplateでエレガントに実装すべきだ！
と主張してみたかったりもする。
C/C++は、組み込みから汎用までいかなる環境にも耐えられる言語であって欲しいです。
言語本体は最小限の機能のみをもつ機械語翻訳機がいい。
ところでDはGCを自作で置き換えるとかできるのかな？
日に日に強力になってきているDに興味が沸きつつある今日この頃。
257:デフォルトの名無しさん
04/06/22 05:44
Cは恥かしすぎ
258:デフォルトの名無しさん
04/06/22 10:13
>>256
>総合的には速いと思う
GCの最適化で？それともコードの実行時最適化？
もっともC++でもそういう総合的に早くするって考えは
あるよね。例えばvectorにpush_backする時にサイズを
２倍ずつ増やすとか。C++erでもそういうトレードオフを
理解しないでSTLとか使ってる奴っているだろうし。
259:デフォルトの名無しさん
04/06/24 17:21
vectorが完全に連続したメモリを確保するのに対して、
dequeがブロック単位でしか連続したメモリを確保しない事を知らない香具師が多すぎ
260:デフォルトの名無しさん
04/06/24 17:25
突然なんだ？
261:デフォルトの名無しさん
04/06/24 17:29
で、ベンチはまだか?
262:デフォルトの名無しさん
04/06/25 00:25
>>259
バッファ用のバイト配列をvectorで確保すると
知らない人間は面食らうよね
263:デフォルトの名無しさん
04/06/25 01:43
C++の難しさって殆んどtemplateが占めてんじゃねーの？
と思ったら>>144みたいなのも居るのね。。。
264:デフォルトの名無しさん
04/06/25 10:04
vector v(x);
read(&v[0]);
なんてやるなら、素直にscoped_arrayや、
それが許されないならコピペや自作で対応した方が
見た目にも易しいし。
265:デフォルトの名無しさん
04/06/25 10:27
>>264
同意しかねる。
その用法はvectorの設計コンセプトに合致するものであり、何の不満も無いよ。
266:デフォルトの名無しさん
04/06/26 12:49
同じく同意しかねる。ただ不満はある。
C++の言語が難しくて聖書のようにあげられる代表的な数冊の本を
読破理解しないと使いこなせないような言語になっちゃうのは
見た目に直感的じゃないからと思う。
267:デフォルトの名無しさん
04/06/26 13:02
でも全体としての言語仕様の大きさはともかく、
すぐ上で挙げられている「テンプレート」や「STL」といった個々の要素に関しては、
習うより慣れろを地で行ってると思うよ。本はリファレンス的に使えばそれで。
268:デフォルトの名無しさん
04/06/26 14:42
C++の難しさは言語仕様よりも使用方法のノウハウの難しさのような気がする
個々はたいした事はないのに組み合わさったときの威力は大きく、それを利用するためだと思う。
template <typename H,typename T> struct TypeList
{
typedef H head ;
typedef T tail ;
} ;
と書かれれば、これがどんな定義なのかはC++をちょっと知っていれば判るが
これをどう活用するのかとなると急に難しくなる。
分りやすい書籍を作るのに従来通りの言語仕様の本とライブラリの本だけでは補えない部分があるのに
その部分を上手く解説した本はあまり無い気がする。
269:デフォルトの名無しさん
04/06/26 15:16
>>268
それ、発想が Lisp 的なんよね。
Lisp 知ってる人からすると、そのコードも見ただけで何がしたいかすぐ分かる。
template を使ったメタプログラミングって関数型言語と似てるらしくて、
Lisp 的表現が良く使われる。
270:デフォルトの名無しさん
04/06/26 15:29
実際のコードは逐次処理的にかいてTypeList等で
それらのコードを組み合わせる構造を記述して
GenScatterHierarchy等で実際にコードを組み合わせて
実装を生成する。
関数型言語だと構造だけでなく実際に実行されるコードも
関数型っぽく記述しなきゃいけないってのが、慣れてない人間
にとっては厳しい。
そういう意味でC++でのMPっての有難いんだよな。
271:デフォルトの名無しさん
04/06/26 21:29
馬鹿は馬鹿なりの使い方すればいいし、
頭いい奴は頭いいなりの使い方すればいい
ってだけの話なんじゃないの？
272:デフォルトの名無しさん
04/06/26 21:40
>>271
両者が一緒にいるときはどうしたらいいのでしょう。
273:デフォルトの名無しさん
04/06/26 22:12
一番はバカにコードを書かせないで頭いいヤツに全部かかせることかな。
そっちの方が早く、優秀なモノが出来るだろう。
274:デフォルトの名無しさん
04/06/26 22:21
根幹にあたる部分を、頭いい奴にザッと作らせる。
頭悪い奴には、ただひたすらそれを使うか、応用する部分を作らせる。
プログラミングに限った話じゃないがナ。
275:デフォルトの名無しさん
04/06/27 02:40
>>272
ベアプログラミングで鍛えるべし。
勉強するきないやつなら、いじめるべし。
276:デフォルトの名無しさん
04/06/29 15:53
ネタふり
C++のグローバル変数初期化タイミングは難しすぎ。
dynamic initilizationなグローバル変数にいたっては
main前に呼ばれることすら保証されてない。
dynamic initilizationなグローバル変数の初期化の
スレッド安全性とか考えると頭痛くなる。
また、main前の初期化順序もある程度は制御したい。
翻訳単位のモジュール性を向上させる意味でも。
こればっかりはjavaが羨ましいよ...。
277:デフォルトの名無しさん
04/06/29 17:37
グローバル変数使うなよ
278:デフォルトの名無しさん
04/06/29 17:46
データメンバ ≒ グローバル変数
279:デフォルトの名無しさん
04/06/29 17:54
Cをやってきた人はC++が出来ないと嘆く人が多いですよね？
自分はC++から入ったんでCの理解はさほど困らなかったんですが、
教授でもそういう人が居ますよ。駄文失礼しました。
280:デフォルトの名無しさん
04/06/29 17:57
出来ないんじゃなくてやる気が無いだけだろ。
CとJavaがあればC++いらないし。
281:デフォルトの名無しさん
04/06/29 19:19
>>279
多い？そんなに聞かないけど。。
プログラムスタイルの違いに始め戸惑うだけじゃない？
282:デフォルトの名無しさん
04/06/30 00:13
>>281
現場では意外に多いよ。テンプレートや継承を勉強せずにいきなりソース見るから理解できるわけもないんだけど。
283:デフォルトの名無しさん
04/06/30 04:34
>>276
そういうのは処理系依存になる事も多いね
#pragma で明示的に指示できる処理系もあるよ
組み込み向けでは、コンパイラメーカーにリクエストだすと機能追加してくれる事もあるし
判り難い標準仕様よりも、そっちに頼っていたりする事が多いです。
284:276
04/06/30 10:14
>>283
確かに、処理系依存では有るけど・・・。
言語内でそういうのを保証しようとするとstaticなlocal変数とか
利用する羽目になるけど、スレッド安全性とかコストとかの問題も
あるし。main先頭でいちいちリソース初期化等の処理を書くってのも
モジュール性の観点から考えるといまいちな気がするしなぁ。
285:デフォルトの名無しさん
04/07/02 00:35
>>279
C++よりもCのほうが難しいだろう。
C++なら簡単にできたことがCだといくつかの要素に還元せねばならず、
しかも全部横並びの関数になるため凝集度が低くなってしまう。
あとからメンテするのが大変。
C++を極めた人間のC++ソースと
Cを極めた人間のCのソースなら
前者のほうが分かりすい。
286:デフォルトの名無しさん
04/07/02 00:39
>>285
ソースの分かりやすさと言語の難しさは違うと思われ。
287:デフォルトの名無しさん
04/07/02 22:26
>>282
ヴァカみたいにテンプレートや継承使いまくってるタコソースなんか見る気がしないということでは ?
288:デフォルトの名無しさん
04/07/03 01:27
>>285
C++で本格的にプログラムを書いた事が一度もありませんね？
289:デフォルトの名無しさん
04/07/03 09:06
>>288
煽っているつもりだろうが、それはむしろ逆だろ、本格的に書けばC++の方がやさしい
C++の言語仕様は厄介だから、ちょこっと書く分には難しい。
変な煽りはヤメレ
290:デフォルトの名無しさん
04/07/03 23:43
>>289
別に、C++でも、C風に書くこともできる
291:デフォルトの名無しさん
04/07/04 04:21
おじさんはextern "C" {}のトリコ
292:デフォルトの名無しさん
04/07/05 02:14
Ｃ＋＋の仕様準拠率がもっとも高いコンパイラって、
現時点では何になるのでしょうか？
もしかしたらスレ違いかもしれないけど、
これだけ「難しい言語」だと
仕様に準拠するのも大変そうだなぁということで…。
293:デフォルトの名無しさん
04/07/05 14:53
準拠度そのものを比較したってのは知らないけど、
Boostのレギュレーションテストは参考になるね。
URLﾘﾝｸ(boost.sourceforge.net)
294:デフォルトの名無しさん
04/07/05 18:25
本格論議はよくわかんないけど、std::map なんかがやっぱり便利だから、
よく初心者の勉強用に用いられる「単語の出現頻度を調べよ」みたいな
プログラムは、C の場合より著しく簡単になるよね・・・
295:デフォルトの名無しさん
04/07/10 14:16
>>282
それはソース云々より設計がタコ
どんな言語で書いてもタコはタコ
まC++はタコさ加減が露呈しやすい言語ではあるが
VBなんかだとみんなタコだからカモフラージュになるしな
タコじゃないほうが浮いて目立って困る
296:デフォルトの名無しさん
04/07/10 14:20
295=タコじゃないつもりのタコ
297:デフォルトの名無しさん
04/07/10 16:32
いきなり設計云々が出てくる辺りがとっても蛸。
298:295
04/07/10 18:48
>>287と>>282を間違えたあたりがタコorz
299:デフォルトの名無しさん
04/08/07 19:46
言語仕様がタコなC++の時代は終わった
これからはtemplateを使う必要がないJavaの時代です
300:デフォルトの名無しさん
04/08/07 19:50
>>299
ｳｾﾞｰあげんなﾎﾞｹ 程度の低い釣りは秋田
301:デフォルトの名無しさん
04/08/08 01:33
>>293
やっぱりboostなんて使えないってことかな。
302:デフォルトの名無しさん
04/08/08 01:34
>>301 意味がわかりません。
303:デフォルトの名無しさん
04/08/08 01:45
>>302
移植性が低いってことでは
304:デフォルトの名無しさん
04/08/08 09:08
boost が使えなくて泪目で boost なんて必要ないんだぁぁぁっ
て事ですな。
305:デフォルトの名無しさん
04/08/11 03:38
>>299
>templateを使う必要がないJavaの時代です
1.4でがんばってね。
306:デフォルトの名無しさん
04/08/12 06:24
現場だと継承、テンプレート一切使わないってこと多いな。
テンプレートなんてそんな難しいか？
boostはともかく、STLと簡単なテンプレートぐらいなら誰でも理解できるだろ？
テンプレートが難しいってのは、一部の天才が作った
ジェネリックプログラムとかのこと？
307:デフォルトの名無しさん
04/08/12 06:55
サイズが10倍になるのでプロの現場では使われません。
308:デフォルトの名無しさん
04/08/12 07:00
テンプレートが難しいんじゃなくて、テンプレートを使って書かれたコードに、
テンプレートパラメータの名前省略されたものが多かったり
traitsとかpolicyに分解されてコードが細切れの散り散りだったり
その上、#ifdef等で切り刻まれていて全体像を把握しづらいコードが多いというだけのこと。
309:デフォルトの名無しさん
04/08/12 07:38
そりゃぁセンスのない奴が書けばテンプレートに限らずね。
>>307
仮令10倍であっても作業効率が上がるのであればプロだからこそ使いますが。
#サイズ云々する現場なんて寧ろ限られるって。
310:デフォルトの名無しさん
04/08/12 17:09
DinkumwareのSTLはセンスの無い奴が書いたのか？
311:デフォルトの名無しさん
04/08/13 05:03
C++の仕様はセンスの無い奴が書いた
312:デフォルトの名無しさん
04/08/14 01:18
>>310
コンパイル時のリソース消費を少しでも軽減するためらしい。
あとは、真似防止か。
313:デフォルトの名無しさん
04/09/03 12:27
Loki を理解するよりも、STL のソースを読むほうが難しいと思う。
314:デフォルトの名無しさん
04/09/03 13:54
実装によるだろ（ｒｙ
315:デフォルトの名無しさん
04/09/04 23:55
>>313
じゃあ、M$版の奴。
316:デフォルトの名無しさん
04/09/06 13:52
C++使えると豪語する奴=本当はCしかできない低脳
ｽﾚﾘﾝｸ(prog板)
317:デフォルトの名無しさん
04/09/06 22:56
漏れはC++よりもVBが難しい
318:デフォルトの名無しさん
04/09/08 11:03
C#やっとけ。嫌ならDやっとけ。嫌なら(ry
319:Ruby!!
04/09/08 17:09
Ruby!!!!!!!!!!!!!
320:デフォルトの名無しさん
04/09/08 19:10
C++って使いどころがない。
for_eachとかいつ使うんだこんなの、forの劣化版でしかない。
321:デフォルトの名無しさん
04/09/08 20:10
例の「ほげ言語のパラドックス」の意味がよくわかるねｗ
322:デフォルトの名無しさん
04/09/08 22:51
>>302
inline
323:デフォルトの名無しさん
04/09/08 23:25
>>320
お前、あれだろ。車を「こんなの地球温暖化の原因になるだろ」って難癖つけて
乗らないだろ。
324:デフォルトの名無しさん
04/09/08 23:44
車と地球温暖化って？
なに言っての、このボンクラ
どこかで聞きかじったのかしらん？ｗ
325:デフォルトの名無しさん
04/09/09 00:47
車と地球温暖化の二つの単語から
「聞きかじった」とかいう発想が出てくるのが凄いｗ
「なに言っての」のあたりといい、かなり必死なようで。
理由はわからんが。げらげら
326:デフォルトの名無しさん
04/09/09 01:29
↑またまた新手の厨が出現ｗ
327:デフォルトの名無しさん
04/09/09 01:30
>>325ってきっと、偉そうなこと言っときながら、GUIなPCしか触ったことないんでしょうね。
DOS時代を知らないんだな、こういう香具師。
328:デフォルトの名無しさん
04/09/09 02:02
悔しいからって二つも書かなくていいぞ、324ｗ
329:デフォルトの名無しさん
04/09/09 03:01
C++は使いまくりだろ。俺はCの方がよく使うけど。
一番使うとこがないのはRubyとJava。
330:デフォルトの名無しさん
04/09/09 03:35
言うまでも無いけど、仕事によって使用頻度が違ってくるからなあ。
普通は使わない言語の方が多いだろ。
逆に、まんべんなく使用するとなったら、それ部署たらいまわしにさ（ｒｙ
331:デフォルトの名無しさん
04/09/10 22:07:23
Java言語仕様も包含してC+++ つーのはどう？
えーい、こうなったら、VBやDelphiも許してしまう
てんこもり言語「C+++++」のお出ましだ！
・・・もうマニアしか使えねぇな
332:デフォルトの名無しさん
04/09/10 22:21:24
class C+++++: public C++, public Java, public VB, public Delphi, protected C#;
333:デフォルトの名無しさん
04/09/10 22:26:06
最強言語Ruby!!!!!!!!!!!!!!!
334:デフォルトの名無しさん
04/09/10 22:46:31
class 最強言語: public C+++++, private Ruby;
335:デフォルトの名無しさん
04/09/11 13:34:55
>>332-334
(ﾟДﾟ );;; ＜ｽｹﾞｪ・・・
336:デフォルトの名無しさん
04/09/11 13:39:36
private Rubyという言葉に笑った。
言いえて妙
337:デフォルトの名無しさん
04/09/11 14:07:08
C++って、何でもできるのがいいよね。
ビットフィールドとか共用体をCから引き継いでるから
エンベディッドのきつい環境でも、メモリを節約しつつ
ある程度見やすく書けるし。
メンバ関数ポインタを配列に突っ込んだりやりたい放題。
一人で組むんなら最高の言語だよ。
338:デフォルトの名無しさん
04/09/11 15:32:40
>>337
>一人で組むんなら
人数が何か関係してるのか？
339:デフォルトの名無しさん
04/09/11 19:22:16
>>338
多人数で組むなら、あんまりトリッキーなコードは書けないじゃん。
それならJavaでも大差ない。
340:デフォルトの名無しさん
04/09/12 00:43:44
俺、最近<boost/preprocessor.hpp>の利用による繰り返し処理を勉強中何だけど
もしかして、これって、perlなどの言語でちょちょいと書いて、出力して、コピペ
したほが可読性の面からもいいんじゃないかと気づいてしまったんだけど
まだまだ理解が足りないというかとなのかな。
341:デフォルトの名無しさん
04/09/12 01:32:06
C++ってそんなに難しいか？
STLが超便利でCなんてやってらんない体になってしまった
342:デフォルトの名無しさん
04/09/12 02:08:55
>>341
幸せな時期だね。
343:デフォルトの名無しさん
04/09/12 05:17:05
286上のQuick C、MASMの時代からC、C++一筋で趣味、仕事でやってきて
他の言語はいらないとまじめに思ってたんだが・・・最近、C#をCつながりで
やってみるかと覗いてみたら・・・もうC++の時代は終わりかもしれんな。
C++を身につけた人間があえて乗り換える必要はないが、新人にC++を教えたり
薦めたりする気はなくなったよ。これからやる人はC#やった方が良いな。
.NET→WinFXと進んでいこうとするならなおさらだな。
344:デフォルトの名無しさん
04/09/12 05:55:31
URLﾘﾝｸ(www.square-enix.co.jp)
小さすぎて見えんがな('Д`)
112 名前：名前が無い＠ただの名無しのようだ ：04/09/09 21:07 ID:s4msPAUO
URLﾘﾝｸ(www.ffcompendium.com)
URLﾘﾝｸ(www.ffcompendium.com)
345:デフォルトの名無しさん
04/09/12 17:33:17
>>343
C#は絶対にC＋＋は超えらんないと思うよ
C#って実質Windowsでしかつかえねーじゃん
WindowsでもDLL内の関数なりクラスを使うとなると
面倒だし・・・
挙げだすと枚挙に暇がない
WindowsではVC++&MFCこれ最強
ま ち が い な い！
346:デフォルトの名無しさん
04/09/12 18:51:02
オトトイ、キ・ヤ・ガ・レ！
347:デフォルトの名無しさん
04/09/12 19:26:19
Windows + C言語のみでMFCも使わずWin32APIネイティブ。
自分でWinProcからMSGをディスパッチしる！ ＜これ最強。
348:デフォルトの名無しさん
04/09/12 20:10:59
>>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++を知っとく
ってのは悪くないとは思うけどね。
349:デフォルトの名無しさん
04/09/12 21:27:02
じゃあ、その画像処理処理コードをC++で書き直してみたら？
C#がC++を凌げない答えがそこにあるから。
350:デフォルトの名無しさん
04/09/12 21:27:08
>>348
> まぁ、ハードに近い分野をMSがどうやってクラスライブラリにのっけてくるか、お手並み
> 拝見だけど、.NETの最適化も1.1→2.0βで大幅に進んでるからね。画像処理のコードを
> 1.1と2.0βで同じようにコンパイルしたら5倍ほど速度アップしてた。1.1上で約16秒
> 要してた処理がコンパイルし直すだけで3秒程で終わるようになってたからね。
ま、まじっすかそれ？
351:デフォルトの名無しさん
04/09/12 21:52:58
>>349
やりましたよ。C++だと.3秒で終わりました。テスト用に作ってる
画像処理用ライブラリなんですけどね。巨大なサイズのビットマップを
読み込んでフィルタ処理するって奴です。
現行だとC++の方が10倍程速いですね。しかしですね、ここが大きな問題
なんですが、C#でもbitmapクラスを使わずにそのままメモリに展開して
ポインタ使ってアクセスすると.4秒程度で終わってしまうんですね。ファイル
読み込みにはもちろん.NETのクラスライブラリを使用してます。
個人的にはC#でunsafeなコードを書くのは邪道だとは思うんですが、やろうと
思えば問題ないって話ですね。dll呼び出しするほど手間でもないですし。
インラインアセンブラ使うような感じですね。となると話しはややこしくなってきます。
C#に対するC++の現行での利点は、
・ポインタを駆使出来る。
・win32apiへのアクセスが容易である。
・ネイティブコードを吐ける。
とまぁ既存のライブラリ資産の問題を抜きにすればこんなところです。後ろの２つは
ここ２～３年で利点でもなんでもなくなってしまう訳です。で、１つ目に関してもボトル
ネックとなるような肝い部分ではC#でも問題なく使用出来る、となればほとんど差は
なくなってしまうんですね。やはり考え込んでしまいますね。ただ、プロジェクトの規模
が非常に大きくなってきた時のGCの挙動というのがどの程度パフォーマンスに影響を
与えるのか現時点では読めません。コードでの工夫のしようはありますが、最終的には
VM任せですから。まぁこのあたりもMSが最適化していくような気はしますが。
一つはっきりしときたいのは私はC++を否定するつもりは毛頭ありません。ただ、スレタイ
にもあるとおり「C++は難しすぎ」と感じる人がいるのだとすれば無理して今から覚える
必要は、Win上での開発を念頭に置いているのなら、ないんじゃないかなと思っただけです。
>>350
ほんとです。ソースはそのままコンパイルやり直しただけでその程度のパフォーマンスの
向上が見られました。βがとれた時はそれなりに期待しても良いのかなという気にはなり
ましたね。
352:デフォルトの名無しさん
04/09/12 22:14:50
俺はc#がVBSのような運命を辿るような気がして成らないんだけど・・・
353:デフォルトの名無しさん
04/09/12 23:16:22
> C#に対するC++の現行での利点は、
> ・ポインタを駆使出来る。
> ・win32apiへのアクセスが容易である。
> ・ネイティブコードを吐ける。
C#はどれもできるぞう。
ところで、最初のはあんまりうれしくないなあ。
354:デフォルトの名無しさん
04/09/12 23:23:24
Ｒｕｂｙ最強言語
Ｒｕｂｙ！！！！！
Ｒｕｂｙ ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞ Ｃω
355:デフォルトの名無しさん
04/09/12 23:59:55
>>353
脊髄反射？
ポインタ使える事は >>351 も知ってるようだぞ？
ポインタは確かにアレなんだけど、本流になるには絶対必要だと思うね・・・残念ながら。
Native 呼び出しはモノによっては結構面倒。単にアクセスの容易さだけなら C++ のが当然上だよ。
確かに普通の Win32 API はそれほど面倒なのに突き当たった事はないけど、
COM だとラッパー作るのが大変なの多いね。TLB とか無い場合は。
もちろん JNI みたいなのよりは全然マシだけど。
それから、C# で直接ネイティブコードは吐けないんじゃない？
インストールしたマシン上で変換はできるけど。
356:デフォルトの名無しさん
04/09/13 00:10:56
まぁ何にせよ楽なのはC#だわな。
別に両方使えれば問題ないさね。適材適所。
357:デフォルトの名無しさん
04/09/13 01:36:37
>>355
本流ってよくわからんが、洗練されたC++コードにはポインタは登場しないよ。
ポインタが飛び交うなら、それはC++の顔をしたCだと思う。
358:デフォルトの名無しさん
04/09/13 01:38:54
っつうか355みたいなのは若い（よね？）ならいいけど
年くってたらヤバいと思いなされ。
359:デフォルトの名無しさん
04/09/13 01:47:40
>>358
何か言いたいならはっきり言えよ
360:デフォルトの名無しさん
04/09/13 02:06:50
>>357
それはおまいがC++が書けないからだよ ｗ
361:デフォルトの名無しさん
04/09/13 02:13:48
>>357
すまん。自分はポインタつかいまくり。
スタックに積むオブジェクトとヒープに確保する
オブジェクトは明確に区別している。
それでヒープに確保するためのオブジェクトはどうしても
ポインタになる。スマートポインタはつかっているけど
生のポインタのほうが適切だと思う場所もあるので
それで生のポインタをつかっている。
362:デフォルトの名無しさん
04/09/13 09:04:59
>>361
> 生のポインタのほうが適切だと思う場所もあるので
そういう場所がほとんどなくなるのが、最近のC++のやりかただと思うのよ。
特殊な例を特長なんかにしないほうがいいよ。
363:デフォルトの名無しさん
04/09/13 14:18:22
>>362
どうやって？
364:361
04/09/13 16:54:41
自分の場合、ヒープに確保するタイプのインスタンスは
以下のような管理の使い分けをしている。
(依存、関連、集約、コンポジションぐらいは理解しているよね)
[依存]
ケース1 :
あるメソッドローカルでつかわれるインスタンスで
メソッドをぬけるとインスタンスが不要になる場合。
auto_ptrかscoped_ptrをつかう。
ケース2 :
あるメソッドの引数として渡されるインスタンス。
渡されたインスタンスはそのメソッドの中でしかつかわれない。
この場合は生ポインタ。理由はインスタンスの寿命にメソッドは
関知しないためスマートポインタにする意味がない。
[単項関連]
ケース1 :
格納するクラスがインスタンスの寿命の管理をしないといけない場合。
この場合はauto_ptrかscoped_ptrかshared_ptr。
ケース2 :
格納するクラスがインスタンスの寿命に関知しない場合。
この場合は生ポインタかweak_ptr。
365:361
04/09/13 16:55:34
[集約]
基本的な方針は単項関連と同じ。集約のコンテナにはSTLコンテナ
をつかい、スマートポインタをつかう場合にはshared_ptr
(これじゃないとコンテナに格納できないから)をつかう。
[コンポジション]
問答無用にSTLコンテナ+shared_ptr。
こんな感じ。依存のケース2のような場合はスマートポインタを
つかう意味がないし、別に特別なケースでもなくてよくあるんだけど。
366:デフォルトの名無しさん
04/09/13 17:01:42
洗練されたC++の流儀とは、boostを使う事だったようです。
最近使えるようになったんでしょうね、うれしくてたまらないみたいです。
367:デフォルトの名無しさん
04/09/13 17:08:53
↑Boost分かってない香具師の僻みｷﾀ━━━(ﾟ∀ﾟ)━━━!!
368:デフォルトの名無しさん
04/09/13 17:17:20
標準がしょぼいせいでいろんなもんが乱立する事態になってる
369:デフォルトの名無しさん
04/09/13 17:23:25
なんたらptrとかほにゃららptrとか確かにウザィよね。
ライブラリレベルでやるもんじゃねえよ。
370:デフォルトの名無しさん
04/09/13 17:29:55
>>367
と言う事にしたいのですね。
自分の場合とか言いながら、長々と何を言うかと期待すれば
boost入門ページの最初の方に書いてある事を書いてみただけ。
ヤレヤレ
そんな事はboostの名前を知ってるような人間は誰でも（活用しているかはともかく）承知している事で、
それでもあえて生ポインタを使っているケースは多々あるのに、それを否定するだけの説得力（代案）が
先の文章には無い。
371:デフォルトの名無しさん
04/09/13 17:37:11
とりあえず否定だけしてみて自分の意見は無い香具師ｷﾀ━━━(ﾟ∀ﾟ)━━━!!
372:361
04/09/13 17:44:29
だからスマートポインタ最大限に利用したとしても
生ポインタをつかうケースがあるって例をあげてみた
んだけど。
>そんな事はboostの名前を知ってるような人間は誰でも
>（活用しているかはともかく）承知している事で、
>それでもあえて生ポインタを使っているケースは多々あるのに、
>それを否定するだけの説得力（代案）が先の文章には無い。
361の発言みれって。自分も生ポインタつかいまくりだって。
373:デフォルトの名無しさん
04/09/13 18:01:12
>>372
使いまくったらダメだろｗ
374:デフォルトの名無しさん
04/09/14 00:56:19
>>364
依存のケース２で生ポインタ使ってるところは参照が適切だと思うが、いかがか？
375:デフォルトの名無しさん
04/09/14 00:58:55
話の途中で悪いが、今の「ポインタを使いまくる」の意味は、
自力でnew/deleteしまくるって意味だよな？
376:デフォルトの名無しさん
04/09/14 00:59:47
>>375 ちがうだろう。
377:デフォルトの名無しさん
04/09/14 00:59:58
void******** (********a)(void******** (********)(void********));
なんて普通に使ってますが、何か？
378:361
04/09/14 01:19:12
>>374
ヒープに確保するオブジェクト限定の話なので、生ポインタです。
個人的にヒープに確保したインスタンスの参照をとるのは
抵抗があるかな。
たしかにスタックに積むオブジェクトや構造体ならむしろ参照の
ほうが望ましいと思います。
379:デフォルトの名無しさん
04/09/14 01:49:54
>>378
その抵抗には何か根拠がある？
まるで意味の無い区別だと思うが。
ヒープ上の（動的）オブジェクトを引数に取る関数と
スタック上の（自動）オブジェクトを引数に取る関数とで
オーバーロードでもするつもりか？
380:デフォルトの名無しさん
04/09/14 02:44:40
いつのまにかスレタイに沿った話題になってる
381:デフォルトの名無しさん
04/09/14 02:47:18
>>375
「生の」な。
生のポインタを渡したり、受け取ったり、コピーしたり、
インクリメントしたり、引き算したり、足し算したりすることかなあ。
そういうCみたいなコードはさすがにメンテするのも疲れる。
382:デフォルトの名無しさん
04/09/14 02:48:46
それはおまいが`使えない'香具師だからだYo
383:デフォルトの名無しさん
04/09/14 02:50:29
む、「Cみたいな」は禁句か？
384:デフォルトの名無しさん
04/09/14 04:32:03
>>382
話についていけないお馬鹿さんが
無視して書き込まなくてもいいのでは? ;-)
385:デフォルトの名無しさん
04/09/14 05:22:30
無視して書き込む? ;-)
386:デフォルトの名無しさん
04/09/14 07:03:25
つーかね、
システムコールがiteratorに移行しない以上、
ポインタ（アドレス渡し）は永遠に不滅です。
387:デフォルトの名無しさん
04/09/14 09:05:47
システムコールなんてwrapされる最たるもんだろ
主パスの処理にシステムコールが出てきたりするなら、C以前だなそりゃ
388:361
04/09/14 09:53:58
>>379
設計の段階でヒープに確保するオブジェクトとスタックに積む
オブジェクトは「明確に区別している」ので、同じクラスの
インスタンスがヒープに確保されたりスタック積んだりとまちまちに
なることはないので、オーバーロードする必要はない。
クラスによってヒープに確保かスタックに積むかが決定している。
ヒープに確保するオブジェクトの例をあげればポリフォーリズムが
必要なクラス、スタックに積むクラスは通貨型やベクトル型、
複素数型、クォーターニオンなど。
C++ではオブジェクトをヒープで確保することを強制できないので
とりあえずコピーコンストラクタや代入演算子をprivate属性に
するぐらいはやっているが、最終的にはドキュメントに書いている。
Compositeパターンのように子ノードの削除の責任が親ノードにある
場合、delete演算子かスマートポインタで破棄するんですが、
これがスタックにつまれていると親ノードの都合で削除できない
ので問題になる。こういうのは仕様できっちりきめるしか
回避方法がないのはC++の欠点だと思っている。
...というか、こういうガイドラインって一般的ではないのかな。
とりあえずつかいわけとしてはC#の値型と参照型に近い
感じなんですが。
389:デフォルトの名無しさん
04/09/14 10:15:27
>>388
> 設計の段階でヒープに確保するオブジェクトとスタックに積む
> オブジェクトは「明確に区別している」ので、同じクラスの
クラスを使う側のローカルな操作なら自分の決定を前提とできるだろうけど、
クラスや関連関数を提供する側では、どちらに確保されるかと言う前提は持てないだろう。
> ヒープに確保するオブジェクトの例をあげればポリフォーリズムが
"polymorphism" な。
> C++ではオブジェクトをヒープで確保することを強制できないので
コンストラクタを protected にして、ヒープに確保するstaticな
生成関数を用意すればできるよ。
> これがスタックにつまれていると親ノードの都合で削除できない
> ので問題になる。こういうのは仕様できっちりきめるしか
> 回避方法がないのはC++の欠点だと思っている。
他の言語なら仕様でキッチリ決めないで回避できるの？
> ...というか、こういうガイドラインって一般的ではないのかな。
> とりあえずつかいわけとしてはC#の値型と参照型に近い
C#は詳しくないけど、それを表したいなら、
C#:値型 → C++:メンバを並べたクラス型
C#:参照型 → C++:実装へのスマートポインタひとつをメンバに持つクラス型
こんな感じの対応付けにならないか？
390:361
04/09/14 10:40:07
>"polymorphism" な。
すんまそん。typoです。マジで恥ずかしい。
>コンストラクタを protected にして、ヒープに確保するstaticな
>生成関数を用意すればできるよ。
そういえばそうだった。忘れていました。
C#だと構造体は必ずスタックにつまれる(ボキシングするとヒープに
移るけど)し、クラスはヒープに確保される。まあC#の場合はも
ともとGCがあるからインスタンスの破棄のことは考えなくていいんだけど。
391:361
04/09/14 11:13:37
>C#:参照型 → C++:実装へのスマートポインタひとつをメンバに持つクラス型
これって俗にいうHandle-Bodyだよね。これも設計ポリシーによってはアリですね。
昔の(今は知らん)xerces-cもそうだったような覚えがある。
392:デフォルトの名無しさん
04/09/14 14:17:40
横槍ですが...
>>388
>Compositeパターンのように子ノードの削除の責任が親ノードに
>ある場合
むしろ私の場合は、Compositeパターンによる関連性と寿命管理を
分離する設計が殆どです。Compositeパターンにより関連付けられた
オブジェクト群を利用するオブジェクトと同じ寿命を持った
オブジェクトを用意し、それに保持させるって感じです。
そういった意味では、ライブラリがクライアントの用意するオブジェクト
の寿命を管理する設計よりも、ライブラリはあくまでもそのオブジェクト間の
関連性だけを利用するようにし、その関連性の利用期間を外部に通知できる
ようなインターフェースを用意します。オブジェクトの寿命が本質的に
あいまいな場合のみshared_ptrを使いますが、稀なような気がします。
393:361
04/09/14 14:48:48
>むしろ私の場合は、Compositeパターンによる関連性と寿命管理を
>分離する設計が殆どです。Compositeパターンにより関連付けられた
>オブジェクト群を利用するオブジェクトと同じ寿命を持った
>オブジェクトを用意し、それに保持させるって感じです
イメージとしてはFlyweightのようなオブジェクトプールを
つかうって感じでしょうか?ちがったらすみません。
一応、GoFの本を確認したところ「component を削除するのは誰か」
という段落で「通常は親ノードが子ノードを削除するのが最もよい」
とは書いてありますが、そうでなければいけないとは書いてないですし、
例外のケースもあげられています。
>あいまいな場合のみshared_ptrを使いますが、稀なような気がします。
個人的にもshared_ptrをガーベージコレクションのかわりに
つかうことは殆どないです。thisポインタ問題(shred_ptrの
thisポインタはスマートポインタで管理されていない。
一応回避策はありますが)や循環参照でメモリリークが
発生したりするので意外とつかいにくいです。むしろ
コンテナに入れることができる唯一のスマートポインタ
というつかいかたが多いです。
クライアントが生成したインスタンスをライブラリ側で
寿命を管理する必要があるかどうかは議論の余地がありますね。