2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

構造体コピーのバカ〜

1 :デフォルトの名無しさん:03/01/16 21:30
struct abc {
int a;
int b;
};
void main()
{
struct abc obj1, obj2;
obj1.a = 10;
obj1.b = 20;
obj2 = obj1; ←☆コレ!!★
}
「コレ」って、昔から出来て当たり前なの?!
なんか、私の中では、5〜6年位昔、使えなかった記憶がありまして、
それで、コンパイラがバージョンでも上がったかと
考えていたんですが、最近それを話したら、「そんなの昔から出来てあたりまえ!」って。。
これは「Cの歴史開闢以来の常識!」なのか、「とちゅ〜で使える様になったのよ」
なのか、はっきり知りたいです!賢者(てゆ〜か昔からやってた)皆様、ヘルプミー!
(文献なんかもあるといいです〜)


2 :デフォルトの名無しさん:03/01/16 21:32
2取れたら1が好きな人に告白する!

3 :デフォルトの名無しさん:03/01/16 21:32
バカ〜

4 :デフォルトの名無しさん:03/01/16 21:32
ハァハァ。。。
て、て××さぁ〜ん!(告白)

5 :デフォルトの名無しさん:03/01/16 21:44
4年続いたヒカルの碁も、そろそろ終わりか。
6色に増えたけど、事実上5色だし。
次はグリーンがいいなーとおもったが、ミドレンジャーみたいに
マイナーになりそうだよね。


6 :デフォルトの名無しさん:03/01/16 21:55
>>1
>「構造体コピー」
アフォさらすな。

7 :デフォルトの名無しさん:03/01/16 21:59
>>4
て××

照子に一票。

8 :デフォルトの名無しさん:03/01/16 22:03
俺はてるみに1票

9 :デフォルトの名無しさん:03/01/16 22:05
・・・てるお?

10 :デフォルトの名無しさん:03/01/16 22:05
てんぐだろ。

11 :デフォルトの名無しさん:03/01/16 22:06
>8
ケコーンしろ

12 :デフォルトの名無しさん:03/01/16 22:08
てxx
http://members.aol.com/tennenmario/


13 :デフォルトの名無しさん:03/01/16 22:36
スレタイが微笑ましくて見てしまったがクソスレか

14 :デフォルトの名無しさん:03/01/16 22:50
てるくはのる
かな?

15 :デフォルトの名無しさん:03/01/16 23:01
>>1 こういうことはC言語のスレッドで質問しろ
いちいちスレ立てるな

16 :デフォルトの名無しさん:03/01/16 23:01
俺が出来るように頼んどいたんだよ。
感謝しろよ。ったく・・・・

17 :デフォルトの名無しさん:03/01/16 23:04
>>16
クソスレアゲる人には感謝しません

18 :1:03/01/16 23:05
自己れすですが。さっき発見しました。
> と書けば済むのですから。ただし、ANSIに準拠していない一部のコンパイラの中には、構造体の代入を許さないものもあります。
>そのようなコンパイラを使う場合には、memcpyを使ってコピーする必要がある場合もあります。
http://www.st.rim.or.jp/~phinloda/cqa/cqa14.html
このコンパイラって、どのコンパイラ!?情報求む!!

>>15 すんまそん。
>>16 ありがと〜(藁


19 :デフォルトの名無しさん:03/01/16 23:05
昔はできなかったような気がするな
今じゃ構造体の引数もコピー渡しできるらしいな

20 :1:03/01/16 23:10
>>19 をを、その様な記憶がございますか!?
当時、どの様な環境で、どのようなコンパイラをお使いでしたか?
よろしければ、参考までにお教え下さいませ(_ _

ちなみに私は、DOSで、マイクロソフトのクイックCを使ってましたが。。。
これだったかどうだか、記憶にないです。くやし〜。


21 :デフォルトの名無しさん:03/01/16 23:12
>>20
K&R Cはできなかったんだよ。
バカ、低脳。

早く氏ね

22 :1:03/01/16 23:17
>>20
>K&R Cはできなかったんだよ。
>バカ、低脳。

>早く氏ね
をを、マジっすか!?
すばらしい情報をありがとうございました!
(一応裏取ろっと。)


23 :19:03/01/16 23:54
DOSのころだからよく覚えてないな
Whitesmith C
MS-C

だったかな

24 :1:03/01/17 00:17
>>21 さんの情報を元に検索したところ。。。
>K&R第1版とANSI Cの仕様において異なるもののひとつとして構造体の扱いがあります。
>K&R第1版のころの仕様では構造体の直接代入を認めていなかったので,
>List 7の最終行のようにmemcpyなどを使ってコピーをしたものです。
http://www.cmagazine.jp/src/kinjite/c/oldstyle.html#index7

これだけ情報があれば・・・。
もぅこうなったらK&Rの本を探しに、古本屋に逝ってきます。


>>23 情報ありがとうございます!
Whitesmich Cも、MS-Cも、
どっちも使った事無いです。
たしかMS-Cって、クイックCの上位版でしたよね。
これらが、ANSIでなくてK&R準拠かどうか、しらべてみます。


25 :デフォルトの名無しさん:03/01/17 01:30
話題がまったく広がらない単発質問でスレを立てないでください。

祝49回 C言語ならあっしに聞け
http://pc3.2ch.net/test/read.cgi/tech/1042640474/

26 :デフォルトの名無しさん:03/01/17 02:17
>>4
徹子に一票(藁

27 :デフォルトの名無しさん:03/01/17 02:44
ん。
俺も最近気がついたよ。構造体のコピー(藁
律義にCopyMemory使ってたんだ。

あっはっはぁー



28 :デフォルトの名無しさん:03/01/17 03:57
>>1
正直、あっても無くてもどうでもいい機能だけどな。

29 :1:03/01/17 08:52
>>27
あぁ同士(涙)C歴の低いプログラマは、平気で、
「構造体コピーなんてC言語開闢以来最初からできてたっつ〜の」
と、知ったかぶりでのたまうのでムカつきます。

>>28
まったくもってその通り(笑)
今回の質問は、C+で「イコール演算子のオーバーロード」を使う時、
独自の処理がいらないならわざわざオーバーロードしなくても、
「obj2 = obj1;」みたいにインスタンス間コピーできるから、
まぁ必要じゃないなら作らなくてもとりあえず動くよ。という課題が原因で出てきました。
このとき私は、「Cの構造体ではもともと無理だしな〜」と思い込んでいました。
んで、VC++6で構造体コピーを試すと、ふつ〜に動いたので、
「いったい何時から出来る様になったんだ〜」と思い立った次第でした。
しかしハッキリしました。書き込んでくれた方々には、本当に感謝しておりますです。ハイ。

>>25
貴方、15?すんまそん(2回目)。次の質問はそこでします。


さて、もう見てないだろうけど、
>>6
>>「構造体コピー」
>アフォさらすな。
結果的に、お前がオフォさらしたな(藁
己の狭い見解で他人をアフォ呼ばわりするお前がアフォだよ(藁

30 :デフォルトの名無しさん:03/01/17 09:17
1さんへ
一度
http://www.taisei-e.co.jp/seikaku/sin-d.htm
http://www02.so-net.ne.jp/~west/mind/seikaku/

を試して、その結果を貼り付けてみて下さい。
どのような性格の方なのか興味があります。

31 :デフォルトの名無しさん:03/01/17 09:33
なんか、>>29が1かどうか知らないが、

さっそく同僚や後輩集めて得得として語ってる1が目の前に見えるようだ。

騙り手ならスバラシイ技術であると、そしてマジに1なら・・・・あんたもあさましすぎないか?

32 :デフォルトの名無しさん:03/01/17 10:58
ANSIドラフト(1988)の段階で構造体のコピー(構造体を返す等)はできてるのに。
1みたいなのが「化石」と呼ばれてるんだろうな。

前も、strftimeを汎用性のないラッパー関数と切り捨てて
gettimeofdayを使えって奴が。
20年前ならいいけどさ。

33 :デフォルトの名無しさん:03/01/17 11:36
ところで、昔、DOSでTurboCやTurboC++を使ってた頃の構造体コピーって
memcpyと同じ全ビットコピーだったと思うんだけど、
今のBCCは各メンバ毎にコピーしてるっぽい。
これってコンパイラ次第?仕様が変わった?C++だから?

34 :デフォルトの名無しさん:03/01/17 11:43
>>33
バイト境界がどうたらこうたら何でしょうかね?


35 :デフォルトの名無しさん:03/01/17 12:44
>>33
コンパイラ次第だと思う。
ていうか、構造体のメンバーが
かならず連続したメモリに来るわけじゃないとか
なんかそういうオプションがあったりなかったり

36 :デフォルトの名無しさん:03/01/17 12:51
構造体なんてクラスのまがい物をつかわず

ク ラ ス を 使 え 、 ク ・ ラ ・ ス を

そしてコピー関数をクラスの中に実装しろ
コピーコンストラクタかJavaのcloneメソッドみたいなものを実装しろ

37 :デフォルトの名無しさん:03/01/17 16:01
>>36
実装部はどうなんの?
同じじゃないの?

38 :デフォルトの名無しさん:03/01/17 17:21
>>36
クラスが構造体で出来てるんだけどね。

39 :デフォルトの名無しさん:03/01/17 20:12
C++などいらん C99で十分だ。

40 :デフォルトの名無しさん:03/01/17 20:42
>>29
>結果的に、お前がオフォさらしたな(藁
>己の狭い見解で他人をアフォ呼ばわりするお前がアフォだよ(藁

ろくに勉強もしないやつがよくいうよ(藁
いつも勤勉であれ。


41 :デフォルトの名無しさん:03/01/17 21:11
>>40
自己啓発ですか?

42 :デフォルトの名無しさん:03/01/18 01:12
>>39
C99って何?

43 :デフォルトの名無しさん:03/01/18 01:14
>>42
1999年に制定されたC言語の新しい仕様。

44 :デフォルトの名無しさん:03/01/18 01:15
クソスレを、上げるな。
Cスレへ行け。

45 :デフォルトの名無しさん:03/01/18 01:15






   単   発   ス   レ   は   放   置





46 :デフォルトの名無しさん:03/01/18 01:16






   単   発   ス   レ   は   放   置






47 :デフォルトの名無しさん:03/01/18 01:16






   単   発   ス   レ   は   放   置






48 :デフォルトの名無しさん:03/01/18 01:17






   単   発   ス   レ   は   放   置






49 :デフォルトの名無しさん:03/01/18 01:17






   単   発   ス   レ   は   放   置






50 :デフォルトの名無しさん:03/01/18 01:17
>>42
Cの規格

51 :1:03/01/18 01:45
30>> やってみました。結果は「貴方のタイプはaabab です」でした。さて。

32>>
>ANSIドラフト(1988)の段階で構造体のコピー(構造体を返す等)はできてるのに。
>1みたいなのが「化石」と呼ばれてるんだろうな。
そう、そういう情報を求めてました。ありがとうございます。
おかげで「化石」を脱出できましたよ。コンパイラの歴史もまとまってきたし。。。
ちなみに今回のはあくまで論文目的であって、
「構造体o2 = o1は使えないコンパイラがあるから使うな」なんて主張してませんのであしからず。

>>31
>さっそく同僚や後輩集めて得得として語ってる1が目の前に見えるようだ。
をしい、得々として語る場があるのは一ヶ月以上先の予定です(藁
いや〜正直楽しみです(藁

>騙り手ならスバラシイ技術であると、そしてマジに1なら・・・・あんたもあさましすぎないか?
あ、本人ですよ。まだ一度も騙られてないです。って書いてもわからないししょうがないか。
「氏ね」とか混ぜずに冷静に答えてくれてありがとうございます。そう、おっしゃるとおり浅ましいですな。反省はしないけど(藁

>>40
>ろくに勉強もしないやつがよくいうよ(藁
>いつも勤勉であれ。
6には、どうしても言いたかったのよ!なにせ私は、aababだし(藁


52 :27:03/01/18 03:37
まあ、>6はただの煽りだろ。
Cの仕様の変移を把握してるヤツなんてかなりの強者。
つか、仕様書を持ってるヤツこそCを語る資格があるね。
K&R程度の本を読破しただけで知ったかぶってるヤツはイタイな。

とまあ、俺は強者になれないのだが。



53 :デフォルトの名無しさん:03/01/18 03:58






   単   発   ス   レ   は   放   置






54 :デフォルトの名無しさん:03/01/18 04:51
で、構造体のワード協会って
アライメント? バウンダリー?
どっちの用語が正解なのよ

55 :デフォルトの名無しさん:03/01/18 06:52
オブジェクトコピーのバカ〜

56 :C++厨:03/01/18 13:54
>>1
え?

57 :デフォルトの名無しさん:03/01/18 23:42
>>37-38 カプセル化しないと気持ち悪いだろ。それだけです。



58 :デフォルトの名無しさん:03/01/20 03:19
>>57
いいよ。面倒くさいし。
名前が漏れないようにソース単位でもっとけばいいじゃん。

59 :デフォルトの名無しさん:03/01/20 04:30
>>54
68000 の場合、通常は構造体のメンバのアライメントは
デフォルトでダブルワードバウンダリーとなる。てな具合だ。


60 :デフォルトの名無しさん:03/01/20 04:59






   放   置   ス   レ   は   単   発






61 :デフォルトの名無しさん:03/01/20 22:41
>>59
用語の使い方は合ってるが、68000 は外部データバスが 16bit なので、ワードバウンダリで十分だよ。

62 :デフォルトの名無しさん:03/01/21 13:19
>>54
Microsoft Word Association of Structures

大きな組織内で、ライセンスの高いMSワードをいかに効率的に
使うかということを研究するためにつくられた非営利団体。

通称 MSWAS (エムエスワス)または単に WAS (ワス)
と呼ばれている。


63 :前に実験したことあるんですが:03/01/21 16:09
>1さん
面白い話題ですね。
まぁ、普通問題になることはありませんが、
struct=structと書いた場合より要素ごとに代入するほうが
微妙に早いことが多いです。(VC6/Release素オプション)
対象の構造体の深さや構造にもよるんですが、struct=structと書いた
場合ループを組んだコードを吐くことが多いようで、最近の
プロセッサだと並列に並べられる命令が連続してること多いほうが
効率上がるせいでしょか。

うちでやってるアプリは特殊だからまぁ大したことじゃないんですが。


64 :デフォルトの名無しさん:03/01/21 22:15
>>63
> 場合ループを組んだコードを吐くことが多いようで、

rep のことか ?

65 :デフォルトの名無しさん:03/01/21 22:42
単発スレ立てて、しかも誘導されているのに未だに無視。
なんか>>1にものすごい腹が立つ。

66 :デフォルトの名無しさん:03/01/22 14:08
構造体ってメモリ上に連続してるの?
そういう保証ってあるんだっけ?
確か、コンパイラによっては
保証する/しないのオプションがあったとおもうけど
デフォルトは保証するの方なのかな
でも、穴だらけの構造体定義するバカとかいるけど
コンパイラの最適化でホールを埋めるように
要素の並び替えとかするのかな?

67 :デフォルトの名無しさん:03/01/22 14:13
>>58 その構造体変数に代入すべき定義域を限定できないではないか

68 :デフォルトの名無しさん:03/01/22 15:10
>>66
メモリ上に連続して無いとmallocもcallocもできないでつ。

69 :デフォルトの名無しさん:03/01/22 15:15
構造体の初期化で
gccは独自拡張で要素直指定で値を入れて初期化できるけど
ほかのだとどうなのかな

70 :デフォルトの名無しさん:03/01/22 15:24
>>69
本当に聞きたいのなら他スレに行きましょうね。

71 :デフォルトの名無しさん:03/01/22 18:51
>>1
かなり前からできる。

が、できないと思っていた君のセンスは
そう悪いものでもない。

72 :デフォルトの名無しさん:03/01/22 19:07
>>66
保証されないんじゃない?
スタック上に取った場合最適化でメンバー消滅とかありうるし

73 :デフォルトの名無しさん:03/01/22 19:10
必死にあげてる>>1は何をしたいんだ?

74 :デフォルトの名無しさん:03/01/22 23:50
>>66
> コンパイラの最適化でホールを埋めるように
> 要素の並び替えとかするのかな?

やらない。と言うか、規格上やってはいけない。

75 :デフォルトの名無しさん:03/01/23 16:52
VC++でコンパイルし直したらに構造体のサイズが変わった覚えがあるなぁ
(sizeofで調べた)

76 :山崎渉:03/01/23 20:03
(^^)

77 :デフォルトの名無しさん:03/01/24 00:12
>>75
アラインメント

78 :デフォルトの名無しさん:03/01/25 02:59
つまり、アーキテクチャは同じでもコンパイラによって
アライメントが違うということ?

そういえばgccだとアライメントを変更する機能があるね
そういうことなのか

79 :デフォルトの名無しさん:03/01/25 04:21
昔よく、4バイト境界になるように
char RFU[3];
とかやった気がする…。

80 :デフォルトの名無しさん:03/01/25 04:32
誰も >>68 に突っ込まないの?

81 :まとめ:03/01/25 04:56
アラインがどうなるかは実装依存だが、基本的にはアーキテクチャ依存。
構造体のメンバは(少なくともCでは)宣言された順に並んでいる。
構造体コピー時に詰め物をコピーするかは実装依存。
構造体のsizeofは詰め物を含んだサイズを返す。

82 :デフォルトの名無しさん:03/01/25 09:22
>構造体のメンバは(少なくともCでは)宣言された順に並んでいる。
これは処理系依存だったような
手元のCコンパイラは全て問題ないけど


83 :デフォルトの名無しさん:03/01/25 09:51
規格は知らないが、手元にあるK&R第二版91刷P265によると
> 構造体のメンバーは、宣言の順序に増えていくアドレスを持つ。
とある。
ドラフト段階とはいえ、ANSI/ISO-Cも同じだと思うのだが。

84 :82:03/01/25 10:10
すみません
処理系依存はビットフィールドだけみたいですね


85 :デフォルトの名無しさん:03/01/25 10:10
>>81
少なくとも、処理系のフェッチのビット幅と、それに満たない
型の順列が、処理系のエンディアンの影響を受けるハズだが。

例えば、32ビット処理系で、アラインメントにあうように
構造体に char[4] を組み込んだとき、アドレス空間のどっち
側に配列の先頭がくるかということだけど。

86 :デフォルトの名無しさん:03/01/25 10:19
>それに満たない型の順列
意味不明。

>構造体に char[4] を組み込んだとき、アドレス空間のどっち
>側に配列の先頭がくるかということだけど。
&char[0] + 4 == &char[4]
ですが。

87 :デフォルトの名無しさん:03/01/25 10:20
ちなみにビットフィールドはアドレスをとれないので
並び順自体意味を持たない(ここにアクセスするか全体をコピーするしかない)

88 :デフォルトの名無しさん:03/01/25 10:26
>86補足
> &char[0] + 4 == &char[4]
ポインタに対する"+"がアドレス値に対しても"+"なのかは知らないが、
"+"を用いると配列において"後"の要素を指すことは規定されている。

89 :デフォルトの名無しさん:03/01/25 18:12
>>81
なかなかいいまとめ方だな。

90 :デフォルトの名無しさん:03/01/25 19:02
戦争にいってきてよかですか?
日本を守ってよかですか?

91 :デフォルトの名無しさん:03/01/25 19:03
天皇陛下万歳!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
天皇陛下万歳!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
天皇陛下万歳!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
天皇陛下万歳!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
天皇陛下万歳!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
天皇陛下万歳!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
天皇陛下万歳!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
天皇陛下万歳!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
天皇陛下万歳!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
天皇陛下万歳!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
天皇陛下万歳!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
天皇陛下万歳!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
天皇陛下万歳!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
天皇陛下万歳!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
天皇陛下万歳!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
天皇陛下万歳!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
天皇陛下万歳!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
天皇陛下万歳!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
天皇陛下万歳!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
天皇陛下万歳!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
天皇陛下万歳!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
天皇陛下万歳!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


92 :デフォルトの名無しさん:03/01/25 23:02
>>1
はるひこの糞本でも載っているぞ

93 :デフォルトの名無しさん:03/01/27 13:36
>>78
VC++はオプションでアラインメント指定ができる
が、指定したからといってコンパイル結果が同じになるわけじゃない
オプション変えずにコンパイルしなおして構造体のサイズが変わったことがある

94 :デフォルトの名無しさん:03/01/27 20:18
>>93
詳細きぼーん。

95 :93:03/01/27 20:45
>>94
メンバの並びが変わるわけではないので
sizeof()で取ったサイズでmemcpy()しても問題ないと思うが
ファイルに構造体のバイナリ直書きするとかはマズイだろう(ソースをコンパイルし直した場合を考えると)

経験的な知識ですまんが、メンバとしてcharとかshortとかを並べるときは
8バイト境界までパディングした方がVC++では無難と思われ


96 :デフォルトの名無しさん:03/01/27 21:57
>>95
だから...

> (ソースをコンパイルし直した場合を考えると)

の場合に、どうまずいのかが知りたい。

> 8バイト境界までパディングした方がVC++では無難と思われ

まさかと思うが、#pragma pack() は知ってるよな。

97 :デフォルトの名無しさん:03/01/27 22:01
移植が面倒になるので入出力はバイトストリームでやってほしいところ
#pragma packはDLL等で言語境界を跨ぐときに有用


98 :デフォルトの名無しさん:03/01/28 02:02
>>96
> >>95
> だから...
> > (ソースをコンパイルし直した場合を考えると)
> の場合に、どうまずいのかが知りたい。

コンパイルするごとに構造体のサイズが変わる可能性があるの
だからファイルに構造体のサイズつかってバイナリ直書きするとかはマズいの
書き込み位置がずれるとかの危険があるだろ
んなアフォはおらんと思うが

> まさかと思うが、#pragma pack() は知ってるよな。

#pragma packがあるくせに、コンパイル・オプションの設定次第でで構造体サイズに
さらに影響出る場合があるから気をつけろといってるの
さらにそういった現象は再現性はないってのが経験的にわかってるの


#pragma packなんぞに頼るコードも書くべきでないの

99 :デフォルトの名無しさん:03/01/28 03:51
>>95
メンバの並びって絶対保証されてたっけ?
微妙に(オプションによって)保証してない環境も
見たことあるような気がする。

パディングした方がいいというあたりは激しく同意

100 :デフォルトの名無しさん:03/01/28 03:59
>>99
メンバの並びを規定していたと思う

101 :デフォルトの名無しさん:03/01/28 04:08
>>100
そうなのか
モー娘。もメンバの並びを規定してた気がするけど
多分おなじ理由だね

102 :デフォルトの名無しさん:03/01/28 04:15
パディングはやってもいいけど、順番は変えちゃダメ、だったと思う

103 :デフォルトの名無しさん:03/01/28 04:24
どう言う事?

>>93
>オプション変えずにコンパイルしなおして構造体のサイズが変わったことがある
>>95
>コンパイルするごとに構造体のサイズが変わる可能性があるの
の文面から、コンパイル時のオプションが同じでも
構造体のサイズが変わる事があると取れるけど

>>95
>#pragma packがあるくせに、コンパイル・オプションの設定次第でで構造体サイズに
>さらに影響出る場合があるから気をつけろといってるの
も考えると#pragmaを使わなければ、オプションが同じでもサイズが変わる事があるし
#pragmaを使ってもサイズが変わる場合があるって事?

普通はオプションやコンパイラに関係なく構造体のサイズを合わせるために
#pragma packを使うのだと思うけど…

104 :デフォルトの名無しさん:03/01/28 04:59
どっちか片方だけpackしてもしょうがない

105 :デフォルトの名無しさん:03/01/28 06:31
構造体のポインタ

106 :19:03/01/28 13:13
>>103
> >コンパイルするごとに構造体のサイズが変わる可能性があるの
> の文面から、コンパイル時のオプションが同じでも
> 構造体のサイズが変わる事があると取れるけど

そういうことがあったんだよ実際

28 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)