【肥大化】C++ を見捨てたヤシ【複雑化】
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2008/01/29(火) 09:52:47C++の構文解析とか、もうワケワカメ。
マイクロソフト拡張大杉。
gcnew とか使うぐらいなら素直に Java でも C# でもつかえ！！！
0232デフォルトの名無しさん
2008/03/12(水) 13:43:100233デフォルトの名無しさん
2008/03/12(水) 15:21:310234デフォルトの名無しさん
2008/03/12(水) 16:10:56だからと言って標準ライブラリに代わりがあるわけではないし、
C++を使わない決定的な理由にならない。
0235デフォルトの名無しさん
2008/03/12(水) 19:43:05C++のエラーは黒魔術
0236デフォルトの名無しさん
2008/03/12(水) 19:58:38C++の場合はポインタが足枷になる
大抵は派生クラスにして終わりなんだが、newできないクラスのラッパを作る時に不便だ
勿論getterも書くが…個人的にはgetterはあまり増やしたくないな
0237デフォルトの名無しさん
2008/03/12(水) 21:48:56しかもあと10年は変わりそうにない言語を
肥大化というのもおかしくないか。
0238デフォルトの名無しさん
2008/03/12(水) 23:12:57まだVC6使ってんのか？
0239デフォルトの名無しさん
2008/03/13(木) 00:44:51まぁ、いろいろな意味と理由で負の遺産となりつつある。
場合によってはCOBOLより凶悪な事態を招きかねない、早いうちに廃棄処分方針をとった方が良いだろうとは思う、さすがに。
固執する人もいるが、そういった人には一度離れて別の言語を見て回ってみろと言いたい、
開発環境・コンパイラといった物から、言語使用その他あらゆる点で時代遅れになっているので……
唯一進んでいるのはboostとその周辺だろうが、これらがメインになるのは恐らく難しいだろう。
0240デフォルトの名無しさん
2008/03/13(木) 01:02:01変数宣言は「型、名前」っていう順番で統一するべきだった。
ポインタを複数宣言する時は
char *a, *b, *c
ではなく
char* a, b, c
のほうが自然だし、そもそも char* を typedef していれば
pchar a, b, c
と書けるという事を考えると。
関数ポインタにしても
void (*hoge)(char*, char*)
ではなく、単に
(void (char*, char*)) *hoge
としてくれた方が素直だったのでは。
0241デフォルトの名無しさん
2008/03/13(木) 01:13:000242デフォルトの名無しさん
2008/03/13(木) 01:15:23Objective-Cという選択肢も一応あるんですがねえ…。
0243デフォルトの名無しさん
2008/03/13(木) 01:16:00>>241
typedef については、これ以上どうしろと・・・
0244デフォルトの名無しさん
2008/03/13(木) 01:22:27typedef void(FUNCP*)(int);
これは最初戸惑った。
typedef void(*)(int) FUNCP;
せめてこうなるべきなんじゃないか？と。
0245デフォルトの名無しさん
2008/03/13(木) 01:25:07それは、宣言の書き方であって typedef 関係ない
0246デフォルトの名無しさん
2008/03/13(木) 01:36:550247デフォルトの名無しさん
2008/03/13(木) 01:42:10それでも問題ないし、そもそも記憶クラスじゃないし。
0248デフォルトの名無しさん
2008/03/13(木) 02:01:56そう、記憶クラスじゃないのに記憶クラス指定子にされているのがなんか気になる。
普段は意識しないし、実用上困ったこともないけどさ。
0249デフォルトの名無しさん
2008/03/13(木) 10:56:42そもそも char* 等は型ではない。
関数プロトタイプに char* と書くようになってから一貫性がなくなってきてるけどね。
>>247
typedef は Storage-Class Specifier ではない。
0250デフォルトの名無しさん
2008/03/13(木) 18:50:53でもそれって配列と文法をあわせてるからでしょ。
むしろ他の言語で配列の初期化周りが統一感ない文法が多くて気持ち悪いが。
0251デフォルトの名無しさん
2008/03/13(木) 22:05:20プリミティブ型からポインタ型や配列型を作れる言語では、
Cの構文以外で一貫性のある型表記を決めるとすると、
関数型言語みたいに「型から型を作る」という意識に立って
typedef &char charptr;
static (const int)*5 intarray;
(int, int) -> void func = { ... };
&((int, int) -> void) funcp;
のように表現せざるを得ない。
で、Cにはタプルもカリー化もないのだから、
わざわざ変数の使い方から乖離した型表記を作る必要はない。
0252デフォルトの名無しさん
2008/03/14(金) 10:03:01関数型の世界しか頭になさそうなアホちんですね
組み込み等では大変役に立ったモンですよ
0253デフォルトの名無しさん
2008/03/14(金) 10:14:55ｋｗｓｋ
>>251
レス番間違えてない？
>>252
よく読んでない悪寒
0254デフォルトの名無しさん
2008/03/14(金) 10:28:570255デフォルトの名無しさん
2008/03/14(金) 12:10:49いや、確かに前と後ろにつける違いがあるけど、どちらも変数につけるじゃん。宣言する時も使用するときも。
ポインタの文法は型にくっつけるべきだというなら、配列の宣言も[]は型にくっつけるべきだぜ。
0256デフォルトの名無しさん
2008/03/14(金) 16:58:18とどのつまり、変数は一つづつ宣言させればいいのさ
それはプログラマがそうすればいいだけの話で、一行に一個づつ変数を宣言しろと。
つか、型宣言はC言語の問題の中では一貫性があり重大な欠陥の少ない部類だろ
なんでこんな所にイチャモンつけてんだか
関数ポインタや、配列返し const volatile register の修飾先が分りにくくて初心者がパニックを起こすのはちと考え物だとは思うが。
0257デフォルトの名無しさん
2008/03/14(金) 18:04:45int *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の宣言を否定しているので、
イチャモン？をつける人が出ても、まぁ致し方ないとは思う。
どうせ標準化委員会のメンバーでもないんだし、
気楽に論争(雑談)して良いと思うよ。
0258デフォルトの名無しさん
2008/03/14(金) 18:44:16型名と変数名を区別するのに苦労させられるのがたまらん。
0259デフォルトの名無しさん
2008/03/14(金) 21:35:000260デフォルトの名無しさん
2008/03/15(土) 04:12:13スキャナで適当に区別してしまえよ、せっかく1 passで解析できるように出来ている構文なんだからさ。
それより、古き良き時代で大変役に立った機能が、今、逆に大きな弊害になっている点に突っ込めよ。
インテリセンス・デザイナ・リファクタリングツール・テストツール
リンクを高速に処理可能な抽象度の高い中間ファイル
モダンな機能が組み込み困難になっている現状こそが問題だろ。
0261デフォルトの名無しさん
2008/03/16(日) 01:54:31ttp://www.kijineko.co.jp/tech/superstitions/only-alnums-and-underscore-are-usable-for-identifier.html
0262デフォルトの名無しさん
2008/03/16(日) 04:22:46ヨーロッパのマが書いたコードを見れば結構出現頻度高いんだよ、それ
日本やアメリカではお目にかからないけど
0263デフォルトの名無しさん
2008/03/16(日) 08:13:45文字列以外でASCIIでない文字を使うプログラマはカス
日本語プログラミング言語は別だけど
0264デフォルトの名無しさん
2008/03/16(日) 15:05:190265デフォルトの名無しさん
2008/03/16(日) 17:22:02日本語ラベルは便利だぞ、C/C++だとラベルはラベル、実行コードは実行コードと分かれているが
リフレクションを持つJavaやC#では、構造体のラベル名を読み取って、そのまま活用できるから、
例えば表のタイトル文字列と、構造体のメンバの名前で表示するとか、XMLの内容をラベル名で出力するとか。
一箇所修正するだけで、全部修正完了するのは便利だ。
0266デフォルトの名無しさん
2008/03/16(日) 20:41:58間違ってるとまでは言わないが
ただ、システムの識別子はリファクタリング以外では変えるべきじゃないし
表示名のような業務要件で変わる外部のものと、内部のものを密結合にされると
逆に面倒なことになることもある
0267デフォルトの名無しさん
2008/03/17(月) 05:18:58それに、他人に説明するときに対応関係を説明する手間も省けるし。
0268デフォルトの名無しさん
2008/04/23(水) 11:39:07粘菌の本質をベースクラスとして定義し
そこから派生クラスで環境依存部分を定義する
後は、派生クラス側で
operator=()をベースクラスのコピーと派生クラスの初期化に定義し直せば、動的に粘菌の性質を変更できるんじゃないのか?
0269デフォルトの名無しさん
2008/04/23(水) 11:48:500270デフォルトの名無しさん
2008/04/24(木) 00:12:270271デフォルトの名無しさん
2008/04/24(木) 00:37:320272デフォルトの名無しさん
2008/04/24(木) 12:26:49いや、そーじゃなくて、プログラミング言語以前に、粘菌とはこれだという定義ができないって話らしいお。
0273デフォルトの名無しさん
2008/04/24(木) 16:04:17定義できないなら、それが粘菌であるかどうかすらわかんないじゃん
例えば、
「晴れたら、小さな芋虫みたいになって、四方八方に散らばり」
「雨が降ったら、ぬちゃぬちゃで繊維質な物体になる」
って性質を持って居るように見えて
本当は、
「晴れたら、小さな芋虫に捕食され、雨が降ったら、その芋虫を養分に育つ」
のが本当の姿である可能性もあるじゃん
その場合、クラスだの、プロトタイプだの関係なく、オブジェクトの設計そのものに失敗しているってことじゃん
0274デフォルトの名無しさん
2008/04/24(木) 16:20:48日本語でおkになってほしい。
0275デフォルトの名無しさん
2008/04/24(木) 16:27:56ま、つまり、そういうことだ。
現実は、オブジェクト設計を失敗してるってこと。
【謎飼育】正体不明の謎生物を7年間に渡って飼育している動物園
ttp://karapaia.livedoor.biz/archives/51124187.html
遺伝子組み換えで、生物どころか単なるパーツが作られちゃうかも。
0276275
2008/04/24(木) 16:29:45クラス派生で生物が進化してきたわけじゃない。
グラデーション、みたいな。
0277275
2008/04/24(木) 16:32:24今、要素を洗い出しても未来には違う要素が出てくる。
スタティックなクラスじゃ足りないってこと。
0278デフォルトの名無しさん
2008/04/24(木) 16:34:28それ最初に本に登場したの1992だよ。
名前は日本語でいいが次のトレンドだよ。
0279デフォルトの名無しさん
2008/04/24(木) 16:40:24＞
＞って性質を持って居るように見えて
＞本当は、
＞
＞のが本当の姿である可能性もあるじゃん
↑
これに具体例を入れるだけで、クラスベース言語の限界と問題点が明確になるテンプレ。
0280デフォルトの名無しさん
2008/04/24(木) 16:53:29> 大きい
> って性質を持って居るように見えて
> 本当は、
> 小さい
> のが本当の姿である可能性もあるじゃん
ねーよｗｗｗ
0281デフォルトの名無しさん
2008/04/24(木) 17:02:34類人猿クラスを作ったらそれとヒトの間はどうするよ、と。
ミッシングリンクみたく、中間は無限にあるという問題になる。
0282デフォルトの名無しさん
2008/04/24(木) 17:12:17それ俺らが生まれる前の時代にさんざん議論されつくした話題じゃん。
結局ある種の制約がないとプログラミングできないんだから、その手の
問題がないほうが問題なんだよ。
制約があるのが正しい状態って結論が出て今があるわけ。
というわけで、いま必要なのは日本語でいいじゃんってことなんだよ。
0283デフォルトの名無しさん
2008/04/24(木) 17:13:39それは、クラスベース言語の問題点じゃなくて、オブジェクト指向の限界だろw
>>280
ねーよｗｗｗ
>>281
それは、オブジェクト指向以前に、デジタル回路ととアナログ回路の違いからやり直した方がいいよ、たぶんw
0284デフォルトの名無しさん
2008/04/24(木) 17:18:13おまい無知なだけじゃん。
スタティックなOOがクラスベースっていうOOのイロハを知らないんだろ。
回線切ってケーブルで（ｒｙ
0285デフォルトの名無しさん
2008/04/24(木) 17:19:54ねーよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
昔あった議論は、OOじゃなくて構造化は是か非か。
その前は、汗じゃなくてCは是か非か。
0286デフォルトの名無しさん
2008/04/24(木) 17:25:41どうよこれ？
いいだろ？
0287デフォルトの名無しさん
2008/04/24(木) 17:26:23ねーよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
プログラミング言語はソフトウェアとともに進化して来てんだよ。
そしてソフトがクラスベース言語で表現できないものも扱い始めたんだよ。
おまいは市んだ法が良い。あどヴぁいすｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
0288デフォルトの名無しさん
2008/04/24(木) 17:31:46会社員クラスから学生クラスには出来ず、また学生クラスから会社員クラスにも出来ないから、クラスベースは静的で役に立たないってかw
0289デフォルトの名無しさん
2008/04/24(木) 17:38:19ヴぁかは読解力が無いようでｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
0290デフォルトの名無しさん
2008/04/24(木) 17:42:13is a関係とhas a関係とかいう奴だな。
そこで、property型を導入するんだよ。
日本語至上主義的には属性ってしたくなるけど、そこは肩書だな。
なんでかっていうと、肩書ってしとけば委譲するとき意味的に
ぴったしっぽいじゃん。
で、よくよく考えると他重軽傷でいいのか？とか思っちゃうんだけど、
そうするとまた最初に戻っちゃうので、肩書を導入すること推奨。
0291デフォルトの名無しさん
2008/04/24(木) 17:47:480292デフォルトの名無しさん
2008/04/24(木) 17:49:34ヒト・サルに文化する前の類人猿に「is-aヒト」、「is-aサル」を問い合わせたら、true？false？
サルが派生してヒトになったわけじゃない。
類人猿が分化して夫々になったわけだし。
0293デフォルトの名無しさん
2008/04/24(木) 17:51:360294デフォルトの名無しさん
2008/04/24(木) 17:52:57いいえになるよ。
だっていいえだろ？
0295デフォルトの名無しさん
2008/04/24(木) 17:53:410296デフォルトの名無しさん
2008/04/24(木) 17:55:35その認識だと類人猿はヒト、サルの共通の祖先なので、
ヒトでもサルでも無い(false)。
ヒト、サルにis-a類人猿したら両方trueだろ。
0297デフォルトの名無しさん
2008/04/24(木) 17:56:47いいえになるよ。
折れるいじねんじゃないしｗ
0298デフォルトの名無しさん
2008/04/24(木) 18:00:15デジタルモンキー乙w
0299デフォルトの名無しさん
2008/04/24(木) 18:02:120300デフォルトの名無しさん
2008/04/24(木) 18:07:110301デフォルトの名無しさん
2008/04/25(金) 00:14:14傍迷惑でビッグなクラスとか、誰にも読めないプロトタイプの山が見えるな
0302デフォルトの名無しさん
2008/04/25(金) 07:29:05クラスっていうのはえさを与えなくても勝手に大きくなっていくものだからな。
テンプレートも一つの解ではあるな。
0303デフォルトの名無しさん
2008/04/25(金) 09:28:47「馬鹿にクラス設計をさせない」
0304デフォルトの名無しさん
2008/04/25(金) 09:43:35↑
これって何？
自演クンって意味？
0305デフォルトの名無しさん
2008/04/25(金) 10:08:000306デフォルトの名無しさん
2008/04/26(土) 10:18:40んもー！ （ ・ω・） . .
○=｛=｝〇, ; .'´ ｀. ﾞ ; ｀
|:::::::::＼,.'.;´," :´,´' . ﾞ .｀ .
.,,.,.,,,.,.,,,.,.,,,.,.,,,.,.,し,,.,.,`（.＠）ｗｗｗｗｗｗｗｗｗｗｗｗｗ
0307デフォルトの名無しさん
2008/04/26(土) 11:43:10テンプレートを使うとクラスの代わりに実行モジュールが肥大化します。
0308デフォルトの名無しさん
2008/04/26(土) 11:53:54テンプレートを使うとコンパイル速度も飛躍的に悪化します。
0309デフォルトの名無しさん
2008/04/26(土) 13:32:46テンプレート使っちゃうと、クラスに対するプロトタイプの利点が無くなるよぉw
0310デフォルトの名無しさん
2008/04/27(日) 00:04:47ついでに生産性も縮小するわけですね、わかります。
0311デフォルトの名無しさん
2008/04/27(日) 00:11:31テンプレートを使うと >>310 の仲間になれるかもよ！
0313デフォルトの名無しさん
2008/04/27(日) 01:21:04クラスが肥大化するのは、設計が悪い場合もあるけど、
提供する機能が多いっていう場合もあるんだよな。
後者の場合、どんなやり方をとったとしても、大きなクラスかたくさんのクラスを作るかせねばならん。
0314デフォルトの名無しさん
2008/04/27(日) 01:52:27むしろ C++ ユーザは肥大化を求めているんじゃないかな。実際どうかは別として、
肥大化すればするほど生産性が上がるという教義だから。
0315デフォルトの名無しさん
2008/04/27(日) 01:55:430316デフォルトの名無しさん
2008/04/27(日) 04:35:53Bjarne氏もD&Eでそう言ってたし。「使わない機能はコストを発生させない」っていう
原則もあることだし。肥大化することで初心者が不幸になることもないと思う。
ただまぁ、何から学べばいいかわかりにくくなるor勉強する（べきだと思われる）ことが
多すぎてしょんぼりくる可能性はあるが。
0317デフォルトの名無しさん
2008/04/27(日) 10:42:23C#がという方がより適切と思うが
LINQとか
0318デフォルトの名無しさん
2008/04/27(日) 12:54:40使わないという当たり前の選択を貫徹するのは不可能に近い。
0319デフォルトの名無しさん
2008/04/27(日) 13:34:57まあな
使わないと選択する為には
少なくともその機能を知っておかなければ
ならない訳で、もうその時点でラーニングコストは
発生している。初めから無理なことを言っている。
0320デフォルトの名無しさん
2008/04/27(日) 13:50:34プロでない人は自分が使いやすい言語を選ぶと良い。
言語の機能の習得ごときでいっぱいいっぱいなら、
組み込み系、DB、マルチメディア処理、ドライバ開発とかの
言語以外ので学習で鼻血出るだろうな。
0321デフォルトの名無しさん
2008/04/27(日) 14:25:09プロならもっと道具を選べよ…
その4つの中で C++ が他の言語より優れているのって
マルチメディア処理だけだな。
0322デフォルトの名無しさん
2008/04/27(日) 14:30:010323デフォルトの名無しさん
2008/04/27(日) 14:40:11その他の言語ってのそれぞれ教えてくれないか？
C言語以外でｗ
0324320
2008/04/27(日) 15:01:09どう読んだのか知らないが、俺の趣旨は
・学習用の言語でないので、言語機能を理解力の低い人に合わせる必要は無い。
・言語の機能の習得と、専門知識の習得では、後者の方が難しい。
ということなんだが。
その４つは例を挙げたに過ぎないし、
それらにC++が適しているとも言っていない。
特にＤＢは俺が最近ＤＢ周りのチューニングとかしてたので、
たまたま脳裏に出てきただけだ。言語はC++じゃない。
道具を選べ、というのは同意する。
他のメンバーやプラットホームの都合があるので、
好きに選べるわけじゃないけどな。
0325デフォルトの名無しさん
2008/04/27(日) 16:07:21C++ 使いには C にコンプレックス持ってる人間が多いな。
道具は使いようだぜ。
組み込み（つっても色々あるが…） -> C
DB（まあ Oracle だと思いねえ） -> Java
マルチメディア（画像処理とか） -> C++
ドライバ（Win は知らんけど…） -> C
>>324
分野別の知識は言語の習得とは直行した課題だと思うよ。
専門知識の習得は、言語が難しかろうが簡単であろうが必要となる事なんだから、
言語の習得は簡単な方が良いとも言えるんじゃないかな。
0326デフォルトの名無しさん
2008/04/27(日) 16:14:10対象.メッセージ(値,値);
構文しか知らんのだろうな、例えば
[対象 メッセージ:値 メッセージ:値];
やら
Send(対象,メッセージ,値,値);
とか、
メッセージ(対象,値,値);
(メッセージ 対象 値 値)
なんかを知ってればもっと増しな議論が
出来るだろうに。
せめてクラスや継承は必要悪でありOOの本質でないと気付いて貰いたいものだ。
0327デフォルトの名無しさん
2008/04/27(日) 16:23:54C++のOOでメッセージを持ち出してくるのもどうかと思う。
http://d.hatena.ne.jp/sumim/20040525/p1
0328デフォルトの名無しさん
2008/04/27(日) 16:43:41確かにそうだがC++で
template<class T>void F(T &対象)
{
対象.メッセージ();
}
//対象1と対象2は同じメッセージを持つ
//意外何ら関連性は無い
型1 対象1;
型2 対象2;
//Fは対象が何であれ構造を気にせず
//処理を行える。
F(対象1);
F(対象2);
という文を見ると、静的ではあるが
メッセージを意識せざる得ない。
アラン・ケイがRubyを誉める理由も
これを動的且つ素直に実装できる事が
一因しているように思う。
0329デフォルトの名無しさん
2008/04/27(日) 16:54:23> C, Java, C++, C
完全に予想通りの回答ありがとうｗ
0330デフォルトの名無しさん
2008/04/27(日) 16:57:27もともとC++はオブジェクト指向できるようにはできていないんだよ、だからSTLなんだ。
しかしオブジェクト指向を考えるならメッセージを考えないというのは論外。
自分は 326 じゃないが
>せめてクラスや継承は必要悪でありOOの本質でないと気付いて貰いたいものだ。
これはオブジェクト指向においては核心部分だぞ。
0331デフォルトの名無しさん
2008/04/27(日) 17:16:33C95とは基本的に互換だから、気にするのはC++の構文が使えない程度
C99との差異は理解の上では大したことないし
精々STLが使えなくて面倒ってとこだろ
■ このスレッドは過去ログ倉庫に格納されています