12/12/14 09:12:48.84
URLﾘﾝｸ(msdn.microsoft.com)
P は "ポインター (pointer)"、LP は "ロング ポインター (long pointer)"
の略として使われてきました。ロング ポインターはファー ポインター (far
pointer) とも呼ばれますが、16 ビット Windows の名残で、現在のセグメント
の外にあるメモリ範囲をアドレス指定するのに使用されていました。LP プレ
フィックスは、16 ビットのコードを 32 ビット Windows に簡単に移植できる
よう、予約されていました。現在ではこの区別は存在せず、単にポインターと
呼ばれています。
73:デフォルトの名無しさん
12/12/14 09:14:13.28
>>71
far pointerはsegment16bit * 16 + offset16bitで20bit(1MB)のメモリ空間を表すもの。
74: ◆QZaw55cn4c
12/12/14 09:40:06.25
>>73
しかしリアルモードではCPU 自身がセグメントを16ビット、オフセットを16ビットと持ち、12ビット分を重ねるのはCPU内
したがって記述レベル、たとえばアセンブリ言語で記述するときもセグメント、オフセットそれぞれに word=16bit の領域を準備することが多い
大概のC処理系でもそう。(sizeof(void far *) = 32)
75:デフォルトの名無しさん
12/12/14 10:11:41.90
>>74
同じことしか言ってないように見える
最後4だし
76:デフォルトの名無しさん
12/12/15 08:37:43.76
>>73
long pointer は FAR で定義されている
FAR を far で定義するか空定義にするかは環境次第
77:デフォルトの名無しさん
12/12/15 09:09:59.58
farなんていうのは16bit x86（16bit プロテクトモードを含む）の
化石だよね。だから>>74がリアルモードに限定しているのは間違い。
16bit x86の設計は8bitCPU8080のコードをポーティングしやすくする
ためにアドレス空間も8080と同じ64KBを基本とした。
この範囲のプログラムはポインタも16bitで良かった。
だが時代が進みコードサイズが爆発的に増えた結果、オフセット
だけでは不足してきたので、セグメントとペアで扱うことにした。
だがC言語的にはポインタはポインタでしかないので、ポインタが
アドレス可能な範囲は実装依存だった。
でもオフセットのみのポインタとセグメントとペアのポインタは区別して
扱わないと開発上問題になる。そこで予約語farを定義して、farがつく
ポインタはセグメントとペア、それ以外はオフセットのみと定義すること
にした。
一般的にはfarのつくポインタだけをセグメントとペアのもの、つかない
ポインタはオフセットのみという認識だが、あえて両者を区別しやすく
するという意味でオフセットのみのポインタを「nearポインタ」と呼ぶ場合
もある。でも今となっては用済みのテクノロジでどうでもいいヨタ話。
78:74 ◆QZaw55cn4c
12/12/15 09:12:44.43
>>77
概ね同意です。
79:デフォルトの名無しさん
12/12/15 09:29:44.69
ヨタついでにもう１つ。
昔の16bit x86用Cコンパイラには「メモリモデル」なるものが存在した。
詳しい話は英文だけど
URLﾘﾝｸ(www.c-jump.com)
このへんを参照。
んで、開発を始める前にプログラム規模をまず見積もり、メモリモデル
のどれを採用するかを慎重に決める必要があった。なぜなら途中から
メモリモデルを変更するとコード全体に波及する可能性があったから。
大抵のプログラムでは単一コードセグメント、単一データセグメントで
間に合うものだったが、後々の保険にということで複数セグメント前提
にしてポインタを全部farにする、なんていう「大は小を兼ねる」判断も
行われていた。
80:デフォルトの名無しさん
12/12/15 09:47:22.53
MS-DOS陣営と違い意外に知られていないが、Mac-OSも680x0の時代は
32KBのコードリソースに入るサイズで切り分ける必要があった。
コードリソースと言う制約自体はMac-OSをベースにしていたPalmOSにも受け継がれた。
81:デフォルトの名無しさん
12/12/15 09:51:36.83
32KBのコードリソースっていうのはおそらくMC680x0における
ショートジャンプ（PC相対とかレジスタ相対ジャンプ）の範囲で
おさめるための策だと思われる。
時代背景から考えて現実的とは言えるけど、単なるウィンドウ
システム側の制約なだけ。MC680x0はリニアなアドレス空間で
16MBまでアクセスできた。
82:デフォルトの名無しさん
12/12/15 10:41:58.36
LPは16-bit時代の遺産だからな
farポインタの存在する環境であればfarポインタになるのだが
32-bit環境以上なら普通のポインタと同じ
83:デフォルトの名無しさん
12/12/15 11:26:29.81
コードリソースの32kBというサイズはPC相対アドレッシングの制約からきたものかも
知れないが、セグメント間はA5相対JSRでアクセスするようコンパイラが判断するから、
関数ポインタを使いたいような場面でもない限りプログラマが意識する必要はなかったな。
84:デフォルトの名無しさん
12/12/15 21:29:59.09
昔のコンパイラは
switchがショートジャンプなので
延々と処理を書くと
適当なとこにジャンプしてた
85:デフォルトの名無しさん
12/12/15 21:35:23.60
>>84
「適当」って「適切」じゃなくて「いい加減」という意味ですか？
怖いですね。
86:デフォルトの名無しさん
12/12/15 22:08:15.49
昔のコンパイラと言うかそのコンパイラが手抜k
87:デフォルトの名無しさん
12/12/15 22:40:53.85
飛べねーぞごらぁ って言うのは見たことあるけど、変なとこに飛ぶコードを吐く奴は
さすがに見たことない。
88:デフォルトの名無しさん
12/12/16 02:35:18.51
質問させてください。
URLﾘﾝｸ(www.geocities.jp)
上記のURL中に
「デストラクタですが、これはクラスのインスタンスが解体されるときに、
解体の直前で自動的に呼び出されます。
解体されるタイミングは、そのインスタンスのスコープを抜けるときです。 」
とあるのですが、
では
IProduct* createFactory(Content* content)
{
switch( content->id )
{
case PARTS_ID_A:
return new ProductA( content );
default:
return NULL;
}
}
ProductA* product = createFactory(content);
のようなコードはなぜ正常に動くのでしょうか？？
createFactory内でnewしたProductAはすぐreturnされてスコープを抜けてしまうので
その時点でデストラクトされ、
productに代入されるポインタはすでに使えないものになっているのではないのでしょうか？
理屈がよくわからないのですが、教えて頂けると嬉しいです。
89:デフォルトの名無しさん
12/12/16 02:53:01.82
newで作成したインスタンスはスコープを抜けても勝手にデストラクトされない
90:74 ◆QZaw55cn4c
12/12/16 02:53:57.65
>>88
new で得たポインタはdeleteしない限り無効にはならない
new で得たポインタは関数を超えても生き残り続ける
new したものはdeleteせよ、という宗教もここからきているかと
91:デフォルトの名無しさん
12/12/16 03:32:27.84
C#だとnewばっかで滅多に削除を明示しない
92:デフォルトの名無しさん
12/12/16 03:36:33.83
なるほど！
ありがとうございますm(__)m