C言語なら俺に聞け（入門編）Part 63

C言語なら俺に聞け（� ..

391:デフォルトの名無しさん
10/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
10/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
10/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:デフォルトの名無しさん
10/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
10/04/24 17:40:07
>>394
構造体や配列を返す関数を設計する場合の一般的な指針を求めています。

>C言語はプログラマ任せだからそんなこと言うようになったら、もうC言語に触れない方が幸せになれるよ

C言語はプログラマ任せだからこそ、プログラマーが、その時々に適切に、自動変数を渡すか、mallocで確保したメモリーを渡すかを選べるようにしておく方が幸せでしょう。
ですので、自動変数をマンセーしているわけではありませんが、自動変数を一切渡せないよりは、渡せた方がメリットがあると考えます。

つまり、自動変数を一切渡せなければ、自動変数を使いたいプログラマーには使えませんが
自動変数を一切渡せれば、自動変数を使いたいプログラマーにも、使いたくないプログラマーにも使えるからです。
これは十分メリットです。

ともかく、自動変数を渡せるかどうかは、今回の質問の本質ではなく、
構造体や配列を返す関数を設計する場合の一般的な指針として、
(1)関数内部でmallocするのと、(2)呼び出し側で確保したメモリー領域を受け取るのと、(3)それ以外の方法（があれば）と、で
どういう時にどうするのが良いのかという指針があれば知りたいと思っています。

396:デフォルトの名無しさん
10/04/24 17:56:48
>どういう時にどうするのが良いのかという指針があれば知りたいと思っています。

ないよ。問題が無い限り好きにしてよしヽ( ´ー｀)ノ

397:351
10/04/24 18:05:31
「好きにしてよい」というのは、特に基準がないのでその日の気分でどちらかに決めるということですよね。
そういう方針の方もいるということはわかりました。ありがとうございます。

それでは引き続き、>>389-390について何か方針をお持ちの方がいましたら、ぜひ教えてください。お願いします。

398:デフォルトの名無しさん
10/04/24 18:24:44
WindowsのAPIは、my_strdup()みたいに格納領域のアドレスとサイズを
渡すインタフェースが多いね
で、Windows系のプログラマはそういう関数をつくることが多いね
無難だけど美しくないよね
パラメタは少ない方がいい

399:デフォルトの名無しさん
10/04/24 18:38:23
>>389
とりあえず、strdupは例として適当じゃないわな。目的が違うから。
単に（最大の）長さが分かっている文字列のコピーは
strcpyなりstrncpyなりを使う。

一般論で言って、必然性がない場合、mallocはしない。
する場合は、旧来では
・確保すべきサイズがかわる
・スコープを越える必要がある

他のケースはプログラマの腕次第で
コードをシンプルにするために使う。
・引数を減らす
・必要な変数を減らす
・インターフェイスの一般化
などなど。

メモリ管理に自信がないならやめとき。

ただイマドキ、そこに自信が持てないなら
Cなんて使わない。
逆に言えば、その程度は必須なわけで、
だから「好きにすれば良い」って意見が出てくる。

400:デフォルトの名無しさん
10/04/24 19:25:00
>351

生成と解放を対にしろってのは、基本方針としてもよいと思う。
よって、strdupのような関数は、できれば使いたくない派。
strdupは生成と解放の数が合わなくなる。

>392
>> 呼出元が生成と破棄を対にして行うのが良い

>良いのはわかります。つまり、それがstrdupや、>>351の(1)の場合ですよね。

これ逆だよね。strdupを使うとmallocが見えないのにfreeしなくちゃならない。

strdupは標準関数だからましだけど、func0, func2, func4が返すポインタは
freeしてね、とかだとやってられない。

やけにstrdupが「サイズを気にしなくてよい」ことがお気に入りのようだが、あくまでも実引数がCstringである場合だけ。
これは自動変数か、ヒープ領域か、静的変数かには無関係。

str系関数は、終端文字がある前提という制限がある。

呼び出し側が領域を用意する場合は、当然呼び出し側でサイズがわかっているはずなので、
そのときに無駄に領域を用意しなければよいだけでしょ。

401:デフォルトの名無しさん
10/04/24 19:32:16
急に流れが加速してて吹いた。

402:351
10/04/24 19:32:36
>>399
> 一般論で言って、必然性がない場合、mallocはしない。
> する場合は、旧来では
> ・確保すべきサイズがかわる
> ・スコープを越える必要がある

これには同意です。
個人的には自動変数で済む場合はmallocは使わないようにしています。

> コードをシンプルにするために使う。
> ・引数を減らす
> ・必要な変数を減らす
> ・インターフェイスの一般化

これは、シンプルになるのであれば、シンプルにしたほうがいいということですね。
つまり、>>351の(1)が可能であれば、常に(1)にしろということですね。
方針の一つとして参考にさせていただきます。

403:デフォルトの名無しさん
10/04/24 19:34:03
・サイズが巨大な場合
が抜けてるな

404:351
10/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:デフォルトの名無しさん
10/04/24 19:52:13
strdupって名前が気に入らないんじゃないの
"alloc" を含んでないから
俺は別にどうでもいいと思うけど

406:デフォルトの名無しさん
10/04/24 20:00:01
関数の実体が書いてないから、何とも言えないね

407:デフォルトの名無しさん
10/04/24 21:35:25
>>398
上位互換を維持しつつ ver 違いを吸収する苦肉の策な面もあるね

APIを実装する際「渡されたｻｲｽﾞからどのver なのか類推・分岐できる」

408:デフォルトの名無しさん
10/04/24 21:57:07
GDI+を使うためにはどうすればいいですか？
VC2008です。

409:デフォルトの名無しさん
10/04/24 21:57:40
上位互換を持するということは、元の関数から引数は変化がないということだろ。
元の関数から変化が変化がないということは、元の関数もアドレスとサイズを持っていたということであって
つまり元々あるのだから苦肉の策では無いんじゃないの。

410:デフォルトの名無しさん
10/04/24 22:07:16
>>408
#include <gdiplus.h>
#pragma comment(lib, "gdiplus")

411:デフォルトの名無しさん
10/04/24 22:10:20
>>410
VC++の他に特に何もいらないということですね。
質問にこたえていただきありがとうございます。

412:デフォルトの名無しさん
10/04/24 22:11:41
VC++EE使ってるならPlatformSDKがいるんじゃ

413:デフォルトの名無しさん
10/04/24 22:14:01
例がたまたまかもしれないけど、my_strdupを使うくらいならstrncpyを使うよね。

話を戻すと、allocとfreeは同じレイヤーにあるのが分かりやすいと思うよ。

414:351
10/04/24 22:26:58
>>413
> 話を戻すと、allocとfreeは同じレイヤーにあるのが分かりやすいと思うよ。

それはそのとおりだと思います。
>>351の(1)(2)ともにその方針に基づいています。
(1)の場合は自前でalloc-freeを行い、(2)の場合は前処理・後処理として必要な場合のみalloc-freeを行います。

今回の質問の趣旨はそこではなく、
構造体や配列を返す関数を設計する場合の一般的な指針を知りたいのです。

415:デフォルトの名無しさん
10/04/24 22:42:53
>>351
俺は、is-aと考えた方が自然なのかhas-aと考えた方が自然なのかで分ける。
分かるとは思うが(1)はis-aの場合で、(2)はhas-aの場合。
あと、自動変数を使用するか、アロケートするかは、
プログラマが使いたいか使いたくないかで考えるのではなく、使用用途で考えるべき。

416:デフォルトの名無しさん
10/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
10/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:デフォルトの名無しさん
10/04/24 23:19:22
入れたいメモリ領域を渡したいことについて
(2)のinitのパラメータに持たせてもいいし、(1)のcreateのパラメータに持たせてもいい。

可変部のサイズを常にパラメータで渡すのであれば、呼び元でそのサイズを確保することは
十分可能なんじゃないの？

419:デフォルトの名無しさん
10/04/24 23:28:12
>>409
いや　パラメータが一括で纏まった構造体　ってﾊﾟﾀｰﾝがほとんどさね
ListView とか　IEのVER違いで、パラメータ構造体のサイズが違う
だが　API（要素の追加とか）のインターフェースは不変
（さらに、APIの実装体は外部ﾘﾝｹｰｼﾞなDLL内）
こういうこと

この例でない話だったらｽﾏﾝ

420:351
10/04/24 23:42:33
>>418
入れたいメモリ領域を渡すのが(2)で、入れたいメモリ領域を渡さず関数内部でメモリ領域を確保するのが(1)です。これが定義です。
ですので、入れたいメモリ領域を渡すのであれば、(2)になります。

また、(1)の場合は、可変部の情報を含めサイズ情報を渡しません。
ですので、(1)の場合、呼び出し元は可変部の情報を含めサイズ情報を呼び出す前に知る必要はありませんし、
前述のとおり関数内部でメモリー領域を確保するので、そのサイズを知ることが出来なくても問題ありません。

421:デフォルトの名無しさん
10/04/24 23:58:42
>>420
入れたいメモリ領域云々を別で考えることはできないの？
そうなればそれは一般的に構造体を扱う時の指針とかそういうのとは別で、特殊化された話になってこないか？

422:351
10/04/25 00:14:29
>>421
> 入れたいメモリ領域云々を別で考えることはできないの？

これはどう言うことでしょうか？
少なくともどこか（関数内あるいは関数外）で、malloc(sizeof(struct my_struct)+data_size)のように構造体のメモリーを確保しなければならないと考えていました。

もしこれを別で考える方法があるならば、ぜひご教示ください。

423:デフォルトの名無しさん
10/04/25 00:33:19
入れたいメモリ領域ってptrじゃないの？
サイズを可変にするためのものとは別だよね。

このptrを同じ関数で確保すべきか、外から渡せるようにするかという話が混ざっているように見える。

424:351
10/04/25 00:41:35
>>423
>入れたいメモリ領域ってptrじゃないの？

入れたいメモリ領域とは、構造体そのものを入れたい領域のことです。

425:400
10/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
10/04/25 00:56:57
>>425
> >(1)の場合は、可変部の情報を含めサイズ情報を渡しません。
> これは無理。

いいえ。無理ではありません。
例えば、関数内でrecv()を使ってネットワークからデータを受信する場合など、処理を完了して初めてデータのサイズが確定することがあります。
そのような場合、関数を呼び出す前にはそのサイズは分かりませんが、関数内ではreallocするなりして適切なサイズのメモリーを確保することができます。
したがって、可能です。

>私には同じには見えないな。

これは関数名が適切ではないとうことでしょうか？
そうであれば特に異論はありません。人の感覚なのでそう見えない人がいることは仕方が無いと思います。
そういう点では、私も、new-deleteという組み合わせが名称としてあまり適切でないと思っています。

私が同じだといったのは、機能としての対応からです。

427:デフォルトの名無しさん
10/04/25 01:52:31
>>426
> 例えば、関数内でrecv()を使ってネットワークからデータを受信する場合など、
> 処理を完了して初めてデータのサイズが確定することがあります。
>そのような場合、関数を呼び出す前にはそのサイズは分かりませんが、
>関数内ではreallocするなりして適切なサイズのメモリーを確保することができます。

なぜ　recv() がそういう造りになっていないのか？　を想像してくれ
上記の構造だと、生成/消滅の入れ子構造が維持し難いんだよね　

428:351
10/04/25 01:59:41
>>427
> なぜ　recv() がそういう造りになっていないのか？　を想像してくれ

何のためにその想像をする必要があるのでしょうか？
目的がよくわかりません。

429:デフォルトの名無しさん
10/04/25 03:25:24
>>424
ならぬるぽのときだけ確保するようにしたらいいんでないかな。

430:デフォルトの名無しさん
10/04/25 03:27:29
>>425
うーん、strdup-freeも対に見えないよ
その論調ならstrdupの存在を否定していいと思うんだ。そしてそれはアリだと俺は思う。

431:デフォルトの名無しさん
10/04/25 03:33:04
って最後の行読んでなかった。まったくもってそのとおりであって、なんていうかごめん。

ちなみにnew[]-deleteはnew[]-delete[]の間違いだよな？

>>426
> 人の感覚なのでそう見えない人がいることは仕方が無いと思います。
なんか多分読み違えているけれど、
create_my_structのような関数を見た場合、同ライブラリにdelete_my_structのような関数があれば
プログラマは注意を払うが、なければ特に何もしなくて良い(freeを使う必要がない)と思ってしまうクセがある。
そういう意味で、hoge-freeが対に見えないという話だよ

432:>425
10/04/25 08:44:44
>431

>ちなみにnew[]-deleteはnew[]-delete[]の間違いだよな？

すみません。タイプミス。注意したつもりだったのに、日頃C++使わない物で、ご容赦ください。

>426
他の人とは、同じ感覚みたいだけど、strdup-freeはリソースの確保と解放のレベルがあっていない、
イヤなコーディングスタイルだってこと。mallocしているレベルが、一段低いから。
名前の問題ではない。
ただ、標準関数という意味でギリギリの許容範囲。
コーディングスタイルを操作できる立場なら、ANSIに含まれないから禁止としたいくらい。
拒否する。

もちろんそういう構造が取れない場合は、あり得る。
だけど「一般的には」リソースの確保と解放の対は、そろっている方がよい。

433:デフォルトの名無しさん
10/04/25 09:22:07
>>432
横からだけど、レベル合わせるのって必要か？
どちらかと言うと、アロケートとリリースが組み合わせになってないことの方が問題じゃないか？
strdupに対して、strdup_free()があれば良いだけで、
使う方は、その中身の実装は問わないってのが正解な気がするが…？
要するに、あるオブジェクトに対してのnewがあるなら、
そのオブジェクトに対するdeleteを用意して、それを使えってだけで、
組み合わせを間違えなければ、内部がどうなってようが、問題にならないと思うが…

434:デフォルトの名無しさん
10/04/25 09:41:31
同じく横からだけど
デストラクタが無い影響はスコープだけじゃなく構造体・共用体の中にまで影響する訳で
入れ物の階層毎に都度専用alloc/freeを用意するのが注意深いcデータ取り扱い方だとおもうよ

435:デフォルトの名無しさん
10/04/25 10:05:18
メモリを確保して返す関数は作るなって話か？
確保するメモリのサイズを事前に取得できない場合はどうすんのって話だな

436:デフォルトの名無しさん
10/04/25 10:14:03
専用reallocを用意するだけじゃないの？

437:デフォルトの名無しさん
10/04/25 10:23:15
とりあえず malloc して、そのポインタのアドレスを渡して、
関数内で realloc してもらうとか？

438:デフォルトの名無しさん
10/04/25 10:30:07
>>437
分けも分からずmalloc()する位なら、NULL使ってrealloc()の方がまし

439:デフォルトの名無しさん
10/04/25 10:35:23
それだと malloc/free の対応がとれないって主張なんじゃないの

440:デフォルトの名無しさん
10/04/25 10:43:30
>>439
必要なのはC++で言うnewとdeleteに対応するものであって
mallocとfreeではないと思うのだが？

441:432
10/04/25 10:45:57
>433

>strdupに対して、strdup_free()があれば良いだけで、

それがレベルを合わせるってこと。
strdupの中でmallocしていれば、strdup_freeで責任もってそれを解放する方が、コード上で
リソースバランスの確認ができる。

>組み合わせを間違えなければ、内部がどうなってようが、問題にならないと思うが…
内部を気にしたくないから、リソース管理の責任レベルを合わせたいってこと。

>435
>確保するメモリのサイズを事前に取得できない場合はどうすんのって話だな
必ずしも、同じレベルでそろえられないかもしれない。でも、大抵は設計が行けてないだけ。

少し話を戻して>432で
「名前の問題ではない」と書いたけど、リソース管理レベルの話題であって、名前の話ではないといういみであり、
人間がコードを書いている以上、リソース管理レベルは識別子で認識している。
従って、リソース管理レベルを意識していれば、名前もそうなるはず。

コード上で名前のバランスが取れていない場合、設計を疑った方がよい。

442:441
10/04/25 11:00:58
>426

>> >(1)の場合は、可変部の情報を含めサイズ情報を渡しません。
>> これは無理。
>いいえ。無理ではありません。
>例えば、関数内でrecv()を使ってネットワークからデータを受信する場合など、処理を完了して初めてデータのサイズが確定することがあります。

OK.あなたと私では、視点のレベルが違っていた。
私の視点は事前にサイズがわからない場合も、とりあえずバッファを用意しておいて、
読んでみないことには知りようがない、という意味だったのです。recvそのものの
レイヤーです。読んでみたあとはサイズがわかる、というのはそうですね。

議論はあくまでも一般論です。個別では理想的な実装ができないかもしれません。

余談ですが、メッセージループの処理ならば一般的には、下記のように書くと思います。
擬似コードです。

for (;;) {
　recvMsg(pMsg);
　/* メッセージに応じた処理 */
　freeMsg(pMsg);
}

これはメッセージを受けるところと、最後に解放するところでリソース管理レベルを
そろえています。

443:デフォルトの名無しさん
10/04/25 11:07:19
要するにコンストラクタとデストラクタを用意するみたいな感じにすべき、ということね？
まあその主張は分からんでも無い

444:デフォルトの名無しさん
10/04/25 11:10:13
>>441
>>strdupに対して、strdup_free()があれば良いだけで、
>それがレベルを合わせるってこと。
何か意図が違う気がする。
strdup()内でmalloc()を呼んでようが、さらに、strdup()で別の関数を呼んで
その中で、malloc()を呼んでようが、俺は気にしないって話だが合ってる？
strdup_free()に関しても、冗長になると分かってても実装して欲しと思うが、
最悪(本当に最悪だが)はdefineの定義するだけでも構わないと思ってるけど同じ？

445:351
10/04/25 12:24:26
>>442
>議論はあくまでも一般論です。個別では理想的な実装ができないかもしれません。

はい。そのとおりです。
ですが、その下の擬似コードは>>351の質問の意図を表していません。

>>351の質問の意図は、
recvMsg(), freeMsg()を使う関数を作るような場合を含めて、
一般的に
・関数から構造体を返す必要がある場合、何か基準や定石があるのかを知りたい。
・こういう時にはこうすれば良いという指針があれば知りたい。
ということです。

recv()とrecvMsg()-freeMsg()のどちらが一般的かという議論は今回の質問の中ではしていません。

446:デフォルトの名無しさん
10/04/25 12:29:35
>>445
構造体自体を返すだけなら free() はいらない。
でも >>351 のお題にあがっている構造体は、メンバに malloc() で得たポインタがはいっているので、
当然そのポインタを free() する必要がある。
一般化というが、上記のことだけ注意すれば OK なのでは。

447:デフォルトの名無しさん
10/04/25 12:30:02
>>351俺なら(1)だな。

さらに、（オーバーロードできるなら、C++なら同名で）
void delete_my_struct(struct my_struct **md) {
　delete_my_struct(*md);
　*md = 0;
}
とすらする。

448:デフォルトの名無しさん
10/04/25 12:32:34
>>447
Cでオーバーロードできる環境なんてあるのか？

449:351
10/04/25 12:36:38
>>446
つまり、構造体内部の後処理だけを関数で行えということなので、常に>>351の(2)が良いということですね。

>>447
どういう場合、>>351の(1)が良いですか？
基準があれば教えてください。

それとも、常に>>351の(1)が良いでしょうか？

450:デフォルトの名無しさん
10/04/25 12:51:51
>>448
いっけね。Cスレだった。C/C++かと思ってた。

>>449
基準も何も、(2)は俺にとって煩雑。
呼び出し元でmallocなりして、init_my_struct呼んで、
要らなくなったらrelease_my_struct呼んで、free呼ぶ。
呼び出し回数が多い。呼び忘れるのも怖い。

(1)ならcreate_my_structで生成と初期化を同時に行い、
delete_my_structで後片付けと削除を同時に行う。
呼び出し回数が少ない。余計な気を使わなくて良い。
create - deleteの対を分かって使えば良いだけ。

C++にしたってコンストラクタ以外に、
new後にinit()呼び出しを要する設計もあるが、
同じ理由で俺はそういうの嫌い。

メソッド間、関数間に呼び出し順の依存関係があると使いにくい。

451:デフォルトの名無しさん
10/04/25 13:33:21
>>351 は構ってちゃんだから、ﾏｼﾞﾚｽ禁止ね（＾o＾）ﾉ

452:デフォルトの名無しさん
10/04/25 13:54:52
>>351は常に(1)でいいよ。
ただし構造体のメンバにアクセスできないようにカプセル化したほうがいい。
ヘッダに

　 struct my_struct* create_my_struct(int param);
　 void delete_my_struct(struct my_struct* md);
　その他my_structを操作する関数のプロトタイプ宣言

を書いて、ソースのほうに

　 struct my_struct {
　　int size;
　　void *ptr;
　　int data[];
　 };
　関数の定義

を書く。

453:351
10/04/25 18:27:17
>>450
> 基準も何も、(2)は俺にとって煩雑。
>>452
> >>351は常に(1)でいいよ。

ありがとうございます。基本は(1)ということですね。

では、呼び出し元で構造体を格納したい場所が決まっている場合はどうすればいいと思われますか。

>>351の(1)の場合は、
呼び出し元で構造体のcretateを実行し、呼び出し元でその結果を構造体を格納したい場所にコピーしなければなりません。

>>351の(2)の場合は、
呼び出し元で構造体のinitに格納したい場所を指定して実行すれば、結果として格納したい場所に構造体が格納されるので、呼び出し元では改めてコピーする必要はありません。

この点で、やはり(2)は捨て切れません。
上位でどう使われるかわからない関数を設計する場合は、やはり(1)(2)の両方を用意したほうがいいでしょうか。

(1)(2)以外にうまい方法があれば知りたいところです。

454:デフォルトの名無しさん
10/04/25 18:51:27
>>453
自分で答え出してるじゃないか。まだ何か困ってるの？

455:351
10/04/25 18:53:31
>>454
はい。
>>453の一番最後の行に書きました。

456:デフォルトの名無しさん
10/04/25 19:30:23
>>455
へぇ。そこ読んでも俺には何に困ってるのかわかんないや。

457:デフォルトの名無しさん
10/04/25 19:34:52
>>351
何のために格納したい場所ってのが必要なのかわからんが、変な書き方するよりは
おとなしくコピーしたほうがいいかもね。

458:351
10/04/25 19:43:23
>>457
格納したい場所が決まっている状況というのは、
例えば、下記のようなコールバックハンドラーを実装する場合に、引数に格納するメモリー領域を渡されるような場合です。

int (*some_callback_handler)(char* buf, int buf_size);

パフォーマンスがそれほど要求されない場面では確かにコピーすれば解決なのですが、
そうではない場合もあるので、コピーの回数は減らせられるようにもしたいのです。

459:デフォルトの名無しさん
10/04/25 19:56:46
おかしいな、引数がヌルポインタかどうかで判断すればいいよっていうのはどうしちゃったんだろ。
reallocみたいな感じといえばいいかな

460:デフォルトの名無しさん
10/04/25 21:13:28
>>458
get_my_struct関数を作ってポインタを返して、そのポインタを使えばいいのでは。

461:351
10/04/25 21:24:14
>>460
構造体を格納したいポインタを知っているのは呼び出し側なので
get_my_struct関数を作っても仕方ないですよね？

462:デフォルトの名無しさん
10/04/25 23:54:00
まだやってんのか

こういうどうでもいい質問はOKウェブみたいな初心者向けQ&Aサイトでやればいいのに

463:デフォルトの名無しさん
10/04/26 00:03:24
>>462
それがこのスレさ

464:デフォルトの名無しさん
10/04/26 11:01:21
いや寧ろ、ここは>351みたいに捻くれた初級者向きじゃない。
いっそ小心者スレ辺りでやってほしい。

465:デフォルトの名無しさん
10/04/26 13:02:05
>>464
お前が童貞専用自慰スレに行けばいい

466:デフォルトの名無しさん
10/04/26 22:05:24
フローチャート記号の「準備」ってどうやって使うものなの？
変数の宣言というのがこういうので、この時に使う？↓
int　nurupo;
これは「処理」でいいよね？↓
int　nurupo = 1

467:デフォルトの名無しさん
10/04/26 22:14:54
int　nurupo = 1
が準備だな

処理に備えて初期化という準備をしているわけだし
変数宣言はフローチャートの中では書かないことが多い

468:デフォルトの名無しさん
10/04/26 22:52:29
会社で初期化と同時に代入書いたら
「こんな書き方見たことない、直せ！」と言われた。

469:デフォルトの名無しさん
10/04/26 23:02:07
初期化と同時に代入ってどうやるんだ

470:デフォルトの名無しさん
10/04/26 23:02:55
int i;
int j = i = 0;

こういうやつか
まあキモいな

471:デフォルトの名無しさん
10/04/26 23:03:11
>>469
語弊があって申し訳ないが、>>467みたいなやつ。

472:デフォルトの名無しさん
10/04/26 23:06:20
「初期化」と「代入」を勉強し直させるべきだな
つーか見たことない、って

473:デフォルトの名無しさん
10/04/26 23:08:35
宣言と同時に代入ってことか？

474:デフォルトの名無しさん
10/04/26 23:10:00
>>466
ソース読めば瞬間わかることを書いてはいけない
よく読まなければわからないことをアシストしてこそ意味がある

475:デフォルトの名無しさん
10/04/26 23:11:39
>>473
それを初期化と言う
まあ、初期化は代入ではないがな

476:デフォルトの名無しさん
10/04/26 23:26:20
初期化は代入じゃない？
int main(void) {int x = 5; return 0; }
なんかだと代入じゃない？

477:デフォルトの名無しさん
10/04/26 23:34:34
いいえ、初期化です

478:デフォルトの名無しさん
10/04/26 23:41:51
466だけど、アホ言ったみたいでほんとごめん。
もう少しグーグル先生で探してくる。プログラムって難しそうね。。
>>474
そういうものなのね。
じゃあ殆どつかわねーよ！という記号もあるとか？

479:デフォルトの名無しさん
10/04/26 23:46:14
auto 変数に初期化なんかあるのか？全部代入じゃないのか？
それとも俺の頭が古いのか？

480:デフォルトの名無しさん
10/04/26 23:58:19
>>479
古いんじゃなくて、最初からちゃんとした文法を覚えていないだけ。

481:デフォルトの名無しさん
10/04/27 00:01:05
>>480
static な変数に対する初期化は理解できるが、auto な変数に初期化という動作はあるのか

main() {
int x; /* 宣言 */
x = 1; /* 代入 */
}

をひとつにまとめものが
main()

482:デフォルトの名無しさん
10/04/27 00:01:46
int main() {
int x = 1; /* 宣言＆初期化 */
}
と思っていたのだが。

483:デフォルトの名無しさん
10/04/27 00:03:31
ごめんなさい。やりなおし。
main()
{
int x; /* 宣言 */
x = 1 /* 代入 */
}
をひとつにまとめたものが
main()
{
int x = 1 /* 宣言＋代入 */
}
だと思っていたのだが、規格はこれを初期化と呼んでいるのか？

484:デフォルトの名無しさん
10/04/27 00:11:39
>483

それは、初期化子付きの宣言。あくまでも宣言で、宣言+代入ではない。
式と宣言では文法が区別されている。

int a[] = {1, 2, 3,};
と書けるが
int a[10];
a[] = {1, 2, 3,};
とは書けないのは別物だから。

485:デフォルトの名無しさん
10/04/27 00:16:06
>>483
JIS X3010 6.7.8 初期化

486:デフォルトの名無しさん
10/04/27 01:11:59
>>481
途中で送信したとは思ったがシュール過ぎて笑った。

487:デフォルトの名無しさん
10/04/27 11:47:43
制御系プログラミングの初歩として、C言語（++ではない）のビット演算を勉強しています。
unsigned char型の変数を、二進数でバラして8個の0/1フラグとして使うための一番効率のよいやり方って何ですか？
一般的に使われるロジックとしては以下のメソッドのような感じでＯＫですか？

//引数srcのnビット目を0か1かで取り出す
unsigned char getNbit(unsigned char src,unsigned char n)
{
//srcと2のn乗（nビット目だけ1の値）と論理乗算して、0になったら0を返す。そうでなければ1。
if( src & (1<<n) == 0 )
{
return 0;
}
else
{
return 1;
}
}

//引数srcのnビット目に指定の値param(0/1)をセットした値を返す
unsigned char setNbit(unsigned char src,unsigned char n,unsigned char param)
{
//0をセットする場合、srcと2のn乗の値を反転した値(255-1<<n)とを、論理乗算する
if(param == 0)
{
return src & (255-1<<n);
}
//1をセットする場合、srcと2のn乗(1<<n)の値とを、論理加算する
else
{
return src | (1<<n);
}
}

488:デフォルトの名無しさん
10/04/27 11:54:37
ビットフィールドじゃあかんの？生成されるコードは汚いけど

489:デフォルトの名無しさん
10/04/27 11:58:10
二つ目はon/offで関数わけようぜ

490:デフォルトの名無しさん
10/04/27 12:00:41
IO操作するならビットフィールド使って、関数で隠蔽する

491:デフォルトの名無しさん
10/04/27 12:15:09
(255 - 1 << n) じゃなくて　~(1 << n)ってするのがビット演算らしい

492:デフォルトの名無しさん
10/04/27 12:34:18
__inline unsigned char getNbit(unsigned char src, unsigned char n) {
return src & (1 << n);
}

__inline unsigned char setNbit(unsigned char src, unsigned char n, unsigned char param) {
return src & ~(1 << n) | (!!param << n);
}

493:デフォルトの名無しさん
10/04/27 12:39:45
return (src >> n) & 1

494:487
10/04/27 13:33:20
皆さん、ありがとうございます。

>>490
まさにIO制御の学習です。
基盤にランプが8個乗っていて、指定のIOポート1つ(1バイト)に値をセットすることで点灯/消灯を制御するといった課題です。
ビットフィールドというのを調べてみます。

>>492
前者は、指定したビットが0のときは0が返るけれど、1のときは1<<nが返りますね。
それでも、このメソッドを使う際に、「0かそうでないか」という運用をすれば良いということですか？
JavaのbooleanやC#のbool型に慣れているゆえ、0か1かの戻り値にこだわらないといけないと思っていましたが、
Cの常識だとそうでもないという認識で良いですか？

後者は、「src & ~(1 << n) | (!!param << n);」の記述の意味を詳しく教えていただけると助かります。
「src & ~(1 << n)」の部分までは、「とりあえず指定ビットを0にする」というのは分かりますが、
その後、 !!とはどういう意味の記述なのでしょうか。

こういう短く基本的な処理を書くにはinlineにしたほうが高速なのですね。とても参考になります。

495:デフォルトの名無しさん
10/04/27 13:38:56
ビットフィールドの実装依存の部分からいってその用途には使えないんじゃないの？
パディングとか順番入れ替わるとかで

496:デフォルトの名無しさん
10/04/27 13:46:15
>>494
>>492の get の方は指摘の通りで、0, 1 に固定するなら(した方がいいだろうけど)、
return !!(src & (1 << n));
としてもいいが、それなら >>493 の方がいいね。

!! は ! を2回やってるだけ。 0なら0、0以外なら1にしたいときにやる常套手段。

497:デフォルトの名無しさん
10/04/27 14:15:09
>>487の判定文、演算子の優先順位をよく調べとけ

498:デフォルトの名無しさん
10/04/27 14:28:54
>>494
JavaでもC#でも0が偽というところは変わらんよ。
if (3)とかかけるでしょ

499:デフォルトの名無しさん
10/04/27 15:34:56
>>498 嘘

500:デフォルトの名無しさん
10/04/27 15:42:12
JARO

501:デフォルトの名無しさん
10/04/27 18:54:10
!!はキモいんだよなあ
好みの問題だろうけど
ちゃんと最適化されるかどうかは気になる

502:デフォルトの名無しさん
10/04/27 19:14:22
!!がいやなら!=0はどうよ？

503:デフォルトの名無しさん
10/04/27 19:20:04
>>485
なるほど、「静的記憶域区間」のみならず「自動記憶域区間」の場合であっても、初期化という言葉が適用されるのですね。
インプリメント上では単なる代入にすぎないものであっても。

504:デフォルトの名無しさん
10/04/27 19:53:57
C++で挫折してCに流れ着いてCの入門書読み終えたんですが、中級者になるために試したらためになる演習課題とかありませんか
たぶんメモ帳とか作る場合GUIとか使わないとならないんですよね？できたらヒント付きで教えてくれませんか？

505:デフォルトの名無しさん
10/04/27 19:54:16
>>502
俺は基本そうしてる
if文に直接書く時はそれすら書かないけど

506:デフォルトの名無しさん
10/04/27 19:55:02
>>504
CUIで作れるような簡単なゲームでも作るといいよ
俺はいつもヒットアンドブローを作るようにしている

507:デフォルトの名無しさん
10/04/27 22:01:56
構造体のメンバに順次アクセスする
ナイスな方法ってある？

508:デフォルトの名無しさん
10/04/27 22:10:36
char*でキャストして、1バイト毎に順次アクセスする

509:デフォルトの名無しさん
10/04/27 22:14:11
メンバの位置や型を配列にして保存しておいて
それでループでアクセス

まあ普通そんなことやるなでFAだが

510:デフォルトの名無しさん
10/04/28 15:43:35
>>507
unionを使うのが一番楽で上品

511:デフォルトの名無しさん
10/04/28 16:33:51
>>510
順次アクセスという言葉の意味がわかってないだろ
馬鹿は黙ってればいいのに

512:デフォルトの名無しさん
10/04/28 17:14:46
順次アクセスできない理由を教えてくれ天才

513:デフォルトの名無しさん
10/04/28 19:37:37
>>511
こういう感じでいけるっしょ。
typedef struct {
int a;
int b;
int c;
int d;
} hoge_t;

typedef union {
hoge_t u;
int l[4];
} chinko_t;

514:デフォルトの名無しさん
10/04/28 19:38:41
あ、int l[0] にしといた方が便利がいいな。

515:デフォルトの名無しさん
10/04/28 20:07:29
アラインメントが気になる
同じ型ならまず問題は無いだろうが、万が一があるしな

516:デフォルトの名無しさん
10/04/28 20:14:52
メリット皆無だし。

517:デフォルトの名無しさん
10/04/28 20:16:54
>>515
それを言い出したらそもそもunionの存在そのものが怖いよな。

>>516
誰もメリットの話なんかしてねーだろ

518:デフォルトの名無しさん
10/04/28 20:26:35
添え字でアクセスしたいだけなら
#define STFX(N,V) switch(N){case 0:struct.a=V;break;case 1:～}
で十分だし。

519:デフォルトの名無しさん
10/04/28 21:01:43
おいおい今日もまたＣの連中はつまんねえことでもめてるよｗｗ

520:デフォルトの名無しさん
10/04/28 21:10:53
>>519
だよな、時代はD言語だろうに老頭児なC厨はオナニーでもしてろってのｗ

521:デフォルトの名無しさん
10/04/28 21:12:26
これだからC厨は・・・

522:デフォルトの名無しさん
10/04/28 21:12:59
D(笑)

523:デフォルトの名無しさん
10/04/28 21:14:18
おじいさまがたはFORTRANでも使っててください

524:デフォルトの名無しさん
10/04/28 21:14:28
老頭児って中国語か

525:デフォルトの名無しさん
10/04/28 21:18:30
おじいさまがたは LISP でも使ってください、
ん？

526:デフォルトの名無しさん
10/04/28 21:24:39
>>523,525
すまん、俺まだ20代だが両方とも会社で使ってるw

527:デフォルトの名無しさん
10/04/28 21:32:21
LISPは未だに超強力だからな。まあWindowsアプリに限って言うならC#の時代が来るかもしれない。囲い込みだしな
でもプログラムはWindowsアプリだけじゃないし、つーかDって誰が普及させるんだよｗ
世界中で使われてるCの牙城を崩す気ねーだろ
あとWebプログラミングのLLはこれからも生き残る

528:デフォルトの名無しさん
10/04/28 21:35:21
LISPはemacsとかあるからまぁ使う機会はそこそこあるかもしれんが
FORTRANを使う場面はまったく思い浮かばん
昔大学で実験に使って以来やってないから、もう文法もわがんね

529:デフォルトの名無しさん
10/04/28 21:49:20
順次アクセスとかそんなイレギュラーな使い方は普通しないし。

530:デフォルトの名無しさん
10/04/28 22:02:10
Fortranは大学ではまだつかってるところあるけど
Ｌｉｓｐってemacsのマクロくらいしかないよ

って書こうとしてリロードして>>528を読んだ
たぶんほとんど同じものを見たのに出した答えが真逆で面白いなと思った

531:デフォルトの名無しさん
10/04/28 22:25:40
構造体の入れ子ってあまりよくないことなんでしょうか？（設計に問題あり？）

532:デフォルトの名無しさん
10/04/28 22:27:57
別に普通

533:ノラ
10/04/28 23:55:51
いま学校の課題で
do-while文を使って
１＋２＋３・・・というように数値を加算して表示し、
加算結果が３００を超えたら表示して
処理を終了するというプログラムを組みたいのですが、
普段から授業ついていけなくて、よくわかりません
どなたか教えてください。お願いします

534:デフォルトの名無しさん
10/04/28 23:57:45
>>533
ここは入門スレなのであまり高度なことはお答えできません。

535:ノラ
10/04/29 00:00:38
>>534
どうしたらいいですか？

536:デフォルトの名無しさん
10/04/29 00:02:05
中学校の課題？

537:ノラ
10/04/29 00:03:53
>>536
いえ専門なんですが
全く授業についていけなくてですね・・・

538:デフォルトの名無しさん
10/04/29 00:03:56
>>535
ｽﾚﾘﾝｸ(tech板)

こちらへどうぞ

539:デフォルトの名無しさん
10/04/29 00:04:27
#include <stdio.h>

int
main(void)
{
　 int i = 1;
　 int sum = 0;

　 do {
　　 sum += i++;
　 } while (sum < 300);
　 printf("%d\n", sum);

　 return 0;
}

540:デフォルトの名無しさん
10/04/29 00:04:29
そういうときは美味しいカレーのレシピを書いて提出だろう

541:ノラ
10/04/29 00:12:06
>>539様ありがとうございます。
参考にしてがんばってみます

542:ノラ
10/04/29 00:14:24
>>539
sum入れないでもできますか？

543:デフォルトの名無しさん
10/04/29 00:16:16
ついていく気は無いようだｗｗｗ

544:デフォルトの名無しさん
10/04/29 00:24:11
>>542 自分でやれよカス

545:デフォルトの名無しさん
10/04/29 00:52:38
>>542
#include <stdio.h>

int
main(void)
{
int i = 1;
do {
printf("%d\n", i * (i + 1) / 2);
i++;
} while (i * (i + 1) <= 600);
return 0;
}

546:デフォルトの名無しさん
10/04/29 00:55:13
>>542
結果を格納しておく変数が必要なわけ。
加算していって、それをどこに保持しておくの？って話になるでしょ？

だから、この場合は「sum」っていうｙ変数に入れてる。
別にgoukeiでもsでも、C言語の規則に従ってればなんでもいい。

547:デフォルトの名無しさん
10/04/29 00:55:55
>>545
綺麗だけど初心者には分かりづらいソースだなｗｗｗｗｗｗｗｗｗｗ

次ページ