- 1 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 09:52:47 ]
- 文法面での機能拡張しすぎ。
C++の構文解析とか、もうワケワカメ。
マイクロソフト拡張大杉。
gcnew とか使うぐらいなら素直に Java でも C# でもつかえ！！！
- 175 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 00:23:14 ]
- その昔、Java で interface を知った瞬間にすべてが分かった。
実装方向からの理解だと、シグニチャからのメソッドの検索ね。
同一型のデータの集合をクラスと捉えるよりも、メソッド集合を
クラス、あるいはプロトタイプと捉えた方が理解が簡単かな…
データなんて飾りですってことで。
- 176 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 01:02:51 ]
- >>172
オブジェクト指向の歴史はしらんが、現在ではある概念の一つでありプログラミングのみで登場する概念ではない。
オブジェクト指向プログラミングとは、一種のプログラム設計の方針であり、クラスの有無とは本質的には無関係である。
しかしながら、現実的にはC++などはクラスを使用することでオブジェクト指向に基づくであろう設計方針を取れる。
オブジェクト指向とは、
１、オブジェクトという単位を基準に考えること。（オブジェクトは部品、と訳すと割といい。）
２、オブジェクトはオブジェクトとやり取りに注目していること。（メンバ関数/イベント等をインスタンスへの命令と考える。）
３、オブジェクトはオブジェクト以上にはなりえないこと。（カプセル化に関連。オブジェクトとして考えていたものがオブジェクトとして認識できなくなる操作はNGという事）
４、オブジェクトはどのオブジェクトとどのような関係があるか、わかること。（has-a、is-aがしっかりとわかること。継承や集約といった関連がどうなっているかわかること）
括弧内はプログラミングから見た場合。
こんなかなぁ･･･怪しいものだ。
- 177 名前：デフォルトの名無しさん [2008/03/11(火) 01:50:32 ]
- >>176
それは、"鋳像と、その鋳型の関係を考える"事じゃないのか?
- 178 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 03:16:10 ]
- >>177
括弧内じゃないほうは鋳像（･･･このスレではじめてみたが）と鋳型という考えは出てないと思うけど。
あとオブジェクト指向の指向は考える、とか定める、とか基準にする、とかに準拠する、という意味合いが強い気がするから、
"〜を考える"ことは割りと定義としてはあってると思うんだが
- 179 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 09:08:51 ]
- >鋳像(実像)と鋳型(モデル)の関係があって初めてオブジェクト指向が成立するものだと思うが
これはまさにクラスだけど、現実世界ってそうじゃないんだおね。
ニューアカの粘菌の説明なんかであったが、
粘菌とはこういうものだと定義しようとするが、
粘菌は場所が変わると色んな風に変化してて、
そのカテゴリーから外れる、みたいな。
動植物の定義でも外れるもの出てくるし、哺乳類の定義でもそう。
結局クラスってのは現実世界とあってない。
- 180 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 10:13:25 ]
- >>178
馬車の鋳像を作ると仮定して
その鋳像は、馬も車輪も御者も全て一緒に作るのか
馬車であることに拘り、本体、車輪、馬、御者をバラバラに作り後から組み立てるのか
それとも、馬や御者は陶器で作成して、馬車のみを精密に鋳像にするのか(屋根を開くようにして中に乗客を乗せることが出来るようにするとか)
>>176の言ってることってこう言うことだよね?
でも、これは、馬車の鋳像の事を考えているように見えて、馬車の鋳像の鋳型の事を考えているよね
でもって、作り出された鋳像の話にすると
車体と車輪を分けて鋳造された場合、きちんと組み立てて馬車の鋳像あるだろうが
中には、一つの車輪をわざと外し、壊れた馬車の鋳像にしている場合も有るだろう
これは、鋳型(クラス、プロトタイプ)から作られた、鋳像(インスタンス)は、鋳型と同じ姿(機能)を有しているが
鋳像同士の使われかたは、別々だと言うこと
これらが意識できない限り、クラスやプロトタイプは変な使われかたをして、作った奴死ねってなるだけの話さ
- 181 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 10:19:43 ]
- そうだね、車輪だと分かり難いけど、鋳造から作った部品を変形させて別物にしたりするよね現実では。
- 182 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 10:34:01 ]
- >>179
それは、クラスとインスタンスの関係を理解していないだけ
- 183 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 10:38:14 ]
- >>182
そうじゃない。
クラスでは現実世界を記述するには役不足。
- 184 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 10:48:48 ]
- >>183
三毛猫は、猫だが、黒猫ではない、だから猫は猫を表現するには役不足だ
と言われて、どう思うよ
- 185 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 10:56:23 ]
- >>180
なんだろ・・・すごい話がかみ合ってない希ガス。
オブジェクト指向はUMLが最もそれらしく体現してるかな。
鋳型を考える手前までの作業がオブジェクト指向。
そこからクラス＝(鋳型)を作る行為はオブジェクト指向とは無関係だと思う。
というか鋳型という表現が良くない。鋳型ではなくカテゴリーとかそこら辺がそれっぽい。
カテゴリーならオブジェクト指向の範疇。
>>180の例でもそうなんだが、それは鋳型（オブジェクトの設計図）を考えること直結してるとは思えない。
少なくともそんなことをオブジェクト指向を何も知らない人はそんなことは思わない。
そして、その例は間違いなくオブジェクト指向してる様に見えるんだが、その例はオブジェクト指向じゃないの？
あと後半の説明は明らかに誤解を招く。どう考えてもインスタンスとクラスは同じ姿（機能）をしてないだろうと。
- 186 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 10:57:48 ]
- だめだ、日本語がわけわかめになってるな。そんなことが同じ文の中に2回登場してるorz
- 187 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 10:59:41 ]
- >>184
現実にはイノシシからブタが発生したりするわけ。
実行時にクラスが増えていくって感じ？
さらにもっと良く見ると、１つ１つのクラス違ってるじゃん、みたいな。
純粋にオブジェクト指向で現実を記述するってのと、
簡単な業務アプリのスタティックなクラスは、
無限の隔たりがあるの。
- 188 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:01:03 ]
- ＞現実にはイノシシからブタが発生したりするわけ。
＞実行時にクラスが増えていくって感じ？
もう少し説明すると、記述して計画的にクラスが分岐するんじゃなくて、
実行した結果分岐しちゃった、みたいな。
だから、スタティックなクラスじゃ書けない。
- 189 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:04:45 ]
- ＞実行時にクラスが増えていくって感じ？
例えばキケイで足が１本少ないってなったとき、
じゃ、足の本数をメンバ変数にすれば良いじゃん、
って単純な話じゃない。
原生生物に突起が出来て、あるとき足と呼ばれるようになった、みたいな。
- 190 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:11:15 ]
- >>188
別に現実世界とオブジェクト指向の隔たりを否定しているレスは無いだろうと常考
>>189
オブジェクト指向プログラミングは現実世界を投影するのが目的じゃないだろう
- 191 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:12:39 ]
- ＞オブジェクト指向プログラミングは現実世界を投影するのが目的じゃないだろう
おまいＯＯわかって無いだろう、ｊｋ
- 192 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:15:44 ]
- >>191
言い方が悪かった
オブジェクト指向プログラミングは現実世界を投影するのが『最終』目的ではないだろう
- 193 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:18:39 ]
- 身近から言うと業務アプリは業務を投影するし、
極端なことを言うと地球シミュレーターは地球を投影する。
人工知能で顔を判別するには顔を投影する。
で？
- 194 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:21:45 ]
- >>193
やっぱりそういう勘違いをしてるのか･･･
- 195 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:21:48 ]
- 俺は、>>191が判ってないのに1票
>>180と>>185は、言葉の違いを言い争ってるのに1票(パンクとメタルの違いみたいなぁ)
クラスから発生したインスタンスは、クラスにはならない
プロトタイプから発生したインスタンスは、プロトタイプになる
そう言いたいので有れば、説明のしかたがおかしい
さらに言うなら、それはオブジェクト指向の話でもなんでも無く、コンパイラとインタプリタの話であり、ややこしくなるだけだから、口を開くな禿
- 196 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:24:39 ]
- >>194
投影、を勘違いと思うなら、OOを勘違いだといってるのと同じ。
この議論の外の話。
- 197 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:25:23 ]
- ＞さらに言うなら、それはオブジェクト指向の話でもなんでも無く、コンパイラとインタプリタの話であり、ややこしくなるだけだから
強烈に頭が悪い悪寒。
- 198 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:26:31 ]
- どっちにしろ、ＯＯってのは現実世界の投影。
それを否定する人は、別の議論に入って良いけど、この議論には入るな！
- 199 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:30:00 ]
- ＞>>180と>>185は、言葉の違いを言い争ってるのに1票(パンクとメタルの違いみたいなぁ)
これ、強烈に頭割る杉。
- 200 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:31:59 ]
- >>196
>>193の例で言えば業務アプリのプログラムを組もうとすることはoopと無関係である。
別にoopでなくとも可能かも知れないし、oopの場合現実世界を必ず投影しなければいけないわけではない。
oopは安全性の向上、再利用性の向上、が目的だろ。
現実世界を投影することとoopで使うことを前提としたクラスライブラリを作ることが同じと申すか。
>>195
185だが、自分で言うのもなんだが確かに不毛。
- 201 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:32:55 ]
- ＞>>180と>>185は、言葉の違いを言い争ってるのに1票(パンクとメタルの違いみたいなぁ)
こいつが頭悪いと言い切れるのは、
学問的にも、クラスベースＯＯとオブジェクトベースＯＯは別物となってて、
既にクラスを推奨しているboochは異端だとか電波だとか言われている。
クラスベースにしがみつく＝キティ
- 202 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:34:28 ]
- ＞oopは安全性の向上、再利用性の向上、が目的だろ。
これは間違い。
手続きプログラミングに対してクラスベースの効果として、安全性、再利用性は言われるもの。
しかし、前述のとおり、ＯＯとしてはクラスベースは異端。
- 203 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:40:19 ]
- >>201
初めて知ったわ。なんかそれぞれの学術書でもあるん？
- 204 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:43:09 ]
- 何を分かった風な。
- 205 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:46:24 ]
- >>202
え、oopの目的って（Cににた言語なら）生産性、安全性、再利用性の向上だと思ってたけど。
何が目的なの？･･･というかそもそも設計方針だからルールはあっても目的とか無いのか･･･。
- 206 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:49:02 ]
- 一人、強烈にオブジェクト指向を理解してないやつが居ることだけは確実だって事だな
しかも、人の説明は違うと言いつつ、自分では何の説明もしないあたり、相当な...
- 207 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 12:21:05 ]
- ＯＯの本流に一番近いのはＲｕｂｙかな
- 208 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 12:25:33 ]
- 一つの言語でまかなえれば、それは楽で良いだろうが
目的に応じて使用する言語を選べる方が、よりオブジェクト指向だと言えるな
- 209 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 12:27:26 ]
- ＞目的に応じて使用する言語を選べる方が、よりオブジェクト指向だと言えるな
おまいのいうオブジェクト指向ってのは、開発のノリのこと？
いわゆる何に対しても、”ロック”、の一言で終わらせるあれ？
- 210 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 12:30:25 ]
- >>209
馬鹿は黙ってろ
- 211 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 12:31:47 ]
- ＞馬鹿は黙ってろ
やっぱ脳みそツルツルの体育会系じゃねーか。
おま、マに向いてないお。
- 212 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 12:36:40 ]
- >>211
プロトタイプとインスタンスの関係も理解できてないのに大きな口を叩くな
理解できてるなら、説明して見ろ
話はそこからだ
- 213 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 14:35:57 ]
- オブジェクト指向は現実世界の投影じゃないよ。
言うなればドメイン(問題領域)の投影だよ。
物理学者ならアレだけど。
プロトタイプは原型だよね(英単語的な意味で)
クラスは変な表現になるけど、興味の対象だよ。
インスタンスとプロトタイプは似てたりもするけどね。
ところで、ここ何のスレ？
- 214 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 14:37:31 ]
- ドメイン(問題領域)の投影
の一例として
現実世界の投影だろ？
213=ヴぁか？
- 215 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 14:41:16 ]
- >>214
だから馬鹿は黙ってろ
話題に混じりたいなら、プロトタイプとインスタンスの関係を説明してから混じれ
- 216 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 14:57:07 ]
- a)オブジェクト指向は現実世界の投影じゃないよ。
b)ドメイン(問題領域)の投影だよ。
c)物理学者ならアレだけど。
aとbを比べたらbの方が巨大。
bはaを含む。
だから、aの「じゃないよ。」は成り立たない。
さらにcで「ならアレだけど」と例外的に書いているのはさらに変。
物理学者だからこそ現実世界以外の問題領域が必要になるわけで、
物理学者じゃないならaで十分ｗ
- 217 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 14:58:40 ]
- >>214
一例になるから213は物理学者ならって書いてるんじゃね？
- 218 名前：213 mailto:sage [2008/03/11(火) 15:03:49 ]
- >>216
オブジェクト指向＝現実世界の投影じゃ〜
って書いた方が良かったかな。
- 219 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 15:04:09 ]
- >>217
いや、
現実世界の投影 ∈ ドメイン(問題領域)の投影
なの。
「現実世界の投影」の方が小さい。
- 220 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 15:05:07 ]
- ＞ドメイン(問題領域)の投影
ってのは、現実にあるもの無いもの含んで超巨大。
これこそ物理学者にふさわしい。
- 221 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 15:08:35 ]
- >>219
プロトタイプとインスタンスの区別も付かない奴に何を言っても無駄
>>220
馬鹿は黙ってろ
- 222 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 15:15:05 ]
- >>219
だからそう言ってんじゃんｗ
どう読んでんだよｗ
213はイコールじゃないって言いたいんだろ
- 223 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 15:17:42 ]
- >>222
あ、自分の読み間違い？
良く分からないけど、ま、次の話題にすすみますか。
- 224 名前：213 mailto:sage [2008/03/11(火) 15:26:51 ]
- 現実世界の投影はドメインの投影に含まれると思っています。
物理学者なら現実世界（シミュレーション的な意味で）をドメインとすることもあるかもね、
というつもりで書きました。
「アレ」では端折り過ぎでした。すみません。
まぁ、次の話題へどうぞ。
- 225 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 15:28:41 ]
- では、ＯＯとしてドメインの投影するには、どんな言語が良いのだ？
- 226 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 15:46:33 ]
- C++でイナフ
- 227 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 18:43:05 ]
- >>209あたりからのレスの進み方を見て、oopが分からない人が多い理由が分かった
- 228 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 22:44:48 ]
- 別に分かっていなくても、奇抜なプログラムを書かず、
そのとき使っている環境で普通とされるコードを書ければそれでいい。
- 229 名前：デフォルトの名無しさん [2008/03/12(水) 08:36:17 ]
- STL、boostが既に奇抜なプログラムな現実について。
- 230 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 08:51:12 ]
- C++ではSTLくらい普通の内です。
- 231 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 13:16:03 ]
- 現状のSTLは欠陥品って報告が数多くでてるじゃん
- 232 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 13:43:10 ]
- ふーん、その欠陥品を模造したものがSTLドトネト→STL.CLIでつか。
- 233 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 15:21:31 ]
- 見捨てた奴スレのレベルの低さから、何かが解るような気がする・・・
- 234 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 16:10:56 ]
- >>231
だからと言って標準ライブラリに代わりがあるわけではないし、
C++を使わない決定的な理由にならない。
- 235 名前：デフォルトの名無しさん [2008/03/12(水) 19:43:05 ]
- www.nicovideo.jp/watch/sm2482689
C++のエラーは黒魔術
- 236 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 19:58:38 ]
- キャスト演算子のオーバーロードをしたいと言うとき、
C++の場合はポインタが足枷になる
大抵は派生クラスにして終わりなんだが、newできないクラスのラッパを作る時に不便だ
勿論getterも書くが…個人的にはgetterはあまり増やしたくないな
- 237 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 21:48:56 ]
- 10年間変わっていない。
しかもあと10年は変わりそうにない言語を
肥大化というのもおかしくないか。
- 238 名前：デフォルトの名無しさん [2008/03/12(水) 23:12:57 ]
- >>231
まだVC6使ってんのか？
- 239 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 00:44:51 ]
- かれこれ20年近くC++を使ってきたが・・・
まぁ、いろいろな意味と理由で負の遺産となりつつある。
場合によってはCOBOLより凶悪な事態を招きかねない、早いうちに廃棄処分方針をとった方が良いだろうとは思う、さすがに。
固執する人もいるが、そういった人には一度離れて別の言語を見て回ってみろと言いたい、
開発環境・コンパイラといった物から、言語使用その他あらゆる点で時代遅れになっているので……
唯一進んでいるのはboostとその周辺だろうが、これらがメインになるのは恐らく難しいだろう。
- 240 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 01:02:01 ]
- そもそも元になってるCに言語としての一貫性と言うか、仕様の一貫性が無いのが気に入らないんだ。
変数宣言は「型、名前」っていう順番で統一するべきだった。
ポインタを複数宣言する時は
char *a, *b, *c
ではなく
char* a, b, c
のほうが自然だし、そもそも char* を typedef していれば
pchar a, b, c
と書けるという事を考えると。
関数ポインタにしても
void (*hoge)(char*, char*)
ではなく、単に
(void (char*, char*)) *hoge
としてくれた方が素直だったのでは。
- 241 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 01:13:00 ]
- それもそうだが、まずtypedefの構文をもっとまともにすべきだったね。
- 242 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 01:15:23 ]
- 問題はC++の次が何か？ってことで、Cの上位互換なら
Objective-Cという選択肢も一応あるんですがねえ…。
- 243 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 01:16:00 ]
- C言語から引き継がれた機能のうち最大の問題はプリプロセッサだと思うけどね。
>>241
typedef については、これ以上どうしろと・・・
- 244 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 01:22:27 ]
- 関数ポインタのことじゃない？
typedef void(FUNCP*)(int);
これは最初戸惑った。
typedef void(*)(int) FUNCP;
せめてこうなるべきなんじゃないか？と。
- 245 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 01:25:07 ]
- >>244
それは、宣言の書き方であって typedef 関係ない
- 246 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 01:36:55 ]
- typedefが記憶クラス指定子ってところがおかしいだろ。
- 247 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 01:42:10 ]
- どこがよwwww
それでも問題ないし、そもそも記憶クラスじゃないし。
- 248 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 02:01:56 ]
- >>247
そう、記憶クラスじゃないのに記憶クラス指定子にされているのがなんか気になる。
普段は意識しないし、実用上困ったこともないけどさ。
- 249 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 10:56:42 ]
- >>240
そもそも char* 等は型ではない。
関数プロトタイプに char* と書くようになってから一貫性がなくなってきてるけどね。
>>247
typedef は Storage-Class Specifier ではない。
- 250 名前：デフォルトの名無しさん mailto:sage [2008/03/13(木) 18:50:53 ]
- >>240
でもそれって配列と文法をあわせてるからでしょ。
むしろ他の言語で配列の初期化周りが統一感ない文法が多くて気持ち悪いが。
- 251 名前：デフォルトの名無しさん [2008/03/13(木) 22:05:20 ]
- >>243
プリミティブ型からポインタ型や配列型を作れる言語では、
Cの構文以外で一貫性のある型表記を決めるとすると、
関数型言語みたいに「型から型を作る」という意識に立って
typedef &char charptr;
static (const int)*5 intarray;
(int, int) -> void func = { ... };
&((int, int) -> void) funcp;
のように表現せざるを得ない。
で、Cにはタプルもカリー化もないのだから、
わざわざ変数の使い方から乖離した型表記を作る必要はない。
- 252 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 10:03:01 ]
- >>251
関数型の世界しか頭になさそうなアホちんですね
組み込み等では大変役に立ったモンですよ
- 253 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 10:14:55 ]
- >>250
ｋｗｓｋ
>>251
レス番間違えてない？
>>252
よく読んでない悪寒
- 254 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 10:28:57 ]
- 熟読した上で、まるで理解できず見当違いの煽りに走った、が正解。
- 255 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 12:10:49 ]
- >>253
いや、確かに前と後ろにつける違いがあるけど、どちらも変数につけるじゃん。宣言する時も使用するときも。
ポインタの文法は型にくっつけるべきだというなら、配列の宣言も[]は型にくっつけるべきだぜ。
- 256 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 16:58:18 ]
- 入れ子状の宣言文上で複数の変数を宣言するから分りにくくなるだけで
とどのつまり、変数は一つづつ宣言させればいいのさ
それはプログラマがそうすればいいだけの話で、一行に一個づつ変数を宣言しろと。
つか、型宣言はC言語の問題の中では一貫性があり重大な欠陥の少ない部類だろ
なんでこんな所にイチャモンつけてんだか
関数ポインタや、配列返し const volatile register の修飾先が分りにくくて初心者がパニックを起こすのはちと考え物だとは思うが。
- 257 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 18:04:45 ]
- // C, C++
int *x,y; // xはintへのポインタ, yはint型
int x[N],y; // xはintの配列, yはint型
// C++ typedef
typedef int* pint;
pint x,y; // xとyはintへのポインタ
// java
int[] x,y; // xとyは int[]型
// C#
int* x,y; // xとyは intへのポインタ
int[] x,y; // xとyは int[]型
// D
int* x,y; // xとyは intへのポインタ
int[] x,y; // xとyは intの配列
int[3]*[5] x; // xは int の3要素配列 へのポインタ の5要素配列
いまさらC,C++の宣言の仕様が変わることは有り得ないけど、
新しい言語がCの宣言を否定しているので、
イチャモン？をつける人が出ても、まぁ致し方ないとは思う。
どうせ標準化委員会のメンバーでもないんだし、
気楽に論争(雑談)して良いと思うよ。
- 258 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 18:44:16 ]
- Cのparserを書こうとすると、Cの宣言の構文が嫌になる。
型名と変数名を区別するのに苦労させられるのがたまらん。
- 259 名前：デフォルトの名無しさん mailto:sage [2008/03/14(金) 21:35:00 ]
- 変数の宣言部分なんて、C++の話じゃなくて、Cの話だしな
- 260 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 04:12:13 ]
- >>258
スキャナで適当に区別してしまえよ、せっかく1 passで解析できるように出来ている構文なんだからさ。
それより、古き良き時代で大変役に立った機能が、今、逆に大きな弊害になっている点に突っ込めよ。
インテリセンス・デザイナ・リファクタリングツール・テストツール
リンクを高速に処理可能な抽象度の高い中間ファイル
モダンな機能が組み込み困難になっている現状こそが問題だろ。
- 261 名前：デフォルトの名無しさん mailto:sage [2008/03/16(日) 01:54:31 ]
- [迷信] 識別子に使える文字は英数字と下線のみ
ttp://www.kijineko.co.jp/tech/superstitions/only-alnums-and-underscore-are-usable-for-identifier.html
- 262 名前：デフォルトの名無しさん mailto:sage [2008/03/16(日) 04:22:46 ]
- >>261
ヨーロッパのマが書いたコードを見れば結構出現頻度高いんだよ、それ
日本やアメリカではお目にかからないけど
- 263 名前：デフォルトの名無しさん mailto:sage [2008/03/16(日) 08:13:45 ]
- まぁ、javaやC#とかでも日本語識別子使えるけど、
文字列以外でASCIIでない文字を使うプログラマはカス
日本語プログラミング言語は別だけど
- 264 名前：デフォルトの名無しさん mailto:sage [2008/03/16(日) 15:05:19 ]
- もうウニコードベースにすりゃいいのに
- 265 名前：デフォルトの名無しさん mailto:sage [2008/03/16(日) 17:22:02 ]
- >>263
日本語ラベルは便利だぞ、C/C++だとラベルはラベル、実行コードは実行コードと分かれているが
リフレクションを持つJavaやC#では、構造体のラベル名を読み取って、そのまま活用できるから、
例えば表のタイトル文字列と、構造体のメンバの名前で表示するとか、XMLの内容をラベル名で出力するとか。
一箇所修正するだけで、全部修正完了するのは便利だ。
- 266 名前：デフォルトの名無しさん mailto:sage [2008/03/16(日) 20:41:58 ]
- まさに、そういう考えの人が多いからこそ嫌いなんだけどな
間違ってるとまでは言わないが
ただ、システムの識別子はリファクタリング以外では変えるべきじゃないし
表示名のような業務要件で変わる外部のものと、内部のものを密結合にされると
逆に面倒なことになることもある
- 267 名前：デフォルトの名無しさん mailto:sage [2008/03/17(月) 05:18:58 ]
- リファクタリグツールから名前を変更すれば、関わる "識別子=表示名" を根こそぎ全部置換してくれるから、変更漏れがなくていいと思うんだが。
それに、他人に説明するときに対応関係を説明する手間も省けるし。
- 268 名前：デフォルトの名無しさん [2008/04/23(水) 11:39:07 ]
- >>179
粘菌の本質をベースクラスとして定義し
そこから派生クラスで環境依存部分を定義する
後は、派生クラス側で
operator=()をベースクラスのコピーと派生クラスの初期化に定義し直せば、動的に粘菌の性質を変更できるんじゃないのか?
- 269 名前：デフォルトの名無しさん mailto:sage [2008/04/23(水) 11:48:50 ]
- 俺はC++を見捨てたというより使いこなせるようになるのを諦めた。
- 270 名前：デフォルトの名無しさん mailto:sage [2008/04/24(木) 00:12:27 ]
- 自分を見限ったという事ですか。
- 271 名前：デフォルトの名無しさん mailto:sage [2008/04/24(木) 00:37:32 ]
- そうでーす
- 272 名前：デフォルトの名無しさん mailto:sage [2008/04/24(木) 12:26:49 ]
- >>268
いや、そーじゃなくて、プログラミング言語以前に、粘菌とはこれだという定義ができないって話らしいお。
- 273 名前：デフォルトの名無しさん [2008/04/24(木) 16:04:17 ]
- >>272
定義できないなら、それが粘菌であるかどうかすらわかんないじゃん
例えば、
「晴れたら、小さな芋虫みたいになって、四方八方に散らばり」
「雨が降ったら、ぬちゃぬちゃで繊維質な物体になる」
って性質を持って居るように見えて
本当は、
「晴れたら、小さな芋虫に捕食され、雨が降ったら、その芋虫を養分に育つ」
のが本当の姿である可能性もあるじゃん
その場合、クラスだの、プロトタイプだの関係なく、オブジェクトの設計そのものに失敗しているってことじゃん
- 274 名前：デフォルトの名無しさん [2008/04/24(木) 16:20:48 ]
- 名前考えるのめんどくさいよね。
日本語でおkになってほしい。
- 275 名前：デフォルトの名無しさん mailto:sage [2008/04/24(木) 16:27:56 ]
- ＞オブジェクトの設計そのものに失敗しているってことじゃん
ま、つまり、そういうことだ。
現実は、オブジェクト設計を失敗してるってこと。
【謎飼育】正体不明の謎生物を7年間に渡って飼育している動物園
ttp://karapaia.livedoor.biz/archives/51124187.html
遺伝子組み換えで、生物どころか単なるパーツが作られちゃうかも。
|
 |
