スレを勃てるまでもないC/C++の質問はここで 12

スレを勃てるまでもな ..

924:デフォルトの名無しさん
09/09/07 22:00:23
ゲーム作っててつまずいたので質問します
struct Test{
TEST1 b[2];
省略
}
std::list< Test > lstTest;
こうやって使ってるんですが、このTEST1の配列を動的に確保することってできますか？
リストの中にリストとかしてみたんですが、同じような動きにならなくて困ってます。（ポインタの問題？

925:デフォルトの名無しさん
09/09/07 22:10:58
リストの中にリスト、大丈夫なはずだが

926:デフォルトの名無しさん
09/09/07 22:11:14
64Gって、研究かな？
今は、64Gのテキストデータなんてのを普通に使うようになったのか・・
恐ろしい時代だ・・・。

927:デフォルトの名無しさん
09/09/07 22:12:01
>>924
struct　Test　{
std::vector<TEST1>　b;
};
でいいと思う。
あと解説サイトを見てlistとvectorの使い分けを覚えよう。

928:デフォルトの名無しさん
09/09/07 22:14:01
list -> 知的でおしゃれな感じを出したいときに使う
vector -> スマートなやり手プログラマを演出したいときにはコレ
deque -> 研究者気取りのあなたに

929:デフォルトの名無しさん
09/09/07 23:22:48
48GBとかのデータを扱うなら、クラスタ上でMPIとか使って並列プログラミングってのが筋かなあ

930:デフォルトの名無しさん
09/09/07 23:54:41
buf[10] = 0xff
buf[11] = 0x32
...

int kansu(u_1 *buf){`

i = 10;
printf("test buf[i] %d", i, buf[i])

このようなプログラムで、引数で配列を渡したとき
printfでbuf[10]等の中身を見ようとしたとき、表示がおかしな値になるのですが
どうしてでしょうか？

%d, %s, %x　等もおかしかったのですが

931:デフォルトの名無しさん
09/09/07 23:55:52
"test buf[%d] %d" では？

932:デフォルトの名無しさん
09/09/08 00:14:45
>>931
すみません、ここに書き方間違ってました。
実際のプログラムではそうかいてます。申し訳ありません。
そう書いて、表示がおかしかたｔのです

933:デフォルトの名無しさん
09/09/08 00:23:39
%x

934:デフォルトの名無しさん
09/09/08 00:34:53
ソースを張るなり上げるなりしてください

935:デフォルトの名無しさん
09/09/08 00:40:31
u_1が何なのかわからないとなぁ

typedef unsigned char u_1;
だったらprintf()はスタック破壊してるだろうし
typedef unsigned long double u_1;
だったら表示がおかしいとかの次元じゃないし

936:デフォルトの名無しさん
09/09/08 00:47:23
>>935
u_1は、unsignede char です

スタック？どの辺がおかしいのでしょうか？

937:デフォルトの名無しさん
09/09/08 01:06:55
>>930
断片だけ書かれてもわからん。
おかしな値が再現するソースを見せてくれ。

938:デフォルトの名無しさん
09/09/08 01:11:54
>>937
すみません、今手元にないのでそのままお見せできないんですが
下のような感じです。とはいってもさっきと一緒で分かりにくいでしょうが・・

buf[50] ;
buf[1] = 0; buf[2] =5　等代入
void kansu(buf);

void kansu(u_1 *buf){`

i = 10;
printf("test buf[%d] %d", i, buf[i])

printf以降でbuf[i]の中身を別のバッファにコピーしてるのですが、
それを確認しようと思い、printfで確認しようとしたところ
まずその確認以前にうまく表示できなかったもので・・・

939:デフォルトの名無しさん
09/09/08 01:18:12
そもそも、bufの型はなんなんだ？
メモリは確保されてるのか？

940:デフォルトの名無しさん
09/09/08 01:18:36
>>939
malloc関数でかくほしております

941:デフォルトの名無しさん
09/09/08 01:19:31
>>939
bufは、unsigned char です

942:デフォルトの名無しさん
09/09/08 01:23:51
mallocで確保するんならbuf[50]は変な気がするけどな。

943:デフォルトの名無しさん
09/09/08 01:40:27
>>941
> i = 10;
> printf("test buf[%d] %d", i, buf[i])
別に表示がおかしくなることはないと思うがな。
この部分の、期待している表示と実際の表示を書いてくれ。

944:デフォルトの名無しさん
09/09/08 07:33:43
>>943
期待しているのは、buf[i]に代入した値が表示したいのですが、
全く関係ない数字が表示されてしまいます。4桁とか

945:デフォルトの名無しさん
09/09/08 07:47:07
部分だけじゃ、どこがおかしいかわかんねえよｗ

946:デフォルトの名無しさん
09/09/08 08:04:01
いくら間違っても4桁になるのはありえなさそうなんだが。。

947:デフォルトの名無しさん
09/09/08 08:31:55
>>938
まだコードが断片すぎる。コンパイルできるぐらいのまとまったものが
ないと他の人には問題は発見できないよ。

948:デフォルトの名無しさん
09/09/08 09:21:13
printf("%d", (unsigned char) 0xff)が何を表示されるのかって問題に帰結するのかな?
それだったら255だ。これがもしprintf("%d", (char) 0xff)ならば、-1かもしれないが。
それ以外の結果になるというのであれば、他の何かがおかしいのだろうよ。

949:デフォルトの名無しさん
09/09/08 18:03:25
fopen()でファイルを開くコストって結構かかる物なのでしょうか？
今実装してるプログラム、メモリ的な制限から探索範囲を狭めるために、ファイルを結構細分化するつもりなんですが・・・

950:デフォルトの名無しさん
09/09/08 18:15:34
>>949
ベンチマーク取ればいいが、
どんだけ多くても数百個だろ？一瞬。
むしろそれを超えると、OSの最大ディスクリプタ数にひっかかる。

951:デフォルトの名無しさん
09/09/08 18:16:48
>>949
まあストレージの種類によるんじゃないかな。ハードディスク上のファイルだと、
ファイルが分散しててディスクヘッドが頻繁に移動するのはハード的にきつい

952:デフォルトの名無しさん
09/09/08 18:30:14
>>949
48Gテキストの人か

953:デフォルトの名無しさん
09/09/08 18:59:52
頻繁にファイル開いて読み込んでってやってたらかなり遅くなるな。
一回読み込んだ内容はメモリ上にキャッシュして、キャッシュあふれたら
使用頻度低いほうから解放して…みたいな戦略は考えといたほうがいいと思うね。

954:デフォルトの名無しさん
09/09/08 20:04:30
>>949
ファイルのオープンクローズよりも、開いたファイルでシークしたほうがはるかに軽い。

ファイルの一部分をメモリにマップする手法としてメモリマップドファイルがあるよ。
ディスクキャッシュをメモリにマップするんで大きなデーターを効率的にアクセスできる。

955:デフォルトの名無しさん
09/09/08 20:08:25
Hoge::operator[](A,B,C);
hoge[a][b][c];
みたいなことができればいいのになんでできないんだよ

956:デフォルトの名無しさん
09/09/08 20:25:33
>>955
それでオーバーロードを許したらambiguous多発で大変じゃないか

957:デフォルトの名無しさん
09/09/08 20:44:33
まあ仕方ないからhoge[make_tuple(a,b,c)];
とかやってるんだけどもっとクールアンドホットなハック的テクはないわけ？

958:デフォルトの名無しさん
09/09/08 20:46:37
>>957
プロキシーオブジェクト

959:デフォルトの名無しさん
09/09/08 20:53:26
>>955 ちょっと工夫すればできるから。

960:デフォルトの名無しさん
09/09/08 21:02:07
やろうと思えばそりゃできるけどさ
コストとか範囲チェキとか考えると[][][]・・・でできるいいほうほうが浮かばないんだよ

961:デフォルトの名無しさん
09/09/08 21:02:39
>>955,958
ちとめんどいができるじゃんと思ったら
あれプロキシーオブジェクトっていうのか
初めて知った。さんくすｗ

962:デフォルトの名無しさん
09/09/08 21:02:51
>>957
operator()じゃ駄目なのか？

963:デフォルトの名無しさん
09/09/08 21:03:31
>>962
見た目がまずダサいのでアウト

964:デフォルトの名無しさん
09/09/08 21:07:57
make_tupleにダサイって言われると地味に凹むな

965:デフォルトの名無しさん
09/09/09 11:35:00
同意

966:デフォルトの名無しさん
09/09/09 23:13:55
ある本の息抜き用の演習問題に、「++CではなくC++と名付けられた理由を考えよ」ってのがあったのですが
正解は何なのでしょうか？

967:デフォルトの名無しさん
09/09/09 23:19:55
Cの互換性を保つため

968:デフォルトの名無しさん
09/09/09 23:26:45
あ、なるほど。前置インクリメントだともはやCではないものを意味するってことですね。

969:デフォルトの名無しさん
09/09/09 23:49:38
まあ、今適当に考えただけなんだけどねｗ
トンチ的な問題だろうから、たぶんそんなに的はずれでもないと思う

970:デフォルトの名無しさん
09/09/10 04:17:25
へんなコストがかかるところ

971:デフォルトの名無しさん
09/09/10 11:40:42
>>970
深いな。

972:デフォルトの名無しさん
09/09/10 13:58:48
//beginコード１
for(int i=0; i<5; i++){
　　// コード
}

int i;
for(i=0; i<5; i++){
// コード
}

C++で上か下、どちらのループの方が良い（皆さん使われている）のでしょうか？

973:972
09/09/10 13:59:57
1行目の
//beginコード１
は間違いです、すみません

974:デフォルトの名無しさん
09/09/10 14:03:33
i の中身がループの外でも意味を持つなら後者、持たないなら前者で十分。
どっちが良いとか悪いとかじゃなく。

975:デフォルトの名無しさん
09/09/10 14:35:18
>>974
なるほど、ありがとうございます。

976:デフォルトの名無しさん
09/09/10 15:45:51
>>966
C++ ： Cを評価してからインクリメントする
++C : Cをインクリメントしてから評価する

C++ は、まずCを評価してから機能を加えたんだよ。

977:デフォルトの名無しさん
09/09/10 17:13:48
baseクラスがいくつかの仮想メンバ関数を持っています（たとえば、void f1(), void f2()）
f1の実装は２パターン、f2の実装も２パターンあります
subクラス側で外部ファイルを参照してそのデータからf1,f2の組み合わせを決定したいです
この場合4種類のsubクラスを作るほかやり方はありますか？

978:デフォルトの名無しさん
09/09/10 17:16:35
仮想関数f1だけのクラスと仮想関数f2だけのクラスをそれぞれ作って2パターンずつ実装し、
subのf1, f2は単にそっちを呼び出す

979:デフォルトの名無しさん
09/09/10 17:17:02
>>977
f1 なり f2 の中で条件分岐すればできる

980:デフォルトの名無しさん
09/09/10 17:27:46
>>978
つまりこういうことでしょうか？
class hoge
{
private:
only_f1_impl *f1_;
only_f2_impl *f2_;

public:
void f1(){f1_->f1();}
void f2(){f2_->f2();}
};
メンバ変数へのアクセスで一手間かかりそうですが、よさそうなので使わせてもらいます
ありがとうございました

>>979
条件分岐は後で大変そうなのでちょっと・・・

981:デフォルトの名無しさん
09/09/10 19:56:01
##ってどういう意味か教えてください

982:デフォルトの名無しさん
09/09/10 20:01:49
そのトークンが現れる位置によって意味が異なるので一概に答えることはできない

983:デフォルトの名無しさん
09/09/10 20:38:19
インスタンスがshared_ptr（かweak_ptr）の形でしか生成できなくすることってできる？

984:デフォルトの名無しさん
09/09/10 21:07:22
>>983
コンストラクタをプライベートにして、ファクトリメソッドを書くとか。