C++は難しすぎ 難易度 ..
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ポインタはスマートポインタで管理されていない。
一応回避策はありますが)や循環参照でメモリリークが
発生したりするので意外とつかいにくいです。むしろ
コンテナに入れることができる唯一のスマートポインタ
というつかいかたが多いです。
クライアントが生成したインスタンスをライブラリ側で
寿命を管理する必要があるかどうかは議論の余地がありますね。
394:デフォルトの名無しさん
04/09/14 14:49:56
とりあえず、俺に責任は無い。
395:デフォルトの名無しさん
04/09/14 23:50:16
C++でポリモーフィズムを使う時って、ヒープに実態確保して、ポインタ使うしかないの？
396:デフォルトの名無しさん
04/09/14 23:56:41
スタックに確保して参照を使うのもアリです。
397:デフォルトの名無しさん
04/09/15 01:24:57
で、361よ。
> 個人的にヒープに確保したインスタンスの参照をとるのは
> 抵抗があるかな。
これは具体的な根拠があるわけじゃない、ってこと？
398:361
04/09/15 12:58:23
ヒープに確保したインスタンスを参照にすると削除するときに&演算子で
ポインタに戻してやらないといけないのと、スマートポインタをつかう
ことも多いので、参照をつかっているところとスマートポインタを
つかっているところで表記がまちまちになって好きじゃない。
一貫性のある表記が好きという個人的な好みの問題。でも本当に
わざわざヒープに確保したインスタンスを参照にする人って
いるの?
ポリモーフィズムは別にスタックに確保したオブジェクトでも
できるけど、スタックに確保しちゃうとインスタンスの寿命の
管理の自由度が下がる。それにスタックに確保しちゃうと
Factoryメソッドのようなメソッド内部で生成したインスタンス
をメソッドの外部に提供するときにコピーコンストラクタが
必要になるのでそういうときに困る。例えばオブジェクトが
ビットマップのような巨大なデータをもつ場合、コピーコン
ストラクトのコストは大きいし、コピーコンストラクタを
書くのが難しいオブジェクトもある。なので必要のない
コピーコンストラクタはprivateにして使用禁止にして
つかわないようにしている。巨大なデータを持つオブジェクトは
前にもいった人がいるようにHandle-Bodyなんかでもいい
(実際にHandle-Bodyをつかっていたり、文字列クラスなんかは
CopyOnWriteをつかっている実装も多い)が、自分はHandle-Bodyを
つかうスタイルではない。これもスタイルの問題。
399:デフォルトの名無しさん
04/09/15 13:42:11
>>398
どこを縦読みすればいいのですか？
400:デフォルトの名無しさん
04/09/15 14:16:46
ポリフォーリズムをポリホと略すスレはここです
401:デフォルトの名無しさん
04/09/15 17:20:36
| ポリフォーリズム の検索結果のうち 日本語のページ 約 7 件中 1 - 3 件目 (0.54 秒)
あるからびっくりだ。
402:デフォルトの名無しさん
04/09/15 19:32:31
全部同一人物？
403:初期不良
04/09/15 21:23:16
>>400
モーフィングとフォーミングを勘違いするなら分かるけど
フォーリングと勘違いするというのは飛んでるなと思う。
3カウント入れちゃうよ
404:361=別名ポリホ
04/09/15 21:35:53
だからマジtypoだって...。まだいりじるのか...。
本気で恥ずかしいんだからいじめんなよ。
405:361=別名ポリホ
04/09/15 21:36:44
>>いりじる
いじるの間違いだ。またtypo。もう嫌...。
406:デフォルトの名無しさん
04/09/15 21:38:17
ていうか、ポリフォーリズムをモリモｰフィズムと間違えるのって恥ずかしすぎ。
407:デフォルトの名無しさん
04/09/15 22:06:55
イリジウムのことね
408:デフォルトの名無しさん
04/09/15 22:12:54
はずかしすぎ。
アンテナでかすぎ。
409:デフォルトの名無しさん
04/09/15 22:24:30
どうtypoったらそうなるのか分からん
410:デフォルトの名無しさん
04/09/15 22:47:57
typoだけに突っ込んでいる人は、
そうやって話をはぐらかそうとしている
厨房なので無視するべし。
411:374
04/09/16 00:56:53
>>394
なんか、どちらかに誤解があるようだな。
>>364の [依存]ケース2 で言っていることは、
たとえば「あるメソッド」foo について、
foo(T*);
というふうに引数の型として生ポインタを使うということじゃないの？
それに対して、
foo(T&);
のほうが適切ではないかと言う突っ込みを>>374で入れている。
これは引数の型の話で、確保したインスタンスを
保持するための型は関係ないと思うんだけど、
漏れが>>364を誤読しているの？
412:374
04/09/16 00:58:09
レスアンカー間違えた。
>>411 は >>398 宛てね。
413:361=別名ポリホ
04/09/16 08:34:22
>>414
何度も同じようなことを書いてすまんけど、
1.クラス設計時にヒープかスタックか決めている
2.ヒープに確保するオブジェクトは常に(スマートポインタを含めた)
ポインタとしてつかいたい
3.参照をつかわないのは参照とポインタが混ざって表記の揺れに
なるからという好みの問題
別に参照をつかっちゃまずいっていう決定的な理由はない。
設計ポリシーとしてメソッドの引数は一貫して参照をつかうの
であればそれはそれでいいんじゃないでしょうか?っていうか俺が
文句いうことじゃないけど。
逆にちょっと質問。setterのようなあるインスタンスを引数の値とって
それをインスタンス変数に保持するメソッドで、かつ削除の権限が
そのsetterを持つインスタンスにある場合、これも参照で渡すの?
そうだとするとどこかの段階で参照からポインタに変換しないと
削除できないような気がするんですが。それともこの場合は
特別にポインタで渡すんでしょうか?
414:361=別名ポリホ
04/09/16 08:38:54
すまんレスの先が411だった。
質問の意図は指摘しているところで参照をつかうと、
setterうんぬんのケースと一貫性を保とうとすると
無理がある場所がでるんじゃないかってことです。
415:374
04/09/17 09:34:20
>>413
最初に突っ込みいれた箇所（>>364の[依存]ケース2）では
「渡されたインスタンスはそのメソッドの中でしかつかわれない」状況となっている。
「インスタンス変数に保持するメソッド」なら状況が違うんじゃないの？
これらの異なる二つの状況の間で一貫性なんてあるはずがない。
生ポインタ使う場所の例として挙げられた箇所に
参照のほうが適切だと突っ込みいれたのに、
スマートポインタ使う場所を挙げて反論されても困る。
416:デフォルトの名無しさん
04/09/17 12:25:53
> 削除の権限が そのsetterを持つインスタンスにある場合
どういう状況だかよく分からんが、std::auto_ptrみたいなものを
作ろうとしてるなら、素直にコピーを作成したオブジェクトが責任を持って
オブジェクトを破壊すべきだ。
参照渡しされたものを受け取った側で破壊するのは、分かりづらい。
とりあえずスマートポインタ勉強してから出直せ。
417:デフォルトの名無しさん
04/09/17 12:56:51
漏れはリアルタイム画像処理をよくやるんだけど、
画像のピクセルデータにアクセスするときはなんとなく生ポインタ使っちゃうな。
あったり無かったりするものを引数にしたいとき、T* 型の引数にして 0 渡すと
「無し」みたいなこともたまにやるし。C# や Java のライブラリでも null 渡せる
メソッドは結構あるから、実装面ではポインタ型の使いどころはそこそこあるん
じゃねーの？
418:デフォルトの名無しさん
04/09/17 15:26:19
まあ、あれだ
参照渡しでもポインタ渡しでもコピー渡しでもなんでもいいけど、
参照剥しをするのは控えた方がいいな。
あとでdeleteするオブジェクトはポインタで保持しとけ。
419:ポリホ
04/09/17 17:46:25
>参照渡しされたものを受け取った側で破壊するのは、分かりづらい。
からポインタつかえっていってんだろ。
>「渡されたインスタンスはそのメソッドの中でしかつかわれない」状況となっている。
>「インスタンス変数に保持するメソッド」なら状況が違うんじゃないの？
>これらの異なる二つの状況の間で一貫性なんてあるはずがない。
状況が違うから一貫性がなくてもよいという判断なら別にいい。
自分はポインタにすると2つの状況で整合がとれるから好きなだけだ。
メソッドの引数はポインタうんぬんという話はヒープに確保した
インスタンスに限定の話だ。しかもコーディングスタイルの問題
だから人のことはとやかくいうつもりはない。
ヒープに確保したインスタンスの参照剥がしが好きじゃないといったら
根拠を求められるし、好きじゃない理由をいったらなぜか参照剥がしは
わかりずらいっていう謎のつっこみが入るし、わけがわかりません。
いったい自分にどうしてもらいたいんだろう。
420:デフォルトの名無しさん
04/09/17 20:42:41
>>411
foo を書いていて引数にnull 値のようなものを許したいとき、
foo(T*) にするか、foo(T&) にして T::Null を提供するかっていうと、
漏れはメンドクサイから大抵前者だけど。
421:デフォルトの名無しさん
04/09/17 21:28:32
＞ポリホ
もうちっと日本語勉強しろよ
422:デフォルトの名無しさん
04/09/18 11:32:18
>>419
>いったい自分にどうしてもらいたいんだろう。
いじられ役に徹してくだちい。
423:デフォルトの名無しさん
04/09/23 02:34:10
とりあえずＣ＋＋ではヒープではなく「フリーストア」って呼ぶんじゃなかったっけ？
まぁ、データメンバを「メンバ変数って呼んじゃダメなの？」くらいの勢いだけど。
424:デフォルトの名無しさん
04/09/23 22:05:22
int* a,b; と int* a; int* b; って違うんだな・・・
425:デフォルトの名無しさん
04/09/24 00:10:23
>>424
いや、それは違いすぎだから…。
両方ポインタにするなら
int* a, *b;
じゃないとね。
だけどこういう書き方になるから型の後にアスタを付けるスタイルは好きではない。
int *a, *b;
のほうが美しいじゃん。好みの問題かもしれないけど。
426:デフォルトの名無しさん
04/09/24 00:14:44
>>424
所詮C++はC言語のころの呪縛から逃れられてないのよ。
>>425
int* a;
int* b;
と2行に分けることを推奨。
427:デフォルトの名無しさん
04/09/24 04:48:24
>>426
＞所詮C++はC言語のころの呪縛から逃れられてないのよ。
だがそれが(・∀・)ｲｲ!!
というか、仕様変更するとコンパイルエラーが発生するレガシーコードが
混在してしまう可能性があるから仕方ないっしょ。
・・・レガシーという単語を使いたかっただけだ。気にしないでくれ。orz
428:デフォルトの名無しさん
04/09/24 08:39:01
int* をtypedefして違う名前を与える
さらにはintを変えられるようにtemplate化
429:デフォルトの名無しさん
04/09/24 09:23:41
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 '=' : 互換性のない型が含まれています。
これはいったい、どうしたことか。
430:デフォルトの名無しさん
04/09/24 10:25:14
>>429
b=a;
が
b.x=a.x;
b.y=a.y;
と同義であるとはいえない。
直感的にはそうであるが。
同義であるなら同義であるとoperator=なりで
コンパイラに教えなきゃわからん。
431:デフォルトの名無しさん
04/09/24 10:43:24
>>429
struct A { int x,y;} a;
struct B { int x,y;} b;
名前を省略しただけの扱いなんだろ。
別々の構造体で、たまたまメンバの並びが同じになっただけで代入ができたら困る。
432:デフォルトの名無しさん
04/09/24 11:45:46
C++スレでC虫臭い話を続けるな
433:デフォルトの名無しさん
04/09/24 17:58:58
>>424-425
こんな解決法もある。
typedef int *PINT;
PINT a, b;
434:デフォルトの名無しさん
04/09/24 18:03:42
それ終わってる。
とっくに。
435:デフォルトの名無しさん
04/10/07 00:13:22
>>429
基本的に別の型に代入はできない。当たり前だけど。Java だって C# だってそうでしょ。
typedef は単なる別名で、新しい型を作る訳では無いって、仕様で決まってますから。
436:デフォルトの名無しさん
04/10/26 17:24:17
メンバの並びが同じな別々の構造体を作る必要性はあるのか？
437:デフォルトの名無しさん
04/10/26 18:09:29
あたりまえ
438:デフォルトの名無しさん
04/10/26 19:18:18
>>436
「今はたまたま同じメンバだけど、将来的には拡張されるかも知れない」
ってことはありそう泣きガス
439:デフォルトの名無しさん
04/10/26 19:56:30
>>438
その場合、直接代入できる必然性はないよね。
440:デフォルトの名無しさん
04/10/27 11:48:39
>>439
ふむ。そりゃそうだ。
441:デフォルトの名無しさん
04/10/29 01:42:08
ふと思ったんだけど、構造体やクラスの（データ）メンバを
while文のようなループ文でくるくる回しながら順番に取れたら便利かも？
名前とか個数とかデータ型を意識せずにクルクル…。
そういうのってうまいこと出来ないかな？
442:デフォルトの名無しさん
04/10/29 01:46:03
>>441
意味が判らない
443:デフォルトの名無しさん
04/10/29 01:53:58
>>441
型の違うデータメンバのいったい何が取得したいのか？ ってことだね。
たとえば各メンバの文字列表現が取得したいのなら
そのような関数を用意すればすむ。
444:デフォルトの名無しさん
04/10/30 03:34:49
うっ、わかりにくかったか…。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のような型」が無い以上、
そういうやり方すら出来ないではないでつか…。
関数にしても結局はすべて名前で指定しなければならないし…。
445:444
04/10/30 03:37:25
>>444
しまった、ループの脱出条件を書いてないから無限ループケテ〜イだ…。orz
まぁ、その辺は突っ込み入れないでちょ。
446:r
04/10/30 08:20:36
>>444
offsetof
使った事無いけど。多分。
447:r
04/10/30 08:25:36
>>444
つーか
TEST_STRUCT srcData[] = ...;
for( int i = 0; i < ...; i++ )
dstArray.push_back( srcData[i] );
じゃなくて？
448:デフォルトの名無しさん
04/10/30 09:57:07
>>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]));
}
これでもなんとかなるかな。
449:デフォルトの名無しさん
04/10/30 19:41:55
>>446
「offsetof」なんて初めて聞いた！
…と思ったらひょっとしてC++の言語仕様にはないものですよね？
ぐぐってみたらどうやら「.NET Framework」なのかな？
>>448
ふむふむ、ポインタを駆使すれば結構なことが出来そうですね。
しかしなんていうか難しいというかちょっぴり複雑に…。(^^;
基本的に私もメンバを一つ一つ指定することになんの抵抗も無かったんですが、
最近職場でBorlandC++Builderに慣れた同僚が、
「構造体のメンバって一つ一つ名前でアクセスしないといけないんですかねぇ？
面倒くさいですねぇ」
…などと話していたので、興味を持った次第でつ。
これができるとどういうメリットがあるかという話ですが、
（C++Builderの話限定になってしまうのですが）
ＤＢの不特定なテーブルから、フィールド名を指定せずに
不特定の構造体のメンバにデータを突っ込めるため、
プログラムの汎用性が高まるということらしいです。
450:デフォルトの名無しさん
04/10/30 22:20:56
offsetofを知らないだけならともかく(それも問題だが)、C#って・・・
絞り込みも出来ない、googleのトップしか見ないで、２番目は無視する人かね
451:448
04/10/31 01:07:37
>>449
offsetofなんて、Cでもマクロで簡単に書ける代物なんだけど。
標準ヘッダを探してみることもできないのかな?
452:デフォルトの名無しさん
04/10/31 02:37:42
うわ〜ん、そんなにいじめるなぁ〜。ヽ(`Д´)ﾉ
簡単にできるというのがいいのだよ。
めんどっちいのはイヤ。
453:デフォルトの名無しさん
04/10/31 02:45:31
しかし、とりあえずoffsetofというマクロが
標準的に用意されてることを教えていただき、
ありがとうございますた。m(_ _ )m
454:r
04/10/31 17:05:43
クラスのメンバを、別々に、同じベクタに入れる意味がわからん
455:デフォルトの名無しさん
04/11/25 02:44:24
最近書き込みがないね。
456:デフォルトの名無しさん
04/11/25 04:01:13
重複スレだからな。
457:デフォルトの名無しさん
04/11/26 03:07:57
C言語とJavaとRuby使って，そこそこ書きました．
次はC++にチャレンジするかと，プログラミング言語C++を買ってきました．
難しいです．何書いてるのかわかりません．
俺の頭が悪いのが原因でしょうが，C++の難しさに挫けそうです
458:デフォルトの名無しさん
04/11/26 08:15:19
ヽ（冫、）ノｽﾞｺｰｯ
何処が難しいか言ってみて。
十分習得出来る知識あるように見えるけど…
459:デフォルトの名無しさん
04/11/26 10:26:54
>>458
>十分習得出来る知識あるように見えるけど…
んな事が >>457 読んで解るのか！ESPer でつか？
460:デフォルトの名無しさん
04/11/26 10:52:23
>>459
Yep
461:デフォルトの名無しさん
04/11/26 14:05:17
>>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);
これでやっと中級に入門です。先は長いです。くじけそうです。
462:デフォルトの名無しさん
04/11/26 14:07:40
C++のことがある程度わかってくると、++、--は前置にするもんです。
463:デフォルトの名無しさん
04/11/26 16:44:04
運置
464:デフォルトの名無しさん
04/11/26 21:17:08
>>462 どうして？
465:デフォルトの名無しさん
04/11/26 21:20:14
>>464
前置の方がコピーのコストがかからないから
466:デフォルトの名無しさん
04/11/26 21:27:04
>>465 どうして？
467:デフォルトの名無しさん
04/11/26 21:32:47
>>466
More Effective C++の項目6を嫁
468:デフォルトの名無しさん
04/11/26 21:36:34
>>467
読んでみた。ありがとう。
インライン展開されるような場合は別に気にしなくていいね。
469:デフォルトの名無しさん
04/11/26 22:23:28
>>461
それ見てC++の方がタイプ量多い割にたいしたこと出来ない。
Cの方が1000万倍マシと悟った。
470:デフォルトの名無しさん
04/11/26 22:24:18
>>469
それはちょっと勘違いだ。
C++ は C より便利だよ。
471:デフォルトの名無しさん
04/11/26 22:24:53
>>467
んじゃ、これから
Effective ++C
と書くことにしちくりマンボ
472:デフォルトの名無しさん
04/11/26 22:28:36
>>471
山田君、座布団一枚持ってっちゃって
473:デフォルトの名無しさん
04/11/26 22:32:14
>>468
テンプレートでの汎用プログラミングのために常に
前置にしておくと後々組み込み型をクラスにしたくなった
とき修正量が減る。
474:デフォルトの名無しさん
04/11/26 23:07:05
>>473
組み込み型かクラスかは別に関係ないような？
475:デフォルトの名無しさん
04/11/26 23:35:39
>>474
クラスだとテンポラリオブジェクトが生成されるよ。
インライン展開されてもね。
476:457
04/11/27 02:51:11
思ったよりレスが…ありがとうございます．
>>458
最初は俺も楽勝だろーとか思っていたのですが，何故か頭が受け付けません．
>>461
今の俺の書き方だと，モロ最初の書き方ですね…
477:デフォルトの名無しさん
04/11/27 03:07:44
>>461
C++を究めた人はアセンブリに戻る。
478:デフォルトの名無しさん
04/11/27 03:10:04
>>477
そういう内容のメガデモ作品があったな
479:デフォルトの名無しさん
04/11/27 06:47:22
>>461の二番目みたいに、全く抽象化されてもいないのに
無理やりイテレータ使う意義って、全くないように思えるんだが
480:デフォルトの名無しさん
04/11/27 09:02:51
インポラリ
481:デフォルトの名無しさん
04/11/27 09:22:04
>>457
> C++の難しさに挫けそうです
「プログラミング言語C++」の難しさに挫けそうなだけだろ。
482:デフォルトの名無しさん
04/11/27 09:34:42
>>479
そんなことはない。
少なくともコンテナを差し替えられる。
483:デフォルトの名無しさん
04/11/27 23:14:25
そんなこといったら、最初の書き方ならば
vectorを配列にさしかえれるという利点があるなｗ
484:デフォルトの名無しさん
04/11/27 23:16:08
>>483
vectorを配列に差し替えても、あまり嬉しくはないだろう。
485:デフォルトの名無しさん
04/11/27 23:37:44
速くなるやん
486:デフォルトの名無しさん
04/11/28 04:04:31
>>485
そういう用途なら、boost::arrayがあるから利点とはならない。
487:デフォルトの名無しさん
04/11/28 04:36:03
boost::rangeでcontainerとbuilt-in arrayが汎用に扱えるようにもなったしね
488:デフォルトの名無しさん
04/11/28 11:09:50
後からコンテナを差し替えやすいってのが利点。
489:デフォルトの名無しさん
04/11/28 17:27:41
コンテナの差し替えなんかするのか？ホントか？
テンプレート引数で型を受け取るときに、
どのコンテナでもOKなのは、確かに意義があるといえるが
前述の例はそういうわけでは全くないし、
正直、三つある例のどの書き方でも、優劣はないと思うが
490:デフォルトの名無しさん
04/11/28 20:57:16
前述の例だけみればたしかにどれでもいいレベルの話だけど、
意識の持ち方のことを言ってるんじゃないの？
できるだけSTLコンテナやSTLアルゴリズムを使おうという。
491:デフォルトの名無しさん
04/11/28 21:39:47
しっかし、組み込み型(intとかdoubleとか)のコンテナならSTLのアルゴリズムは
教科書通りに使えるんだが、クラスになると途端に使い物にならなくなるのは
どういうこと?
STLの範囲で済ます場合、メンバ関数ならアダプタでなんとかなるが、メンバ変数は
叙述関数・関数オブジェクトを用意しなければならない。
正直、boost::bindやboost::lambdaが無かったらやってられないよ。
でもこれも一長一短で、boost::lambdaは動かないコンパイラもあるし(bcc32)、
boost::bindは遅いし。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5386日前に更新/241 KB
担当:undef