【肥大化】C++ を見捨てたヤシ【複雑化】

【肥大化】C++ を見捨 ..

159:デフォルトの名無しさん
08/03/10 12:24:42
>>158
それだとクラスって何って話になるじゃん
クラスは、型の動作定義にしか過ぎないわけだし、クラス宣言指向では意味がわからん

160:デフォルトの名無しさん
08/03/10 13:00:06
そもそもオブジェクトとは何かを理解するのが重要なのに、
オブジェクトって言葉が消えるのは具合が悪い。

161:デフォルトの名無しさん
08/03/10 13:06:36
それは認識間違いです。

完全なオブジェクト指向じゃないのがクラスベース言語。
オブジェクト指向を想定してクラスベース言語を理解しようとするから難関。
素直にクラスの文法を学べば良い。

そうじゃなくて完全なオブジェクト指向を目指すなら、オブジェクトベース言語に逝こう。

162:デフォルトの名無しさん
08/03/10 13:59:17
オブジェクトが何かというのが大切であるなら、英語のオブジェクトをオブジェクトのまま扱っている方が問題
だから、"物"なんていう直訳の極みを説明に出してしまう事になる
オブジェクト指向のオブジェクトは、"物"ではなく"鋳像"と訳すべきであり
概念としては、"鋳像と、その鋳型の関係を考える"ことがオブジェクト指向だろう

163:デフォルトの名無しさん
08/03/10 14:06:40
＞オブジェクト指向のオブジェクトは、"物"ではなく"鋳像"と訳すべきであり

それは違う。

鋳像となってるのはクラスベースＯＯＰの話。

ミスリード激し杉。

164:デフォルトの名無しさん
08/03/10 14:11:26
つかRubyあればあとはイラネ

165:デフォルトの名無しさん
08/03/10 14:24:33
>>163がオブジェクトの説明を素人にも判りやすく説明してくれるというので期待上げ！！！

166:デフォルトの名無しさん
08/03/10 17:25:09
>>163
オブジェクト指向の判りやすい説明はどうしたの
早く教えてくれよ

167:デフォルトの名無しさん
08/03/10 17:28:54
　　 ∩＿＿＿∩
　　 | ノ　　　　　ヽ
　　/　　●　　　● |
　 |　　　　( _●_)　ミ
　彡､　　　|∪|　　､｀＼
/　＿＿　ヽノ　/´>　 )
(＿＿＿）f^f^f^f^f^f^f^f^f^┐
　|　　　　|~ ~ ~ ~ ~ ~ ~ ~ ~ │
　|　　　　|　知ってるが　 │
　|　　／ |　お前の熊度が |
　|　/　　|　　気にクマない |
　∪　　 |______＿＿＿＿＿|
　　　　　　　＼＿)

168:デフォルトの名無しさん
08/03/10 17:33:57
>>167
お前には失望した
嘘吐き小僧の名を進呈しよう

169:デフォルトの名無しさん
08/03/10 19:08:49
URLﾘﾝｸ(codezine.jp)

このようなクラス-インスタンスという概念を使用するオブジェクト指向言語のことを、クラスベースオブジェクト指向言語（Class Based Object Oriented Language）と言います。

　それとは異なり、JavaScriptではクラス-インスタンスという考え方をしません。
オブジェクトは別なオブジェクトを元（プロトタイプ）にして独自の特徴を付加することで存在する、という考え方をします。
このようなオブジェクト指向言語のことを、プロトタイプベースオブジェクト指向言語（Prototype Based Object Oriented Language）と言います。

170:デフォルトの名無しさん
08/03/10 21:42:34
>>169
その説明だと、クラスとプロトタイプの違いがさっぱりわからん
もっと優しく説明してくれないか

171:デフォルトの名無しさん
08/03/10 22:19:55
クラスベースはプラモデル
プロトタイプベースはレゴ
ってかんじかね。

172:デフォルトの名無しさん
08/03/10 22:36:34
>>171
その説明だと、>>163の>>162に対するミスリード発言が深い謎になるのだが?

173:デフォルトの名無しさん
08/03/10 23:10:42
プロトタイプベースは鋳像とその鋳型（＝クラス）の関係じゃないことは確か。

174:デフォルトの名無しさん
08/03/11 00:02:58
>>173
実行中に形が変わるから、違うものだと言うのか?
クラスが作れるからオブジェクト指向ではないし、プロトタイプが作れるからオブジェクト指向でもない

鋳像(実像)と鋳型(モデル)の関係があって初めてオブジェクト指向が成立するものだと思うが
同じ物を同じ物として作ることが出来、なおかつ、作り出された一つ一つは個性を失わない
それが出来て初めてオブジェクト指向と言えると思うけどな

175:デフォルトの名無しさん
08/03/11 00:23:14
その昔、Java で interface を知った瞬間にすべてが分かった。
実装方向からの理解だと、シグニチャからのメソッドの検索ね。
同一型のデータの集合をクラスと捉えるよりも、メソッド集合を
クラス、あるいはプロトタイプと捉えた方が理解が簡単かな…

データなんて飾りですってことで。

176:デフォルトの名無しさん
08/03/11 01:02:51
>>172
オブジェクト指向の歴史はしらんが、現在ではある概念の一つでありプログラミングのみで登場する概念ではない。
オブジェクト指向プログラミングとは、一種のプログラム設計の方針であり、クラスの有無とは本質的には無関係である。
しかしながら、現実的にはC++などはクラスを使用することでオブジェクト指向に基づくであろう設計方針を取れる。

オブジェクト指向とは、
１、オブジェクトという単位を基準に考えること。（オブジェクトは部品、と訳すと割といい。）
２、オブジェクトはオブジェクトとやり取りに注目していること。（メンバ関数/イベント等をインスタンスへの命令と考える。）
３、オブジェクトはオブジェクト以上にはなりえないこと。（カプセル化に関連。オブジェクトとして考えていたものがオブジェクトとして認識できなくなる操作はNGという事）
４、オブジェクトはどのオブジェクトとどのような関係があるか、わかること。（has-a、is-aがしっかりとわかること。継承や集約といった関連がどうなっているかわかること）

括弧内はプログラミングから見た場合。
こんなかなぁ･･･怪しいものだ。

177:デフォルトの名無しさん
08/03/11 01:50:32
>>176
それは、"鋳像と、その鋳型の関係を考える"事じゃないのか?

178:デフォルトの名無しさん
08/03/11 03:16:10
>>177
括弧内じゃないほうは鋳像（･･･このスレではじめてみたが）と鋳型という考えは出てないと思うけど。
あとオブジェクト指向の指向は考える、とか定める、とか基準にする、とかに準拠する、という意味合いが強い気がするから、
"～を考える"ことは割りと定義としてはあってると思うんだが

179:デフォルトの名無しさん
08/03/11 09:08:51
>鋳像(実像)と鋳型(モデル)の関係があって初めてオブジェクト指向が成立するものだと思うが

これはまさにクラスだけど、現実世界ってそうじゃないんだおね。

ニューアカの粘菌の説明なんかであったが、
粘菌とはこういうものだと定義しようとするが、
粘菌は場所が変わると色んな風に変化してて、
そのカテゴリーから外れる、みたいな。

動植物の定義でも外れるもの出てくるし、哺乳類の定義でもそう。
結局クラスってのは現実世界とあってない。

180:デフォルトの名無しさん
08/03/11 10:13:25
>>178
馬車の鋳像を作ると仮定して
その鋳像は、馬も車輪も御者も全て一緒に作るのか
馬車であることに拘り、本体、車輪、馬、御者をバラバラに作り後から組み立てるのか
それとも、馬や御者は陶器で作成して、馬車のみを精密に鋳像にするのか(屋根を開くようにして中に乗客を乗せることが出来るようにするとか)
>>176の言ってることってこう言うことだよね?
でも、これは、馬車の鋳像の事を考えているように見えて、馬車の鋳像の鋳型の事を考えているよね

でもって、作り出された鋳像の話にすると
車体と車輪を分けて鋳造された場合、きちんと組み立てて馬車の鋳像あるだろうが
中には、一つの車輪をわざと外し、壊れた馬車の鋳像にしている場合も有るだろう

これは、鋳型(クラス、プロトタイプ)から作られた、鋳像(インスタンス)は、鋳型と同じ姿(機能)を有しているが
鋳像同士の使われかたは、別々だと言うこと

これらが意識できない限り、クラスやプロトタイプは変な使われかたをして、作った奴死ねってなるだけの話さ

181:デフォルトの名無しさん
08/03/11 10:19:43
そうだね、車輪だと分かり難いけど、鋳造から作った部品を変形させて別物にしたりするよね現実では。

182:デフォルトの名無しさん
08/03/11 10:34:01
>>179
それは、クラスとインスタンスの関係を理解していないだけ

183:デフォルトの名無しさん
08/03/11 10:38:14
>>182
そうじゃない。
クラスでは現実世界を記述するには役不足。

184:デフォルトの名無しさん
08/03/11 10:48:48
>>183
三毛猫は、猫だが、黒猫ではない、だから猫は猫を表現するには役不足だ

と言われて、どう思うよ

185:デフォルトの名無しさん
08/03/11 10:56:23
>>180
なんだろ・・・すごい話がかみ合ってない希ガス。

オブジェクト指向はUMLが最もそれらしく体現してるかな。
鋳型を考える手前までの作業がオブジェクト指向。
そこからクラス＝(鋳型)を作る行為はオブジェクト指向とは無関係だと思う。
というか鋳型という表現が良くない。鋳型ではなくカテゴリーとかそこら辺がそれっぽい。
カテゴリーならオブジェクト指向の範疇。

>>180の例でもそうなんだが、それは鋳型（オブジェクトの設計図）を考えること直結してるとは思えない。
少なくともそんなことをオブジェクト指向を何も知らない人はそんなことは思わない。
そして、その例は間違いなくオブジェクト指向してる様に見えるんだが、その例はオブジェクト指向じゃないの？

あと後半の説明は明らかに誤解を招く。どう考えてもインスタンスとクラスは同じ姿（機能）をしてないだろうと。

186:デフォルトの名無しさん
08/03/11 10:57:48
だめだ、日本語がわけわかめになってるな。そんなことが同じ文の中に2回登場してるorz

187:デフォルトの名無しさん
08/03/11 10:59:41
>>184
現実にはイノシシからブタが発生したりするわけ。
実行時にクラスが増えていくって感じ？
さらにもっと良く見ると、１つ１つのクラス違ってるじゃん、みたいな。

純粋にオブジェクト指向で現実を記述するってのと、
簡単な業務アプリのスタティックなクラスは、
無限の隔たりがあるの。

188:デフォルトの名無しさん
08/03/11 11:01:03
＞現実にはイノシシからブタが発生したりするわけ。
＞実行時にクラスが増えていくって感じ？

もう少し説明すると、記述して計画的にクラスが分岐するんじゃなくて、
実行した結果分岐しちゃった、みたいな。
だから、スタティックなクラスじゃ書けない。

189:デフォルトの名無しさん
08/03/11 11:04:45
＞実行時にクラスが増えていくって感じ？

例えばキケイで足が１本少ないってなったとき、
じゃ、足の本数をメンバ変数にすれば良いじゃん、
って単純な話じゃない。

原生生物に突起が出来て、あるとき足と呼ばれるようになった、みたいな。

190:デフォルトの名無しさん
08/03/11 11:11:15
>>188
別に現実世界とオブジェクト指向の隔たりを否定しているレスは無いだろうと常考
>>189
オブジェクト指向プログラミングは現実世界を投影するのが目的じゃないだろう

191:デフォルトの名無しさん
08/03/11 11:12:39
＞オブジェクト指向プログラミングは現実世界を投影するのが目的じゃないだろう

おまいＯＯわかって無いだろう、ｊｋ

192:デフォルトの名無しさん
08/03/11 11:15:44
>>191
言い方が悪かった
オブジェクト指向プログラミングは現実世界を投影するのが『最終』目的ではないだろう

193:デフォルトの名無しさん
08/03/11 11:18:39
身近から言うと業務アプリは業務を投影するし、
極端なことを言うと地球シミュレーターは地球を投影する。
人工知能で顔を判別するには顔を投影する。

で？

194:デフォルトの名無しさん
08/03/11 11:21:45
>>193
やっぱりそういう勘違いをしてるのか･･･

195:デフォルトの名無しさん
08/03/11 11:21:48
俺は、>>191が判ってないのに1票
>>180と>>185は、言葉の違いを言い争ってるのに1票(パンクとメタルの違いみたいなぁ)

クラスから発生したインスタンスは、クラスにはならない
プロトタイプから発生したインスタンスは、プロトタイプになる
そう言いたいので有れば、説明のしかたがおかしい
さらに言うなら、それはオブジェクト指向の話でもなんでも無く、コンパイラとインタプリタの話であり、ややこしくなるだけだから、口を開くな禿

196:デフォルトの名無しさん
08/03/11 11:24:39
>>194
投影、を勘違いと思うなら、OOを勘違いだといってるのと同じ。
この議論の外の話。

197:デフォルトの名無しさん
08/03/11 11:25:23
＞さらに言うなら、それはオブジェクト指向の話でもなんでも無く、コンパイラとインタプリタの話であり、ややこしくなるだけだから

強烈に頭が悪い悪寒。

198:デフォルトの名無しさん
08/03/11 11:26:31
どっちにしろ、ＯＯってのは現実世界の投影。

それを否定する人は、別の議論に入って良いけど、この議論には入るな！

199:デフォルトの名無しさん
08/03/11 11:30:00
＞>>180と>>185は、言葉の違いを言い争ってるのに1票(パンクとメタルの違いみたいなぁ)

これ、強烈に頭割る杉。

200:デフォルトの名無しさん
08/03/11 11:31:59
>>196
>>193の例で言えば業務アプリのプログラムを組もうとすることはoopと無関係である。
別にoopでなくとも可能かも知れないし、oopの場合現実世界を必ず投影しなければいけないわけではない。

oopは安全性の向上、再利用性の向上、が目的だろ。
現実世界を投影することとoopで使うことを前提としたクラスライブラリを作ることが同じと申すか。

>>195
185だが、自分で言うのもなんだが確かに不毛。

201:デフォルトの名無しさん
08/03/11 11:32:55
＞>>180と>>185は、言葉の違いを言い争ってるのに1票(パンクとメタルの違いみたいなぁ)

こいつが頭悪いと言い切れるのは、
学問的にも、クラスベースＯＯとオブジェクトベースＯＯは別物となってて、
既にクラスを推奨しているboochは異端だとか電波だとか言われている。

クラスベースにしがみつく＝キティ

202:デフォルトの名無しさん
08/03/11 11:34:28
＞oopは安全性の向上、再利用性の向上、が目的だろ。

これは間違い。
手続きプログラミングに対してクラスベースの効果として、安全性、再利用性は言われるもの。

しかし、前述のとおり、ＯＯとしてはクラスベースは異端。

203:デフォルトの名無しさん
08/03/11 11:40:19
>>201
初めて知ったわ。なんかそれぞれの学術書でもあるん？

204:デフォルトの名無しさん
08/03/11 11:43:09
何を分かった風な。

205:デフォルトの名無しさん
08/03/11 11:46:24
>>202
え、oopの目的って（Cににた言語なら）生産性、安全性、再利用性の向上だと思ってたけど。
何が目的なの？･･･というかそもそも設計方針だからルールはあっても目的とか無いのか･･･。

206:デフォルトの名無しさん
08/03/11 11:49:02
一人、強烈にオブジェクト指向を理解してないやつが居ることだけは確実だって事だな
しかも、人の説明は違うと言いつつ、自分では何の説明もしないあたり、相当な...

207:デフォルトの名無しさん
08/03/11 12:21:05
ＯＯの本流に一番近いのはＲｕｂｙかな

208:デフォルトの名無しさん
08/03/11 12:25:33
一つの言語でまかなえれば、それは楽で良いだろうが
目的に応じて使用する言語を選べる方が、よりオブジェクト指向だと言えるな

209:デフォルトの名無しさん
08/03/11 12:27:26
＞目的に応じて使用する言語を選べる方が、よりオブジェクト指向だと言えるな

おまいのいうオブジェクト指向ってのは、開発のノリのこと？
いわゆる何に対しても、”ロック”、の一言で終わらせるあれ？

210:デフォルトの名無しさん
08/03/11 12:30:25
>>209
馬鹿は黙ってろ

211:デフォルトの名無しさん
08/03/11 12:31:47
＞馬鹿は黙ってろ

やっぱ脳みそツルツルの体育会系じゃねーか。
おま、マに向いてないお。

212:デフォルトの名無しさん
08/03/11 12:36:40
>>211
プロトタイプとインスタンスの関係も理解できてないのに大きな口を叩くな
理解できてるなら、説明して見ろ
話はそこからだ

213:デフォルトの名無しさん
08/03/11 14:35:57
オブジェクト指向は現実世界の投影じゃないよ。
言うなればドメイン(問題領域)の投影だよ。
物理学者ならアレだけど。

プロトタイプは原型だよね(英単語的な意味で)
クラスは変な表現になるけど、興味の対象だよ。
インスタンスとプロトタイプは似てたりもするけどね。

ところで、ここ何のスレ？

214:デフォルトの名無しさん
08/03/11 14:37:31
ドメイン(問題領域)の投影
の一例として
現実世界の投影だろ？

213=ヴぁか？

215:デフォルトの名無しさん
08/03/11 14:41:16
>>214
だから馬鹿は黙ってろ
話題に混じりたいなら、プロトタイプとインスタンスの関係を説明してから混じれ

216:デフォルトの名無しさん
08/03/11 14:57:07
a)オブジェクト指向は現実世界の投影じゃないよ。
b)ドメイン(問題領域)の投影だよ。
c)物理学者ならアレだけど。

aとbを比べたらbの方が巨大。
bはaを含む。
だから、aの「じゃないよ。」は成り立たない。

さらにcで「ならアレだけど」と例外的に書いているのはさらに変。
物理学者だからこそ現実世界以外の問題領域が必要になるわけで、
物理学者じゃないならaで十分ｗ

217:デフォルトの名無しさん
08/03/11 14:58:40
>>214
一例になるから213は物理学者ならって書いてるんじゃね？

218:213
08/03/11 15:03:49
>>216
オブジェクト指向＝現実世界の投影じゃ～
って書いた方が良かったかな。

219:デフォルトの名無しさん
08/03/11 15:04:09
>>217
いや、
現実世界の投影　∈　ドメイン(問題領域)の投影
なの。

「現実世界の投影」の方が小さい。

220:デフォルトの名無しさん
08/03/11 15:05:07
＞ドメイン(問題領域)の投影

ってのは、現実にあるもの無いもの含んで超巨大。
これこそ物理学者にふさわしい。

221:デフォルトの名無しさん
08/03/11 15:08:35
>>219
プロトタイプとインスタンスの区別も付かない奴に何を言っても無駄

>>220
馬鹿は黙ってろ

222:デフォルトの名無しさん
08/03/11 15:15:05
>>219
だからそう言ってんじゃんｗ
どう読んでんだよｗ
213はイコールじゃないって言いたいんだろ

223:デフォルトの名無しさん
08/03/11 15:17:42
>>222
あ、自分の読み間違い？

良く分からないけど、ま、次の話題にすすみますか。

224:213
08/03/11 15:26:51
現実世界の投影はドメインの投影に含まれると思っています。
物理学者なら現実世界（シミュレーション的な意味で）をドメインとすることもあるかもね、
というつもりで書きました。
「アレ」では端折り過ぎでした。すみません。

まぁ、次の話題へどうぞ。

225:デフォルトの名無しさん
08/03/11 15:28:41
では、ＯＯとしてドメインの投影するには、どんな言語が良いのだ？

226:デフォルトの名無しさん
08/03/11 15:46:33
C++でイナフ

227:デフォルトの名無しさん
08/03/11 18:43:05
>>209あたりからのレスの進み方を見て、oopが分からない人が多い理由が分かった

228:デフォルトの名無しさん
08/03/11 22:44:48
別に分かっていなくても、奇抜なプログラムを書かず、
そのとき使っている環境で普通とされるコードを書ければそれでいい。

229:デフォルトの名無しさん
08/03/12 08:36:17
STL、boostが既に奇抜なプログラムな現実について。

230:デフォルトの名無しさん
08/03/12 08:51:12
C++ではSTLくらい普通の内です。

231:デフォルトの名無しさん
08/03/12 13:16:03
現状のSTLは欠陥品って報告が数多くでてるじゃん

232:デフォルトの名無しさん
08/03/12 13:43:10
ふーん、その欠陥品を模造したものがSTLドトネト→STL.CLIでつか。

233:デフォルトの名無しさん
08/03/12 15:21:31
見捨てた奴スレのレベルの低さから、何かが解るような気がする・・・

234:デフォルトの名無しさん
08/03/12 16:10:56
>>231
だからと言って標準ライブラリに代わりがあるわけではないし、
C++を使わない決定的な理由にならない。

235:デフォルトの名無しさん
08/03/12 19:43:05
URLﾘﾝｸ(www.nicovideo.jp)

C++のエラーは黒魔術

236:デフォルトの名無しさん
08/03/12 19:58:38
キャスト演算子のオーバーロードをしたいと言うとき、
C++の場合はポインタが足枷になる
大抵は派生クラスにして終わりなんだが、newできないクラスのラッパを作る時に不便だ
勿論getterも書くが…個人的にはgetterはあまり増やしたくないな

237:デフォルトの名無しさん
08/03/12 21:48:56
10年間変わっていない。
しかもあと10年は変わりそうにない言語を
肥大化というのもおかしくないか。

238:デフォルトの名無しさん
08/03/12 23:12:57
>>231
まだVC6使ってんのか？

239:デフォルトの名無しさん
08/03/13 00:44:51
かれこれ20年近くC++を使ってきたが・・・
まぁ、いろいろな意味と理由で負の遺産となりつつある。
場合によってはCOBOLより凶悪な事態を招きかねない、早いうちに廃棄処分方針をとった方が良いだろうとは思う、さすがに。
固執する人もいるが、そういった人には一度離れて別の言語を見て回ってみろと言いたい、
開発環境・コンパイラといった物から、言語使用その他あらゆる点で時代遅れになっているので……
唯一進んでいるのはboostとその周辺だろうが、これらがメインになるのは恐らく難しいだろう。

240:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/03/13 01:13:00
それもそうだが、まずtypedefの構文をもっとまともにすべきだったね。

242:デフォルトの名無しさん
08/03/13 01:15:23
問題はC++の次が何か？ってことで、Cの上位互換なら
Objective-Cという選択肢も一応あるんですがねえ…。

243:デフォルトの名無しさん
08/03/13 01:16:00
C言語から引き継がれた機能のうち最大の問題はプリプロセッサだと思うけどね。

>>241
typedef については、これ以上どうしろと・・・

244:デフォルトの名無しさん
08/03/13 01:22:27
関数ポインタのことじゃない？
typedef void(FUNCP*)(int);
これは最初戸惑った。
typedef void(*)(int) FUNCP;
せめてこうなるべきなんじゃないか？と。

245:デフォルトの名無しさん
08/03/13 01:25:07
>>244
それは、宣言の書き方であって typedef 関係ない

246:デフォルトの名無しさん
08/03/13 01:36:55
typedefが記憶クラス指定子ってところがおかしいだろ。

247:デフォルトの名無しさん
08/03/13 01:42:10
どこがよwwww
それでも問題ないし、そもそも記憶クラスじゃないし。

248:デフォルトの名無しさん
08/03/13 02:01:56
>>247
そう、記憶クラスじゃないのに記憶クラス指定子にされているのがなんか気になる。
普段は意識しないし、実用上困ったこともないけどさ。

249:デフォルトの名無しさん
08/03/13 10:56:42
>>240
そもそも char* 等は型ではない。
関数プロトタイプに char* と書くようになってから一貫性がなくなってきてるけどね。

>>247
typedef は Storage-Class Specifier ではない。

250:デフォルトの名無しさん
08/03/13 18:50:53
>>240
でもそれって配列と文法をあわせてるからでしょ。
むしろ他の言語で配列の初期化周りが統一感ない文法が多くて気持ち悪いが。

251:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/03/14 10:03:01
>>251
関数型の世界しか頭になさそうなアホちんですね
組み込み等では大変役に立ったモンですよ

253:デフォルトの名無しさん
08/03/14 10:14:55
>>250
ｋｗｓｋ
>>251
レス番間違えてない？
>>252
よく読んでない悪寒

254:デフォルトの名無しさん
08/03/14 10:28:57
熟読した上で、まるで理解できず見当違いの煽りに走った、が正解。

255:デフォルトの名無しさん
08/03/14 12:10:49
>>253
いや、確かに前と後ろにつける違いがあるけど、どちらも変数につけるじゃん。宣言する時も使用するときも。
ポインタの文法は型にくっつけるべきだというなら、配列の宣言も[]は型にくっつけるべきだぜ。

256:デフォルトの名無しさん
08/03/14 16:58:18
入れ子状の宣言文上で複数の変数を宣言するから分りにくくなるだけで
とどのつまり、変数は一つづつ宣言させればいいのさ
それはプログラマがそうすればいいだけの話で、一行に一個づつ変数を宣言しろと。
つか、型宣言はC言語の問題の中では一貫性があり重大な欠陥の少ない部類だろ
なんでこんな所にイチャモンつけてんだか
関数ポインタや、配列返し const volatile register の修飾先が分りにくくて初心者がパニックを起こすのはちと考え物だとは思うが。

257:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/03/14 18:44:16
Cのparserを書こうとすると、Cの宣言の構文が嫌になる。
型名と変数名を区別するのに苦労させられるのがたまらん。

259:デフォルトの名無しさん
08/03/14 21:35:00
変数の宣言部分なんて、C++の話じゃなくて、Cの話だしな

260:デフォルトの名無しさん
08/03/15 04:12:13
>>258
スキャナで適当に区別してしまえよ、せっかく1 passで解析できるように出来ている構文なんだからさ。
それより、古き良き時代で大変役に立った機能が、今、逆に大きな弊害になっている点に突っ込めよ。
インテリセンス・デザイナ・リファクタリングツール・テストツール
リンクを高速に処理可能な抽象度の高い中間ファイル
モダンな機能が組み込み困難になっている現状こそが問題だろ。

261:デフォルトの名無しさん
08/03/16 01:54:31
[迷信] 識別子に使える文字は英数字と下線のみ
URLﾘﾝｸ(www.kijineko.co.jp)

262:デフォルトの名無しさん
08/03/16 04:22:46
>>261
ヨーロッパのマが書いたコードを見れば結構出現頻度高いんだよ、それ
日本やアメリカではお目にかからないけど

263:デフォルトの名無しさん
08/03/16 08:13:45
まぁ、javaやC#とかでも日本語識別子使えるけど、
文字列以外でASCIIでない文字を使うプログラマはカス

日本語プログラミング言語は別だけど

264:デフォルトの名無しさん
08/03/16 15:05:19
もうウニコードベースにすりゃいいのに

265:デフォルトの名無しさん
08/03/16 17:22:02
>>263
日本語ラベルは便利だぞ、C/C++だとラベルはラベル、実行コードは実行コードと分かれているが
リフレクションを持つJavaやC#では、構造体のラベル名を読み取って、そのまま活用できるから、
例えば表のタイトル文字列と、構造体のメンバの名前で表示するとか、XMLの内容をラベル名で出力するとか。
一箇所修正するだけで、全部修正完了するのは便利だ。

266:デフォルトの名無しさん
08/03/16 20:41:58
まさに、そういう考えの人が多いからこそ嫌いなんだけどな
間違ってるとまでは言わないが

ただ、システムの識別子はリファクタリング以外では変えるべきじゃないし
表示名のような業務要件で変わる外部のものと、内部のものを密結合にされると
逆に面倒なことになることもある

267:デフォルトの名無しさん
08/03/17 05:18:58
リファクタリグツールから名前を変更すれば、関わる "識別子=表示名" を根こそぎ全部置換してくれるから、変更漏れがなくていいと思うんだが。
それに、他人に説明するときに対応関係を説明する手間も省けるし。

268:デフォルトの名無しさん
08/04/23 11:39:07
>>179
粘菌の本質をベースクラスとして定義し
そこから派生クラスで環境依存部分を定義する

後は、派生クラス側で
operator=()をベースクラスのコピーと派生クラスの初期化に定義し直せば、動的に粘菌の性質を変更できるんじゃないのか?

269:デフォルトの名無しさん
08/04/23 11:48:50
俺はC++を見捨てたというより使いこなせるようになるのを諦めた。

270:デフォルトの名無しさん
08/04/24 00:12:27
自分を見限ったという事ですか。

271:デフォルトの名無しさん
08/04/24 00:37:32
そうでーす

272:デフォルトの名無しさん
08/04/24 12:26:49
>>268
いや、そーじゃなくて、プログラミング言語以前に、粘菌とはこれだという定義ができないって話らしいお。

273:デフォルトの名無しさん
08/04/24 16:04:17
>>272
定義できないなら、それが粘菌であるかどうかすらわかんないじゃん

例えば、
「晴れたら、小さな芋虫みたいになって、四方八方に散らばり」
「雨が降ったら、ぬちゃぬちゃで繊維質な物体になる」
って性質を持って居るように見えて
本当は、
「晴れたら、小さな芋虫に捕食され、雨が降ったら、その芋虫を養分に育つ」
のが本当の姿である可能性もあるじゃん

その場合、クラスだの、プロトタイプだの関係なく、オブジェクトの設計そのものに失敗しているってことじゃん

274:デフォルトの名無しさん
08/04/24 16:20:48
名前考えるのめんどくさいよね。
日本語でおkになってほしい。

275:デフォルトの名無しさん
08/04/24 16:27:56
＞オブジェクトの設計そのものに失敗しているってことじゃん

ま、つまり、そういうことだ。
現実は、オブジェクト設計を失敗してるってこと。

【謎飼育】正体不明の謎生物を7年間に渡って飼育している動物園
URLﾘﾝｸ(karapaia.livedoor.biz)

遺伝子組み換えで、生物どころか単なるパーツが作られちゃうかも。

276:275
08/04/24 16:29:45
「現実は」ってのは、”現実世界は”ってことね。

クラス派生で生物が進化してきたわけじゃない。
グラデーション、みたいな。

277:275
08/04/24 16:32:24
もっというと、生物の進化は、単純化・複雑化の２方向があるが、現実は「複雑化」の一方。

今、要素を洗い出しても未来には違う要素が出てくる。
スタティックなクラスじゃ足りないってこと。

278:デフォルトの名無しさん
08/04/24 16:34:28
めたふぁとしてのオブジェクトはもういいよ。
それ最初に本に登場したの1992だよ。
名前は日本語でいいが次のトレンドだよ。

279:デフォルトの名無しさん
08/04/24 16:40:24
＞例えば、
＞
＞って性質を持って居るように見えて
＞本当は、
＞
＞のが本当の姿である可能性もあるじゃん

　↑
これに具体例を入れるだけで、クラスベース言語の限界と問題点が明確になるテンプレ。

280:デフォルトの名無しさん
08/04/24 16:53:29
> 例えば、
> 大きい
> って性質を持って居るように見えて
> 本当は、
> 小さい
> のが本当の姿である可能性もあるじゃん

ねーよｗｗｗ

281:デフォルトの名無しさん
08/04/24 17:02:34
まあ、ヒトクラスとサルクラスを作ったらその分化前の類人猿はどうするよ、と。
類人猿クラスを作ったらそれとヒトの間はどうするよ、と。
ミッシングリンクみたく、中間は無限にあるという問題になる。

282:デフォルトの名無しさん
08/04/24 17:12:17
>>281
それ俺らが生まれる前の時代にさんざん議論されつくした話題じゃん。
結局ある種の制約がないとプログラミングできないんだから、その手の
問題がないほうが問題なんだよ。
制約があるのが正しい状態って結論が出て今があるわけ。

というわけで、いま必要なのは日本語でいいじゃんってことなんだよ。

283:デフォルトの名無しさん
08/04/24 17:13:39
>>279
それは、クラスベース言語の問題点じゃなくて、オブジェクト指向の限界だろw

>>280
ねーよｗｗｗ

>>281
それは、オブジェクト指向以前に、デジタル回路ととアナログ回路の違いからやり直した方がいいよ、たぶんw

284:デフォルトの名無しさん
08/04/24 17:18:13
>>283
おまい無知なだけじゃん。
スタティックなOOがクラスベースっていうOOのイロハを知らないんだろ。

回線切ってケーブルで（ｒｙ

285:デフォルトの名無しさん
08/04/24 17:19:54
＞それ俺らが生まれる前の時代にさんざん議論されつくした話題じゃん。

ねーよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

昔あった議論は、OOじゃなくて構造化は是か非か。
その前は、汗じゃなくてCは是か非か。

286:デフォルトの名無しさん
08/04/24 17:25:41
整数型　ねーよ　＝　いいえ。
どうよこれ？
いいだろ？

287:デフォルトの名無しさん
08/04/24 17:26:23
＞制約があるのが正しい状態って結論が出て今があるわけ。

ねーよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

プログラミング言語はソフトウェアとともに進化して来てんだよ。
そしてソフトがクラスベース言語で表現できないものも扱い始めたんだよ。

おまいは市んだ法が良い。あどヴぁいすｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

288:デフォルトの名無しさん
08/04/24 17:31:46
あれか、人クラスを作ったとき
会社員クラスから学生クラスには出来ず、また学生クラスから会社員クラスにも出来ないから、クラスベースは静的で役に立たないってかw

289:デフォルトの名無しさん
08/04/24 17:38:19
288=誤読乙！

ヴぁかは読解力が無いようでｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

290:デフォルトの名無しさん
08/04/24 17:42:13
>>288
is a関係とhas a関係とかいう奴だな。
そこで、property型を導入するんだよ。
日本語至上主義的には属性ってしたくなるけど、そこは肩書だな。
なんでかっていうと、肩書ってしとけば委譲するとき意味的に
ぴったしっぽいじゃん。
で、よくよく考えると他重軽傷でいいのか？とか思っちゃうんだけど、
そうするとまた最初に戻っちゃうので、肩書を導入すること推奨。

291:デフォルトの名無しさん
08/04/24 17:47:48
芝君の話は難しすぎて判りませんね(棒読

292:デフォルトの名無しさん
08/04/24 17:49:34
会社員や学生に「is-aヒト」問い合わせしたらtrueだろうが、
ヒト・サルに文化する前の類人猿に「is-aヒト」、「is-aサル」を問い合わせたら、true？false？
サルが派生してヒトになったわけじゃない。
類人猿が分化して夫々になったわけだし。

293:デフォルトの名無しさん
08/04/24 17:51:36
C++0xに肩書が導入されたらどうするよ？

294:デフォルトの名無しさん
08/04/24 17:52:57
>>292
いいえになるよ。
だっていいえだろ？

295:デフォルトの名無しさん
08/04/24 17:53:41
誰だよふぁびょってるのは・・・

296:デフォルトの名無しさん
08/04/24 17:55:35
>>292
その認識だと類人猿はヒト、サルの共通の祖先なので、
ヒトでもサルでも無い(false)。
ヒト、サルにis-a類人猿したら両方trueだろ。

297:デフォルトの名無しさん
08/04/24 17:56:47
>>296
いいえになるよ。
折れるいじねんじゃないしｗ

298:デフォルトの名無しさん
08/04/24 18:00:15
>>297
デジタルモンキー乙w

299:デフォルトの名無しさん
08/04/24 18:02:12
略してでじもん乙。

300:デフォルトの名無しさん
08/04/24 18:07:11
取り敢えず、芝君の仲間になりたくないから、俺はC++で頑張るわ

301:デフォルトの名無しさん
08/04/25 00:14:14
芝君にとってのオブジェクト指向は、なんでも解決するスーパーテクニックの様です

傍迷惑でビッグなクラスとか、誰にも読めないプロトタイプの山が見えるな

302:デフォルトの名無しさん
08/04/25 07:29:05
じゃぁ、クラスの肥大化を防ぐテクニックについて語ろうぜ。
クラスっていうのはえさを与えなくても勝手に大きくなっていくものだからな。
テンプレートも一つの解ではあるな。

303:デフォルトの名無しさん
08/04/25 09:28:47
クラスを肥大化させないテクニックは
「馬鹿にクラス設計をさせない」

304:デフォルトの名無しさん
08/04/25 09:43:35
＞芝君

　↑
これって何？
自演クンって意味？

305:デフォルトの名無しさん
08/04/25 10:08:00
芝君の仕事は、2chのスレに芝を生やすことだぉ

306:デフォルトの名無しさん
08/04/26 10:18:40
　　　　　　　　　　　_,　._　
　　んもー！　（　・ω・）　　　　.　　.
　　　　　　　　○=｛=｝〇,　;　.'´　｀.　ﾞ　;　｀
　　　　　　　　|:::::::::＼,.'.;´,"　:´,´'　.　ﾞ　.｀　.
　.,,.,.,,,.,.,,,.,.,,,.,.,,,.,.,し,,.,.,`（.＠）ｗｗｗｗｗｗｗｗｗｗｗｗｗ　

307:デフォルトの名無しさん
08/04/26 11:43:10
>>302
テンプレートを使うとクラスの代わりに実行モジュールが肥大化します。

308:デフォルトの名無しさん
08/04/26 11:53:54
>>302
テンプレートを使うとコンパイル速度も飛躍的に悪化します。

309:デフォルトの名無しさん
08/04/26 13:32:46
>>302
テンプレート使っちゃうと、クラスに対するプロトタイプの利点が無くなるよぉw

310:デフォルトの名無しさん
08/04/27 00:04:47
実行モジュールのサイズを縮小し、コンパイル速度も短縮して
ついでに生産性も縮小するわけですね、わかります。

311:デフォルトの名無しさん
08/04/27 00:11:31
>>302
テンプレートを使うと >>310 の仲間になれるかもよ！

312:デフォルトの名無しさん
08/04/27 01:20:43
>>307-309,>>311
std名前空間使用禁止ﾜﾛﾀｗ

313:デフォルトの名無しさん
08/04/27 01:21:04
>>302
クラスが肥大化するのは、設計が悪い場合もあるけど、
提供する機能が多いっていう場合もあるんだよな。
後者の場合、どんなやり方をとったとしても、大きなクラスかたくさんのクラスを作るかせねばならん。

314:デフォルトの名無しさん
08/04/27 01:52:27
クラスを使っても肥大化、テンプレートを使っても肥大化。言語仕様も益々肥大化。
むしろ C++ ユーザは肥大化を求めているんじゃないかな。実際どうかは別として、
肥大化すればするほど生産性が上がるという教義だから。

315:デフォルトの名無しさん
08/04/27 01:55:43
バグの生産性ですね分かります

316:デフォルトの名無しさん
08/04/27 04:35:53
別に肥大化したところで、使いたいと思わない機能は使わなきゃいんじゃね？
Bjarne氏もD&Eでそう言ってたし。「使わない機能はコストを発生させない」っていう
原則もあることだし。肥大化することで初心者が不幸になることもないと思う。
ただまぁ、何から学べばいいかわかりにくくなるor勉強する（べきだと思われる）ことが
多すぎてしょんぼりくる可能性はあるが。

317:デフォルトの名無しさん
08/04/27 10:42:23
肥大化はC++がというより
C#がという方がより適切と思うが
LINQとか

318:デフォルトの名無しさん
08/04/27 12:54:40
使ってる人間の殆どが肥大化嗜好だから、使いたいと思わない機能は
使わないという当たり前の選択を貫徹するのは不可能に近い。

319:デフォルトの名無しさん
08/04/27 13:34:57
>>318
まあな
使わないと選択する為には
少なくともその機能を知っておかなければ
ならない訳で、もうその時点でラーニングコストは
発生している。初めから無理なことを言っている。

320:デフォルトの名無しさん
08/04/27 13:50:34
プロの道具なので仕方ない。
プロでない人は自分が使いやすい言語を選ぶと良い。

言語の機能の習得ごときでいっぱいいっぱいなら、
組み込み系、DB、マルチメディア処理、ドライバ開発とかの
言語以外ので学習で鼻血出るだろうな。

321:デフォルトの名無しさん
08/04/27 14:25:09
プロｷﾀー！

プロならもっと道具を選べよ…
その4つの中で C++ が他の言語より優れているのって
マルチメディア処理だけだな。

322:デフォルトの名無しさん
08/04/27 14:30:01
でもすべての言語をその4つの平均点で比べるとC++はかなり有能だろ

323:デフォルトの名無しさん
08/04/27 14:40:11
>>321
その他の言語ってのそれぞれ教えてくれないか？
C言語以外でｗ

324:320
08/04/27 15:01:09
>>321
どう読んだのか知らないが、俺の趣旨は
　・学習用の言語でないので、言語機能を理解力の低い人に合わせる必要は無い。
　・言語の機能の習得と、専門知識の習得では、後者の方が難しい。
ということなんだが。

その４つは例を挙げたに過ぎないし、
それらにC++が適しているとも言っていない。

特にＤＢは俺が最近ＤＢ周りのチューニングとかしてたので、
たまたま脳裏に出てきただけだ。言語はC++じゃない。

道具を選べ、というのは同意する。
他のメンバーやプラットホームの都合があるので、
好きに選べるわけじゃないけどな。

325:デフォルトの名無しさん
08/04/27 16:07:21
>>323
C++ 使いには C にコンプレックス持ってる人間が多いな。
道具は使いようだぜ。

組み込み（つっても色々あるが…） -> C
DB（まあ Oracle だと思いねえ） -> Java
マルチメディア（画像処理とか） -> C++
ドライバ（Win は知らんけど…） -> C

>>324
分野別の知識は言語の習得とは直行した課題だと思うよ。
専門知識の習得は、言語が難しかろうが簡単であろうが必要となる事なんだから、
言語の習得は簡単な方が良いとも言えるんじゃないかな。

326:デフォルトの名無しさん
08/04/27 16:14:10
ところで、上の方でOO云々語ってる奴らはJavaやらC++の
対象.メッセージ(値,値);
構文しか知らんのだろうな、例えば
[対象メッセージ:値メッセージ:値];
やら
Send(対象,メッセージ,値,値);
とか、
メッセージ(対象,値,値);
(メッセージ対象値値)
なんかを知ってればもっと増しな議論が
出来るだろうに。
せめてクラスや継承は必要悪でありOOの本質でないと気付いて貰いたいものだ。

327:デフォルトの名無しさん
08/04/27 16:23:54
知っているに越したことはないが、それはまたC++とは別の世界。
C++のOOでメッセージを持ち出してくるのもどうかと思う。
URLﾘﾝｸ(d.hatena.ne.jp)

328:デフォルトの名無しさん
08/04/27 16:43:41
>>327
確かにそうだがC++で

template<class T>void F(T &対象)
{
　対象.メッセージ();
}

//対象1と対象2は同じメッセージを持つ
//意外何ら関連性は無い
型1 対象1;
型2 対象2;

//Fは対象が何であれ構造を気にせず
//処理を行える。
F(対象1);
F(対象2);

という文を見ると、静的ではあるが
メッセージを意識せざる得ない。
アラン・ケイがRubyを誉める理由も
これを動的且つ素直に実装できる事が
一因しているように思う。

329:デフォルトの名無しさん
08/04/27 16:54:23
>>325
> C, Java, C++, C
完全に予想通りの回答ありがとうｗ

330:デフォルトの名無しさん
08/04/27 16:57:27
>C++のOOでメッセージを持ち出してくるのもどうかと思う。
もともとC++はオブジェクト指向できるようにはできていないんだよ、だからSTLなんだ。
しかしオブジェクト指向を考えるならメッセージを考えないというのは論外。

自分は 326 じゃないが
>せめてクラスや継承は必要悪でありOOの本質でないと気付いて貰いたいものだ。
これはオブジェクト指向においては核心部分だぞ。

331:デフォルトの名無しさん
08/04/27 17:16:33
C++使ってる奴がCにコンプレックスってのは考えられないな

C95とは基本的に互換だから、気にするのはC++の構文が使えない程度
C99との差異は理解の上では大したことないし
精々STLが使えなくて面倒ってとこだろ

332:デフォルトの名無しさん
08/04/27 17:17:25
>>331
現実には多いよ

333:デフォルトの名無しさん
08/04/27 17:19:16
>>330
そうなのか？
327のとこにはこう書いてあるけど。
> ストラウストラップの「ユーザー定義型の」オブジェクト指向
中略
> なお、この文脈の「オブジェクト指向」において、メッセージングはぜんぜん関係ない無用のもの
> and/or 動的性実現のための（仮想関数より効率の悪い）実装のひとつに過ぎない…
> ということを強く意識する必要があります。

334:デフォルトの名無しさん
08/04/27 17:20:58
>>332
そいつらってどういうコンプレックス持ってるんだ？
「ポインタ分からないのでstd::vectorとか使わないと可変配列も作れません」
とかの馬鹿はC++分かってるとは言わないし

335:デフォルトの名無しさん
08/04/27 17:21:36
そうかなあw
ポインタ本の人（前橋）の意見じゃないけど、メッセージ云々こそ「言い方を変えただけ」
に過ぎず本質と何も関係ないと思うけど。

336:デフォルトの名無しさん
08/04/27 17:23:26
>>331
折角苦労して C++ 覚えたのに C で何の問題も無い事を見せつけられたら
僻む気持ちも出てくる事だろうさ。今までの努力が水の泡だからな。
上には Java 下には C で居場所無いもんね。生産性重視なら LL があるし。

337:デフォルトの名無しさん
08/04/27 17:36:51
>>336
＞折角苦労して C++ 覚えたのに
そういう可哀想な連中は先々で躓くから気にしなくていいだろ
おそらくC++開発者としてもあまり役に立たないだろう

というか今日日、JavaやLL系も使えてもらえないと
流石にC++しか出来ませんじゃ困るだろ

338:デフォルトの名無しさん
08/04/27 17:48:28
>>332
>>335
　実装と理論は違うがな。
たまたまC++は実行コストから
関数≒メッセージレシーバの方式を
採っただけで本来メッセージの受信者は
PCの周辺機器やら、ネットワークの
向こう、はたまた操作するユーザーでも
構わないんだから。それらを抽象化して
クラスやプロとタイプと言うアプローチ
も構わないが根底にメッセージ概念が
有る事を意識する事は重要。
(故に単にメソッド&クラス脳の
Java屋はOO世界から馬鹿にされるんだがな)

339:デフォルトの名無しさん
08/04/27 17:57:48
Cを理解していればC++は0からよりは早く使えるようになる。
C++、Java、C#のどれかを理解してたら、
他の２つもすんなり使えるようになる。
JavaScript、Python、PHPなども同様。

宣言型言語に対してはともかく、
他の命令型言語に対してそれらの知識は水の泡にはならないと思う。
水の泡になるくらい応用力無いならＰＧ向いてない。

次ページ