1001コメント409KB

OOP 2

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

0001デフォルトの名無しさん

2010/11/10(水) 22:51:25

前スレのあらすじ

OOPってよくわかんないよね

http://hibari.2ch.net/test/read.cgi/tech/1284115490/

0067デフォルトの名無しさん

2010/11/14(日) 11:33:52

そりゃ open(2) や write(2) とか、「(2)」のレベルで多態になってるからだ。
言語のレベルとは話が違う。

0068デフォルトの名無しさん

2010/11/14(日) 12:59:12

> 言語のレベル
OOPLじゃなくてOOPの話じゃなかったの
と思いつつ>>66もそれなりに微妙

0069デフォルトの名無しさん

2010/11/14(日) 18:59:22

>>63-64
専門用語一つ社会で使われている意味で使えないで、
自分の考えを正しく伝えられないような社会不適合者がなんか言ってる。

0070デフォルトの名無しさん

2010/11/14(日) 20:50:29

ちんこがサラリーマンのふりをしてるだけだろ

0071デフォルトの名無しさん

2010/11/15(月) 18:49:49

社会で使われている意味でのOOPの意味ってなんだよ。
誰も説明できはしないだろ。
関数は大体引数取るし、引数はその関数の処理の「対象」なんだから、その関数のオブジェクトだし、
ほら、オブジェクト使ってるからオブジェクト指向だってんなら、全部OOPになっちゃう。
OOPとそうでないものの明確な線引きって何よ。
誰も答えられないだろ。
だから俺が言ってやってんだろ。
オブジェクトってのは要は言葉を濁してんだよ。
データと処理の区別がない、なんとも言えない曖昧なプログラムのパーツのことを
どうとも表現できないから、「オブジェクト」なんて呼んでるんだ。
だから、データ構造と制御構造の区別のない曖昧なものが「オブジェクト」で、
それを中心に考えるのがOOで、
それでプログラムを構築する手法がOOPで、
それが前提の言語がOOPLなんだ。
でも、なんで曖昧である必要があるんだ？
Itumono言語だと、データ構造と制御構造は明確に区別されるし、
区別されるってだけで、通常のOOP相当のことも当たり前に出来る。
しかも、データ構造と制御構造を明確に区別することで、
マルチメソッドやダックタイピングまで可能だってのに。
なんで、曖昧にしておく必要があるんだ？
曖昧なままだと、少なくともマルチメソッドは無理なんだぜ。
どのみちこのみち。

0072デフォルトの名無しさん

2010/11/15(月) 19:15:25

>>71
>曖昧なままだと、少なくともマルチメソッドは無理なんだぜ。
OOPLでもマルチメソッド出来るものはあるワケだが…

0073デフォルトの名無しさん

2010/11/15(月) 19:23:16

何々教えて。CLOSとか言うなよ。

0074デフォルトの名無しさん

2010/11/15(月) 19:25:06

ん？CLOSはOOPLというよりOOPシステムだけど、それでもいいよ？
てかJavaでもオーバーロードで出来ると思うが？何を指してる？

0075デフォルトの名無しさん

2010/11/15(月) 19:30:30

それは、静的なんじゃないの？

0076デフォルトの名無しさん

2010/11/15(月) 19:33:54

へ？動的じゃないとダメなの？
まあ、動的でもそのCLOSは出来るんだよね？

0077デフォルトの名無しさん

2010/11/15(月) 19:38:31

静的なものは通常ポリモとは言わんだろう。
CLOSをOOPと言っていいのかは微妙だ・・・
どちらにしても、みんなの求めているものはコレジャナイ。
手続き型言語が欲しいんだろ？

0078デフォルトの名無しさん

2010/11/15(月) 19:48:48

>>77
静的なものはポリモじゃないってんなら、Javaにポリモは無いことにならんか？

0079デフォルトの名無しさん

2010/11/15(月) 19:57:04

JavaのメソッドはC++で言う仮想関数だから、
vtable相当を使った単一ディスパッチは出来るだろ。
ただ、多重ディスパッチ(マルチメソッド)には対応していなかった筈だが。
オーバーロードは可能だが、静的結合だ。

0080デフォルトの名無しさん

2010/11/15(月) 19:59:57

というか、単一オブジェクトがvtable抱えてるから、
原理的にマルチメソッドが出来ない。
だから俺はそのvtableをどっか別のところへ持って行こうと。
構造体からvtable消して、型情報はポインタに持たせる。
ポインタの型情報を使って、関数呼び出しをマルチメソッド化する。
上手いやり方だと思うが。

0081デフォルトの名無しさん

2010/11/15(月) 20:48:03

>>77
ポリモとかHDDをハードと呼ぶくらいにうざいですう。

0082デフォルトの名無しさん

2010/11/15(月) 21:07:30

>>71
>データ構造と制御構造の区別のない曖昧なものが「オブジェクト」
わかってるんじゃないか

中身の実装を隠蔽するのがカプセル化だよ
「自分が呼び出してるのがフィールドなのか、メソッドなのかを隠す」
ってのもその一部

カプセル化する対象の実装を書くのがクラス
クラスのインスタンスがオブジェクト

このオブジェクトを組み合わせてプログラミングしようってのがOOP
そんなに難しい話じゃないでしょ

0083デフォルトの名無しさん

2010/11/15(月) 21:27:05

>>82
彼に、ノイマン・アーキテクチャから演繹できない概念を理解させようとしても無駄だよ。
その手の抽象化の必要性を痛感する場面に遭遇したことがないみたいだし。

0084デフォルトの名無しさん

2010/11/15(月) 21:30:36

・万能感がある落ちこぼれってうざいよね。
・fopen以前を誰も知らない世代てのはいいことであるわけだけれどもなあ。
・「全てはOOと非OOに分けることが可能である」俺理論乙「その境目は仮想関数テーブルの有無である」俺理論乙
・LISPが式と値を曖昧なままにして――区別してないのはOOPに関係ないことくらい習わなんだのか。
・つかCでも関数ポインタを引数にとり関数ポインタを返す関数とかあるよな。
・型情報はポインタに持たせることにより多重継承もできるんだとさ。
・多重ディスパッチなんて使い道は殆ど無い。使うのは実行時とコンパイル時が同じインタプリタ言語くらいだ。
・「相対性理論は間違っている」うざい。間違っていると思うのは手を動かさず演説ばかりしてるからだ。
・OOなんて経験知の集積だ。プログラムを書いてれば分かるもので、書かない阿呆には理解はできん。
・何度も言われただろうが、これから何度も言われるだろう「Itumonoが便利だと思うのはそれを使ったことが無いからだ」
纏めんの面倒
後全部グローバル名前空間にぶち込むなど阿呆とかいろいろ有るけど趣味グラマでもない人には言っても無駄

0085デフォルトの名無しさん

2010/11/15(月) 21:38:39

>Itumonoが便利だと思うのはそれを使ったことが無いからだ

なんという説得力

0086デフォルトの名無しさん

2010/11/15(月) 22:47:44

>>84
>・OOなんて経験知の集積だ。プログラムを書いてれば分かるもので、書かない阿呆には理解はできん。
神が居た。

0087デフォルトの名無しさん

2010/11/15(月) 22:48:38

>「自分が呼び出してるのがフィールドなのか、メソッドなのかを隠す」

そもそもフィールドが存在しない言語を考えれば良い。
データがスタック上 (引数やローカル変数) にしかない言語。
関数型言語がそれに近い。

(フィールドの集まりである) thisやselfがなければ、マルチメソッドなんて無駄な概念も出てこない。
ついでに、スタックとフィールドの間でデータを移動する手間も省ける。

0088デフォルトの名無しさん

2010/11/15(月) 23:01:12

それはそうかもな、と思える指摘もあるが、
単一継承ならまだしも、多重継承はさすがに要らないだろ。

あれこれ言う人にはこの一言だ。
C++0xはああなった。

何処まで時間をさかのぼれば失敗を取り返せるか。
そう考えるのは自然だろ。

0089デフォルトの名無しさん

2010/11/15(月) 23:07:25

>>87
>データがスタック上 (引数やローカル変数) にしかない

FORTRANの香りがする

0090デフォルトの名無しさん

2010/11/15(月) 23:10:04

>>87
それは面白い試みなんだけど、
昨今のコンピュータには膨大なメモリ空間があって、
プログラマはそれの操作をしたがってる。
副作用を起こしてな。

副作用って、数学的には不味いんだが、
コンピュータにとってはむしろ本質的なものに思える。
「メモリ操作したい！有るんだから操作したい！触らせろ」ってな。
input -> update -> output はコンピュータにとっては呼吸のようなものだろうか。

Itumono言語は「いつもの言語」だから、普通でなければならないと思ってる。
C言語＋テンプレート＋マルチメソッド＋型推論＋何らかのカプセル化機能
これで十分でしょ。

0091デフォルトの名無しさん

2010/11/15(月) 23:16:23

>>90
>何らかのカプセル化機能
データと処理の区別が云々はどこいったの？

0092デフォルトの名無しさん

2010/11/15(月) 23:21:27

型付きラムダ式でもやってれば

0093デフォルトの名無しさん

2010/11/15(月) 23:23:00

仮想関数テーブルを噛まさないのであれば、それほど問題とも思えん。
get_value( &hoge );　とかな。
問題は、そこで小難しいことをやろうとしたことだ。
間にvtableを挟んでな。
vtableはデータと処理の橋渡しをするが、あまりに貧弱だし、邪魔だ。
構造体の先頭に仕込むアイデアは糞以下。
ポインタに持たす仕様だったら、幾分かはマシだったろうがな。
shared_ptrはそうなってるのにな。共有ポインタがデストラクタ持ちまわる。

0094デフォルトの名無しさん

2010/11/15(月) 23:26:47

そろそろC++ ISOスレに名前変えるか
>>93がどっか行って消えればいいんじゃないかな

0095デフォルトの名無しさん

2010/11/15(月) 23:29:13

俺が居ないとこのスレ回らないって知ってた？
それから、元々アンチOOPのスレなんだぜ？
今はスレタイ端折りまわってこうなってるけどな。
OOPなんぞ、スレタイ考えるのもアホくさいってこったろ。

0096デフォルトの名無しさん

2010/11/15(月) 23:32:14

一応張っとくか。

>8 名前：デフォルトの名無しさん[sage] 投稿日：2010/11/11(木) 00:17:49
>前々スレ
>
>結局OOpが役に立たないのはなぜ?
>http://hibari.2ch.net/test/read.cgi/tech/1271175248/

元はこんなノリだ。

0097デフォルトの名無しさん

2010/11/15(月) 23:33:54

否定的なタイトルつけると
OOPやったこともないような人が難癖付けにくるから
こうしただけなんだけどね

あと特にOOPに悪意は持ってないよ

0098デフォルトの名無しさん

2010/11/15(月) 23:35:46

いつもスレ立てご苦労様。

0099デフォルトの名無しさん

2010/11/15(月) 23:40:33

vtablevtableうるさいってことだよ

0100デフォルトの名無しさん

2010/11/15(月) 23:44:08

だけど、OOPの真髄はvtableだろ？
同時に一番のヘマだ。

0101デフォルトの名無しさん

2010/11/15(月) 23:48:46

>>95
誰も回してくれと頼んだ覚えはないのだが。

0102デフォルトの名無しさん

2010/11/15(月) 23:54:30

>>93
チューリング完全なら、実装方法が何であろうと計算能力は同等なんだからどうでもいい。

0103デフォルトの名無しさん

2010/11/15(月) 23:55:01

2chで長文書いてる暇があるなら少しずつでも実装しろよ

理想のOOPを実現するために
言語を作って本までだしたメイヤーさんを見習え

せめて仕様書かけ。

0104デフォルトの名無しさん

2010/11/15(月) 23:57:05

プリプロセッサの要る要らないの話を永遠と聞きたいってのか？
Q どっちのクラスに実装すべきでしょうか？A それは仕様を見ないと解らないね。
AやらBやらCやらDやら・・・
そんな展開だぜ？
まー俺が来てから、俺の話題ばっかになっちゃったのはアレだけどな。

0105デフォルトの名無しさん

2010/11/16(火) 00:03:38

>>104
> Q どっちのクラスに実装すべきでしょうか？A それは仕様を見ないと解らないね。

それが一意に決まるなら設計・分析フェーズなんかいらんわな。

0106デフォルトの名無しさん

2010/11/16(火) 00:05:35

>>103
だけど、そういう人たちの熱い原動力ってなんなんだろうね。正直うらやましい。

まー実装するとしたら、インタプリタかトランスレータかJavaVMか.Netかネイティブかだけど、
最適化まで考えると、ネイティブはしんどいよなぁ。
まずは簡単なインタプリタで実装で良いかな。そんで言語仕様のアラを取ってから次の展開でも遅くはないよな。
コンパイラはエラー入力前提だから、山のようなエラーメッセージ仕込まないとダメだし、
もう、一生費やす勢いだな。俺にとってのItumonoになりそうだ。
プロジェクトファイル名もどうせ「Itumono」だろ？萎えるぜ。
そして、多分、完成しないよね。それが普通だと思う。

0107デフォルトの名無しさん

2010/11/16(火) 00:32:52

>>88
C++に多重継承はインターフェイスに限るなんて仕様は無いが。
「ワタシはjavaやC#もしりません」なんてことを書くんなら出てけよ。

0108デフォルトの名無しさん

2010/11/16(火) 00:34:55

何言ってんだか。
特にその、「インターフェース以外の多重継承」が要らない対象だろ。
ダイヤモンド継承乙

0109デフォルトの名無しさん

2010/11/16(火) 00:41:43

void f([HOGE*,HOGEEX*]);
void g([FOOEX*,HOGEEX*]);
void main(){
　auto q = new HOGE();
　f(q);
　g(q);//compile error
　auto p = new HOGEEX();
　f(p);
　g(p);
}
市ね。

0110デフォルトの名無しさん

2010/11/16(火) 00:51:48

ダックタイピングだってのに。
EXとか言われても、継承って概念が無いのにさぁ。
オーバーロードはあってもオーバーライドは無いのさ。
コードを使いまわすのなら、継承よりコンポジションだろ？
継承でのポリモは基底クラスが同じじゃなきゃダメってのが結構痛いんだよね。

0111デフォルトの名無しさん

2010/11/16(火) 00:52:56

だからちんこはとっととLispコンパイラ作れや

0112デフォルトの名無しさん

2010/11/16(火) 00:54:00

なんでLispなんだよw

0113デフォルトの名無しさん

2010/11/16(火) 00:57:53

Lisp処理系は実装が超簡単と言われている。
後は分かるな・・・。

0114デフォルトの名無しさん

2010/11/16(火) 01:02:28

Pascalのコンパイラなら書いたことあるぞ。
エラーメッセージ仕込むのがとにかく大変でな。
まーCもPascalと似たようなもんでしょ。
文法がアレな分、Cの方が大変そうだが。

0115デフォルトの名無しさん

2010/11/16(火) 01:13:07

void f(WndClassBase*);
void g(IIconhaving*);
C++での↑が
void f(WNDCLASS*);
void f(WNDCLASSEX*);
void g(WNDCLASSEX*);
void g(CWINDOW*);
の動的オーバーロードでうまくいくと言っていたのは誰であったであろうか。

0116デフォルトの名無しさん

2010/11/16(火) 01:30:16

それだと、狭い世界で生きているんだなぁってことしか解らんよ。

とにかく、継承はないんだ。
やっても、インターフェイスの継承だろう。
インターフェイスの継承なら、ダックタイピングで十分間に合う。
テンプレートがその例だ。ただし、テンプレートは静的に結合しちゃうがな。

0117デフォルトの名無しさん

2010/11/16(火) 01:32:39

>>90
一言居士の発言て中身空だよね。

0118デフォルトの名無しさん

2010/11/16(火) 01:36:44

class WndClassBase{
public:
　virtual ~WndClassBase();
　virtual f()=0;
};
class IIconHaving{
public:
　virtual g()=0;
};
こっちだったか。「C言語用に書かれた構造体を、手を加えずにポリモの対象に出来る」んでしょ。
でもこのくらいの類推が出来ないようじゃ失格もので・・・
でも失格者相手だから・・・

0119デフォルトの名無しさん

2010/11/16(火) 01:38:24

だからね、どうしても継承が欲しくて欲しくてたまらない人は、
永遠と俺のこと叩いてればいいんだよ。

俺はこう思ってるわけ。
ポリモを求める人は居ても、いまさら継承を求める人は居ない、と。
ポリモできるんであれば、継承は要らない、ダックタイピングならなお良し、と。

テンプレートのおかげでダックタイピングの便利さは一般にも広まった。
俺もテンプレートで学んだ。ダックタイピング、こりゃ便利だ。なにせ共通の基底クラスが要らないんだからな。
あとはこれが動的になればなぁ。まー普通の感覚だわな。

0120デフォルトの名無しさん

2010/11/16(火) 01:46:14

>>118
OO脳って怖いなって思う。
そういう風にしかもう考えられないんだろうか。
この例だと、

add_WndClassBase( &hoge );
add_IconHaving( &hoge );

要は、add_～を呼んでフレームワークに登録する/しないで、
その構造体のスペックが決まる。継承で決める訳ではないんだよね。
上の例では、f( hoge_t * )とg( hoge_t * )が定義されてないとリンクエラーだね。

0121デフォルトの名無しさん

2010/11/16(火) 01:49:43

class WndClass:public WndClassBase{
public:
　WndClass();
　virtual ~WndClass();
　virtual int f();
private:
　WNDCLASS wc;
};
class WndClassEx:public WndClassBase, IIconHaving{
public:
　WndClassEx();
　virtual ~WndClass();
　virtual int f();
　virtual int g();
private:
　WNDCLASSEX wc;
};
でもItumono語でこれをするには
・「頭から型値を割り振る」（>>27）のをやめ全構造体で一意の数を型値を割り振り、
　動的オーバーロードは配列を引くのではなくハッシュテーブルを引くようにする。
・「class pointer_t{ int type; void *addr; };」（>>17）を変更しtype1とtype2をもつようにする。
のどちらかを選ばなければならない。
ここまで書かれなきゃ屑だって分からんのがもうねえ。

0122デフォルトの名無しさん

2010/11/16(火) 01:59:33

>>120
実行時にadd_～を呼んだかどうかで
コンパイル時にリンクエラーが発生するとか
そんな発想常人には無理だわ。

0123デフォルトの名無しさん

2010/11/16(火) 02:06:29

vector<auto *> g_wnd_bases;
vector<auto *> g_icon_havings;

add_wnd_base( auto *wnd_base ){ push_back( &g_wnd_bases, wnd_base ); }
add_icon_having( auto *icon_having ){ push_back( &g_icon_havings, icon_having ); }

void update()
{
　　//for_eachの仕様は適当。まだ定まってないからな。擬似言語。
　　for_each( g_wnd_bases ){　f( _1 );　}
　　for_each( g_icon_havings ){ g( _1 ); }
}

ほらよ。

g_wnd_basesに突っ込まれりゃ「f」が呼ばれるし、
g_icon_havingsに突っ込まれりゃ「g」が呼ばれる。
ただそれだけ。対応するfやgが無きゃリンクエラーだ。
いたって単純。

継承がどうとかいちいち考えるから、頭がおかしくなるんだ。

ところで、型値はポインタ宣言ごとのローカルなものなんだけど、
ポインタからポインタへの代入時は当然型値の変換も行うんだぜ。
そりゃローカルからローカルだから、変換は必要だ罠。
だから、それ用のテーブルも作る。
グローバルな型値も、動的モジュールのロードに備えて、裏では持つだろうけど、
現段階ではポインタには持たせないつもり。

0124デフォルトの名無しさん

2010/11/16(火) 02:08:34

>>122
コンパイル時に解るだろ。
呼ばれる可能性があれば、呼ばれると判断する。
だから、if( false ){ add_～　}
でも、add_～は呼ばれるものと見なし、
対応する関数が無い場合はリンクエラーだ。

0125デフォルトの名無しさん

2010/11/16(火) 02:28:52

なに、これ、？
もしかしてf(x)を呼ぶにはfのキューにxを登録してupdateがf(x)を呼ぶのを待つとかそういうなにそれこわい
そもそもtypeid(HOGE)じゃなくて&hogeの時点でなんか変だとは……

0126デフォルトの名無しさん

2010/11/16(火) 08:20:06

>>124
> 呼ばれる可能性があれば、呼ばれると判断する。

そういうのはな、バグの温床って言うんだよ。
お前は静的型言語を何だと思ってるんだ。

0127デフォルトの名無しさん

2010/11/16(火) 09:59:43

>>126
どんなバグよ？

0128デフォルトの名無しさん

2010/11/16(火) 20:46:56

本人が完成できないと自覚してるんだから
わざわざレビューしてやることもないだろ

0129デフォルトの名無しさん

2010/11/16(火) 20:54:03

>>127
コードのどこかにadd～という一文があるかないかでコンパイラの挙動が変わり、
しかも実行時にそこを通るか通らないかでプログラムの挙動が変わるとか、
迷宮入りのバグを量産する悪寒しかしないわけだが。

0130デフォルトの名無しさん

2010/11/16(火) 22:02:10

auto *を返す関数を遅延ロードするのに、
静的にリンカが型を解決してエラー吐くのは無理だろ。
どっちか諦めろ。

そんなことよりモジュール単位をデカくしようとする、
その方向性が俺には理解出来ん。

0131デフォルトの名無しさん

2010/11/16(火) 22:34:19

>>130
責務の分割を拒否する・・・というより責務という概念がないことによる当然の帰結だなぁ。

0132デフォルトの名無しさん

2010/11/16(火) 22:56:08

>>108
bool f((A*|B*)p){return true;}
bool f((B*|C*)p){return false;}
void main(){
　(A*|B*|C*)p = new B;
　f(p);
}
ダイヤモンド継承乙

0133デフォルトの名無しさん

2010/11/16(火) 23:05:09

多重継承で思い出したんだが
Mixinってどうなの？はやってんのかな
実際に使ってる人いる？

0134デフォルトの名無しさん

2010/11/16(火) 23:08:48

boostにはゴロゴロない？base_from_memberとか。

0135デフォルトの名無しさん

2010/11/16(火) 23:25:18

>>base_from_member
検索してみたけどよくわからんかった
Mixinとたんなる多重継承の違いってなに？

0136デフォルトの名無しさん

2010/11/16(火) 23:36:54

>>129
何言ってんの？
C++のテンプレートも触ったことないの？

それ以前に、
コードのどこかに何かが有るか無いかでコンパイラの挙動が変わるのは、当たり前だし、
実行時にどこを通るか通らないかでプログラムの挙動が変わるのも、当たり前だ。
挙動が変わらなきゃ、一体どうするんだよw。もうどうでもいいや。

>>130
コンパイル時にもリンクエラーを吐き、
動的モジュールロード時にもエラーを吐くのさ。
どっちか諦めるのではなく、どっちもする。

動的にライブラリロードして、目的の関数が無かった場合に
実行時エラーになるのは、当たり前の挙動だわな。CやC++でも同じ挙動。
読み込んだライブラリにバグがあったんだから、仕方ない罠。
それ以上はどうしようもない。

>>132
(A*|B*) と (B*|C*) と (A*|B*|C*) はそれぞれ別の型で、何の関連性も無い。
だから、f(p)はリンクエラーだね。
正しくはこう。
bool f((A*|B*)p){return true;}
bool f((B*|C*)p){return false;}
void main(){
　((A*|B*)|(B*|C*))p = (A*|B*) new B;
　f(p);　//true
}
まーこんなコードを許すかどうかは言語仕様次第だが。
する奴居ないでしょ。面白いがな。

0137デフォルトの名無しさん

2010/11/17(水) 00:20:28

>>135
mixinをやる方法の一つが継承なだけで、マクロでできるのもあるし、言語によっては専用構文あるし。
違いはアップキャストを目的としないのがmixinと言えば良いのかな、
各ボタンクラスはButtonBaseを継承するのが単なる継承というようなものなら、
RectangleButtonクラスにRectangleクラスを継承させるのがmixin。おお、古くて新しいw

0138デフォルトの名無しさん

2010/11/17(水) 01:49:04

>>136
>上段
「要は、add_～を呼んでフレームワークに登録する/しないで、その構造体のスペックが決まる。」
とか言われたら普通は実行時にスペックが決まると思うがな。んで、
typedef (A*|B*|C*) IHoge;
で継承みたいなことができるのに継承は無い継承は無いと。
まあ、Itumono人は頭が悪いから聞く方が読み替えたり補ったりするべきとはそうなんだろうが。
残りは分割コンパイル不可能て話。

>中段
>>52、>>56と同じ話。
(HogeA*|HogeB*|HogeCInDllWhichCreatedAfterThisProgramCompiled*)

>下段
プログラミング経験が無いのが分かっているのにも関わらず
itumono人がプログラミング経験を持っていると、あれだけでもう理解できると考えたこちらが悪かった。
>(A*|B*) と (B*|C*) と (A*|B*|C*) はそれぞれ別の型で、何の関連性も無い。
斬新な発想だ。
f(A*);
f((B*|C*));
g((A*|B*|C*)[3]ar){
　f(ar[0]);
　f(ar[1]);
　f(ar[2]);
}

0139デフォルトの名無しさん

2010/11/17(水) 08:18:44

>>136
> C++のテンプレートも触ったことないの？

テンプレートに、そんなユーザを混乱させる機能があるとは初耳だが。

0140デフォルトの名無しさん

2010/11/17(水) 08:24:49

>>139
ちょっと具体的な混乱の例挙げてみてよ
無ければ無いで別にいいけど

0141デフォルトの名無しさん

2010/11/17(水) 18:26:37

>typedef (A*|B*|C*) IHoge;
>で継承みたいなことができるのに継承は無い継承は無いと。

あくまで共用体の扱いだからな。基底クラスが無い以上、継承とは言えんわな。

>残りは分割コンパイル不可能て話。

出来る出来る。その辺は最初っから考えてある。
まー、ライブラリロード時に関数テーブルやらの拡張処理とリンク処理が入るがな。
リンク処理相当は、通常のDLLロード時にも起こるものだから、
テーブルの拡張だけが、Itumono言語特有だな。

あともうややこしいから、適当な内部コードを今から書くよ。
どこかのアプロダにそのうちアップする。それで良いでしょ。

>>139
std::vector< hoge_t >　hoges;
としたとき、hoge_tにコピーコンストラクタが無いと、
コンパイラはエラー吐くでしょ。
hoge_tのコピーコンストラクタが無ぇって。
それは、std::vecotr内で、hoge_tのコピーコンストラクタを呼び出しているからだ。
プログラマが混乱するってのは概ね当たってるんだけど、
コンパイル出来ないから、バグったままプログラムがリリースされることは無い。
そういう意味では、バグを量産するって事は無いな。

0142デフォルトの名無しさん

2010/11/17(水) 19:09:58

なんでこう自分が答えられると思うことに対してだけ答えて、
答えられなさそうなことにはだんまりを決め込むのかね。

0143デフォルトの名無しさん

2010/11/17(水) 19:21:19

>>137
>違いはアップキャストを目的としない
なるほどアップキャストかー
納得した。ありがとう

0144デフォルトの名無しさん

2010/11/17(水) 20:20:19

>>142
答えられないからに決まってんだろ

0145デフォルトの名無しさん

2010/11/17(水) 20:24:16

>>140
大量にあるコードのどこか、プログラマAが担当している部分：
　//if (isHoge()) { ← デバッグ中で付けたり外したりしている
　　add～();
　//}

大量にあるコードのどこか、プログラマBが担当している部分：
　hoge_t* a = ...;
　f(a);

<プログラマA>: やっとバグが取れたぞ～＾＾来週旅行行くからあとはよろしく＾＾
<プログラマB>: なんかビルドする度にバグが再現したりしなかったりするんですけど；；

0146デフォルトの名無しさん

2010/11/17(水) 20:29:37

>>144
いや、知りたいのはそこじゃなくて、答えられないのにもかかわらず
自分のほうがよく物を知っているんだという態度をとり続けているとこ。

0147デフォルトの名無しさん

2010/11/17(水) 20:39:10

(A*|B*)foo1();
(B*|C*)foo2();
(C*|A*)foo3();
void hoge(){
　(A*|B*|C*)p1 = foo1();
　(A*|B*|C*)p2 = foo2();
　(A*|B*|C*)p3 = foo3();
}
>>123
>ポインタからポインタへの代入時は当然型値の変換も行うんだぜ。
らしいけどハッシュでも引くらしい

0148デフォルトの名無しさん

2010/11/17(水) 20:47:42

ハッシュで引くなんて誰が言ったんだよ。
あと、例のバグ大量君はもう無視でいいでしょ。もうわけわからん。

そんで、これ、
http://www.dotup.org/uploda/www.dotup.org1255331.cpp.html
コンパイラの吐き出すであろうコードをC++にしてみた。
突貫工事だからバグあるかもね。

0149デフォルトの名無しさん

2010/11/17(水) 20:51:11

あーと、collectionはs要るんだっけ？
つけてねーや。忘れて。

0150デフォルトの名無しさん

2010/11/17(水) 20:55:28

>>147見れば単なるオフセットの足し引きじゃ実装できないと分かるやろに。
それとも(A*|B*)から(A*|B*|C*)へのキャストは出来ないと？

0151デフォルトの名無しさん

2010/11/17(水) 21:02:13

>>146
http://hibari.2ch.net/test/read.cgi/prog/1262227165/
の有名人らしいぞ

0152デフォルトの名無しさん

2010/11/17(水) 21:02:40

> あと、例のバグ大量君はもう無視でいいでしょ。もうわけわからん。

＾＾；；；

0153デフォルトの名無しさん

2010/11/17(水) 21:12:09

マルチメソッドはどこいったのか

0154デフォルトの名無しさん

2010/11/17(水) 21:52:38

>>136
>遅延ロード云々

auto *func()が遅延ロードされるとき、
pfunc = dlsym(dll, "func");
auto *p = pfunc();
local_func(p);
なるコードで、静的に動くリンカは、
・pの型をどのような共用体(的な何か)として解釈するか
・local_funcをどのように解決するか

世間では遅延ロードの有無によらず
実行時に解決だと思うがどーか？

0155デフォルトの名無しさん

2010/11/17(水) 22:04:17

>>151
> Bertrand Meyer : "OO入門"はOOの聖書. 絶対に読むべき.

らしいから別人じゃね？

0156デフォルトの名無しさん

2010/11/17(水) 22:11:57

>>155
>>151をざくっと斜め読みしたけど
主張がコロコロかわってるから結構ここの人と似てる

0157デフォルトの名無しさん

2010/11/17(水) 23:45:51

素のCでOOというと今は亡きSUNのXViewを思い出す（w

0158デフォルトの名無しさん

2010/11/18(木) 00:03:58

>>153
欲しい？でもコード見れば何時でも対応可能なことは解るよね。
ここまで下地がありゃ後はどうとでもなる。

そして今悩んでるのはこれ。
auto *p;
p = (a*|b*)NULL;
p = (b*|c*)NULL;
のとき、pの型を
( a* | b* | c* )にするか、
( (a*|b*) | (b*|c*) )にするか。
前者はポリモ時のオーバーヘッドが少ないが、文法に整合性がない。汚い。
トップレベルの共用体に限り、纏め上げられる、とか、適当なただし書きが必要だからな。
加えて、ポインタ代入時に型値変換も必要。
後者は分法に整合性があるし、直感的。
型値変換も必要ないし、コンパイラ書くのも楽。
ただし、ポリモ時のオーバーヘッドがデカイ。
加えて、ポリモが何か気持ち悪いことになる。
逆共用体化演算子とかも用意したくなるしな！
記号は@が良いだろうな。あーややこし。プログラマの混乱の元になりそうだ。

>>154
ロードしたときに、auto *pの型が拡張される。
具体的には、型値変換テーブルと、関数テーブルが拡張される。
加えて、local_funcの有無もロード時に確認する。
ランタイムにそれなりの仕込みが必要なんだけど、
ロード時にリンクエラーやらなんやら事前に調べてくれたほうが
プログラマは嬉しいだろう。

0159デフォルトの名無しさん

2010/11/18(木) 00:18:00

それから、向こうのスレの人は俺しらねーぜ。
そのスレ自体しらん。今から読んでくる。

・・・読んできた。

リファクタリングの本だけ読んだことあるなぁ。
えらい分厚いくせに、そのほとんどがコード例で、しかも当たり前のことしか書いてない奴。
たしか、結構なお値段だったような。俺は研究室に置いてあったから、タダ見だが。
読まなくても解ってる奴は解ってるし、
解ってない奴は、読んでも解らん。そんな類の本だった記憶が。

あ、Rubyは美しいとか言ってるw

Pythonねぇ。selfはキモイだろう。
構造体にCスタイルの関数を突っ込めます。第一引数は自動でわたりますってアイデアは悪くないのだが、
なにか釈然としない。

全部読むと頭がおかしくなるからもう読まない。大分マズイ方向へ行ってる人だね。

0160デフォルトの名無しさん

2010/11/18(木) 00:22:06

>>150
>>148で上げたデモで、まったくそのまま、それをやってるよ。
テーブル用意して変換してる。

0161デフォルトの名無しさん

2010/11/18(木) 04:06:17

なんかOOPって深くやればやるほどめんどくさくなるよねえ。
再利用とか隠蔽なんかしなくていいから、俺はパッと見てわかりやすいソフトが作れればいいや。

0162デフォルトの名無しさん

2010/11/18(木) 07:45:54

>>161
Prolog

0163デフォルトの名無しさん

2010/11/18(木) 07:48:15

>>161
LISP

0164デフォルトの名無しさん

2010/11/18(木) 08:17:38

>>161
規模の大きなソフトウェアや、メンテナンス時に地獄を見る発想。

0165デフォルトの名無しさん

2010/11/18(木) 09:15:22

俺はパッと見てわかりやすくするための、
隠蔽なんだがｗ
で、それをするってことは、その単位が再利用しやすくなってるわけで。

0166デフォルトの名無しさん

2010/11/18(木) 10:06:51

さんざんテンプレートやら型推論、ダックタイピングがどうのこうの言ってたのに
いまさらパッと見で分かりやすいとか言われてもね

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