5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

C++って使わないの??

1 :もも:01/10/28 09:02
教えてください!
来月から、UNIXの仕事をすることになりました。
いままでは、VC++で開発してたのですが、
「Cの復習しといてね〜。C++も使えるけど、
UNIXはたいていCだから」  そんな〜〜!!
やっぱ、Cなんですか?? クラスなんて要らないんですか??

2 :名無しさん@お腹いっぱい。:01/10/28 09:09
くだらない質問はここに書き込め!なんでもアリ3
http://pc.2ch.net/test/read.cgi/unix/1002700894/

単発スレは嫌われます

3 :名無しさん@お腹いっぱい。:01/10/28 09:43
いや、なぜUNIXではC++が普及しないのかってのは、
わりと面白い話題だと思うんだが。。

でも1はそもそもC++もあんまし分かってなさそうなのでsage

4 :名無しさん@お腹いっぱい。:01/10/28 10:02
KDE/Qt

5 ::01/10/28 10:05
すみません。単発スレ以後気をつけます。

私的にはCよりC++のほうが明らかに完成された言語だと思うのですが。
Cはとにかく危険すぎませんか。うかつに使って痛い目見たくないです。
今更一箇所でズラズラと宣言するのも嫌だし。
とにかくC開発者は、すでにある便利な機能を使わず、いつまでたっても古典的なイメージが。
メモリー直接いじれる自分に酔ってる感じ。

6 :知ろうとする素人:01/10/28 10:07
C++を使いこなせればCもオッケーなんと違うんですか?
ライブラリとかの使いこなしの話?

7 :名無しさん@お腹いっぱい。:01/10/28 10:16
そう。やっぱ、一人で開発するわけじゃないから、自分だけC++ってのも。
あと、客側もCでやってくれっていうのがほとんどらしい。

8 :名無しさん@お腹いっぱい。:01/10/28 10:23
> Cはとにかく危険すぎませんか。

んなこたない

9 :名無しさん@Emacs:01/10/28 10:36
Cの方がC++よりも危険だと思っている方が危険

10 :名無しさん@お腹いっぱい。:01/10/28 11:14
1に同情上げ
C++使いにとってCで書かされることほど屈辱はないよな...
感覚的にはいきなり原始時代につれていかれていっしょに狩をするよう
なものだよ

おれも上司に「ここはqsortを使って...」と言われたとき
こいつを殺そうと思ったよ。

まぁ、Cでも無理やりオブジェクト指向で書くことはできるから
頑張ってくれよ。
こういうところにかぎって、結構コンパイラ自体はC++のを
使うことが多いから。ちょこっとSTLとか使ったりして
周りの人を啓蒙するところからはじめよう。

11 :名無しさん@お腹いっぱい。:01/10/28 11:14
高校生なみの論理だね >>1

12 :名無しさん@Emacs:01/10/28 11:43
> やっぱ、Cなんですか?? クラスなんて要らないんですか??

ものによる。なにつくるの?

13 :名無しさん@お腹いっぱい。:01/10/28 11:57
オブジェクト指向といえばC++なのか悲しい。

14 :名無しさん@お腹いっぱい。:01/10/28 12:07
「C++使い」とか自称してる奴でロクなコード書く奴見たことないよ。
qsortを使うだけで殺そうとまで思われるのか、
ドキュソとは仕事したくねえな。

15 :名無しさん@お腹いっぱい。:01/10/28 12:11
何にクラスを使いたいのか分からないけど、
UNIXには普通MFCは無いよ。

C++好きな人って、グローバル変数を囲い込んだだけのクラスを作って
オブジェクト指向とか言いそうなので嫌。

16 :名無しさん@お腹いっぱい。:01/10/28 12:36
>>14
火をつけようと思ってライターを使おうとしたら
上司に「これを使え」と、木の棒と板を渡されたら
殺そうと思いませんか?

17 :/dev/null:01/10/28 12:45
たばこに火を付けようとして火炎放射器をいじっているところに、
マッチを渡されたようなものでは。

18 :名無しさん@お腹いっぱい。:01/10/28 12:47
C++がCより優れてると思ってるやつは危険。

19 :名無しさん@お腹いっぱい。:01/10/28 12:56
>>18
禿同。
向き不向きもあるけど、目的が達成出来るんなら
言語なんて何でもいいじゃん。

20 :名無しさん@お腹いっぱい。:01/10/28 13:13
>>16,17
ワラタ

21 :20:01/10/28 13:16
どの道具を使うべきかわかってないヤツ多いよな。
「フードプロセッサに比べたら包丁なんてクソ」とか主張するヤツとか。
なんでもかんでも刺身包丁で切ろうとするヤツとか。

22 :名無しさん@お腹いっぱい。:01/10/28 13:40
GTK+は変態

23 :0/Unix.c ◆0/Unix.c :01/10/28 13:52
10年ちょい前に stallman がいろいろ語ってる。
でも結局 g++ だもんなあ
C++は不真面目な言語だと言ったのは誰だっけ

24 :名無しさん@お腹いっぱい。:01/10/28 13:58
>>23
これ?
http://hp.vector.co.jp/authors/VA000092/jokes/strup.html

25 :名無しさん@お腹いっぱい。:01/10/28 14:14
>>15
おいおい、既存のクラスライブラリを使うだけなのか。

C++ は切れ味が鋭すぎる上、トラップもいたるところに張ってある言語だから C より安全
とは口が裂けても言えない。しかし OO で分析/設計した場合には、その結果を素直に
コードで記述できるから、

 分析/設計/実装

の距離が縮まるから、開発効率は悪くないよ。

それと C だと

- UML のようなソフトウェアの設計を表現する標準的な記法が確立していない。

- どうしても実装上の細かい点が隠蔽しきれない(しなくてもコードを書けてしまう)から、実
 装をはじめると設計全体に目を配らず、近視眼的に目の前の問題を解決してしまいがち。
 そういうコードが積もり積もると、あとで設計に手を入れるのが非常に困難になる。

- Generic Programming をサポートする手段が提供されていないため、ポリシーをパラメタ
 化することが難しい。最初は dererence 時に NULL チェックしていたのを、あとで実行時
 効率を重視するためにチェックをやめようと思ったとき、一ヶ所だけ書き換えて済ますのは
 難しい。(がんばってマクロ書けば不可能じゃないけど、えらく読みにくいソースになる)

というのは、辛いと思う。

私は数千行程度で済むプログラムなら C でも構わないけど、それを超える規模だったり、
複数人で開発するプログラムの場合には C++ で書かせて欲しいと思うよ。

26 :名無しさん@お腹いっぱい。:01/10/28 14:50
プログラムの勉強しているのですが、なぜC++はUNIXで使われないのですか?
UNIXで使われないのなら、どういうところで使うのですか?
マジレス希望

27 :名無しさん@お腹いっぱい。:01/10/28 14:54
>>26
>>4

28 :名無しさん@お腹いっぱい。:01/10/28 15:13
>>26
商用の開発ならUNIXでもC++使ってるって。
フリーソフトでも結構使われてる、と思う。

でも、C++ってコンパイラ(とそのバージョン)によってライブラリの互換性が無いのと
(昔は)まともなコンパイラが無かったから、あまり使いたがる人がいなかったような気がする。

Windowsの世界ではVisual C++やらMFCやらが標準的に使われてるからね。
もしも、Windowsの世界でもVisual C++が糞高くて、COMが無かったら
C++は普及しなかったんじゃないかなぁ。

UNIXの世界でもそういう独占的なC++コンパイラ&バイナリ互換の仕組みがあれば、
C++ももっと普及したかも。

29 :名無しさん@お腹いっぱい。:01/10/28 15:13
C++は業務で顧客のための専用をソフトを書くようなときに使います。
おもな特徴は
・安いプログラマを大量に使う。
・実際にコーディングする人と考える人が別。
・客はコンピュータをよく分かってなくて無理な注文をする。
・細かいチューニングより早く確実に完成することが重要。

30 :名無しさん@お腹いっぱい。:01/10/28 15:14
>>26は「なぜUNIXでメジャーでないのか」と聞いてるんじゃないの。
それだと>>4は答えになってないだろう。

31 :名無しさん@お腹いっぱい。:01/10/28 15:17
>>29
ネタは sage てな。

32 : :01/10/28 15:19
>>C++は業務で顧客のための専用をソフトを書くようなときに使います。
日本語で説明して?

33 :26:01/10/28 15:30
プログラムを勉強するとしたら、C++が一番だと思っていたのですが、
UNIX用のソフト作るなら、Cだけでもいいのでしょうか?
C++はオブジェクト指向で書けるという、プログラミングの方法自体が
いいという以外に、他に何か利点のものはないのでしょうか?
C++がもてはやされてるのは、他に何か理由があると思うのですが。

34 :名無しさん@お腹いっぱい。:01/10/28 15:35
C++はCを使ってオブジェクト指向がかける言語。
純粋にオブジェクト指向を勉強したいなら適切ではない。

オブジェクト指向以外の利点としては、C++はCのようなプログラムもかける。
あとはSTLが便利と思ってる人もいるかもしれない。
もっとも大きな理由は自分が使いたいライブラリ(GUIなど)が
C++で書いてあるからC++を使うってのじゃないだろうか?

35 :26:01/10/28 15:48
C++は主にGUIのソフトの制作者向けということでいいのでしょうか?

36 :名無しさん@お腹いっぱい。:01/10/28 15:52
29は正しいと思うが。
本格的にオブジェクト指向するんじゃなくて、
ベターCとして使うんでしょ。
正解だよ。
DBCとかとも似てるけど、
すべての型や関数を、その業務用のクラスでラップしておけば、
バカが変なことをやってもすぐ検出できるでしょ。
あと、トレースとかの埋め込みも簡単だし。
少々冗長になっても、クラス側で
エラーチェックを厳重にやって、
最悪の場合でも、常に例外を投げるようにラップすれば、
コアを吐くリスクは減るし。
同じバグでも、一応エラーメッセージをだして終了するか、
コアを吐いて死ぬか、では、「お客様」の評価がぜんぜん違う。

// 文字列の宣言
char str[16];
// 文字列の最後にヌルをいれる
str[16] = 0;

FILE *input_file;
input_file = fopen( pFilename, mode );
( オープン失敗のさいのエラーチェックはどこよ?)
nread = fread( input_file,,,);

なんてスゴいコードをがんがん書くPGを使う側にとっては、
つかえる戦略です。

37 :名無しさん@お腹いっぱい。:01/10/28 15:55
質問ばかりで済みません。
CとC++ではどちらが求人とかの需要高いですか?
UNIXだと主にC、WindowsだとVC++だから、
C++よりやはりCが多いと思うのですが、やはりそうでしょうか?

38 :26:01/10/28 15:56
>>37 = >>26です。

39 :名無しさん@お腹いっぱい。:01/10/28 16:07
>>36
そのレベルの「なんちゃってプログラマ」を前提とした場合には VC++ より VB 使わせておけ、というのが
Win32 界隈では妥当と思われ。

40 :名無しさん@お腹いっぱい。:01/10/28 16:20
C++はクソ。Javaマンセー

41 :名無しさん@お腹いっぱい。:01/10/28 16:21
>>40
>>21

42 :名無しさん@お腹いっぱい。:01/10/28 16:26
>>37
両方とも需要はあるが、分野が微妙に違う。自分が何をやりたいのか、オープンシステム系の
開発なのか組み込みなのか、それを考えるのが先。そうすれば必然的に言語は決まってくる。

この手の話はプログラマー板にいったほうが良いと思うが。

43 :26:01/10/28 16:28
答えてくれた方どこかへ行っちゃったみたいですね。
色々質問に答えてくださった方、どうもありがとうございました。
とても参考になりました。

44 :26:01/10/28 16:30
>>42
あ、まだいらっしゃった。
分かりました。
どうもありがとうございました。

45 :名無しさん@お腹いっぱい。:01/10/28 16:30
何故C vs C++という構図になるの?他にも言語はあるのに。
そもそも「UNIXでC++が普及しなかった」のではなくて「WindowsでC++
がスタンダード」ってだけなので、まるでC++があらゆる環境のスタン
ダードであるかのような1の問題提起はおかしい。

46 :Hirotakaueno.com:01/10/28 16:34
俺はOvjectiveCをMacOSXのために勉強したが、結局採用されないでやんの・・・
Cの派生もいいがとりあえずCでいいならより枯れているものを選ぶのがUNIXのモットーなんじゃないか。
あと、UNIXに簡単にクラス管理できるソフトがない(あっても高い)からC++がはやらないじゃないかなぁ?
プログラミング詳しくないけど多分フリーではないでしょ?

47 :名無しさん@お腹いっぱい。:01/10/28 16:37
C++よりJavaやObjective Caml(普及してないから実際には無理
だが)の方が使いたい。

48 :名無しさん@お腹いっぱい。:01/10/28 16:37
>>45
そりゃ C, C++ の得意とする分野が重複するからと思われ。

49 :名無しさん@お腹いっぱい。:01/10/28 16:37
もし26が学生さんならいろいろな言語を実際に使ってみるのがいいと思う。
求人が多いかといった観点でも、どれかが使えるよりはいろいろな言語を
使えるって方が重宝されそう。

50 :名無しさん@お腹いっぱい。:01/10/28 16:37
UNIX板に全角英数のスレタイトルがあると浮くな

51 :名無しさん@お腹いっぱい。:01/10/28 16:54
>39

・UNIX(というか、WIN以外)には、使える簡易言語体系がない。
・WINでもそうなのだが、簡易言語を使った場合、最後の最後で、
突如の仕様変更を食らい、その簡易言語では普通じゃできないことを
やらないといけない場合に非常に困る。
・第一、C++によるオブジェクト、、、のほうが単価が高い(笑い)

・・・ってなわけで、PG、SEとか、派遣会社の経歴書には
書いてあるくせに、「VB、NTならできます」
(できるって、どんなレベルを「できる」といってるんだゴラァ!!!)
みたいなやつを相手にするときは、C++は便利です。
typedef vector<tanka_t> tanka_arrey;
とかやって、
「とにかくさ、単価を収める配列は、tanka_arrey(要素数)で宣言しようね」
「たりなくなったらさ、resize() ってやればokだからね」
「不安だったらさ、push_back() ってやるの」
とか、おしえれば、まあ、一応は動くコードになります。
もちろん、当のPGはなーんも原理を理解せず、
たた、派遣会社の履歴書に
「C++、STLを駆使し、高度のAP作成経験あり」
と記載されるだけですが。

52 :名無しさん@お腹いっぱい。:01/10/28 17:20
俺の周辺だとUnixではC++よりもJavaかな。まぁSolarisだからだけど。
今でもそうかわからんけど、ちょっと前まではC++コンパイラが別ライ
センスになってて、使うに使えないって状況もあったしねぇ。

53 :名無しさん@お腹いっぱい。:01/10/28 17:42
>>51
>・UNIX(というか、WIN以外)には、使える簡易言語体系がない。
shとかawkとかperlとか(笑)
Solaris8以降はperlもついてくるし。
でも、最近はSolarisとかLinuxつかってても書ける人は減った感じ。

>・・・ってなわけで、PG、SEとか、派遣会社の経歴書には
>書いてあるくせに、「VB、NTならできます」
>(できるって、どんなレベルを「できる」といってるんだゴラァ!!!)
>みたいなやつを相手にするときは、C++は便利です。
でも、それは出来上がるものが怖いような...
そういう人にはJavaの方がいいかもねぇ。

>>52
周辺ではSolaris&LinuxでC++とJavaが2:3くらいです。
Sun謹製のC/C++コンパイラはまだ別売りです。Enterpriseは数十万します。
AIXとかHP-UXの状況は知らないです。

個人的にはSunC++よりもgccの方が好きですが、
昔からSunC++を使ってて問題点とか色々知っているとか、
商用のライブラリ・ミドルウェアではSunC++のものしかついてこない場合が多いので
結局みんなSunC++(しかもRogueWaveで)使ってます。

54 :名無しさん@お腹いっぱい。:01/10/28 18:14
>53

わかってない。
自分の感覚でモノ言ってますよ。

Cはやっぱポインタでセグるからさ・・・
徹夜明けで集中力がキレたときなんかやっちゃうよね。。。
その点、SEDやPERLはラク。JAVAもいいよね。

みたいな感覚を、そこらの派遣PGに当てはめちゃだめだよ。
「あのさぁー、へんなエラーがでるんですけどぉ」
「・・・(まず、日本語を学べよ・・)行末のセミコロン、チェックした?」
「あー、付け忘れてましたぁ!Cって不便ですよね」
みたいなレベルなんだぞ、現実は。
こんなやつに、新しい言語なんて教えられると思うか?
そんなやつを使うには、
参照はあるわ auto_ptr あるわ、のC++は便利なんだよ。

55 :名無しさん@お腹いっぱい。:01/10/28 18:33
>>54
C++ の参照は

void func(A& a);
ClassA *p = 0;
func(*p);

で簡単にごまかせるし、auto_ptr も極めて薄いラッパで、dererence 時に NULL ポインタ参照の
例外も投げないし dangling pointer の検出をしてくれることもない。例としては、ちょっと適当では
ないと思われ。

ポインタがらみで落ちるのを防ぐこと関しては、むしろ Win32 で導入された handle ベースのリソー
ス管理の方が適当じゃない?

#言いたいことは分かるけど。

56 :53:01/10/28 18:47
>>54
>みたいなレベルなんだぞ、現実は。
>こんなやつに、新しい言語なんて教えられると思うか?
んー、確かにやりたくないね。根気と時間がかかりそうだし。

でもC++も無理なような気がする。(Cは論外だろう)
delete忘れそうだし。auto_ptrでは限界があるだろうし。
で、参照のみでガベコレががんばってくれるJavaの方が
まだましかなぁ、と思うのです。
JavaでもC++でもどっちでもいいならだけど。

でもVBとの類似性も考えるとC++になるのかなぁ。
VBよく知らないから何とも言えん。

57 :名無しさん@お腹いっぱい。:01/10/28 19:05
そんなさ、頭いいことカンケーなし。

「いいかな。とにかくさ、納品処理はさ、
auto_ptr<Class_nouhin> p_nouhin(new Class_nouhin);
ってやってさ、・・・
え、この意味?いいよいいよ。おまじないだからさ。
とにかくやればいいんだよ。うまくいくから。
でさ、あとは、
p_nohhin->get(item);
p_nouhin->set(item);
だからね」
みたいな教え方してるんだよ!!!!
そのレベルの奴等に、auto_ptr のワナがどうこう、
なんて関係ないよ。
それはオレの解決する問題。

58 :名無しさん@お腹いっぱい。:01/10/28 19:08
なんか、ダメプログラマに対する愚痴スレっぽくなってきたな。

ダメプログラマに何を使わせるかはともかく、ちゃんと設計から実装までこなせる技術力がある人間が
UNIX でプログラミングする場合 C, C++ どっちを使うのかって話しに戻さん? C, C++ 以外にも言語
はあるが、プログラムの内容によっては他の選択肢はペケだから、とりあえず忘れる。

59 :名無しさん@お腹いっぱい。:01/10/28 19:17
ごめそ。戻そう。

そのスジで議論するなら、

メンバー全員が本当に技術力がある(そんなことあるのか?)
・・・・このばあいは、なんでもいいとおもうよ、マジで。
Cでもいいし、C++をベターCとしてつかってもいいし、
本格的オブジェクト指向してもいいし。
UMLでもデザインパターンでもROSEでも、なんでも使ったら?
どうせならLISPとか使ったら?CPUパワーあまってるし。

上位のメンバーはウデはあるが、下位がダメ(まれにあるパターン)
・・・・この場合は、まえにもかいたけど、
C++をベターCとして使うのが正解。
理由は散々書いたとおり。

上位も下位もダメ(実はほとんどの場合はこれ)
・・・・COBOLかVB。

60 ::01/10/28 19:29
> ごめそ。戻そう。
戻してない (w

61 :名無しさん@お腹いっぱい。:01/10/29 02:11
だれかカーネルをC++で書こうとしたやつはいないのか?

62 :名無しさん@お腹いっぱい。:01/10/29 02:18
>>61
BeOS?

63 :名無しさん@お腹いっぱい。:01/10/29 02:23
>>62
え? そうナノ?

64 :名無しさん@お腹いっぱい。:01/10/29 02:39
CさえマスターしときゃC++もいずれ使えるようになる
あとはアセンブラ覚えれば何とかしのげる

こんなもんだろ

65 :名無しさん@お腹いっぱい。:01/10/29 02:43
>>61
あと、WinNTもそうだね。おかげで開発が大混乱したっていうのは
「戦うプログラマー」に詳しい。

66 :名無しさん@お腹いっぱい。:01/10/29 03:05
たぶんOOPはカーネル作るのに向いてない。
無駄が多すぎる。
そもそもOOPなんて作る側の都合だろ?
動かすほうにはあんまり関係ない。

67 :名無しさん@お腹いっぱい。:01/10/29 03:40
                               ________
                              /
                              | さァ >>1 はスグそこだ!
                             ∠  トバすぜ相棒!
                           / ) \__/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
                    ∧_∧  / /      | お・・・おゥ!
                    (  ´Д`) ./ /     ∠_____
                  /    _二ノ
                 //   ミ クイックイッ / ̄ ̄ ̄ ̄ ̄ ̄
                (_二二づ_∧  。o ・・・コーフンして俺の耳引っ張んじゃねェよ
                 /   (  ´Д`)   \マジうぜェな・・・コイツ
           -=≡ /⌒( ヽ/⌒ヽ/\     ̄ ̄ ̄ ̄ ̄ ̄ ̄
    -=≡ ./⌒ヽ,  /    \ \ \\ ヽ/⌒ヽ,
   -=≡  /   |_/__i.ノ ,へ _  / )/ \\/  .| /ii
   -=≡ ノ⌒二__ノ__ノ  ̄ | / i / .\ヽ  |./ |i               (( ( )))
  -=≡ ()二二)― ||二)    ./ / / / ()二 し二) ―||二)        -=≡(Д`;  ) ウワーンキモイヨー!
  -=≡ し|  | \.||     ( ヽ_(_つ  |   |\ ||          -=≡ / つ_つ
   -=≡  i  .|  ii      ヽ、つ       i   |  ii          -=≡ 人  Y
    -=≡ ゙、_ ノ               ゙、 _ノ           -=≡ し'(_)

68 :名無しさん@お腹いっぱい。:01/10/29 05:13
昔は、linux-kernel で「C++でカーネル書くのはどうよ?」ってポストが
(わりと)定期的にあったと思うけど、最近はどうなのかしら?

69 :名無しさん@お腹いっぱい。:01/10/29 05:21
>>61
UNIXとはちょっと違うけどCygwinのカーネル(Cygwin DLL)はC++で書いてあるよ。
何を指してるかによって振る舞いを変えなきゃいけないファイル記述子周りとか、
tty deviceのterminal line desciplineの共通化とかは、クラス階層を使って
実現してる。

70 : :01/10/29 08:00
solarisのvfsはC++で書きなおしてある。

UNIXでC++が利用されてないわけでもないんだけどな。
単に年寄admin(漏れを含む)が多いので、使えないというのもあるが。

71 :名無しさん@お腹いっぱい。:01/10/29 08:10
icewmもc++で書かれていますね。
使っている人は使っているようです。

72 :名無しさん@お腹いっぱい。:01/10/29 08:24
C++だとアセンブリファイルの構造がコンパイラごとに全然違うというのは
普及の弊害って聞いたけどどうですか?おれC++よく分からないんでなんとも
いえないんだけど。

73 :名無しさん@お腹いっぱい。:01/10/29 08:27
>>68
Linux 板で定期的にあるな。

74 :名無しさん@お腹いっぱい。:01/10/29 12:42
C++は分析、設計には向いてるがコーディングには向いていない気がする。
C++を採用することによる分析、設計面での長所をコーディング面でのデメリットが凌駕している。
業務系アプリ等は分析、設計、コーディングをそれぞれ別の人間がやる事が多いのでC++でもいいが、

75 :名無しさん@お腹いっぱい。:01/10/29 13:32
UNIX での C++ って、まぁ、不幸だな。

- 所詮 better C としてしか使われなかった
- OOP だなんだと騒いでたころに、標準的な便利ライブラリ集が
デファクトでも出てこなかった

ってなとこだろ。
「便利な枠は作った。道具はおまえらが一から作れ」じゃちょっとねぇ。

Win の場合は、MFC があるし、GUI 的なものには OOP のほうが都合いいからのぅ。

76 :名無しさん@お腹いっぱい。:01/10/29 13:52
KDE/Qtのこと、みんな忘れないでネ

77 :名無しさん@Emacs:01/10/29 14:02
つーか、C++がここまで流行ったのはMSのおかげなんじゃないか
とさえ思うんだけど。。

ところでgtk--の話を誰もしないが、KDE/Qtとgtk--では
どっちのほうが使いやすいんですかね?

78 :名無しさん@お腹いっぱい。:01/10/29 14:11
gtk-- って興味あるんだけども
日本語ドキュメントって皆無じゃない?

あったら教えてん。

79 :52:01/10/29 14:56
>>75
確かにデファクトなライブラリが無いというのは痛いね。一度Javaをやって
しまうと特にそう思う。

>「便利な枠は作った。道具はおまえらが一から作れ」じゃちょっとねぇ。

C++じゃないけど、pthreadもそんな感じね。premitiveな所しか無いから
一度Win32のスレッド/同期オブジェクト使っちゃうと面倒くさいのなんの。

80 :名無しさん@お腹いっぱい。:01/10/29 15:03
C言語だってデファクトなライブラリ無いじゃん。

81 :名無しさん@お腹いっぱい。:01/10/29 15:25
>>77
そうだろうね。MS の開発言語としての C++ が普及したのだろう。
他に目を向けてみりゃ ObjectiveC だったりするし。

82 :名無しさん@お腹いっぱい。:01/10/29 16:06
>>80
C の場合は UNIX 自体がデファクトなライブラリじゃないの?

83 :名無しさん@お腹いっぱい。:01/10/29 16:08
>>82
そういう見方もある。
しかしそれはC++にも当てはまる。

84 :名無しさん@お腹いっぱい。:01/10/29 23:22
>>70
それは知らなかった。
確かにVFSがクラス継承使って書けるとハッピーですなぁ。

85 :名無しさん@お腹いっぱい。:01/10/30 04:21
>>66
>>84
つーか、VFS は昔から C でクラス継承やってるだろ。
優秀なプログラマは C でも、アセンブラでさえもオブジェクト指向できるのさ。
C を使ったオブジェクト指向的実装の最高傑作の一つは Xt だよな。
カーネルとオブジェクト指向ってネタだと、FreeBSD の new-bus はかなりオブジェクト指向を意識した作りになってる。あとは、最近の草の根 OS (AtheOS とか)は、わりと C++ で書かれてるね。

86 :名無しさん@お腹いっぱい。:01/10/30 04:54
>>85
オブジェクト指向を意識しているのと実際にオブジェクト指向言語で書いてあるのとでは、
サブクラスを書くときの手間がぜんぜん違うよ。

VFSもXtもCで無理やりクラス継承なんてしてるから、新しいVFSやウィジェットが直感的に
書けないのさ。Cを使ったオブジェクト指向的実装としては、Xtは確かに傑作だけど、
これが最初からC++だったら、新しいウィジェットやウィジェットセットを作るのはもっと
簡単だったはずだよ。

87 :名無しさん@お腹いっぱい。:01/10/30 05:10
Xt が傑作とは思わないなあ。
よくぞCであそこまで頑張った、とは思うけど。粘着って感じ。
あれのやりにくさのせいで X の GUI が進歩しなかったんでは
ないだろうか。

88 :名無しさん@お腹いっぱい。:01/10/30 08:05
Xt な app resouce のいじりかたとかで OO って何なのかを学んだ人って
意外と多いかも。code うんぬんはおいといて。

89 :名無しさん@お腹いっぱい。:01/10/30 08:31
>>85
> 優秀なプログラマは C でも、アセンブラでさえもオブジェクト指向できるのさ。
アセンブラさえあれば原理的には何でもできるわけだが、Ken と Dennis は UNIX kernel を(当時の)
高級言語 C で書いたよね。

90 :名無しさん@お腹いっぱい。 :01/10/30 10:12
>>89
その認識は大事なことだ。

91 :名無しさん@お腹いっぱい。:01/10/30 14:43
>>78
ほれ。
http://www.interq.or.jp/earth/inachi/gtk/gtk--/tutorial/html/tutorial_ja.html

まぁ、もともとGtk+がそーゆー設計だからってのはあるけど、
Gtk--使った方がGtkプログラミングは楽だよ。個人的にはね。

92 :名無しさん@お腹いっぱい。:01/10/30 15:05
優秀なプログラマなら、JavaでOS(使い物になる)書ける?

93 :厨房質問:01/10/30 15:06
>>92
Java で H/W に食いつく部分てどうやって作るの?

94 :消防:01/10/30 15:24
JNI?

95 :名無しさん@お腹いっぱい。:01/10/30 15:25
いらんつっこみ。
>>89
最初期の UNIX は C で書かれたわけじゃないよ。途中、UNIX を
書くために C を作り出したような感じ。

>>92
Java で全部書かれた JavaOS っていう構想が昔あったね。
モノも実際に出ていたかな?

96 :名無しさん@お腹いっぱい。:01/10/30 15:31
さらにいらんつっこみ
>>95
>最初期の UNIX は C で書かれたわけじゃないよ。途中、UNIX を
>書くために C を作り出したような感じ。

B がインタプリタで糞遅かったてのがあって C を作ったようなもので
UNIX を書く為ってのはちと違うな。

ついでに最初に C で書かれた UNIX VERSION4 は糞遅かったってハナシだな(w

97 :名無しさん@お腹いっぱい。:01/10/30 15:52
Unix自体を C++で再実装しなおせば、APIが method呼び出しになって
幸せ。ってことですか?

98 :名無しさん@お腹いっぱい。:01/10/30 16:03
338 名前:心得をよく読みましょう :01/10/14 22:17 ID:5r0xorkP
ひろゆきもそろそろ管理人としての姿勢を見直すべき
珍走団がひろゆきに土下座をさせたのは、荒らしの責任を取らせたのではなく
あくまでも、ひろゆきの電話での態度について落とし前をつけたまで
日本生命やINSIのように、安全を確信できる相手には、イキガッテみて、
珍走団のように理屈の通じない相手には遜って土下座までするようでは
あまりにもカッコワルイ

99 :名無しさん@お腹いっぱい。:01/10/30 16:17
>>97
んなこと無い。しっかりしろ

100 :名無しさん@お腹いっぱい。:01/10/30 16:30
64

101 :名無しさん@お腹いっぱい。:01/10/30 18:48
>>97
そうだぞ、しっかりしろ。
STREAMSじゃなくてC++でクラス使ってモジュール性を確保していれば、
いろんなデバイスドライバがもっと楽に書けたって話だ(嘘)

102 : :01/10/30 23:53
カーネルじゃなくてインタフェースモジュールをクラス化するだけでも
APIがmethod呼び出しになるんじゃないかと・・・

new msgq = MSG( 0x7fff0001 , IPC_CREAT ) ;
if ( ! msgq.getstat )
{
  delete msgq ;
  return( 0 ) ;
}
msgq.send( "omaemo-na-" ) ;
delete msgq ;

103 :名無しさん@Emacs:01/10/30 23:58
>>102
そういうlibcつくれば?

104 :名無しさん@お腹いっぱい。:01/10/31 00:53
煽りではないのですが、素朴な感想として...

Cしか知らない人、C++をベターCだと思っている人には、何を言っても
話が通じないのだと、絶望的な気持ちになります。
洗濯機で育った世代に、「タライ一つでなんでもできるんだぞ。いや、
できなきゃおかしい」って言う感じです。ほんとに鬱。

あと、Javaがいいというのはわかるけど、Cの代替は無理ですよね。

ねえ、若い人。C++使ってみてよ。

105 :名無しさん@お腹いっぱい。:01/10/31 01:12
>>104
禿げ同

106 :名無しさん@お腹いっぱい。:01/10/31 01:18
じゃぁギャラ上げて。

107 :名無しさん@お腹いっぱい。:01/10/31 01:18
うんにゃ。オレはC++はかえって危険だと考える。
複雑だし不透明な部分も多いし、覚えなきゃならないことも多い。
低レベルな処理でC++を使うにはよほど慎重を期さないといけない。
むしろ、時代はC++を跳びこえたほうがいいと思う。
アプリケーションはJava, Python, Lispなどの、
もっと高級な言語で書いたほうがいい。計算機の能力は
上がってきているのだから。C++は一部の人間が使う程度でいい。

ところでUNIXの世界では「Cで書けばエライ」的な信仰が
どこかにあるのかしら。そういうのは今まで聞いたことないけど。

108 :詳しくは知らんけど:01/10/31 01:26
>>107
そんなこたねーだろ。

109 :名無しさん@お腹いっぱい。:01/10/31 01:26
>>107
C++ が複雑なのは確かだが、不透明と言うのはどうかなぁ。むしろ透明度が高くて、実装が
見えすぎるぐらいだと思うが。

110 :104:01/10/31 01:30
>>109
禿げ同です。C++はガラス張り。
見えすぎが嫌ならJavaって選択だと思います。

111 :107:01/10/31 01:36
ああそんじゃ不透明って部分は撤回するよ。でも複雑なことには変わりない。
オレがいいたいのは、C,C++ レベルでの実装は
もう万人がやるべきことじゃないってこと。
だからCだろうがC++だろうが正直どっちでもいい。
それより、UNIXでデファクトになっている高級言語が
今のところPerlぐらいしかないということのほうが
問題だと思う。JavaやPythonはいまひとつって感じだな。

112 :名無しさん@お腹いっぱい。:01/10/31 01:41
>>104
だから環境によるって。
Windows 環境なら VC++ が主流(VB除く)だから自動的に C++ を使うことになるだろうが、
C++ で書かれたライブラリが C で書かれたライブラリより圧倒的に少ない(たぶんPerlより少ない)
UNIX でわざわざ C++ を使う気になれない。g++ の STL サポートが今一なのも含めて。
C、Perl、Java でこと足りる。

113 :名無しさん@お腹いっぱい。:01/10/31 01:42
>>111
UNIX 以外でも C, C++ 以外でデファクトスタンダードになっている汎用高級言語ってあるのか?
まぁ VB や COBOL はある意味スタンダードだが、C/C++ の代用にするのは無理だし。

114 :名無しさん@お腹いっぱい。:01/10/31 01:45
>>112
既存のクラスライブラリを組み合わせてすむ程度のソフトウェアに関しては、正直、どうでもいい。

115 :105:01/10/31 01:48
>>112
>g++ の STL サポートが今一なのも含めて。
いつの話だよ

116 :名無しさん@お腹いっぱい。:01/10/31 01:50
>>114
つーか普通ライブラリの一つや二つ使わないか?
もちろん C++ から C のライブラリ呼べるけどさ。何か居心地悪い。

>既存のクラスライブラリを組み合わせてすむ程度のソフトウェア
の例を挙げてみてくれ。

117 :名無しさん@お腹いっぱい。:01/10/31 01:55
>>116
C ではなく C++ と言ってるのは、オブジェクト指向で分析/設計/実装やろうって話でしょ。
クラスライブラリがあると実装で楽をできるけど、はるかに比重が高い分析/設計の方は
手助けしてくれん。

118 :名無しさん@お腹いっぱい。:01/10/31 01:58
>>113
WindowsならVBとDelphiがあるでしょ。
ドライバやデーモン書くのならともかく、通常の
アプリケーションはこれで十分のはず(VBは汚ないからやだけど)。
UNIXにはそれに相当するものがない。それをC++でやるのは無理があるように思う。
最近Kylixが出てきたが、Linux専用だし、デファクトに
なれるかどうかはあやしい。
個人的にはPythonを使っている。でも、まだまだ普及度が足りない。
UNIXユーザ(C使い)に聞いても時々「パイソン? なにそれ?」って言われる。

119 :名無しさん@お腹いっぱい。:01/10/31 01:59
>>117
OO で分析設計して C で実装じゃだめ?
Gtk+ のごとく。

120 :名無しさん@お腹いっぱい。:01/10/31 02:01
>>118
マジレス

VB も用意されている機能だけでは足りず、少し凝ったことをしようと思うと Win32 API を呼び出す
ことになって、結局 C で組んでるのと変わらん世界に突入する。Del は知らない。

121 :105:01/10/31 02:05
>>119
Cか…。
Gtk+はまだしも、Bonoboは悲惨だと思うのは俺だけじゃないだろう。

122 :名無しさん@お腹いっぱい。:01/10/31 02:08
>>119
C++ が存在しない時代ならともかく、今は勘弁してください。

継承を実装するために関数ポインタの配列を手で操作し、インターフェース多重継承時に
基底クラスへのキャストを行うたびに関数ポインタの配列のオフセットを操作する。やって
られんよ。

123 :名無しさん@お腹いっぱい。:01/10/31 02:10
>>121
mozilla のように分けわかめなのもあるが、それは言語によらないと思ふ。
俺が C まんせーなのは職業プログラマじゃないし、
LOC が 100K 超えるような大き目なプログラムは書いたことないからかな。
C のプログラム + Perl や Ruby のスクリプト (+ シェルスクリプト ) の組み合わせが多い。

124 :105:01/10/31 02:15
いや、XPCOMはそう使いにくくないと思ってるんだけど…。
まぁいいや。

125 :名無しさん@お腹いっぱい。:01/10/31 02:20
ヘッダより先にコードを見るもんで。
コードの海を泳いでいるうちに溺れた。

126 :名無しさん@お腹いっぱい。:01/10/31 02:44
>>124
あー。インターフェイスがしっかりしていれば、
中身はリファクタリングする一方で良いってことか。すまん。

127 : :01/10/31 02:58
MFCにはwin32apiのラッピングクラスがあるからのう・・・
WindowsではC++のみでもいけるかもしれんがのう・・・

システムコールを呼ぶだけだったらCの方がラクだでのう・・・
C++のロードモジュールはcoreの解析がめんどくさいからのう・・・

128 :85:01/10/31 03:12
>>86
ああ、別にいまさら C で同じことやれ、とも、C でやるのがベターだ、とも言うつもりはないよ。
ただ、「クラス継承」自体は C でできるし、VFS とか Xt ではそれをやってるから、「VFS がクラス継承で書けると幸せ」は適切じゃないね、ということ。
もちろん、「言語サポートでクラス継承が簡単に書けると幸せ」という意味なら同意する。
# 実用性や新しさは別として、Xt を C++ で書き直すと面白いかもね。

129 :128:01/10/31 03:35
> # 実用性や新しさは別として、Xt を C++ で書き直すと面白いかもね。
UNIX と C++ というネタでツールキットの話を持ち出してるにもかかわらずすっかり忘れてたけども、Interviews なんてのもあったね。
今となっては歴史的な存在だけど、これの研究成果の一部は今の OOP の世界にも生きてるよね。
# Berlin の絡みで以前ネタにしたのに忘れてたよ :D

130 : :01/10/31 13:48
Cの何が嫌かというと、途中で変数宣言ができないってことね。
スコープのなかで使う変数は全部最初に宣言しなくちゃならなくて
すごーくめんどくさい。
for(int i=0;i<hoge;i++)なんての認められないから、
一時的につかうだけのiなんかも最初にかかなきゃならない。
あと、//のコメント使えないのもめんどうだよー。
それから構造体でも、コンストラクタがあると便利だよ。
クラスを使うのが嫌でも、部分的にC++の機能を使うのはアリだと思うけど。

131 :名無しさん@お腹いっぱい。:01/10/31 13:58
>>130 見た目の良し悪しは別として 途中で変数宣言したい時は {} を使って
 {
  int i;
  for (i = 0; i < hoge; i++)
    :
 }
みたいなことはできるんじゃ? あとgccならCのコードでも // で
コメント書けるね gcc以外のコンパイラ使うと問題が出るだろうけど

132 :名無しさん@お腹いっぱい。:01/10/31 14:02
>>130
それがベターCでしょ。

Cの変数宣言制約はブロック先頭だから、全部最初に宣言しなくちゃ
いかんということはないぞ。
一時期関数内のブロック(複文)をよく使ってたけど、後輩に「おかしいです」
とか言われちゃって、ちと哀しかった。

133 :131:01/10/31 14:03
>>131と被った。

134 :名無しさん@お腹いっぱい。:01/10/31 14:45
最近のCの規格だと//のコメントも途中での変数宣言もあるよね。
inlineとかconstも入ってたと思う。

この新しいCの規格がもっと普及してくれるとうれしい。
ベターCとして使ってる人がいるからC++の印象が悪くなってると思う。

135 :名無しさん@お腹いっぱい。:01/10/31 20:49
Pythonで十分

136 :名無しさん ◆.62G1GvM :01/10/31 23:02
>>135
オレはPerlで十分だと思う。
Perlでバイナリファイルいじくっている毎日だし、
OOなプログラミングもできる。

137 :!135:01/10/31 23:45
Perlはよく使うけど、Pythonの代用にするのはきつい。
ときどき型検査の曖昧性のせいでひどいバグを入れてしまう。
数百行以上のプログラムなら、Pythonかな。あとguileもなかなかよし。

どうでもいいけど、guileってGNUお墨付きの言語なのに
あまり普及してないよなー。

138 :名無しさん@お腹いっぱい。:01/11/01 00:23
言語の良し悪しよりもどれだけライブラリが充実してるかだな。

139 :名無しさん@お腹いっぱい。:01/11/01 00:51
>>135 >>136
いったい何が十分なのだ?
自分にとってなら、好きなの使えば良い。
だがスレ違いの話のような気がするが。

140 :名無しさん@お腹いっぱい。:01/11/01 00:56
>>139
彼らが組むプログラムは 10 分でできる使い捨てプログラム、という意味かと(嘘)

しかし、設計も何も考えずに 10 分でプログラムを書いて、さっさと目の前の仕事を片付けるのが
正解と言うことも多い。そういう用途には Perl は便利だ。

141 :名無しさん@お腹いっぱい。:01/11/01 01:46
このスレはUNIXのアプリケーションを何で組むかって話じゃないの?
どうでもいいがここでいう「UNIXアプリケーション」とは何だろう。
httpdとかじゃあないよね?

142 :名無しさん:01/11/01 09:21
>>140
いえ、違います。わたしなら Kernel を Python を使って 10 分で書けるという意味です。(嘘)
すれ違いなのでsageます。
ついでに厨房呼ばわり覚悟で質問します。
C++ のコンパイラって buggy ですか? まさかそんなことはないですよね。。。

143 :名無しさん@お腹いっぱい。:01/11/01 11:15
プロならば言われたならば、CであろうがアセンブラであろうがPrologだろうが仕事はこなさにゃならん。
クラスとかに代表されるOOPの概念は設計をする時の手段のことであって、
言語とは一線を隔てるものだ。C++でなきゃクラスを意識した設計ができない、
などと主張するなら転職を考えるべきだろう。

なおUNIXはオブジェクトをファイルと捉えてnewの代わりにopen()、
deleteの代わりにclose()していると考えると多少スッキリするだろう。

144 :しつもん:01/11/01 11:57
new、またはmallocしたメモリ領域って、
自分で開放しないとプログラムが終了した後もそのまま残ってしまうんですか?

145 :名無しさん@お腹いっぱい。:01/11/01 12:55
>>144
残りません。

#fjで聞いてみるとよいかと(嘘

146 :名無しさん@お腹いっぱい。:01/11/01 12:57
>>144
ヒープから割り当てたメモリ(new/malloc)はプロセスの所有物なので、
プロセスが消えれば一緒に消える。昔のWin95は残るケースがあったと聞くが…

147 :名無しさん@お腹いっぱい。:01/11/01 14:13
>>143
無茶な仕事は断る。コの業界で長生きしたければ、デスマーチの香りをかぎ分ける嗅覚は
必須です。

全然 C++ と関係ないね。sage

148 :144:01/11/01 15:49
どうもありがとうございました。
ところで、そうするとメモリの解放って明示的に行う必要はないんでしょうか?
いわゆるガベッジコレクション機能はC/C++には無いと聞きますが、
プロセス全体を通して特にメモリを圧迫するようなことをしていないなら
必要ないのでしょうか?

149 :名無しさん@お腹いっぱい。:01/11/01 15:52
>>148
それこそfjで(以下略

150 :名無しさん@お腹いっぱい。:01/11/01 20:39
>>148
限りなくスレ違いだが。プログラマー板で fj.comp.lang.c の議論をネタにしてるスレッドが
あったけど、そこで技術的な話も一通り出てました。探してみてください。

> そうするとメモリの解放って明示的に行う必要はないんでしょうか?
あなたは自動変数やプログラムのコードが利用している領域を、プログラム終了時に明示的に開放して
いますか?

151 :名無しさん@お腹いっぱい。:01/11/01 20:59
>>142
「C++ のコンパイラって buggy ですか?」
ベンダにもよるしバージョンにもよる、ってのは無し?

152 :名無しさん@お腹いっぱい。:01/11/01 21:00
http://groups.google.com/groups?hl=ja&threadm=88mle0%24mnm%241%40ns.src.ricoh.co.jp&rnum=6&prev=/groups%3Fas_q%3Dmalloc%2520free%26as_ugroup%3Dfj.*

>>148
上のURIの不毛な議論をドウゾw
たぶんスレッドの先頭じゃないから、マジメによむなら適当に発言辿ってくれ。

153 :名無しさん@お腹いっぱい。:01/11/01 21:22
>>150
これだな。

 始まった!malloc and free - fj.comp.lang.c
 http://mentai.2ch.net/prog/kako/981/981051921.html

152 が挙げてる NetNews の記事と合わせて読むと、良い暇つぶしになる(w

154 :名無しさん@お腹いっぱい。:01/11/01 22:48
>>143
あんまりけんかとかしたくないんだけど。
>クラスとかに代表されるOOPの概念は設計をする時の手段のことであって、
>言語とは一線を隔てるものだ。C++でなきゃクラスを意識した設計ができない、
>などと主張するなら転職を考えるべきだろう。
なんでこんなこと言えるんだろう。若者をまどわす老人そのものだよ。

Cでクラス(と同等のもの?)なんてできません。おおかた、構造体と関数への
ポインタの組み合わせとか考えているんだと思うけど。
おとーさんは、ほんとーに、鬱です。

155 :名無しさん@お腹いっぱい。:01/11/01 23:07
>>154
> Cでクラス(と同等のもの?)なんてできません。おおかた、構造体と関数への
> ポインタの組み合わせとか考えているんだと思うけど。
やってやれないことはないけど、メンテナンス不可能なコードになるから実質的には無理ですな。

156 :名無しさん@お腹いっぱい。:01/11/01 23:07
C++信者うぜー
一生Windowsと暮らしてろ

157 :名無しさん@お腹いっぱい。:01/11/01 23:08
lispだよ、lisp
C/C++なんて捨て捨て

158 :154:01/11/01 23:44
>>156
いや、だからUNIXのC++の話だんべよ。
(俺は、プログラマ板から来たWin屋だけどね。よくわかたね。)

>>157
Lispいいの?興味はある。(C/C++捨てんけどな。w)

Lisp勧める人って、プログラムは書けなかったり、書くときは
COBOLやFORTRANだったりする。俺の周りでは。

159 :名無しさん@XEmacs:01/11/02 00:00
UNIX だと Perl あたりで十分なコトが多いからなぁ。
C か C++ かと言われれば迷わず C++ だけど。

# とはいってもキチンと C++ 使えてるわけじゃない(^^;
# Perl5 と同じ感覚かしら。(わけわか
## そぉいえば C++ って Perl5 と似てるような気がしないでもないなぁ。

160 :名無しさん@お腹いっぱい。:01/11/02 00:07
一年がかりで開発するなら C++ を使うかもしれないが、
作り捨てのプログラムを書くなら C のほうが早い。
OOP のメリットはドキュメント化された、
まともなクラスライブラリの存在あってこそでしょ。
0 からつくるなら、Cでバシバシ組んだほうが早い。

161 :158:01/11/02 00:14
158では、ちょっとぞんざいな口調になってごめん。

>>159
UNIXもPerlも初心者だけど
>UNIX だと Perl あたりで十分なコトが多いからなぁ。
は、なんかわかる。UNIXって、小さいプログラムが集合的に働くのに、ものすごく
よくできてるって感じがする。
Perlって、ほんの初歩をかじっただけだけど、悪魔のような言語だよね。
(あ、ほめてるんだよ。)テキスト主義のUNIX文化では、ある意味、最強かも
とは思う。(違う?はずしてる?)

でも、大きいのを組むなら、C++いいけどな。

俺がムッとしたのは、CでもC++でも、みんな同じ...みたいな論。

162 :名無しさん@お腹いっぱい。:01/11/02 00:17
>>160
趣旨はわかる。でも「1年がかり」じゃなくて「1月がかり」くらいから、
C++でよいのでは。。。

163 :名無しさん@お腹いっぱい。:01/11/02 00:28
>>162
一ヶ月は微妙な線だけど、
まともなライブラリをドキュメント込みで作ろうとすると、
最低一ヶ月はかかるよ。

機能の種類と、使いまわせる手持ちのライブラリしだいだね。

164 :名無しさん@お腹いっぱい。:01/11/02 00:54
>Cでクラス(と同等のもの?)なんてできません。

あらら。
最近はもうないだろうけど、初期のC++はもともとCのサブセット
でしかなく、冗談抜きでプリプロセッサでC++ -> C その後コン
パイルしてたんだよ。
CとC++が全く別ものだなんて考え方するのは素人さんだけだと思
うよ。>>154がプロなら(以下略

けど>>155は正しい。

165 :名無しさん@お腹いっぱい。:01/11/02 01:01
うちはUNIXで特殊分野向け計算エンジンの開発やってるけど
C++使ってるよ
GUI一切無いコマンドラインプログラムだけどC++で作ってる

やっぱりちょっと大きくなるとC++の方が楽だと思う

166 :名無しさん@お腹いっぱい。:01/11/02 01:20
>>165

そりゃそうだ。
C++は作る奴が楽するために生まれたのだ。

167 :名無しさん@お腹いっぱい。:01/11/02 01:23
あ、そ。ただのPGのくせにうだうだぬかすな。

168 :名無しさん@お腹いっぱい。:01/11/02 01:25
PG?
プレイガ〜ル(ダミ声)?

169 :名無しさん@お腹いっぱい。:01/11/02 01:26
>>164
私も>>155に同意。UNIXじゃないけどActiveXのコードをCで書いた例をみて驚いた。

C++ → Cのトランスレータの仕組みは今でもかなり「生き」だから、
効率の良いC++を書きたければ知っておいて損はないよね。
絶版になっちゃってるけどトッパンから出てた良い本を読んでC++も好きになれたよ。

170 :名無しさん@お腹いっぱい。:01/11/02 01:38
ところで、
VC++ 5.0だかの巨大な(奥行き50cmぐらいある)パッケージを見て、
「だれか止める奴はいなかったのか」
と思ったのは私だけ?

171 :名無しさん@お腹いっぱい。:01/11/02 01:39
>>167
素人はだまっとけ(W

172 :名無しさん@お腹いっぱい。:01/11/02 02:01
>>160
> 0 からつくるなら、Cでバシバシ組んだほうが早い。
私は STL が使える時点で C++ ですね。設計を OO でやるかどうかは別として。

173 :名無しさん@お腹いっぱい。:01/11/02 02:18
>>172 同意。というか、OO抜きでSTLだけならだれでも7日も
あれば覚えられるだろうに勿体ない。といつも思う。

174 :名無しさん@お腹いっぱい。:01/11/02 03:05
通しで読んでいると、>>24(Stroustrupの冗談)の話題が出ていたの
で...

皆さん、アジソンの「プログラミング言語 C++ 第3版」(日本語版)、
どう思われていますか?

どこ見ても「C++を本気で学ぶものは必ず読むもの」って書かれてい
ますが、個人的には誤植の多さに閉口しています(日本語の正誤表も
出されていますが、これぢゃあ足りません)。

本当に内容を読んで書評を書いているのかすごく疑問を感じてしまい
ます(少なくとも、内容確認のために少しでも掲載されているソース
を打ち込めば(実践すれば)、問題だらけなのがわかるはずなのに)。
個人的には「そんな人たちに薦められても...」と思ったりしてい
て...まぁ、ソースの中身でなく思想を読む(読み取る)本であるこ
とはわかりますが...

/*
ちなみに誤植は図とリストに多いので、おそらく日本語版の編集作業
でしくじっているものと思われます。原著は読んでいないので想像で
しかありませんが。
*/

「誤植が多いので薦められない」とamazon.co.jpの書評を書いたら、
本自体が検索しても引っかからなくなりました。どうして?(この意見
は抹殺されるの?)

>>170
VC++ 1.0のPro版だったはず。秋葉原から担いで帰った記憶があります。

175 :名無しさん@Emacs:01/11/02 03:20
うーーん。
「スピードが重要」かつ「巨大」なものなら
C++ がいいというのには同意。STL もいいし。

ただ、そういう仕事はそんなに沢山あるわけではないと思うんだがなあ。
数値計算とかなら仕方ないが。なぜ STL と C++ にこだわるのかがわからん。

176 :名無しさん@お腹いっぱい。:01/11/02 03:21
ナイススレ

177 :名無しさん@XEmacs:01/11/02 05:47
>160
うーん、おいらが厨房だから C で書いた方が早いってのが
わからないなぁ。 C++ の方が C よりもコンピュータに任せられる
部分が多目で、楽に早く書けると思うんだけど…

# って、このあたりは何を組むかにもよるし、その人の資産にも
# よるから、なんともいえないかぁ。


>161
UNIX は気のきいた小物が簡単に手に入るけど、それが使えなきゃ
キツい世界だね。
あと Perl はテキストを扱うことに慣れるにはイイ環境だと思う。
でも、それが UNIX 的かどうかは、、、

# Perl は Win32 でも便利そう…詳しくないけど。。。

178 :名無しさん@お腹いっぱい。:01/11/02 07:54
>>175
>「スピードが重要」かつ「巨大」なものならC++ がいい

可哀相に(w

179 :名無しさん@お腹いっぱい。:01/11/02 08:36
>>164
C++で書いたものをCにコンバートする意味って何?
C++が読み書きできるんなら、それでいいじゃん?
コンバータの存在は、単に、C++の読めないプログラマの
不安解消だけなんじゃないの?

誤解があるようだから言っておくと、「C++ができる人は偉い」
って言ってんじゃなくて、「C++を使えば楽な場面がかなりある」と
思うわけ。ガイシュツだけどSTLくらいからはいれば、簡単だよ。
でも、ちょっとしたテキスト処理ならPerlに脱帽だ。是と非をわけよう。

180 :名無しさん@お腹いっぱい。:01/11/02 08:38
コンバータの吐いたCコード見たことあるけど、
ライブラリ任せにするだけで、少しも「いいプログラム」じゃなかったよ。

181 :名無しさん@XEmacs:01/11/02 09:20
>>129
> Interviews なんてのもあったね。
> 今となっては歴史的な存在だけど、これの研究成果の一部は今の OOP の世界にも生きてるよね。

Interviews 1/2の成果は、なかなか民間製品に活かされなかったねー。

182 :名無しさん@お腹いっぱい。:01/11/02 09:23
トランスレータってプリプロセッサみたいに考えちゃだめだよ。
C++ -> Cのコンパイラと考えた方がいい。
Cコンパイラがアセンブリを吐くからといって、アセンブリでプログラム
書くわけじゃないでしょ。

183 :  :01/11/02 11:50
メンバ変数を全部インラインで書くと
ほとんどJAVAと同じ感じ・・・

184 :名無しさん@お腹いっぱい。:01/11/02 12:31
>>183
でも、そうやるとヘッダーに書くことになっちゃうんだよね。
リンカがへぼいとマズーだし。

185 :名無しさん@お腹いっぱい。:01/11/02 13:46
>>184
テンプレートとか使うと・・・。

186 :名無しさん@XEmacs:01/11/03 00:19
>>179
> C++で書いたものをCにコンバートする意味って何?

Native compiler作るのは大変だから、(platformがWintelだけならいざしらず)
Cをtargetにした。それだけの話だよ。CFrontが主流の頃の話。
同じアプローチを取った処理系は、初期のObjective-C、
KCL(Kyoto Common Lisp; 現GNU Common Lisp)なんかがあるよ。

Code generationやoptimizationはC compierに任せばいいから楽だよね。
ただ、今のC++の仕様だと、分割compileと両立しないんだけどさ。
くわしくは、"Design and …"でも読んでくれ。

187 :名無しさん@お腹いっぱい。:01/11/03 00:32
つーか一段階一段階極めていきたい俺はCに固執しちゃイカンとですか?

188 :名無しさん@Emacs:01/11/03 00:36
学習コストはどうよ。
C をしらずにいきなり C++ を使いこなせる?
個人的には無理だと思ってるんだが。

189 :名無しさん@お腹いっぱい。:01/11/03 00:42
いや、むしろまっさらから教えるならC++のほうが楽だと思うが。

190 :名無しさん@お腹いっぱい。:01/11/03 00:42
>>188
「使う」のは可能だが「使いこなす」のは無理。

std::string をブラックボックスとして使うのは簡単だけど、自分で同等のテンプレートを設計/実装
できるようになるには、ちょっと時間が必要。C プログラムさえ不自由と言うレベルだと、話にならな
い。

191 :ななしさん@おなかいっぱい:01/11/03 00:50
>>190
そう? Cを知らずにC++から入っていっても、使いこなせるようにはなる
と思うけど? 確かに、そこまで到達するにはそれなりの時間が必要。け
ど、C++を勉強するためにまずCの勉強から入る場合と比べてどうかって
ことであれば、不利になるとも思えないな。

192 :名無しさん@お腹いっぱい。:01/11/03 00:58
でも、最初からC++に入った人を見たことない。実はけっこういるのかな?
JAVAから入ったってんなら、それなりにいそうだね。

193 :名無しさん@お腹いっぱい。:01/11/03 01:07
まず軽くCを通してC++(クラス〜)に入ればいいのでは、と思うが・・
基本的設計はC++固有の知識だが、実装は実質Cなのだから・・・

194 :名無しさん@お腹いっぱい。:01/11/03 01:10
C++にいまからはいるやつ。

ズバリ糞だね、いろんな意味で。

195 :名無しさん@お腹いっぱい。:01/11/03 01:13
>>194
ネタは sage でな。

196 :名無しさん@お腹いっぱい。:01/11/03 01:16
>>192
>最初からC++に入った人を見たことない。

はい。
「ドキュ習C++」見て覚えました。それが初めてのプログラミング言語っす。
それから会社入ってC++とJavaで業務に携わってます。
多いかどうかは知らないけど、周りは似たり寄ったりです。

197 :がってんタスケ:01/11/03 01:27
>>196
肥溜めにウンコ状態だね(w

198 :名無しさん@お腹いっぱい。:01/11/03 01:34
ドキュメント無しで、ソースを引き継がなきゃなんないとしたら、
C++ のほうが嫌だが。

199 :がってんタスク:01/11/03 01:47
>>多いかどうかは知らないけど、周りは似たり寄ったりです。

スゲー会社だな。
若い奴ばっか??

200 :名無しさん@お腹いっぱい。:01/11/03 01:51
>C++を勉強するためにまずCの勉強から入る場合と比べてどうかって
>ことであれば、不利になるとも思えないな。

結果両方できるなら問題ないさ。
けどC++から始めた奴のCのソースは、はっきり言って醜い。

201 :名無しさん@お腹いっぱい。:01/11/03 07:39
講談社ブルーバックス「これならわかるC++」って本、いいと思いますよ。
ほぼ初心者から読めて、すぐに「C++らしいプログラム」が書けます。
もちろん、極めるところまでは行ってませんが、「C++から始める」は可能で
はないかと。

202 :Vormerkbuch:01/11/03 11:51
実は、Cで、スパゲテイソースを書いて、
管理不能になったことがあります。

自分で書いた、関数が、500を超えまして、
管理できなくなったわけです。

Linkerもフェ

お話によると、関数の管理が、特に容易になるとか、
言うことですけど、やはりそうなのでしょうかー。

それと、開発を止めた原因の中で最も多いのは、
デバッグする際に、CPU のレジスターが、ブレークポイント
指定できない為、バグが取れずに困ったことがあります。

昔のことですから、リモートモードでデバッグを、するし
かないという、デバガーソフト屋さんの助言で、
2台のコンピューターを使ってをリモートモードでデバッグを、
やりながら、CPU レジスターの間違いが無いかを、デバッグしました。

32バイト、64バイトモードのデバッガーは、最強なんでしょう
けど、ICEを使わないと、デバッグできないとか言うことは無いので
しょうかー。

それと、変な質問ですけど、アメリカの戦略ミサイルとかのOS
は、やはり、UNIX の C++で書かれているんでしょうかー。

203 :名無しさん@お腹いっぱい。:01/11/03 14:43
C++?
あんな煩雑な言語使えるか。
Keep it simple, stupid!!

204 :名無しさん@お腹いっぱい。:01/11/03 15:37
>>203
単純なコードを記述できるようにするため、言語やライブラリを拡充させるという方向は KISS と
矛盾しないと思うが、どうか?

単純な言語が良いならアセンブラ使えば良いわけだし。

205 :名無しさん@お腹いっぱい。:01/11/03 15:37
//難しいか? >>203
#include <iostream>
using namespace std;

int main()
{
cout << "Hello, world!" << endl;
}

206 :名無しさん@お腹いっぱい。:01/11/03 16:00
>>205
複雑怪奇。

オブジェクトのインスタンスと古典的な関数呼び出しがごっちゃ。
namespaceまで入ってきて何がなんだか。

207 :名無しさん@お腹いっぱい。:01/11/03 16:04
>>206
じゃあ

int main()
{
  printf("Hello, world!\n");
  return (0);
}

が簡単化というと、そんなことは全然ないと思うが。標準出力という概念自体が高度に抽象的
だし、実際にコンソールなりファイルなりに出力されるまでの過程を kernel にまで踏み込んで
追っていくと、うんざりするほど長いぞ。(それに比べれば C++ の std::cout のレイヤなんか薄
い薄い)

208 :名無しさん@お腹いっぱい。:01/11/03 16:06
>>205
その << を実現するための仕組みを利用しようとすると
ad-hoc さ加減にうんざりしてくる。

209 :名無しさん@お腹いっぱい。:01/11/03 16:13
>>208
話が逸れますが、もし、

(1) C のプリミティブ型のことは忘れていい
(2) C++ との互換性も忘れていい

という条件で operator を overload できる C の拡張規格を出してくれと言われたら、どんな仕様に
します?

210 :名無しさん@お腹いっぱい。:01/11/03 16:19
C++のキャッチコピーを考えた。
「地雷を踏んだらサヨウナラ」
パクリでスマソ。

とにかく言語仕様が複雑で、
うっかり間違えると、とんでもないことになりそう。
大は小を兼ねるということで、
必要最小限の機能に絞って使えばいいのかも知れないが。

全てを知り尽くした地雷原で、爆死する阿呆どもを尻目に
ひとり、スイスイと渡って行く快感はあるかも。

Cより安全というのは嘘でしょう。
Cもポインタ絡みで危険は多いが、
C++よりは圧倒的に言語仕様がシンプルなので、
(というかC++は、どの言語と較べても複雑すぎる)
その分間違いを犯す率も小さいと思われ。

211 :名無しさん@お腹いっぱい。:01/11/03 16:23
>>210
「なりそう」、とか「思う」と書いてると言うことは、実際に自分で使った上で判断したわけではなく、
単なる思い込みということでよろしいか?

212 :名無しさん@お腹いっぱい。:01/11/03 16:30
>>211
思い込みでよいです。
但し、自分で使ってみて、自分は大丈夫だが、
他の人には無理だろうという、極めて傲慢な。

213 :名無しさん@お腹いっぱい。:01/11/03 16:34
>>212
日本語を話せよ、あんたは

214 :名無しさん@お腹いっぱい。:01/11/03 16:35
>>213
使ってますが何か?

215 :名無しさん@お腹いっぱい。:01/11/03 17:11
>>214
213 はかなーりマイナーだが、元ネタつきのネタ発言と思われ。

結局 >>210 >>212

- 俺はできるプログラマだから良いが、他のヤツが C++ 使うのはやめとけ。
- ただし、根拠はない。

と主張してるの?

216 :  :01/11/03 17:12
>>207
なんで、りたーんに、かっこを、つけるの?

それから、0しか返さないなら、mainもvoidでいいと思う。

217 :名無しさん@お腹いっぱい。:01/11/03 17:29
>>216
> それから、0しか返さないなら、mainもvoidでいいと思う。
ANSI C++ を考えているのなら、ダメ。

> 3.6.1 Main function
> 2 An implementation shall not predefine the main function. This function shall not be overloaded. It shall
> have a return type of type int, but otherwise its type is implementationdefined. (以下略)

218 :ななしさん@おなかいっぱい:01/11/03 17:33
>>216
mainの返り血はintって、規格で決まってるんじゃなかったっけ? つか、
それってCでも同じ。void mainって書くと警告出されるけど?

219 :名無しさん@お腹いっぱい。:01/11/03 17:42
>>217
ANSI C でも

int main(void)
int main(int argc, char *argv[])

しかダメな。C99 の規格書が手元にあるなら 5.1.2.2.1 Program startup の 1 に書いてある。

もちろん処理系によっては

void main(int argc, char *argv[])
int main(int argc, char *argv[], char *env[])

などが使える場合もあるけどね。

220 :名無しさん@お腹いっぱい。:01/11/03 17:52
>>210
>Cより安全というのは嘘でしょう。
>Cもポインタ絡みで危険は多いが、
>C++よりは圧倒的に言語仕様がシンプルなので、
>(というかC++は、どの言語と較べても複雑すぎる)

だから、better C としてC++を一度つかってごらん。
std::string を使ってみるだけでもいい。
それだけなら複雑さはさほど増さないだろう。
>Cもポインタ絡みで危険は多いが、
その上で、std::stringを使うだけでもソースコード上のポイ
ンタ(演算)の数はぐっと減るでしょう。

#C++でコード書いていてポインタ演算をする必要が頻繁にあったら
#設計ミスを疑う。

221 :名無しさん@お腹いっぱい。:01/11/03 18:03
自分でしかコード書かないのだったら better C として使っても
いいけど, そうでないんだったらやっぱり統一するのに難儀するんじゃない?

222 :名無しさん@お腹いっぱい。:01/11/03 18:17
ってゆーかさ。
C++をどうのこうの批判するCプログラマってさ、結局、C++できないのが劣等感なんだろ。
それで、知たっかぶりして、批判するだけ。
で、とばっちりを受けるのは若くて柔軟なプログラマ。
立場的にはコボラーと同じなのに、妙に強気なので、実に有害。
ただ、「私はC++のことは知りません。そういう仕事はできません」とだけ言っとけって。
逆に、「Cを使うな」というC++プログラマはあんまりいないだろ。
C++使いがムカツクのは、C使いじゃなくて、C使いのくせに知ったかでC++を批判するやつだ。

223 :名無しさん@お腹いっぱい。:01/11/03 18:18
>>222
正直、憶えることが多くて面倒くさい>C++

224 :名無しさん@お腹いっぱい。:01/11/03 18:20
それならJava勉強するわってなる。

225 :222:01/11/03 18:21
Javaが悪いなんて一言もいっとらんぞ。
Javaで済むなら、それもよいだろうさ。

226 :名無しさん@お腹いっぱい。:01/11/03 18:25
>>224
べつに C++ ではなく Java という選択肢をとるのは構わなんよ。現実に Java の方が向いてる
領域もあるしね。ただし、

- C++ をきちんと理解していないのに、あらぬ言いがかりをつける。
- C/C++ でないと困る仕事もあるのに、それを無視して全部 Java でやれと言い出す。

のは禁止。

227 :名無しさん@お腹いっぱい。:01/11/03 18:28
>>226
激しく同意。いいこと言った。

228 :名無しさん@お腹いっぱい。:01/11/03 18:30
面白いことは面白いんだけどC++。
言語自体がパズルめいて楽しいというか。
STLなんか特に。

車で言えばJava=AT車
C++=MT車みたいな。

車好きにはATが物足りないように、
プログラミング好きにはJavaは物足りない。

229 :名無しさん@Emacs:01/11/03 18:47
>>228
なんかそれ分かるよね.Effective C++ とか More... とか読んで
「うげー,複雑やのう・・・」
って思ったけど,逆になんか面白さが増したっつーか,好きになれた感じ.

まぁ生活かかっていない人間だからかもしれんけど.

230 :名無しさん@お腹いっぱい。:01/11/03 18:53
Javaでのパフォーマンスチューニングは難しい。

231 :名無しさん@お腹いっぱい。:01/11/03 20:43
>>228
基本的には同意なんだけど。
> プログラミング好きにはJavaは物足りない。
ってのにはちょっと異論あり。

JavaだとGCや豊富なライブラリのおかげで、
フレームワーク作りとかの部分に専念できるのが嬉しいね。
Webアプリとかを作っていくなかで、使えるフレームワークが
出来上がっていくのはすごく楽しい。

楽をするためなら、どんな努力も惜しまないって人にはおすすめ。

232 :名無しさん@お腹いっぱい。:01/11/03 21:08
>>231
比較するなら、素の C++ ではなく

 C++ と 適当なクラスライブラリ
 Java

の方が、現状に合ってると思われ。

233 :名無しさん@お腹いっぱい。:01/11/03 21:23
Javaは潔さの勝利だと思う。AppletやNCでダメになりかけて、
死の淵をさまよったあと、Serverサイドで見事に復活した。
なかなかドラマチックだ。

234 :名無しさん@お腹いっぱい。:01/11/03 21:28
C、C++共に使い、過去にはC++に傾倒していた時期もあるけど、基本的にはC好き。
JavaもPerlももちろんやるけど、どの言語を選択するかはミッション次第かな。

非限定のUNIXで仕事する、ということになればCかPerlを選択すると思う。
better Cとしてだけ使うならC++である恩恵は大きくないし
# 開発段階では実際CにC++の文法を混ぜることも出来るわけだから。
やはりUNIXにC++の様々なクラスライブラリがないことが大きいかな。
その点でPerlはCPANがあってありがたい。

235 :名無しさん@お腹いっぱい。:01/11/03 21:50
C、C++、Javaともに使い、過去にJavaに傾倒した時期もあるけど、基本的にはC++が好き。
どの言語を選択するかはミッション次第かな。

非限定の仕事をするなら、C++を選択すると思う。
最近はライブラリが充実してきたからな。

236 :名無しさん@お腹いっぱい。:01/11/03 22:03
C++をbetter Cとして使うのならいいけど、
オブジェクト指向だからCより優れてるとか言うのは違うと思う。

あとC++の例外って使いにくい。

237 :名無しさん@お腹いっぱい。:01/11/03 22:04
>>236
> あとC++の例外って使いにくい。
C で setjmp() を使うよりは 256 倍 楽と思われ。

238 :名無しさん@お腹いっぱい。:01/11/03 22:41
>>236
ベターCならCを使えよ。
Javaの例外なら使いやすいのか?違うだろ。「例外」そのものを扱えないだけだろ。
(C++はJavaと違って、例外を扱えないやつでも大丈夫になってるけどな。親切だろ。)

なあ、オブジェクト指向が嫌いなの?C++が嫌いなの?
アメちゃんの文献読んでみなよ。オブジェクト指向なんて、もう当たり前なんだよ。

239 : :01/11/03 23:07
スタックがぶっとんだときの解析性が悪いからヤダ < C++
後輩くんの組んだプログラムがC++で、
原因不明にcoreを吐くようなときほどイヤなものはない。
シリぬぐいは先輩の仕事つーのもラクじゃねーな。

240 :名無しさん@お腹いっぱい。:01/11/03 23:08
漏れもC++からプログラムに入りました
C++を勉強しだすと自動的にCも勉強しなければならなくなりますが
C++はCに比べて確かに複雑で覚える事が多いんだなあと思いました

でも実際のコーディング時に「同時に」考えなくてはいけない事は
それほど多くないと思いますしCに比べてプログラムの全体像が
考えやすいと思います
でもその代わり隅のほうで苦労するような気がします

漏れは言語フェチではないので道具である言語は何でも良いし
Javaも良いとは思いますがネイティブコンパイラがあまりに少ない
のが原因ではないでしょうか
誕生の思想からそういうものではない事は分かりますが

241 :名無しさん@お腹いっぱい。:01/11/04 01:49
C++ はデストラクタがしっかりあるのが Good。
ガーベッジコレクション系の言語だと、えてして、
メモリ以外のリソースの解放を明示的にやらなくては
いけないので(よく close メソッドとかあるよね)、結構
解放忘れがあったりする。
(Ruby はその辺、イタレータで克服してるのが大したもんだ)

ま、それはともかく、STL抜きで、C++ を語るのは、ちょっと
不公平。スタックぶっとんだとか、バッファオーバーランとか
結局、vector とか、string とかクラスライブラリを使えば
回避できる話で、そういった道具を使わずに、C言語から
引き継いだ欠点もひっくるめて、C++ を貶めるのは
どうかと。

しかし思うに、シンプル指向の C 言語派と、高級指向の
Java 派の両方から、挟み撃ちで攻撃されてないかい、C++。

242 :名無しさん@お腹いっぱい。:01/11/04 02:15
>>241
そういえば C だとスタック壊したことは何度かあるけど、C++ だとないなぁ。

あとスタック飛ぶよりも、複雑なデータ構造でデータが腐るほうが遥かに辛い。死亡時のデータを
ダンプしても、手で解析するのはまず不可能だし。あらゆる個所に assert() 突っ込んで、細かい
単位で UnitTest、問題が発生する前につぶすようにしないとデバッグ地獄で泣く。

これは C, C++ どっちでも言える事。Java だと理論的に dangling pointer が発生し得ないので、
その点だけは少し楽。

243 :提案:C++の勉強方:01/11/04 03:15
「C言語→ベターC→STL→OOとC++」
はどうか?
”可能かつ効率的かつ実践的かつ興味を持続しやすい”と思うのだが・・・
要は構造化の流れの最後にSTLをもてきただけなのだが。

244 :名無しさん@お腹いっぱい。:01/11/04 03:18
>>243
もはや UNIX と関係ないし。sage よう。

245 :名無しさん@お腹いっぱい。:01/11/04 05:25
>>216
>それから、0しか返さないなら、mainもvoidでいいと思う。
これって、ステータス値ちゃんと 0 になるの?
UNIX のバッチ系のツール作る場合だったら、俺なら絶対やらないけど。

246 :名無しさん@お腹いっぱい。:01/11/04 05:58
>>245
> これって、ステータス値ちゃんと 0 になるの?
ならない。たとえばia32だと%eaxが返り値になるが、voidの時にわざわざ
xorl %eax,%eaxしたりしない。

247 :245:01/11/04 06:20
>>246
>ならない。たとえばia32だと%eaxが返り値になるが、voidの時にわざわざ
ありがとう。やっぱりそうなんだね。

なら、
絶対にエラー終了しないプログラムか、
作り捨てのプログラムで無い限り、
void main() なんてコーディングは俺には考えられん。
まあ、OS によっては問題にならないのだろうが、
少なくとも UNIX ではね。

248 :名無しさん@お腹いっぱい。:01/11/04 06:44
いつのまにやら本題とずれまくってるんだが…
UNIXでC++があまり使われない理由は
・UNIX(Xでもいいや)のアプリケーションを作るための
 標準的なクラスライブラリがなかったから
・Cを愛しすぎてC++をよく知らずに毛嫌いする輩が多いから
てなとこでOKか?

249 :名無しさん@お腹いっぱい。:01/11/04 06:48
>>248
そのへんが標準的な見方だろうね。コンパイラ (g++の2.7台くらいまで)
がヘボヘボだったってのもいれていいかもね。

250 :名無しさん@お腹いっぱい。:01/11/04 08:04
>>248 >>249
冷静な意見だな。サンクス。

251 :名無しさん@お腹いっぱい。:01/11/04 08:57
groffってC++じゃなかったっけ?

システムコールがクラスライブラリとして整備されればUNIXでもC++を使う土壌って整うと思う。
あとは最近のSTLの実行速度とかメモリ使用率ってどうなっているんだろう。
カーニハンの「プログラミング作法」やジョン・ベントリーの「珠玉のプログラミング」によると、
Cと比較してあまりにC++/STLが悪いんだよね。
# もちろんC++のほうがコード量が少ないということは言っておく。

252 :名無しさん@お腹いっぱい。:01/11/04 09:13
>>251
> groffってC++じゃなかったっけ?
C++だよ。リリース当時(10年くらい前だっけ?)、コンパイルできなくて萎えた。

> システムコールがクラスライブラリとして整備されればUNIXでもC++を使う土壌って整うと思う。
C++が最初から、システムコールやstdio、stdlibの薄いwrapperを
標準で提供してれば、better Cとして使われることは多かったんじゃないかな。
overloadできて嬉しいのはわかるけど、
cout << "Hello, world!" << endl;
を見て引いた奴も多かったんじゃない? (少なくとも俺は引いた)

253 :名無しさん@お腹いっぱい。:01/11/04 09:35
>>252
"Hello, world!" >> endl >> cout;
だったらそれなりに受け入れられたと思う(藁

254 :名無しさん@お腹いっぱい。:01/11/04 10:47
こんな感じか?

昨日、AT&TのBell研行ったんです。Bell研。
そしたらなんか人がめちゃくちゃいっぱいで座れないんです。
で、よく見たらなんか垂れ幕下がってて、C++とか書いてあるんです。
もうね、アホかと。馬鹿かと。
お前らな、C++如きで普段来てないBell研に来てんじゃねーよ、ボケが。
C++だよ、C++。
なんか親子連れとかもいるし。一家4人でBell研か。おめでてーな。
よーしパパオブジェクト指向しちゃうぞー、とか言ってるの。もう見てらんない。
お前らな、C++やるからその席空けろと。
Bell研ってのはな、もっと殺伐としてるべきなんだよ。
System V売ってるUSLの奴といつ喧嘩が始まってもおかしくない、
刺すか刺されるか、そんな雰囲気がいいんじゃねーか。女子供は、すっこんでろ。
で、やっと座れたかと思ったら、隣の奴が、演算子のoverloadとか言ってるんです。
そこでまたぶち切れですよ。
あのな、演算子のoverloadなんてきょうび流行んねーんだよ。ボケが。
得意げな顔して何が、演算子のoverloadだ。
お前は本当に演算子をoverloadしたいたいのかと問いたい。問い詰めたい。小1時間問い詰めたい。
お前、タイプ数を減らしたいだけちゃうんかと。
Bell研通の俺から言わせてもらえば今、Bell研通の間での最新流行はやっぱり、
Limbo、これだね。
Limbo on Inferno on Plan 9。これが通の環境。
Limboってのは安全なプログラムが書ける。そん代わりInfernoがないと動かない。これ。
で、それをPlan 9で動かす。これ最強。
しかしこれに慣れると他の環境でプログラムを書く気がうせるという危険も伴う、諸刃の剣。
素人にはお薦め出来ない。
まあお前らド素人は、AWKでも使ってなさいってこった。

255 :名無しさん@XEmacs:01/11/04 11:09
>>249
後、C++が発展途上の言語だった、というのも大きいと思うな。
UNIXではAPIをコロコロ変える文化がなかったから。
// 最近はGnome系を筆頭にupper layerで良く変わるんだけど。
C++98でやっとC++は固まったんだし。

256 :名無しさん@Emacs:01/11/04 13:10
>>254
実際には Plan9 が研究されているのは Lucent のベル研
(www.bell-labs.com) で、いま Stroustrap がいる AT&T の
旧ベル研 (www.research.att.com) とは別の組織。

257 :名無しさん@お腹いっぱい。:01/11/04 13:44
>>251
> あとは最近のSTLの実行速度とかメモリ使用率ってどうなっているんだろう。
かなり良くなってます。

プログラミング作法にあったサンプルコード (http://cm.bell-labs.com/cm/cs/tpop/code.html)
コンパイルして、実行した結果をつけます。x.txt は psalms.txt を 10 回繰り返したファイル。

OS Windows 2000 SP2
CPU AthlonXP 1600+
コンパイラ Visual C++ 6.0 SP5 (コンパイルオプション /O2 /MD)
STL STLport 4.5 (http://www.stlport.org/)

% time ./markov.exe < x.txt > /dev/null
0.01u 0.00s 0:01.54 0.6%

% time ./markov++.exe < x.txt > /dev/null
0.01u 0.00s 0:03.14 0.3%

ちなみに Gygwin 版の gcc 2.95.3 と、それについてくる STL だと、こんな感じ。

OS Windows 2000 SP2
CPU AthlonXP 1600+
コンパイラ gcc 2.95.3-5 (cygwin-special)
STL gcc 付属のもの

% time ./markov.exe < x.txt > /dev/null
1.12u 0.04s 0:01.18 99.1%

% time ./markov++.exe < x.txt > /dev/null
4.51u 0.06s 0:04.54 100.6%

258 :名無しさん@お腹いっぱい。:01/11/04 14:00
cygwin gcc + STLportの結果も必要
これだとSTLの評価としては意味ないでしょ

259 :名無しさん@お腹いっぱい。:01/11/04 14:12
>>258
C と C++ w/ STL の大雑把な比較が目的。

STL 自体の比較は 258 氏にお任せします :D

260 :名無しさん@お腹いっぱい。:01/11/04 14:20
>>255
> // 最近はGnome系を筆頭にupper layerで良く変わるんだけど。

さらに話の流れから外れるけど、それってどっちかというと Linux 方面の
文化だよね...

261 :名無しさん@XEmacs:01/11/04 14:30
>>257
> OS Windows 2000 SP2
> CPU AthlonXP 1600+
> コンパイラ Visual C++ 6.0 SP5 (コンパイルオプション /O2 /MD)

というの(STLportなし)も知りたいからお願いしたいの。

VC++のはプラウガが作ってるみたいだから知りたいの。(VC++持ってないのよ)

262 :名無しさん@お腹いっぱい。:01/11/04 14:37
>>259

>C と C++ w/ STL の大雑把な比較が目的。
>>257だとこの目的ちっとも達成してねーじゃん(w

263 :名無しさん@お腹いっぱい。:01/11/04 14:54
>>261
諒解。

VC++ 6.0 付属の STL
% time ./markov++.exe < x.txt > /dev/null
0.01u 0.00s 0:07.54 0.1%

VC6 付属の STL は性能は悪いし、仕様は古いし (std::auto_ptr に reset メソッドがなかったり)で、
かなりダメです。gcc + STLport は、STLport をインストールする必要があって面倒なんで、パスさ
せてください。

>>262
プログラミング作法の第3章に倣って、同じようなプログラムを C と C++ で組んで実行させてみた
ときに、特定の実装でどの程度の速度差が出るのかを比較してるだけ。

プログラムのソースコードも実行方法も全部明記してあるんだから、そこから自分にとって意味が
ある情報を抽出して利用するなり、全部無視して捨てるなりは読む人にお任せします。

264 :251:01/11/04 15:32
おお、なんか詳細なレポートが書かれてる!!ありがとうございます。

…同じマシンでのPerl版も見てみたい気はします。

265 :名無しさん@お腹いっぱい。:01/11/04 17:10
>>264
手元に環境があるものを、全部書いときます。先頭の数値が実行時間順、単位は秒。

1.2 C   (gcc 2.95.3-5, cygwin-special: -O2)
1.2 C   (Borland C++ Compiler 5.5.1: -O2)
1.5 C   (Visual C++ 6.0 SP5: /O2 /MD)
2.0 Perl (Perl 5.6.1, cygwin-multi)
2.3 Java (IBM J2RE 1.3.0 IBM build cn130-20010329, jit enabled)
3.1 C++  (Visual C++ 6.0 SP5, STLport 4.5: /O2 /MD)
4.5 C++  (gcc 2.95.3-5, cygwin-special, 標準STL: -O2)
5.8 AWK  (GNU awk 3.0.4, cygwin)
7.5 C++  (Visual C++ 6.0 SP5, 標準STL: /O2 /MD)
8.5 C++  (Borland C++ Compiler 5.5.1, 標準STL: -O2)

それと書き忘れてましたが、time は cygwin でコンパイルした tcsh 6.11.00 の内部
コマンドを使ってます。cygwin1.dll 使ってないプログラムに関しては、3 番目の総実
行時間以外は信用できませんので無視してください。

266 : :01/11/04 17:15
なんやかんや言ってみんなくわしいじゃん。< C++
これにメモリマップ上の動きまで入れば・・・
何やったときにどの部位がshared、anonymous、privateにくるかわかれば
グッドだねー。

267 :名無しさん@お腹いっぱい。:01/11/04 17:40
>>265
あれ?>>257とずいぶん数値も割合も違うね.

268 :名無しさん@お腹いっぱい。:01/11/04 17:53
>>267
これで、合ってるんじゃないの?

>>257
> コンパイラ Visual C++ 6.0 SP5 (コンパイルオプション /O2 /MD)
> STL STLport 4.5 (http://www.stlport.org/)
> % time ./markov.exe < x.txt > /dev/null
> 0.01u 0.00s 0:01.54 0.6%
>
> % time ./markov++.exe < x.txt > /dev/null
> 0.01u 0.00s 0:03.14 0.3%

この二つが >>265

> 1.5 C   (Visual C++ 6.0 SP5: /O2 /MD)
> 3.1 C++  (Visual C++ 6.0 SP5, STLport 4.5: /O2 /MD)

これに対応していて、最初の方の実行時間 1.54 秒を一桁で切り捨てて 1.5 秒に、後のほうの 3.14 秒
を 3.1 秒にしたものと思われ。

ユーザ時間、システム時間、CPU 占有率に関しては、cygwin1.dll 使ってないと無意味な数値しか返っ
てこないから、実行時間だけ抜いてきた、と。

269 :251:01/11/04 19:28
>>265
ありがとうございました。お疲れさまでした。

例題が文字列処理で得意分野だということを考えても、Perlの検討ぶりが目を引きますね。
Javaもなかなかですね…なるほどIBMのですか。そういえばjikesも狂ったように速かったですからねぇ。

270 :名無しさん@お腹いっぱい。:01/11/04 20:13
>>269
jikesは確かに速いが、どっちかと言うと標準のjavacが遅すぎってだけだろう。
まぁVMロードの時間がある分しょうがないけど。
>>265の計測も、プログラムの起動〜終了までの計測だったら全然違った結果に
なるんじゃないか?(少なくともJavaに関しては)

271 :名無しさん@XEmacs:01/11/04 20:30
>>270
timeの総実行時間なんだから、プログラムの起動〜終了までの計測だろ?
思い込みの激しい奴だな。

272 :名無しさん@お腹いっぱい。:01/11/04 20:45
>>270
> プログラムの起動〜終了までの計測
time 使って計測してる以上、CreateProcess() してから、そのプロセスが終わるまでの時間ですよね。

それとも、JVM の初期化やなんかのオーバーヘッドを除去して、純粋にデータの読み書きしてる部分だけ
持って来たら Java はもっと速いのでは、って話ですか? さすがに Athlon XP なんて CPU を使ってると、
実行ファイルやライブラリが RAM にキャッシュされている限りは、JVM や Perl インタプリタを起動する時
間は 0.1 秒未満で誤差の範囲でしょう。

273 :名無しさん@お腹いっぱい。:01/11/04 20:52
>>266 が何を言っているか理解できないのは、私だけ?

274 :Bill Shay:01/11/04 21:00
JDK1.4になるとさらに速くなるね、Javaは!
もうそんなに速くしなくていいよって感じ。

Javaの特権の遅延束縛生かしたままだからすっげーよなー♪

275 :名無しさん@お腹いっぱい。:01/11/04 21:04
>>274
Java に関しては Swing の遅さとユーザインターフェースの貧弱さをどうにかして欲しい。さすがに
MS が好き勝手に拡張する Win32 API についていくのは大変だと思うが、それでも同等のユーザ
インターフェースぐらい提供してくれないと辛いのよ。

276 :Bill Shay:01/11/04 21:12
ユーザインターフェースの貧弱さというのが意味不明だけど、
Javaは最大公約数を仕様としてるからねー。

Win32 APIが好きなら、VC++で十分じゃない?

277 :名無しさん@お腹いっぱい。:01/11/04 21:38
>>276
Swing が使いモノになれば MFC 捨てて Java で書ける仕事も多いのに、という意見。性能面では
不満ないし、ライブラリも充実してるしさ。

278 :名無しさん@お腹いっぱい。:01/11/04 22:40
Java1.4でやっとホイールスクロールに対応。
動作は相変わらず鈍重だが、たまーに速くなってるなと思わせてくれる時がある。
@Celeron400

ペン4の2GHz+最新グラフィックカードなら実用レベル逝くのかな?

279 :新手のC++使いゴゴゴ:01/11/04 22:43
C++ がこんなに遅いのがちょっと信じられなかったので、
ベンチマークのソース見たけど、
C++ 版プログラムは map クラスを使ってますね。

これって、連想配列ではあるけれども、
バイナリツリーか何かで実現されているから、
ハッシュテーブル使っている Java とか Perl に
勝てなくても当然のような。

(ハッシュテーブルはどんなに要素数が多くなっても
定数時間で要素を取り出せるけど、ツリーだと
n log n がせいぜい。そのかわりメモリを食わない)

あまり、ソースを深く読んだわけではないので、
外していたら、スマソ。

280 :270:01/11/04 23:51
>>271
う、その通り。なんか寝ぼけていた模様...逝ってきます。

281 :名無しさん@お腹いっぱい。:01/11/04 23:55
>>279
確かにmapがバイナリツリーならそう考えるのが妥当だと思う。
でも利用する側からすれば必要な連想配列のmapを使うのは正しい。
mapの変わりにハッシュテーブルを自前で実装したら
「Cと同等の速度になる」と容易に想像できるけれど、
それではC++/STLの旨味は薄れてしまう。
遅くなった詳細な理由はどうであれ連想配列のmapを使った結果ならば、
「(比較的)C++/STLが遅い」と結論しても間違ってない。

でもメモリ使用量とか、C++/STLのプロファイルは気になるね。

282 :名無しさん@お腹いっぱい。:01/11/05 00:16
>>281
非標準だけど hash_map や hash というコンテナを提供してる実装もあります。プログラミング作法
では IRIX のコンパイラで hash をサポートしていたので試してみたが map と差が出なかったとの
こと。

これも実装とデータによりけりでしょうが。

>>279
> ツリーだと n log n がせいぜい。
tree でバランスが取れてると仮定すると、n 個のデータを格納した tree の深さは log(n) ですよね。
したがって比較を主要な計算とすれば、一要素を取り出すのは O(n log n) ではなく O(log n) なの
では?

tree の場合は取出しよりも、むしろ挿入時にバランスをとる処理が重いんじゃないかなぁ。

283 :名無しさん@お腹いっぱい。:01/11/05 00:17
g++を(SGIのSTLを)使ってるなら #include <hash_map> で自作は
まぬがれますなぁ。漏れは把握してないけど、ほかの実装にもあるんじゃ
なくって?できれば <map>, <hash系map> の両方示して欲しいなぁ。

284 :C++屋さん:01/11/05 00:19
>>265
ご苦労さまでした。文句無くおもしろいデータです。

ただ、C++嫌いの人が「それ見たことか」と言うのは、的はずれであることも、
確認させてください。チューニングしたCとSTLで、実行時間を競うことに意味は
ないはずですから。(「比べる」の有意義で、おもしろかったです。)
C++で、チューニングすれば、そこは「珠玉」のようなコードになるべきですし、
その部分だけはCと同じようなコードになるわけです。
(むしろ、そういうコードをうまくラッピングできるところがよいところだと、思います。)

「STLの旨み」は重要ですが、「C++の旨み」全体ではありません。お忘れなく。
冷静な発言が多くなったので、よけいなお世話かもしれませんが。

285 :名無しさん@お腹いっぱい。:01/11/05 00:23
STLport には hash_map あるから試すのは簡単ですが、ハッシュ関数はどうします?

struct PrefixHash {
  size_t operator()(const Prefix& pref) const
  {
    // ここ
  }
};

これさえ定義すれば、あとは

// map<Prefix, vector<string> >statetab;
hash_map<Prefix, vector<string>, PrefHash >statetab;

と書き直すだけで行けますが。

286 :名無しさん@お腹いっぱい。:01/11/05 00:27
>>285
Cのをうまいことハメられないですか?

287 :名無しさん@お腹いっぱい。:01/11/05 00:49
mapじゃなくて、連結リストとかvectorで比べてほしい。

288 :名無しさん@お腹いっぱい。:01/11/05 00:51
>>287
そ、その心は。

289 :新手のC++使いゴゴゴ:01/11/05 00:54
>>282

失礼、嘘書いちゃいました。ごめんなさい。
頭の中で、ソートの時間とごっちゃになってしまった。。。
log n で正解です。

290 :名無しさん@お腹いっぱい。:01/11/05 00:57
>>286
結果から先に。
2.0 C++  (Visual C++ 6.0 SP5, STLport 4.5, hash_map: /O2 /MD)

なお、ハッシュ関数は C のコードに忠実に次のように定義しました。

struct PrefixHash
{
  enum { MULTIPLIER = 31, NHASH = 4093 };

  size_t operator()(const Prefix& pref) const
  {
    size_t h = 0;
    int i;
    const unsigned char *pc;
    for (i = 0; i < NPREF; i++)
      for (pc = reinterpret_cast<const unsigned char*>(pref[i].c_str()); *pc != '\0'; pc++)
        h = MULTIPLIER * h + *pc;

    return h % NHASH;
  }
};

291 :名無しさん@お腹いっぱい。:01/11/05 01:01
なるほど
まぁそんなものかなという感じです。
ありがとう>290さん

292 :新手のC++使いゴゴゴ:01/11/05 01:04
>>290

おぉ、素晴らしい。これなら納得がいきます。
ありがとうございました。お疲れ様です。

あぁ、しかし、STL も一般性を重視しすぎなんだよなー。
幾ら、どんなオブジェクトでもそれなりに速度が出る
ハッシュ関数を作れないといっても、
ハッシュテーブル自体を STL から追い出すこたぁないのに。

このあたり、Java とかの割り切りの良さも見習って
欲しいと思わないでもない。。。

293 :名無しさん@お腹いっぱい。:01/11/05 13:39
某社の面接説明会にて
おそらくはエライお人の弁

「やぁっぱさあ、時代はVB。今はCで組めるプログラマなんか求められてないわけさ。
 だから今はVBの仕事が多いわけ。これからは殆どVBになってくよ(ヘヘヘッ」

どう対処したら良かったか?

294 :名無しさん@お腹いっぱい。:01/11/05 14:04
「ではVBの時代が終わった時に御社は対応できるのですか?」
「本当に能力のある者ならば言語の違いなどは、取るに足らないことでしょう」

サゲだサゲ!!

295 :_:01/11/05 23:21
やっぱみんなC++はシンプルに使ってるんだね。昔言語仕様隅々まで勉強して遊んでたけど
どんどん生産性悪くなった気がする。(その後Delphiへ)
今はまた使ってるけど今度はモジュールのクラス化、単一継承、どこでも宣言とか
しか使ってない。いい感じ。

296 :>1:01/11/05 23:55
彼氏はいますか?

297 :名無しさん@お腹いっぱい。:01/11/06 00:04
>>295
多重継承はもちろん、仮装関数だって、使いたくなきゃ使わんでよいでしょ。

C++で重要なのは、クラスによるデータ隠蔽(それによるデータ抽象、つまり、
実装とインターフェースの分離)だと思う。
C++が出だした頃、「データ隠蔽だけでC++使ってる気になるなよ」みたいな
尊大なマヌーが多かった。C++に反感持ってるCプログラマの多くは、この手の
知ったかさんに不愉快な目にあったのでは?

けど、実際には、データ隠蔽が使いこなせれば、まず、よいんだと思うな。
そんで、それは決して難しくもないし、忌み嫌うほどのものじゃない。その先の
「オブジェクト指向」はお好みで使えばよいのではないだろうか。

基本は、keep it simple!で、何も大仰な道具を使うのがC++プログラミングでは
ないと思う。

あと、最近は、テンプレートってのもC++の御利益の一つだと思う。ただ、凝りすぎ
ると、またなんだけど。

DelphiとかVBとか、もうUNIXじゃないな。

298 :名無しさん@お腹いっぱい。:01/11/06 00:23
int i = 0;
cout << i++ << i++ << i++ << endl;
この動きが感覚的に合いません。

299 :名無しさん@XEmacs:01/11/06 00:26
Cのprogramは、wordの長さに上限があるので、そこの所よろしく。
手元のSTLport-4.5を見るとbasic_stringの初期buffer長は8にみえるけど、
これ変えたらもうちょっと速くなるかな?

300 :名無しさん@お腹いっぱい。:01/11/06 00:38
>>298
たしかに。でも、
printf("%d %d %d\n", i++, i++, i++);
の動きは感覚に合います?

301 :名無しさん@お腹いっぱい。:01/11/06 00:57
>>300
まったくその通り。Cは、どうしてそうなるの?

302 :名無しさん@お腹いっぱい。:01/11/06 00:59
>>301
シーケンスポイントで検索してみよう。

303 :名無しさん@お腹いっぱい。:01/11/06 01:25
>>302
了解しました。未定義言語仕様領域ですか。

304 :_:01/11/06 01:27
>>297
やっぱOOPの肝はデータ隠蔽だよね。
Cでもやれないでもないけど・・・

305 :名無しさん@お腹いっぱい。:01/11/06 04:55
ポインタをメンバに含む (当然デストラクタでそれを delete している) クラ
スで、コピーコンストラクタを定義し忘れて、かつ関数引数に値渡ししてしまっ
てハマったなんて人はいないのかなあ。
まあ、こんなの C++ を使うんなら基本中の基本だからいないのかもしれない
けど、シロートまじりの大規模プロジェクトの場合 (大規模プロジェクトの場
合、どうしてもダメな奴っているっよね?)、C++ はこの種の落し穴が一杯あ
りすぎて、Java に逃げて危険を回避してしまうことが多い気がする。

といっても自分は一人で C で書ける規模の仕事しかしてないので良く知らん
のだけど。STL に対応するものは既に自分で書いたのがあるので、別になくて
も困らないし (ていうか、そのあたりを自分で書くのが楽しくてプログラミン
グを仕事にしているというか)。継承さえしなきゃ、データ抽象くらい C でも
何の問題もないしね。

アプリケーションを動かすのが好きか、骨組みを作る方が好きかの違いかも
しれないなあ。

306 :名無しさん@Emacs:01/11/06 05:37
> C++が出だした頃、「データ隠蔽だけでC++使ってる気になるなよ」みたいな
> 尊大なマヌーが多かった。C++に反感持ってるCプログラマの多くは、この手の
> 知ったかさんに不愉快な目にあったのでは?

「データ隠蔽だけでC++使ってる気になるなよ」は
さすがにチト無理があると思うが、
「データ隠蔽だけでオブジェクト指向だと思うなよ」とは
言われているよね。

> やっぱOOPの肝はデータ隠蔽だよね。
> Cでもやれないでもないけど・・・

それが、そうじゃないらしいよ。
プログラム板の OOP スレとか見た?

あとどうでもいいけど UNIX とはもはや
あまり関係がなくなってきているような。

307 :名無しさん@お腹いっぱい。:01/11/06 08:24
OOPの肝は「データとその操作を固めておけること、そして抽象化できること」に尽きるね!
「警鐘による再利用」とかいいだす奴には近寄らんことにしてる。

>プログラム板の OOP スレとか見た?

近寄らないほうがいいよ。ヴァカの巣窟じゃん(w

308 :名無しさん@お腹いっぱい。:01/11/06 08:30
> OOPの肝は「データとその操作を固めておけること、そして抽象化できること」に尽きるね!
> 「警鐘による再利用」とかいいだす奴には近寄らんことにしてる。
ということで、構造体と関数ポインタで充分じゃんてことになりましたとさ。

309 :名無しさん@お腹いっぱい。:01/11/06 08:44
>>304
> やっぱOOPの肝はデータ隠蔽だよね。
それは勉強不足だなぁ。べつに従来の手法で事足りているならOOを勉強する必要はないけど(はっきり
言ってOOが向かない分野だってあるし)、勘違いしたままでOOを批判すると的を外すので注意。

>>305
> 継承さえしなきゃ、データ抽象くらい C でも何の問題もないしね。
それは「C の範囲で実現できるテクニックしか使わなければ、C で書ける」と言ってるようなものだから当
然でしょう。たとえばデザインパターンの Abstract Factory に類する機能を使おうと思ったら C だとかな
り厳しい(書けないことはないが、保守性が犠牲になる)。

C++ は C よりも設計上の選択肢が多い。その設計の柔軟性に意義を見出せれば C++ 使えば良いし、
意義を見出せなければ C で OK。ただ自分が勉強していないことを棚に上げて「C++ にはメリットがな
い」と真顔で主張するのは、やめて欲しいかな。2ch だし、それでも良いけど。

310 :307:01/11/06 09:00
>>308
抽象化ができないなー、構造体と関数ポインタじゃ。

311 :名無しさん@Emacs:01/11/06 09:01
>>309 がいいこと言った、ような気がする。
でもこのスレは C++ の是非を論じるスレではないでしょう。

あらためて 1 のような視点に立ってみると、
UNIX における C++は「ねぎだく」のように思える。
つまり、>>1 のような初心者にはお勧めできない、と。

C++ のような複雑な言語を使いこなせるキレ者 (そんなにいない) を
育てるよりは、もっと単純で、とっつきやすくて、そこそこ小回りのきく言語
(もちろん C ではない) をデファクトにしたほうが UNIX 開発者全体の
ためにいいんではないかと思う。

312 :307:01/11/06 09:15
310は戯言だった。忘れてくれ。

>>311 いいこといった!
「C++が理解できないのはきみの頭が悪いせいではない」なんつー言葉もあるしな。

で1のいうUNIXの仕事ってなによ?
kernelやらデバドラ開発やらならCだろよ。
ネットワーク分散+セキュリティ重視ならJava。
単にアプリ開発をUNIXでなら言語なんてなんでも。

313 :厨房:01/11/06 17:01
とりあえずUNIXでC++とSTLを使うためには何をインストール
すれば良いのか教えろやコ゛ルア

あとUNIX上のC++やSTLが実用段階に達しているか教えろやコ゛ルア

314 :名無しさん@お腹いっぱい。:01/11/06 17:29
>>313
とりあえず ftp://どっかのGNU mirror/gcc/gcc-3.0.2/gcc-3.0.2.tar.gz
いっとけやコ゛ルア

あと充分実用になるとおもうぞコ゛ルア

315 :名無しさん@お腹いっぱい。:01/11/06 18:59
まだ gcc-3.x は使うのが怖いぞゴルァ。

316 :名無しさん@お腹いっぱい。:01/11/06 19:32
いつまでもそんなこと言ってっからいまだにUNIXでC++が普及ねえんだよゴルァ。

317 :名無しさん@お腹いっぱい。:01/11/06 19:32
STLはtemplateコードでしかないからUNIX上の云々は忘れてしまえコ゛ルア

318 :名無しさん@お腹いっぱい。:01/11/06 22:27
gcc-3.0.2は、C++使う分には、問題ないのでは?

319 :名無しさん@お腹いっぱい。:01/11/07 01:11
難しいこと考えずに使い分けりゃいいの。
C++で書くのが適切であるならそれ使えばいいし
どれでもいいなら好きなもの使えばいい。

320 :名無しさん@お腹いっぱい。:01/11/07 01:40
>とりあえずUNIXでC++とSTLを使うためには何をインストール
>すれば良いのか教えろやコ゛ルア
一日一回しかリセットしないデーモンプロセスをg++で書いて
4年安定動作。ただしgcc2.7。
egcs以降のコンパイラではちょっと危険を感じる。
メンバー変数をグローバル変数にしないと
代入されないバグにぶつかった。
4000ぐらいのソースの一箇所。
gdbを使いこなせれば大丈夫だが。

321 :名無しさん@お腹いっぱい。:01/11/07 01:47
>>320
1日1回リセットって、たいして安定しているわけでもないような。

322 :名無しさん@お腹いっぱい。:01/11/07 01:55
>>320
リセットなしはDRAMを使っているマシンでは冒険。
5分止めたら切腹ってケースでは使えない。

323 :名無しさん@お腹いっぱい。:01/11/07 04:17
BC++を使いましょう。

324 :名無しさん@お腹いっぱい。:01/11/07 04:23
C++なんて現場じゃ使わねぇなぁ。
研究者の言語だろ?

325 :名無しさん@お腹いっぱい。:01/11/07 05:03
>>324
Windowsの現場では使ってるようす。

326 :名無しさん@お腹いっぱい。:01/11/07 05:26
またC++信者がさわぐからほっとけ。

327 :名無しさん@お腹いっぱい。:01/11/07 11:24
>>325
最近は、一部の組み込み機器でさえ使われてるが。

328 :C++は複雑すぎだけど、OOP自体は便利だ:01/11/07 11:30
あの。
使ってますよ。C++。ユニックスでも。
どういう、基準でクラス化してるのか、さっぱりな感じですが・・・。
C++使う前に、それを使うメリットを学んでほしいと思った。

なんのために、クラス化するのか?っと。
ウィンドウズを作るとしたら。
Cでつくるより、C++の方が(というよりOOPの方が)、
多くの人は、やり易いのだと思う。
その理由を考えれば、使いどころわかる出所。

パラメータが1万以上もあるプログラムを、
OOPでない言語で管理する大変さ。
1万のパラメータを考慮して、機能の改定や追加をやっていたのでは(^^;

329 :名無しさん@お腹いっぱい。:01/11/07 11:45
>>323 >>324 >>328
UNIX specific な話でないなら、スレ違いなんだから sage てくれ。

それから 328 は、文章を推敲してくれ。「使いどころわかる出所」という表現など、どうにも
意味不明だ。

330 : :01/11/07 13:28
でしょ

331 :名無しさん@お腹いっぱい。:01/11/08 11:58
アプリ等の応用レベルならどんな言語を使おうと勝手。
目的に合ったライブラリがそろったものを選べ。

低レベルなプログラミングなら、やっぱCかアセンブラだろ。

332 :名無しさん@お腹いっぱい。:01/11/08 19:27
シーぷらぷら

と言うのは気持ち悪いから即刻やめろ!!!!!!!!!
何がプラプラやねんボケ!!!!!!!!!!!!!!
何かお前の目の前では垂れ下がっとるんか。
ウマかおんどれは。

333 :1を読まずにカキコ:01/11/08 21:13


334 :名無しさん@お腹いっぱい。:01/11/08 21:19
>>332
っていうか、なんと呼べっていうの?

335 :名無しさん@お腹いっぱい。:01/11/08 21:46
C++信者なんてまだいるのぉ?(w

336 :名無しさん@お腹いっぱい。:01/11/08 22:02
昔 C++ をなんて読むのかわからなくって
某ユーザサポートに電話かけたついでに
聞いたことがあったような…
向こうは さぞあきれてただろーなー

もー 8年ぐらい前の話

337 :名無しさん@お腹いっぱい。:01/11/08 22:10
「しいぷっぷ ♥ 」が正しい。

338 :名無しさん@お腹いっぱい。:01/11/08 22:15
よっぽどC++が嫌いな人がいることがわかった。
「C++嫌い教」信者だな。
もういいよ。好きにしなよ。
まあ、ウソ八百を若者の前で言うのはやめてほしいけどな。

339 :名無しさん@お腹いっぱい。:01/11/08 22:21
よっぽどC++が好きな人がいることがわかった。
「C++好き教」信者だな。
もういいよ。好きにしなよ。
まあ、ウソ八百を若者の前でいくら言ってもいいけどな(藁

340 :名無しさん@お腹いっぱい。:01/11/08 23:25
off topic な話題は sage でやれ。

341 :名無しさん@お腹いっぱい。:01/11/08 23:26
「ぷらぷら」なんて呼ばずとも職場内では「プラス」で通じるからねえ

342 :名無しさん@お腹いっぱい。:01/11/08 23:44
しーぷら
ちんぷら

343 :名無しさん@お腹いっぱい。:01/11/08 23:55
しぃたすたすでしょ。

344 :名無しさん@お腹いっぱい。:01/11/09 00:08
マクロス++

345 :名無しさん@お腹いっぱい。:01/11/09 00:09
Cインクリメント

346 :名無しさん@お腹いっぱい。:01/11/09 00:15
俺の歌を聞け聞け!

347 :名無しさん@お腹いっぱい。:01/11/09 00:21
会社に来たどうしようもない中途採用が「インストゥール」というのが気になります。
風の神様のハストゥールのトゥールと一緒なんです。
気になります。

348 :名無しさん@お腹いっぱい。:01/11/09 00:24
>>347
インストロールよりは良いだろ(w

349 :名無しさん@お腹いっぱい。:01/11/09 00:35
インストロールは分かってていうからいいけど
心の底からホントにインストゥールだと思ってる節があるのが怖い。

いあ!いあ!

350 :名無しさん@お腹いっぱい。:01/11/09 00:39
ディスクトップとかもな。

351 :名無しさん@お腹いっぱい。:01/11/09 00:54
>>347
対抗して、いんすたー って読んであげれ。

352 :名無しさん@お腹いっぱい。:01/11/09 01:04
>>350
OpenBlock のことか?

353 :名無しさん@お腹いっぱい。:01/11/09 02:05
>>336
そんで何て読むんだよ。
何で肝心のことを書いとかねーんだよ、ゴルァ!

ちなみに俺はシープラスプラスと読む。
昔、TurboC++買ったときに付いていた解説ビデオでも
シープラスプラスと読んでいた。

354 :名無しさん@お腹いっぱい。:01/11/09 03:28
おれには「すぃぷらっぷらっ」に聞こえたぞ。

355 :名無しさん@Emacs:01/11/09 05:24
外人は、ちゃんと律義に
「しーぷらすぷらぁす (最後にアクセントがある)」
っていってるぞ。

どうでもいいけど、むかしMacのDAにDiskTopってのが
あったんだよねーあれは便利だったなー。

356 :名無しさん@お腹いっぱい。:01/11/09 05:28
しーたすたすって読んで笑われました

357 :おたく、名有りさん?:01/11/09 09:05
ぼくは拡張子をとって「しーぴーぴー」って呼んでいます。
ちなみにC++賛成派です。

358 :名無しさん@お腹いっぱい。:01/11/09 09:06
>>356
じゃあ、i++ はなんて読むの?

359 :名無しさん@お腹いっぱい。:01/11/09 10:03
先日 "C++" を "C incremented" と呼んでる人に出会った。
また新たなカルチャーショックが(藁

360 :名無しさん@お腹いっぱい。:01/11/09 16:08
>>357
C のプリプロセッサはなんて呼ぶの?

361 :1です:01/11/10 00:49
自分の新レスがこんなに続いてるなんて・・・。
ずっとVC++だったので、当たり前のように使っていたMFCが使えないというのは
かなりショックでした。
確かにVB,VCばっかりだったらバカになるかも。
ヌルなんて意識したことありません。ヤバイなぁ。
頑張って勉強しなきゃ〜〜〜

362 :名無しさん@お腹いっぱい。:01/11/10 18:55
>>361
VC なんて、余計 NULL を意識しなかったら例外の嵐だと思うのだが
VB とて Null と全く無縁ではないし

そもそも、MFC 自体がアレだから使わない、という人が
Windows 用で高速でコンパクトなバイナリを吐く為だけに
VC 使う人間も居るわけだから、結局使う人間で決まるよ

363 :名無しさん@お腹いっぱい。:01/11/10 20:17
>>362
NULL, Null といってるが、何をさしてるのか明記しないとワケ分からん。C/C++ の null pointer
constatant?

364 :名無しさん@お腹いっぱい。:01/11/10 23:39
あんまりよく知らなくても組めるMFCが嫌で(根本から理解したいクチ)
自分でイチからやってったんだが
そうしたら何かアセンブラもやらねばならんような気がしてやり始めた。

こうやっていつも俺は遠回りだ!!!ボケ!!!!!

365 :名無しさん@お腹いっぱい。:01/11/10 23:52
>>364
Winなら最高の近回りジャン。

なんでもいいけどUNIXの話してくれ¥。

366 :デフォルトの名無しさん:01/11/11 23:55
VisualC++のMFC クラスを使ったプログラムだが、
あんなものを使って、きちんとしたPG作れるのが不思議だと思う。

実際、クラスを効果的に使っているというケースはすくないとおもうのだが。

367 :新人プロ巨乳♪:01/11/11 23:58
UNIXはJAVA+SHELLが多いんでない?

368 :名無しさん@お腹いっぱい。:01/11/12 01:14
>>364
板違いだけど、マジレス。

MFC は結局、背景にある Win32 API やメッセージループに関する知識がないと使いこなせない。
アセンブラはともかく、MFC なしの素の Win32 API プログラミングを経験するのは必須だよ。

369 :名無しさん@お腹いっぱい。:01/11/12 01:40
もとから知りたい人間だと
コンパイラも作りたくなるってもんさー。

370 :名無しさん@お腹いっぱい。:01/11/12 01:50
コンパイラ作るとなると、C++は仕様がでかすぎだYO!

371 :名無しさん@お腹いっぱい。:01/11/12 03:19
compiler 作る場合は Scheme が best ?
って激しく話が外れたな。

372 :名無しさん@お腹いっぱい。:01/11/12 03:47
GUI系はGTK+とかQT触った事ないので比較できないけど、Unixでも少なく
ともシステムコールの知識は必要だよね。
もちろん抽象化して意識させないようにする方法もあるけど、そうすると
今度は(OWLやJavaと同様)かゆい所に手が届かなくていらいらする訳で。

MFC Internalとか読むと、MFCというのは「何でもいいからとにかく既存の
DOS/CプログラマをとっととWindowsに移行させてがんがん開発させる」為に
作られたようなので、クラスライブラリとしての出来が悪いのは「そんなん
言われなくてもわかっとるわボケ」って所なんでは。

# ちなみにMFCの一番最初のプロトタイプは、抽象化された「まともな」設計
# だったらしいが、当時のマシンパワーでは遅すぎて使い物にならなかった
# んで、作り直した結果ああなったのだとか

MSを養護するつもりはさらさらないが、「設計よりも戦略重視」「移行の為
の暫定ライブラリ」という意味では、あれで正解だったんだろう(事実Winの
開発者どっと増えたしね)。

ってやっぱり激しく板違い(しかも長い)だな。すまん。

373 :名無しさん@お腹いっぱい。:01/11/12 04:46
>>372 s/養護/擁護/

374 :名無しさん@お腹いっぱい。:01/11/12 05:07
何年か前までCがメインだったけど今ではC++以外考えられない。
Cの前はAda使ってたこともあったし言語にはあまりこだわりない。

必要に応じてCも使うけど、今まで書きためたプログラムの再利用を
考えたらCはキツい。特にアプリ作るときは。
仕様見て前に同じようなスペックのウインドウ作ったよなぁ〜ってと
きに前に作ったそのウインドウクラスの継承クラス作ってそれにチョ
コチョコっと書き足してハイ終わりっと。
おかげでウチはかなり工数減った。

でもデメリットも確かにあるね....
C++って設計がマズいとC以上に最悪の結果をもたらすんだよね。
それとtry&catchをいたるところで乱用されたりするとデバッグが大
変なんでチーム内でコーディング規約ガチガチにしたりと。

うちは「シープラプラ」って呼んでます。

単なる余談なのでsage

375 :デフォルトの名無しさん:01/11/12 20:11
>それとtry&catchをいたるところで乱用されたりすると
デバッグが大
変なんで

そうかな?

376 :名無しさん@お腹いっぱい。:01/11/12 20:19
エラーではない例外を多用されるとしずらいかもね
書き方によっては

377 :名無しさん@お腹いっぱい。:01/11/12 20:42
UnixでC++が使われない理由・俺バージョン:
 man(1)で標準ライブラリのリファレンスが読めないから

378 :名無しさん@お腹いっぱい。:01/11/12 20:54
>>375
ちゃんとthrowしてくれればいいんだろうけど
throwする事をヘッダに明記しておいてくれないと探すのは
結構大変だと思う

class A
{
  public:
    void func1() throw(MyError); //throwする
    void func2() throw();     //throwしない
};

379 :名無しさん@お腹いっぱい。:01/11/12 21:28
>>378
C++のthrowに指定してないものを投げてもコンパイル時にエラーに
ならないですよね?
それで、実行時にunexpected()が実行されるんでしたっけ?
なんか、使いにくくないですか?

380 :374:01/11/12 22:23
>>375
複数で作るときにきちんと取り決めして、それに従って書かれて
いればいいんですけどね。

>>376
そうそうそういうのですよ、人によって
・エラーでも例外でもなんでもかんでも全てthrowで飛ばす。

「エラー」と「(本来の意味の)例外」を混同して使われると
エラー処理に一貫性がなくてエラーの後処理やメッセージの表示
がうまくいかない。ファイルへの書き込み中のディスク容量不足
なんて想定されるエラーの手続きであって例外ではない。
そいつのソース見てreturnでエラー値を返すメンバ関数が皆無だっ
たとき(全部 void xxxxx(); でやんの)は鬱になった。
1人でも「みんなの決め事」を無視して書く奴がいたらもうアウト!

さらに・・・
・catchがどこにあるか本人しかわからない。
→よくよくソースを調べると7つも8つも上の呼び出し元のcatch
にいきなり飛び込んでくるようなプログラムとかね。こういうソー
ス書かれるとどこで例外が発生しているのかを探すのも労力使う。
throwがいっぱいあって本人にどこでcatchすんの?って聞いても
本人もよくわからないくらい複雑になってしまったりとか。

オグジェクト指向の狂信的信者がC++のテクニックに溺れて書いた
ようなソースはダメダメなのが多いというのが教訓。

381 :名無しさん@お腹いっぱい。:01/11/12 22:42
ム板よりはるかにまともな議論になってる・・・
ここはT大生とか多いからか?

382 :名無しさん@お腹いっぱい。:01/11/12 22:49
>>379
はっきり言って使いモノにならない。

383 :名無しさん@お腹いっぱい。:01/11/12 23:01
>>380
> よくよくソースを調べると7つも8つも上の呼び出し元のcatch
> にいきなり飛び込んでくるようなプログラムとかね
一気にスタックをさかのぼれるのが例外のメリットだから、7, 8 階層上で catch するのは、むしろ
よくあることだけど。基本的には

- 原因となる事態が発生した個所
- その事態に対処する個所

が近いレイヤにあれば戻り値で、そうでなければ例外にする。

あと、例外とOOは直交する概念と思われ。例外を駆使したデザインパターンとか、聞いたことないし。

384 :374:01/11/12 23:35
>>383
> 一気にスタックをさかのぼれるのが例外のメリット
確かにそうなんですけどね、勝手にやられると書いた本人以外にはエラー
または例外発生時の処理の流れが非常にわかりにくい(==維持&改造が困難)
プログラムになってしまって本末転倒という事態が多々あったもので。

385 :名無しさん@お腹いっぱい。:01/11/13 01:20
要するにランタイムエラーと例外はちゃんと分けて
考えようって事だね

386 :名無しさん@お腹いっぱい。:01/11/13 01:27
「例外だけは例外で」と説明されたときには
どう突っ込んでいいものやら迷った。

387 :名無しさん@お腹いっぱい。:01/11/13 01:29
>>381
同じ職場で高卒でも能力によっては大卒より
高い給料がもらえる職業だけどな

・・・ってかんけーねーなsage

388 :名無しさん@お腹いっぱい。:01/11/13 01:35
>>385
なんか、微妙に実のある方向に話が進んでますね :D

言葉の定義になりますが「ランタイムエラー」と「例外」は、具体的にどういう基準で区別してます?
私は原則として >>383 に書いた基準で、例外を投げるか戻り値で返すかは決めてます。いわゆる
実行時に発生するエラーでも、例外を投げる設計にすることはあります。

たとえばスマートポインタクラスで

- dereference するときに、ポインタが有効かどうかをチェックする

という要件があったとします。この場合、チェックした結果ポインタが不正な値を指していたら、戻り
値で問題を知らせるのではなく、例外を投げるようにしますね。(だから「ランタイムエラー」というの
は、ちょっと言葉が違う気がする)

389 :374:01/11/13 03:13
>>388
区別は・・・
例外としてしか処理出来ない事象(コンストラクタ内で発生するエラー(ラン
タイムエラー含む)とか)は当然ですけど、プログラムが続行不可能な致命的
なランタイムエラーについては例外扱いで処理することが多いです。
「予測可能もしくは予測すべき」一般的なランタイムエラー(mallocでメモ
リ確保出来なかったとかディスク容量足りないとか)を例外で処理することは
ほとんどないです。

390 :名無しさん@お腹いっぱい。:01/11/13 03:27
>>374=389
でも new が bad_alloc を throw したりするんでニンともカンとも。
けっきょく、例外を投げるか戻り値で返すかという議論の答えは
「好きにすれば」になりそうでコワい。

391 :こんな言葉がある:01/11/13 04:16
投げたらアカン。

392 :名無しさん@お腹いっぱい。:01/11/13 09:06
>>390-391 このスレ、年寄ばっか?

393 :名無しさん@お腹いっぱい。:01/11/13 14:15
>>390
最終的にはそのプログラムによると思うんだけど
漏れはほとんどの場合newするときはtry-catchで
bad_allocを検出してます

bad_allocだった場所がクリティカルだったらメッセージ出して
落とすこともあるし実害が無ければ自分の例外クラスをthrow
するようにする事もある

394 :393:01/11/13 14:20
補足
もちろんnewしてる関数内でtry-catchしてる訳ではないよ
それだと返り値判断とかわらなくなっちゃうから(w

newする関数を使うところでtry-catchしてるって事ね

395 :名無しさん@お腹いっぱい。:01/11/14 14:06
>>389
C で exit() + atexit() 使う代わりに C++ では例外を使ってる、ということかな。それだと setjmp() を
使うべき場面には、どう対応しているんだろうか。longjmp せずに exit で済ませるというのも、それで
済むソフトならアリだけど。

396 :名無しさん@XEmacs:01/11/15 00:16
>>395
さらに、dtorに後始末を任せるprogramming styleが、例外の醍醐味なのにね。
"exception safeなctor"って何なのか調べるべきだな。>>389
Exceptional C++でも読んで。

397 :374(==389):01/11/15 04:05
>>395
>C で exit() + atexit() 使う代わりに C++ では例外を使ってる、
そういうわけではないです。というかexit()等で終わらせることもsetjmp()
で飛ばすことも可能な限り避けてます。なるべくスタンダードライブラリ
に依存しないように書きます。なぜなら同じソースをベースにしたWinやMacへ
の移植を前提にしているためです。稀に各々のプラットホームのライブラリ
で微妙に動作が違うことがあるのと、WinはまぁいいとしてMacのライブラリ
があまり良くない(遅い重いデカい)という事情で。

398 :名無しさん@お腹いっぱい。:01/11/15 12:10
>>397
C, C++ 問わず大域脱出を使っていないわけですね。ま、それはそれで幸せかも。

399 :名無しさん@お腹いっぱい。:01/11/15 13:39
>>396
あとは例外を階層化できるのも利点ですな。

400 :名無しさん@お腹いっぱい。:01/11/22 00:39
初心者向きでも、オブジェクト指向やテンプレートをちゃんとやってくれる本見つけた。
すごく気に入ったんで、書かせてくれ。
「これならわかるC++」
http://www.amazon.co.jp/exec/obidos/ASIN/4062573318/qid=1006356888/sr=1-2/ref=sr_1_0_2/249-2301510-3475560

401 :名無しさん@お腹いっぱい。:01/11/22 09:40
例外処理なら「ExceptionalC++」。嫁。

402 :名無しさん@お腹いっぱい。:01/11/22 12:49
More Exceptional C++ モナー
http://www.amazon.co.jp/exec/obidos/ASIN/020170434X/

403 :名無しさん@お腹いっぱい。:01/11/22 15:46
>>400
よさげな本ですね、書店で探してきます。

404 :名無しさん@お腹いっぱい。:01/11/22 23:12
UNIX派って、なんだかんだいってもただの
手続き型言語であるC使いなんだね。要するに力作業。
C++の本当の良さを知らないからCでじゅうぶんだと言ってる連中もいるし。

405 :名無しさん@お腹いっぱい。:01/11/22 23:27
この辺で煽ることはないと思われ。マターリな。

406 :名無しさん@お腹いっぱい。:01/11/22 23:32
>>404
UNIX 派と一括りにするのは、よくない。それいったら Win 厨だって VB で十分とか言い出すヤツは
たくさんいるんだし。

せっかく age たことだし、技術的なネタでも振ってくれ。>>404

407 :名無しさん@お腹いっぱい。:01/11/22 23:37
議論がループする予感。

408 :名無しさん@お腹いっぱい。:01/11/23 00:53
>>407
俺は 404 は逃げるので、議論にならないに一票だな。

409 :名無しさん@お腹いっぱい。:01/11/23 01:26
別にVBでもVCでも何でもいい。
人が何使おーが知ったこっちゃない。そんな金にならん事をグダグダ言うよりも
明日のオマンマだ。

410 :名無しさん@お腹いっぱい。:01/11/23 01:33
>>409
VB の仕事は単価安いから、あまり腹がふくれないけど。

411 :名無しさん@お腹いっぱい。:01/11/23 03:02
力作業って言われてもねえ。"一流プログラマ"とやらが書いた
C++よりもBernsteinが書いたCの方が信用できるし。

英数をすべて全角で書いてるのは煽りの一環なのかな(笑)

412 :名無しさん@お腹いっぱい。:01/11/23 03:08
明日のおまんまより今日のおまん○

413 :名無しさん@お腹いっぱい。:01/11/23 04:20
UNIXは力作業派が多いね。よくCでいつまでもガリガリやってるよ。

414 :名無しさん@お腹いっぱい。:01/11/23 04:22
Cしか使わないから、サイズがでかいという理由でWinを認められないんだな。

415 :名無しさん@お腹いっぱい。:01/11/23 07:22
確かに、みぢかくて無駄のないCプログラムは美しいな。
(若くないC++使いはたいてい元C使いだからそれはわかるのだよ。)
でも長いプログラムであの美しさが維持されることはほとんどないだろ。

他人が書いた5万行のCプログラムのメンテなんて任されたら、それを
書いたやつらが「優秀」でもものすごくいやじゃない?
C++の場合、それが「優秀」なやつらのものなら、「ものすごくいや」が
「いや」くらいになる。
(もちろん、だめなやつのプログラム別だよ。CだろうがC++だろうが。)

というわけでCとC++使い分ければいいじゃん。

416 :名無しさん@お腹いっぱい。:01/11/23 10:05
>>413-414
ネタは sage でな。

417 :名無しさん@お腹いっぱい。:01/11/23 10:09
>>415
tcsh だの sendmail のソースに手を入れるのは、正直疲れすぎ。

だからといって Mozilla が楽かと言えば、まぁ、そんなこともないんだが。

418 :名無しさん@お腹いっぱい。:01/11/23 22:46
sendmailって、設定から疲れすぎな俺は、何?

419 :名無しさん@お腹いっぱい。:01/11/23 23:06
あがってる。
>>400 さんくす。
全部読んでないけどいいな。明日の予定は読書だ。(w

420 :名無しさん@お腹いっぱい。:01/11/25 21:59
あげ

421 :名無しさん@お腹いっぱい。:01/11/25 22:05
漏れの場合、使わないんじゃねーよ。使えねぇんだよ。

422 :名無しさん@お腹いっぱい。:01/11/25 22:20
つうか門すら叩いてないぞ。
つうか「C++やりたい人はコチラ」の案内板すら見てないぞ。
つうか頭にすらやる気が起きてないぞ。

今のところはな。

423 :名無しさん@お腹いっぱい。:01/11/25 22:34
C++なんてそういう言語があるということしか知らないですが何か?

424 :1:01/11/25 22:58
1です。
UNIXの開発をはじめて2週間がたちました。
Cのみですが、基本はCということを改めて痛感してます。
ところで、UNIXでC++で開発してるのは全体の割合でどれくらいなんでしょうか?

425 :名無しさん@お腹いっぱい。:01/11/25 23:14
基本は汗だと心得よボケがぁ。

426 :名無しさん@お腹いっぱい。:01/11/25 23:19
FreeBSDの/usr/src 以下をcpp/ccでfindすると、ヒットするのは
gperf,groff,libio,libstdc++,openssl,ncursesだけだ。
このうち、opensslは全体のごく一部だけがC++。
libio,libstdc++はC++のライブラリだからあって当然。
ncursesはC++インタフェース部分だけ。
だからこれらは除く。
するとbase配布物の中ではgperf,groffだけがC++。
しかもこれらは両方ともGNU配布でcontribの中にある。

つまり、基本システムだけ見ると「ほとんど使われてない」と言って差し支えない。
たぶんLinuxの同じくらいだと思う。

427 :名無しさん@お腹いっぱい。:01/11/25 23:44
大文字の C はhitしない?

428 :名無しさん@お腹いっぱい。:01/11/25 23:45
>>427
しませんでした

429 :名無しさん@お腹いっぱい。:01/11/26 00:01
>>425
ボケというほど無茶なことは言ってないと思うが。

430 :名無しさん@お腹いっぱい。:01/11/26 00:06
回し者?

431 :名無しさん@お腹いっぱい。:01/11/26 00:09
>1,424
そもそもUNIXの種類に応じてC++コンパイラの品質に著しい差があるんだから。
AIXではその比率は多いと思われ。

432 :関西人の使う「アホ」と一緒:01/11/26 00:48
>>429

洒落&勢いだよボケがぁ。

433 :名無しさん@お腹いっぱい。:01/11/26 01:00
C使いのじじい供は現代のコボラーだと聞きました。
本当でしょうか?<図書スレ@ム板

434 :名無しさん@お腹いっぱい。:01/11/26 02:04
Cは力作業。

435 :名無しさん@お腹いっぱい。:01/11/26 02:05
アホではこのスレについて行けん。
修行のたびに出てきます。

436 :名無しさん@お腹いっぱい。:01/11/26 02:24
coboler? Cの手に余る場面ではgc付き言語を使う機会が多いだけなん
だけどな。(java,perl,python,ruby,etc.) ま、Windowsプログラマは
C++の記憶管理作業が好きな人が多いらしいので噛み合わんか。

437 :名無しさん@お腹いっぱい。:01/11/26 03:21
Cはもう古い。

438 :名無しさん@お腹いっぱい。:01/11/26 06:51
C使いは現代のコボラーってのに一票。
数にまかせて新しい言語に抵抗するところがクリソツ。

しかし、わざわざC++スレにでばってきて、悪意に満ちたレスを繰り返す
ところは、より極悪と言えよう。

439 :名無しさん@お腹いっぱい。:01/11/26 09:18
UNIXって、C知ってりゃいいのか。

440 :名無しさん@お腹いっぱい。:01/11/26 10:11
「C使いは現代のコボラー」

って恥ずかしげも無く言える人間になりたい。

441 :名無しさん@お腹いっぱい。:01/11/26 10:19
コボラーってOS書けるんですか?

442 :名無しさん@お腹いっぱい。:01/11/26 10:39
C使いっていうよりCしか使えない、だな

443 :名無しさん@お腹いっぱい。:01/11/26 10:41
C使えりゃアセンブリ以外はどの言語も簡単

444 :名無しさん@お腹いっぱい。:01/11/26 11:09
そういうやつに限ってJavaすら使えない。
なんでもフローチャートで書けるとか思ってない、あんた?

445 :名無しさん@お腹いっぱい。:01/11/26 11:13
またレベルの低い奴がまぎれこんでるな(ワラワラ

446 :名無しさん@お腹いっぱい。:01/11/26 11:18
Cしか使えないプログラマなんていないだろ(笑)
VC++しか使えないプログラマとかJavaしか使えない
プログラマならいそうだな

447 :名無しさん@お腹いっぱい。:01/11/26 11:26
>VC++しか使えないプログラマとかJavaしか使えない
>プログラマならいそうだな

いそうどころかそういう奴ばっか
そういうのがUnix板に来てC、Unixを否定しに来るもんだから微笑ましい。

448 :名無しさん@お腹いっぱい。:01/11/26 12:08
>447

たしかに最近の新人はそこから入るからそういうやついるけどな。
ポインタを知らないJavaOnly野郎とか。
しかし、Cやその他の手続き型言語しかできないやつらよりはいいぞ。
手続き型言語なんてそんなのは覚えるだけで誰でもできる。
Javaでオブジェクト指向を学んだほうが将来的にぜったいにいい。
C野郎があと使うのはせいぜいスクリプト用の言語ぐらいだろ?
そんなのばっかりやってるとオブジェクト指向についていけなくなるぞ。

449 :名無しさん@お腹いっぱい。:01/11/26 12:47
カーネルのソースを理解できないクセして、
Cはいいとかいってるのもう見てらんない。

450 :名無しさん@お腹いっぱい。:01/11/26 13:00
>>448がいいこと言った。
そう、Cなんて(文法だけなら)誰でもできるんだよ。
それを偉そうにしているのはなぜ?

ついでに言うとC++だって誰でもできるんだよ。
でも、ヒィヒィ言ってやっとCを覚えたじいさんたちはそれすら
できねーで、C++なんかいらねーとか言ってんのね。

たく、おまえらこそUNIXから出て毛よ。

451 :名無しさん@お腹いっぱい。:01/11/26 13:03
ポインタを理解できたのが、あんたらの人生の最高点だったんだろ。
>>Cオンリーさんたち。

452 :名無しさん@お腹いっぱい。:01/11/26 13:27
粘着質ですなぁ・・・・

453 :名無しさん@お腹いっぱい。:01/11/26 13:53
今1から通して読んでみたけど
C++を擁護してCを煽ってる問題児が一匹いるね。
煽ってるというよりC++を愛しすぎて熱くなりすぎ(笑

454 :名無しさん@お腹いっぱい。:01/11/26 14:01
言語を必要以上に排他的に語る人にデキル者はいない。これ常識

455 :名無しさん@お腹いっぱい。:01/11/26 14:15
なんか「C++==オブジェクト指向」と思い込んでる可哀想な人達が多いな

456 :名無しさん@お腹いっぱい。:01/11/26 14:16
>>454
じゃ、ここのC++信者はできそこないばっかだね(笑)

457 :名無しさん@お腹いっぱい。:01/11/26 14:35
>>451
Cしかできない人をばかにしちゃあかん。あの人たちかて、家では
りっぱなおとーさんなんや、て、ママに言われなかったか。

458 :名無しさん@お腹いっぱい。:01/11/26 15:13
>>456
そりゃ「信者」と言った時点で(たぶん一神教なんだろうから)他の言語に寛容ということはあるまいて。

将来的にはどうか分からんが、現時点では UNIX や Win32 で C++ 使って仕事してる人間は、C から
入ってるのが大半 (最初の仕事は C だったろ?)。だから C++ を擁護して C を叩くプログラマは、あ
まりいないと思われ。プログラマ以外は知らん。

459 :名無しさん@お腹いっぱい。:01/11/26 16:02
>>457
職場で苛められてるのか?相談に乗るぞ。

460 :名無しさん@お腹いっぱい。:01/11/26 16:53
Javaでオブジェクト指向を学べというのは良く分かる
でもさコンピュータでプログラムを書く以上頭の中にメモリマップが
浮かぶのと浮かばないのは大きな違いだと思うんだよね
ポインタを理解したからってメモリマップが浮かばなければ全く
意味が無いと思う

461 :メモリマップなんて:01/11/26 17:02
全く浮かびません。逝ってきます。

462 :名無しさん@お腹いっぱい。:01/11/26 17:22
メモリマップが浮かばないという事はポインタを理解していないという事です。

463 :名無しさん@お腹いっぱい。:01/11/26 17:25
ポインタ=メモリアドレスという理解は誤りです。もう一度規格書を読みましょう。

464 :名無しさん@お腹いっぱい。:01/11/26 17:38
Java,Perl,C++,C

↑どれから極めるべきでしょうか?

465 :I is a hacker:01/11/26 17:55
>>464
「べき」というご質問には応えられませんが、ぼくの遍歴を披露します。
1. C でポインタに挫折したまま強引に C++ でオブジェクトを学ぶ
2. Perl は型宣言がないのでお気楽にスイスイコードを書きまくる。
3. Perl のリファレンス機能を学習して C のポインタの概念を理解する。
4. Perl でオブジェクト指向プログラミングを学習して、プログラムそのものの書き方を勉強しつつ
   C++ にカムバック
5. いつか Java やってみたい。

466 :名無しさん@お腹いっぱい。:01/11/26 17:55
そういうふうに迷う464はまずシェルスクリプトから・・・

467 :名無しさん@XEmacs:01/11/26 18:15
shell script ってむずくないかい?
UNIX の余計な知識が必要になって。。。
ってココは UNIX 板だから、いいのか。それもまた。

# って、 464 は極めてないだけで、全部そこそこできたりしてなぁ。。。

468 :名無しさん@お腹いっぱい。:01/11/26 18:50
自分が若いうちに必死に覚えた言語がもう古くなってしまってくやしいのは
わかるが、それ以降の新しい言語を否定するのは枯れたじじいになった証拠だ。
まあC使いに無理やりC++使わせても、クラスに「関数」をつめこんだ巨大なクラス
しか作らんからな。ガリガリ体力勝負のCでもかかせてあげよう。
しかしその体力は尊敬に値する。

469 :名無しさん@お腹いっぱい。:01/11/26 21:05
>>468
はげどう。

ちなみに、このスレのC++使いは1人ではない。
さらに、Cそのものを否定するC++使いは1人もいない(と思う)。
C++を否定する粘着C使いは2、3人いるようだな。
腹の中にたまった毒素をまき散らすのはやめれ。

470 :名無しさん@お腹いっぱい。:01/11/26 21:39
C++を否定しているレスってあるか?
俺にはCを否定する粘着質しか見えないが?

471 :名無しさん@お腹いっぱい。:01/11/26 21:47
C++?
ヴァカですか、あんな半端なもんやってるやつまだいるのぉ?

ま、いても仕事でしかたなくやってるやつだろよ。
そんなヘタレがでかい口たたくなや、なー(藁

472 :名無しさん@お腹いっぱい。:01/11/26 21:52
とすると半端でないのはC++以降の、たとえばJAVAなどが、
洗練されているということかい?

473 :名無しさん@お腹いっぱい。:01/11/26 21:57
半端じゃないのは Schemeだね。

誤解のないよういっとくけどアセは必須よ、一応ね。
アセのまえではCも半端ものね(藁

474 :名無しさん@お腹いっぱい。:01/11/26 22:08
>>471 サブイ

475 :名無しさん@お腹いっぱい。:01/11/26 22:11
言語もよく宗教戦争になるな...。
著しく不毛なのはわかってるはずなのに...。

476 :名無しさん@お腹いっぱい。:01/11/26 22:14
>>475
半端なやつほどこだわりがねーんだよな。
ひとことでいうとヘタレね(藁

477 :名無しさん@お腹いっぱい。:01/11/26 22:25
>>470
471を見ろ。ぼけ。

478 :名無しさん@お腹いっぱい。:01/11/26 22:34
>>477
だからサブイって

479 :名無しさん@お腹いっぱい。:01/11/26 22:44
>>478
過去ログもよく読んで字を書け。ぼけ。
日本の人じゃないのか?

480 :このスレって:01/11/26 23:19
糞スレですか?

481 :名無しさん@お腹いっぱい。:01/11/26 23:22
>>480
95% ぐらいは、ダメダメですな。一瞬だけ、まともなスレッドになりかけたけど。

482 :名無しさん@お腹いっぱい。 :01/11/27 02:29
大したスキルも無いのにCがあればいいだろとかいってるのもうみてらんない。

483 :名無しさん@お腹いっぱい。:01/11/27 05:16
C++マンセーな奴が出てきていっきに糞スレ化してるな。

Unixでは、C++はC以外のその他大勢の言語 (Ada、Fortran、Modula 3、
Objective C、Scheme…) よりは若干優勢程度の扱いだった。だから、
特定のプロジェクトでは使用しても、クラスプラットフォームを
ターゲットにした場合にはあまり使われてこなかっただけだろ。
現在ではC++人口の増加やコンパイラ、各種クラスライブラリの普及に
ともなってC++の使われる局面は増えてるみたいだけどね。

484 :名無しさん@お腹いっぱい。:01/11/27 08:55
>>446
「VC++ しか使えない」って、どういうプログラマなんだ? VC++ は単なる Win32 用の C/C++ コンパイラ
だから、ロジック部分は C/C++ で書くんだけど。

(確かに Hello World だけなら Wizard にお任せで作れるけど、その先は自分でコード書くしかないですぜ)

485 :名無しさん@お腹いっぱい。:01/11/27 15:56
「VC++しか使えない」ってどーゆー事か問い詰めたら
「MFCしか使えない」って事だったって事があったらしいです。
あれ?「VC++」じゃなくて「C++しか使えない」だったかも。

486 :名無しさん@お腹いっぱい。:01/11/27 16:19
漏れUNIXでしか開発した事無いからC++は使えるけどMFCは使えない
逝ったほうが良い?

487 :名無しさん@お腹いっぱい。:01/11/27 16:43
Windowsで開発しないんならMFC知らなくてもいいんじゃねーの?

488 :名無しさん@お腹いっぱい。:01/11/27 17:04
数値計算エンジン屋なんだよね
Windowsでも開発はするんだけどGUIは他の人が書く
こういう事ばっかりやってるとヤパーリ取り残される?

GUIはやってみたいとは思うけどMFCのメッセージマップがどうも
気持ち悪くてQtとかならいいな

オフトピックすまんsage

489 : :01/11/27 18:39
>>487
Windowsでの開発でもMFC知らないほうが幸せかもしれない・・・。

490 :名無しさん@お腹いっぱい。:01/11/27 19:20
>>489
おれは、さすがに数千行の WndProc のメンテナンスするのは嫌だ。。。

491 :本人さえよけりゃ何でもええと思うねんけど:01/11/27 23:37
Cも覚えて
Javaも一応出来て
アセンブリも冷や汗かきながら本見ながらだけど出来る
VBもこうなりゃ自白だ、「ドンと来いや」

な俺はどうすりゃいいの?

492 :名無しさん@お腹いっぱい。:01/11/27 23:42
>>491
そういう人には答えは見えてるでしょう。

でも
>Cも覚えて
はどうかと思う。(w

493 :コボちゃん:01/11/27 23:44
入りづらい雰囲気だよ、おじいちゃん。

494 :名無しさん@お腹いっぱい。:01/11/27 23:51
わたしの言語遍歴

仕事:VC++→C++→C→Java→現在に至る
趣味:VC++→C++→C→アセンブリ→Cとアセンブリ

趣味は深みにはまって行くぅぅ
電気の勉強をしに夜間大学院に逝きたい

495 :名無しさん@お腹いっぱい。:01/11/28 00:02
>>494
行き着く先は、ハード?

496 :名無しさん@お腹いっぱい。:01/11/28 00:17
そんなあなたにC++Builder
ゴロ悪いな

497 :名無しさん@お腹いっぱい。:01/11/28 00:18
あーここUNIX板だった
来年Linux版のC++Builderは出るらしいが

498 :名無しさん@お腹いっぱい。:01/11/28 01:17
>495
笑顔で黙々と16進を打ち込む変態に一票

499 :名無しさん@お腹いっぱい。:01/11/28 01:32
>>496
Borland C++ Builder は BCB と略されることが多いが。(@プログラム技術板)

500 :名無しさん@お腹いっぱい。:01/11/28 01:35
>>498
ディップスイッチで……(略)

501 :名無しさん@お腹いっぱい。:01/11/28 01:38
>>497
BCB じゃないが Intel C++ Compiler for Linux は出てるね。

http://developer.intel.com/software/products/compilers/c50/linux/

誰か使った人いる?

502 :名無しさん@お腹いっぱい。:01/11/28 01:57
C++Builder

CBill

ちびる

503 :名無しさん@お腹いっぱい。:01/11/28 11:54
>501
OpenSSLをソレでつくってみたら爆速でちょっと感動したが、よく
segvるw。C++に関係ないのでsage.

504 :名無しさん@お腹いっぱい。:01/11/28 15:32
少しさかのぼるが、UNIXで例外運用について統一ルールがないのは
C++ フレームワークが普及していないからでは?
MFCを使う場合はMFCの例外ルール(あるのかどうか疑わしいが)に
従わないとめちゃくちゃになるよね。

505 :名無しさん@お腹いっぱい。:01/11/28 15:45
っつかそーゆー意味では
C++って標準のI/Oクラスも無いって言えるかも…
みんなクラス内で fread()とかやってません?
俺だけ?

506 :名無しさん@お腹いっぱい。:01/11/28 21:24
だいぶずれるけど
C++でオブジェクトを確保したら
メモリ上にはどうやって格納されてるの?

507 :名無しさん@お腹いっぱい。:01/11/28 21:40
>>506
デバッガで遊んでみれば?

508 :名無しさん@お腹いっぱい。:01/11/28 23:07
>>505
iostream は微妙に使いづらいんだよね。俺も C++ だと #include <cstdio> だったり。

509 :名無しさん@お腹いっぱい。:01/11/29 00:36
>>506
主流の実装は二通りあるんだが、VC で使ってるやつだと

+-----------------
| vptr
+-----------------
| メンバ変数1
+-----------------
| メンバ変数2
+-----------------

って感じだ。vptr は vtbl (仮想関数へのポインタの配列) を指していて、これで多態を実現
している。

510 :名無しさん@お腹いっぱい。:01/11/29 11:55
さんくぅす。

511 :名無しさん@お腹いっぱい。:01/11/29 12:24
cout << "Hello, world!" << endl;
って、エラー処理をしていないのでまずいよね。

>>505, >>508
C++標準化の歴史を抜きにすれば、iostreamで、入出力エラー時に例外が
出ないのはどう考えてもおかしいと思うんだが。

ところで javaライブラリの C++化って行われてるのかな?

512 :名無しさん@お腹いっぱい。:01/11/29 15:20
Limbo、これ最強。

513 :名無しさん@お腹いっぱい。:01/11/29 20:56
>>511
エラーが出たところで

・どこまで出力されたか判別できない
・明示的にある時点まで巻き戻ることができない

という事情があるんだが?

514 :名無しさん@お腹いっぱい。:01/11/29 23:10
>>513
フィルタとして使う場合なんかはエラーが起きたら異常終了終了して欲しい。
そのエラーが回復不能だからといって、エラーを無視していいわけではないだろ。

515 :名無しさん@お腹いっぱい。:01/11/29 23:46
フィルタならstdio使え

向き不向きがあるんだよ

516 :名無しさん@お腹いっぱい。:01/11/30 03:01
>>511
ios_base::exceptions() で、問題が発生したときに例外を投げるように設定できます。

>>515
前半は完全に同意なんだけど、それにしても C++ の iostream って仕様がイマイチ
じゃない? operator<<(), operator>>() が最悪に近い演算子多重定義なのは目
をつむるとしても、

- 書式指定が面倒
- STL との連携もないし、ポインタが絡んだ場合のシリアライズのフレームワーク
 も提供していない

など、どうも仕様が中途半端な気がする。

517 :名無しさん@お腹いっぱい。:01/11/30 07:11
>>516
日本人が一枚かんでるんだから、そういぢめるな
iostreamの軽量版なら、俺も欲しい

518 :515:01/11/30 07:49
>>516
ワシもそう思う

519 :名無しさん@お腹いっぱい。:01/11/30 08:11
>>517
その「一枚かんでる」日本人って、誰?

520 :名無しさん@XEmacs:01/11/30 09:51
>>516
言語仕様がようやく固まってきたから、次はライブラリーだー!

521 :名無しさん@お腹いっぱい。:01/11/30 10:18
はやく時代遅れになってくんないかなあ > C++

522 :名無しさん@お腹いっぱい。:01/11/30 10:37
C++の仕様は大好きです。
でも、スレッドとかネットワークとか、Java並(?)の簡単ライブラリは作らないんでしょうかね。

523 :名無しさん@お腹いっぱい。:01/11/30 23:19
今は亡きOOCのJTread/C++なんてのは?

524 :名無しさん@お腹いっぱい。:01/12/05 21:24
>>517 ねえねえ、その一枚かんでる日本人て誰なん? じらさんといて。

525 :Kusakabe Youichi:01/12/15 21:43
In article >>521, 名無しさん@お腹いっぱい。/521 wrote:

> はやく時代遅れになってくんないかなあ > C++

あなたが時代遅れです。

526 ::01/12/15 22:25
0chだって。
http://medetai.kakiko.com/0ch

527 :名無しさん@お腹いっぱい。:01/12/16 02:03
やっぱ UNIX って遅れてるよ

528 :名無しさん@お腹いっぱい。:01/12/16 02:07
>>526
クリックしちまった

529 :名無しさん@お腹いっぱい。:01/12/16 02:47
僕はひさしぶりにUNIXの仕事をしました。
まるで時代が戻ったような感じでした。
UNIXしかしらない人がいたら、それはやばいですよ。

530 :名無しさん@お腹いっぱい。:01/12/16 03:01
KDEが遅いのはC++のせいかも。
でもあれだけ大きいソフトはC++でないと作れなかったかも。

531 :名無しさん@お腹いっぱい。:01/12/16 03:06
UNIXってGUIにしてもWindowsと同じレベルのことすると
Windowsより重いよね。

532 :名無しさん@お腹いっぱい。:01/12/16 03:19
そうだなぁ。Windows のように Widget も統一されてないしね。
まぁそれが Unix の良さなんだが。
気が済むまで自分で自分のスタイルを作ることができるという。
しかし、GUI と CUI は対立関係にあるわけじゃないし補完すればよいから
GUI で Windows と同じレベルのことをしたきゃ俺は素直に Windows 使うけど。

533 :名無しさん@お腹いっぱい。:01/12/16 03:27
>>529
うーんと、言語ではなくて、フレームワークのことがいいたいのかしら?
DCOMとかATLみたいなものがほしいの?

私もやばいのかしら?入社してから2年半UNIXばっか。
言語はC,Java,C++,Ruby,Perl,Scheme,Lisp,Prolog,Fortranは書けるよ。
仕事でつかうのは、C,Java,Perl,Rubyで、ちょぴっとC++だよ。

534 :名無しさん@お腹いっぱい。:01/12/16 12:50
.NETが普及してC++を書けないWindowsプログラマが大量生産されますように

535 :名無しさん@お腹いっぱい。:01/12/16 13:00
すでにVBでうんこしか作れない自称“プログラマ”が大漁ですが何か?

536 :名無しさん@お腹いっぱい。:01/12/16 14:53
C#はいいぞ

537 :名無しさん@お腹いっぱい。:01/12/16 14:59
Mono
DotGNU

538 :名無しさん@お腹いっぱい。:01/12/16 19:03
>>535
うんことはいえVB使ってる時点であなたもオブジェクト指向プログラマ。
C++で組んでる大半のやつらよりね。
C++は単にクラス設計とか継承とかを手動でやれるってだけだ。
だからoop理解してないうんこがC++使ってもうんこはうんこ。
VBみたいな組んでる本人がoopを理解してなくてもoopやってるってのが理想と思うな。
俺もCの次にすぐにC++やったけど今思うとホント臭いうんこだった。
VBみたいな完成されたクラス設計見て初めてoopがなんたるかを知ったよ。
もちろんVBの設計が完璧とは思わないが。
VBやったあと再びC++やって、だいぶoopらしくなったと思ったが最近やっぱまだまだだと気づいた。

539 :名無しさん@お腹いっぱい。:01/12/16 19:15
10点。
うんこがなければ25点。

540 :名無しさん@XEmacs:01/12/16 20:28
>>538
> VBやったあと再びC++やって、だいぶoopらしくなったと思ったが最近やっぱまだまだだと気づいた。

どうせ、C++ってVC++だけのことなんでしょ。

541 :538:01/12/16 22:27
>>540
ちゃうよ。ってかGUIのプログラムを作ってるわけじゃないんで。
ほとんどDOS上で作ってるのとかわらん状況・・・

542 :名無しさん@お腹いっぱい。:01/12/16 23:37
>538

たんに、あんたがC++をつかいこなせてないだけの話だろ。
はずかしいやつだな。

543 :名無しさん@お腹いっぱい。:01/12/16 23:50
VBをうんことい奴が多いが、その中核にあるCOMの技術を
よく勉強しなさい。
たしかにうんこは多いが。

544 :名無しさん@お腹いっぱい。:01/12/16 23:53
>>543
うんこといってナニ?

545 :名無しさん@お腹いっぱい。:01/12/17 00:07
>544

君のことだよ。うんことい君。

546 :名無しさん@お腹いっぱい。:01/12/17 00:42

> 君のことだよ。うんことい君。
>
VBは初心者向け言語です。

547 :名無しさん@お腹いっぱい。:01/12/17 00:47
だからうんこは多いって言ってるでしょ

548 :なまお:01/12/17 00:59

うちの会社の場合、UNIX の仕事では、C++ は GUI まわり
だけは使います。後は C です。

C++ は、設計が悪いと、記憶力が良い人にしか読めない
コードになり、メンテナンスが辛くなりますが、

C だったら、どんなバカな奴でもプログラム読めますからね。

549 :名無しさん@お腹いっぱい。:01/12/17 03:11
>>548
> C だったら、どんなバカな奴でもプログラム読めますからね。
だが、メンテナンスは不可能だったりするぞ。関数数千行でグローバル変数使いまくり、
なぞの switch - case や if - else 大量でロジックこんがらがってると、さすがに手に
負えん。

C++ で、なんでもかんでも多重継承してるプログラムも手に負えないけど。

550 :名無しさん@お腹いっぱい。:01/12/17 03:12
>>543
> その中核にあるCOMの技術
それ VC++ で勉強した方がいいと思われ。使うだけなら VB が便利だけど、仕組みは
C++ 知らんと理解不能だろ。

551 :名無しさん@お腹いっぱい。:01/12/17 07:37
>>549
> だが、メンテナンスは不可能だったりするぞ。関数数千行でグローバル変数使いまくり、
> なぞの switch - case や if - else 大量でロジックこんがらがってると、さすがに手に
> 負えん。

それはCかC++かの問題じゃないし

552 :名無しさん@お腹いっぱい。:01/12/17 14:50
>>551
そのとおり。

何の言語を使わせようが、ダメなヤツはダメ。

553 :名無しさん@XEmacs:01/12/18 00:51
>>543
> その中核にあるCOMの技術をよく勉強しなさい。

これが、

>>538
> VBやったあと再びC++やって、だいぶoopらしくなったと思ったが最近やっぱまだまだだと気づいた。

これとどう繋がるの?

554 :名無しさん@お腹いっぱい。:01/12/18 01:13
COMねぇ。VBから使う分には楽ちんでいいけど、あんなもん作る方にまわり
たくないよ。特にC/C++でCOMって、言語制約から来るお約束事項が多すぎ。
ソースもMFC以上にマクロだらけでウザいし、レジストリいかれるとバイナリ
そこにあっても動かなくなるし。趣味ならともかく仕事でやるとげっそり。
ちーとも面白くない。

今だったら、VBでIEコンポーネント貼り付けてブラウザもどき作って
「ほーこりゃ便利だのー」って遊ぶ位にしといた方がいいと思われ。
C#ちゃんとリリースされたら(C#のclassはCOMオブジェクトになるという
事なので)本格的にやってみてもいいかもね。
# まぁ最初はCLRとか安定しないんだろうけど

555 :名無しさん@お腹いっぱい。:01/12/18 09:53
どうやらプログラム技術板から流れてきたやつがいるな…

556 :名無しさん@お腹いっぱい。:01/12/18 17:25
>>553
単なる電波だ。相手にするだけ時間の無駄と思われ。

>>555
流れてきたというか、単に UNIX, Win32 掛け持ちのプログラマが少なくないだけだと思われ。
仕事で両方やってる人もいるし、仕事は Win32 でも UNIX のバックグラウンドがある人は多
いんじゃないかなぁ。

それはそれとして、板違いな書き込みは sage で頼みたいが。

557 :名無しさん@お腹いっぱい。:01/12/26 13:23
C++の話をしよう。
そもそも、ストラウストラップ先生がだ。。。(以下略)

558 :名無しさん@お腹いっぱい。:01/12/26 13:47
>>548
本物の「なまお」ちゃんかい?

559 :名無しさん@お腹いっぱい。:01/12/26 17:06
>>552
禿同
結合度を弱く強度を強くするとか、階層をむやみに深くしないとか、
そういったテクニックは、言語は関係ないことが多いものね。
ま、不向きな言語も無いとはいえないけど。

560 :名無しさん@お腹いっぱい。:01/12/26 17:31
>>538
VBってオブジェクト指向だったの??いつからそうなったの?
マジで時代遅れか。打つだ氏脳。
スレ違いなのでsage

561 :名無しさん@XEmacs:02/01/04 23:21
>557
simula から始めてくれ

562 :名無しさん@お腹いっぱい。:02/01/05 09:27
>>554
「VBから使う分には楽ちんでいいけど」が全てだ。
C++プログラマは血反吐を吐け。

…と言う悟りを開きました。

563 :名無しさん@お腹いっぱい。:02/01/18 02:18
>>560
いちおうクラスつくれるよ


564 :名無しさん@お腹いっぱい。:02/01/18 03:37
>>563
Javaで言うinterfaceも作れるよん。しかもVB5から。
まぁ派生できないからいまいちなんだけど。

565 : :02/01/19 13:04
お前ら、勘違いスンナよ。プログラムで飯を食ってることが既に負け組みなんだよ。

566 :名無しさん@お腹いっぱい。:02/01/19 13:28
勝ち組は何で飯を食うの?


567 :名無しさん@お腹いっぱい。:02/01/19 13:33
>>566
コン猿


568 :名無しさん@お腹いっぱい。:02/01/19 13:53
確かに、PGってSEや紺猿が所有する兵隊だよね

569 :名無しさん@お腹いっぱい。:02/01/19 14:09
でも、コード書けなきゃ生きてる意味ないし。

570 :田代まさし:02/01/19 14:17
1<<
C++を「本当に」理解しているなら、Cが嫌だなんて思わないはず。
C++を使っているというより、MFCがないとソフトが組めないだけじゃない?


571 :名無しさん@お腹いっぱい。:02/01/19 15:06
コード組めてもいつかはソフトもPGも陳腐化する宿命。
PGからSEへ上れないと、結局使い捨て。
すべてのPGがSEになんかなれなから、大半のPGは使い捨て。
脳みその切り売りsage

572 :名無しさん@お腹いっぱい。:02/01/19 15:07
PGなんかでいい気になっていると、足元すくわれるぞ

573 :名無しさん@お腹いっぱい。:02/01/19 15:13
考えてもみろよ。50過ぎてたときに、20そこそこの若造と同じPGじゃやってられないだろ。
そもそもこの業界、50過ぎまでまともに働ける奴がどのくらいいるかなんてわからんけどな

574 :名無しさん@お腹いっぱい。:02/01/19 15:49
つうか、コード書くのいやなら、書ける奴に命令してみれば?
「俺はSE様だ、PGなんてやってらんねえんだよ、設計したからお前らこのとおりに作れ。」


575 :名無しさん@お腹いっぱい。:02/01/19 16:10
まともなC++のコード書けるプログラマ、ほしいなあ…

576 :名無しさん@お腹いっぱい。:02/01/19 16:27
俺はperl気分でC++使ってますが何か?


577 :名無しさん@お腹いっぱい。:02/01/19 16:48
>>570
MFCなんざ逝ってよしですがSTLがないと生きていけません。
というか未だにSTLを使わない奴の気が知れない。

578 :名無しさん@お腹いっぱい。:02/01/19 23:56
C++ の class template は便利だ。
STL とこれだけで C++ 使う価値あると思うのだが。
# jdk(java)1.5 にも class template が採用されるとかされないとか。

579 : :02/01/20 19:14
c++でなんかいいtoolない?

580 :名無しさん@お腹いっぱい。:02/01/20 19:24
>578
># jdk(java)1.5 にも class template が採用されるとかされないとか。
今更何イッテンダカ。。


581 :名無しさん@お腹いっぱい。:02/01/20 20:48
javaのGenericsは、メタプログラムの観点からみると、今ひとつ。

582 :名無しさん@お腹いっぱい。:02/01/20 23:21
>579
C++で作られてるなんかいいtool
なのか,
C++で開発する上でなんかいいtool
のどっちをお探し?

まぁ漏れはどっちもあんま知らねーけど.


583 :名無しさん@お腹いっぱい。:02/01/24 16:49
こんどC++の仕事入ったよ。まんせ。

584 :名無しさん@お腹いっぱい。:02/01/24 16:51
まだこのスレあったのか・・・・
C++なんか使うなボケェ

585 :名無しさん@お腹いっぱい。:02/01/24 17:11
現代のコボラーってやつか。しつこいぞ。

586 :名無しさん@お腹いっぱい。:02/01/24 19:08
template使った奴ってやたらビルド時間かかるんですけど......
やぱり今時のプログラマはそんな事を気にせず富豪になるべきなのでしょうか。


587 :名無しさん@お腹いっぱい。:02/01/24 19:21
吉祥寺にある大検・大学受験予備校の中央高等学院
ここは、完全に狂ってる。
授業料は一年分一括前払いなので、
金が入れば、生徒は要らない
金を振り込んだら、何とかその生徒を辞めさせようと
講師どもが、あの手、この手でイヤガラセをしてきますね。
セクハラはもちろん、脈絡の無い罵倒は日常茶飯だね。
酒臭い講師もいるし・・・ 人生の最果て中央高等学院
学歴詐称、経歴詐称、合格実績詐称、デタラメ授業、
http://www.chuo-school.ac/

http://chs-f.com/index.html 中央高等学院福岡校
司法浪人の田中校長は ↑ また司法試験に落ちましたが
HP上では下らない見栄を張っています


588 :名無しさん@お腹いっぱい。 :02/01/24 19:45
>>586
テンプレート使って楽した分、
コンパイルの回数を減らせばいいだけだろ

589 :名無しさん@お腹いっぱい。:02/01/24 20:12
テンプレートでビルドに時間かかる?
あまり感じたことはなかったけど、田の人もそうなの?

590 :名無しさん@お腹いっぱい。:02/01/24 23:11
>>589
VC6 だけど、

1) ほとんど素の C に近い C++ のコード
  (ただし DirectX 使ってるから、DirectX のインターフェース周りは C++ の構文使う)
2) ATL/WTL, STL など template ライブラリ多用したコード
  設計も完全に OO 流儀、例外も多用

だと、かなり差が出てます。似たようなサイズのプロジェクトがあったから、フルビルドに要した
時間を計ってみました。

環境
 Pentium III-M 800MHz + RAM 384MB, Windows 2000 SP2 + VS6 SP5 + STLport 4.51
 最適化レベル O1 (サイズ優先)
 フルビルド
 プリコンパイルヘッダを使用(プリコンパイルヘッダの作成時間もビルド時間に含める)

結果
 1 ほとんど素の C に近いコード
  総ソースコード 11370 行、315,669 バイト
  7 秒

 2 template 多用したコード
  総ソースコード 10879 行、267,555 バイト
  97秒

1, 2 でソースコードの中身が全く違う代物なんで単純に比較はできないけど、一例ということで。

591 :名無しさん@お腹いっぱい。:02/01/25 00:41
template libraryは本体がヘッダだから
プリコンパイルできないと、ライブラリを毎回コンパイルしなおしてるような
もんなんだよね…
gccのプリコンパイル対応はいつになるんだろうか。

あとtemplate使うと、エラーメッセージが難読になるのも問題ね。

STLに関してはScott Meyers先生のEffective STLっていう良書があるんだけれど
これの邦訳もいつになるんだろうか…

592 :589:02/01/25 04:38
>>591
template 使った場合は、プリコンパイルしてても

 「毎回コンパイルしなおし」

に近い状況になるよ。型が確定して初めて構文解析できるわけだから。トークン列までは
template 見た段階で解析できるけど、たとえば引数で渡された型 T の変数 a に対して

 a.foo();

とか書いてある場合、ほんとに foo がメソッドかどうかは T を見ないと分からん(他にもグ
ローバルな名前空間にある変数とか typedef とかも)。

どう実装するかは幅があるけど、文献を読んだ感じだと、テンプレート定義が出てきた段階
では字句解析と構文解析を少々で止めておいて、テンプレートをインスタンス化するときに
個別に構文解析しなおすのが一般的みたい。

VC6 のプリコンパイルヘッダの詳細は分からんけど、STL はプリコンパイルしてもしなく
ても、あまり速度が変わらなかったと思う。

>  2 template 多用したコード
>  総ソースコード 10879 行、267,555 バイト
>  97秒
コンパイルオプションを /O1 (速度優先) から /O2 (実行サイズ優先) に変えて、リンクす
るランタイムライブラリを DLL からスタティックリンクにしたら 27 秒まで短縮された。

593 :589:02/01/25 23:24
マジレスありがとう。>>590 >>591 >>592
590の1)と2)のコードってすごそう。

594 :名無しさん@お腹いっぱい。:02/01/26 17:09

> a.foo();
>
>とか書いてある場合、ほんとに foo がメソッドかどうかは T を見ないと分からん(他にもグ
>ローバルな名前空間にある変数とか typedef とかも)。

gcc2.95付属のstlで見ただけだけど、
#include <algolithm>
で定義されるtemplate(たとえばsort)見てマジで感動しました。
Cだと型独立に定義しようとしたらマクロで小細工しないといけないようなことを
C++のテンプレート使ってやってるんだね。
ただなぁ、デフォルトでドキュメントが付いてこないのがなぁ。

595 :590:02/01/26 18:24
>>593
> 590の1)と2)のコードってすごそう。
いや 1 は ttp://www1.odn.ne.jp/giggle/hotate/frame.htm から拾ってきた
シューティングゲームのソースに手を入れてプリコンパイルヘッダを使うよう
にしただけ。

2 は自分で書いたコードだから、見たければあげますが。

>>594
私は MSDN Library と SGI STL のドキュメントを使ってます。

SGI STL
Index: The Standard Template Library
http://www.sgi.com/tech/stl/stl_index_cat.html

ダウンロードページにアーカイブがおいてあるから、手元に持ってきておくと
良いかと。時間と気合があれば C++ 標準ライブラリの roff 版ドキュメントを
作りたいところだけど。できれば

% man for_each

とかでマニュアル読みたいよね。

596 :名無しさん@お腹いっぱい。:02/01/26 18:36
>590
うぷきぼんぬ

597 :名無しさん@お腹いっぱい。:02/01/26 22:06
>>596
http://members.tripod.co.jp/lambda_func/

ついでに、思い切り template を使って、実質的に翻訳単位をひとつに
まとめてしまったソースも置いときます。

フルビルドに要する時間や、実行ファイルのサイズ、新規にメソッドを追
加する際の手間なんかを見ると、翻訳単位一つにして、ヘッダにコードを
書いたほうが効率が良いみたい。

代わりに

- 「常にフルビルド」状態になる
- バイナリ互換性が容易に崩れる
- 前方宣言を避けるために template を巧妙に利用すると、ヘッダ順序の
 制約が厳しくなる。

というデメリットもあるから、規模が大きくなると泣くと思うけど。

598 :596:02/01/26 23:19
>597
ガ━━(゚Д゚;)━━ソ!
Unix 系じゃ動かんのね,
良く見たら
> ATL/WTL
って書いてあるのか・・・

一応アリガト.WTL 使う機会があったら参考にさせて頂くかもですm(_ _)m

599 :名無しさん@お腹いっぱい。:02/01/26 23:30
>>598
最初から Visual C++ 6.0 だと言ってるのに(苦笑)

そこそこ MI/MD 分離した設計になってるから、MD 部分だけ手を入れれば X でも
動くかもしれません。とりあえず GDI, DirectDraw7 両対応にはなってますし。
(私は X プログラミングは知らないので無理)

600 :名無しさん@お腹いっぱい。:02/01/27 04:03
ここの人はC++で仕事するときはどんなライブラリを使ってるの?
自作?それなら結構。羨ましいです。
それ以外の人は結構大変ですよね?仕事の度に違うライブラリと付き合わなくては
ならないのは。Windowsな人はひとつのライブラリだけでいいから、そういった
意味では楽ですね。
今はネットワーク系のよいフリーのライブラリを探しているのですが、
ACEのようなでかい規模のものではなくてもっと小さいものがあればそれを使い
たいなと思います。

何かいいものはありますか?

601 :名無しさん@お腹いっぱい。:02/01/27 14:57
gcc な STL 使っとけや。

602 :名無しさん@お腹いっぱい。:02/01/27 15:42
>>601
STL にネットワーク関係のライブラリは規定されてないだろ。

603 :名無しさん@お腹いっぱい。:02/01/27 22:07
>>600
俺も同じ質問す。
でも、ACEって最近名前を聞いただけの「素人」です。
ACEはどのくらい認知されてるんでしょう?
600氏が避けるような理由があるのでしょうか?
ACEを勉強しようかどうしようか迷ってるんです。
教えていただければ幸いです。

604 :名無しさん@お腹いっぱい。:02/01/28 01:50
>>603
今度仕事で評価を兼ねて使うことが決まってるから、
その結果を待て!

605 :名無しさん@お腹いっぱい。:02/01/28 01:57
>604
600 でも 603 でも無いけど期待age!!
ちなみにいつ頃になりますか?

606 :名無しさん@お腹いっぱい。:02/01/28 02:02
来週末までにプロトタイプと報告書をまとめることになってる。
それをここに書き込むよ。

607 :605:02/01/28 02:07
>606殿
うぉー!超,超,超ぉ〜期待しております!!!
お仕事頑張って下さい!!

608 :603:02/01/28 21:27
603です。
>>604 >>606
うあ。ありがとうございます。よろしくお願いします。
期待しまくりです。
>>607と同じ気持ちです。605氏にも感謝!)


609 :名無しさん@お腹いっぱい。:02/02/01 00:24
GNU common C++
http://www.gnu.org/software/commonc++/commonc++.html
ってどーよ?

と思ったら1.9.5コンパイル通らねーし!!
とりあえず1.9.4をいぢってみるかのぅ・・・

610 :名無しさん@XEmacs:02/02/01 01:29
>>591
Effective STL 邦訳出てたよ。
>>600
qtはどうでしょうか?でかすぎ?趣味で使うにはとても便利です。

611 :609:02/02/01 01:30
しまった.gcc-3.0.3 だとコンパイル通らんらしいけど 2.95.3
だったら逝けた.鬱氏.
さてイヂってみるかな・・・


612 :名無しさん@お腹いっぱい。:02/02/01 01:57
Qtマンセー

613 :名無しさん@お腹いっぱい。:02/02/05 01:50
gtk-- ってどうなのよ?

614 :北京 ◆5rr1Eed6 :02/02/07 00:11
全角英字使うな。これだからウィナーは。

615 : :02/02/07 00:51
>614
誤爆?

616 :!= 591:02/02/07 03:37
>>610
亀レスだが、Effective STLの情報ありがとう

617 :603:02/02/08 13:23
>>606
どうなったでしょうか。お待ちしております。

618 :名無しさん@お腹いっぱい。:02/02/17 16:10
>>606
死んだか?

619 :名無しさん@お腹いっぱい。:02/02/17 21:41
死者をむち打つようなことをすな。

620 :名無しさん@お腹いっぱい。:02/03/16 21:56
age

621 :名無しさん@お腹いっぱい。:02/03/16 21:57
Lokiマンセー


622 :名無しさん@お腹いっぱい。:02/03/16 23:46
C++をあまり使わないのは、実績と信頼性で不安だから
ですかね?

C++を使うとコーディングが楽だけど、CでもC++っぽい
プログラミングは出来る。クラスの表現だって出来る
からな。




623 :名無しさん@お腹いっぱい。:02/03/17 01:06
徒歩だって東京から大阪までいけるんだYO!とかなんとか主張する消防が集うって
スレはここですか?


624 :名無しさん@お腹いっぱい。:02/03/17 09:59
C++が使われないのは、UNIXがC文化の産物だからじゃないかな。

UNIXでは、小さなツールを組み合わせ、ありもんで済まない部分はスクリプトを書く
ことが多い。
問題を分割してしまえば、オブジェクト指向言語のメリットは相対的に小さくなる。

portabilityもCの方が有利。ANSI Cライブラリは絶対どこにでもあるけど、
STLはどんな実装があるかわからない。

securityを重視する局面で、C++を使うのも適切ではない。
root権限で動くプログラムを書くなら、パラノイアでなければならないから。
djbはlibcですら信用できないと考えている。
C++は、プログラマが書いた以外に、コンパイラが大量の暗黙のコードを追加するのに
できるバイナリがsecureだと保証するのは容易ではない。

Cで書けるところはCで、スクリプトで書けるところはスクリプトで…と考えて
いくと、当然、C++の出番は少なくなるよ。


625 :名無しさん@お腹いっぱい。:02/03/17 10:53
>>624
でも、そこらのサーバプログラムのsecurity holeって
C++でちゃんと組めば出て来にくいものだろ。

626 :名無しさん@お腹いっぱい。:02/03/17 11:03
>625
たしかにクラスでカプセル化できれば、オブジェクトに対する操作を
安全なものに限定し易くなる。
でもそれは補助でしかない。
結局は、地道にコードをレビューして、危険性を取り除くしかない。

そしてC++で書かれたコードのレビューは悪夢だ。


627 :名無しさん@お腹いっぱい。:02/03/17 11:08
>>625
「ちゃんと組む」というのが言語によらず最も難しいと思われる。


628 :名無しさん@お腹いっぱい。:02/03/17 11:40

ちゃんと設計出来ない奴がいい加減に組むと、
Cより始末悪いな。C++のソースは。

だから VC++ のデバッガは強力なんだな。

Cだとデバッガいらないもんな。




629 :名無しさん@お腹いっぱい。:02/03/17 14:37
>>625
バッファオーバーフローだの、二回 free() 問題なんかは、string, vector や
auto_ptr を使うと発生頻度はかなり下がるよな。

630 :名無しさん@お腹いっぱい。:02/03/17 14:38
>>628
> Cだとデバッガいらないもんな。
ddb ラブラブですが、何か?

631 :名無しさん@お腹いっぱい。:02/03/17 14:46
>>624
> C++は、プログラマが書いた以外に、コンパイラが大量の暗黙のコード
> を追加する
確かに temporary object や synthesize constructor/destructor など、
いろいろコンパイラが追加するが、それとセキュリティホールとは直接
は関係ない。その挙動は、まっとうなプログラマなら分かってるはずだ
し。(C 言語でも libc やスタートアップライブラリを信用しないっつーの
は、さすがに djb 一派ぐらいなものだ)

C++ で保証しにくいのは、

- temporary object にからんで、スタック消費が増える可能性がある
- 例外を投げた場合など、自動変数として確保されているインスタンスの
 解放が発生するが、このコストが分かりづらい。特に、厳しい時間制約
 がある場合には問題になりうる。

っつーあたりじゃないのか。

> Cで書けるところはCで、スクリプトで書けるところはスクリプトで…と考えて
> いくと、当然、C++の出番は少なくなるよ。
C++ でかけるところは C++ で、だと C の出番が少なくなると思われ。

ただコンパイラ/ライブラリの互換性の問題は、確かにあるよな。そろそろ
ANSI C++ に相当程度対応したコンパイラも増えてきたから、今後の見通し
は明るいと思うけど。

Visual C++ も VC7 (VC++.net) になって大分マシになったし、gcc も 3.0 系列
で改善された。

632 :631:02/03/17 14:48
s/スタートアップライブラリ/スタートアップルーチン/

crt0.o みたいな、プロセス実行から main 呼ばれるまでに実行される
プログラムの事ね。

633 :名無しさん@お腹いっぱい。:02/03/17 18:56
方程式の有用性を知らない人間が鶴亀算の素晴らしさを熱く語るようなものだな。
いつも思うことではあるが。


634 :名無しさん@お腹いっぱい。:02/03/17 19:41
>>633

あなたはチームで仕事していない人じゃない?

自分が組むなら C++ は良いけど、レベル低い奴の C++
ソースってホントに困るぞ。2ヵ月で作って10年使おう
と思ったら、Cが無難。


635 :名無しさん@お腹いっぱい。:02/03/17 19:46
>>634
レベル低いやつの C はそれ以上に困りますが、何か?

636 :633:02/03/17 19:53
チームで仕事もしますが、大抵自分ら小人数でC++(事情によりまれにC)でコアな
部分を作成し、皆様には既存あるいは独自のスクリプト言語で他の部分を書いて貰
うことが多いです。

634,635にも同意ですが、楽をできる言語を知っている人間まで、そうでない人間
に引きずられるのは御免被りたいという感じですかね。


637 :名無しさん@お腹いっぱい。:02/03/17 20:11
>>634
そうやって、使えないプログラマが書いたソースを後でメンテナンスさせられた
ことがある人間として。

 バカにはコードを書かせるな
 責任もって教育して、それから使ってくれ

いやほんとに(;_;)

638 :名無しさん@お腹いっぱい。:02/03/17 20:28
c++を使わせるとバカがカプセル化されるから良いかも(^^

639 :名無しさん@お腹いっぱい。:02/03/17 20:44
レベル低い奴のソースは言語がなんであってもひどい。これ定説。
# どうしてあそこまで糞なコードが書けるのか、ある意味感心はするがな。

>>638
大甘。「カプセル化」という言葉すら知らないんだぞ。
コンストラクタでグローバルのnewやってたりするんだぞ。
手に負えないっつーの。

640 :名無しさん@お腹いっぱい。:02/03/17 20:51
チャチャだけど.. 639は
ヘボプログラマにかなり泣かされているね(^^
それともヘボプログラマを泣かせている方かな?

641 :名無しさん@お腹いっぱい。:02/03/17 21:05
>>639
深い深い条件分岐のネストとか、その中でグローバル変数を設定とかな。
バグが取れないと泣きつかれたんだけど、どうにもソースが解析できずに、
捨てて作り直したことがあるよ。

C++ でもグローバル変数をバリバリ使われたら手におえん。

642 :名無しさん@お腹いっぱい。:02/03/17 21:08
デストラクタきらい。
Java = C++--

643 :名無しさん@お腹いっぱい。:02/03/17 21:12
WindowsのC++のソースを、 :: を __ にawkで置換してからUNIXのCに移植し
てるCジジイを見た時には寒気がしたけどな。もうね、アホかと。動くのかと。

static int m_foo = xxx;
void CFoo__CFoo(void)
{
m_foo = 100;
}

...


644 :643:02/03/17 21:13
動きませんでした。


645 :名無しさん@お腹いっぱい。:02/03/17 21:31
それ以前にコンパイラ通らんと思うんだが...
ちくちくとコンパイルエラー潰したんか?


646 :643:02/03/17 21:34
>>645
yes.
互換ライブラリをCで書いてなw


647 :名無しさん@お腹いっぱい。:02/03/17 21:40
もっと真っ当な手はなかったのかな
g++ つかうとか、Sun なら forte 使うとか(俺はforteは使ったことないけど^^;;)


648 :名無しさん@お腹いっぱい。:02/03/17 21:43
C++が書けないんだろ




649 :名無しさん@お腹いっぱい。:02/03/17 21:49
つうか、 Windows からの移植なら、c++ 以前の問題として、
WindowsAPIべったりの記述をどうにかするほうが大問題だと思うが。
(まあ、処理の内容によるけど)

650 :名無しさん@お腹いっぱい。:02/03/18 21:33
>>649
そこはどうにかなったんだよ。でも、643のようなインスタンスの概念のない
Cのソースコードに落としてしまったらWindowsのメッセージングベースのプ
ログラムの構造をうまく表現できなくて沈没。
ってこんなこと、当然すぎて書くのも馬鹿馬鹿しいんだけどさ。C-dog には
わからないんだよ。



651 :名無しさん@お腹いっぱい。:02/03/23 03:38
age

652 :名無しさん@お腹いっぱい。:02/03/23 11:06
結局使わないんじゃなくて、使うスキルがないっていうこと。

メインフレームのオヤジPGがCOBOLしか使えないように、
UNIXのオヤジPGがCしか使えない、
ということだ。リストラ覚悟しとけ>該当者

653 :名無しさん@お腹いっぱい。:02/03/23 11:47
アプリケーションプログラマはC++が万能だと思えるかもしれないが
C++を「使わない」シチュエーションもあるわな。
いざとなりゃアセンブラだって使うわな。
適材適所でイインジャネーノ?

654 :名無しさん@お腹いっぱい。:02/03/23 11:49
>>652
言語習得するのって、そんなに難しいかぁ?
まあ実績作るのは大変だけど。


655 :名無しさん@お腹いっぱい。:02/03/23 11:56
C++はシンドイと思う。
例外安全からデフォルトコンストラクタの挙動からなにから、
枝葉末節まで把握してないと
なあなあではまともなプログラムが書けない。
さらにオブジェクト指向分析・設計のスキル、クラスライブラリ等々
きりがない。

656 :名無しさん@お腹いっぱい。:02/03/23 12:29
>>654
> 言語習得するのって、そんなに難しいかぁ?
わりと。

俺も最初は C++ の入門書をざっと読んで、

 なんだ構造体が拡張されてるぐらいじゃん

とか思っていたが、Effective C++ 読んで衝撃を喰らって、More Effective C++,
Exceptional C++ を読んで

 全然分かってなかったのね、俺

と反省しきり。その後も Generic Programming やらデザインパターンやら、日々
これ勉強ですよ。

657 :名無しさん@お腹いっぱい。:02/03/23 12:50
>適材適所でイインジャネーノ?

全くその通りで誰も全部C++にしろとは言っていない。いろんな言語や開発手法、
新しい技術に臨機応変に対応できるスキルが求められる中、UNIXならCとshとawkだけで
十分、みたいになっていくオヤジはリストラまっしぐら、ということだ。>該当者

658 :名無しさん@お腹いっぱい。:02/03/23 17:51
オヤジはCGIもCとshとawkだけで書いたりするらしいね。


659 :名無しさん@XEmacs:02/03/23 18:17
まあ、C++自体ようやく仕様が固まったから、これからでしょう。

660 :名無しさん@お腹いっぱい。:02/03/23 18:32
C++って器用貧乏だよね。

それに分厚い言語仕様の本を抱えて仕事しなきゃならん
なんて、辞書もって外国語の会話するようなものじゃん。
悪い言語だとは思わないけど、なんとなくケチつけたくはなるな。

>>656
おれはC++使い始めて1年ぐらいになるけど、やっぱり大変だよ。
日々勉強に同意。いつになったら楽させてもらえるんだろう、、

661 :名無しさん@お腹いっぱい。:02/03/23 18:55
>>658
すまん。sh+javaでcgi書いた事ある(w
# もちろん自分しか使わないでっちあげcgiだけど

662 :名無しさん@お腹いっぱい。:02/03/23 19:10
各論賛成、総論反対って感じの言語だな >>C++
おれも、いまやってるプロジェクトを C++で全部書き直したら
楽になるなあ、とか夢想をするけど、
きっと知らなかった言語仕様の部分とかでつまづくんだろうなあ...


663 :名無しさん@お腹いっぱい。:02/03/23 19:23
>>659
>ようやく仕様が固まったから
西暦何年何月?



664 :名無しさん@お腹いっぱい。:02/03/23 19:34
C と C++ を比較して、バグの収束率とか開発効率とかの
調査って、どっかの大学の先生とかやってないのかなぁ?

665 :名無しさん@お腹いっぱい。:02/03/23 19:37
>>662
バグ入れちゃったときが大変だよね。
こう間違えたので、C++ではこのように動いて、
ここを直したから、これで大丈夫です。
という説明するために、言語仕様ひっかきまわし(w

666 :仕様書無しさん:02/03/23 19:50
便利な部分だけつかえばいいのさ:)


667 :名無しさん@お腹いっぱい。:02/03/23 19:58
機能の全てを使い切りたいという止み難い衝動に駆られるから無理です

668 :名無しさん@お腹いっぱい。:02/03/23 20:04
ていうかvector使うだけでパンドラの箱が開いちゃう

669 :名無しさん@お腹いっぱい。:02/03/23 20:17
>>668
でも、STLは使いたくなっちゃうだよ。char* にイライラしてくると、
stringとは言わないまでもvector<char>が。

670 :名無しさん@お腹いっぱい。:02/03/23 21:04
人間がコードを書くと、意思とは別に
起こりうることは、まず、書いてしまいます。(w
だから大きな仕様の言語だと、デバッグが大変なのです。

671 :656:02/03/23 23:21
>>660
日々勉強だけど、勉強して身についた範囲で楽は出来てるよ。もう C には
戻りたくない。

でも複数人での開発だと、どこまで C++ の機能を使うかが問題だったり。
(バカとは一緒にコード書きたくないよな…)

672 :名無しさん@お腹いっぱい。:02/03/24 05:49
>>663
> 西暦何年何月?
1998-09-01

673 :名無しさん@お腹いっぱい。:02/03/24 06:47
ルーシー
モノ
ストーン!!


674 :名無しさん@お腹いっぱい。:02/03/24 06:49
最近??もう3年以上前ですが。



675 :名無しさん@お腹いっぱい。:02/03/24 09:33
言語の普及は、処理系の普及と同義なので、非常に時間がかかると思われ。
処理系の実装と安定、そして各サイトでのアップデート…3年では足りぬ。

676 :名無しさん@お腹いっぱい。:02/03/24 11:17
>675
backward compatibilityを考えなくても良くなる
までの時間を考えると10年でも足りないかも。

677 :名無しさん@お腹いっぱい。:02/03/24 11:49
>>675
Windows の世界だと 3 年は太古の昔に感じるが、UNIX だとそうでもない
気がする。

678 :名無しさん@お腹いっぱい。:02/03/24 11:57
正直、Cですらつい最近まで K&R と ANSI 記法がまじってたくらいだしねぇ。
*BSD の原型宣言の __P() ってそのあたりで有名かな。




679 :名無しさん@お腹いっぱい。:02/03/24 12:34
Windowsのクラスライブラリはせいぜい2年が賞味期限でしょ。
後は腐っているのを無理やり食べさせられている状態。

680 :名無しさん@お腹いっぱい。:02/03/24 14:45
>>679
X でも GTk あたりは、バージョン上がると互換性ぶち壊してくれるからなぁ…

681 :名無しさん@お腹いっぱい。:02/03/25 13:10
>>680
さすがに GTK では業務向プログラム書きたくないねぇ…

682 :名無しさん@お腹いっぱい。:02/03/26 13:21
>>643
ワラタ

683 :名無しさん@お腹いっぱい。:02/03/27 00:30
>680-681
GTK+ の互換性の無さはよく言われているけど、
できれば、具体例を挙げて欲しいと言ってみるテスト。
某 ML で聞いた人がいたけど、全くレスがつかなかったしな。

疑っているわけじゃなく、後学のため、反面教師にするためにね。

684 :名無しさん@お腹いっぱい。:02/03/27 02:41
>>683
とりあえず、複数のバージョンの GTK を持ってきて API を比較してみましょう。

685 :名無しさん@お腹いっぱい。:02/03/27 12:04
>>684
>>683の言いたいことは、たぶん、GTKだけでなく、QT-2.3.1とQT-3.0.2でも
APIが異なりソース互換性がなくイナリ互換性もない。Motif-1.2とMotif-2.1
でもAPIが異なりバイナリ互換性がない。にもかかわらず、GTKだけがなぜ
互換性を考慮していないと言われなければならないってことでは。

686 :名無しさん@お腹いっぱい。:02/03/27 12:09
イナリ互換性→バイナリ互換性ね

687 :名無しさん@お腹いっぱい。:02/03/27 14:55
>685 君が例に挙げてるふたつはメジャーバージョンアップ。
Gtk+はマイナーバージョンアップでAPI互換が崩れるからDQNだと言われるのだろう。

688 :683:02/03/27 15:48
>685
えぇ、俺が言っているのは >687 で言われているマイナーバージョンでも
互換性がないということです。
やっぱり、ソースを見るしかないのかな……

689 :685:02/03/27 17:37
>>687
長文スマソ。

gtkでは1.x.yのxがELFでのメジャーバージョンとして扱われるとして
というだけであって、それなら安定バージョンの1.0.xと1.2.xと2.0.x
で互換性がなくても1.0.x間や1.2.x間、2.0.x間で互換性が保たれて
いるなら問題では?

ELF(でないUNIXもあるけど)のライブラリ管理におけるバージョン
(libhoge.so.x.y.zのx,y,zのこと)とアプリケーション/ライブラリの
バージョン(hogehoge-1.2.3とか)を一緒にしなければならないという
決まりはないよね?

ちゃんと確認していないけど、互換性のない1.0から1.2への変更では
ELFにおけるメジャーバージョンが1つか2つ上がり、1.0.x間や1.2.x間
では関数が追加されるなど後方互換性がある場合にはマイナーバージョン
が上がり、それ以外ではリリースバージョンが上がっていたと記憶して
いる。

それなら、単にバージョンの捉え方に誤解が生じやすいだけであって、
GTKはQTやMotifと同じレベルの互換性があり、互換性を考慮していない
ということにはならないはず。

690 :685:02/03/27 17:40
ただ、1.1や1.3のような開発バージョンで全く互換性を考慮せずガンガン
変更されていたのは事実で、開発バージョンであってもちゃんとインター
フェイスを決めてから実装すべきだとは思うけど、インターフェイスの
バグ修正等で互換性を完全に保てないのは開発バージョンならしかたが
ないと思うなあ。

某 う さんがGTKをさんざん嫌っているのは、1.0と1.2の間にかなり期間が
あり、その間に1.1を対象とするアプリがたくさん開発されたため、互換性
に問題があるアプリがいっぱいできている中、やっと1.2がリリースされたと
思ったら、同じ1.2.xなのにバイナリ互換性がなくなる変更があったからじゃ
ないかな。

でも、確かこの互換性がなくなる変更というのはある関数の返り値が特定
のウィジットで間違っていて、仕様と実装に食い違いが生じていたからで
あって、仕方がない変更だったはずなんだけど記憶違いかも。ここ、確認
できる人います? 他に安定バージョンで(後方互換性が保たれていない)
互換性がない変更があったか確認できる人いますか?

691 :685:02/03/27 18:15
あう、

...1.0.x間や1.2.x間、2.0.x間で互換性が保たれて
いるなら問題では?

問題ないんでは?

692 :名無しさん@お腹いっぱい。:02/04/03 20:46
age

693 : :02/05/12 11:58
C++の反省のもとにJavaがあると思うのだが、Javaではダメなことには
どんなものがあるのだね?

694 :名無しさん@お腹いっぱい。:02/05/12 12:24
>>693
Write Once, Run Somewhere.

695 :名無しさん@お腹いっぱい。:02/05/12 12:26
まずは重いことかな? gcjみたいなネイティブコンパイラ使えばいいのかも知れないが......

696 :695:02/05/12 12:28
「ネイティブコンパイラ」っつうか「ネイティブバイナリを吐くコンパイラ」ね

697 :名無しさん@お腹いっぱい。:02/05/12 13:26
>>695
HotSpot VMではご不満か?

698 :名無しさん@お腹いっぱい。:02/05/12 13:54
>>695
比較したことないんだろなぁ、こういう人って(w


699 :名無しさん@お腹いっぱい。:02/05/12 16:14
JAVA標準のクラスライブラリをgcjから
使えるの?


700 :名無しさん@お腹いっぱい。:02/05/12 16:32
>>698
それは比較してみれば重くないことが判るってことでしょうか。

個人的には javac ってやってヘルプ出るまでの間が耐えられん。
(VM の起動時間なのかな?)


701 :名無しさん@お腹いっぱい。:02/05/12 19:06
Javaマンセー
って言ってて、出来ない事が多いから初期のJavaからだいぶ様変わりしてきとるのでは。
サーバサイドで使うから今のJavaであってクライアントだったら問題外だし。
>>694で書いてる事も今はただの看板のようなもんだし。
というかなんでJavaで盛り上がるんだよー。
Java好きな人も、なんでもかんでもJava使うわけじゃなかろうて。

702 :名無しさん@お腹いっぱい。:02/05/12 20:36
>>701
JNIすらしらないんだろうなぁ、こういう人って(w

703 :名無しさん@お腹いっぱい。:02/05/12 21:17
>>702
そこまでしてまでもJavaに拘るんだろうなぁ、こういう人って(w

704 :名無しさん@お腹いっぱい。:02/05/12 21:22
なんでこんな話してんのよ。ほんとにJavaOnlyマンセーなヤツは他の所にいるだろて。

705 :名無しさん@お腹いっぱい。:02/05/12 21:43
CにできてJavaにできないことかぁ、あったかなぁ?
あ、一個だけあったヨ。

buffer over flow だけはできないや、クヤシイー(w


706 :名無しさん@お腹いっぱい。:02/05/12 21:59
はいはい、どっか行っていいってばさ

707 :名無しさん@お腹いっぱい。:02/05/12 22:12
Java房必死だな。
こんなところにまで出張すな。

おとなしくMC++でも始めろ。

708 :名無しさん@お腹いっぱい。:02/05/12 22:18
>>707
C++ ( ´,_ゝ`) プッ

709 :名無しさん@お腹いっぱい。:02/05/18 18:16
>>708
頭の M が何の略か分かってない?

俺は MC++ は別にお奨めではないが、まぁ知っておいて悪くないと思うぞ。

710 :ガガガ:02/05/22 00:37
ジョセフソン素子とガリウム砒素素子について知っている人いたら教えてくれませんか?
宜しくお願いします。

711 :名無しさん@お腹いっぱい。:02/05/22 00:38
「現代用語の基礎知識」より
◆ジョセフソン素子(Josephson device)〔参照用補遺〕
ニオブなどある種の材料を絶対零度(マイナス二七三・一五℃)に近い極低温に冷やすと超電導現象が起
きて、電流の流れに対する抵抗がほとんどゼロになる。このとき二つの材料の間に、この現象による相互
作用を起こさせると、スイッチの作用を作ることができる。このスイッチの組み合わせで作るコンピュー
タの論理素子を現象の発見者の名前をとってジョセフソン素子とよび、通産省電子技術総合研究所などで
実用化に向けて基礎的な研究が進められた。
この素子の特色は、非常にスイッチ速度が速い(二○ピコ秒=一兆分の二○秒)ことと、消費電力が極め
て少ないことである。したがって超大型の計算機に活用することが期待されている。
一九八三(昭和五八)年には、電子技術総合研究所から七ピコ秒というデータも発表された。八三年、ア
メリカIBM社の研究所は、この研究を「ほとんど中止に近い縮小」することを発表した。集積回路に作
ることの難しさ、設計上の厳しさ、などをあげ、成功の見込みの少ない研究と判断したためである。
八六年ごろから、高温で超電導を示す物質がみつけられ、研究の大きな話題となった。ジョセフソン素子
の今後は、この高温超電導材料の研究の発展にその一部がかかっている。が、その一方、新しい試みとし
て、ジョセフソン素子と、半導体ICとを一体化して複合素子という形で両方の特色を生かそうという工
夫が進んでいる。例えば富士通研究所では九一(平成三)年二月、室温で動く高速のガリウム砒(ひ)素
LSIと、ジョセフソン素子とを、ひとつの基板の上にまとめることに成功、今後この方向に進歩すると、
一ギガヘルツの高速コンピュータが実現する可能性が予測される。(現代用語の基礎知識1999年版より)

「現代用語の基礎知識」より
◆ガリウム砒(ひ)素半導体〔電子工学〕
ゲルマニウムやシリコンにはみられない独特な性能をもっているので、研究開発が進められている。(1)
まず、この材料でp-n接合(→別項)を作って、p型をプラス、n型をマイナスにバイアス電圧をかけると、
レーザー発振を開始し、干渉性をもったレーザー光を放射する。これが光通信用の半導体レーザーで、ゲ
ルマニウムやシリコンでは本性上の違いで、この効果はけっして得られない。(2)次に、ガリウム砒
(ひ)素半導体の特色はその中で走る電子のスピードが、ゲルマニウムやシリコンの中よりもはるかに速
いということである。
この特色を生かして、一〇ギガヘルツ程度の高い周波数で働く電場効果トランジスタ(FET)を作り、
人工衛星によるテレビ放送電波受信装置が開発された。また、コンピュータなどパルス技術に使う高速の
デバイス(素子)として、ガリウム砒(ひ)素半導体が、精力的に研究されている。とくにこの場合、特
別の構造のデバイスを作ることによっていっそうこの高速の性能を引き出すため、さまざまな工夫が重ね
られている。
ガリウム砒(ひ)素半導体のもうひとつの妙味は、ガリウム、ヒ素、アルミニウムなどの元素を高い真空
の中で静かに蒸発させ好みの組成の半導体を数十オングストローム(一オングストロームは一億分の一セ
ンチメートル)の厚さで、積み重ねて成長させる技術の発展にある。とくに最近では、こういった化合物
半導体の結晶を、原子のレベルの精度(コントロール)で作り上げる技術が急速に進歩したために、これ
まで自然には存在しなかった構造の結晶を作り、またいろいろの細かい構造のデバイスさえ作れるように
なった。このため、物理学に新しい課題が生まれ、そのかかわりから、一〇年後までに何か新しい飛躍が
生まれる期待がもたれている。
ガリウム砒(ひ)素のデバイスを作るには、そのような層の成長によるが、その層を成長させる基板のガ
リウム砒(ひ)素結晶が必要で、とくにその質のよさが決定的な要因となる。この方面では日本の技術は
極めて高く、転移欠陥の極めて少ない大口径結晶スライスを世界に提供している。



712 :名無しさん@お腹いっぱい。:02/05/22 00:52
お前厨だろ。MC++ なんて言わんぞ。

713 :712:02/05/22 01:00
すまん、ム板の、しかもぜんぜん関係無いスレと間違えた…

714 :名無しさん@お腹いっぱい。:02/05/22 15:20
コンパイラとかライブラリとかの互換性の問題は最近は善くなっているんですか?

715 :名無しさん@お腹いっぱい。:02/07/25 23:01
C#は?

716 :名無しさん@お腹いっぱい。:02/07/25 23:11
OpenOfficeはC++で書かれているそうですよ(マ板ネタですが)

717 :名無しさん@お腹いっぱい。:02/08/09 08:43
数値計算をするのであれば、Fortran95がもっとも適切で機能も豊富だよ。
C++のようなポインター乱用、メモリーリーク温存しまくり、かってな
型の自動変換、うっかり間違っても関数オーバーロードが出来てしまう、
などなどの機能は危険すぎる。オブジェクト指向によるソフトウェアの
安全な記述と堅牢性の売りは、Cとの上位互換性を求めた為におじゃんに
なっていて、むしろCよりもめちゃくちゃ悪い言語に成り下がっている。
プロトタイピングには向くかもしれんが、後のデバッグや保守、ソフトウェア
の正しさの観点からは、マイナス要因だらけ。

718 :名無しさん@お腹いっぱい。:02/08/09 08:48

数 値 計 算 な ら Java で き ま り  

                    以上


719 :名無しさん@お腹いっぱい。:02/08/09 11:49
Javaの利点は、プラットフォームに依存しないことだけ。
その代償として重い。
プラットフォーム非依存性の必要ないサーバーサイドにまで
Javaを使う人の気が知れん。
なんで C/C++ でがちっと書かないのだろう?

720 :名無しさん@お腹いっぱい。:02/08/09 12:37

Fortran95 というのがあっても、実際数値計算やる頭の固い人たちは
FORTRAN77 なんだよね、書き方が。COMMON文乱発でどーしようもなく
モノリシックなコードになってしまってる。
で、やっぱり若い人もそういう人たちからFORTRANを教わるわけで、
結局 FORTRAN77 以上の進展がない(さすがにdo-enddoとかは使うみた
いだけど)。
FORTRAN77 的コードの書き方はとっても理解するのが簡単で、しかも
それなりのシミュレーションとかができてしまうので、 結局、
彼らはそれ以上のものを求めないわけね。

FORTRAN rots the brain.
というのがフォーチュンにあるけど、まさにその通りだと思う。



721 :名無しさん@お腹いっぱい。:02/08/09 23:03
>>720
でもまぁ、数値計算だと「その程度の書き方」でも間に合う規模のプログラムが
多いし、良いんじゃないの?

722 :名無しさん@お腹いっぱい。:02/08/09 23:06
>>719
サーバーサイドの場合、負荷がかかるのは RDBMS でロジックに回す CPU は
余ってるケースが多いからじゃないの? Web がらみだと ASP, JSP, ColdFusion
などなどが主流で C, C++ で書くことは少ないよな。

723 :名無しさん@お腹いっぱい。:02/08/09 23:17
>>719
パフォーマンスの悪さは金で解決できるし、開発・保守コストを含めれば
かえって安上がりだったりするんじゃないかな。

俺は(他人が)仕事で書いたC++プログラムの保守なんてやりたくない。
C++はオープンソースものに趣味で手を出すぐらいが好き。

724 :名無しさん@お腹いっぱい。:02/08/10 02:52
>>720
「それなりのシミュレーション」ってどういう意味ですか?

725 :名無しさん@お腹いっぱい。:02/08/10 03:07
>>722
もしくは Perl Python 等の script lang を、かなり大規模なとこでも
使っちゃうしね。

Perl とか Python とかは web front まわりだけだろとかいう人もいるかも
しれないけど、その認識は往々にして間違い。

726 :名無しさん@お腹いっぱい。:02/08/10 03:14
>>719
> その代償として重い。

比較したことないんだろうなぁ。
JavaならSMP対応はもちろん、分散計算だって簡単なのにね。

>なんで C/C++ でがちっと書かないのだろう?

きちんとスタックガードしてね。
したら確実にJavaより重くなるけどね(w


727 :名無しさん@お腹いっぱい。:02/08/10 03:44
>>726
ん? >>718 以降で話題になっているのは HPC 用途でしょ。んなもん、Java じゃ
Fortran に劣るに決ってい………
と思ったら 719 は web server とかの server side Java の話題をしているのか。

なぜ C/C++ で書かないのかは、719 が自分で書いてみればわかるだろうねぇ。

728 :名無しさん@お腹いっぱい。:02/08/10 07:34
どうでもいいよ金さえ貰えれば

729 :名無しさん@お腹いっぱい。:02/08/10 08:29
>>727
HPCだとなにか何か変わるの?


730 :名無しさん@お腹いっぱい。:02/08/10 09:58
実はsolarisの/etc/rc2.dには、結構javaものが増えてきているという罠

というか、もはやJ2EEあたりまでいくと、言語というよりはフレームワークになってくるので
javaだけ知っててもCOBOLer状態になってしまうという罠

もうつかれちゃったよ・・・なんだよtomcatだのRMI/IIOPだのEJBだのって くすん

731 :名無しさん@お腹いっぱい。:02/08/10 10:27
>>730
まあ、メシの種だと思ってどんどん学習するしかないよね。
気を抜くと食われる側になっちゃうから。

って、ここC++スレなのか。

732 :名無しさん@お腹いっぱい。:02/08/10 12:07
つーか、
Javaって単に重いだけじゃなく、
よく固まるし、未だに動作が不安定じゃん。
俺は一応学習した上で捨てたよ。

733 :名無しさん@お腹いっぱい。:02/08/10 12:22
>>732
参考までに、環境は?

734 :名無しさん@お腹いっぱい。:02/08/10 12:36
数値計算でも、最近はC++でやるケースが増えてきてるみたいですね。
CERNの素粒子解析システムなんかがいい例。

735 :名無しさん@お腹いっぱい。:02/08/10 12:48
>>732
豚に真珠かぁ

736 :名無しさん@お腹いっぱい。:02/08/10 13:36
>>729
Java と Fortran とで数値計算ライブラリの種類とコンパイラの最適化のことを
考えてみてね

737 :名無しさん@お腹いっぱい。:02/08/10 14:15
>>736
数値計算ライブラリは豊富だろうね、 Fortranのほうが。
コンパイラの最適化はJavaが上だな、なんてたって実行時最適化だからね。

Fortranってこういう盲信者が多いよねぇ。
実際に比較もしないでさ。まさに阿呆徒卵(w


738 :名無しさん@お腹いっぱい。:02/08/10 14:46
>>736-737
C++ でも UNIX でもない数値計算ネタはシミュ板でよろしこ。

739 :名無しさん@お腹いっぱい。:02/08/10 17:35
>>737
だいたいシミュレーションやる人は数学や物理には精通してるが、
計算機となると厨房、、、っていう人が大半のような気がするな。
#まぁ、本業は計算機ぢゃないからそれでいいのだろうけど。
こういう厨房がはびこってる間は、数値計算はFORTRANが主流って
ことになるんだろうな。
#まぁ、その方がコンパイラ作る側も楽だから。
CなりC++なりが主流になるのはいつのことやら。

>実際に比較もしないでさ。まさに阿呆徒卵(w
だから、その前にFORTRANしかできないんだってば(藁


740 :名無しさん@お腹いっぱい。:02/08/10 21:25
>>737
ベクトル化って知ってる?

741 :名無しさん@お腹いっぱい。:02/08/11 01:46
>>737,739

シミュレーション結果を論文に書くことを考えると、
その学会でメジャーな言語を選択しておいた方が
理解されやすいって要因もある気がする。

742 :名無しさん@お腹いっぱい。:02/08/11 02:29
で、現実にアプリケーションや計算ライブラリはどの言語で書かれてるんでしょう?

743 :名無しさん@お腹いっぱい。:02/08/11 09:51
>>739
>だから、その前にFORTRANしかできないんだってば(藁

そうだね、5割くらいはそれで満足してるね。まさに井のなかのゆで蛙。

>>740
知ってるけど、それが何か?
そのレベルのことは普通はコンパイラにやらせない?素人馬鹿自慢ですか?(w


744 :名無しさん@お腹いっぱい。:02/08/11 09:59
>>742
C/C++だらけ。これが現実

745 :名無しさん@お腹いっぱい。:02/08/11 13:04
C で数値計算、3000行ぐらいのをやってます。このスレ読んで、C++を
あんまり大層にとらえなくてもいいんだな、と思いました。
で、C++をBetter C として使うにあたって、これだけは覚えとけよ、
とうのがあったら教えてくれませんか。// だけじゃ寂しい…。

746 :名無しさん@お腹いっぱい。:02/08/11 13:28
そりゃ、寂しいねえ、、、、

747 :名無しさん@お腹いっぱい。:02/08/11 13:48
>>745
とりあえずinline

748 :名無しさん@お腹いっぱい。:02/08/11 14:00
>>745
operator overloading、コンストラクタ、一時オブジェクト。計算に使うなら便利でしょ。

749 :名無しさん@お腹いっぱい。:02/08/11 14:04
>>747
それって、Better Cですか?

750 :名無しさん@お腹いっぱい。:02/08/11 14:05
>>747 ×
>>748
です。スマン

751 :名無しさん@お腹いっぱい。:02/08/11 14:16
>>749
クラス使わなくても実現可能な範囲だから、Cの延長として使うにはいいと思うけど。
そんな機能はbetterじゃないって事?

752 :名無しさん@お腹いっぱい。:02/08/11 15:00
ありがとう。コンストラクタって new のアレだっけ、ぐらいに知識が
ないので、とりあえずあげられた事項を調べてみます。
と、数値計算といってもスピード命のクリティカルなやつではないので、
人間側がラクチンになれる方法希望(さきに書くんだった)。
STL というのも調べてみます。

753 :748:02/08/11 15:17
>>752
> 人間側がラクチンになれる方法希望(さきに書くんだった)。
うん。伝わってるよ。>>748でイメージしてたのはこんな感じ↓の使い方。
vector = p(x1, y1) - p(x2, y2);

754 :名無しさん@お腹いっぱい。:02/08/11 16:56
>>752
コンストラクタと new は違うでしょ。
ちなみに俺は C++ で書く時に new をあえて使わないようにしている。
(デフォルト以外の)コンストラクタは使うけど。

755 :名無しさん@お腹いっぱい。:02/08/11 21:47
>>748
は、誰かが作ったクラスを使うのはアリってスタンスですかね。
それだったら、stlはまず使いたいところかな。

756 :748:02/08/12 08:45
>>755
いや、>>753ぐらいの簡単なものならstruct + コンストラクタと
オーバーロードしたグローバル関数で実現できるから、クラスの概念を学ばずに
C気分のまま楽できるんじゃないかと。わかりにくくてスマソ

まあ、structにコンストラクタってもの微妙だけど。

757 :名無しさん@お腹いっぱい。:02/08/12 17:13
多体問題のシムレーションのときにラクなのかな
思いついたのはそれだったんだけど・・・ < OOPの効用

758 :名無しさん@お腹いっぱい。:02/08/12 22:19
関数の多重定義は?

759 :名無しさん@お腹いっぱい。:02/08/13 18:59
>>741
論文でも、プログラムそのものは外に出さない場合が多くない?

>>742
アプリケーションの種類による。

760 :名無しさん@お腹いっぱい。:02/08/13 23:08
最近公開する人多いよね。分野によるけど。
つーか、公開してくれ > 怪しい論文

761 :名無しさん@お腹いっぱい。:02/08/13 23:40
>>758
それはOOPとは直交するような。
むしろgenericsに属すると思われ。

762 :758:02/08/14 00:01
>>761

>>758>>745 に対する返答のつもりだったので。
OOPでなくてもいいんですよね。Better Cなら。

763 :名無しさん@お腹いっぱい。:02/08/22 08:03
Javaって64ビットアドレス空間に対応できるの?バイトコードインタ
プリタ―って、64ビットアドレスで動く? そもそもJavaの
ポインターとか整数とかは64ビットマシンを想定してるのかな?

764 :名無しさん@お腹いっぱい。:02/08/22 08:23
>>763
> Javaって64ビットアドレス空間に対応できるの?

当然

765 :名無しさん@お腹いっぱい。:02/08/22 10:03
>>764 Arrayのindexがintなのはちと不満かも。

766 :名無しさん@お腹いっぱい。:02/08/22 10:04
C++ で書いて、 cfront 通すってのはどう?
って、自分ではまだ cfront 使ったこと無いんだけどね。

767 :名無しさん@お腹いっぱい。:02/08/22 11:15
cでgccコンパイルして、C++使うほうがおすすめ。

768 :名無しさん@お腹いっぱい。:02/08/22 16:55
>>765
32bitCPUでは 毎回long 使われて遅くなるよりゃいいでしょ。
int で不足になったら 286 とかと同じで
セグメントみたいなことやって回避するのかな?
それとも long な配列つくれるようにするんだろうか?

769 :名無しさん@お腹いっぱい。:02/08/25 05:27
対応してなくてもJavaVM書きなおせば済む

なんせclassにはハード依存部分ないしー

# JNIで呼び出した側のことまでは知らんが

770 :名無しさん@お腹いっぱい。:02/08/25 08:18
>>769
Java Virtual Machine Specification見ると、JVM自体は32bit仮想機械としか思えん。
64bit環境で動かした場合、どのくらいメリットあるんだろう。


771 :名無しさん@お腹いっぱい。:02/08/25 19:36
>>770
VMのつくりによるところ大
理由:実装部分で吸収する部分がそれを体感できるはずだから

772 :名無しさん@お腹いっぱい。:02/08/25 21:40
C++でUNIX系OSを見事に実装されている例があるのだろうか?
無いのだとしたら、C++の有効性には疑問符がつくな。
JavaでUNIX系OSを見事に実装されている例があるのだろうか?
無いのだとしたら、Javaの有効性には疑問符がつくな。

773 :名無しさん@お腹いっぱい。:02/08/25 22:50
>>772

BeOSはC++で実装だな。
Unix系とは言えないかもしれんが。


774 :名無しさん@お腹いっぱい。:02/08/25 23:32
>>772
>JavaでUNIX系OSを見事に実装されている例があるのだろうか?

あるよ、今あるJavaVMそのもの。
足りないところがあったらいってみてよ。



775 :名無しさん@お腹いっぱい。:02/08/25 23:53
>>770
今(32bit 32bit)になってるとこが(64bit)になるだけ。
OSの64bit化と何も変わりませんが、何か?


776 :名無しさん@お腹いっぱい。:02/08/26 00:30
>773
Beは、C++の落とし穴に見事にはまって
苦しんでいた記憶があるが。

777 :名無しさん@お腹いっぱい。:02/08/26 00:40
>>776
素の C++ を使うのは、

- メンバ変数一つ加えると、バイナリ互換性があっさり崩れる
- クラスの動的ローディングができない
- コンパイル時にクラスの実体が完全に固定されてしまう
 (あとでインターフェースが同じ他のクラスとかに差し替えられない)

と面倒があって、後方互換性が重視される OS の世界だと、いろいろ
厳しい。

Win32 の COM とか JavaVM みたいに、一段クッションを噛ませれば
良いんだけどさ。

778 :名無しさん@お腹いっぱい。:02/08/27 08:01
COMはともかく、JavaVMはクッションにというには大きすぎじゃないか?

779 :名無しさん@お腹いっぱい。:02/08/28 08:17
C#も似たようなものだわな

780 :名無しさん@お腹いっぱい。:02/08/28 12:39
>>779
そか、.NETだとVM使うんだよな。.NETは言語非依存なのはいいけど、Win専用
というのが辛い。

781 :名無しさん@お腹いっぱい。:02/08/28 13:48
>>780
FreeBSDでも動いてるYO!
Linux方面でもmonoとかいうプロジェクトでインプリメントしてるんじゃなかったっけ。


782 :名無しさん@お腹いっぱい。:02/08/29 02:26
>>772
VFSってCで書いてるOSとC で書いてCに変換してるOSあんぞ

VFSのメモリオブジェクトほどOOPが効くもんないぞ、OSの世界では

他には、たとえばWindowsNTのカーネル資源のオブジェクト表現については、
OOP設計C実装のいい例なのかもしれん。

783 :C++使い:02/08/29 09:17
>>1
俺ら迫害されてるんだよ。
革命でも起こさないとダメさ。

784 :EJB使い:02/08/31 02:31
なんか知らんがいつも変態扱いされてまそ

何説明しても「ふーん よくわかんないんですけど、納期明日だから」としか応答してくれまそん

もうこんな生活嫌ぁ・・・


785 :名無しさん@お腹いっぱい。:02/08/31 09:12
ふーん よくわかんないですけど、がんばってね

786 :名無しさん@お腹いっぱい。:02/10/02 23:17

で、実際 UNIXで C++やるとして、何かいい参考書ないし参考ページある? ぐぐったが
探し方が悪いらしくぱっとしたのが見つからない。

一応 Cで書いたライブラリは使い回せるとは言うものの、C++の文字列オブジェクトから
一々 char *とってたら馬鹿馬鹿しいだろうし、1から作り直すのは勘弁願いたいので適当
なできあいのライブラリで標準的なのもあると嬉しいのだが、特にネット関連(HTTPの処
理とか)。



787 :名無しさん@お腹いっぱい。:02/10/03 01:35
>>786
KDEとかGNOME方面は当たってみた?

788 :名無しさん@お腹いっぱい。:02/10/03 05:18
C++(KDE) vs C(GNOME) という感じがするのだが。
Qtは良くできてるので見といた方がいいかも。

789 :名無しさん@お腹いっぱい。:02/10/04 01:28
Kylixは?

790 :名無しさん@お腹いっぱい。:02/10/04 01:31
>>789
Objective Pascal

791 :名無しさん@お腹いっぱい。:02/10/04 01:51
KylixはC++もつかるんじゃ?

792 :名無しさん@お腹いっぱい。:02/10/04 01:55
3からでしょ?

793 :名無しさん@お腹いっぱい。:02/10/04 01:58
>>790
最近になってDelphi languageとかいう名前に変わったな

794 :名無しさん@お腹いっぱい。:02/10/04 02:15
program hoge;
begin
(* C経験者は書いててイライラするかも、Objective Pascal *)
end.

795 :名無しさん@お腹いっぱい。:02/10/04 02:34
関数の最初に使う変数を宣言しなくちゃいけないから、
C++経験者としては、とってもイライラします。

796 :名無しさん@お腹いっぱい。:02/10/04 03:49
使ってまだ日も浅いけど、Delphiの嫌いなとこ

・ operator overloadできない (まあ、これは許せる)
・ 所詮COM由来のinterface (Javaのinterfaceの方がしがらみなくて便利)
・ 継承classでメソッドの可視性さげられん (public -> privateとか。Singletonとか書くときメンドい)
・ namespaceが貧弱 (つーか殆んど無いに等しい)
・ virtual; abstract; の継承失敗が全部runtime errorなのはカンベン
・ Javaみたいにthrows欲しい...

まあ、重箱の隅っちゃー隅なんだけど。
# あー、あとプロトタイプ宣言、一字一句同じでないと致命的エラーなんも嫌い...


797 :名無しさん@お腹いっぱい。:02/10/06 17:49
一応メモっとく。誰か使ってみた事ある?

Common C++ - A GNU Portable Application Framework
http://cplusplus.sourceforge.net/

offering portable support for threading, sockets, file access,
persistent object management, and system services
だそうだ。

798 :786:02/10/07 03:29

遅レス スマソ。前任者から引き継いだサーバがどうも変なので同僚と調べてたら rootkitが
仕込まれてやがんの(藁)。おかげで先週一杯 被害確認と復旧で死にかけてたもので。
ま、これであのクソなヤシもクビだと思うとせいせいするがな。。。愚痴スマソ。

>>787 >>788 なるほど、Qt(KDE)ね。GUIプログラムせんのですっかり抜け落ちてた。
>>797 能書き見る限りだとよさそうだな、これ。ためしにこいつベースでいじってみると
する。 サンクスコ



799 :名無しさん@お腹いっぱい。:02/10/31 05:34
昨日のできごと。
Solaris8/Sun WorkShop6(5.2)で、C++のお勉強がてら共有ライブラリ
を作ってたんだが、

main() -> Class1::func() -> Class2::func()

でClass[12]が共有ライブラリ上にあった時、Class2::func()でthrow
した例外がClass1::func()でcatchできない(main()側のcatchにしか
引っかからない)というのでハマってた。

コンパイラをgcc 2.95.2に変えても駄目、Sun SolveからC++/共有
ライブラリに関連しそうなパッチ取ってきてぶち込んでも駄目、しかし
スタティックライブラリにするとOK、HP-UX11.00に持っていくと共有
ライブラリにしてもOK、という事でしばらく頭を抱えてた。

「やっぱUnixでC++は避けた方がいいのかな…」と半ば諦めかけて
いたけど、なにげにMakefileを見てたら原因判明。なんの事はない、
共有ライブラリを作る時に直接ld叩いてたせいだった。CC/g++とか
のフロントエンドを通せばOKという事で、オプションが足りなかった
とかそんなつまらん問題だったんだろう。(´・ω・`)ショボーン

800 :名無しさん@お腹いっぱい。:02/11/01 02:05
可憐に800get

801 :名無しさん@お腹いっぱい。:02/11/05 00:05
C++マンセーあげ。

802 :名無しさん@お腹いっぱい。:02/11/05 00:09
799のmainの行を見て一瞬Haskellかとおもっちったよ

803 :名無しさん@お腹いっぱい。:02/11/05 04:14
>>1
GTK+ のソース見てみろよ。
全部 C で書かれているけどしっかりOOPになっている。
継承も使えるし、メンバ変数が直接見えないように工夫している。
関数の名前がやたら長いけど、、、

804 :名無しさん@お腹いっぱい。:02/11/05 04:21
>>803
歯でビール瓶開けられるからって、偉くはないぞ。
栓抜き使えと。

805 :名無しさん@お腹いっぱい。:02/11/05 07:20
(´・ω・`)

806 :名無しさん@お腹いっぱい。:02/11/05 07:40
X もあるでよ

807 :名無しさん@お腹いっぱい。:02/11/05 19:31
>>803 逆に漏れはGTK+見てC++をマジメに覚えようとオモタよ

808 :名無しさん@お腹いっぱい。:02/11/05 20:15
C++以外は糞。

809 :↑おまえが糞:02/11/05 21:11


810 :名無しさん@お腹いっぱい。:02/11/05 21:16
ずいぶんショボイ燃料だな。

811 :名無しさん@お腹いっぱい。:02/11/05 22:03
UNIXだと、パイプを使ったりclient/serverにしたりして、かなり
一つ一つのプロセスを単純にするから、個々のツールが一つの
巨大なクラスとして働いていて、結果本格的なオブジェクト指向が
不必要になっている、という面があると思う。で、そのインスタンスが
プロセス。もちろん、プロセス間通信は、普通の関数呼び出しに比べれば
はるかに面倒だし、polymorphismなんかの有難味はあまり享受できない
けど、自然な設計単位を示してくれている、というのはあると思う。

812 :名無しさん@お腹いっぱい。:02/11/05 22:25
それでもapacheみたいな巨大なプロジェクトでC++でなくCを選んだせいで
ACEのような既存の完成したライブラリを使用できず、似たようなライブラリを
自前で作ってるのは単なる間抜けだと思うが。

813 :名無しさん@お腹いっぱい。:02/11/05 23:43
正直、C++はこれからでしょ。
boostがもっと一般的に使われるだろうし、
その時にはCとC++どっちがいいのか
なんてバカな話も出なくなるだろうし。

814 :名無しさん@お腹いっぱい。:02/11/05 23:56
apacheで作られたCのライブラリが今後使われるようになる、
ってことはないの?


815 :名無しさん@お腹いっぱい。:02/11/06 00:10
みんなC++使いこなせて良いですね.私なんて
gcc-3.2をコンパイルしたけどlibstdc++-v3, g++でerrorが
消えなくて(勉強するために)環境を整えることさえ
できませんて... せっかく本も買ったのに。鬱だ...

816 :名無しさん@お腹いっぱい。:02/11/06 00:19
>その時にはCとC++どっちがいいのか
>なんてバカな話も出なくなるだろうし。

そのときは、C++とC##(架空)のどちらがよいか
みたいなバカな話が出てくるに一票

817 :名無しさん:02/11/06 02:07
つまり無限ループね。

818 :名無しさん@お腹いっぱい。:02/11/06 02:53
UNIXはとにかく早く試作品作って、テスト繰り返してってのが流儀だから
最初に設計して、再利用考えてってのは合わんのよ。
理想としては
「スモール・イズ・ビューティフル。
 ゆえに大規模プログラミング固有の問題は存在しない」。
現実は、場当たり主義で泥臭く何とか実用レベルに持っていく。

819 :名無しさん@お腹いっぱい。:02/11/06 08:36
いつまで古事記みたいなこと言ってんだか

820 :名無しさん@お腹いっぱい。:02/11/06 09:15
>>819
まぁまぁ、>>818はピラミッドの最下層にいるデジタル土方さんなんだよ(w


821 :名無しさん@お腹いっぱい。:02/11/06 10:19
おまいら、Objective-C を忘れていますよ!



いや、使ったことないけどさ・・・

822 :名無しさん@お腹いっぱい。:02/11/06 16:27
>>812 Apacheのライブラリ再利用は進んでいないが,GIMPのGTK+は(略

今後はこういう例が増えるといいね.車輪の再実装はやめたいよ・・・

823 :名無しさん@お腹いっぱい。:02/11/06 16:48
MSだしてるMicrosoft Visual C++
のパッケージって、ほんとに入門用?
買うか買わぬか・・・
厨房に扱えるかなあ

824 :名無しさん@お腹いっぱい。:02/11/06 17:02
>>823
それはさすがに板違いだろう。

825 :名無しさん@お腹いっぱい。:02/11/06 18:54
ObjCはむしろCっていうよりSmallTalkだろ。

826 :名無しさん@お腹いっぱい。:02/11/06 20:27
VC++はANSI C++ではありません。
またドトネト対応に忙しくてそんなことをするつもりもないようです。
というわけで本末転倒ですが、C++のプログラムを書きたいのなら、
gcc向けに書きましょう。

827 :名無しさん@お腹いっぱい。:02/11/06 22:52
>>820
といいつつ、UNIXユーザって土方がマジョリティでしょ。

828 :名無しさん@Emacs:02/11/06 23:38
別に土方でいいじゃん。よくその話は聞くけど
土方だと何か問題があるのか?

829 :名無しさん@お腹いっぱい。:02/11/06 23:46
>>818
>  ゆえに大規模プログラミング固有の問題は存在しない
UVM のソースとか読んだこと無いんだろうな…と想像してみる。

830 :名無しさん@お腹いっぱい。:02/11/06 23:50
>>828
俺はソリューションバブル (ってほとじゃないが) の現状はともかく、5 年後を
考えると仕事の単価が下がると見込んでる。

使えないシステムでも、とりあえず IT バブルにのって導入しちゃったし、メン
ツの問題もあるからメンテナンスしとくか、っつーお客さんが減ったときが勝負
じゃないかね。(っつーわけでソリューション系の業界から逃げました>私)

831 :名無しさん@お腹いっぱい。:02/11/07 00:05
プログラム言語を恋愛に例えると、

C    純愛
C++  愛人
JAVA 遊び相手
perl  変態プレイ

だな。

832 :名無しさん@お腹いっぱい。:02/11/07 00:25
>>831
C
やや古臭いが隠し事は一切なく純粋。信じることが大事。

C++
周りも自身も華やか。ちょっとインテルぶっている。
友達にプライベートを見せる一面も。

JAVA
基本的に親族にしかプライベートは見せない。
奥手だが育ちがいいエリート。

perl
packageでスコープを制限できるが、デフォルトでは
裸で歩いているのと同じ。言われればなんでもやっちゃう。

833 :名無しさん@お腹いっぱい。:02/11/07 00:32
intelぶってるの?

834 :名無しさん@お腹いっぱい。:02/11/07 00:43
>>833
まちがた

835 :名無しさん@お腹いっぱい。:02/11/07 01:02
>>832
C も void* と static を使って隠すことがあります。親しき仲にも礼儀あり。

836 :名無しさん@お腹いっぱい。:02/11/07 01:22
void*は隠してるのとは微妙に違わないか?

837 :名無しさん@お腹いっぱい。:02/11/07 01:23
         これってほんとか?
         ↓   ↓    ↓
http://www.dream-express-web.com/entertainment.htm


838 :名無しさん@Emacs:02/11/07 01:53
うそです

839 :名無しさん@お腹いっぱい。:02/11/07 03:02
やっぱ lisp だな

とか脈略も無くほざいてみるテスト

840 :名無しさん@お腹いっぱい。:02/11/07 04:26
おれの中では
C = Lisp
C++ = Haskell,ML
ってな感じだな。
C++ユーザーはLispよりも型付関数型言語をやるほうがしっくりくる。

841 :名無しさん@お腹いっぱい。:02/11/07 08:47
C
アセに陰毛がはえた程度のいたいけな少女。
あそこの見た目はきれいだが、はまると一家心中。

C++
Cの陰毛がさらに繁茂、やりまくりでいつも濡れ濡れ悪女。
ケツの毛まで抜かれて、最後は自己破産。

Java
基本的に親族にしかプライベートは見せない。
奥手だが育ちがいいエリート。

perl
ただの馬鹿



842 :名無しさん@お腹いっぱい。:02/11/07 09:44
> 裸で歩いているのと同じ。言われればなんでもやっちゃう。
(;´Д`) ハァハァ

> ただの馬鹿
(;´Д`) Σ

843 :名無しさん@お腹いっぱい。:02/11/07 09:47
>>841
ワラタ


844 :名無しさん@お腹いっぱい。:02/11/07 13:15
http://pc3.2ch.net/test/read.cgi/tech/1032438837/57n

845 :名無しさん@お腹いっぱい。:02/11/07 20:18
C99はとろろ丼だの始めた吉野屋みたいなものか

846 :名無しさん@お腹いっぱい。:02/11/09 05:06
煮込みハンバーグ定食だの始めたロッテリアみたいなものか

847 :名無しさん@お腹いっぱい。:02/11/21 01:09
C爺さん   小言じいさん。アセンブリ曾じいさんにはかなわない。
C++氏   働き盛り。C爺さんがちょっとうざい。
Java小僧  最近、ようやく社会人に。
C#ボウヤ  MSの秘蔵っこ。実は、ひとりで外出できない。
Perl婆さん 裸の美女と間違えられたり、案外最強だったりする。

848 :名無しさん@お腹いっぱい。:02/11/21 04:14
C++が使えないという、仕事には全く使えないうんこ共がC++に暴言を吐くスレというのは此方ですか?
漏れの心の師である、επιστημηタソ程度には使いこなせてから語ってもらいたいもんです。

849 :名無しさん@お腹いっぱい。:02/11/21 04:21
Know the C++, or die.
Try the C++, or die.
Think the C++, or die.
Do the C++, or die.
Play the C++, or die.
Pray to the C++, or die.
Speak in the C++, or die.
Be as the C++, or die.

850 :名無しさん@お腹いっぱい。:02/11/21 15:29
epistemeが心の師なのかよ。

851 :名無しさん@お腹いっぱい。:02/12/06 00:40
スレ違いかもしれんが、原子力発電所だのミサイルだの
やばそうな制御プログラムはどの言語で書くべきだと思う?
処理系の枯れっぷりから考えてC/C++やJavaでは書いて欲しくない。
許せる選択肢はFortranくらいしか残らん気がする。

適材適所ということを言いたかった。スレ違いすまん。逝ってきます。

852 :名無しさん@お腹いっぱい。:02/12/06 02:51
>>851
Ada

853 :名無しさん@お腹いっぱい。:02/12/06 03:37
だろうな

854 :名無しさん@お腹いっぱい。:02/12/06 11:51
C++ や Java ならともかく、C なら別にいいんじゃないか?

855 :名無しさん@お腹いっぱい。:02/12/06 12:00
C++ や Java ならともかく、ぬるぽなら別にいいんじゃないか?

856 :名無しさん@お腹いっぱい。:02/12/07 10:19
ぬるぽって何?マジレス求む。

857 :名無しさん@お腹いっぱい。:02/12/07 10:30
もうぬるぽ。
http://www.google.com/search?lr=lang_ja&ie=eucjp&q=%A4%CC%A4%EB%A4%DD

858 :名無しさん@お腹いっぱい。:02/12/07 19:15
>>857
さんくす。

859 :名無しさん@お腹いっぱい。:02/12/07 19:26
  ( ・∀・)   | | ガッ        ( ・∀・)   | | ガッ        ( ・∀・)   | | ガッ
 と    )    | |          と    )    | |          と    )    | |
   Y /ノ    人            Y /ノ    人            Y /ノ    人
    / )    <  >__Λ∩         / )    <  >__Λ∩         / )    <  >__Λ∩
  _/し' //. V´Д`)/ ←>>855  _/し' //. V´Д`)/ ←>>856  _/し' //. V´Д`)/ ←>>857
 (_フ彡        /        (_フ彡        /        (_フ彡        /

860 :名無しさん@お腹いっぱい。:02/12/08 09:56
http://www.terminator3.com/content/desktop_downloads/desktop_lg/t3_desktop_a01_1280.jpg
ターミネーターもC++で動いてるし(右側

でも printf

861 :名無しさん@お腹いっぱい。:02/12/08 11:08
void main()かよ

862 :名無しさん@お腹いっぱい。:02/12/08 14:00
windows.h とか HINSTANCE ってことは Windows なのか...
ターミネーターは定期的に再起動が必要なの?

863 :名無しさん@お腹いっぱい。:02/12/08 14:53
なんかやなもんみちゃったな(w

864 :名無しさん@お腹いっぱい。:02/12/08 16:01
>>1
何だよ、「C++」って。
オマエ厨臭いぞ。板違いだから削除依頼出しとけ。

865 :名無しさん@お腹いっぱい。:02/12/08 17:59
>>864
マジレス14ヶ月目の法則ですか?

866 :名無しさん@お腹いっぱい。:02/12/09 01:42
VIRUS NEC がずらっと並んでいるように見えるのは気のせいか?

867 :名無しさん@お腹いっぱい。:02/12/10 20:34
Objective Camlとかはダメなんですか?
あまり綺麗な言語仕様とは思わないけど、実用的だと思う。
Cはもちろん、C++からでも充分乗り換える価値があると思うのだが。

868 :名無しさん@お腹いっぱい。:02/12/10 20:47
言われてみればC使ってるな


869 :名無しさん@お腹いっぱい。:02/12/10 20:53
プログラミングコンテストだとC++はMLやHaskellに負けまくりだけど
あれって、一般人だとどうなるんだろう?。コンテストに出てるやつは
まがりなりにも計算機についてちゃんと勉強したやつだろうからなあ。

870 :名無しさん@お腹いっぱい。:02/12/12 01:12
どうって、どう?
一般人で ML だの Haskell だの名前だけでも知ってるほうが珍しいんでは?

871 :851:02/12/12 01:20
>>852
Ada ってどれくらい普及してるんでしょうか?

ある程度以上普及してないと処理系は枯れないし、
アプリケーションの実装者側も変な失敗をする危険は
避けられないように思うのですが、そういう意味での
普及度・噂・実績はどんなもんでしょう?

マジレス希望。
ヤバそうなシステム開発の経験者の経験談、希望。

# スレ違いなら、どこかへ誘導してください。


872 :名無しさん@お腹いっぱい。:02/12/12 01:22
>>871
ここか?
ほとんどネタスレだが。

米国国防省の標準高等言語エイダ(Ada)を語れ!
http://pc3.2ch.net/test/read.cgi/tech/1010492940/

873 :名無しさん@お腹いっぱい。:02/12/14 01:51
ネタスレとネスレの区別がつかないのですが

874 :名無しさん@お腹いっぱい。:02/12/14 02:30
タヌキさんですか?


875 :名無しさん@お腹いっぱい。:02/12/15 19:48
>>862
Windowsのpwlファイルのビュアーかなんかのソースだろうか MS謹製っぽいコメントが入ってるし

876 :名無しさん@お腹いっぱい。:02/12/20 16:12
http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/devd/

/sbinでC++かぁ…

一瞬「ひょっとして、でぶでー(デブだな)というシャレ?」とか思った
2徹明けの午後。そろそろ寝ないとまずそうだ。。。

877 :名無しさん@お腹いっぱい。:02/12/27 20:50


878 :山崎渉:03/01/15 13:14
(^^)

879 :名無しさん@お腹いっぱい。:03/01/20 05:38
>>873
ネッスルじゃなかったのか

880 :名無しさん@お腹いっぱい。:03/01/21 20:21
ネッスルとマッスルの関係を述べよ。
サフィックスに日本がつく場合についても言及すること。

881 :名無しさん@お腹いっぱい。:03/01/22 08:46
ネッスル=ネットする
マッスル=マッチする

882 : :03/01/23 00:52
つかわない んじゃないんです

つか「え」ないんです、上の人間(会社の場合)or協力者(それ以外の場合)が

883 :名無しさん@お腹いっぱい。:03/01/23 03:32
つまり、 C++ 自体には問題は無いという事だな。

884 : :03/01/23 04:39
ないんじゃない?
solarisのvfsなんてOOPで設計してるくらいだし

885 :名無しさん@お腹いっぱい。:03/01/24 05:46
C++をOOP言語としてしか見てない香具師は
恥かしいので厨房レベルぐらいまでは勉強してください。
上のレスは見てるこっちが恥かしいです。
884がもの凄いUNIXハカーであればあるほど。

886 : :03/01/24 12:01
>>884
別にハカーじゃねーよ vfsがOOPなのは誰でも知ってるよーなことだ。

本物のOOP言語についてはプログラム技術板の方がお似合いだから
ここでは言及しねーぜ、漏れは。

# OOP言語なんてのは、ホントはどこにもありゃしないのさ。

887 :名無しさん@お腹いっぱい。:03/01/26 16:02
日本製でソースが公開されていて、C++で書かれていて複数人で
メンテナンスされているソフトを教えてください。

888 :名無しさん@お腹いっぱい。:03/01/27 06:45
>>887
ないです。というより当分出てこないと思われます。
理由は関数型言語のメジャーなアプリケーションが
ないことと大体同じかと。5年後には変わっているの
でしょうが、今は無理でしょうね。

889 :名無しさん@お腹いっぱい。:03/01/27 22:47
>>887
日本製ってのがアレだが

日本人も開発に参加してるってことなら groff (jgroff patch), Qt とか。英語圏でも
良ければ GNU source-highlight やら doxygen やらイロイロ。

>>888
関数型言語だと、むしろ Emacs Lisp が大量に。

890 :名無しさん@お腹いっぱい。:03/01/29 00:14
>>889
C++を使うと大規模なソフトを見通し良く構築することができると
言われていますよね?日本のプロジェクトでそれを実践できている
ものがあればを見たいです。そのようなソフトが公開されてないなら、
何故無いのか知りたいです。

891 :名無しさん@お腹いっぱい。:03/01/29 01:49
>>890
日本人C++プログラマの質が低いんじゃねえのって言いたいんだろ?
遠まわしになんだか嫌らしい奴だな。おれはその通りだと思うがな。
第一日本人がこれまでC++に関するまともな本を、何一つ書けてない
事実からしてもその程度が知れてるもんだと思うがな。

892 :名無しさん@お腹いっぱい。:03/01/29 10:51
>>890
> 日本のプロジェクトでそれを実践できているものがあればを見たいです。
仕事だと、ほとんど C++ だけどねぇ。

> 第一日本人がこれまでC++に関するまともな本を、
日本でプログラミング関係の本を出しても部数捌けないから金にならんし、
米国と違って独立系技術コンサルタントのような仕事もあまりないので、
本を書く動機がないのが主因だと思うぞ。

技術者の層自体は、標準化委員会やなにかに人を出してる企業もあるし、
それほど薄くないんだが。

893 :名無しさん@お腹いっぱい。:03/01/29 12:26
>>892
>技術者の層自体は、標準化委員会やなにかに人を出してる企業もあるし、
>それほど薄くないんだが
いや、それは一部分の話でしょ。おれが思うのは雑誌記事書いたりする
ライターからそれの読者までのようなレベルがcujなんかと比べると
えらく低いなと思うんだよ。そのことで別に卑屈になる必要はなくて
よいものはどんどん取り入れて追いつけばいい話なんだけど。

894 :名無しさん@お腹いっぱい。:03/01/29 12:32
誤解招きそうだからあえて言っておきますが、おれもレベルの低い1人です。

895 :名無しさん@お腹いっぱい。:03/01/29 12:38
>>894
おれ、って誰?

896 :名無しさん@お腹いっぱい。:03/01/29 13:16
>>895
894=893。つまり書き込んでる自分のことです

897 :名無しさん@お腹いっぱい。:03/01/29 13:21
>>896
その番号を 894 に書いて欲しかった・・・。
「書き込んでる自分のこと」 なのはわかるが、それが誰なのかこれじゃあわからんぞ。

898 : :03/01/29 16:24
業務系SE/PGの間では、もうCつかわないところ多いです
生産性・改造容易性ではやはりC++が上です UMLきっちり書くところも多いですよ

ただ、性能を重視したいOSに近いところは、Cでかかないとダメだけど。
UNIX板で扱うものの半分はそれがあるでしょ?
名前空間検索ロスとか

でもそーでもないよーなのでもCで書いてるからフシギよね・・・


899 :名無しさん@お腹いっぱい。:03/01/29 20:05
>>898
そーゆーのはJava使うんじゃないの?
これからならC#?

900 :名無しさん@お腹いっぱい。:03/01/29 21:53
>>893
> おれが思うのは雑誌記事書いたりする
> ライターからそれの読者までのようなレベルがcujなんかと比べると
> えらく低いなと思うんだよ。
というか、ふつー質の高い情報が欲しければ cuj 読むのでは? 日本からでも
購読できるし。

>>899
> そーゆーのはJava使うんじゃないの?
過去の資産というやつが…

901 :名無しさん@お腹いっぱい。:03/01/30 06:06
名前空間検索ロスってなあに?

902 : :03/01/30 23:25
>>899
マシンに充てるお金けちられること多いのでJavaは、、、正直Servletだけにしたい

903 :山崎渉:03/04/17 12:33
(^^)

904 :山崎渉:03/04/20 05:58
   ∧_∧
  (  ^^ )< ぬるぽ(^^)

905 :山崎渉:03/05/22 02:12
━―━―━―━―━―━―━―━―━[JR山崎駅(^^)]━―━―━―━―━―━―━―━―━―

906 :名無しさん@お腹いっぱい。:03/07/06 19:26
STLつかってると gccは糞遅くて使い物にならん。

907 :山崎 渉:03/07/15 11:35

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

908 :あぼーん:あぼーん
あぼーん

909 :あぼーん:あぼーん
あぼーん

910 :名無しさん@お腹いっぱい。:03/12/15 00:47
GCCのC++対応は結構いい線いってるんだから,
FSF関係者はC++でアプリを書くことをあるていど考え始めた方がいいと思うな.
C++の導入がスムーズにできたら,今後の発展に大きく響くよ.
もちろん(マシンリソースが)しょぼい特殊用途の環境でがんばってる人のためには配慮がいるけど.

911 :うに:03/12/17 00:59
>10

たしかに qsort はないよな〜、バブルソートやろ。

912 :名無しさん@お腹いっぱい。:04/01/01 12:51
ドライバ書いているけどC++って自動で余分なコード付いてくるから遅いんだよね。


913 :名無しさん@お腹いっぱい。:04/01/07 20:46
Cにこだわり続けているやつでC++まともに使えるやついるのか?
ただ単に新しい言語を覚えるのをめんどくさがってるとしか思えん。
速度効率を考えるとCなんだろうが、
PC能力が格段にあがった今日、開発効率の方が重要な場合が多いと思うんだが。(ドライバ開発とかは除いてね)

複数人でまとまった規模のプログラムを書こうと思ったら、手続き型言語なんて効率悪いだろ。


914 :名無しさん@お腹いっぱい。:04/01/07 20:50
>>911
qsortってクイックソートのこと?バブルより効率いいアルゴリズムだったと記憶しているが・・・

915 :名無しさん@お腹いっぱい。:04/01/08 11:37
>>797
GNU Common C++ なら、こっちのページのほうがドキュメントがそろってるよ。
http://www.gnu.org/software/commoncpp/

リファレンスマニュアルをみると、かなり充実してるっぽい。
とくに Socket と Thread 関連が特徴かな。
http://www.gnu.org/software/commoncpp/docs/refman/html/index.html

916 :名無しさん@お腹いっぱい。:04/01/29 20:30
age = age++;


917 :名無しさん@お腹いっぱい。:04/01/29 20:38
>>916
何それ?

918 :名無しさん@お腹いっぱい。:04/01/29 21:34
>>917
ttp://www.imou.to/~AoiMoe/nikki-word/2002.html#2749a5bdae532bb2d50be85e30c7cc28

919 :名無しさん@お腹いっぱい。:04/01/30 02:10
ageは増えるのか?増えないのか?

920 :マイク ◆yrBrqfF1Ew :04/01/30 18:27
Side Effectを伴うコードな為不定か未定義

921 :名無しさん@お腹いっぱい。:04/02/05 15:54
>>777
DarwinのIOKitはC++だね。

922 :名無しさん@お腹いっぱい。:04/03/16 07:28
1から読んできましたけど、
皆さんUnixとWindows両方使ってるんですね。

923 :名無しさん@お腹いっぱい。:04/03/16 23:54
・開発言語による生産性にはほとんど違いがない(5%程度。アセンブラは別)
・企業におけるプログラマーの能力差は10倍。企業自体の生産性にも10倍の開きがある

と、ピープルウエアの中の人がいってます。


924 :名無しさん@お腹いっぱい。:04/03/17 00:01
なるほど。確かにそうかも。

925 :名無しさん@お腹いっぱい。:04/03/17 00:59
>>919
代入が終わってから加算されるので、増えない。
に一票

926 :名無しさん@お腹いっぱい。:04/03/17 01:09
「C++ をマトモに使う」ってどういうことかな。
template は魅力的だけど C++ の OOP なんてキモチワルイ
だけで便利な構造体以上の使い方する気しないんですけど。

927 :名無しさん@お腹いっぱい。:04/03/17 01:32
//こんなコメントの書き方に憧れた。
//これだけの為にC++はじめた。
//結局その他の機能は手つかず。
//仕事は未だにアセンブラばかりなのでどうでもいいのだが。

928 :名無しさん@お腹いっぱい。:04/03/19 01:22
>>926
C++のOOPが気持ち悪いなら自分なりのOOPを書けばいいだけなんだけど

C++は無駄な機能はたくさんあるけど、足りない機能はほとんどないでしょ

929 :名無しさん@お腹いっぱい。:04/03/19 03:50
動的にいろいろいじる機能がない気がするけど。
動的な関数生成とか。

930 :名無しさん@お腹いっぱい。:04/03/19 04:39
>>928
あとジャグ配列あれば文句ない。
まぁクラス自分で作ればいいんだけどね。

931 :名無しさん@お腹いっぱい。:04/03/19 05:17
>>929
そんなのCにだってないじゃん。
C++はあくまでCの路線には忠実なんだよ。それがいいところ。

932 :名無しさん@お腹いっぱい。:04/03/19 06:22
>>931
でも、そこがOOしてないと言われちゃうところなんじゃないの?
動的にいろいろいじれてこそのOOだと思う人も多いわけだし。

まあ、動的にいろいろすると、デバグはしにくくなってしょうが
ないからヲレは嫌いなんだけどね…

933 :名無しさん@お腹いっぱい。:04/03/19 09:54
>>929
飛躍しすぎだろ、アホ

934 :名無しさん@お腹いっぱい。:04/03/20 04:21
気持ち悪くない Object System 作るのは、もうちょっと動的な機能がないと厳しいと思う。
多機能な C として使うぶんにはいいけど。

935 :名無しさん@お腹いっぱい。:04/03/20 04:51
C++に限らず、ネイティブコードに落とすコンパイラで実現してる環境があるのかね?
「C++インタープリタ」でも探したら?

どうしてもやりたければ
Javaみたいに中間言語にするか
スクリプトエンジンでも作るんだね。
JITまで実装すれば速度的なデメリットも緩和されるでしょ。
俺には不可能だし、そもそも「C/C++」にそんな機能が欲しいとも思わないけどね。

936 :名無しさん@お腹いっぱい。:04/03/20 08:52
>>935
物知らずというのは強いねえ。


937 :名無しさん@お腹いっぱい。:04/03/20 15:49
D言語のDはDQNのD

938 :名無しさん@お腹いっぱい。:04/03/20 19:02
動的な機能ってOOPと関係あんの?

939 :名無しさん@お腹いっぱい。:04/03/20 19:38
未だにSmalltalkだけがOOPだと信じてる人にとっては
関係あるんじゃない?

940 :名無しさん@お腹いっぱい。:04/03/21 01:07
>>935
> C++に限らず、ネイティブコードに落とすコンパイラで実現してる環境があるのかね?

Lisp 系とか関数型とかの言語には特に重要な機能だから、そっちの処理系では大体実装されてると思う。

Common Lisp だと CMUCL とか SBCL が直接 native code に落とすね。
Scheme だと Bigloo とか Chicken とか、一度 C に変換するのが多い。
ML だと OCaml とかが native code 吐くみたい。
などなど。


>>938
OOP って根本的に動的なものだと思うけど。
問題を Object の関わりとして記述する。
関わりの中で、「Object」も「関わり」も、いろいろ変化を続けていく。
その変化の先に、求める答えが現れるようにするのが OOP でしょ。

で。
変化の中で、使いたい method が変わってくることもある。
でも、 method が動的に生成できないと、使いたくなるかもしれない method を、予め全部作っとかなきゃいけない。
極端に大規模な State Pattern とか Strategy Pattern を template と組み合わせて…みたいな。
そういう OOP は可能かもしれないけど、私は「気持ち悪い」。


>>939
Smalltalk「だけ」とは思わないけど…
C++ で手が届く範囲だけだと、ちょっと狭いと思う。

941 :名無しさん@お腹いっぱい。:04/03/21 01:43
Lispのコンパイラって?

942 :名無しさん@お腹いっぱい。:04/03/21 01:48
すまん。
動的に作成したmethodをどうやってnative実行してるの?
バリバリに実行環境に依存したコードだよね?ネイティブコードって。
複数プロセッサ(ネットワーク上)や異機種間の動作(RMI相当)とかは無視していいのかな。

943 :名無しさん@お腹いっぱい。:04/03/21 13:12
>>931
実行時の動的関数生成は C++ の設計思想と相反するから要らんけど、
無名関数は書けるようになって欲しい。STL の algorithm とか使い
出すと、

o 関数オブジェクトをグローバルに定義する
o mem_fun とかを駆使して関数オブジェクトを作る
o boost::lambda 使う

どれかの選択を迫られる。後者二つは C++ 標準の記法とかけ離れる
ことがしばしばで、ちょっと辛い。

944 :名無しさん@お腹いっぱい。:04/03/21 16:48
Javaの無名クラスも。あれはよいものだ。


945 :名無しさん@お腹いっぱい。:04/03/24 04:05
>>942
ごめん、内部はよく知らない。
# 見てみたけど、解析できなかった…

247 KB
■ このスレッドは過去ログ倉庫に格納されています

>>23
>>2>>78Vq>>35v>>21>>77@,Q>>39C>>35>>38>>56>>1>>85~b{>>67o>>89★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)