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

1 名前：前々スレ985 mailto:sage [03/12/18 06:52] 理解できないわけないだろ！ デザパタも知らずにC++使いの質を下げるC厨には げんあり 前スレ達 難易度:1 pc2.2ch.net/tech/kako/1058/10586/1058675178.html 難易度:2 1pc2.2ch.net/test/read.cgi/tech/1063323615/ 357 名前：デフォルトの名無しさん mailto:sage [04/09/13 01:36:37] >>355 本流ってよくわからんが、洗練されたC++コードにはポインタは登場しないよ。 ポインタが飛び交うなら、それはC++の顔をしたCだと思う。 358 名前：デフォルトの名無しさん mailto:sage [04/09/13 01:38:54] っつうか355みたいなのは若い（よね？）ならいいけど 年くってたらヤバいと思いなされ。 359 名前：デフォルトの名無しさん mailto:sage [04/09/13 01:47:40] >>358 何か言いたいならはっきり言えよ 360 名前：デフォルトの名無しさん [04/09/13 02:06:50] >>357 それはおまいがC++が書けないからだよ　ｗ 361 名前：デフォルトの名無しさん mailto:sage [04/09/13 02:13:48] >>357 すまん。自分はポインタつかいまくり。 スタックに積むオブジェクトとヒープに確保する オブジェクトは明確に区別している。 それでヒープに確保するためのオブジェクトはどうしても ポインタになる。スマートポインタはつかっているけど 生のポインタのほうが適切だと思う場所もあるので それで生のポインタをつかっている。 362 名前：デフォルトの名無しさん mailto:sage [04/09/13 09:04:59] >>361 > 生のポインタのほうが適切だと思う場所もあるので そういう場所がほとんどなくなるのが、最近のC++のやりかただと思うのよ。 特殊な例を特長なんかにしないほうがいいよ。 363 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [04/09/13 17:01:42] 洗練されたC++の流儀とは、boostを使う事だったようです。 最近使えるようになったんでしょうね、うれしくてたまらないみたいです。 367 名前：デフォルトの名無しさん mailto:sage [04/09/13 17:08:53] ↑Boost分かってない香具師の僻みｷﾀ━━━━━(ﾟ∀ﾟ)━━━━━!! 368 名前：デフォルトの名無しさん mailto:sage [04/09/13 17:17:20] 標準がしょぼいせいでいろんなもんが乱立する事態になってる 369 名前：デフォルトの名無しさん mailto:sage [04/09/13 17:23:25] なんたらptrとかほにゃららptrとか確かにウザィよね。 ライブラリレベルでやるもんじゃねえよ。 370 名前：デフォルトの名無しさん mailto:sage [04/09/13 17:29:55] >>367 と言う事にしたいのですね。 自分の場合とか言いながら、長々と何を言うかと期待すれば boost入門ページの最初の方に書いてある事を書いてみただけ。 ヤレヤレ そんな事はboostの名前を知ってるような人間は誰でも（活用しているかはともかく）承知している事で、 それでもあえて生ポインタを使っているケースは多々あるのに、それを否定するだけの説得力（代案）が 先の文章には無い。 371 名前：デフォルトの名無しさん mailto:sage [04/09/13 17:37:11] とりあえず否定だけしてみて自分の意見は無い香具師ｷﾀ━━━━━(ﾟ∀ﾟ)━━━━━!! 372 名前：361 [04/09/13 17:44:29] だからスマートポインタ最大限に利用したとしても 生ポインタをつかうケースがあるって例をあげてみた んだけど。 >そんな事はboostの名前を知ってるような人間は誰でも >（活用しているかはともかく）承知している事で、 >それでもあえて生ポインタを使っているケースは多々あるのに、 >それを否定するだけの説得力（代案）が先の文章には無い。 361の発言みれって。自分も生ポインタつかいまくりだって。 373 名前：デフォルトの名無しさん mailto:sage [04/09/13 18:01:12] >>372 使いまくったらダメだろｗ 374 名前：デフォルトの名無しさん mailto:sage [04/09/14 00:56:19] >>364 依存のケース２で生ポインタ使ってるところは参照が適切だと思うが、いかがか？ 375 名前：デフォルトの名無しさん mailto:sage [04/09/14 00:58:55] 話の途中で悪いが、今の「ポインタを使いまくる」の意味は、 自力でnew/deleteしまくるって意味だよな？ 376 名前：デフォルトの名無しさん mailto:sage [04/09/14 00:59:47] >>375 ちがうだろう。 377 名前：デフォルトの名無しさん [04/09/14 00:59:58] void******** (********a)(void******** (********)(void********)); なんて普通に使ってますが、何か？ 378 名前：361 mailto:sage [04/09/14 01:19:12] >>374 ヒープに確保するオブジェクト限定の話なので、生ポインタです。 個人的にヒープに確保したインスタンスの参照をとるのは 抵抗があるかな。 たしかにスタックに積むオブジェクトや構造体ならむしろ参照の ほうが望ましいと思います。 379 名前：デフォルトの名無しさん mailto:sage [04/09/14 01:49:54] >>378 その抵抗には何か根拠がある？ まるで意味の無い区別だと思うが。 ヒープ上の（動的）オブジェクトを引数に取る関数と スタック上の（自動）オブジェクトを引数に取る関数とで オーバーロードでもするつもりか？ 380 名前：デフォルトの名無しさん mailto:sage [04/09/14 02:44:40] いつのまにかスレタイに沿った話題になってる 381 名前：デフォルトの名無しさん mailto:sage [04/09/14 02:47:18] >>375 「生の」な。 生のポインタを渡したり、受け取ったり、コピーしたり、 インクリメントしたり、引き算したり、足し算したりすることかなあ。 そういうCみたいなコードはさすがにメンテするのも疲れる。 382 名前：デフォルトの名無しさん [04/09/14 02:48:46] それはおまいが`使えない'香具師だからだYo 383 名前：デフォルトの名無しさん mailto:sage [04/09/14 02:50:29] む、「Cみたいな」は禁句か？ 384 名前：デフォルトの名無しさん [04/09/14 04:32:03] >>382 話についていけないお馬鹿さんが 無視して書き込まなくてもいいのでは? ;-) 385 名前：デフォルトの名無しさん [04/09/14 05:22:30] 無視して書き込む? ;-) 386 名前：デフォルトの名無しさん mailto:sage [04/09/14 07:03:25] つーかね、 システムコールがiteratorに移行しない以上、 ポインタ（アドレス渡し）は永遠に不滅です。 387 名前：デフォルトの名無しさん mailto:sage [04/09/14 09:05:47] システムコールなんてwrapされる最たるもんだろ 主パスの処理にシステムコールが出てきたりするなら、C以前だなそりゃ 388 名前：361 [04/09/14 09:53:58] >>379 設計の段階でヒープに確保するオブジェクトとスタックに積む オブジェクトは「明確に区別している」ので、同じクラスの インスタンスがヒープに確保されたりスタック積んだりとまちまちに なることはないので、オーバーロードする必要はない。 クラスによってヒープに確保かスタックに積むかが決定している。 ヒープに確保するオブジェクトの例をあげればポリフォーリズムが 必要なクラス、スタックに積むクラスは通貨型やベクトル型、 複素数型、クォーターニオンなど。 C++ではオブジェクトをヒープで確保することを強制できないので とりあえずコピーコンストラクタや代入演算子をprivate属性に するぐらいはやっているが、最終的にはドキュメントに書いている。 Compositeパターンのように子ノードの削除の責任が親ノードにある 場合、delete演算子かスマートポインタで破棄するんですが、 これがスタックにつまれていると親ノードの都合で削除できない ので問題になる。こういうのは仕様できっちりきめるしか 回避方法がないのはC++の欠点だと思っている。 ...というか、こういうガイドラインって一般的ではないのかな。 とりあえずつかいわけとしてはC#の値型と参照型に近い 感じなんですが。 389 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [04/09/14 14:49:56] とりあえず、俺に責任は無い。 395 名前：デフォルトの名無しさん mailto:sage [04/09/14 23:50:16] C++でポリモーフィズムを使う時って、ヒープに実態確保して、ポインタ使うしかないの？ 396 名前：デフォルトの名無しさん mailto:sage [04/09/14 23:56:41] スタックに確保して参照を使うのもアリです。 397 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [04/09/15 13:42:11] >>398 どこを縦読みすればいいのですか？ 400 名前：デフォルトの名無しさん [04/09/15 14:16:46] ポリフォーリズムをポリホと略すスレはここです 401 名前：デフォルトの名無しさん mailto:sage [04/09/15 17:20:36] |　　ポリフォーリズム の検索結果のうち 日本語のページ 約 7 件中 1 - 3 件目 (0.54 秒) あるからびっくりだ。 402 名前：デフォルトの名無しさん mailto:sage [04/09/15 19:32:31] 全部同一人物？ 403 名前：初期不良 mailto:sage [04/09/15 21:23:16] >>400 モーフィングとフォーミングを勘違いするなら分かるけど フォーリングと勘違いするというのは飛んでるなと思う。 3カウント入れちゃうよ 404 名前：361=別名ポリホ mailto:sage [04/09/15 21:35:53] だからマジtypoだって...。まだいりじるのか...。 本気で恥ずかしいんだからいじめんなよ。 405 名前：361=別名ポリホ mailto:sage [04/09/15 21:36:44] >>いりじる いじるの間違いだ。またtypo。もう嫌...。 406 名前：デフォルトの名無しさん mailto:sage [04/09/15 21:38:17] ていうか、ポリフォーリズムをモリモｰフィズムと間違えるのって恥ずかしすぎ。 407 名前：デフォルトの名無しさん [04/09/15 22:06:55] イリジウムのことね 408 名前：デフォルトの名無しさん mailto:sage [04/09/15 22:12:54] はずかしすぎ。 アンテナでかすぎ。 409 名前：デフォルトの名無しさん mailto:sage [04/09/15 22:24:30] どうtypoったらそうなるのか分からん 410 名前：デフォルトの名無しさん mailto:sage [04/09/15 22:47:57] typoだけに突っ込んでいる人は、 そうやって話をはぐらかそうとしている 厨房なので無視するべし。 411 名前：374 mailto:sage [04/09/16 00:56:53] >>394 なんか、どちらかに誤解があるようだな。 >>364の [依存]ケース2 で言っていることは、 たとえば「あるメソッド」foo について、 　foo(T*); というふうに引数の型として生ポインタを使うということじゃないの？ それに対して、 　foo(T&); のほうが適切ではないかと言う突っ込みを>>374で入れている。 これは引数の型の話で、確保したインスタンスを 保持するための型は関係ないと思うんだけど、 漏れが>>364を誤読しているの？ 412 名前：374 mailto:sage [04/09/16 00:58:09] レスアンカー間違えた。 >>411 は >>398 宛てね。 413 名前：361=別名ポリホ mailto:sage [04/09/16 08:34:22] >>414 何度も同じようなことを書いてすまんけど、 1.クラス設計時にヒープかスタックか決めている 2.ヒープに確保するオブジェクトは常に(スマートポインタを含めた) ポインタとしてつかいたい 3.参照をつかわないのは参照とポインタが混ざって表記の揺れに なるからという好みの問題 別に参照をつかっちゃまずいっていう決定的な理由はない。 設計ポリシーとしてメソッドの引数は一貫して参照をつかうの であればそれはそれでいいんじゃないでしょうか?っていうか俺が 文句いうことじゃないけど。 逆にちょっと質問。setterのようなあるインスタンスを引数の値とって それをインスタンス変数に保持するメソッドで、かつ削除の権限が そのsetterを持つインスタンスにある場合、これも参照で渡すの? そうだとするとどこかの段階で参照からポインタに変換しないと 削除できないような気がするんですが。それともこの場合は 特別にポインタで渡すんでしょうか? 414 名前：361=別名ポリホ mailto:sage [04/09/16 08:38:54] すまんレスの先が411だった。 質問の意図は指摘しているところで参照をつかうと、 setterうんぬんのケースと一貫性を保とうとすると 無理がある場所がでるんじゃないかってことです。 415 名前：374 mailto:sage [04/09/17 09:34:20] >>413 最初に突っ込みいれた箇所（>>364の[依存]ケース2）では 「渡されたインスタンスはそのメソッドの中でしかつかわれない」状況となっている。 「インスタンス変数に保持するメソッド」なら状況が違うんじゃないの？ これらの異なる二つの状況の間で一貫性なんてあるはずがない。 生ポインタ使う場所の例として挙げられた箇所に 参照のほうが適切だと突っ込みいれたのに、 スマートポインタ使う場所を挙げて反論されても困る。 416 名前：デフォルトの名無しさん mailto:sage [04/09/17 12:25:53] > 削除の権限が そのsetterを持つインスタンスにある場合 どういう状況だかよく分からんが、std::auto_ptrみたいなものを 作ろうとしてるなら、素直にコピーを作成したオブジェクトが責任を持って オブジェクトを破壊すべきだ。 参照渡しされたものを受け取った側で破壊するのは、分かりづらい。 とりあえずスマートポインタ勉強してから出直せ。 417 名前：デフォルトの名無しさん mailto:sage [04/09/17 12:56:51] 漏れはリアルタイム画像処理をよくやるんだけど、 画像のピクセルデータにアクセスするときはなんとなく生ポインタ使っちゃうな。 あったり無かったりするものを引数にしたいとき、T* 型の引数にして 0 渡すと 「無し」みたいなこともたまにやるし。C# や Java のライブラリでも null 渡せる メソッドは結構あるから、実装面ではポインタ型の使いどころはそこそこあるん じゃねーの？ 418 名前：デフォルトの名無しさん mailto:sage [04/09/17 15:26:19] まあ、あれだ 参照渡しでもポインタ渡しでもコピー渡しでもなんでもいいけど、 参照剥しをするのは控えた方がいいな。 あとでdeleteするオブジェクトはポインタで保持しとけ。 419 名前：ポリホ [04/09/17 17:46:25] >参照渡しされたものを受け取った側で破壊するのは、分かりづらい。 からポインタつかえっていってんだろ。 >「渡されたインスタンスはそのメソッドの中でしかつかわれない」状況となっている。 >「インスタンス変数に保持するメソッド」なら状況が違うんじゃないの？ >これらの異なる二つの状況の間で一貫性なんてあるはずがない。 状況が違うから一貫性がなくてもよいという判断なら別にいい。 自分はポインタにすると2つの状況で整合がとれるから好きなだけだ。 メソッドの引数はポインタうんぬんという話はヒープに確保した インスタンスに限定の話だ。しかもコーディングスタイルの問題 だから人のことはとやかくいうつもりはない。 ヒープに確保したインスタンスの参照剥がしが好きじゃないといったら 根拠を求められるし、好きじゃない理由をいったらなぜか参照剥がしは わかりずらいっていう謎のつっこみが入るし、わけがわかりません。 いったい自分にどうしてもらいたいんだろう。 420 名前：デフォルトの名無しさん mailto:sage [04/09/17 20:42:41] >>411 foo を書いていて引数にnull 値のようなものを許したいとき、 foo(T*) にするか、foo(T&) にして T::Null を提供するかっていうと、 漏れはメンドクサイから大抵前者だけど。 421 名前：デフォルトの名無しさん mailto:sage [04/09/17 21:28:32] ＞ポリホ もうちっと日本語勉強しろよ 422 名前：デフォルトの名無しさん mailto:sage [04/09/18 11:32:18] >>419 >いったい自分にどうしてもらいたいんだろう。 いじられ役に徹してくだちい。 423 名前：デフォルトの名無しさん mailto:sage [04/09/23 02:34:10] とりあえずＣ＋＋ではヒープではなく「フリーストア」って呼ぶんじゃなかったっけ？ まぁ、データメンバを「メンバ変数って呼んじゃダメなの？」くらいの勢いだけど。 424 名前：デフォルトの名無しさん mailto:sage [04/09/23 22:05:22] int* a,b; と int* a; int* b; って違うんだな・・・ 425 名前：デフォルトの名無しさん mailto:sage [04/09/24 00:10:23] >>424 いや、それは違いすぎだから…。 両方ポインタにするなら int* a, *b; じゃないとね。 だけどこういう書き方になるから型の後にアスタを付けるスタイルは好きではない。 int *a, *b; のほうが美しいじゃん。好みの問題かもしれないけど。 426 名前：デフォルトの名無しさん mailto:sage [04/09/24 00:14:44] >>424 所詮C++はC言語のころの呪縛から逃れられてないのよ。 >>425 int* a; int* b; と2行に分けることを推奨。 427 名前：デフォルトの名無しさん mailto:sage [04/09/24 04:48:24] >>426 ＞所詮C++はC言語のころの呪縛から逃れられてないのよ。 だがそれが(・∀・)ｲｲ!! というか、仕様変更するとコンパイルエラーが発生するレガシーコードが 混在してしまう可能性があるから仕方ないっしょ。 ・・・レガシーという単語を使いたかっただけだ。気にしないでくれ。orz 428 名前：デフォルトの名無しさん [04/09/24 08:39:01] int* をtypedefして違う名前を与える さらにはintを変えられるようにtemplate化 429 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [04/09/24 10:25:14] >>429 b=a; が b.x=a.x; b.y=a.y; と同義であるとはいえない。 直感的にはそうであるが。 同義であるなら同義であるとoperator=なりで コンパイラに教えなきゃわからん。 431 名前：デフォルトの名無しさん mailto:sage [04/09/24 10:43:24] >>429 struct A { int x,y;} a; struct B { int x,y;} b; 名前を省略しただけの扱いなんだろ。 別々の構造体で、たまたまメンバの並びが同じになっただけで代入ができたら困る。 432 名前：デフォルトの名無しさん mailto:sage [04/09/24 11:45:46] C++スレでC虫臭い話を続けるな 433 名前：デフォルトの名無しさん mailto:sage [04/09/24 17:58:58] >>424-425 こんな解決法もある。 typedef int *PINT; PINT a, b; 434 名前：デフォルトの名無しさん mailto:sage [04/09/24 18:03:42] それ終わってる。 とっくに。 435 名前：デフォルトの名無しさん mailto:sage [04/10/07 00:13:22] >>429 基本的に別の型に代入はできない。当たり前だけど。Java だって C# だってそうでしょ。 typedef は単なる別名で、新しい型を作る訳では無いって、仕様で決まってますから。 436 名前：デフォルトの名無しさん mailto:sage [04/10/26 17:24:17] メンバの並びが同じな別々の構造体を作る必要性はあるのか？ 437 名前：デフォルトの名無しさん mailto:sage [04/10/26 18:09:29] あたりまえ 438 名前：デフォルトの名無しさん mailto:sage [04/10/26 19:18:18] >>436 「今はたまたま同じメンバだけど、将来的には拡張されるかも知れない」 ってことはありそう泣きガス 439 名前：デフォルトの名無しさん mailto:sage [04/10/26 19:56:30] >>438 その場合、直接代入できる必然性はないよね。 440 名前：デフォルトの名無しさん mailto:sage [04/10/27 11:48:39] >>439 ふむ。そりゃそうだ。 441 名前：デフォルトの名無しさん mailto:sage [04/10/29 01:42:08] ふと思ったんだけど、構造体やクラスの（データ）メンバを while文のようなループ文でくるくる回しながら順番に取れたら便利かも？ 名前とか個数とかデータ型を意識せずにクルクル…。 そういうのってうまいこと出来ないかな？ 442 名前：デフォルトの名無しさん mailto:sage [04/10/29 01:46:03] >>441 意味が判らない 443 名前：デフォルトの名無しさん mailto:sage [04/10/29 01:53:58] >>441 型の違うデータメンバのいったい何が取得したいのか？ ってことだね。 たとえば各メンバの文字列表現が取得したいのなら そのような関数を用意すればすむ。 444 名前：デフォルトの名無しさん mailto:sage [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 mailto:sage [04/10/30 03:37:25] >>444 しまった、ループの脱出条件を書いてないから無限ループケテ〜イだ…。orz まぁ、その辺は突っ込み入れないでちょ。 446 名前：r mailto:sage [04/10/30 08:20:36] >>444 offsetof 使った事無いけど。多分。 447 名前：r mailto:sage [04/10/30 08:25:36] >>444 つーか TEST_STRUCT srcData[] = ...; for( int i = 0; i < ...; i++ )     dstArray.push_back( srcData[i] ); じゃなくて？ 448 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [04/10/30 19:41:55] >>446 「offsetof」なんて初めて聞いた！ …と思ったらひょっとしてC++の言語仕様にはないものですよね？ ぐぐってみたらどうやら「.NET Framework」なのかな？ >>448 ふむふむ、ポインタを駆使すれば結構なことが出来そうですね。 しかしなんていうか難しいというかちょっぴり複雑に…。(^^; 基本的に私もメンバを一つ一つ指定することになんの抵抗も無かったんですが、 最近職場でBorlandC++Builderに慣れた同僚が、 「構造体のメンバって一つ一つ名前でアクセスしないといけないんですかねぇ？ 　面倒くさいですねぇ」 …などと話していたので、興味を持った次第でつ。 これができるとどういうメリットがあるかという話ですが、 （C++Builderの話限定になってしまうのですが） ＤＢの不特定なテーブルから、フィールド名を指定せずに 不特定の構造体のメンバにデータを突っ込めるため、 プログラムの汎用性が高まるということらしいです。 450 名前：デフォルトの名無しさん mailto:sage [04/10/30 22:20:56] offsetofを知らないだけならともかく(それも問題だが)、C#って・・・ 絞り込みも出来ない、googleのトップしか見ないで、２番目は無視する人かね 451 名前：448 mailto:sage [04/10/31 01:07:37] >>449 offsetofなんて、Cでもマクロで簡単に書ける代物なんだけど。 標準ヘッダを探してみることもできないのかな? 452 名前：デフォルトの名無しさん mailto:sage [04/10/31 02:37:42] うわ〜ん、そんなにいじめるなぁ〜。ヽ(`Д´)ﾉ 簡単にできるというのがいいのだよ。 めんどっちいのはイヤ。 453 名前：デフォルトの名無しさん mailto:sage [04/10/31 02:45:31] しかし、とりあえずoffsetofというマクロが 標準的に用意されてることを教えていただき、 ありがとうございますた。m(_ _ )m 454 名前：r mailto:sage [04/10/31 17:05:43] クラスのメンバを、別々に、同じベクタに入れる意味がわからん 455 名前：デフォルトの名無しさん [04/11/25 02:44:24] 最近書き込みがないね。 456 名前：デフォルトの名無しさん mailto:sage [04/11/25 04:01:13] 重複スレだからな。 457 名前：デフォルトの名無しさん mailto:sage [04/11/26 03:07:57] C言語とJavaとRuby使って，そこそこ書きました． 次はC++にチャレンジするかと，プログラミング言語C++を買ってきました． 難しいです．何書いてるのかわかりません． 俺の頭が悪いのが原因でしょうが，C++の難しさに挫けそうです

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef