08/01/29 09:52:47
文法面での機能拡張しすぎ。
C++の構文解析とか、もうワケワカメ。
マイクロソフト拡張大杉。
gcnew とか使うぐらいなら素直に Java でも C# でもつかえ！！！
2:デフォルトの名無しさん
08/01/29 09:53:57
つ C++ Builder
3:デフォルトの名無しさん
08/01/29 09:55:02
標準と非標準の区別もつかない池沼か
確かにC++から離れた方がいいな
4:デフォルトの名無しさん
08/01/29 10:00:01
__LINE__ とか __FILE __ とか __FUNCTION__ はMS仕様かい？
5:デフォルトの名無しさん
08/01/29 10:12:55
＞【肥大化】ユーザー を見捨てたヤシ【複雑化】
これって何てＭ＄？
6:デフォルトの名無しさん
08/01/29 10:18:53
classname hoge;
てやったときに静的インスタンスが作られるってのがすごく扱いづらい。
JAVAみたいにみんなポインタ扱い、関数の引数は参照渡しでいいのに。
7:デフォルトの名無しさん
08/01/29 10:21:42
>>6
ヒント： 慣れ
8:デフォルトの名無しさん
08/01/29 10:22:22
>>6
お前は何を言っているんだ?
9:デフォルトの名無しさん
08/01/29 10:23:28
× C++ を見捨てた
○ C++ に挫折した
10:デフォルトの名無しさん
08/01/29 10:25:36
そもそも全てのクラスの基底になるクラスが存在していないのがおかしい
throw で何でも投げられて catch で何でも補足できるのもヤメレ。
11:デフォルトの名無しさん
08/01/29 10:27:32
void f() throw() が文法上定義されているのにコンパイラ側が未実装ってどういうことやねん！！！
12:デフォルトの名無しさん
08/01/29 10:28:50
うちの会社はなぜ C++ なんかつかっているのだ。
DirectX つかうなら C# でいいじゃんよ
過去の資産が問題ならDLL化すればいいじゃないのよ。
13:デフォルトの名無しさん
08/01/29 10:45:02
>>6
そらそうよ
ていうか静的結合って時点でC++はオブジェクト指向じゃないし。
14:デフォルトの名無しさん
08/01/29 10:53:23
>>12
逆だろ。
次の環境とか言語が発生したら、Ｃ丼資産即氏だろうが。
Ｃ丼禁止
15:デフォルトの名無しさん
08/01/29 10:58:48
C++でさ
class A {..};
class B: public A {..}
て宣言して B の静的オブジェクトを作ったとき、
B b()
これってちゃんとポリフォリズム動作するの？
16:デフォルトの名無しさん
08/01/29 10:59:56
動作するよ。常考。
17:デフォルトの名無しさん
08/01/29 11:05:50
catch (例外の最上位クラス e)
てやってクラスツリー末端の静的例外オブジェクトを投げても、ちゃんとキャッチしてくれるのか
18:デフォルトの名無しさん
08/01/29 11:15:41
そういう場合は、
catch (...)
と書く。常考。
19:デフォルトの名無しさん
08/01/29 11:16:19
＞ちゃんとキャッチしてくれるのか
yes.
20:デフォルトの名無しさん
08/01/29 11:16:46
なんだ、C++最強。
21:デフォルトの名無しさん
08/01/29 11:44:53
何一人で会話してるの？
22:デフォルトの名無しさん
08/01/29 14:07:43
（ ＾ω＾）今日もC++使うお
23:デフォルトの名無しさん
08/01/29 19:40:30
>>17-18
まあそういうのは限定的な状況でしかやるべきじゃないけどな。
24:デフォルトの名無しさん
08/01/29 21:17:05
次のc++だとまたあたらしい文法ふえるみたい。どこまで複雑にすればきがすむんだ？
25:デフォルトの名無しさん
08/01/29 21:59:54
MS拡張がクソってことだろ
26:デフォルトの名無しさん
08/01/29 23:45:50
正直、ここまでくるともう失敗作としか言いようがない気がする。
いったん破棄して全てを無に戻すんだ！
27:デフォルトの名無しさん
08/01/29 23:55:43
いや、もっと突き進んで門を狭くしてくれ。馬鹿が入って来られないように。
28:デフォルトの名無しさん
08/01/30 00:04:51
俺も、こんなんじゃまだまだ生温いから、もっとガンガンに突き進んで欲しい
一つのファイルをコンパイルするのに最新マシンで 1 時間以上かかるくらい
じゃないと C++ の到達点としては不十分だな
そして、一般人が付いてこられなくなって、言語そのものが廃れます様に
( -人-).｡oO(ﾅﾑﾅﾑ...)
29:デフォルトの名無しさん
08/01/30 01:22:34
C++ の仕様はまだまだ不十分だろ
世の中にあるプログラミング言語の機能を全て盛り込んで、
全てのアルゴリズムを標準ライブラリとして規格に入れて、
仕様書の厚みがブリタニカを超えて、コンパイラ作成者が
実装を諦めるくらいじゃないといかん
C++ は現在・過去・未来に於ける全ての言語を超越して
唯一無二の輝かしき超言語として地上に君臨し、プロ・アマ
を問わず全てのプログラマがその恩恵に感謝すべきだ
30:デフォルトの名無しさん
08/01/30 01:25:45
とりあえずGUIとCOMとブラウザと動画音声コデックぐらいは
言語仕様として欲しい
31:デフォルトの名無しさん
08/01/30 01:31:30
俺が使っている C++ とお前が使っている C++ は全然別物だな
というくらいの仕様の広がりは欲しいな。
C++ は単一にして全てを包含する、神の言葉を記す為の言語だ。
32:デフォルトの名無しさん
08/01/30 01:33:01
boost::lambdaを使ってるとC++のコードに見えなくなってくる。
33:デフォルトの名無しさん
08/01/30 01:42:52
>>24
複雑性を認識出来るうちはまだまだなんだって。
本当に複雑な物は、それが複雑なのかどうかすら 分 か ら な い 。
34:デフォルトの名無しさん
08/01/30 01:51:38
言語仕様にテトリスとマインスイーパーが入るのはいつかな。
35:デフォルトの名無しさん
08/01/30 01:54:12
昔のgccは
#pragma
って書くとcppがダンジョンゲームを立ち上げたんだぜ、豆知識な
36:デフォルトの名無しさん
08/01/30 08:12:49
MS拡張ではなく、次期 Ansi C++ の仕様では
std::vector<int> v = { 1, 2, 3 };
というのが可能になるらしい。。。。
ｽﾚﾘﾝｸ(tech板)
37:デフォルトの名無しさん
08/01/30 08:39:16
やはり C >>>>>>>>>>>>>>>> C++ みたいです。
URLﾘﾝｸ(www.aoky.net)
38:デフォルトの名無しさん
08/01/30 15:28:18
>>37
OOPを正しく理解していたらC>>>C++になるわけがないのだが。
39:デフォルトの名無しさん
08/01/30 19:20:39
OOP は言語に依存しないからな
40:デフォルトの名無しさん
08/01/31 05:39:07
他人と一緒にC++を使う難しさはよくわかるんだけど、
自分一人で使う場合、本人がまともに勉強してさえいれば、C++の複雑さの殆どは
長所として機能すると思う。
41:デフォルトの名無しさん
08/01/31 09:06:20
コンパイルに時間が掛かるのが好きな人ならそうだろうね
42:デフォルトの名無しさん
08/01/31 10:27:21
C++ は一人で使っていても面白くないよ
43:デフォルトの名無しさん
08/01/31 10:30:19
>>41
そりゃー、お前はヘッダに全部書くからそうなるかもしれないけどさ。
44:デフォルトの名無しさん
08/01/31 14:30:20
>>43
C++の旨味ってヘッダに殆ど書ける所だろ。
テンプレートライブラリが典型。
45:デフォルトの名無しさん
08/01/31 16:56:36
典型というかそれだけだな。
あとの場合でやるのは、コンパイルに時間が掛かるのが好きな人or無能。
46:デフォルトの名無しさん
08/01/31 21:08:27
むしろC++は一人向けだろ。フリーソフトなんてみんなC++なわけで。
企業でチーム開発はJavaとかしょ
てか10年以上C++やってる俺にとっては肥大化どころか機能不足に感じるよ。
使えるoperator記号とかもっと増やしてほしい
47:デフォルトの名無しさん
08/01/31 22:06:01
>>43
もしかしてC++のコンパイルが遅いのに気付いてないのか?
羨ましいな感覚の持ち主だな。
48:デフォルトの名無しさん
08/01/31 22:12:08
なにがどれくらい遅いと言ってるの？
49:デフォルトの名無しさん
08/01/31 22:57:58
コンパイル速度が超遅い
50:デフォルトの名無しさん
08/01/31 23:05:49
>>46
一人じゃ優越感に浸れないじゃん。個人で勝手にアプリ作ってるのに
わざわざC++使ってる俺ってこんなに凄いぜだけじゃ単なる自己満足。
51:デフォルトの名無しさん
08/01/31 23:31:11
>>45
>典型というかそれだけだな。
C++ユーザの心の支えを軽々しくそれだけとか言うな。
むしろそれこそが全てだ。それ以外に利点など無い。
52:デフォルトの名無しさん
08/01/31 23:32:25
>>50
C++で優越感に浸りたいって・・・おまえ向いてないよ・・
53:デフォルトの名無しさん
08/01/31 23:34:32
>>49
いやだから超遅いって・・なにがどうなのよ
54:デフォルトの名無しさん
08/01/31 23:36:21
（なにが）：コンパイル速度が
（どうなのよ）：超遅い
55:デフォルトの名無しさん
08/01/31 23:39:44
質問が悪い。
56:デフォルトの名無しさん
08/01/31 23:47:20
くだらね
57:デフォルトの名無しさん
08/01/31 23:52:14
これは仕方が無い
58:デフォルトの名無しさん
08/02/01 00:09:09
>>52
他にわざわざC++を持ち出す理由なんて無いだろ。向きは典型的だよ。
59:デフォルトの名無しさん
08/02/01 00:37:33
ANSI C++ を完璧にサポートしてるコンパイラって何？
MSVC++ は
void hoge() throw(std::bad_alloc) {...}
ていう例外指定が未実装だからダメだし。
60:デフォルトの名無しさん
08/02/01 07:08:01
>>47
それは君が「でっかいプロジェクト」を強く想像するあまり、これが個人のプログラミングの話だってのを
失念してるからでは。
個人作業なら、その辺はまともにやればかなりスマートになるよ。
俺が想定したのは、俺なりの「普通の個人のプログラム」・・・具体的には、10万行未満の少ないコード量で、
マシン性能がまぁ普通で、書き手が「無能ではない」ケース。
このケースで5秒以上かかるコンパイルなんて滅多に起こらない。
まぁ、個人の感覚に結構差があるのは確かで、この5秒に対してそこまで皮肉めいた羨ましさを示すのなら、
そこで話は物別れになってしまうんだけれども、俺的にはその5秒は、腕でも伸ばして身体をほぐすのに丁度良いんだ。
61:デフォルトの名無しさん
08/02/01 09:21:48
コードを書くのにオープンソースのライブラリに手を入れて使うのは想定外
なんだろうな。気分が乗ってコーディングしている時にも一々コンパイラを
走らせる度に強制的に休憩を取らされるのを鬱陶しいと思った事は無いのかな。
羨ましいというか珍しい感覚の持ち主だよ。C++のコンパイルが遅いという
過去繰り返し叫ばれている客観的事実を認めたがらない人間は初めて見た。
10万行が5秒で終わるかどうかは週末にでも計測しておく。
62:デフォルトの名無しさん
08/02/01 09:30:42
＞コードを書くのにオープンソースのライブラリに手を入れて使うのは想定外なんだろうな。
＞10万行が5秒で終わるかどうかは週末にでも計測しておく。
Ｃ＋＋とは無関係だろ。常考。
ま、Ｃ＋＋のコンパイルは劇遅だが。
63:デフォルトの名無しさん
08/02/01 10:17:06
>>62
kwsk
64:デフォルトの名無しさん
08/02/01 10:23:19
うちの会社は、なぜかライブラリを dll 化したり lib かしたりしません。
プロジェクトには大量のライブラリ用 hとcppが登録されており、リビルドする時は
強制的にコーヒー休憩です。
65:デフォルトの名無しさん
08/02/01 10:42:43
>>63
何を聞きたいのかkwsk。
前文なら、１０万行のオプソなら、どの言語でもおせーよ、だし。
後文なら、C++ってクラス毎にヘッダーがあってあらゆるcppファイルで展開されるから、
プログラムが短いのに何万行もコンパイルされてるー、みたいになるし、
文法が複雑だから、コンパイラの構文解析が手間取るんじゃね？
66:デフォルトの名無しさん
08/02/01 22:09:59
まあスクリプト厨が増えた現代ではC++できると優越感になるのかもな。
昔はできてあたりまえだったのになあ
67:デフォルトの名無しさん
08/02/02 01:17:28
>>64
dll, lib, so, sl, a, dylib等にしないものをライブラリとは言わないのでは？
あと、まさかdependency checkもしてないとか言わないよね。
68:デフォルトの名無しさん
08/02/02 01:47:14
dependency check ってなに？
69:デフォルトの名無しさん
08/02/02 01:57:58
ビルド時においては、コンパイル対象ファイルが依存するファイルの更新状態を確認し、不要なコンパイルを省略すること。
70:デフォルトの名無しさん
08/02/02 04:31:06
そういうのはしてないよという話に見えるが…
71:デフォルトの名無しさん
08/02/03 00:42:09
>>61
> 一々コンパイラを走らせる度に
> 10万行が5秒で終わるかどうかは週末にでも計測しておく。
この2つが同時に出てくるということは、明らかに誤読してるか、あるいは君のコーディングは
何かを変更するたびに一々そのプログラムの全行がコンパイルし直される
問題外な構造だってことだな。
72:デフォルトの名無しさん
08/02/03 03:28:21
>>71
他の人が誤読してるのかなと思ったら、その周囲のレスを
もう一度注意深く読み返してみると良いよ。レスは慎重に。
73:デフォルトの名無しさん
08/02/03 04:36:13
10万行は2,3分はかかるねえ。普通はある程度コンパイルする単位を
プロジェクトとして分けるね。
74:デフォルトの名無しさん
08/02/03 12:11:25
分割するかどうかは別の文脈で出て来た話なんだけどね。
一つのレスの中で複数の文脈が出てくると混乱する人がいるみたいだ。
10万行のコンパイル時間の話は、他の言語に比べてC++のコンパイル
時間が劇的に遅いという議論で出て来ている事だから、分割するしない
の議論とは独立した話なんだけどね。他の言語だって分割コンパイル
すればもっと速くコンパイルが終わる訳だから。
75:デフォルトの名無しさん
08/02/03 14:09:29
>>72
いや、「自分一人の裁量で好きに書かれた全10万行程度のプログラム」であれば、
まともに書けていればそう滅多に全体をコンパイルすることなんて起きないから、
C++のコンパイルの遅さをモロに味わうことなんて滅多に無い、と言っているのに、
なんで「何かするたびに一々」という言い方で「10万行のC++コードをコンパイルするのにかかる時間」
について語るんだろう、と思って。
それに、開発環境2つ起動させといて、片方が長めのコンパイルしてる間は他方で作業を続行するとか、
それくらいは普通に工夫するのでは。
76:デフォルトの名無しさん
08/02/03 16:03:20
>>75
なんでかと言えば、そういう話をしている訳じゃないからだよ。
流れが見えてないのに無理矢理レスする神経が分からん。
77:デフォルトの名無しさん
08/02/03 16:09:06
そりゃ他の言語はその分のしわ寄せが、実行時に遅いってことで出てくる
わけだからね。
てか、他のコンパイル言語？って何のこと言ってんの。Delphi？
78:デフォルトの名無しさん
08/02/03 16:15:56
結局まだC++のコンパイルが遅いという事実を直視出来ない奴はいるのか?
79:デフォルトの名無しさん
08/02/03 16:40:00
どうしたの？仕事つらいの？
80:デフォルトの名無しさん
08/02/03 16:42:45
いや、光を見つけられない人が居るのが心配なだけ。
81:デフォルトの名無しさん
08/02/03 17:14:09
コンパイルも実行速度も速いのがあればいいんだけどね
82:デフォルトの名無しさん
08/02/03 17:17:53
>>80
へんな光が見えちゃう病気でつか。早く治るといいね。
83:デフォルトの名無しさん
08/02/03 17:20:50
>>81
C++が特段実行速度が速いという訳ではないからね
84:デフォルトの名無しさん
08/02/03 17:25:29
こんな簡単な事実からすら目を逸らそうと必死になるなんて、毎日大変だろうな…
85:デフォルトの名無しさん
08/02/03 18:04:31
C++以外の言語は遅すぎるのでせいぜいWebアプリにしか使えないことが
この10年でわかった事実
86:デフォルトの名無しさん
08/02/03 19:06:53
おまいは10年間寝てたのか？
87:デフォルトの名無しさん
08/02/03 19:27:23
>>85
残念だがそれなりに事実ではあるな
88:デフォルトの名無しさん
08/02/03 19:33:54
自己レスが流行ってるのか？
89:デフォルトの名無しさん
08/02/03 20:31:41
標準化委員会の中の人にすら理解できない言語というのも珍しい。
90:デフォルトの名無しさん
08/02/03 20:45:26
他言語は個人の趣味で作られてるからな
91:デフォルトの名無しさん
08/02/03 20:59:50
対岸の C++ を見ていると、GLS が如何に偉大かが分かるよな
92:デフォルトの名無しさん
08/02/03 21:09:00
主流に乗り損ねた奴らはいつの時代もみじめなもんだな
93:デフォルトの名無しさん
08/02/03 21:14:25
つまらん事を気にするな
主流じゃなくともBoostとか楽しげじゃん
94:デフォルトの名無しさん
08/02/03 21:41:11
>>91
仕事ない言語選んじゃった奴はかわいそうだよね。対岸で指くわえてないで、
今からC++とかJavaとか勉強しなよ。まだ間に合うって。
95:デフォルトの名無しさん
08/02/03 21:51:51
>>94
GLS も知らない素人に Java を勧められた場合はどうすれば良いでしょうか?
96:デフォルトの名無しさん
08/02/03 22:00:15
>>95
求人広告はC++/Javaばっかだもんね。いやだよね。
最初は難しいかもしれないけどそのうちできるようになるよ。
97:デフォルトの名無しさん
08/02/03 22:02:25
恥の上塗り
98:デフォルトの名無しさん
08/02/03 22:07:08
C++は才能ない奴は何年やっても無理
99:デフォルトの名無しさん
08/02/03 22:13:06
『GLS？何だ、また新しいLLかよ。どうせ俺の理解出来ないチャラチャラした
機能が満載なんだろう。取り敢えず煽っとけ』みたいな感じかな?
100:デフォルトの名無しさん
08/02/03 22:16:47
そこでPHPですよ
101:デフォルトの名無しさん
08/02/03 22:22:14
>>98
最新の便利言語を一切無視してC++を続けるには非凡な才能が必要そうだね
超越した忍耐力がないと続かないよ
102:デフォルトの名無しさん
08/02/03 22:24:51
>>94=96 はもう少し Java を勉強した方が良いよ
2ch だから許されるけど、世間では冗談では済まないだろうて…
103:デフォルトの名無しさん
08/02/03 22:31:48
>>100
PHPじゃメーラもワープロもブラウザも作れないし
>>101
どの会社でもみんな普通に使ってるC++/Javaが憶えられないとか、忍耐力がいるとか
ってかわいそうだね。確かに難しくはあるけどね。他人についていけずに焦る
気持もあると思うけど少しずつがんばりなよ。
104:デフォルトの名無しさん
08/02/03 22:33:51
>>103
Java を知らないのは君な訳だが…
君はもう少し焦った方が良いと思うよ。頑張っても無駄かもしれんが。
105:デフォルトの名無しさん
08/02/03 22:40:13
>>101
C++挫折者必死だな。どこでつまづいたんだ？
106:デフォルトの名無しさん
08/02/03 22:45:03
都合が悪くなると話を変えるのなw
107:デフォルトの名無しさん
08/02/03 22:46:08
>>105
ところで C++ の設計者の名前は知ってるのか?
108:デフォルトの名無しさん
08/02/03 22:50:35
>>105
まあここ挫折者スレだし・・
109:デフォルトの名無しさん
08/02/03 22:53:18
つまり>>105は挫折したという事か。
110:デフォルトの名無しさん
08/02/03 22:54:31
C++に才能なんて必要ないだろ。何いってんだ、お前ら。
必要なのはモチベーションだよ。
111:デフォルトの名無しさん
08/02/03 22:58:57
>>105
どこでつまづいたとかは恥ずかしくて言いたくないもんだろ
112:デフォルトの名無しさん
08/02/03 23:00:37
そうだな。まずは>>105から告ってみたら？
113:デフォルトの名無しさん
08/02/03 23:04:14
>>105が非常に人気者な件
114:デフォルトの名無しさん
08/02/03 23:04:20
挫折者って次どこに逃げるんだろうな。やっぱVB？
115:デフォルトの名無しさん
08/02/03 23:05:36
>>105
質問みたいだぞ
116:デフォルトの名無しさん
08/02/03 23:10:50
お前らみたいなカスにC++は無理。Rubyでもやってろ。
117:デフォルトの名無しさん
08/02/03 23:12:41
>>116=>>50 だろ。C++で優越感に浸ってるのって・・・
118:デフォルトの名無しさん
08/02/03 23:29:32
C++に挑戦しようという気になってきました。なにから始めたらいいでしょうか？
119:デフォルトの名無しさん
08/02/04 00:19:39
C
120:デフォルトの名無しさん
08/02/04 01:00:59
GUI周りが面白いかもね。すぐに効果がわかって。
121:デフォルトの名無しさん
08/02/04 01:33:17
>>120
オブジェクトが形として見えるから良いとは思うけど、
問題はどのライブラリを使うかだよね。
MFCはフリーじゃないしmain隠蔽とかメッセージマップとか独自過ぎ、
wxもメッセージマップだし、Qtはmocとかいう独自プリプロセッサだし、
FOXやFLTKはまともに日本語が使えないし、
Windows Formsは悪くないけどC++/CLIは独自拡張で論外だし、
初心者に優しいライブラリがまったくない。
122:デフォルトの名無しさん
08/02/04 02:07:34
C++の勉強のためのGUIならWin32かな
123:デフォルトの名無しさん
08/02/04 02:23:35
変なラッパーやライブラリより直叩きの方が素直だとは思うけど、
C++というよりC言語の勉強になるような希ガス。
124:デフォルトの名無しさん
08/02/04 08:55:51
Win32ってライブラリがあるんですか？
125:デフォルトの名無しさん
08/02/04 09:25:50
>>121
一応、gtkmmというのもあるけど。
GUIやるならJavaがいいよ。どこでも動くしさ。
126:デフォルトの名無しさん
08/02/04 11:41:28
>>124
ライブラリっていうかWindowsに最初から付いているAPI。
C言語の関数の塊なんで、C++のクラスとかは使っていない。
この辺を見て地道に勉強するしかない。
URLﾘﾝｸ(www.kumei.ne.jp)
はっきり言って初心者向けではないし面白くもないと思う。
最初は意味不明でひたすら写経になる。
理解しようとしても徒労だと思うのでパターンに慣れるしかない。
半年くらいひたすらやっているとパターンがつかめてくる。
仕事で強制でもされなければ大抵は挫折するんだけどさ。。。
まあ、要するにC/C++でGUIは初心者には鬼門だってこと。
GUIでオブジェクト指向を勉強するならC#かJavaの方が良い。
127:デフォルトの名無しさん
08/02/05 10:21:29
GLSってなに？ググってもプログラムと無関係ぽいのばかりでてくるんだけど
128:デフォルトの名無しさん
08/02/05 10:45:15
>>127
オリジナルの Java の仕様策定者の一人だよ。C++ はストラウストラップが
有名だけど、Java はゴスリング、ジョイ、スティール (GLS) の三人で最初の
仕様を作ったんだ。
GLS は ECMAScript, Scheme, Common Lisp, C, Java, Fortran などの
仕様決定にも関わっていて、プログラミング言語の権威中の権威であり、
コンピュータサイエンス界の大巨人。ストラウストラップみたいな素人上がり
とはバックグラウンドが違う。
まあ単に Java を書けるだけのプログラマなら GLS を知らないかもしれんけど、
もう少し上のレベルの人間には常識。
129:デフォルトの名無しさん
08/02/05 12:01:26
>>94 が如何に滑稽なレスだったか理解してもらえたかな?
知識が無いのは仕方が無いが、自分の身の丈を知らないのは恥ずかしいぞ。
130:デフォルトの名無しさん
08/02/05 21:48:11
129の釣られすぎにﾜﾛﾀ
131:デフォルトの名無しさん
08/02/05 22:32:05
127=128にﾌｲﾀ
132:デフォルトの名無しさん
08/02/05 22:38:00
windowsのアプリ作りたいんだが、独自拡張が少ないのはどれか教えてくれエロい人
ちょっと見た感じC++Builderかな？
133:デフォルトの名無しさん
08/02/05 22:49:20
>>130=131
負け惜しみのレスは心の中にしまっておくのが大人の態度だよ
134:デフォルトの名無しさん
08/02/06 04:24:52
なにここ・・粘着キモスレだな
135:デフォルトの名無しさん
08/02/06 09:03:59
スレタイ見れば分かるだろw
136:デフォルトの名無しさん
08/02/06 09:10:20
>>128
ごくろーさん、がんばったね。偉い人の名前いっぱい知ってるんだ。
レポートでいい点取れるといいね。ﾌﾟ
137:デフォルトの名無しさん
08/02/06 09:11:37
>>132
C++ Builderはプロパティとかコールバックとか独自拡張しまくり。
おまけに__fastcallを押し付けられるし。
素直にWin32APIを直叩きすれ。
138:デフォルトの名無しさん
08/02/06 09:30:43
ま、開発スピードではC++ Builder最強。
クロスプラットフォームじゃwx-devcpp最強じゃね？
139:デフォルトの名無しさん
08/02/06 20:38:02
Builderはやめとけ
独自拡張だらけ、バグだらけ、コンパイラはカス
ろくに使ってない俺ですら、ダメだしせずにはいられないぐらいひどい代物だ
140:デフォルトの名無しさん
08/02/06 20:38:32
おまけに参考文献ろくにないし
141:132
08/02/06 22:05:45
そうですか。
やっぱりVC++が無難かな。
JAVAに慣れてしまったおれにはイベントハンドラとかメッセージとか何言ってんのかさっぱり分らないんだがしょうがないな。
それかDLLだけ作ってC#にするか。
アドバイスくれたみなさんありがとう。
142:デフォルトの名無しさん
08/02/06 23:48:21
>>136
そんなに僻む時間があるならもっと勉強した方が良いと思うよ
前向きに
143:デフォルトの名無しさん
08/02/07 08:38:20
＞ろくに使ってない俺ですら、
＞ダメだしせずにはいられないぐらいひどい代物だ
矛盾。
VC++/MFCを一回使ってみ？
これって何言語っていうくらいヘンテコですぐに投げ出すこと請け合い。
144:デフォルトの名無しさん
08/02/07 22:35:11
ろくに使ってない俺ですら、
コンパイラのだめさ加減（普通なら通る構文が通らない等）や、
IDEのバグを沢山知ってしまってるって話だよ
使い込んだら、一生根に持ちそうだ
145:デフォルトの名無しさん
08/02/08 08:42:17
本当にその通りだねｗｗｗ
VC6 と VC7 の互換性
URLﾘﾝｸ(program.station.ez-net.jp)
□ COM 動かず…
さて、エラーも取り除けたということで動作させてみたのですけど、CreateObject をして、そのあとでメソッドを呼び出してみると…、DLL の読み込みでエラーが発生してしまいました。
どうやらうまく移行できなかったようです。
146:デフォルトの名無しさん
08/02/08 08:49:34
VC++のダメさ加減というのは、COMや、最近ではドトネトを混ぜないと開発できないところ。
C++のソースの中でのCOMの複雑怪奇かつ素直にクラス派生できないわずらわしさは最強。
VC++を捨てればスッキリ。
147:デフォルトの名無しさん
08/02/08 09:10:11
VC++ ← ネイティブとCOMとドトネトの三つ巴でC++を複雑怪奇にしたA級戦犯
148:デフォルトの名無しさん
08/02/08 19:37:55
過渡期ですからしょうがないっすよ・・・
149:デフォルトの名無しさん
08/02/13 02:27:47
つーか全然.netの仕事来ないんだが、、、
.netを使わないでくれってのばっか
150:デフォルトの名無しさん
08/02/13 05:44:13
そりゃお宅が使えばクソ重くなるからな
151:デフォルトの名無しさん
08/02/14 02:37:23
結局のところ、世の中に完璧なものはなく
自分に合うかどうか
152:デフォルトの名無しさん
08/02/16 02:14:03
try{...} catch{...} finally{...} 排除スレ
ｽﾚﾘﾝｸ(tech板)
1 名前: デフォルトの名無しさん Mail: 投稿日: 2008/02/15(金) 14:15:49
重いんじゃボケ
153:デフォルトの名無しさん
08/02/16 13:53:04
>>146
COMはC++から使うもんではないですぜ。
スクリプト言語やVBAからつまむもの。
そうも言っていられないのが現実だけど。
154:デフォルトの名無しさん
08/03/10 00:57:23
まあ、オブジェクト指向が理解できない内は、「Windowsのプログラムは複雑でわかんね」になるねぇ
155:デフォルトの名無しさん
08/03/10 01:01:09
オブジェクト指向ってそんなに難しいのか?
俺はオブジェクト指向言語から入ったから、難しいというのが理解出来ん。
156:デフォルトの名無しさん
08/03/10 09:19:33
プログラミングってのは、言葉。一番はじめにおぼえた言葉を簡単に感じるもの。
次に覚える言葉は外国語。
157:デフォルトの名無しさん
08/03/10 12:02:46
>>155
オブジェクト指向なんて気取った言い方を止めない限り
理解しやすくはならないんじゃないかな?
「型定義指向」みたいな言い方の方が理解しやすいと思うんだけどねぇ
158:デフォルトの名無しさん
08/03/10 12:17:56
＞「型定義指向」
これだと分かんないじゃん。
クラス宣言指向のんが良いんじゃない？
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なども同様。
宣言型言語に対してはともかく、
他の命令型言語に対してそれらの知識は水の泡にはならないと思う。
水の泡になるくらい応用力無いならＰＧ向いてない。
340:デフォルトの名無しさん
08/04/27 18:01:54
>>338
否定する気は無いけど、とりあえず>>327読んでからレスした方がいい
341:デフォルトの名無しさん
08/04/27 18:05:41
>>327のリンク先のことな
342:デフォルトの名無しさん
08/04/27 18:08:15
>>340
338ではないが、327 の考え方はゆがんでいると思うので、どうかな？
もっとシンプルにオブジェクト指向をとらえないと訳わからんようなるよ。
具体的にどう挙動するかなんて見たら、全部チューリングマシンになっちまう、そんなの意味無い。
歴史を紐解いたら、紆余曲折して進歩した以上、全部オブジェクト指向になりかねない、そんなの意味無い。
343:デフォルトの名無しさん
08/04/27 18:13:55
> 具体的にどう挙動するかなんて見たら、全部チューリングマシンになっちまう
同じように、342の言う「もっとシンプルにオブジェクト指向をとらえる」を当てはめれば、
全部メッセージになってしまう気がする、Cの関数呼出やアセンブリでのジャンプすらも。
どっちも次元や方向性は違えど、極論すぎるという点では同じと感じた。
344:デフォルトの名無しさん
08/04/27 18:15:20
>>343
言葉の定義なんだから、今主流的に言われている物でいいんだよ、変な事は考える必要はないかと。
345:デフォルトの名無しさん
08/04/27 18:18:26
オブジェクト指向はともかく、
メッセージって言葉は主流だと思えないけど。
346:デフォルトの名無しさん
08/04/27 18:22:48
>>341
アレは読んだが、アレを鵜呑みにする限り
C++＝OOを理解しないタコ
と言うレッテルは消えないだろうな
(まぁ、実際テンプレートにハマってしまえば
そんなレッテルはられようとどうでも
よくなるが…)
だが、Cで掛かれたドライバですら意識して
設計されてるんだ。言語に捕らわれ
設計思想として意識しないのは勿体無い。
347:デフォルトの名無しさん
08/04/27 18:26:51
C++はオブジェクト指向以外にもいろいろ広範囲に可能なことや思想が入っているから
オブジェクト指向ができないから駄目だという事にはならない訳で・・・
奇妙なオブジェクト指向は問題とは思うが、C++を知らないというのはさびしい話だね。
348:デフォルトの名無しさん
08/04/27 18:28:54
逆に、純粋にOOだけやっていたいというのであれば、
C++を使わないのもある意味正解。誘惑や罠が多すぎる。
349:デフォルトの名無しさん
08/04/27 18:40:20
クラスの肥大化防止はどうしたんだよ。
350:デフォルトの名無しさん
08/04/27 18:42:00
>>343
制御構造なんてのはメッセージを
受け取った相手の振る舞い又は
伝達手段の一部。
メッセージは多態であり抽象的な
もので、制御そのものをメッセージと
捉えるのは違うと思う。
351:デフォルトの名無しさん
08/04/27 18:48:09
>>346
340で書いた通り否定する気は無いけど、
327の先にある「このどれに軸足を置くかの違いでしかない」のところは正しいと思う
シンプルに捉えるのは良いけど、あんまり突き詰めると逆に混乱するぞ
オブジェクト指向という言葉が厳密に意味付けされてないからな
352:デフォルトの名無しさん
08/04/27 18:58:26
お前らスレタイ読めよ。
C++の話なんだからそんなもんどうでもいいだろ。
353:デフォルトの名無しさん
08/04/27 18:58:52
全ては関数
全ては入出力
全てはオブジェクト
全てはメッセージ
全てはリスト
354:デフォルトの名無しさん
08/04/27 19:04:18
>>352
まともなOOが出来ない→C++ｲﾗﾈ
→否意識・設定の仕方の問題だ
↑の流れと見ればスレタイの範囲では?
355:354
08/04/27 19:06:06
設定じゃなく設計だったｽﾏﾝ
356:デフォルトの名無しさん
08/04/27 19:09:56
じゃぁ、まともなOOはできないが素直なOOができるってことにしとけ。
357:デフォルトの名無しさん
08/04/27 19:20:35
てかよくよく考えたら別にOOじゃなくたってC++だったらいいんだ。
C++まんせー！
358:デフォルトの名無しさん
08/04/27 19:24:52
そうやってアイデンティティが一つ一つ消えていくんだな…
359:デフォルトの名無しさん
08/04/27 19:48:44
ところで、昨日ブレークポイントで止めてから丸一日が過ぎようとしているのだが…
おれ何やってたんだろ。
360:デフォルトの名無しさん
08/04/27 19:52:10
折角苦労して C++ 覚えたのに C で何の問題も無い事を見せつけられたら...ってそんなわけあるかぼけぇ!!!
こちとら、趣味でC++覚えたが、Cよりも便利で感動しとるわ!!!
少なくとも、Windows用のフレームワークを自作すれば、「Cで何の問題も無い事なんて有り得ない」って気が付くはずだが
361:デフォルトの名無しさん
08/04/27 19:54:50
オブジェクト指向とか言って、気構えているから難しいんだよ
ライブラリの読み書きの仕方程度に思ってりゃ楽勝さ
362:デフォルトの名無しさん
08/04/27 20:00:28
>>360
とはいえ、Windowsには独自のOOがあってCでも困らないという。
363:デフォルトの名無しさん
08/04/27 20:02:11
C++ いろいろな物が限界に達しているからな
コンパイルは遅いし、リンクも遅いし、言語もこれ以上の拡張はヤバすぎるし、ライブラリの混沌ぶりも尋常でないし、まともな開発補助ツールはないし
実用的オブジェクト指向をこの世に出現させ、これは他の言語で開花した。
以後の最大の成果としては template プログラミング、これも他の言語へ移行中。
一通り終わったら、次の世代に託して静かに消え去ってもらうのが良いと思うよ。
364:デフォルトの名無しさん
08/04/27 20:04:41
>>363
まぁまだ先の話だしな。
おれが先かC++が先かってくらい遠い将来の話だろ。
C++が死滅するのは。
今からそんなこと考えたって無駄だな。
365:デフォルトの名無しさん
08/04/27 20:06:41
>コンパイルは遅いし、リンクも遅いし
この二点だけで終わってるよ、マジしゃれならんレベルにまで落ち込んでる。
業務で使っているなら、他の言語にも触ったことがあるなら、深刻さは分かるはず。
366:デフォルトの名無しさん
08/04/27 20:25:11
少なくとも、templateがADAを除き
完全に他に移ることは無いと思うぞ。
他の言語に
class Container<type>
{
priverte type member;
public type pop(){…}
public void push(type x){…}
}
なんて構造があってもtypeは(void*)
と変わらんからな。呼び出し時
Object obje;
Container<Object> list;
list.push(obje);//○
list.push(3); //×
のように制約が加えられるだけ。
恐らくこの先もコストがデカすぎて
実行時にクラス内の構造が変わる
コンパイル言語はでてこないだろ。
367:デフォルトの名無しさん
08/04/27 20:25:46
次がないからみんな困ってる
368:デフォルトの名無しさん
08/04/27 20:27:39
>>365
そこで分割コンパイルとプリコンパイルドヘッダを活用するってことだな。
369:デフォルトの名無しさん
08/04/27 20:29:25
>>368
そこまでやっても話にならない現状を一度他の言語をみて思い知っておくといいと思う。
370:デフォルトの名無しさん
08/04/27 20:41:24
>>362
それで困るから、フレームワークを自作するんだけどな
個人で使う分には、MFCやWTLほど大げさじゃなくてもいいし
371:デフォルトの名無しさん
08/04/27 20:44:14
c++の資産って他の言語から使えんの？
.netだとc++/cliでラッパー作って・・・ってするらしいけど
cだと普通に呼び出せたりするのにな
372:デフォルトの名無しさん
08/04/27 20:46:11
>>371
通常はCOMにする、ATL使ったら一発。
VBだろうか、VB.NET だろうか C# だろうが、死滅しかけのその他.NET言語でもイケる。
373:デフォルトの名無しさん
08/04/27 20:46:26
>>371
そりゃ使えるでしょVBからでもC#からでも
374:デフォルトの名無しさん
08/04/27 20:48:53
>>369
上から目線だｗ
C++使いは盲目的でC++しか使ったことがない教団の人ですか？
375:デフォルトの名無しさん
08/04/27 20:52:38
オープンソースのアプリに C++ のコードが混じってると
コンパイルがスローモーションになるから直ぐ分かるw
376:デフォルトの名無しさん
08/04/27 20:53:30
死滅しかけと言えばJ♯はどうなったんだ？
377:デフォルトの名無しさん
08/04/27 20:56:47
>>375
ビルドしかしないからそう見えるのでは？
修正→ビルド→…って繰り返してれば分割コンパイルや
プリコンパイルドヘッダの効果が出るよ。
確かにもうちょっと早くなってくれればいいんだけどねぇ。
378:デフォルトの名無しさん
08/04/27 20:58:44
>>377
そんなの当然やっての話ですよ。
どれほどの差があると思ってるんですか？
379:デフォルトの名無しさん
08/04/27 20:59:20
>>376
死滅がどうとかいうステージにすら立てないだろうその題材じゃｗ
380:デフォルトの名無しさん
08/04/27 20:59:21
>>368
Boost.SpiritとかBoost.LambdaとかP-Stade.Ovenとか
分割コンパイルとプリコンパイルドヘッダではどうにもならないんだが。
LambdaだけはC++0xで用済みになってくれるが。
>>366
Dのテンプレートはそんなんじゃなさそうな雰囲気。
Dを取り巻く環境（ツールやライブラリ）でまだまだ移ろうという気にならないけど。
381:デフォルトの名無しさん
08/04/27 21:00:54
つかC++のビルドって、リンクだけでお話しにならないからな
382:デフォルトの名無しさん
08/04/27 21:01:25
オープンソース戦士登場！
自由のために戦いまっす！！！
ソースダウンロード！まけまけいんすとーる！
おっせ～～～！C++だっせ～～～！
↑
こんなのに言い負かされてしまうｗ
383:デフォルトの名無しさん
08/04/27 21:03:37
>>378
ほ～～。
じゃぁ君はC++のとこだけ遅くなるからすぐわかるってくらい
全面的に修正してからリビルドするのかね。
そりゃぁすごいもんだ。
384:デフォルトの名無しさん
08/04/27 21:05:20
>>383
まぁ、井戸の外出た時にでもカルチャーショク受けてくださいなw
385:デフォルトの名無しさん
08/04/27 21:06:03
>>380
spiritは駄目だな。
あれはやりすぎだ。
変態的だとは思わないけどな。
386:デフォルトの名無しさん
08/04/27 21:08:06
>>384
遅いのは誰でも知ってることなんだよ。
使ってる人間が一番困ってるにきまってるだろうに。
387:デフォルトの名無しさん
08/04/27 21:08:56
>>383
コアな所を修正してたら再ビルドは全体に渡るんじゃないの。
388:デフォルトの名無しさん
08/04/27 21:10:33
>>387
プリコンパイルヘッダを限界まで効かせても、コンパイルが多方面に渡らなくても十分遅いからw
389:デフォルトの名無しさん
08/04/27 21:11:05
>>387
オープンソースのコアなとこを修正してビルド。
390:デフォルトの名無しさん
08/04/27 21:12:48
>>371
D言語の作者は制限無しにリンクするのは無理っていってる
多重継承とか例外周りが難所らしい
391:デフォルトの名無しさん
08/04/27 21:14:09
MFCだけどビルドのみだとチグハグなコトに・・って経験が何回もあると
ちょっとした変更でもリビルドやりたい病にかかる
392:デフォルトの名無しさん
08/04/27 21:16:19
MFCはビルド早いからいいけどな。
テンプレート駆使されると極端に遅くなるよな。
393:デフォルトの名無しさん
08/04/27 21:21:54
C++のビルドで、深刻な点の一つは参照先のobjが増えた時にリンクが加速的に遅くなる点だな。
独立プロジェクトが三個・四個になったら平気で5分となるが、この時間だけで C#やVBなら五回全ビルドできる。
まぁ、小さいプロジェクトを使っているうちは問題ないかもしれんが。
もちろんコンパイルその物の大変深刻ではあるが。
394:デフォルトの名無しさん
08/04/27 21:24:10
C#は恐ろしいほど早いと思ったけどなぁ。
でるひのほうがさらに早いって言われたなぁ。
395:デフォルトの名無しさん
08/04/27 21:25:45
ポーランドの製品はコンパイルが速くて高いオプティマイズが売りだから、そりやそうかと。
それがなかったら買い手がつかない。
396:デフォルトの名無しさん
08/04/27 21:28:22
spiritもだいぶ頑張って使いこなせるようになってきたけど、
結論としては使わないほうがいいな。
397:デフォルトの名無しさん
08/04/27 21:33:08
以前この板でcaperっていうのが出てきて期待してたんだけど、
だいぶ叩かれて作者もちべーしょんうしなったみたいだな。
いくつかバグはあるけど動作に問題はないしもう少し作りこんで
ほしかったけどな。
あれなんでたたかれてたんだろな。
398:デフォルトの名無しさん
08/04/27 21:36:17
コンパイルする言語としてはC++とJavaとC#を使ってるけど、
コード量に対するコンパイル速度に大した差は無い。
そんな差より、俺のＰＣと先輩のＰＣ（自腹で強化）との
コンパイル時間の差が有り過ぎ。
Core 2 Quad + メモリ3G でクソ早い。
俺のＰＣで30秒以上掛かるのがマジ5秒くらいで終る。会社ＰＣのスペックじゃない。
399:デフォルトの名無しさん
08/04/27 21:39:00
>>393
毎回フルビルドしてるの？
もし差分でそれならソースやばいんじゃない？
400:デフォルトの名無しさん
08/04/27 21:39:50
>>399
だからリンクだけって一生懸命かいてる、コンパイル0秒としてだ。
401:デフォルトの名無しさん
08/04/27 21:39:55
>>398
C++とJava・C#だとだいぶ開きがあるような。
spiritなんかF5押すたびにお茶が飲める。
かといってJavaでspiritみたいなことできるかっていうと、もっと
面白みのないものになるだろうけど。
402:デフォルトの名無しさん
08/04/27 21:41:28
>>399
一瞬オープンソースの子供が混じってただけで、>>393は普通の人だよ。
403:デフォルトの名無しさん
08/04/27 21:44:23
流石大人は違うなw
404:デフォルトの名無しさん
08/04/27 21:44:37
お前等どんなにボロイPCつかってんねん
もっといいPC買えよ
405:デフォルトの名無しさん
08/04/27 21:45:48
リンクで５分とか掛かり過ぎじゃね？
.dllとか.so無くて単一の実行バイナリ作ってるとかだったら吹くけど
406:デフォルトの名無しさん
08/04/27 21:46:47
>>398
俺もよそのCore 2 Quadでコンパイルしてみたことがあるが、
まるでC#やJavaのコンパイルみたいにC++も早いんだ。
こういう環境ならSpiritも楽しく使える。
こういう環境ならプリプロセッサも要らないと思える。
ちなみにC#だとまるでインタプリタのように一瞬で実行され始める、
コンソールプログラムだからあまり参考にならないかもしれないけど。
407:デフォルトの名無しさん
08/04/27 21:49:31
>>406
そんなに早いのか。
マシン性能って大事なんだな。
408:デフォルトの名無しさん
08/04/27 21:50:37
> こういう環境ならプリプロセッサも要らないと思える。
これどういう意味なんだろ？？
釣りなんかな。
409:デフォルトの名無しさん
08/04/27 21:50:44
まあCore2Quadなら50倍速ぐらい平気ででるかならw
410:デフォルトの名無しさん
08/04/27 21:51:00
>>404
もともとC++はしょぼいコンピュータでも使えるように
仕様作っていたはずなんだけどな。
今や高性能PCでないと使えないなんて何たる皮肉。
個人で手が出せるだけまだましか。
411:デフォルトの名無しさん
08/04/27 21:51:46
>>408
ごめんプリコンパイルドヘッダの間違いだ。
察してくれよ。
412:デフォルトの名無しさん
08/04/27 21:52:53
> こういう環境ならプリプロセッサも要らないと思える。
> まあCore2Quadなら50倍速ぐらい平気ででるかならw
オープンソース厨が嫌われる理由がなんとなく垣間見えた。
413:デフォルトの名無しさん
08/04/27 21:54:05
C++はDLL化しづらいのがきついところだな。
俺の趣味ライブラリはライン数が約7万の
全てスタティックライブラリで、フルビルドに8分ぐらいか。
CPUはセロリン1.4GHz
414:デフォルトの名無しさん
08/04/27 21:55:00
ばかやろう
開発機は昔から高性能だっちゅうの
415:デフォルトの名無しさん
08/04/27 21:55:30
>>410
原因のうちの一つは、プリプロセッサ
昔はこれにより大幅な高速化と利便性を得ることができたが、影響するものに全部インクルードすると、数が増えると指数関数的に遅くなってしまう。
その２は、objの形式の問題。
オブジェクト指向的なコードに対応する構造ではないから、ひどい有様になっている。
いずれも、昔は軽量であったものの、実は計算オーダーの問題がヤバかったと。
416:デフォルトの名無しさん
08/04/27 21:55:33
まぁ、全員Quad以上にしろってのは、ちょっと酷だけどｗ
開発マシンのスペックを上げるのも必要だろう。
ユーザーからの要求が高度化して、プログラムも複雑化・大量化して
それに応えるために言語も高度化していく。
さらに単価は抑えられてるから、生産性も求められる。
だからマシン強化も必要だろう、と俺は思う。
417:デフォルトの名無しさん
08/04/27 21:57:16
趣味ライブラリで７万ってすごいな。
マングリングってなんで統一しないんだろな。
できないのかな。
418:デフォルトの名無しさん
08/04/27 21:58:16
人のVC++ 2005プロジェクトが
いくつか静的LIBに分けて並列ビルドするようにするのを見て、
頭いいと思った。
サーセン
419:デフォルトの名無しさん
08/04/27 21:58:58
>>418
かえって遅くて笑ったでしょ
420:デフォルトの名無しさん
08/04/27 21:58:59
>>414
俺のPCだって買った当時はそこそこ高性能だった、はず……。
421:デフォルトの名無しさん
08/04/27 22:01:51
今じゃ俺のPen4 2.6Gは雑魚マシン扱いです
422:デフォルトの名無しさん
08/04/27 22:02:31
>>415
プリプロセッサで大幅に高速化ってどうやるの？
423:デフォルトの名無しさん
08/04/27 22:03:10
このスレには、アンチMSが一人、紛れ込んでるようですね
424:デフォルトの名無しさん
08/04/27 22:03:23
これからの言語は計算量のオーダが爆裂しないようになってないと厳しいっすよ
どんどん規模でかくなるし。
425:デフォルトの名無しさん
08/04/27 22:05:49
415がobjの問題を挙げているが、
今から新しいobj形式を作れないのかな？
ついでにexport templateへの対応が容易とかあれこれやっちゃって。
まあ焼け石に水だと思うけど。
426:デフォルトの名無しさん
08/04/27 22:05:57
>>423
確かによく読むとおかしなことをそれらしく書き込んでる子がいるけど、
アンチMSと何の関係があるのかさっぱり。
427:デフォルトの名無しさん
08/04/27 22:06:57
プリプロセッサで大幅に高速化ってなんだろ？
428:デフォルトの名無しさん
08/04/27 22:07:54
>>427
GNUがやってる、全ファイルをあらかじめ一本に結合してからコンパイル。
互換性の問題があって難航している。