2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 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
>>2