- 1 名前：デフォルトの名無しさん [2010/04/10(土) 23:30:23 BE:454421186-S★(520172)]
- C言語の＊入門者＊向け解説スレッドです。
★前スレ
C言語なら俺に聞け（入門編）Part 62
pc12.2ch.net/test/read.cgi/tech/1269517734/
★過去スレ
makimo.to:8000/cgi-bin/search/search.cgi?q=%82b%8C%BE%8C%EA%82%C8%82%E7%89%B4%82%C9%95%B7%82%AF&andor=AND&sf=0&H=&view=table&D=tech&shw=5000
★初心者、初級者の方は他の質問スレのほうが良いかもしれません。
例えば
【初心者歓迎】C/C++室 Ver.72【環境依存OK】
pc12.2ch.net/test/read.cgi/tech/1267775473/
とか
★教えて欲しいのではなく宿題を丸投げしたいだけなら
↓宿題スレ↓へ行ってください。
C/C++の宿題片付けます 135代目
pc12.2ch.net/test/read.cgi/tech/1269438098/
★C++言語についてはなるべく聞かないでください。C++対応明記スレへどうぞ
★分からない事をなるべく詳しく書いて下さい。
★ソースコードを晒すと答えやすくなるかもしれません。
# 抜粋／整形厳禁、コンパイラに渡したソースをそのまま貼ること
# サイズが大きい場合は宿題スレのアップローダ等を利用してください
★開発環境や動作環境も晒すと答えが早いかもしれません。
★質問者は最初にその質問をした時のレス番号を名前欄に書いて下さい。
- 331 名前：デフォルトの名無しさん mailto:sage [2010/04/23(金) 19:11:03 ]
- 何も有益な情報は残さずに読むものを不快にさせるだけのレスをするやつは死ねばいいのにな
- 332 名前：デフォルトの名無しさん mailto:sage [2010/04/23(金) 19:12:48 ]
- int (*(*foo)(int (*(*)(void))(void)))(int (*)(void))
- 333 名前：デフォルトの名無しさん mailto:sage [2010/04/23(金) 19:13:21 ]
- 俺は死ねばいいとか思わないけど、なんで>>331は自殺しないの？
- 334 名前：デフォルトの名無しさん mailto:sage [2010/04/23(金) 19:20:08 ]
- ﾎﾟｲﾝﾀと配列がごっちゃになってしまうところ
ある配列の実要素が ﾎﾟｲﾝﾀである（ﾎﾟｲﾝﾀ配列）場合 配列である（2次元配列）場合
各それぞれで、記憶領域の配置が本質的に違うのに理解できるまでの敷居が高い。
既に書かれている記述を読むのは可能でも
やりたいことを実装するのに、どちらが適切かを選択できるか がｷｰﾎﾟｲﾝﾄ
- 335 名前：デフォルトの名無しさん mailto:sage [2010/04/23(金) 19:21:54 ]
- 関数の引数や戻り値にポインタ変数が使われる場合なんかも初心者は混乱しやすいな
- 336 名前：デフォルトの名無しさん mailto:sage [2010/04/23(金) 19:24:36 ]
- 次元配列って
□□□□□□□□□
□□□□□□□□□
□□□□□□□□□
□□□□□□□□□
□□□□□□□□□
こんな感じで
配列の実要素がポインタってのは
□→□□□□□□□□□
□→□□□□□□□□□
□→□□□□□□□□□
□→□□□□□□□□□
□→□□□□□□□□□
こういうこと？
- 337 名前：デフォルトの名無しさん mailto:sage [2010/04/23(金) 19:30:14 ]
- >>336
おおよそ yes
指している先がどれだけの大きさの器があるか未確定 & ほとんど知る術は無い
（さらに、不正な場所を指している可能性もあるん）
□→□□□□
□→□□□□□□□
□→□
□→ぬるぽ！
□→鼻から悪魔
こういうことがあり得る
- 338 名前：デフォルトの名無しさん mailto:sage [2010/04/23(金) 19:34:43 ]
- >>321
割った余りで考えるという思考がありませんでした…。
ありがとうございました！
>>322
真偽でif文作るってのがあるのを知りませんでした。
勉強になりました！
- 339 名前：デフォルトの名無しさん mailto:sage [2010/04/23(金) 21:27:13 ]
- >>332
これ関数ポインタ？
DLLの関数を動的に呼ぶときに、
GetProcAdress（）で関数ポインタ取ってくるくらいしか使い道が分からん。
- 340 名前：デフォルトの名無しさん mailto:sage [2010/04/23(金) 21:38:28 ]
- 分かりやすそうなところを選ぶとしたらイベントハンドラとかかな。
- 341 名前：デフォルトの名無しさん mailto:sage [2010/04/23(金) 22:14:53 ]
- >>339
引数を取らず引数を取らずintを返す関数へのポインタを返す関数へのポインタを取り、
引数を取らずintを返す関数へのポインタを取りintを返す関数へのポインタを返す関数
へのポインタだね。
- 342 名前：デフォルトの名無しさん mailto:sage [2010/04/23(金) 22:27:42 ]
- ええい、いいから黙ってtypedefしろ
- 343 名前：デフォルトの名無しさん mailto:sage [2010/04/23(金) 22:35:09 ]
- typedefしまくりで夢がひろがりんぐ
- 344 名前：デフォルトの名無しさん [2010/04/23(金) 23:21:31 ]
- kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/10575.c
番号と名前がランダムに記入されたテキストを読み込んで、数字と名前に分けて配列に格納し、番号昇り順で並べかえてテキストファイルで出力したいのですが
並べかえがうまくいきません
とりあえず作ってみたのですが…
アドバイスください
- 345 名前：デフォルトの名無しさん mailto:sage [2010/04/23(金) 23:26:57 ]
- >>344
tmp はいらない
ソートができていない
ソートが終わってから出力すればいい
誰かに写させてもらったの？
- 346 名前：344 mailto:sage [2010/04/23(金) 23:33:00 ]
- 過去に作ったやつを何個か組み合わせて作ってたらこうなりました…
- 347 名前：デフォルトの名無しさん mailto:sage [2010/04/23(金) 23:33:07 ]
- >>344
番号、名前、テキストの定義をすると話が早いと思う。
例：
番号は、'0'から'9'の文字からなる文字列
名前は、ひらがな、かたかな、漢字からなる文字列
テキストは、番号と名前をスペースからなる文字列で、最後以外の番号および名前の後には必ずスペースが来る。
11113 3333 5892739 山田 12128384 高橋 32939 8883 細川 32932399
とか。
- 348 名前：デフォルトの名無しさん mailto:sage [2010/04/23(金) 23:37:36 ]
- >>344
ヒント
for
fscanf
for
for
if
for
fprintf
- 349 名前：デフォルトの名無しさん mailto:sage [2010/04/23(金) 23:41:59 ]
- >>344
まず
1.ファイルを全部読む
2.並び替えを行う
3.並び替えたデータをファイルに書く
っていう流れに書き換えて
2.の部分をじっくり考えてみてください。
- 350 名前：349 mailto:sage [2010/04/23(金) 23:43:51 ]
- >>348
もろかぶったスマンｗ
- 351 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 00:47:16 ]
- 関数から構造体を返す必要がある場合、何か基準や定石はありますか？
こういう時にはこうすれば良いという指針があれば知りたいです。
//構造体の例
struct my_struct {
int size;
void *ptr;
int data[];
};
//(1)create関数の中で構造体をmallocして、delete関数の中でfreeする。
struct my_struct* create_my_struct(int param);
void delete_my_struct(struct my_struct* md);
//(2)呼び出し元で構造体を確保して、init関数の中でメンバーをmallocして、release関数の中でメンバーをfreeする。
// 構造体そのものは呼び出し元でどうにかする。
int init_my_struct(struct my_struct* md, int param);
void release_my_struct(struct my_struct* md);
それぞれ下記のデメリットがあると思います。
(1)のデメリットは呼び出し元で入れたいメモリー領域がある場合、createした構造体をコピーする必要がある。
(2)のデメリットは呼び出し元でinitを呼ぶ前に構造体の大きさを知っていなければいけない。
- 352 名前：344 mailto:sage [2010/04/24(土) 00:55:12 ]
- 皆さんのアドバイス通りに流れを考えて、いちからやり直したら無事成功しました。
ありがとうございました。
- 353 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 01:20:37 ]
- >>351
（１）のデメリットがよくわからんな
そのメモリ領域ってのは create で確保するんじゃないの？
あとコピーうんぬんはコピー用の関数でOK?
- 354 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 01:51:37 ]
- >>353
実装はこんな感じです。
struct my_struct* create_my_struct(int param)
{
struct my_struct* md = (struct my_struct*)malloc(sizeof(struct my_struct) + sizeof(int)*param);
md->size = param;
md->ptr = malloc(param);
return md;
}
void delete_my_struct(struct my_struct* md)
{
free(md->ptr);
free(md);
}
デメリットは、下記のような場合、memcpyが必要なことです。
int get_data(char* buf, int size)
{
struct my_struct* md = create_my_struct(size); //←ここでbufを渡せたら
int ret = memcpy(buf, md->ptr, size); //←ここでコピーしなくていい
delete_my_struct(md);
return ret;
}
- 355 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 02:02:09 ]
- なんか違和感があるな。どういう思想なんだろ
- 356 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 02:49:32 ]
- >>354
*ptrの使い道はなんだろ。つーか、メンテしやすさ重視ならこうじゃね？
typedef struct {
int size;
int chinko;
int unko;
int data[];
} unko_t ;
unko_t *create_unko( unko_t *md, char *buf, size_t size )
{
md = malloc( sizeof(unko_t) + sizeof(int)*size );
if(md){
md->size=size;
memcpy(md->data,buf,size);
}
return md;
}
int get_data(char *buf, int size)
{
unko_t *md;
if( create_unko( md, buf, size )==NULL ) perror("unko");
- 357 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 02:50:30 ]
- 途中で送信しちゃったよもうどうでもいいや
- 358 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 02:58:38 ]
- >>354
まぁよくわからないんだけど、こんな感じにすればOK?
struct my_struct* create_my_struct(int param, char *buf)
{
struct my_struct* md = (struct my_struct*)malloc(sizeof(struct my_struct) + sizeof(int)*param);
md->size = param;
md->ptr = malloc(param);
if (buf)
memcpy(md->ptr, buf, size);
return md;
}
なんにせよ、構造体のサイズが不定って段階で create/delete 方式だね。
後でもっとよい実装を思いついたときにも直しやすそうだ。
- 359 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 02:59:04 ]
- いや、全然ダメだろ
create_unko()の第一引数が冗長だし、リソース開放できなくなってるし
どうでもいいけど、いまどきvoid *の代わりにchar *使わなくても
あと、変更しない変数にはconstを明示的に付けた方が幸せになれる
- 360 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 03:00:37 ]
- 豪快にかぶったけどまあどうでもいいな
- 361 名前：351 mailto:sage [2010/04/24(土) 03:04:33 ]
- 分かりにくかったので、>>354に追加します。
int do_some_process_to_my_struct(struct my_struct* md, int param)
{
for(int i = 0; i < md->size; i++){
((int*)md->ptr)[i] = param+i;
}
return param+i;
}
int get_data2(char* buf, int size)
{
struct my_struct* md = create_my_struct(size); //←ここでbufを渡せたら
do_some_process_to_my_struct(md, 12345);
int ret = memcpy(buf, md->ptr, size); //←ここでコピーしなくていい
delete_my_struct(md);
return ret;
}
- 362 名前：351 mailto:sage [2010/04/24(土) 03:12:28 ]
- >>358
いいえ。OKではないです。
memcpyするのはあくまでも例ですので、createの中にmemcpyを入れてしまうのは話が違ってしまいます。
知りたいことは、>>351に書いたとおり、関数から構造体を返す場合に
(1)と(2)あるいはその他の方法で良いやり方があるのか、ということです。
- 363 名前：351 mailto:sage [2010/04/24(土) 03:19:32 ]
- >>361
int do_some_process_to_my_struct(struct my_struct* md, int param)
{
int i;
for(i = 0; i < md->size; i++){
((char*)md->ptr)[i] = (char)(param+i);
}
return param+i;
}
あくまでも例ですが、間違っていたので訂正します。
- 364 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 03:23:36 ]
- やりたいことがまったく分からなくなってきたので
もう少し簡潔にわかりやすく実例込みで説明頼む
- 365 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 04:35:09 ]
- マクロでsubstituteする良い方法無い？
#define substitute_ptr(a) ??
#define fn_typedef(a,b) typedef a(*fn##substitute_ptr(a)##substitute_ptr(b))(b);
fn_typedef(ANYSTRUCT*const,int); → typedef ANYSTRUCT*const (*fnANYSTRUCTconstint)(int);
- 366 名前：デフォルトの名無しさん [2010/04/24(土) 06:47:19 ]
- printf( "sin(π) = %g \n" ,sin(M_PI) );
sinπが0にならないんだけど？
- 367 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 07:04:50 ]
- そんくらいの誤差は出るだろ
- 368 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 07:47:45 ]
- >>351
struct my_struct {
int size;
struct {
char param; /* malloc からchar型を想定 */
int data;
} elem[];
};
こういうふうにペアにしたらダメ？
型の異なる（しかし要素数の等しい）可変長ｻｲｽﾞを持つ構造体を取り扱いたいようだが…
- 369 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 09:17:20 ]
- >351
元々の質問は、一般的にはその2通りのやりかただろう、と答える。
しかし(1)のデメリットが理解できない。
(1)のデメリットは呼び出し元で「入れたいメモリー領域がある場合」、createした構造体をコピーする必要がある。
とくに「入れたいメモリ領域がある場合」という部分が不明。
ポインタがメンバになっているときに、その実体が欲しいってこと？
>354 >361を見てると、あってんだか違うんだか。creat関数の中でメンバを取得しようとしているのかワケワカ。
もしメンバがの実体が欲しいなら、そういう機能を実現した関数を作ればよい。
こんな感じじゃないか。
void get_data(struct my_struct* pMyData, void *pData)
{
pData = malloc(pMyData->size);
memmove(pData, pMyData->ptr);
}
- 370 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 09:55:27 ]
- 関数ポインタの配列について教えてください。
void func1( );
void func2( );
void main()
{
int i;
void (*func_ptr[2])( )= { func1, func2};
for(i=0; i<2; ++i)
{
(*func_ptr[i])( ); /* ★★★★ */
}
}
void func1( )
{
printf("func1\n");
}
void func2( )
{
printf("func2\n");
}
上記のプログラムでfunc1とfunc2が実行できたんですが、
★★★★のところを(func_ptr[i])( ); としても、func1とfunc2が実行できました。
関数ポインタの配列に*を付けた場合と付けない場合は何が違うのでしょうか？
- 371 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 10:00:40 ]
- 281 名前：デフォルトの名無しさん[sage] 投稿日：2007/11/08(木) 00:27:05
関数ポインタって代入時の&と実行時の*ってなくても動作変わらないよね？
もともとはどっちが正しいの？
282 名前：デフォルトの名無しさん[sage] 投稿日：2007/11/08(木) 01:06:42
元々必要だったらしいが、gccがなんか理論武装して独自拡張として省略しても良くしたら、
世間に受け入れられたなんて話を聞いたことがある。
- 372 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 10:10:25 ]
- a[3]と*(a+3)は何が違う
ってきくようなもの
書き方が違うだけでまったく同じ
- 373 名前：351 mailto:sage [2010/04/24(土) 10:42:37 ]
- >>368
struct my_struct はあくまでも構造体の一例です。
今回の質問ではstruct my_struct の中身を工夫することはあまり重要ではありません。
一般的な話として、関数から構造体を返す場合の、関数プロトタイプの設計に定石があるかどうかを知りたいのです。
こういう時にはこうすれば良いという指針があれば知りたいです。
>>369
>ポインタがメンバになっているときに、その実体が欲しいってこと？
いいえ。今、具体的な構造体あって、その構造体を扱う関数の作り方を知りたいということではありません。
質問の意図は、
構造体を初期化あるいは生成する関数を設計するときの一般論として、
例えば
「ポインタがメンバーになっている構造体の場合は(1)が良くて、そうでない構造体は(2)が良い」（←これは例です。）
というような定石があれば知りたい、ということです。
ですので、get_dataの作り方は質問の対象ではありません。
質問の対象は>>351の(1)(2)の関数プロトタイプについてです。
- 374 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 11:43:19 ]
- >>351
趣旨が良く分からんのだが、要するに、
構造体の中身を動的にメモリを確保しなくちゃならん時に、
構造体自身も動的に確保したい場合、
一緒に確保した方が良いのか、別々に確保した方が良いのかって話？
- 375 名前：370 mailto:sage [2010/04/24(土) 11:43:48 ]
- >>371-371
回答ありがとうございます。
*を付けると、func1という関数名になり最終的には、
関数名だけ書いた場合はアドレスになるというルールでアドレスになる。
*を付けないと、func1のアドレスになる
どちらでも同じようにfunc1が実行されるということで合ってますでしょうか？
- 376 名前：351 mailto:sage [2010/04/24(土) 11:46:36 ]
- >>374
そうですね。
どういう場合には一緒に確保したほうが良くて、どういう場合には別々に確保したほうが良いという指針があれば知りたいです。
他にもっと良いやり方があればそれも知りたいです。
- 377 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 12:59:50 ]
- >>376
その構造体の隠蔽具合や生命期間との相談かな
FILE ぐらい がちがちに隠蔽する
関数利用側は基本的にメンバアクセスしない： 操作関数(群) とセットになる
気なのか （この場合は create/delete で完結すべき）
リスト的用途に近く、親struct の生命期間とは生きている必要がある時間が
違う場合は、メンバは alloc せず NULL のまま
- 378 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 13:23:31 ]
- >>351
あぁ〜、やっぱり、趣旨がいまいち良く分からんな…。
>>354のget_data()の使い方を見るとcreate_my_struct()した時に、
領域の確保だけでなく、実際に必要なデータが作成されて、
その内容をget_data()で引っ張るって仕組みって認識したんだが、
ってことは、(1)でのcreate_my_struct()は、
メモリの確保だけでなく、データまで作成するって認識であってる？
で、(2)ではinit_my_struct()でデータだけ作成するってこと？
※ここでのデータ作成は、メモリの動的確保を含む
と言う事であれば、そのinit_my_struct()で作成すべきデータは
それだけで、一つの構造ってことになるから、
それぞれ用のcreateを作るが正しいと思うのだが？
仮にinit_my_struct()をcreate_my_struct2()とすると
create_my_struct()の中でcreate_my_struct2()を呼び出すイメージ。
で、その時々で必要なcreate()を呼ぶ。
- 379 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 14:04:10 ]
- >>376
俺も概ね>>377と同意見。
他のやり方としては、構造体なら関数の戻り値として
構造体の実体を返す方法もあるよ。
エラーを返しづらかったり、癖の強いやり方だけど。
- 380 名前：デフォルトの名無しさん [2010/04/24(土) 14:34:29 ]
- 板違いだったらすみません。。。
C言語(WinAPIを含む)でグローバルIPアドレスを無理やり変えることはできますか？
- 381 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 14:42:44 ]
- 通信できなくなるでしょ
- 382 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 14:47:21 ]
- >>380
C言語(WinAPIを含む)を使って、何の機器のグローバルIPを
どんな意味で変えたいのによるな
何もしても、このスレないことは確か。
- 383 名前：351 mailto:sage [2010/04/24(土) 14:59:48 ]
- >>377
>その構造体の隠蔽具合や生命期間との相談かな
なるほど。この指標は考える上での参考になりそうです。
ただちょっと初めの質問の意図と違ってきたので、ちょっと考え直します。
- 384 名前：デフォルトの名無しさん [2010/04/24(土) 15:06:31 ]
- >>381-382
無理ってことでしょうか？
たとえば掲示板などに書き込むと管理者には
グローバルIPがわかる($_SERVER["REMOTE_ADDR"])と思うのですが、
それをルータ、パソコンをシャットダウンしなくても
ソフトで簡単に変えられたら便利かな？って思ったので・・・
もっと深く突っ込むと
IP斬られてしまったりした場合にすぐに変更できれば
またレスできるぢゃないですかｗ
それをしたいんです・・・
- 385 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 15:09:03 ]
- >>384 板違い。
- 386 名前：デフォルトの名無しさん [2010/04/24(土) 15:10:44 ]
- >>385
板違いですか？
WinAPIだと思ったので・・・
- 387 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 15:11:55 ]
- >>384
IP変えるとか、それ以前の問題だな
ネットワークの知識とか、モラルとか、1からやり直せ
- 388 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 15:12:27 ]
- >>386 pc11.2ch.net/pcqa/
- 389 名前：351 mailto:sage [2010/04/24(土) 15:36:11 ]
- 標準ライブラリにstrdupがあります。strdupは内部でmallocします。（>>351の(1)に相当）
char *strdup(const char *s);
char* str = strdup("hogehoge"); //←確保するメモリー領域のサイズはstrdupのおまかせ！○
printf("%s\n", str); //処理の例
free(str); //freeが必要×
同等のことを行うmy_strdupを作ることもできます。my_strdupは内部でmallocしません。（>>351の(2)に相当）
void my_strdup(const char* src, char* dst, int size);
char str[100]; //←コピーする文字列より大きなサイズのメモリーが必要×
my_strdup("hogehoge", str, sizeof(str));
printf("%s\n", str); //処理の例
//freeは必要ない！○
（次に続く）
- 390 名前：351 mailto:sage [2010/04/24(土) 15:37:17 ]
- （>>389の続き）
【my_strdupのメリット】
strdupは、内部でmallocをするため、呼び出した後、必ずfreeが必要になります。
一方、my_strdupなら、自動変数を引数に渡せるので、必ずしもfreeは必要ありません。
この点では、my_strdupの方が便利です。これがmy_strdupのメリットです。
【strdupのメリット】
しかし、my_strdupでは、文字列全体をコピーしたい場合、
元の文字列よりも大きなサイズのメモリー領域を渡さなければ、文字列全体をコピーすることが出来ません。
このため、my_srtdupを呼び出す前に、strlenを使うなどして元の文字列のサイズを知る必要があります。
一方、strdupは内部で必要なサイズの領域をmallocするので呼び出す前に元の文字列のサイズを知る必要はありません。
この点では、strdupの方が便利です。これがstrdupのメリットです。
以上は文字列での例でしたが、
構造体や他のデータ領域を扱う関数を考えるときにも
呼び出し元でメモリーを確保して渡すか、あるいは関数の内部でmallocするか、
についてどういう時にどうしたらいいのか、を考えることができるかと思います。
一般的な指針があれば知りたいです。
- 391 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 16:12:35 ]
- strdup()のデメリットがfree()を必要とすることでは無い
オブジェクトを生成したら破棄するのは当然のことである(create/destroyの対が大切)
my_strdup()のメリットが自動変数を引数に渡せるとかなんとか言っているが
自動変数の領域が足りない場合や書き換えが必要な場合、結局メモリ確保が必要となり自動変数が渡せることはデメリットでしかない
たとえば、標準ライブラリのf*()について考えてみよう
FILEがクラスでfopen()がコンストラクタ、fclose()がデストラクタ、その他のf*()関数がFILEインスタンスに対するメッセージと考えれば、f*()群は低級なオブジェクト指向をしているとか意釈できる
ここで、一つの指針を示そう
あるオブジェクトを生成しメッセージを送り破棄せよ
foo_t *foo;
foo = create_foo();
do_something_foo(foo);
destroy_foo(foo);
呼出元が生成と破棄を対にして行うのが良い
この関係は、strupでもmy_strdupでも同じことになる
char *s = strdup(foo); /* create */
(void)s; /* do something */
free(s); /* destory */
char *t = malloc(bar); /* create */
my_strdup(foo, t, bar); /* do something */
free(t); /* destory */
my_strdup()がソースとデストが逆のmemcpy()みたいで気持ちが悪いと言っておくテスト
- 392 名前：351 mailto:sage [2010/04/24(土) 16:38:53 ]
- >>391
> strdup()のデメリットがfree()を必要とすることでは無い
> オブジェクトを生成したら破棄するのは当然のことである(create/destroyの対が大切)
確かに当然のことです。当然のことですので、その当然のことを忘れた場合、深刻なバグになるという大きなデメリットがあります。
> my_strdup()のメリットが自動変数を引数に渡せるとかなんとか言っているが
> 自動変数の領域が足りない場合や書き換えが必要な場合、結局メモリ確保が必要となり自動変数が渡せることはデメリットでしかない
自動変数で問題がいない場面では、上記の深刻なバグを避けられるという点で十分メリットがあります。
仰りたいことはわかりますが、一概に決められるものではないと思います。
例えば、>>391の主張では、memcpyはデメリットしか無いことになってしまいますよね？
> 呼出元が生成と破棄を対にして行うのが良い
良いのはわかります。つまり、それがstrdupや、>>351の(1)の場合ですよね。
my_strdupにmallocで確保したメモリー領域を与え、使用後freeするのも良いと思います。
ですが、my_strdupに自動変数を渡してはいけないということにはならないですよね？下記のようなコードは普通に書かれると思います。
void func(const char* str) //strは99文字以下の文字列
{
char buf[100];
strncpy(buf, str, sizeof(buf));
/*strに対する処理*/
printf("%s\n", str);
}
これは、若干恣意的な例ですが、これに限らず、自動変数の構造体や配列へのポインターを関数に渡すことは一般的に行われることですよね。
- 393 名前：351 mailto:sage [2010/04/24(土) 16:43:53 ]
- >>392の訂正です。すいません。
void func(const char* str) //strは99文字以下の文字列
{
char buf[100];
strncpy(buf, str, sizeof(buf));
/*bufに対する処理*/
printf("%s\n", buf);
}
- 394 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 17:20:21 ]
- >392
バグ(メモリリーク)になるから自動変数使うとかどれだけ舐めてるんだよ
C言語はプログラマ任せだからそんなこと言うようになったら、もうC言語に触れない方が幸せになれるよ
別にmemcpy()がデメリットしかないダメダメ関数とは言っていない
一般化したいと言っているのに自動変数マンセーとか言っているからだよ
自動変数(オブジェクト)に対してmempcy()(メッセージ)を送っているが、領域不足やコピーが必要になったときに結局メモリ(新しいオブジェクト)が必要になるのなら最初からメモリ使っておけばいいだろ
つまり、一般的にあるオブジェクトに対するメッセージの引数に自動変数が渡せるからって嬉しいことは無いだろと
memcpy()は抽象し過ぎているから混乱しているんだろう
別に、my_strdup()に自動変数を渡してはいけないとは言っていない
少なくとも自動変数が渡せることがメリットにはならないし、一般的に考えれば自動変数を使うことはデメリットになると言及しただけのこと
確かに、自動変数で領域や生存期間が足りるのであれば自動変数でも構わない
しかし、一般化してオブジェクトがN個必要なときに困ったことになる
ある場面ではi個必要で、自動変数をi個用意しなければならない、またある場面ではj個必要で、自動変数をj個用意しなければならない
じゃあ、i <= jだから、j個用意しとけばいいやとするのか、iが遥かにjより小さい場合無駄が多いからすべきでは無い
そんなことしないで、必要な時に必要なだけ用意してやれば済むこと
一般化したいのか具体化したいのかどちらかにしてもらえないだろうか
- 395 名前：351 mailto:sage [2010/04/24(土) 17:40:07 ]
- >>394
構造体や配列を返す関数を設計する場合の一般的な指針を求めています。
>C言語はプログラマ任せだからそんなこと言うようになったら、もうC言語に触れない方が幸せになれるよ
C言語はプログラマ任せだからこそ、プログラマーが、その時々に適切に、自動変数を渡すか、mallocで確保したメモリーを渡すかを選べるようにしておく方が幸せでしょう。
ですので、自動変数をマンセーしているわけではありませんが、自動変数を一切渡せないよりは、渡せた方がメリットがあると考えます。
つまり、自動変数を一切渡せなければ、自動変数を使いたいプログラマーには使えませんが
自動変数を一切渡せれば、自動変数を使いたいプログラマーにも、使いたくないプログラマーにも使えるからです。
これは十分メリットです。
ともかく、自動変数を渡せるかどうかは、今回の質問の本質ではなく、
構造体や配列を返す関数を設計する場合の一般的な指針として、
(1)関数内部でmallocするのと、(2)呼び出し側で確保したメモリー領域を受け取るのと、(3)それ以外の方法（があれば）と、で
どういう時にどうするのが良いのかという指針があれば知りたいと思っています。
- 396 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 17:56:48 ]
- >どういう時にどうするのが良いのかという指針があれば知りたいと思っています。
ないよ。問題が無い限り好きにしてよしヽ( ´ー｀)ノ
- 397 名前：351 mailto:sage [2010/04/24(土) 18:05:31 ]
- 「好きにしてよい」というのは、特に基準がないのでその日の気分でどちらかに決めるということですよね。
そういう方針の方もいるということはわかりました。ありがとうございます。
それでは引き続き、>>389-390について何か方針をお持ちの方がいましたら、ぜひ教えてください。お願いします。
- 398 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 18:24:44 ]
- WindowsのAPIは、my_strdup()みたいに格納領域のアドレスとサイズを
渡すインタフェースが多いね
で、Windows系のプログラマはそういう関数をつくることが多いね
無難だけど美しくないよね
パラメタは少ない方がいい
- 399 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 18:38:23 ]
- >>389
とりあえず、strdupは例として適当じゃないわな。目的が違うから。
単に（最大の）長さが分かっている文字列のコピーは
strcpyなりstrncpyなりを使う。
一般論で言って、必然性がない場合、mallocはしない。
する場合は、旧来では
・確保すべきサイズがかわる
・スコープを越える必要がある
他のケースはプログラマの腕次第で
コードをシンプルにするために使う。
・引数を減らす
・必要な変数を減らす
・インターフェイスの一般化
などなど。
メモリ管理に自信がないならやめとき。
ただイマドキ、そこに自信が持てないなら
Cなんて使わない。
逆に言えば、その程度は必須なわけで、
だから「好きにすれば良い」って意見が出てくる。
- 400 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 19:25:00 ]
- >351
生成と解放を対にしろってのは、基本方針としてもよいと思う。
よって、strdupのような関数は、できれば使いたくない派。
strdupは生成と解放の数が合わなくなる。
>392
>> 呼出元が生成と破棄を対にして行うのが良い
>良いのはわかります。つまり、それがstrdupや、>>351の(1)の場合ですよね。
これ逆だよね。strdupを使うとmallocが見えないのにfreeしなくちゃならない。
strdupは標準関数だからましだけど、func0, func2, func4が返すポインタは
freeしてね、とかだとやってられない。
やけにstrdupが「サイズを気にしなくてよい」ことがお気に入りのようだが、あくまでも実引数がCstringである場合だけ。
これは自動変数か、ヒープ領域か、静的変数かには無関係。
str系関数は、終端文字がある前提という制限がある。
呼び出し側が領域を用意する場合は、当然呼び出し側でサイズがわかっているはずなので、
そのときに無駄に領域を用意しなければよいだけでしょ。
- 401 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 19:32:16 ]
- 急に流れが加速してて吹いた。
- 402 名前：351 mailto:sage [2010/04/24(土) 19:32:36 ]
- >>399
> 一般論で言って、必然性がない場合、mallocはしない。
> する場合は、旧来では
> ・確保すべきサイズがかわる
> ・スコープを越える必要がある
これには同意です。
個人的には自動変数で済む場合はmallocは使わないようにしています。
> コードをシンプルにするために使う。
> ・引数を減らす
> ・必要な変数を減らす
> ・インターフェイスの一般化
これは、シンプルになるのであれば、シンプルにしたほうがいいということですね。
つまり、>>351の(1)が可能であれば、常に(1)にしろということですね。
方針の一つとして参考にさせていただきます。
- 403 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 19:34:03 ]
- ・サイズが巨大な場合
が抜けてるな
- 404 名前：351 mailto:sage [2010/04/24(土) 19:45:44 ]
- >>400
>生成と解放を対にしろってのは、基本方針としてもよいと思う。
>よって、strdupのような関数は、できれば使いたくない派。
個人的にはstrdupは使いませんが、
strdupもstrdup-freeで生成と解放の対になっているので問題ないと思います。
（n対1の対応なので若干違和感はありますが。）
>これ逆だよね。strdupを使うとmallocが見えないのにfreeしなくちゃならない。
いいえ、関数の中でmallocを行うという点で、strdupと>>351の(1)は同じです。
create_my_struct()に対するdelete_my_struct()は、strdup()に対するfree()です。
- 405 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 19:52:13 ]
- strdupって名前が気に入らないんじゃないの
"alloc" を含んでないから
俺は別にどうでもいいと思うけど
- 406 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 20:00:01 ]
- 関数の実体が書いてないから、何とも言えないね
- 407 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 21:35:25 ]
- >>398
上位互換を維持しつつ ver 違いを吸収する苦肉の策な面もあるね
APIを実装する際「渡されたｻｲｽﾞからどのver なのか類推・分岐できる」
- 408 名前：デフォルトの名無しさん [2010/04/24(土) 21:57:07 ]
- GDI+を使うためにはどうすればいいですか？
VC2008です。
- 409 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 21:57:40 ]
- 上位互換を持するということは、元の関数から引数は変化がないということだろ。
元の関数から変化が変化がないということは、元の関数もアドレスとサイズを持っていたということであって
つまり元々あるのだから苦肉の策では無いんじゃないの。
- 410 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 22:07:16 ]
- >>408
#include <gdiplus.h>
#pragma comment(lib, "gdiplus")
- 411 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 22:10:20 ]
- >>410
VC++の他に特に何もいらないということですね。
質問にこたえていただきありがとうございます。
- 412 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 22:11:41 ]
- VC++EE使ってるならPlatformSDKがいるんじゃ
- 413 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 22:14:01 ]
- 例がたまたまかもしれないけど、my_strdupを使うくらいならstrncpyを使うよね。
話を戻すと、allocとfreeは同じレイヤーにあるのが分かりやすいと思うよ。
- 414 名前：351 mailto:sage [2010/04/24(土) 22:26:58 ]
- >>413
> 話を戻すと、allocとfreeは同じレイヤーにあるのが分かりやすいと思うよ。
それはそのとおりだと思います。
>>351の(1)(2)ともにその方針に基づいています。
(1)の場合は自前でalloc-freeを行い、(2)の場合は前処理・後処理として必要な場合のみalloc-freeを行います。
今回の質問の趣旨はそこではなく、
構造体や配列を返す関数を設計する場合の一般的な指針を知りたいのです。
- 415 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 22:42:53 ]
- >>351
俺は、is-aと考えた方が自然なのかhas-aと考えた方が自然なのかで分ける。
分かるとは思うが(1)はis-aの場合で、(2)はhas-aの場合。
あと、自動変数を使用するか、アロケートするかは、
プログラマが使いたいか使いたくないかで考えるのではなく、使用用途で考えるべき。
- 416 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 22:45:55 ]
- > (1)のデメリットは呼び出し元で入れたいメモリー領域がある場合、createした構造体をコピーする必要がある。
入れたいメモリ領域がある場合はinitのパラメータにもたせれば良いのでは？
> (2)のデメリットは呼び出し元でinitを呼ぶ前に構造体の大きさを知っていなければいけない。
my_struct *p = (my_struct *)malloc(sizeof(my_struct));
ではだめだということ？
常に呼ばなければならないreleaseを作成するのであれば、常にinitの中でallocすればいいと思う。
そうでないのなら、構造体本体は利用者がalloc-freeすればいいと思う。というか、そうしてる。
- 417 名前：351 mailto:sage [2010/04/24(土) 23:00:41 ]
- >>415
なるほど。その指針は明快ですね。納得です。
ありがとうございます。
>>416
>> (1)のデメリットは呼び出し元で入れたいメモリー領域がある場合、createした構造体をコピーする必要がある。
>入れたいメモリ領域がある場合はinitのパラメータにもたせれば良いのでは？
つまり、常に>>351の(2)にするのが良いということでしょうか？
>> (2)のデメリットは呼び出し元でinitを呼ぶ前に構造体の大きさを知っていなければいけない。
>my_struct *p = (my_struct *)malloc(sizeof(my_struct));
>ではだめだということ？
はい、ダメです。
struct my_structは可変長配列のメンバーdataを持っているのでそのサイズ分多めにメモリーを確保しなくてはいけません。
- 418 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 23:19:22 ]
- 入れたいメモリ領域を渡したいことについて
(2)のinitのパラメータに持たせてもいいし、(1)のcreateのパラメータに持たせてもいい。
可変部のサイズを常にパラメータで渡すのであれば、呼び元でそのサイズを確保することは
十分可能なんじゃないの？
- 419 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 23:28:12 ]
- >>409
いや パラメータが一括で纏まった構造体 ってﾊﾟﾀｰﾝがほとんどさね
ListView とか IEのVER違いで、パラメータ構造体のサイズが違う
だが API（要素の追加とか）のインターフェースは不変
（さらに、APIの実装体は外部ﾘﾝｹｰｼﾞなDLL内）
こういうこと
この例でない話だったらｽﾏﾝ
- 420 名前：351 mailto:sage [2010/04/24(土) 23:42:33 ]
- >>418
入れたいメモリ領域を渡すのが(2)で、入れたいメモリ領域を渡さず関数内部でメモリ領域を確保するのが(1)です。これが定義です。
ですので、入れたいメモリ領域を渡すのであれば、(2)になります。
また、(1)の場合は、可変部の情報を含めサイズ情報を渡しません。
ですので、(1)の場合、呼び出し元は可変部の情報を含めサイズ情報を呼び出す前に知る必要はありませんし、
前述のとおり関数内部でメモリー領域を確保するので、そのサイズを知ることが出来なくても問題ありません。
- 421 名前：デフォルトの名無しさん mailto:sage [2010/04/24(土) 23:58:42 ]
- >>420
入れたいメモリ領域云々を別で考えることはできないの？
そうなればそれは一般的に構造体を扱う時の指針とかそういうのとは別で、特殊化された話になってこないか？
- 422 名前：351 mailto:sage [2010/04/25(日) 00:14:29 ]
- >>421
> 入れたいメモリ領域云々を別で考えることはできないの？
これはどう言うことでしょうか？
少なくともどこか（関数内あるいは関数外）で、malloc(sizeof(struct my_struct)+data_size)のように構造体のメモリーを確保しなければならないと考えていました。
もしこれを別で考える方法があるならば、ぜひご教示ください。
- 423 名前：デフォルトの名無しさん mailto:sage [2010/04/25(日) 00:33:19 ]
- 入れたいメモリ領域ってptrじゃないの？
サイズを可変にするためのものとは別だよね。
このptrを同じ関数で確保すべきか、外から渡せるようにするかという話が混ざっているように見える。
- 424 名前：351 mailto:sage [2010/04/25(日) 00:41:35 ]
- >>423
>入れたいメモリ領域ってptrじゃないの？
入れたいメモリ領域とは、構造体そのものを入れたい領域のことです。
- 425 名前：400 mailto:sage [2010/04/25(日) 00:42:10 ]
- >351 >420
あなたの言う1)と2)の違いを、把握できていなかったから、議論がぐるぐる回っていたぞ。
議論の焦点は
>入れたいメモリ領域を渡すのが(2)で、入れたいメモリ領域を渡さず関数内部でメモリ領域を確保するのが(1)です。これが定義です。
ということだね。
そうでであるならば
>(1)の場合は、可変部の情報を含めサイズ情報を渡しません。
これは無理。
1)の実現例としてstrdupを挙げているのなら、str系は終端文字列付きという制限を与えることで、
間接的にサイズ情報を与えている。
>404
>いいえ、関数の中でmallocを行うという点で、strdupと>>351の(1)は同じです。
私には同じには見えないな。
malloc-free, new-delete, new[]-delete, create_my_struct-delete_my_struct
は対に見える。
だけど関数内部でmallocするhogeがあるとしてhoge-freeは対には見えない。
そういうことに注意してコーディングしたくない。
だからstrdup使うくらいなら、mallocしてstrcpyして、freeする。
- 426 名前：351 mailto:sage [2010/04/25(日) 00:56:57 ]
- >>425
> >(1)の場合は、可変部の情報を含めサイズ情報を渡しません。
> これは無理。
いいえ。無理ではありません。
例えば、関数内でrecv()を使ってネットワークからデータを受信する場合など、処理を完了して初めてデータのサイズが確定することがあります。
そのような場合、関数を呼び出す前にはそのサイズは分かりませんが、関数内ではreallocするなりして適切なサイズのメモリーを確保することができます。
したがって、可能です。
>私には同じには見えないな。
これは関数名が適切ではないとうことでしょうか？
そうであれば特に異論はありません。人の感覚なのでそう見えない人がいることは仕方が無いと思います。
そういう点では、私も、new-deleteという組み合わせが名称としてあまり適切でないと思っています。
私が同じだといったのは、機能としての対応からです。
- 427 名前：デフォルトの名無しさん mailto:sage [2010/04/25(日) 01:52:31 ]
- >>426
> 例えば、関数内でrecv()を使ってネットワークからデータを受信する場合など、
> 処理を完了して初めてデータのサイズが確定することがあります。
>そのような場合、関数を呼び出す前にはそのサイズは分かりませんが、
>関数内ではreallocするなりして適切なサイズのメモリーを確保することができます。
なぜ recv() がそういう造りになっていないのか？ を想像してくれ
上記の構造だと、生成/消滅の入れ子構造が維持し難いんだよね
- 428 名前：351 mailto:sage [2010/04/25(日) 01:59:41 ]
- >>427
> なぜ recv() がそういう造りになっていないのか？ を想像してくれ
何のためにその想像をする必要があるのでしょうか？
目的がよくわかりません。
- 429 名前：デフォルトの名無しさん mailto:sage [2010/04/25(日) 03:25:24 ]
- >>424
ならぬるぽのときだけ確保するようにしたらいいんでないかな。
- 430 名前：デフォルトの名無しさん mailto:sage [2010/04/25(日) 03:27:29 ]
- >>425
うーん、strdup-freeも対に見えないよ
その論調ならstrdupの存在を否定していいと思うんだ。そしてそれはアリだと俺は思う。
- 431 名前：デフォルトの名無しさん mailto:sage [2010/04/25(日) 03:33:04 ]
- って最後の行読んでなかった。まったくもってそのとおりであって、なんていうかごめん。
ちなみにnew[]-deleteはnew[]-delete[]の間違いだよな？
>>426
> 人の感覚なのでそう見えない人がいることは仕方が無いと思います。
なんか多分読み違えているけれど、
create_my_structのような関数を見た場合、同ライブラリにdelete_my_structのような関数があれば
プログラマは注意を払うが、なければ特に何もしなくて良い(freeを使う必要がない)と思ってしまうクセがある。
そういう意味で、hoge-freeが対に見えないという話だよ
|
 |
