page0081
の編集
http://osecpu.osask.jp/wiki/?page0081
[
トップ
] [
編集
|
差分
|
バックアップ
|
添付
|
リロード
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
-- 雛形とするページ --
BracketName
FormattingRules
FrontPage
Fulyn
Fulyn-v2
Fulyn_Samples
Help
InterWiki
InterWikiName
InterWikiSandBox
K
KOR_PIT8254
KWVM.NET
Liva
MANA
MenuBar
OSECPU_FPGA
PG_MANA
PHP
PukiWiki
PukiWiki/1.4
PukiWiki/1.4/Manual
PukiWiki/1.4/Manual/Plugin
PukiWiki/1.4/Manual/Plugin/A-D
PukiWiki/1.4/Manual/Plugin/E-G
PukiWiki/1.4/Manual/Plugin/H-K
PukiWiki/1.4/Manual/Plugin/L-N
PukiWiki/1.4/Manual/Plugin/O-R
PukiWiki/1.4/Manual/Plugin/S-U
PukiWiki/1.4/Manual/Plugin/V-Z
RecentDeleted
SandBox
WikiEngines
WikiName
WikiWikiWeb
YukiWiki
hikalium
hikarupsp
hikarupsp_ELCHNOS
hikarupsp_ELCHNOS_IDE
hikarupsp_FrontEndCode
hikarupsp_WebCPU-VM
hikarupsp_WebCPU-VM_internal
hikarupsp_study_hh4
impressions
impressions0000
jpag0000
jpag0001
jpag0002
jpag0003
jpag0004
jpag0005
lambdalice
mandel59
members
memo0000
memo0001
memo0002
memo0003
memo0004
memo0005
memo0006
memo0007
memo0008
memo0009
memo0010
osask
osecpu4android
page0000
page0001
page0002
page0003
page0004
page0005
page0006
page0007
page0008
page0009
page0010
page0011
page0012
page0013
page0014
page0015
page0016
page0017
page0018
page0019
page0020
page0021
page0022
page0023
page0024
page0025
page0026
page0027
page0028
page0029
page0030
page0031
page0032
page0033
page0034
page0035
page0036
page0037
page0038
page0039
page0040
page0041
page0042
page0043
page0044
page0045
page0046
page0047
page0048
page0049
page0050
page0051
page0052
page0053
page0054
page0055
page0056
page0057
page0058
page0059
page0060
page0061
page0062
page0063
page0064
page0065
page0066
page0067
page0068
page0069
page0070
page0071
page0072
page0073
page0074
page0075
page0076
page0077
page0078
page0079
page0080
page0081
page0082
page0083
page0084
page0085
page0086
page0087
page0088
page0089
page0090
page0091
page0092
page0093
page0094
page0095
page0096
page0097
page0098
page0099
page0100
page0101
page0102
page0103
page0104
page0105
page0106
page0107
page0108
page0109
pagenames
populars
seccamp2013
seccamp2014
seccamp2017
ttwilb
ttwilb-asmi
yao
* オブジェクト指向 -(by [[K]], 2014.05.22) ** (0) -(ここに書いていることは2014年度内には実現しません!) -何年か先には、OSECPU-VMでもオブジェクト指向言語を作ることになると思います。もし僕が作ることになったら、C++言語を参考にすると思います。ここに書くのはそれらに関するアイデアのメモです。 ~ -僕としてはC++を作りたいのではなくて、C++よりもよい「なにか」を作りたいです。とはいえ、C++を否定しているわけではないので、C++をC++としてOSECPU-VM上で作ってくれる人がいたらそれは歓迎します。 ** (1) -C++でvirtualなメンバ関数を含むクラスを作ると、内部では見えないメンバ変数が一つ追加されて、virtualな関数へのポインタが並んだ配列を指し示すように初期化されます。 --例: class C { int a, b; virtual void setA(int _a) { a = _a; } virtual void setB(int _b) { b = _b; } }; sizeof (C) は { TypeInfo *info; int a, b; } から計算して12バイトになる。 TypeInfoにはsetAやsetBのポインタが格納されている。 この仕組みのおかげでこんなことができます。 class C を継承して class D を作り、setBだけオーバーロードした場合、そのTypeInfoは setBのポインタが新しい関数を指しているので、正しく子クラスの関数ポインタを得ることができ、 うまく呼び出せます。 -つまりC++でvirtualなメンバ関数を呼び出す場合は、オブジェクトからinfoの値を呼び出して、そしてその中からメンバ関数のポインタを取得して、それを呼び出すようなコードになっています。 -infoの構造(何番目の関数ポインタがsetBを指しているのか)などは、基本的に固定で、継承されるたびに新しいvirtual関数が付け足されていきます。 -このような仕組みになっているので、オブジェクトが一つでもあれば、そこからメンバ関数のポインタを取得することができます。 ~ -このinfoは「仮想関数テーブル」と呼ばれていて、vtableと表すのが一般的のようです。 --http://ja.wikipedia.org/wiki/%E4%BB%AE%E6%83%B3%E9%96%A2%E6%95%B0%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB ** (2) -C++の方式では、以下のような問題があります。 --あるクラスがあって、そのクラスにもsetAとsetBというメンバ関数があります(他の関数もある)。しかしこのクラスは上記の class C とは継承関係にはありません。この場合、このクラスに対して class C 向けに書かれた関数を利用することはできません。 --同じメンバ関数があれば、たとえ継承関係がなくても、同じように使えるべきだという考え方があって、それは「ダック・タイピング」と呼ばれていますが、僕はできるべきだと考えているのです。 ---http://ja.wikipedia.org/wiki/%E3%83%80%E3%83%83%E3%82%AF%E3%83%BB%E3%82%BF%E3%82%A4%E3%83%94%E3%83%B3%E3%82%B0 --これができる言語もあります。 --上記のWikipediaのページでは、C++でもテンプレートを使うことでこれを実現しています。しかしこれで生成されるコードは、各型ごとのtestが作られているだけなのです。それは僕がやりたいこととは違うのです。つまりC++のテンプレートによる解決は、ソースの行数は減らしたけれど、実際に生成されるコードの量は減っていないのです。 -僕の考える方式では、違った考え方をします。 -まず、関数のポインタをオブジェクトの中から取得することをやめます。それは呼び出し元からもらうのです。 C++方式: void func(C *c) { c->setA(13); } 提案手法: void func(C *c, Func *setA) { (*setA)(c, 13); } // イメージ. -提案手法を厳密に書くとややこしくなるので雑にしていますが、イメージは分かると思います。 -setAとsetBを使うのだとしたら、その両方のポインタを引数で渡してやればいいじゃないですか。それをオブジェクトから自動で求められるようにしようとしたから、C++はダック・タイピングができなくなってしまったのです。呼び出し元が関数のポインタを教えてあげる方法なら、必要なメンバ関数がそろっていれば、問題なく利用できます。 --もちろん毎回必要なメンバ関数を引数に列挙しなければいけなくなったら、それは大変です。でもそれは高級言語の方でカバーしてもらえばいいのです。 -この方式だと、setAの代わりにsetBをあえて使わせる、みたいなことも可能です。つまり対応する機能があれば、関数名が一致していなくてもいいのです。 -このアイデアは、Cの<stdlib.h>のqsort()を思い出したときに思い付きました。・・・この仕様は良く考えられていて、十分に応用がきくと思います。 --たとえばソートはいろいろな順序でやりたいはずで、それは比較関数を変えるだけで制御できます。もしこれがcompareというメンバ関数をもつ、比較可能なクラスにのみで利用可能だとしたら、比較方法を1種類しか実装できないことになってしまいます。 * こめんと欄 #comment
タイムスタンプを変更しない
* オブジェクト指向 -(by [[K]], 2014.05.22) ** (0) -(ここに書いていることは2014年度内には実現しません!) -何年か先には、OSECPU-VMでもオブジェクト指向言語を作ることになると思います。もし僕が作ることになったら、C++言語を参考にすると思います。ここに書くのはそれらに関するアイデアのメモです。 ~ -僕としてはC++を作りたいのではなくて、C++よりもよい「なにか」を作りたいです。とはいえ、C++を否定しているわけではないので、C++をC++としてOSECPU-VM上で作ってくれる人がいたらそれは歓迎します。 ** (1) -C++でvirtualなメンバ関数を含むクラスを作ると、内部では見えないメンバ変数が一つ追加されて、virtualな関数へのポインタが並んだ配列を指し示すように初期化されます。 --例: class C { int a, b; virtual void setA(int _a) { a = _a; } virtual void setB(int _b) { b = _b; } }; sizeof (C) は { TypeInfo *info; int a, b; } から計算して12バイトになる。 TypeInfoにはsetAやsetBのポインタが格納されている。 この仕組みのおかげでこんなことができます。 class C を継承して class D を作り、setBだけオーバーロードした場合、そのTypeInfoは setBのポインタが新しい関数を指しているので、正しく子クラスの関数ポインタを得ることができ、 うまく呼び出せます。 -つまりC++でvirtualなメンバ関数を呼び出す場合は、オブジェクトからinfoの値を呼び出して、そしてその中からメンバ関数のポインタを取得して、それを呼び出すようなコードになっています。 -infoの構造(何番目の関数ポインタがsetBを指しているのか)などは、基本的に固定で、継承されるたびに新しいvirtual関数が付け足されていきます。 -このような仕組みになっているので、オブジェクトが一つでもあれば、そこからメンバ関数のポインタを取得することができます。 ~ -このinfoは「仮想関数テーブル」と呼ばれていて、vtableと表すのが一般的のようです。 --http://ja.wikipedia.org/wiki/%E4%BB%AE%E6%83%B3%E9%96%A2%E6%95%B0%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB ** (2) -C++の方式では、以下のような問題があります。 --あるクラスがあって、そのクラスにもsetAとsetBというメンバ関数があります(他の関数もある)。しかしこのクラスは上記の class C とは継承関係にはありません。この場合、このクラスに対して class C 向けに書かれた関数を利用することはできません。 --同じメンバ関数があれば、たとえ継承関係がなくても、同じように使えるべきだという考え方があって、それは「ダック・タイピング」と呼ばれていますが、僕はできるべきだと考えているのです。 ---http://ja.wikipedia.org/wiki/%E3%83%80%E3%83%83%E3%82%AF%E3%83%BB%E3%82%BF%E3%82%A4%E3%83%94%E3%83%B3%E3%82%B0 --これができる言語もあります。 --上記のWikipediaのページでは、C++でもテンプレートを使うことでこれを実現しています。しかしこれで生成されるコードは、各型ごとのtestが作られているだけなのです。それは僕がやりたいこととは違うのです。つまりC++のテンプレートによる解決は、ソースの行数は減らしたけれど、実際に生成されるコードの量は減っていないのです。 -僕の考える方式では、違った考え方をします。 -まず、関数のポインタをオブジェクトの中から取得することをやめます。それは呼び出し元からもらうのです。 C++方式: void func(C *c) { c->setA(13); } 提案手法: void func(C *c, Func *setA) { (*setA)(c, 13); } // イメージ. -提案手法を厳密に書くとややこしくなるので雑にしていますが、イメージは分かると思います。 -setAとsetBを使うのだとしたら、その両方のポインタを引数で渡してやればいいじゃないですか。それをオブジェクトから自動で求められるようにしようとしたから、C++はダック・タイピングができなくなってしまったのです。呼び出し元が関数のポインタを教えてあげる方法なら、必要なメンバ関数がそろっていれば、問題なく利用できます。 --もちろん毎回必要なメンバ関数を引数に列挙しなければいけなくなったら、それは大変です。でもそれは高級言語の方でカバーしてもらえばいいのです。 -この方式だと、setAの代わりにsetBをあえて使わせる、みたいなことも可能です。つまり対応する機能があれば、関数名が一致していなくてもいいのです。 -このアイデアは、Cの<stdlib.h>のqsort()を思い出したときに思い付きました。・・・この仕様は良く考えられていて、十分に応用がきくと思います。 --たとえばソートはいろいろな順序でやりたいはずで、それは比較関数を変えるだけで制御できます。もしこれがcompareというメンバ関数をもつ、比較可能なクラスにのみで利用可能だとしたら、比較方法を1種類しか実装できないことになってしまいます。 * こめんと欄 #comment
テキスト整形のルールを表示する