消えてなくなれよ > ..
655:デフォルトの名無しさん
09/06/18 22:01:28
>>653
勝手な介錯だな
656:デフォルトの名無しさん
09/06/18 22:03:57
切腹ー
657:デフォルトの名無しさん
09/06/18 22:15:32
>>652
あぁ、誤解していました。すみません。
OOでは継承と仮想関数によって「種類を増やす」事をしていた訳ですので、
polymorphic variantsが同様の役割を担っているのはおっしゃる通りです。
あと、
>モジュールシステムは元々操作を拡張することができる
というのは、"新しい操作を加えることができる"の間違いでした。
OOではこれをやろうとすると、visitorパターンを使わなきゃいけなくなります。
で、visitorパターンを使うと今度は種類を増やせなくなる。
つまり、expression problemはC++やJavaでは解決できません。
658:デフォルトの名無しさん
09/06/18 22:25:23
Javaでexpression problemを解決しようと頑張ってみた例↓
URLﾘﾝｸ(www.graco.c.u-tokyo.ac.jp)
これと比べれば、polymorphic variantsによる解法が如何に簡潔か分かると思う。
659:デフォルトの名無しさん
09/06/18 22:39:20
OOがゴミということは最初からなんとなく判ってたんだ
途中から総称型がもてはやされた時点で確信に変わった
次第にOOはどんどん隅に追いやられ、やがて名前だけの存在になった
つまりOOは、OOであることをやめてしまったのだ
660:デフォルトの名無しさん
09/06/19 00:56:11
OOPLにはなんでタプルとバリアントが無いの？バカなの？死ぬの？
661:デフォルトの名無しさん
09/06/19 01:01:09
どったん？死ぬん？
662:デフォルトの名無しさん
09/06/19 01:19:17
アメリカでOOP禁止になるかもな
663:デフォルトの名無しさん
09/06/19 02:05:57
>>660
その文体飽きちゃった
664:デフォルトの名無しさん
09/06/19 11:01:28
>>632
template <typename T, typename C> class stack {
typedef T value_type;
typedef C container_type;
public:
virtual value_type top(void) = 0;
virtual void pop(void) = 0;
virtual void push(value_type) = 0;
private:
container_type _container;
}
665:デフォルトの名無しさん
09/06/20 00:05:37
PythonにはタプルあるしVB系にはバリアントあるけど…
666:デフォルトの名無しさん
09/06/20 04:08:07
C++はboostのtupleが使えるから特に問題無いな。実装は汚いが。
667:デフォルトの名無しさん
09/06/20 08:29:23
>>665
バリアントの意味が違う
どの型でも代入できる変数なんてキモいやつの事じゃないからね
668:デフォルトの名無しさん
09/06/20 09:48:29
いわゆる代数的データ型だな
669:デフォルトの名無しさん
09/06/20 10:30:47
代数的データ型といえば、コンパイルは通るのに実行時にパターンマッチ失敗して
どこが間違ってるのか探すのが面倒で、静的型の意味がないと思った記憶がある
670:デフォルトの名無しさん
09/06/20 10:31:11
バリアントあれば継承いらねえことに気づいた
671:デフォルトの名無しさん
09/06/20 10:54:32
>>670
おまえ全然分かってないな
672:デフォルトの名無しさん
09/06/20 10:55:07
>>670
それは、継承の使い方を間違っているだけじゃないの?
673:デフォルトの名無しさん
09/06/20 11:23:44
>>670
「いらないこともある」だな。
継承あった方が便利って時もある。
674:デフォルトの名無しさん
09/06/20 12:51:11
変数に型があるからオブジェクト指向が考えにくいのかもしれん。
Lispみたいに変数の型を無くして値に型を持たせたらいいかもな。
675:デフォルトの名無しさん
09/06/20 13:03:22
URLﾘﾝｸ(practical-scheme.net)
> 個人的には、オブジェクト指向抽象化が必要だと思ったことは一度もない。 Common Lispは
> 恐ろしいほど強力なオブジェクトシステムを持っているが、私は一度もそれを使ったことがないん
> だ。ハッシュテーブルにクロージャを詰め込むとか、弱い言語だったらオブジェクト指向テクニッ
> クが必要だっただろうと思えることはたくさんやってきたけれど、CLOSを使う必要に迫られたこ
> とは無かった。
676:デフォルトの名無しさん
09/06/20 13:37:55
>>673
それで設計変わっちゃうのってどうよ？
677:デフォルトの名無しさん
09/06/20 13:59:46
>>670も>>673もおまいらみんな土方だろ
継承の代わりになり得るのはバリアントじゃなくて多相バリアントだ
678:デフォルトの名無しさん
09/06/20 14:08:00
>>675
要約すると
「LISPのOOはCLOSがあるけど結局クセが強すぎて怖くて使わなかった
考えてみたらおりゃのやる範囲じゃOOいらなかった」
679:デフォルトの名無しさん
09/06/20 14:12:51
CLOSが変態なのはCLOS屋も認めるところだからなあw
680:デフォルトの名無しさん
09/06/21 10:27:22
>>669
それ、exhaustive checkの警告を華麗にスルーしてるだろww
681:デフォルトの名無しさん
09/06/21 11:16:47
やっぱり、無制限に新しい型を作れるオブジェクト指向と、
静的型システムとは相性が悪いんだよ。
Objective-C みたいに、別々に存在してるほうがいいんじゃないの。
682:デフォルトの名無しさん
09/06/21 18:09:22
まぁ臨機応変に
683:デフォルトの名無しさん
09/06/21 21:32:03
>>681
>やっぱり、無制限に新しい型を作れるオブジェクト指向と、
>静的型システムとは相性が悪いんだよ。
相性以前に、型なんて何にも考えずに作った構文やセマンティクスの上に
おまけで型を入れようとするから、静的にならないんじゃないかな。
684:デフォルトの名無しさん
09/06/21 22:29:23
型システムをおまけとして分離すると再利用しやすくなる。
例えば型システムの古いバージョンと新しいバージョンを連携させることもできる。
685:デフォルトの名無しさん
09/06/21 23:47:28
>>684
>型システムをおまけとして分離する
型安全とか型推論ってその言語で定義される値や構文の上に定義されるものだから、
分離すること自体が困難そうにみえるのだけど。
型システムをおまけとして扱う関連情報源ありますか？
686:デフォルトの名無しさん
09/06/22 00:55:42
>>685
Objective-Cの話だと思うが
動的型付けが気に入らないなら、C++/CLIとか調べてみれば
687:デフォルトの名無しさん
09/06/22 08:19:34
>>685
アノテーション使うヤツなら太古の昔から色々提案されてるだろ。
688:デフォルトの名無しさん
09/06/22 19:37:19
>>674
それって python じゃね？
まあスピードもメモリも気にしないってことなら
いいんじゃないかと思うが。
689:デフォルトの名無しさん
09/06/22 19:50:59
あんな括弧もないような言語は捨てちまえ
690:デフォルトの名無しさん
09/06/22 19:52:51
>>689 誉めてつかわす
691:デフォルトの名無しさん
09/06/22 20:00:33
lisperｷﾓ
692:デフォルトの名無しさん
09/06/22 20:19:36
lisperは巣にｶｴﾚ!!!
693:デフォルトの名無しさん
09/06/22 21:07:36
lisper lisperささやいて〜
694:デフォルトの名無しさん
09/06/22 22:21:36
動的型のOOPLは、自分が書くときには最高のパフォーマンスを発揮する。
物によっては、基底クラスやオブジェクト自身の型さえ変えられる。
でも、他人のソースを読むときは、まさにカオス。
695:デフォルトの名無しさん
09/06/22 23:16:48
だからケント・ベックは他人が読みやすいコードの重要性にSmalltalkで気付いたのかな。
696:デフォルトの名無しさん
09/06/23 00:13:55
動的型のOOPLのソースコード、引き継ぎたくねー。
697:デフォルトの名無しさん
09/06/23 01:01:18
じゃあrubyとか最悪ですね
698:デフォルトの名無しさん
09/06/23 02:45:55
うちの会社じゃ、Rubyのコーディング規約として、publicなものには型を
コメントとして書く事にしてるよ。
699:デフォルトの名無しさん
09/06/23 05:27:32
それ最低だな。
静的型の型検査も、動的型のフレキシブルな記述も、両方とも捨ててる。
700:デフォルトの名無しさん
09/06/23 09:04:49
>>699
なにその一見同意しそうで、いやちょっとまてよ？ん？となる文章は。
701:デフォルトの名無しさん
09/06/23 09:07:37
型を意識するだけでなく、コメントとして書くぐらいなら
型シグネチャが必要な言語でいいじゃんって思うけど
強い静的型のLLなんてない(強いていうならHaskell？)現実
702:デフォルトの名無しさん
09/06/23 09:30:48
せめてLLを定義してから言えよ
703:デフォルトの名無しさん
09/06/23 09:31:09
静的型＋型推論が一番かなぁ。コンパイル言語になっちゃうが。
704:デフォルトの名無しさん
09/06/23 11:28:49
別に今のLLだって最初に全体をプリコンパイルしてるの多いし
そうでなくても全体をパースしちゃうのも多いから
純粋なインタプリタなんて今や希少種じゃね？
705:デフォルトの名無しさん
09/06/23 11:46:47
/bin/shさいこおおおおおおお
706:デフォルトの名無しさん
09/06/23 12:31:30
>701
スクリプトモードののScalaとか？
Rubyで、コメントにアノテーションとして型を明示する書法無いの？
なんかのライブラリのHTMLドキュメント見た時に書いてあったから、
そういうツールが出回ってるのかと思い込んでたけど。
707:デフォルトの名無しさん
09/06/23 13:27:32
>705
ああ、シェルスクリプトやバッチファイルはそうだっけ。
708:デフォルトの名無しさん
09/06/23 13:54:25
>>704
具体的に言語名は？
ruby,pythonなんか遅いからそんなことやってないと思うが。
709:デフォルトの名無しさん
09/06/23 13:58:32
>708
RubyもPythonも最初に全体をパースしてなかったっけ？
710:デフォルトの名無しさん
09/06/23 14:03:54
ファイル全体を一気にパースしたらコンパイル言語というのは少し御幣があるな。
抽象構文木を解釈しながら実行するなら、インタプリタと呼ぶべきかと。
PythonなんかだとJITコンパイルをする実装もあるが。
711:デフォルトの名無しさん
09/06/23 14:16:08
いや、俺（>704）は「コンパイル言語」とは言ってないよ。
ただ、どっちにしても全体を最初に見るワケだから
「静的型＋型推論」をするのにコンパイル言語である必要は無いんじゃないのか？と言いたかった。
言葉足らず過ぎてすまん。
712:デフォルトの名無しさん
09/06/23 14:30:20
>>708
> ruby,pythonなんか遅いからそんなことやってないと思うが。
${PYTHON}/Doc/glossary.rst
bytecode
Python source code is compiled into bytecode, the internal representation
of a Python program in the interpreter. The bytecode is also cached in
``.pyc`` and ``.pyo`` files so that executing the same file is faster the
second time (recompilation from source to bytecode can be avoided). This
"intermediate language" is said to run on a :term:`virtual machine`
that executes the machine code corresponding to each bytecode.
713:デフォルトの名無しさん
09/06/23 17:24:08
>>704
>別に今のLLだって最初に全体をプリコンパイルしてるの多いし
ここに反応してレスしたんだ。多いのだったらいくらでも例をあげられるだろう。
ruby,pythonをあげるととたんにパースしているはないだろう。
もしそういうのがあれば使ってみたい。
>>712
マシン語にならないのにプリコンパイルと言われても他の言語になっているだけ。
714:デフォルトの名無しさん
09/06/23 17:33:18
>>713
> マシン語にならないのにプリコンパイルと言われても
>>704はこの考え方が古いって言っているんだよね。
中間言語へコンパイルしてさえいないのはいまや希少。
> もしそういうのがあれば使ってみたい。
v8 javascript engine
構文木からいきなりx86に変換して実行。
eval関数がある言語なのに。
REPLでも同じようにx86に変換して実行する。
715:デフォルトの名無しさん
09/06/23 17:35:50
実行中に型推論うごかすのかよw
716:デフォルトの名無しさん
09/06/23 18:10:55
大抵はインクリメンタルにやればすぐ終わるよ
そのまま動かす方がオーバーヘッドが大きい
717:デフォルトの名無しさん
09/06/23 18:13:04
>>714
> eval関数がある言語なのに。
lisp 系は昔から native 吐くやつざらにあるじゃん
718:デフォルトの名無しさん
09/06/23 18:50:43
>>714
V8のソースを少し見てみたが、本当に抽象構文木Tから直接マシン語を
出力してるな。アセンブリ言語に近い中間言語に落として最適化を
かけてからコード生成というアプローチだとレイテンシー等の問題が
出るってこと？
719:デフォルトの名無しさん
09/06/23 20:01:37
>>717
ほとんど全てのLispはインタープリタも持ってるでしょ。
(Scheme実装のStarlinみたいな処理系もあるけど)
だからS式のまま実行できる。
v8はインタープリタはない。そこが違う。
>>718
二度手間だって事でしょ。
WebではJavascriptのコードはソースで提供されるわけで、
PythonみたいにILを外部ファイルに持っておけるわけじゃない。
だったらJIT一発で実行した方がいい。
それからプロパティアクセスを高速化するためにはJIT必須という考え方。
Cの構造体フィールドアクセスと同じコードになってる。
「コンパイラ・スクリプトエンジン」相談室スレに移動した方がいいかな?
720:デフォルトの名無しさん
09/06/23 20:03:30
つまりnativeで実行できない言語はゴミ
721:デフォルトの名無しさん
09/06/23 20:36:25
native実行していてもゴミ同然の言語あるよねw
722:デフォルトの名無しさん
09/06/23 20:41:37
>>719
IR無しだと最適化が二度手間になると思うんだが、ターゲットCPUが
x86, x86_64, ARMだけだから何とかなっているのかもしれん。
というかLLVMなどを使うより高速なコード生成が出来るなら
やっぱりGoogleは凄いってことだな。
723:デフォルトの名無しさん
09/06/23 20:43:32
v8はデータフロー解析みたいな最適化は一切やってないんだわ。
ピープホール的な事をちょっとやってるだけで。
724:デフォルトの名無しさん
09/06/24 00:00:59
民主党が政権とると
OOPは規制対象になるね税金の無駄遣いだし
725:デフォルトの名無しさん
09/06/24 03:21:05
民主党が政権とるとOOPを使えないってこと？
自民党だと派遣マンセーでjavaを強制的に使わされそうだし
この際OOP規制で良いや
726:デフォルトの名無しさん
09/06/27 14:12:33
今朝がたの会話
俺 「そんなやりかたじゃ規格が満たせません」
某SE「今までこの方法で動かなかったものはないんだからこれでいいんだ」
… … …
規格書の読み方も知らんのか? > OO できる SE
727:デフォルトの名無しさん
09/06/27 15:04:52
OO関係ないやん。
728:デフォルトの名無しさん
09/06/27 18:34:56
上司「その規格書さ、間違ってるから」
よくあることである
729:726
09/06/27 20:14:14
>>728
某SE「OO的に書けないんだからその MP4 の規格書間違ってる」ってか
730:デフォルトの名無しさん
09/06/27 20:57:13
理解力の無さから察するに >>726 の方が間違ってそう
731:デフォルトの名無しさん
09/06/27 21:04:35
今日、次期政権担当政党で
IT詳しい人に聞いたがやっぱり
OOPは禁止だと言ってた
それってレガシーなんでしょって言ってたよ
732:デフォルトの名無しさん
09/06/27 22:45:16
w
733:デフォルトの名無しさん
09/06/28 10:09:49
>>731
734:デフォルトの名無しさん
09/06/30 14:16:49
オブジェクト指向って、せっかくまとまっているグローバル変数を
あっちこっちに散らかしてわかりにくくしたものなのですね
と言ってみる
735:デフォルトの名無しさん
09/06/30 16:14:11
流石にグローバル変数を持ち出されるとコボラ乙としか言えない
736:デフォルトの名無しさん
09/06/30 16:15:24
オブジェクト指向なんかPhotoshopで言えばレイヤーみたいなもん
あって当然使えて当然
ただ使えるだけで威張ってるのは馬鹿
「レイヤーを使わないと絵が描けません」と威張る言語も馬鹿
737:デフォルトの名無しさん
09/06/30 19:47:19
使えませんと言って威張ってるのはもっと馬鹿
738:デフォルトの名無しさん
09/07/01 00:44:29
アメリカでもEUでもOOP規制の動きが
出始めてる。ソフトウェア産業に害しか及ぼさないということで
原則使用禁止を国レベルで採択する方向が強まってるね
739:デフォルトの名無しさん
09/07/01 00:46:19
つまんね
740:デフォルトの名無しさん
09/07/01 10:39:35
>>738
何言ってんのお前
若年性認知症か？
741:デフォルトの名無しさん
09/07/01 22:53:57
>>740
>>740
>>740
>>740
742:デフォルトの名無しさん
09/07/01 23:46:22
「OOを使わない」と「OOを使えない」の差は大きいね。
743:デフォルトの名無しさん
09/07/02 00:03:01
この際使えなくていいよ。もう使わないから。
744:デフォルトの名無しさん
09/07/02 06:53:06
私も C++ Ver1 のころはOOはいいと思ってました。
745:デフォルトの名無しさん
09/07/02 11:14:11
C++ はそれ以外に問題が大杉だw
746:デフォルトの名無しさん
09/07/02 13:40:09
lisp属の()が可愛く見えるほど
変態構文だらけになってしまったもんなぁ > C++
747:デフォルトの名無しさん
09/07/02 13:55:39
たとえばどんな？ あるいはとくにどれが？
748:デフォルトの名無しさん
09/07/02 15:19:33
テンプレートとか今度入ってくるラムダとかのことじゃねぇの
749:デフォルトの名無しさん
09/07/02 19:17:27
boostなんかだと演算子をオーバーロードしまくってるから
とてもC++とは思えないコードになるからな。
750:デフォルトの名無しさん
09/07/02 19:21:29
日本を代表するc++ハッカーのやねうらお氏もlispが来ると言ってるね
URLﾘﾝｸ(d.hatena.ne.jp)
751:デフォルトの名無しさん
09/07/02 19:27:31
こねぇｗｗｗ
752:デフォルトの名無しさん
09/07/02 19:53:26
ぶろっがーの間でははやるんじゃね？
753:デフォルトの名無しさん
09/07/02 20:18:19
やねうらってLISP知ってたのか
組み込み寄りの人かと思った
754:デフォルトの名無しさん
09/07/02 20:30:46
ＨＳＰerとLISPerってどっちが馬鹿なの？
755:デフォルトの名無しさん
09/07/02 21:09:13
あくまでも、Lispは実験言語だな。
でも、実験言語としては非常に優れている。
プログラムとデータが渾然一体としているから、
どんな革新的な機能でも追加できる。
ただし、文法がS式なことだけ我慢すれば。
756:デフォルトの名無しさん
09/07/02 21:16:31
S式は抽象構文木として使えばいいのであって、
具象構文は普通にパーサ書けばいいだけ。
LISPは元々は自然言語処理のために開発されたことを忘れないで＞＜
757:デフォルトの名無しさん
09/07/02 22:12:54
まぁ、何だかんだ言っても馬鹿にはLispは使えませんよ
758:デフォルトの名無しさん
09/07/02 23:27:19
だからって、Lispを練習しても馬鹿が直る訳じゃないんだが、
時々それを勘違いしてる奴が居る。
759:デフォルトの名無しさん
09/07/02 23:34:50
>>756が新しい言語を作るそうです
760:デフォルトの名無しさん
09/07/03 00:13:04
guile ctax なんてものもあったけど、使われてないね。
761:デフォルトの名無しさん
09/07/03 01:09:08
他人のオナニー見ても気持ちよくないからね
762:デフォルトの名無しさん
09/07/03 14:56:07
>>756
今時RLISPかよ
763:デフォルトの名無しさん
09/07/03 15:26:45
見事にLISPスレ的な流れになったな
764:デフォルトの名無しさん
09/07/03 16:07:14
LISP語るならCLOSについて話せよ
765:デフォルトの名無しさん
09/07/03 16:26:12
モノを完成させてからオブジェクト指向で書き直すなんて二度手間です＞＜
766:デフォルトの名無しさん
09/07/03 23:15:27
>>758が「馬鹿はLispが使えない」ことを証明しますた。
767:デフォルトの名無しさん
09/07/03 23:31:13
別にわざわざLisp使う意味がわからないな
C言語でいいじゃん
768:デフォルトの名無しさん
09/07/03 23:51:48
>>767
使いなれてしまうと日常的にCを使いたくなくなるな
つか、俺にとってはCは未だに高級アセンブラ、C++は超高級マクロアセンブラ
なんでスペシャル変数を導入しないんだろ >C++
769:デフォルトの名無しさん
09/07/04 00:02:52
最近、Ｃ言語で地味に堅く組むのがマイブーム
770:デフォルトの名無しさん
09/07/04 00:43:46
高級アセンブラと思ったことはないけど、Cは十分に高級言語なので
たいていのことはこなせる。
Cより複雑なことをしたい場合は、PerlとかRubyとかのスクリプト言語にするよ
771:デフォルトの名無しさん
09/07/04 05:10:49
スペシャル変数www
それがプログラミング言語設計一般で使われる概念名称だと思ってるのかwww
ひさしぶりに腹かかえたwwwww
772:デフォルトの名無しさん
09/07/04 07:44:15
なれるとLispはCやC++よりプログラムを考えるのが楽チン
773:デフォルトの名無しさん
09/07/04 08:25:34
むかしLISPを勉強しようと思ってMSDOS用のXLISPを入手した。
これが使用中にしょっちゅう落ちる。でメンテしてめったに落ちなくしてついでに
いろんな関数を作って高級アセンブラ並にしたんだが結局Cを使った方が楽で使わ
なかった。LISPはおれにとって楽チンどころか苦痛を与えるためにあるようんもんだ。
774:デフォルトの名無しさん
09/07/04 09:12:52
マジOOは思想ごとこの世から消えて欲しい。
CやVBでさえまだ満足に使えてないのに、
周りがどんどんOOに進んでいくので、落ちこぼれ感が半端ない。
技術的というより、精神的に追い詰められる。
775:デフォルトの名無しさん
09/07/04 09:34:28
相手を追い詰めることで自分が進んでいると思えるって、ひどい相対主義だな
776:デフォルトの名無しさん
09/07/04 09:39:41
追い詰めると言うよりは、置き去りですな。
もしくは、怠慢でついて来れないだけ。
777:デフォルトの名無しさん
09/07/04 09:43:58
DOSのLispっておもちゃだったからなあ。
778:デフォルトの名無しさん
09/07/04 10:18:36
OOを捨てることは何時だって出来るのに
これだけ普及＆定着しまくってるんだから
何かしら捨てられない理由でもあるんでしょう
779:デフォルトの名無しさん
09/07/04 10:28:50
GUI 関連ならそりゃ普及してるけど、
それ以外で無理に使う必要あるか？
780:デフォルトの名無しさん
09/07/04 10:30:56
OOPはこれから規制対象になるんだけどねぇ
品質が上がらない要因といわれている
781:デフォルトの名無しさん
09/07/04 11:00:56
一定以上複雑なプログラムには有効な整理方法だよ
単純なプログラムには必要ないね
782:デフォルトの名無しさん
09/07/04 11:04:44
LinuxカーネルもWindows7のカーネルも
すごい複雑だけど1行もOOP使ってないけどね
783:デフォルトの名無しさん
09/07/04 11:12:27
WindowsにOOPが使われてないとは初耳だなぁ...
784:デフォルトの名無しさん
09/07/04 11:21:38
>>783
VistaはカーネルのコードC++で書いて
失敗した。だから全部Cで書き直したよ
785:デフォルトの名無しさん
09/07/04 11:59:26
カーネルは複雑じゃないから OOP は必要ないだろうね
786:デフォルトの名無しさん
09/07/04 12:06:50
なぜそこにOOPをつっこもうとする
787:デフォルトの名無しさん
09/07/04 12:13:00
パフォーマンス問題がクリティカルな分野でOOPなんてやるわけねーだろ
そんなん言ったら大半の組み込みプログラムが非OOPだわ
788:デフォルトの名無しさん
09/07/04 12:13:19
>>782
嘘言うなよ
LinuxはVFS周りのコードがOOPだ
789:デフォルトの名無しさん
09/07/04 12:25:43
>>788
ソースみたけど全部Cで書いてあるけど？
790:デフォルトの名無しさん
09/07/04 12:27:16
>>789
CでのOOPに決まってるだろ
791:デフォルトの名無しさん
09/07/04 12:34:06
GObject…
792:デフォルトの名無しさん
09/07/04 12:40:47
>>790
CにOOPなんてねーだろ
バカなのアホなの？
793:デフォルトの名無しさん
09/07/04 12:52:43
お前本当に頭悪いな
GObjectが何か調べてから物を言えよカスが
794:デフォルトの名無しさん
09/07/04 12:58:34
>792
お前はまずOOPとは何かを学んだほうが良いぞ
OOPLはOOPをしやすくした言語であってOOPLじゃないとOOPができないワケじゃない
795:デフォルトの名無しさん
09/07/04 13:17:00
カーネルプログラミングでGObject(汗
796:デフォルトの名無しさん
09/07/04 13:27:35
じゃばばんばぁは言語にOOPがないとOOPができないとおもってるからなぁ
797:デフォルトの名無しさん
09/07/04 14:21:06
LinusがC++嫌ってるからしかたなくCで書いたんだろ
798:デフォルトの名無しさん
09/07/04 14:25:09
手動メソッドディスパッチ…
799:デフォルトの名無しさん
09/07/04 14:32:23
>>797
LinusがC++嫌いなのはその通りだけど、そんな簡単なものでもない。
URLﾘﾝｸ(www.tux.org)
800:デフォルトの名無しさん
09/07/04 14:38:58
LinusどころかOOPLユーザの過半数がC++を嫌っているという現実
801:デフォルトの名無しさん
09/07/04 14:41:08
C++は糞これはガチ
802:デフォルトの名無しさん
09/07/04 15:48:38
>>794
そう言って、Cでオブジェクト指向プログラミングができるって
テクニックを公開しているやつをなんども見てるけど、つかえそう
なのって、カプセル化、抽象データ型くらいで、継承とか多態
までいくと「おいおい、それはムリがあるだろ」って感じのばっかり
だな。
ああいうの真に受けるやつがいるから、広めるのやめてほしい。
803:デフォルトの名無しさん
09/07/04 15:55:45
C++ を糞だと思うのは自由だが、OOP と GP の直交が醸す広大な抽象空間を
知らずに人生を終えるのはちょっともったいないと思うよ。
804:デフォルトの名無しさん
09/07/04 15:56:37
多態なんて関数ポインタ使えれば誰でも考え付くこと。
805:デフォルトの名無しさん
09/07/04 16:03:17
>>803
GPって何？ゴールドポイント？
806:デフォルトの名無しさん
09/07/04 16:07:17
>805
グレートプログラム
807:デフォルトの名無しさん
09/07/04 16:23:57
>>803
C++ のジェネリックプログラミング:
アイデアは全部よその言語のパクリ, あの変態構文を除けば… … …
808:デフォルトの名無しさん
09/07/04 17:02:27
グランプリ
809:デフォルトの名無しさん
09/07/04 17:07:01
GenericProgramingをGPと略すのはどうなんだろう
GPといったら普通は遺伝的プログラミング(genetic programming)の方かと
810:デフォルトの名無しさん
09/07/04 17:09:08
Giant Penis
811:デフォルトの名無しさん
09/07/04 17:10:36
紛らわしいシリーズとしては
generative programmingってのもある
812:デフォルトの名無しさん
09/07/04 17:18:56
GP = Generic Programming のこと。C との互換性と GP によって、C++
は今後も戦力外通告されない「潰しの効く」言語の一つたりえる。Bjarne
Stroustrup は C++ の原作者として、プログラマが言語学習に投資した
時間を無駄にするような言語仕様の変更を加えないよう、絶妙のバランス
感覚で手綱をしめてる。C++ は次の改訂でさらに初心者にやさしい使い
やすい言語になるよ。
813:デフォルトの名無しさん
09/07/04 17:21:37
>>804
それは多態じゃなくて高階関数な。
814:デフォルトの名無しさん
09/07/04 17:27:26
OOと関係ない方向で性徴
815:デフォルトの名無しさん
09/07/04 17:38:06
Generic ProgrammingやりたきゃC++なんかよりSMLやHaskellのほうがずっといい。
816:デフォルトの名無しさん
09/07/04 17:48:03
scrap your boilerplate
817:デフォルトの名無しさん
09/07/04 18:43:29
C++は組み込み分野では利用禁止が定着しつつある
一般開発では既に利用禁止が大半となっている
818:デフォルトの名無しさん
09/07/04 18:47:51
ま、C++でまともにコードかけるやつがめったにいないしな。
819:デフォルトの名無しさん
09/07/04 20:19:45
>>817
w
820:デフォルトの名無しさん
09/07/04 20:21:23
まともにかける奴がいない = かける俺が偉い
というオナニーなんだろうが
lispに比べればはるかに多いだろ
lispが使われて無いのはかける奴がいないからに他ならないわけで
821:デフォルトの名無しさん
09/07/04 21:56:18
>>817
電子回路設計ではSystemCとかいうＣ言語の亜種が出てるのにな
822:デフォルトの名無しさん
09/07/04 22:04:31
組み込みの分野で使われてるのってluaとか？
あれも、オブジェクト指向はなしで、
関数型を取り入れたって感じだな
823:デフォルトの名無しさん
09/07/04 22:09:56
組み込みってハードに近いあれの話だろ？
Ｃ言語の変な仕様バージョンが圧倒的に多い
みためＣ言語だけどＣ言語仕様にはそってないの
なんちゃって？Ｃ言語？っての？
824:デフォルトの名無しさん
09/07/04 22:27:49
qsortの無いやつもあるしな
825:デフォルトの名無しさん
09/07/04 22:33:28
そもそも標準ライブラリなんてほとんど使わん
826:デフォルトの名無しさん
09/07/04 22:47:45
C++は、現実の問題に対処できるように何でもできる言語を目指しているが、
何でもできることで、かえって現実のプログラマの集団を
うまく統制できない言語になってしまった。
言語機能の一部を使用禁止する命令とか作ったほうがいいんじゃないか？
827:デフォルトの名無しさん
09/07/04 22:53:18
>>826
実際構文解析・チェックツール使って
スタイルに合ってないヤツを書き直させてる現場もあるよ
828:デフォルトの名無しさん
09/07/04 22:53:51
>>826
いやだからEUでC++0xの仕様採択中止になったしょ？
ほらEUだとソフトウェアのレベル計測する基準とかあるだろ
あれで軒並みC++は該当外になっている。
829:デフォルトの名無しさん
09/07/04 23:05:50
>>828
へーそうなんだ。ソースどこ?
830:デフォルトの名無しさん
09/07/04 23:36:50
脳内
831:デフォルトの名無しさん
09/07/05 00:03:58
オブジェクト指向のクソなところをまた一つ発見した。
予約語が増える。
832:デフォルトの名無しさん
09/07/05 00:57:59
SKI！！SKI！！
833:デフォルトの名無しさん
09/07/05 01:45:33
>823-824
こういう感じのやつ？
URLﾘﾝｸ(ja.wikipedia.org)フリースタンディング環境
834:デフォルトの名無しさん
09/07/05 06:51:21
>>831
SmalltalkよりもCのほうが桁違いに予約語が多いのだが？
835:デフォルトの名無しさん
09/07/05 07:03:12
SmalltalkはifTrueなんかも予約語じゃないのではなかったか？
836:デフォルトの名無しさん
09/07/05 07:10:35
ifTrueやwhileTrueもメソッド名だね < Smalltalk
837:デフォルトの名無しさん
09/07/05 07:54:31
予約語が増えるくらいどうということないじゃん。
もともとCやC++はオペレータの数が少ないんだし
Lispなんてオペレータが多すぎて訳ワカメやぞ。
838:デフォルトの名無しさん
09/07/05 07:57:05
釣り、、、だよな、、、、？
839:デフォルトの名無しさん
09/07/05 08:07:29
$から変数名はじめればいいだけ
840:デフォルトの名無しさん
09/07/05 11:19:32
予約語が多いというとCOBOLを思い浮かべるが…
841:デフォルトの名無しさん
09/07/05 11:33:29
エディタがハイライトしてくれるから、予約語の数なんて大した問題じゃないだろ
842:デフォルトの名無しさん
09/07/05 11:41:19
新しい概念なんだから予約語が増えるのは当然
似て非なる言語仕様が乱立するほうがよっぽど怖いぜ
843:デフォルトの名無しさん
09/07/06 00:44:35
２０，３０くらいの予約語ならいいが、
１００を超えるのはあほだろ。
844:デフォルトの名無しさん
09/07/06 00:59:21
予約語の数がどうの言う奴は馬鹿
それよりCのように名前空間が無い言語を使ってシンボル名が衝突する方が問題
845:デフォルトの名無しさん
09/07/06 02:52:55
COBOLは酷いよな…ライブラリまるごと予約語にするから予約語の数がおかしなことになってる
846:デフォルトの名無しさん
09/07/06 08:16:05
emacs lispは酷いよな…
hoge-moge-hage-sage-pとか
名前空間の力は偉大だよ
最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5400日前に更新/178 KB
担当:undef