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

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

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ポインタはスマートポインタで管理されていない。
一応回避策はありますが)や循環参照でメモリリークが
発生したりするので意外とつかいにくいです。むしろ
コンテナに入れることができる唯一のスマートポインタ
というつかいかたが多いです。

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

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のような型」が無い以上、
そういうやり方すら出来ないではないでつか…。
関数にしても結局はすべて名前で指定しなければならないし…。

次ページ