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

C++は難しすぎ難易度 ..

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

次ページ