09/04/19 11:55:04
>>727
>ハードウェアが書き込み，プロセッサが読み出す領域: const volatile
この使い方って本当に大丈夫？
例示できないけどconst有り無しのオーバーロード関数とか・・・
751:デフォルトの名無しさん
09/04/19 12:10:18
>プロセッサが書き込み，ハードウェアが読み出す領域: volatile
これも疑問だよな
プロセッサもハードウェアも読み書きする領域じゃないのか？
752:デフォルトの名無しさん
09/04/19 12:16:38
そのコードが動作するプロセッサの管理外で読み書きされる領域
753:デフォルトの名無しさん
09/04/19 13:47:07
プロセッサによって細かい挙動は違うだろうけど、
volatileって常に最新の実体を参照するようにするだけだよね？
754:デフォルトの名無しさん
09/04/19 13:52:46
最適化を無効にしてるだけだから
755:デフォルトの名無しさん
09/04/19 14:38:46
その変数を扱っているプログラムとは別のなにかによって内容が変更されうる変数。
volatile int i;
int j;
if ( i == 1 ) j = i;
で j == 1 でないときがありえる変数。
constをつけるとそのプログラムからは内容が変更できないのに参照するたびに内容はかわるかもしれない変数になる。
ポインタ経由でアドレスにマッピングされたI/Oポートとやり取りするのに使ったりする。
756:733
09/04/19 14:51:18
>>734
thx! 亀レスｽﾏｿ
「自然に実装すれば」というのは、アセンブル段階で
構造体やクラスのコードはすべて code セグメントに集約している
場合、ということでしょうか。
もう１つ謎なのは、インスタンス化を可能とするために、
clear() を呼んだ際に、どのメモリ領域が this に該当するのかを
どうにかして渡しているはずですが、その文献が見当たりません。
どのように処理しているんでしょうか。
757:デフォルトの名無しさん
09/04/19 16:36:28
>>756
> 「自然に実装すれば」というのは、アセンブル段階で
> 構造体やクラスのコードはすべて code セグメントに集約している
> 場合、ということでしょうか。
クラス（あるいは構造体）のメンバ変数は、
インスタンス毎に値が違うので、各インスタンスごとに
用意してやる必要があるが、メンバ関数は各クラス毎に
一つだけ用意してやればよい。
よって、>>733の場合だと、スタックにメンバ関数（へのポインタ）が
用意される必要はない（virtual関数は微妙に別）
> もう１つ謎なのは、インスタンス化を可能とするために、
> clear() を呼んだ際に、どのメモリ領域が this に該当するのかを
> どうにかして渡しているはずですが、
>>733の例のclear()の場合、処理系が勝手に
__struct_fruit_clear(fruit* this)
のような関数に置き換える（ことが多い）。ただし、処理系依存。
758:733
09/04/19 17:46:48
>>757
丁寧な説明、本当にありがとうございます。
かなり理解できました。
759:デフォルトの名無しさん
09/04/19 20:32:45
個人開発にて C++ にインターフェースの概念を取り入れようとしております。
.NET や Java では interface が言語仕様として存在しますが、
C++ では言語仕様レベルで Java のような interface は存在しません。
なので、単一継承とは別に、
純粋仮想関数だけで固められたクラスのみ、多重継承を許可して実装しようと思ってます。
そのような実装で問題点などありますでしょうか。
よろしくお願いします。
760:デフォルトの名無しさん
09/04/19 20:35:38
特に問題はないと思うけど、インターフェイスだと分かるようなクラス名にするとか工夫した方がいいかも
結局は規約次第だと思うが
761:デフォルトの名無しさん
09/04/19 20:59:23
>>760
レスありがとうございます。
やっぱり規約や、実装者の意識の問題になりそうですよね。
個人（自分だけ）での開発なので、その辺の問題は薄そうですが・・・
コンパイラで上手くカスタマイズして、
間違った実装したときに警告とか出せればいいんですけどね。
762:デフォルトの名無しさん
09/04/19 21:03:35
>>759
struct IHoge {virtual ~IHoge();};
struct IFoo : IHoge {};
struct IBar : IHoge {};
class Piyo : IFoo, IBar {};
Piyo piyo;
このとき、(IHoge*)(IFoo*)&piyo == (IHoge*)(IBar*)&piyoが
真になるとは限らないということを許容できないなら、仮想継承を使うべきと言っておく。
処理系間や多言語間での互換性を高めるため、仮想継承を使っていないMSのCOMでは、
これが理由でポインタの比較が面倒（仮想継承の代わりに規約で縛りを入れて対処している）。
763:デフォルトの名無しさん
09/04/19 21:45:10
>>762
operatorの再定義のことを言ってる？
よく分からん。
764:デフォルトの名無しさん
09/04/19 22:00:25
>>763
仮想継承しなければ、IFooの部分オブジェクトのIHogeとIBarの部分オブジェクトのIHogeは別物ということ。
インタフェースという元のお題からは外れるが、IHogeに非静的メンバ変数xがあれば、
IFoo側のxとIBar側のxは、仮想継承しないなら別々、仮想継承したら同一の存在だろ。
（かなり乱暴な言い方だけど）
それと同じ話。単にメンバ変数がないからポインタの比較でもしないと問題が発覚しないだけで。
765:デフォルトの名無しさん
09/04/19 22:20:17
教科書に書いてある内容なんだから
「仮想継承」も調べておいた方がいいとかで済ませればいいのに
766:デフォルトの名無しさん
09/04/19 23:49:51
>>762
レスありがとうございます。
仮想継承はよく理解してなかったんで、Wikipedia とかで調べてました。
多重継承する上で理解しておかないといけない概念ですね。
ありがとうございました。
767:デフォルトの名無しさん
09/04/19 23:52:40
おまえらスレがもったいないから
>>765さんが教科書で覚えたことはいちいち説明するなよ。
ググレカス。
768:デフォルトの名無しさん
09/04/19 23:56:49
俺もC|Java|C#|VB厨だから仮想継承を調べてみた
たしかにこれはググればわかる気がする
今後は namespace C++{ 仮想継承 } とか名前空間で囲んでくれると名前的にわかりやすい
RDFでも可
769:デフォルトの名無しさん
09/04/20 13:17:27
namespaceは神
これさえあればC言語風に書けるしなw
クラス？
そんなもんいらね。
770:デフォルトの名無しさん
09/04/20 13:26:09
namespaceはCに取り込まれるべきだと思うね
コメントの//より優先されるべきだった
771:デフォルトの名無しさん
09/04/20 14:31:19
namespaceだとC++と同じだから、namekukanでCに取り込んだら
どうだろうか
772:デフォルトの名無しさん
09/04/20 14:33:16
programminglang::C::namespaceでいいよ。
773:デフォルトの名無しさん
09/04/20 15:40:24
namespace 入れてくれれば enum を気兼ねなく使えるしな
namespaceだとC++と同じだから、miniascapeでCに取り込んだらどうだろうか
774:デフォルトの名無しさん
09/04/20 19:37:14
普通に
namespaceでいいよ。だからさっさと取り込んでくれ。
775:デフォルトの名無しさん
09/04/20 22:17:27
namespiceでいいよ
776:デフォルトの名無しさん
09/04/20 22:20:40
namaespaceでいいよ
777:デフォルトの名無しさん
09/04/20 23:33:28
namaekukanだろｊｋ
778:デフォルトの名無しさん
09/04/20 23:35:43
無名名前空間も頼む。
staticいちいち付けるの面倒なんじゃ。