Ｃ＋＋って使わないの？？

教えてください！
来月から、ＵＮＩＸの仕事をすることになりました。
いままでは、ＶＣ＋＋で開発してたのですが、
「Ｃの復習しといてね〜。Ｃ＋＋も使えるけど、
ＵＮＩＸはたいていＣだから」　　そんな〜〜！！
やっぱ、Ｃなんですか？？　クラスなんて要らないんですか??

くだらない質問はここに書き込め！なんでもアリ3
http://pc.2ch.net/test/read.cgi/unix/1002700894/

単発スレは嫌われます

いや、なぜUNIXではC++が普及しないのかってのは、
わりと面白い話題だと思うんだが。。

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

KDE/Qt

すみません。単発スレ以後気をつけます。

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

C++を使いこなせればCもオッケーなんと違うんですか？
ライブラリとかの使いこなしの話？

そう。やっぱ、一人で開発するわけじゃないから、自分だけＣ＋＋ってのも。
あと、客側もＣでやってくれっていうのがほとんどらしい。

> Ｃはとにかく危険すぎませんか。

んなこたない

Cの方がC++よりも危険だと思っている方が危険

1に同情上げ
C++使いにとってCで書かされることほど屈辱はないよな...
感覚的にはいきなり原始時代につれていかれていっしょに狩をするよう
なものだよ

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

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

高校生なみの論理だね >>1

> やっぱ、Ｃなんですか？？　クラスなんて要らないんですか??

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

オブジェクト指向といえばC++なのか悲しい。

「C++使い」とか自称してる奴でロクなコード書く奴見たことないよ。
qsortを使うだけで殺そうとまで思われるのか、
ドキュソとは仕事したくねえな。

何にクラスを使いたいのか分からないけど、
UNIXには普通MFCは無いよ。

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

>>14
火をつけようと思ってライターを使おうとしたら
上司に「これを使え」と、木の棒と板を渡されたら
殺そうと思いませんか？

たばこに火を付けようとして火炎放射器をいじっているところに、
マッチを渡されたようなものでは。

C++がCより優れてると思ってるやつは危険。

>>18
禿同。
向き不向きもあるけど、目的が達成出来るんなら
言語なんて何でもいいじゃん。

>>16,17
ﾜﾗﾀ

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

GTK+は変態

10年ちょい前に stallman がいろいろ語ってる。
でも結局 g++ だもんなあ
C++は不真面目な言語だと言ったのは誰だっけ

>>23
これ?
http://hp.vector.co.jp/authors/VA000092/jokes/strup.html

>>15
おいおい、既存のクラスライブラリを使うだけなのか。

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

　分析／設計／実装

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

それと　C だと

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

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

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

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

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

プログラムの勉強しているのですが、なぜC++はUNIXで使われないのですか？
UNIXで使われないのなら、どういうところで使うのですか？
マジレス希望

>>26
>>4

>>26
商用の開発ならUNIXでもC++使ってるって。
フリーソフトでも結構使われてる、と思う。

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

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

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

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

>>26は「なぜUNIXでメジャーでないのか」と聞いてるんじゃないの。
それだと>>4は答えになってないだろう。

>>29
ネタは sage てな。

>>C++は業務で顧客のための専用をソフトを書くようなときに使います。
日本語で説明して？

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

C++はCを使ってオブジェクト指向がかける言語。
純粋にオブジェクト指向を勉強したいなら適切ではない。

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

C++は主にGUIのソフトの制作者向けということでいいのでしょうか？

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

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

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

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

質問ばかりで済みません。
CとC++ではどちらが求人とかの需要高いですか？
UNIXだと主にC、WindowsだとVC++だから、
C++よりやはりCが多いと思うのですが、やはりそうでしょうか？

>>37 = >>26です。

>>36
そのレベルの「なんちゃってプログラマ」を前提とした場合には VC++ より VB 使わせておけ、というのが
Win32 界隈では妥当と思われ。

C++はｸｿ。Javaマンセー

>>40
>>21

>>37
両方とも需要はあるが、分野が微妙に違う。自分が何をやりたいのか、オープンシステム系の
開発なのか組み込みなのか、それを考えるのが先。そうすれば必然的に言語は決まってくる。

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

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

>>42
あ、まだいらっしゃった。
分かりました。
どうもありがとうございました。

何故C vs C++という構図になるの？他にも言語はあるのに。
そもそも「UNIXでC++が普及しなかった」のではなくて「WindowsでC++
がスタンダード」ってだけなので、まるでC++があらゆる環境のスタン
ダードであるかのような1の問題提起はおかしい。

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

C++よりJavaやObjective Caml（普及してないから実際には無理
だが）の方が使いたい。

>>45
そりゃ C, C++ の得意とする分野が重複するからと思われ。

もし26が学生さんならいろいろな言語を実際に使ってみるのがいいと思う。
求人が多いかといった観点でも、どれかが使えるよりはいろいろな言語を
使えるって方が重宝されそう。

UNIX板に全角英数のスレタイトルがあると浮くな

>39

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

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

俺の周辺だとUnixではC++よりもJavaかな。まぁSolarisだからだけど。
今でもそうかわからんけど、ちょっと前まではC++コンパイラが別ライ
センスになってて、使うに使えないって状況もあったしねぇ。

>>51
>・ＵＮＩＸ（というか、ＷＩＮ以外）には、使える簡易言語体系がない。
shとかawkとかperlとか(笑)
Solaris8以降はperlもついてくるし。
でも、最近はSolarisとかLinuxつかってても書ける人は減った感じ。

>・・・ってなわけで、ＰＧ、ＳＥとか、派遣会社の経歴書には
>書いてあるくせに、「ＶＢ、ＮＴならできます」
>（できるって、どんなレベルを「できる」といってるんだゴラァ！！！）
>みたいなやつを相手にするときは、Ｃ＋＋は便利です。
でも、それは出来上がるものが怖いような...
そういう人にはJavaの方がいいかもねぇ。

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

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

>53

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

Ｃはやっぱポインタでセグるからさ・・・
徹夜明けで集中力がキレたときなんかやっちゃうよね。。。
その点、ＳＥＤやＰＥＲＬはラク。ＪＡＶＡもいいよね。

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

>>54
C++ の参照は

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

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

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

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

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

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

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

そんなさ、頭いいことカンケーなし。

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

なんか、ダメプログラマに対する愚痴スレっぽくなってきたな。

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

ごめそ。戻そう。

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

メンバー全員が本当に技術力がある（そんなことあるのか？）
・・・・このばあいは、なんでもいいとおもうよ、マジで。
Ｃでもいいし、Ｃ＋＋をベターＣとしてつかってもいいし、
本格的オブジェクト指向してもいいし。
ＵＭＬでもデザインパターンでもＲＯＳＥでも、なんでも使ったら？
どうせならＬＩＳＰとか使ったら？ＣＰＵパワーあまってるし。

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

上位も下位もダメ（実はほとんどの場合はこれ）
・・・・ＣＯＢＯＬかＶＢ。

> ごめそ。戻そう。
戻してない (w

だれかカーネルをC++で書こうとしたやつはいないのか?

>>61
BeOS?

>>62
え? そうナノ?

CさえマスターしときゃC++もいずれ使えるようになる
あとはアセンブラ覚えれば何とかしのげる

こんなもんだろ

>>61
あと、WinNTもそうだね。おかげで開発が大混乱したっていうのは
「戦うプログラマー」に詳しい。

たぶんOOPはカーネル作るのに向いてない。
無駄が多すぎる。
そもそもOOPなんて作る側の都合だろ?
動かすほうにはあんまり関係ない。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　＿＿＿＿＿＿＿＿
　　　　　　　　　　　　　　　　　　　　　　 　　　　　　　／
　　　　　　　　　　　　　　　　　　　　　　 　　　　　　　|　さァ >>1 はスグそこだ！
　　　　　　　　　　　　　　　　　　　　　　　　　 　　　∠　　トバすぜ相棒！
　　　　　　　　　　　　　　　　　　　　　　　　　　　/ ） ＼＿＿／￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　　　　　　∧＿∧　　/ /　　　　　 |　お・・・おゥ！
　　　　　　　　　　　　　　　　　　 　（　 ´Д｀） ./ /　　　　 ∠＿＿＿＿＿
　　　　　　　　　　　　　　　　　　／　　　 ＿二ノ
　　　　　　　　　　　　　　　　 ／／　　 ミ ｸｲｯｸｲｯ ／￣￣￣￣￣￣
　　　　　　　　　　　　　　　　（＿二二づ＿∧　　｡o　・・・コーフンして俺の耳引っ張んじゃねェよ
　　　　　　　　　　　　　　　　　/　　 （　 ´Д｀）　 　＼マジうぜェな・・・コイツ
　　　　 　　　　　 -=≡　／⌒（　ヽ／⌒ヽ/＼　　　　￣￣￣￣￣￣￣
　　　 -=≡　.／⌒ヽ,　 /　　　 ＼ ＼　＼＼　ヽ／⌒ヽ,
　　 -=≡　 / 　 |_/__i.ノ　,へ _　　/　）／ ＼＼/　 .|　/ii
　　 -=≡　ノ⌒二＿＿ノ__ノ　￣ |　/　i　/ .＼ヽ　 |./　|i　　　 　　　　　　　　　　 （（ （ ）））
　　-=≡　()二二)― ||二)　　　 ./ /　/ /　()二 し二) ―||二)　　　　　　　　-=≡（Д｀；　 ）　ｳﾜｰﾝｷﾓｲﾖｰ！
　　-=≡　し|　　| ＼.||　　　　　（　ヽ_（＿つ　 | 　　|＼ ||　　　　　　　　　　-=≡　/　つ_つ
　　　-=≡　 i　 .|　　ii　　　　　　ヽ､つ 　 　 　 i　　 |　 ii　　　　　　　　　　-=≡　人　 Y
　　　　-=≡　ﾞ､＿ ノ　　　　　　　　　　　　　　　ﾞ､ ＿ノ　　　　　 　　　　　-=≡　し'（＿）

昔は、linux-kernel で「C++でカーネル書くのはどうよ？」ってポストが
（わりと）定期的にあったと思うけど、最近はどうなのかしら？

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

solarisのvfsはC++で書きなおしてある。

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

icewmもc++で書かれていますね。
使っている人は使っているようです。

C++だとアセンブリファイルの構造がコンパイラごとに全然違うというのは
普及の弊害って聞いたけどどうですか？おれC++よく分からないんでなんとも
いえないんだけど。

>>68
Linux 板で定期的にあるな。

Ｃ++は分析、設計には向いてるがコーディングには向いていない気がする。
Ｃ++を採用することによる分析、設計面での長所をコーディング面でのデメリットが凌駕している。
業務系アプリ等は分析、設計、コーディングをそれぞれ別の人間がやる事が多いのでＣ++でもいいが、

UNIX での C++ って、まぁ、不幸だな。

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

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

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

KDE/Qtのこと、みんな忘れないでネ

つーか、C++がここまで流行ったのはMSのおかげなんじゃないか
とさえ思うんだけど。。

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

gtk-- って興味あるんだけども
日本語ドキュメントって皆無じゃない?

あったら教えてん。

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

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

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

Ｃ言語だってデファクトなライブラリ無いじゃん。

>>77
そうだろうね。MS の開発言語としての C++ が普及したのだろう。
他に目を向けてみりゃ ObjectiveC だったりするし。

>>80
C の場合は UNIX 自体がデファクトなライブラリじゃないの?

>>82
そういう見方もある。
しかしそれはＣ++にも当てはまる。

>>70
それは知らなかった。
確かにVFSがクラス継承使って書けるとハッピーですなぁ。

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

>>85
オブジェクト指向を意識しているのと実際にオブジェクト指向言語で書いてあるのとでは、
サブクラスを書くときの手間がぜんぜん違うよ。

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

Xt が傑作とは思わないなあ。
よくぞCであそこまで頑張った、とは思うけど。粘着って感じ。
あれのやりにくさのせいで X の GUI が進歩しなかったんでは
ないだろうか。

Xt な app resouce のいじりかたとかで OO って何なのかを学んだ人って
意外と多いかも。code うんぬんはおいといて。

>>85
> 優秀なプログラマは C でも、アセンブラでさえもオブジェクト指向できるのさ。
アセンブラさえあれば原理的には何でもできるわけだが、Ken と Dennis は UNIX kernel を（当時の）
高級言語 C で書いたよね。

>>89
その認識は大事なことだ。

>>78
ほれ。
http://www.interq.or.jp/earth/inachi/gtk/gtk--/tutorial/html/tutorial_ja.html

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

優秀なプログラマなら、JavaでOS（使い物になる）書ける？

>>92
Java で H/W に食いつく部分てどうやって作るの？

JNI?

いらんつっこみ。
>>89
最初期の UNIX は C で書かれたわけじゃないよ。途中、UNIX を
書くために C を作り出したような感じ。

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

さらにいらんつっこみ
>>95
>最初期の UNIX は C で書かれたわけじゃないよ。途中、UNIX を
>書くために C を作り出したような感じ。

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

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

Unix自体を C++で再実装しなおせば、APIが method呼び出しになって
幸せ。ってことですか?

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

>>97
んなこと無い。しっかりしろ

６４

>>97
そうだぞ、しっかりしろ。
STREAMSじゃなくてC++でクラス使ってモジュール性を確保していれば、
いろんなデバイスドライバがもっと楽に書けたって話だ(嘘)

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

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

>>102
そういうlibcつくれば?

煽りではないのですが、素朴な感想として．．．

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

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

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

>>104
禿げ同

じゃぁギャラ上げて。

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

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

>>107
そんなこたねーだろ。

>>107
C++ が複雑なのは確かだが、不透明と言うのはどうかなぁ。むしろ透明度が高くて、実装が
見えすぎるぐらいだと思うが。

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

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

>>104
だから環境によるって。
Windows 環境なら VC++ が主流（VB除く）だから自動的に C++ を使うことになるだろうが、
C++ で書かれたライブラリが C で書かれたライブラリより圧倒的に少ない（たぶんPerlより少ない）
UNIX でわざわざ C++ を使う気になれない。g++ の STL サポートが今一なのも含めて。
C、Perl、Java でこと足りる。

>>111
UNIX 以外でも C, C++ 以外でデファクトスタンダードになっている汎用高級言語ってあるのか？
まぁ VB や COBOL はある意味スタンダードだが、C/C++ の代用にするのは無理だし。

>>112
既存のクラスライブラリを組み合わせてすむ程度のソフトウェアに関しては、正直、どうでもいい。

>>112
>g++ の STL サポートが今一なのも含めて。
いつの話だよ

>>114
つーか普通ライブラリの一つや二つ使わないか？
もちろん C++ から C のライブラリ呼べるけどさ。何か居心地悪い。

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

>>116
C ではなく C++ と言ってるのは、オブジェクト指向で分析／設計／実装やろうって話でしょ。
クラスライブラリがあると実装で楽をできるけど、はるかに比重が高い分析／設計の方は
手助けしてくれん。

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

>>117
OO で分析設計して C で実装じゃだめ？
Gtk+ のごとく。

>>118
マジレス

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

>>119
Cか…。
Gtk+はまだしも、Bonoboは悲惨だと思うのは俺だけじゃないだろう。

>>119
C++ が存在しない時代ならともかく、今は勘弁してください。

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

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

いや、XPCOMはそう使いにくくないと思ってるんだけど…。
まぁいいや。

ヘッダより先にコードを見るもんで。
コードの海を泳いでいるうちに溺れた。

>>124
あー。インターフェイスがしっかりしていれば、
中身はリファクタリングする一方で良いってことか。すまん。

MFCにはwin32apiのラッピングクラスがあるからのう・・・
WindowsではC++のみでもいけるかもしれんがのう・・・

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

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

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

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

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

>>130
それがベターCでしょ。

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

>>131と被った。

最近のCの規格だと//のコメントも途中での変数宣言もあるよね。
inlineとかconstも入ってたと思う。

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

Pythonで十分

>>135
オレはPerlで十分だと思う。
Perlでバイナリファイルいじくっている毎日だし、
OOなプログラミングもできる。

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

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

言語の良し悪しよりもどれだけライブラリが充実してるかだな。

>>135 >>136
いったい何が十分なのだ?
自分にとってなら、好きなの使えば良い。
だがスレ違いの話のような気がするが。

>>139
彼らが組むプログラムは 10 分でできる使い捨てプログラム、という意味かと（嘘）

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

このスレはUNIXのアプリケーションを何で組むかって話じゃないの?
どうでもいいがここでいう「UNIXアプリケーション」とは何だろう。
httpdとかじゃあないよね?

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

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

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

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

>>144
残りません。

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

>>144
ヒープから割り当てたメモリ(new/malloc)はプロセスの所有物なので、
プロセスが消えれば一緒に消える。昔のWin95は残るケースがあったと聞くが…

>>143
無茶な仕事は断る。コの業界で長生きしたければ、デスマーチの香りをかぎ分ける嗅覚は
必須です。

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

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

>>148
それこそfjで（以下略

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

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

>>142
「C++ のコンパイラって buggy ですか?」
ベンダにもよるしバージョンにもよる、ってのは無し？

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の不毛な議論をドウゾｗ
たぶんスレッドの先頭じゃないから、マジメによむなら適当に発言辿ってくれ。

>>150
これだな。

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

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

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

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

>>154
> Ｃでクラス（と同等のもの？）なんてできません。おおかた、構造体と関数への
> ポインタの組み合わせとか考えているんだと思うけど。
やってやれないことはないけど、メンテナンス不可能なコードになるから実質的には無理ですな。

C++信者うぜー
一生Windowsと暮らしてろ

lispだよ、lisp
C/C++なんて捨て捨て

>>156
いや、だからUNIXのC++の話だんべよ。
（俺は、プログラマ板から来たWin屋だけどね。よくわかたね。）

>>157
Lispいいの？興味はある。（C/C++捨てんけどな。w）

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

UNIX だと Perl あたりで十分なコトが多いからなぁ。
C か C++ かと言われれば迷わず C++ だけど。

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

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

158では、ちょっとぞんざいな口調になってごめん。

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

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

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

>>160
趣旨はわかる。でも「1年がかり」じゃなくて「1月がかり」くらいから、
C++でよいのでは｡｡｡

>>162
一ヶ月は微妙な線だけど、
まともなライブラリをドキュメント込みで作ろうとすると、
最低一ヶ月はかかるよ。

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

>Ｃでクラス（と同等のもの？）なんてできません。

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

けど>>155は正しい。

うちはUNIXで特殊分野向け計算エンジンの開発やってるけど
C++使ってるよ
GUI一切無いコマンドラインプログラムだけどC++で作ってる

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

>>165

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

あ、そ。ただのPGのくせにうだうだぬかすな。

PG?
プレイガ〜ル（ダミ声）？

>>164
私も>>155に同意。UNIXじゃないけどActiveXのコードをCで書いた例をみて驚いた。

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

ところで、
VC++　5.0だかの巨大な（奥行き５０ｃｍぐらいある）パッケージを見て、
「だれか止める奴はいなかったのか」
と思ったのは私だけ？

>>167
素人はだまっとけ(W

>>160
> 0 からつくるなら、Cでバシバシ組んだほうが早い。
私は STL が使える時点で C++ ですね。設計を OO でやるかどうかは別として。

>>172 同意。というか、OO抜きでSTLだけならだれでも７日も
あれば覚えられるだろうに勿体ない。といつも思う。

通しで読んでいると、>>24(Stroustrupの冗談)の話題が出ていたの
で．．．

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

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

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

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

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

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

うーーん。
「スピードが重要」かつ「巨大」なものなら
C++ がいいというのには同意。STL もいいし。

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

ﾅｲｽｽﾚ

>160
うーん、おいらが厨房だから C で書いた方が早いってのが
わからないなぁ。 C++ の方が C よりもコンピュータに任せられる
部分が多目で、楽に早く書けると思うんだけど…

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


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

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

>>175
>「スピードが重要」かつ「巨大」なものならC++ がいい

可哀相に（ｗ

>>164
C++で書いたものをCにコンバートする意味って何？
C++が読み書きできるんなら、それでいいじゃん？
コンバータの存在は、単に、C++の読めないプログラマの
不安解消だけなんじゃないの？

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

コンバータの吐いたＣコード見たことあるけど、
ライブラリ任せにするだけで、少しも「いいプログラム」じゃなかったよ。

>>129
> Interviews なんてのもあったね。
> 今となっては歴史的な存在だけど、これの研究成果の一部は今の OOP の世界にも生きてるよね。

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

トランスレータってプリプロセッサみたいに考えちゃだめだよ。
C++ -> Cのコンパイラと考えた方がいい。
Cコンパイラがアセンブリを吐くからといって、アセンブリでプログラム
書くわけじゃないでしょ。

メンバ変数を全部インラインで書くと
ほとんどＪＡＶＡと同じ感じ・・・

>>183
でも、そうやるとヘッダーに書くことになっちゃうんだよね。
リンカがへぼいとマズーだし。

>>184
テンプレートとか使うと・・・。

>>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 …"でも読んでくれ。

つーか一段階一段階極めていきたい俺はCに固執しちゃイカンとですか？

学習コストはどうよ。
C をしらずにいきなり C++ を使いこなせる?
個人的には無理だと思ってるんだが。

いや、むしろまっさらから教えるならC++のほうが楽だと思うが。

>>188
「使う」のは可能だが「使いこなす」のは無理。

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

>>190
そう？　Cを知らずにC++から入っていっても、使いこなせるようにはなる
と思うけど？　確かに、そこまで到達するにはそれなりの時間が必要。け
ど、C++を勉強するためにまずCの勉強から入る場合と比べてどうかって
ことであれば、不利になるとも思えないな。

でも、最初からC++に入った人を見たことない。実はけっこういるのかな？
JAVAから入ったってんなら、それなりにいそうだね。

まず軽くＣを通してＣ++（クラス〜）に入ればいいのでは、と思うが・・
基本的設計はＣ++固有の知識だが、実装は実質Ｃなのだから・・・

C++にいまからはいるやつ。

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

>>194
ネタは sage でな。

>>192
＞最初からC++に入った人を見たことない。

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

>>196
肥溜めにウンコ状態だね（ｗ

ドキュメント無しで､ソースを引き継がなきゃなんないとしたら、
C++ のほうが嫌だが。

>>多いかどうかは知らないけど、周りは似たり寄ったりです。

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

>C++を勉強するためにまずCの勉強から入る場合と比べてどうかって
>ことであれば、不利になるとも思えないな。

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

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

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

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

Linkerもフェ

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

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

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

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

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

C++？
あんな煩雑な言語使えるか。
Keep it simple, stupid!!

>>203
単純なコードを記述できるようにするため、言語やライブラリを拡充させるという方向は KISS と
矛盾しないと思うが、どうか？

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

//難しいか？　>>203
#include <iostream>
using namespace std;

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

>>205
複雑怪奇。

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

>>206
じゃあ

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

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

>>205
その << を実現するための仕組みを利用しようとすると
ad-hoc さ加減にうんざりしてくる。

>>208
話が逸れますが、もし、

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

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

C++のキャッチコピーを考えた。
「地雷を踏んだらサヨウナラ」
パクリでスマソ。

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

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

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

>>210
「なりそう」、とか「思う」と書いてると言うことは、実際に自分で使った上で判断したわけではなく、
単なる思い込みということでよろしいか？

>>211
思い込みでよいです。
但し、自分で使ってみて、自分は大丈夫だが、
他の人には無理だろうという、極めて傲慢な。

>>212
日本語を話せよ、あんたは

>>213
使ってますが何か？

>>214
213 はかなーりマイナーだが、元ネタつきのネタ発言と思われ。

結局 >>210 >>212 は

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

と主張してるの？

>>207
なんで、りたーんに、かっこを、つけるの？

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

>>216
> それから、０しか返さないなら、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. (以下略)

>>216
mainの返り血はintって、規格で決まってるんじゃなかったっけ？　つか、
それってCでも同じ。void mainって書くと警告出されるけど？

>>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[])

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

>>210
>Cより安全というのは嘘でしょう。
>Cもポインタ絡みで危険は多いが、
>C++よりは圧倒的に言語仕様がシンプルなので、
>(というかC++は、どの言語と較べても複雑すぎる）

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

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

自分でしかコード書かないのだったら better C として使っても
いいけど, そうでないんだったらやっぱり統一するのに難儀するんじゃない?

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

>>222
正直、憶えることが多くて面倒くさい＞C++

それならJava勉強するわってなる。

Javaが悪いなんて一言もいっとらんぞ。
Javaで済むなら、それもよいだろうさ。

>>224
べつに C++ ではなく Java という選択肢をとるのは構わなんよ。現実に Java の方が向いてる
領域もあるしね。ただし、

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

のは禁止。

>>226
激しく同意。いいこと言った。

面白いことは面白いんだけどC++。
言語自体がパズルめいて楽しいというか。
STLなんか特に。

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

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

>>228
なんかそれ分かるよね．Effective C++ とか More... とか読んで
「うげー，複雑やのう・・・」
って思ったけど，逆になんか面白さが増したっつーか，好きになれた感じ．

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

Javaでのパフォーマンスチューニングは難しい。

>>228
基本的には同意なんだけど。
> プログラミング好きにはJavaは物足りない。
ってのにはちょっと異論あり。

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

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

>>231
比較するなら、素の C++ ではなく

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

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

Javaは潔さの勝利だと思う。AppletやNCでダメになりかけて、
死の淵をさまよったあと、Serverサイドで見事に復活した。
なかなかドラマチックだ。

C、C++共に使い、過去にはC++に傾倒していた時期もあるけど、基本的にはC好き。
JavaもPerlももちろんやるけど、どの言語を選択するかはミッション次第かな。

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

C、C++、Javaともに使い、過去にJavaに傾倒した時期もあるけど、基本的にはC++が好き。
どの言語を選択するかはミッション次第かな。

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

C++をbetter Cとして使うのならいいけど、
オブジェクト指向だからCより優れてるとか言うのは違うと思う。

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

>>236
> あとC++の例外って使いにくい。
C で setjmp() を使うよりは 256 倍 楽と思われ。

>>236
ベターCならCを使えよ。
Ｊａｖａの例外なら使いやすいのか？違うだろ。「例外」そのものを扱えないだけだろ。
（C++はJavaと違って、例外を扱えないやつでも大丈夫になってるけどな。親切だろ。）

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

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

漏れもC++からプログラムに入りました
C++を勉強しだすと自動的にCも勉強しなければならなくなりますが
C++はCに比べて確かに複雑で覚える事が多いんだなあと思いました

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

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

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

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

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

>>241
そういえば C だとスタック壊したことは何度かあるけど、C++ だとないなぁ。

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

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

「Ｃ言語→ベターＣ→ＳＴＬ→ＯＯとＣ＋＋」
はどうか？
”可能かつ効率的かつ実践的かつ興味を持続しやすい”と思うのだが・・・
要は構造化の流れの最後にＳＴＬをもてきただけなのだが。

>>243
もはや UNIX と関係ないし。sage よう。

>>216
＞それから、０しか返さないなら、mainもvoidでいいと思う。
これって、ステータス値ちゃんと 0 になるの？
UNIX のバッチ系のツール作る場合だったら、俺なら絶対やらないけど。

>>245
> これって、ステータス値ちゃんと 0 になるの？
ならない。たとえばia32だと%eaxが返り値になるが、voidの時にわざわざ
xorl %eax,%eaxしたりしない。

>>246
>ならない。たとえばia32だと%eaxが返り値になるが、voidの時にわざわざ
ありがとう。やっぱりそうなんだね。

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

いつのまにやら本題とずれまくってるんだが…
UNIXでC++があまり使われない理由は
・UNIX（Xでもいいや）のアプリケーションを作るための
　標準的なクラスライブラリがなかったから
・Cを愛しすぎてC++をよく知らずに毛嫌いする輩が多いから
てなとこでOKか？

>>248
そのへんが標準的な見方だろうね。コンパイラ (g++の2.7台くらいまで)
がヘボヘボだったってのもいれていいかもね。

>>248 >>249
冷静な意見だな。サンクス。

groffってC++じゃなかったっけ?

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

>>251
> groffってC++じゃなかったっけ?
C++だよ。リリース当時(10年くらい前だっけ?)、コンパイルできなくて萎えた。

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

>>252
"Hello, world!" >> endl >> cout;
だったらそれなりに受け入れられたと思う(藁

こんな感じか?

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

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

>>254
実際には Plan9 が研究されているのは Lucent のベル研
(www.bell-labs.com) で、いま Stroustrap がいる AT&T の
旧ベル研 (www.research.att.com) とは別の組織。

>>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%

cygwin gcc + STLportの結果も必要
これだとSTLの評価としては意味ないでしょ

>>258
C と C++ w/ STL の大雑把な比較が目的。

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

>>255
> // 最近はGnome系を筆頭にupper layerで良く変わるんだけど。

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

>>257
> OS　Windows 2000 SP2
> CPU AthlonXP 1600+
> コンパイラ　Visual C++ 6.0 SP5　(コンパイルオプション /O2 /MD)

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

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

>>259

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

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

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

おお、なんか詳細なレポートが書かれてる!!ありがとうございます。

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

>>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 番目の総実
行時間以外は信用できませんので無視してください。

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

>>265
あれ？>>257とずいぶん数値も割合も違うね．

>>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 使ってないと無意味な数値しか返っ
てこないから、実行時間だけ抜いてきた、と。

>>265
ありがとうございました。お疲れさまでした。

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

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

>>270
timeの総実行時間なんだから、プログラムの起動〜終了までの計測だろ？
思い込みの激しい奴だな。

>>270
> プログラムの起動〜終了までの計測
time 使って計測してる以上、CreateProcess() してから、そのプロセスが終わるまでの時間ですよね。

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

>>266 が何を言っているか理解できないのは、私だけ？

JDK1.4になるとさらに速くなるね、Javaは！
もうそんなに速くしなくていいよって感じ。

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

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

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

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

>>276
Swing が使いモノになれば MFC 捨てて Java で書ける仕事も多いのに、という意見。性能面では
不満ないし、ライブラリも充実してるしさ。

Java1.4でやっとホイールスクロールに対応。
動作は相変わらず鈍重だが、たまーに速くなってるなと思わせてくれる時がある。
＠Celeron400

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

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

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

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

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

>>271
う、その通り。なんか寝ぼけていた模様...逝ってきます。

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

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

>>281
非標準だけど hash_map や hash というコンテナを提供してる実装もあります。プログラミング作法
では IRIX のコンパイラで hash をサポートしていたので試してみたが map と差が出なかったとの
こと。

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

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

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

g++を(SGIのSTLを)使ってるなら #include <hash_map> で自作は
まぬがれますなぁ。漏れは把握してないけど、ほかの実装にもあるんじゃ
なくって？できれば <map>, <hash系map> の両方示して欲しいなぁ。

>>265
ご苦労さまでした。文句無くおもしろいデータです。

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

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

STLport には hash_map あるから試すのは簡単ですが、ハッシュ関数はどうします？

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

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

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

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

>>285
Cのをうまいことハメられないですか?

mapじゃなくて、連結リストとかvectorで比べてほしい。

>>287
そ、その心は。

>>282

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

>>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;
　　}
};

なるほど
まぁそんなものかなという感じです。
ありがとう>290さん

>>290

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

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

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

某社の面接説明会にて
おそらくはエライお人の弁

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

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

「ではVBの時代が終わった時に御社は対応できるのですか?」
「本当に能力のある者ならば言語の違いなどは、取るに足らないことでしょう」

サゲだサゲ!!

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

彼氏はいますか?

>>295
多重継承はもちろん、仮装関数だって、使いたくなきゃ使わんでよいでしょ。

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

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

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

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

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

int i = 0;
cout << i++ << i++ << i++ << endl;
この動きが感覚的に合いません。

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

>>298
たしかに。でも、
printf("%d %d %d\n", i++, i++, i++);
の動きは感覚に合います？

>>300
まったくその通り。Cは、どうしてそうなるの？

>>301
シーケンスポイントで検索してみよう。

>>302
了解しました。未定義言語仕様領域ですか。

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

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

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

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

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

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

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

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

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

ＯＯＰの肝は「データとその操作を固めておけること、そして抽象化できること」に尽きるね！
「警鐘による再利用」とかいいだす奴には近寄らんことにしてる。

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

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

> ＯＯＰの肝は「データとその操作を固めておけること、そして抽象化できること」に尽きるね！
> 「警鐘による再利用」とかいいだす奴には近寄らんことにしてる。
ということで、構造体と関数ポインタで充分じゃんてことになりましたとさ。

>>304
> やっぱＯＯＰの肝はデータ隠蔽だよね。
それは勉強不足だなぁ。べつに従来の手法で事足りているならＯＯを勉強する必要はないけど（はっきり
言ってＯＯが向かない分野だってあるし）、勘違いしたままでＯＯを批判すると的を外すので注意。

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

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

>>308
抽象化ができないなー、構造体と関数ポインタじゃ。

>>309 がいいこと言った、ような気がする。
でもこのスレは C++ の是非を論じるスレではないでしょう。

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

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

310は戯言だった。忘れてくれ。

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

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

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

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

>>313
とりあえず ftp://どっかのGNU mirror/gcc/gcc-3.0.2/gcc-3.0.2.tar.gz
いっとけやコ゛ルア

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

まだ gcc-3.x は使うのが怖いぞゴルァ。

いつまでもそんなこと言ってっからいまだにUNIXでC++が普及ねえんだよゴルァ。

STLはtemplateコードでしかないからUNIX上の云々は忘れてしまえコ゛ルア

gcc-3.0.2は、C++使う分には、問題ないのでは？

難しいこと考えずに使い分けりゃいいの。
C++で書くのが適切であるならそれ使えばいいし
どれでもいいなら好きなもの使えばいい。

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

>>320
1日1回リセットって、たいして安定しているわけでもないような。

>>320
リセットなしはDRAMを使っているマシンでは冒険。
5分止めたら切腹ってケースでは使えない。

BC++を使いましょう。

C++なんて現場じゃ使わねぇなぁ。
研究者の言語だろ？

>>324
Windowsの現場では使ってるようす。

またC++信者がさわぐからほっとけ。

>>325
最近は、一部の組み込み機器でさえ使われてるが。

あの。
使ってますよ。Ｃ＋＋。ユニックスでも。
どういう、基準でクラス化してるのか、さっぱりな感じですが・・・。
Ｃ＋＋使う前に、それを使うメリットを学んでほしいと思った。

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

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

>>323 >>324 >>328
UNIX specific な話でないなら、スレ違いなんだから sage てくれ。

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

でしょ

アプリ等の応用レベルならどんな言語を使おうと勝手。
目的に合ったライブラリがそろったものを選べ。

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

シーぷらぷら

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

>>332
っていうか、なんと呼べっていうの？

Ｃ＋＋信者なんてまだいるのぉ？（ｗ

昔 C++ をなんて読むのかわからなくって
某ユーザサポートに電話かけたついでに
聞いたことがあったような…
向こうは さぞあきれてただろーなー

もー 8年ぐらい前の話

「しいぷっぷ ♥ 」が正しい。

よっぽどC++が嫌いな人がいることがわかった。
「C++嫌い教」信者だな。
もういいよ。好きにしなよ。
まあ、ウソ八百を若者の前で言うのはやめてほしいけどな。

よっぽどC++が好きな人がいることがわかった。
「C++好き教」信者だな。
もういいよ。好きにしなよ。
まあ、ウソ八百を若者の前でいくら言ってもいいけどな（藁

off topic な話題は sage でやれ。

「ぷらぷら」なんて呼ばずとも職場内では「プラス」で通じるからねえ

しーぷら
ちんぷら

しぃたすたすでしょ。

マクロス++

Ｃインクリメント

俺の歌を聞け聞け！

会社に来たどうしようもない中途採用が「インストゥール」というのが気になります。
風の神様のハストゥールのトゥールと一緒なんです。
気になります。

>>347
インストロールよりは良いだろ（ｗ

インストロールは分かってていうからいいけど
心の底からホントにインストゥールだと思ってる節があるのが怖い。

いあ！いあ！

ディスクトップとかもな。

>>347
対抗して、いんすたー って読んであげれ。

>>350
OpenBlock のことか？

>>336
そんで何て読むんだよ。
何で肝心のことを書いとかねーんだよ、ｺﾞﾙｧ！

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

おれには「すぃぷらっぷらっ」に聞こえたぞ。

外人は、ちゃんと律義に
「しーぷらすぷらぁす (最後にアクセントがある)」
っていってるぞ。

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

しーたすたすって読んで笑われました

ぼくは拡張子をとって「しーぴーぴー」って呼んでいます。
ちなみにC++賛成派です。

>>356
じゃあ、i++ はなんて読むの?

先日 "C++" を "C incremented" と呼んでる人に出会った。
また新たなカルチャーショックが(藁

>>357
C のプリプロセッサはなんて呼ぶの？

自分の新レスがこんなに続いてるなんて・・・。
ずっとＶＣ＋＋だったので、当たり前のように使っていたＭＦＣが使えないというのは
かなりショックでした。
確かにＶＢ，ＶＣばっかりだったらバカになるかも。
ヌルなんて意識したことありません。ヤバイなぁ。
頑張って勉強しなきゃ〜〜〜

>>361
VC なんて、余計 NULL を意識しなかったら例外の嵐だと思うのだが
VB とて Null と全く無縁ではないし

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

>>362
NULL, Null といってるが、何をさしてるのか明記しないとワケ分からん。C/C++ の null pointer
constatant?

あんまりよく知らなくても組めるMFCが嫌で（根本から理解したいクチ）
自分でイチからやってったんだが
そうしたら何かアセンブラもやらねばならんような気がしてやり始めた。

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

>>364
Winなら最高の近回りジャン。

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

VisualC＋＋のMFC　クラスを使ったプログラムだが、
あんなものを使って、きちんとしたPG作れるのが不思議だと思う。

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

UNIXはJAVA＋SHELLが多いんでない？

>>364
板違いだけど、マジレス。

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

もとから知りたい人間だと
コンパイラも作りたくなるってもんさー。

コンパイラ作るとなると、C++は仕様がでかすぎだYO!

compiler 作る場合は Scheme が best ?
って激しく話が外れたな。

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

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

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

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

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

>>372 s/養護/擁護/

何年か前までCがメインだったけど今ではC++以外考えられない。
Cの前はAda使ってたこともあったし言語にはあまりこだわりない。

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

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

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

単なる余談なのでsage

>それとtry&catchをいたるところで乱用されたりすると
デバッグが大
変なんで

そうかな？

エラーではない例外を多用されるとしずらいかもね
書き方によっては

UnixでC++が使われない理由・俺バージョン：
　man(1)で標準ライブラリのリファレンスが読めないから

>>375
ちゃんとthrowしてくれればいいんだろうけど
throwする事をヘッダに明記しておいてくれないと探すのは
結構大変だと思う

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

>>378
C++のthrowに指定してないものを投げてもコンパイル時にエラーに
ならないですよね?
それで、実行時にunexpected()が実行されるんでしたっけ?
なんか、使いにくくないですか?

>>375
複数で作るときにきちんと取り決めして、それに従って書かれて
いればいいんですけどね。

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

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

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

ム板よりはるかにまともな議論になってる・・・
ここはT大生とか多いからか？

>>379
はっきり言って使いモノにならない。

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

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

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

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

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

要するにランタイムエラーと例外はちゃんと分けて
考えようって事だね

「例外だけは例外で」と説明されたときには
どう突っ込んでいいものやら迷った。

>>381
同じ職場で高卒でも能力によっては大卒より
高い給料がもらえる職業だけどな

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

>>385
なんか、微妙に実のある方向に話が進んでますね :D

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

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

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

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

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

>>374=389
でも new が bad_alloc を throw したりするんでニンともカンとも。
けっきょく、例外を投げるか戻り値で返すかという議論の答えは
「好きにすれば」になりそうでコワい。

投げたらアカン。

>>390-391 このスレ、年寄ばっか?

>>390
最終的にはそのプログラムによると思うんだけど
漏れはほとんどの場合newするときはtry-catchで
bad_allocを検出してます

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

補足
もちろんnewしてる関数内でtry-catchしてる訳ではないよ
それだと返り値判断とかわらなくなっちゃうから（ｗ

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

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

>>395
さらに、dtorに後始末を任せるprogramming styleが、例外の醍醐味なのにね。
"exception safeなctor"って何なのか調べるべきだな。>>389
Exceptional C++でも読んで。

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

>>397
C, C++ 問わず大域脱出を使っていないわけですね。ま、それはそれで幸せかも。

>>396
あとは例外を階層化できるのも利点ですな。

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

例外処理なら「ExceptionalC++」。嫁。

More Exceptional C++ モナー
http://www.amazon.co.jp/exec/obidos/ASIN/020170434X/

>>400
よさげな本ですね、書店で探してきます。

ＵＮＩＸ派って、なんだかんだいってもただの
手続き型言語であるＣ使いなんだね。要するに力作業。
Ｃ＋＋の本当の良さを知らないからＣでじゅうぶんだと言ってる連中もいるし。

この辺で煽ることはないと思われ。マターリな。

>>404
UNIX 派と一括りにするのは、よくない。それいったら Win 厨だって VB で十分とか言い出すヤツは
たくさんいるんだし。

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

議論がループする予感。

>>407
俺は 404 は逃げるので、議論にならないに一票だな。

別にVBでもVCでも何でもいい。
人が何使おーが知ったこっちゃない。そんな金にならん事をグダグダ言うよりも
明日のオマンマだ。

>>409
VB の仕事は単価安いから、あまり腹がふくれないけど。

力作業って言われてもねえ。"一流プログラマ"とやらが書いた
C++よりもBernsteinが書いたCの方が信用できるし。

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

明日のおまんまより今日のおまん○

ＵＮＩＸは力作業派が多いね。よくＣでいつまでもガリガリやってるよ。

Ｃしか使わないから、サイズがでかいという理由でＷｉｎを認められないんだな。

確かに、みぢかくて無駄のないCプログラムは美しいな。
（若くないC++使いはたいてい元C使いだからそれはわかるのだよ。）
でも長いプログラムであの美しさが維持されることはほとんどないだろ。

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

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

>>413-414
ネタは sage でな。

>>415
tcsh だの sendmail のソースに手を入れるのは、正直疲れすぎ。

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

sendmailって、設定から疲れすぎな俺は、何？

あがってる。
>>400 さんくす。
全部読んでないけどいいな。明日の予定は読書だ。（ｗ

あげ

漏れの場合、使わないんじゃねーよ。使えねぇんだよ。

つうか門すら叩いてないぞ。
つうか「C++やりたい人はコチラ」の案内板すら見てないぞ。
つうか頭にすらやる気が起きてないぞ。

今のところはな。

C++なんてそういう言語があるということしか知らないですが何か？

1です。
UNIXの開発をはじめて２週間がたちました。
Cのみですが、基本はCということを改めて痛感してます。
ところで、UNIXでC++で開発してるのは全体の割合でどれくらいなんでしょうか？

基本は汗だと心得よボケがぁ。

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の同じくらいだと思う。

大文字の C はhitしない？

>>427
しませんでした

>>425
ボケというほど無茶なことは言ってないと思うが。

回し者？

>1,424
そもそもUNIXの種類に応じてC++コンパイラの品質に著しい差があるんだから。
AIXではその比率は多いと思われ。

>>429

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

C使いのじじい供は現代のコボラーだと聞きました。
本当でしょうか?＜図書スレ＠ム板

Ｃは力作業。

アホではこのスレについて行けん。
修行のたびに出てきます。

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

Ｃはもう古い。

Ｃ使いは現代のコボラーってのに一票。
数にまかせて新しい言語に抵抗するところがクリソツ。

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

ＵＮＩＸって、Ｃ知ってりゃいいのか。

「Ｃ使いは現代のコボラー」

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

コボラーってOS書けるんですか？

C使いっていうよりCしか使えない、だな

Ｃ使えりゃアセンブリ以外はどの言語も簡単

そういうやつに限ってJavaすら使えない。
なんでもフローチャートで書けるとか思ってない、あんた？

またレベルの低い奴がまぎれこんでるな（ﾜﾗﾜﾗ

Cしか使えないプログラマなんていないだろ（笑）
VC++しか使えないプログラマとかJavaしか使えない
プログラマならいそうだな

>VC++しか使えないプログラマとかJavaしか使えない
>プログラマならいそうだな

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

>447

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

カーネルのソースを理解できないクセして、
Cはいいとかいってるのもう見てらんない。

>>448がいいこと言った。
そう、Cなんて（文法だけなら）誰でもできるんだよ。
それを偉そうにしているのはなぜ？

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

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

ポインタを理解できたのが、あんたらの人生の最高点だったんだろ。
>>Cオンリーさんたち。

粘着質ですなぁ････

今１から通して読んでみたけど
Ｃ++を擁護してＣを煽ってる問題児が一匹いるね。
煽ってるというよりＣ++を愛しすぎて熱くなりすぎ（笑

言語を必要以上に排他的に語る人にデキル者はいない。これ常識

なんか「C++==オブジェクト指向」と思い込んでる可哀想な人達が多いな

>>454
じゃ、ここのC++信者はできそこないばっかだね（笑）

>>451
Cしかできない人をばかにしちゃあかん。あの人たちかて、家では
りっぱなおとーさんなんや、て、ママに言われなかったか。

>>456
そりゃ「信者」と言った時点で（たぶん一神教なんだろうから）他の言語に寛容ということはあるまいて。

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

>>457
職場で苛められてるのか？相談に乗るぞ。

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

全く浮かびません。逝ってきます。

メモリマップが浮かばないという事はポインタを理解していないという事です。

ポインタ＝メモリアドレスという理解は誤りです。もう一度規格書を読みましょう。

Java,Perl,C++,C

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

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

そういうふうに迷う464はまずシェルスクリプトから・・・

shell script ってむずくないかい?
UNIX の余計な知識が必要になって。。。
ってココは UNIX 板だから、いいのか。それもまた。

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

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

>>468
はげどう。

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

C++を否定しているレスってあるか？
俺にはCを否定する粘着質しか見えないが？

C++？
ヴァカですか、あんな半端なもんやってるやつまだいるのぉ？

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

とすると半端でないのはC++以降の、たとえばJAVAなどが、
洗練されているということかい？

半端じゃないのは Schemeだね。

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

>>471 ｻﾌﾞｲ

言語もよく宗教戦争になるな...。
著しく不毛なのはわかってるはずなのに...。

>>475
半端なやつほどこだわりがねーんだよな。
ひとことでいうとヘタレね（藁

>>470
471を見ろ。ぼけ。

>>477
だからｻﾌﾞｲって

>>478
過去ログもよく読んで字を書け。ぼけ。
日本の人じゃないのか？

糞ｽﾚですか？

>>480
95% ぐらいは、ダメダメですな。一瞬だけ、まともなスレッドになりかけたけど。

大したスキルも無いのにCがあればいいだろとかいってるのもうみてらんない。

C++マンセーな奴が出てきていっきに糞スレ化してるな。

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

>>446
「VC++ しか使えない」って、どういうプログラマなんだ？　VC++ は単なる Win32 用の C/C++ コンパイラ
だから、ロジック部分は C/C++ で書くんだけど。

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

「VC++しか使えない」ってどーゆー事か問い詰めたら
「MFCしか使えない」って事だったって事があったらしいです。
あれ？「VC++」じゃなくて「C++しか使えない」だったかも。

漏れUNIXでしか開発した事無いからC++は使えるけどMFCは使えない
逝ったほうが良い？

Windowsで開発しないんならMFC知らなくてもいいんじゃねーの?

数値計算エンジン屋なんだよね
Windowsでも開発はするんだけどGUIは他の人が書く
こういう事ばっかりやってるとﾔﾊﾟｰﾘ取り残される？

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

オフトピックすまんsage

>>487
Windowsでの開発でもMFC知らないほうが幸せかもしれない･･･。

>>489
おれは、さすがに数千行の WndProc のメンテナンスするのは嫌だ。。。

Cも覚えて
Javaも一応出来て
アセンブリも冷や汗かきながら本見ながらだけど出来る
VBもこうなりゃ自白だ、「ドンと来いや」

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

>>491
そういう人には答えは見えてるでしょう。

でも
>Cも覚えて
はどうかと思う。（ｗ

入りづらい雰囲気だよ、おじいちゃん。

わたしの言語遍歴

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

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

>>494
行き着く先は、ハード？

そんなあなたにC++Builder
ゴロ悪いな

あーここUNIX板だった
来年Linux版のC++Builderは出るらしいが

>495
笑顔で黙々と16進を打ち込む変態に一票

>>496
Borland C++ Builder は BCB と略されることが多いが。（＠プログラム技術板）

>>498
ディップスイッチで……(略）

>>497
BCB じゃないが Intel C++ Compiler for Linux は出てるね。

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

誰か使った人いる？

C++Builder
↓
CBill
↓
ちびる

>501
OpenSSLをソレでつくってみたら爆速でちょっと感動したが、よく
segvるw。C++に関係ないのでsage.

少しさかのぼるが、UNIXで例外運用について統一ルールがないのは
C++ フレームワークが普及していないからでは？
MFCを使う場合はMFCの例外ルール(あるのかどうか疑わしいが)に
従わないとめちゃくちゃになるよね。

っつかそーゆー意味では
Ｃ++って標準のI/Oクラスも無いって言えるかも…
みんなクラス内で fread()とかやってません？
俺だけ？

だいぶずれるけど
C++でオブジェクトを確保したら
メモリ上にはどうやって格納されてるの？

>>506
デバッガで遊んでみれば？

>>505
iostream は微妙に使いづらいんだよね。俺も C++ だと #include <cstdio> だったり。

>>506
主流の実装は二通りあるんだが、VC で使ってるやつだと

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

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

さんくぅす。

cout << "Hello, world!" << endl;
って、エラー処理をしていないのでまずいよね。

>>505, >>508
C++標準化の歴史を抜きにすれば、iostreamで、入出力エラー時に例外が
出ないのはどう考えてもおかしいと思うんだが。

ところで javaライブラリの C++化って行われてるのかな？

Limbo、これ最強。

>>511
エラーが出たところで

・どこまで出力されたか判別できない
・明示的にある時点まで巻き戻ることができない

という事情があるんだが？

>>513
フィルタとして使う場合なんかはエラーが起きたら異常終了終了して欲しい。
そのエラーが回復不能だからといって、エラーを無視していいわけではないだろ。

フィルタならstdio使え

向き不向きがあるんだよ

>>511
ios_base::exceptions() で、問題が発生したときに例外を投げるように設定できます。

>>515
前半は完全に同意なんだけど、それにしても C++ の iostream って仕様がイマイチ
じゃない？　operator<<(), operator>>() が最悪に近い演算子多重定義なのは目
をつむるとしても、

- 書式指定が面倒
- STL との連携もないし、ポインタが絡んだ場合のシリアライズのフレームワーク
　も提供していない

など、どうも仕様が中途半端な気がする。

>>516
日本人が一枚かんでるんだから、そういぢめるな
iostreamの軽量版なら、俺も欲しい

>>516
ワシもそう思う

>>517
その「一枚かんでる」日本人って、誰？

>>516
言語仕様がようやく固まってきたから、次はライブラリーだー！

はやく時代遅れになってくんないかなあ > C++

C++の仕様は大好きです。
でも、スレッドとかネットワークとか、Java並(?)の簡単ライブラリは作らないんでしょうかね。

今は亡きOOCのJTread/C++なんてのは？

>>517 ねえねえ、その一枚かんでる日本人て誰なん? じらさんといて。

In article >>521, 名無しさん＠お腹いっぱい。/521 wrote:

> はやく時代遅れになってくんないかなあ > C++

あなたが時代遅れです。

0chだって。
http://medetai.kakiko.com/0ch

やっぱ UNIX って遅れてるよ

>>526
ｸﾘｯｸしちまった

僕はひさしぶりにＵＮＩＸの仕事をしました。
まるで時代が戻ったような感じでした。
ＵＮＩＸしかしらない人がいたら、それはやばいですよ。

KDEが遅いのはC++のせいかも。
でもあれだけ大きいソフトはC++でないと作れなかったかも。

ＵＮＩＸってＧＵＩにしてもＷｉｎｄｏｗｓと同じレベルのことすると
Ｗｉｎｄｏｗｓより重いよね。

そうだなぁ。Windows のように Widget も統一されてないしね。
まぁそれが Unix の良さなんだが。
気が済むまで自分で自分のスタイルを作ることができるという。
しかし、GUI と CUI は対立関係にあるわけじゃないし補完すればよいから
GUI で Windows と同じレベルのことをしたきゃ俺は素直に Windows 使うけど。

>>529
うーんと、言語ではなくて、フレームワークのことがいいたいのかしら？
DCOMとかATLみたいなものがほしいの？

私もやばいのかしら？入社してから2年半UNIXばっか。
言語はC,Java,C++,Ruby,Perl,Scheme,Lisp,Prolog,Fortranは書けるよ。
仕事でつかうのは、C,Java,Perl,Rubyで、ちょぴっとC++だよ。

.NETが普及してC++を書けないWindowsプログラマが大量生産されますように

すでにVBでうんこしか作れない自称“プログラマ”が大漁ですが何か？

Ｃ＃はいいぞ

Mono
DotGNU

>>535
うんことはいえVB使ってる時点であなたもオブジェクト指向プログラマ。
C++で組んでる大半のやつらよりね。
C++は単にクラス設計とか継承とかを手動でやれるってだけだ。
だからoop理解してないうんこがC++使ってもうんこはうんこ。
VBみたいな組んでる本人がoopを理解してなくてもoopやってるってのが理想と思うな。
俺もCの次にすぐにC++やったけど今思うとホント臭いうんこだった。
VBみたいな完成されたクラス設計見て初めてoopがなんたるかを知ったよ。
もちろんVBの設計が完璧とは思わないが。
VBやったあと再びC++やって、だいぶoopらしくなったと思ったが最近やっぱまだまだだと気づいた。

10点。
うんこがなければ25点。

>>538
> VBやったあと再びC++やって、だいぶoopらしくなったと思ったが最近やっぱまだまだだと気づいた。

どうせ、C++ってVC++だけのことなんでしょ。

>>540
ちゃうよ。ってかＧＵＩのプログラムを作ってるわけじゃないんで。
ほとんどDOS上で作ってるのとかわらん状況・・・

>538

たんに、あんたがＣ＋＋をつかいこなせてないだけの話だろ。
はずかしいやつだな。

ＶＢをうんことい奴が多いが、その中核にあるＣＯＭの技術を
よく勉強しなさい。
たしかにうんこは多いが。

>>543
うんこといってナニ？

>544

君のことだよ。うんことい君。

> 君のことだよ。うんことい君。
>
VBは初心者向け言語です。

だからうんこは多いって言ってるでしょ

うちの会社の場合、UNIX の仕事では、C++ は GUI まわり
だけは使います。後は C です。

C++ は、設計が悪いと、記憶力が良い人にしか読めない
コードになり、メンテナンスが辛くなりますが、

C だったら、どんなバカな奴でもプログラム読めますからね。

>>548
> C だったら、どんなバカな奴でもプログラム読めますからね。
だが、メンテナンスは不可能だったりするぞ。関数数千行でグローバル変数使いまくり、
なぞの switch - case や if - else 大量でロジックこんがらがってると、さすがに手に
負えん。

C++ で、なんでもかんでも多重継承してるプログラムも手に負えないけど。

>>543
> その中核にあるＣＯＭの技術
それ VC++ で勉強した方がいいと思われ。使うだけなら VB が便利だけど、仕組みは
C++ 知らんと理解不能だろ。

>>549
> だが、メンテナンスは不可能だったりするぞ。関数数千行でグローバル変数使いまくり、
> なぞの switch - case や if - else 大量でロジックこんがらがってると、さすがに手に
> 負えん。

それはCかC++かの問題じゃないし

>>551
そのとおり。

何の言語を使わせようが、ダメなヤツはダメ。

>>543
> その中核にあるＣＯＭの技術をよく勉強しなさい。

これが、

>>538
> VBやったあと再びC++やって、だいぶoopらしくなったと思ったが最近やっぱまだまだだと気づいた。

これとどう繋がるの？

COMねぇ。VBから使う分には楽ちんでいいけど、あんなもん作る方にまわり
たくないよ。特にC/C++でCOMって、言語制約から来るお約束事項が多すぎ。
ソースもMFC以上にマクロだらけでウザいし、レジストリいかれるとバイナリ
そこにあっても動かなくなるし。趣味ならともかく仕事でやるとげっそり。
ちーとも面白くない。

今だったら、VBでIEコンポーネント貼り付けてブラウザもどき作って
「ほーこりゃ便利だのー」って遊ぶ位にしといた方がいいと思われ。
C#ちゃんとリリースされたら(C#のclassはCOMオブジェクトになるという
事なので)本格的にやってみてもいいかもね。
# まぁ最初はCLRとか安定しないんだろうけど

どうやらプログラム技術板から流れてきたやつがいるな…

>>553
単なる電波だ。相手にするだけ時間の無駄と思われ。

>>555
流れてきたというか、単に UNIX, Win32 掛け持ちのプログラマが少なくないだけだと思われ。
仕事で両方やってる人もいるし、仕事は Win32 でも UNIX のバックグラウンドがある人は多
いんじゃないかなぁ。

それはそれとして、板違いな書き込みは sage で頼みたいが。

C++の話をしよう。
そもそも、ストラウストラップ先生がだ。。。（以下略）

>>548
本物の「なまお」ちゃんかい？

>>552
禿同
結合度を弱く強度を強くするとか、階層をむやみに深くしないとか、
そういったテクニックは、言語は関係ないことが多いものね。
ま、不向きな言語も無いとはいえないけど。

>>538
VBってオブジェクト指向だったの？？いつからそうなったの？
マジで時代遅れか。打つだ氏脳。
スレ違いなのでsage

>557
simula から始めてくれ

>>554
「VBから使う分には楽ちんでいいけど」が全てだ。
C++プログラマは血反吐を吐け。

…と言う悟りを開きました。

>>560
いちおうクラスつくれるよ

>>563
Javaで言うinterfaceも作れるよん。しかもVB5から。
まぁ派生できないからいまいちなんだけど。

お前ら、勘違いスンナよ。プログラムで飯を食ってることが既に負け組みなんだよ。

勝ち組は何で飯を食うの？

>>566
コン猿

確かに、ＰＧってＳＥや紺猿が所有する兵隊だよね

でも、コード書けなきゃ生きてる意味ないし。

1<<
C++を「本当に」理解しているなら、Cが嫌だなんて思わないはず。
C++を使っているというより、MFCがないとソフトが組めないだけじゃない？

コード組めてもいつかはソフトもＰＧも陳腐化する宿命。
ＰＧからＳＥへ上れないと、結局使い捨て。
すべてのＰＧがＳＥになんかなれなから、大半のＰＧは使い捨て。
脳みその切り売りsage

ＰＧなんかでいい気になっていると、足元すくわれるぞ

考えてもみろよ。５０過ぎてたときに、２０そこそこの若造と同じＰＧじゃやってられないだろ。
そもそもこの業界、５０過ぎまでまともに働ける奴がどのくらいいるかなんてわからんけどな

つうか、コード書くのいやなら、書ける奴に命令してみれば？
「俺はSE様だ、PGなんてやってらんねえんだよ、設計したからお前らこのとおりに作れ。」

まともなC++のコード書けるプログラマ、ほしいなあ…

俺はperl気分でC++使ってますが何か?

>>570
MFCなんざ逝ってよしですがSTLがないと生きていけません。
というか未だにSTLを使わない奴の気が知れない。

C++ の class template は便利だ。
STL とこれだけで C++ 使う価値あると思うのだが。
# jdk(java)1.5 にも class template が採用されるとかされないとか。

c++でなんかいいtoolない？

>578
># jdk(java)1.5 にも class template が採用されるとかされないとか。
今更何イッテンダカ。。

javaのGenericsは、メタプログラムの観点からみると、今ひとつ。

>579
C++で作られてるなんかいいtool
なのか，
C++で開発する上でなんかいいtool
のどっちをお探し?

まぁ漏れはどっちもあんま知らねーけど．

こんどC++の仕事入ったよ。まんせ。

まだこのスレあったのか・・・・
C++なんか使うなﾎﾞｹｪ

現代のコボラーってやつか。しつこいぞ。

template使った奴ってやたらビルド時間かかるんですけど......
やぱり今時のプログラマはそんな事を気にせず富豪になるべきなのでしょうか。

吉祥寺にある大検・大学受験予備校の中央高等学院
ここは、完全に狂ってる。
授業料は一年分一括前払いなので、
金が入れば、生徒は要らない
金を振り込んだら、何とかその生徒を辞めさせようと
講師どもが、あの手、この手でイヤガラセをしてきますね。
セクハラはもちろん、脈絡の無い罵倒は日常茶飯だね。
酒臭い講師もいるし・・・　人生の最果て中央高等学院
学歴詐称、経歴詐称、合格実績詐称、デタラメ授業、
http://www.chuo-school.ac/

http://chs-f.com/index.html　中央高等学院福岡校
司法浪人の田中校長は　↑　また司法試験に落ちましたが
ＨＰ上では下らない見栄を張っています

>>586
テンプレート使って楽した分、
コンパイルの回数を減らせばいいだけだろ

テンプレートでビルドに時間かかる？
あまり感じたことはなかったけど、田の人もそうなの？

>>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 でソースコードの中身が全く違う代物なんで単純に比較はできないけど、一例ということで。

template libraryは本体がヘッダだから
プリコンパイルできないと、ライブラリを毎回コンパイルしなおしてるような
もんなんだよね…
gccのプリコンパイル対応はいつになるんだろうか。

あとtemplate使うと、エラーメッセージが難読になるのも問題ね。

STLに関してはScott Meyers先生のEffective STLっていう良書があるんだけれど
これの邦訳もいつになるんだろうか…

>>591
template 使った場合は、プリコンパイルしてても

　「毎回コンパイルしなおし」

に近い状況になるよ。型が確定して初めて構文解析できるわけだから。トークン列までは
template 見た段階で解析できるけど、たとえば引数で渡された型 T の変数 a に対して

　a.foo();

とか書いてある場合、ほんとに foo がメソッドかどうかは T を見ないと分からん（他にもグ
ローバルな名前空間にある変数とか typedef とかも）。

どう実装するかは幅があるけど、文献を読んだ感じだと、テンプレート定義が出てきた段階
では字句解析と構文解析を少々で止めておいて、テンプレートをインスタンス化するときに
個別に構文解析しなおすのが一般的みたい。

VC6 のプリコンパイルヘッダの詳細は分からんけど、STL はプリコンパイルしてもしなく
ても、あまり速度が変わらなかったと思う。

> 　2 template 多用したコード
>　　総ソースコード 10879 行、267,555 バイト
>　　97秒
コンパイルオプションを /O1 (速度優先) から /O2 (実行サイズ優先) に変えて、リンクす
るランタイムライブラリを DLL からスタティックリンクにしたら 27 秒まで短縮された。

マジレスありがとう。>>590 >>591 >>592
590の1)と2)のコードってすごそう。

>　a.foo();
>
>とか書いてある場合、ほんとに foo がメソッドかどうかは T を見ないと分からん（他にもグ
>ローバルな名前空間にある変数とか typedef とかも）。

gcc2.95付属のstlで見ただけだけど、
#include <algolithm>
で定義されるtemplate（たとえばsort)見てマジで感動しました。
Cだと型独立に定義しようとしたらマクロで小細工しないといけないようなことを
C++のテンプレート使ってやってるんだね。
ただなぁ、デフォルトでドキュメントが付いてこないのがなぁ。

>>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

とかでマニュアル読みたいよね。

>590
うぷきぼんぬ

>>596
http://members.tripod.co.jp/lambda_func/

ついでに、思い切り template を使って、実質的に翻訳単位をひとつに
まとめてしまったソースも置いときます。

フルビルドに要する時間や、実行ファイルのサイズ、新規にメソッドを追
加する際の手間なんかを見ると、翻訳単位一つにして、ヘッダにコードを
書いたほうが効率が良いみたい。

代わりに

- 「常にフルビルド」状態になる
- バイナリ互換性が容易に崩れる
- 前方宣言を避けるために template を巧妙に利用すると、ヘッダ順序の
　制約が厳しくなる。

というデメリットもあるから、規模が大きくなると泣くと思うけど。

>597
ｶﾞ━━(ﾟДﾟ;)━━ｿ!
Unix 系じゃ動かんのね，
良く見たら
> ATL/WTL
って書いてあるのか・・・

一応アリガト．WTL 使う機会があったら参考にさせて頂くかもですm(_ _)m

>>598
最初から Visual C++ 6.0 だと言ってるのに(苦笑)

そこそこ MI/MD 分離した設計になってるから、MD 部分だけ手を入れれば X でも
動くかもしれません。とりあえず GDI, DirectDraw7 両対応にはなってますし。
（私は X プログラミングは知らないので無理）

ここの人はC++で仕事するときはどんなライブラリを使ってるの？
自作？それなら結構。羨ましいです。
それ以外の人は結構大変ですよね？仕事の度に違うライブラリと付き合わなくては
ならないのは。Windowsな人はひとつのライブラリだけでいいから、そういった
意味では楽ですね。
今はネットワーク系のよいフリーのライブラリを探しているのですが、
ACEのようなでかい規模のものではなくてもっと小さいものがあればそれを使い
たいなと思います。

何かいいものはありますか？

gcc な STL 使っとけや。

>>601
STL にネットワーク関係のライブラリは規定されてないだろ。

>>600
俺も同じ質問す。
でも、ACEって最近名前を聞いただけの「素人」です。
ACEはどのくらい認知されてるんでしょう？
600氏が避けるような理由があるのでしょうか？
ACEを勉強しようかどうしようか迷ってるんです。
教えていただければ幸いです。

>>603
今度仕事で評価を兼ねて使うことが決まってるから、
その結果を待て！

>604
600 でも 603 でも無いけど期待age!!
ちなみにいつ頃になりますか?

来週末までにプロトタイプと報告書をまとめることになってる。
それをここに書き込むよ。

>606殿
うぉー!超，超，超ぉ〜期待しております!!!
お仕事頑張って下さい!!

603です。
>>604　>>606
うあ。ありがとうございます。よろしくお願いします。
期待しまくりです。
（>>607と同じ気持ちです。605氏にも感謝！）

GNU common C++
http://www.gnu.org/software/commonc++/commonc++.html
ってどーよ?

と思ったら1.9.5コンパイル通らねーし!!
とりあえず1.9.4をいぢってみるかのぅ・・・

>>591
Effective STL 邦訳出てたよ。
>>600
qtはどうでしょうか？でかすぎ？趣味で使うにはとても便利です。

しまった．gcc-3.0.3 だとコンパイル通らんらしいけど 2.95.3
だったら逝けた．鬱氏．
さてイヂってみるかな・・・

Qtマンセー

gtk-- ってどうなのよ?

全角英字使うな。これだからウィナーは。

>614
誤爆?

>>610
亀レスだが、Effective STLの情報ありがとう

>>606
どうなったでしょうか。お待ちしております。

＞＞６０６
死んだか？

死者をむち打つようなことをすな。

age

Lokiマンセー

C++をあまり使わないのは、実績と信頼性で不安だから
ですかね?

C++を使うとコーディングが楽だけど、CでもC++っぽい
プログラミングは出来る。クラスの表現だって出来る
からな。

徒歩だって東京から大阪までいけるんだYO!とかなんとか主張する消防が集うって
スレはここですか?

C++が使われないのは、UNIXがC文化の産物だからじゃないかな。

UNIXでは、小さなツールを組み合わせ、ありもんで済まない部分はスクリプトを書く
ことが多い。
問題を分割してしまえば、オブジェクト指向言語のメリットは相対的に小さくなる。

portabilityもCの方が有利。ANSI Cライブラリは絶対どこにでもあるけど、
STLはどんな実装があるかわからない。

securityを重視する局面で、C++を使うのも適切ではない。
root権限で動くプログラムを書くなら、パラノイアでなければならないから。
djbはlibcですら信用できないと考えている。
C++は、プログラマが書いた以外に、コンパイラが大量の暗黙のコードを追加するのに
できるバイナリがsecureだと保証するのは容易ではない。

Cで書けるところはCで、スクリプトで書けるところはスクリプトで…と考えて
いくと、当然、C++の出番は少なくなるよ。

>>624
でも、そこらのサーバプログラムのsecurity holeって
C++でちゃんと組めば出て来にくいものだろ。

>625
たしかにクラスでカプセル化できれば、オブジェクトに対する操作を
安全なものに限定し易くなる。
でもそれは補助でしかない。
結局は、地道にコードをレビューして、危険性を取り除くしかない。

そしてC++で書かれたコードのレビューは悪夢だ。

>>625
「ちゃんと組む」というのが言語によらず最も難しいと思われる。

ちゃんと設計出来ない奴がいい加減に組むと、
Cより始末悪いな。C++のソースは。

だから VC++ のデバッガは強力なんだな。

Cだとデバッガいらないもんな。

>>625
バッファオーバーフローだの、二回 free() 問題なんかは、string, vector や
auto_ptr を使うと発生頻度はかなり下がるよな。

>>628
> Cだとデバッガいらないもんな。
ddb ラブラブですが、何か？

>>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 系列
で改善された。

s/スタートアップライブラリ/スタートアップルーチン/

crt0.o みたいな、プロセス実行から main 呼ばれるまでに実行される
プログラムの事ね。

方程式の有用性を知らない人間が鶴亀算の素晴らしさを熱く語るようなものだな。
いつも思うことではあるが。

>>633

あなたはチームで仕事していない人じゃない?

自分が組むなら C++ は良いけど、レベル低い奴の C++
ソースってホントに困るぞ。２ヵ月で作って10年使おう
と思ったら、Cが無難。

>>634
レベル低いやつの C はそれ以上に困りますが、何か？

チームで仕事もしますが、大抵自分ら小人数でC++(事情によりまれにC)でコアな
部分を作成し、皆様には既存あるいは独自のスクリプト言語で他の部分を書いて貰
うことが多いです。

634,635にも同意ですが、楽をできる言語を知っている人間まで、そうでない人間
に引きずられるのは御免被りたいという感じですかね。

>>634
そうやって、使えないプログラマが書いたソースを後でメンテナンスさせられた
ことがある人間として。

　バカにはコードを書かせるな
　責任もって教育して、それから使ってくれ

いやほんとに(;_;)

c++を使わせるとバカがカプセル化されるから良いかも(^^

レベル低い奴のソースは言語がなんであってもひどい。これ定説。
# どうしてあそこまで糞なコードが書けるのか、ある意味感心はするがな。

>>638
大甘。「カプセル化」という言葉すら知らないんだぞ。
コンストラクタでグローバルのnewやってたりするんだぞ。
手に負えないっつーの。

チャチャだけど.. 639は
ヘボプログラマにかなり泣かされているね(^^
それともヘボプログラマを泣かせている方かな？

>>639
深い深い条件分岐のネストとか、その中でグローバル変数を設定とかな。
バグが取れないと泣きつかれたんだけど、どうにもソースが解析できずに、
捨てて作り直したことがあるよ。

C++ でもグローバル変数をバリバリ使われたら手におえん。

デストラクタきらい。
Java = C++--

WindowsのC++のソースを、 :: を __ にawkで置換してからUNIXのCに移植し
てるCジジイを見た時には寒気がしたけどな。もうね、アホかと。動くのかと。

static int m_foo = xxx;
void CFoo__CFoo(void)
{
m_foo = 100;
}

...

動きませんでした。

それ以前にコンパイラ通らんと思うんだが...
ちくちくとコンパイルエラー潰したんか？

>>645
yes.
互換ライブラリをCで書いてなw

もっと真っ当な手はなかったのかな
g++ つかうとか、Sun なら forte 使うとか(俺はforteは使ったことないけど^^;;)

C++が書けないんだろ

つうか、 Windows からの移植なら、c++ 以前の問題として、
WindowsAPIべったりの記述をどうにかするほうが大問題だと思うが。
（まあ、処理の内容によるけど）

>>649
そこはどうにかなったんだよ。でも、643のようなインスタンスの概念のない
Cのソースコードに落としてしまったらWindowsのメッセージングベースのプ
ログラムの構造をうまく表現できなくて沈没。
ってこんなこと、当然すぎて書くのも馬鹿馬鹿しいんだけどさ。C-dog には
わからないんだよ。

age

結局使わないんじゃなくて、使うスキルがないっていうこと。

メインフレームのオヤジPGがCOBOLしか使えないように、
UNIXのオヤジPGがCしか使えない、
ということだ。リストラ覚悟しとけ＞該当者

アプリケーションプログラマはC++が万能だと思えるかもしれないが
C++を「使わない」シチュエーションもあるわな。
いざとなりゃアセンブラだって使うわな。
適材適所でイインジャネーノ？

>>652
言語習得するのって、そんなに難しいかぁ?
まあ実績作るのは大変だけど。

C++はシンドイと思う。
例外安全からデフォルトコンストラクタの挙動からなにから、
枝葉末節まで把握してないと
なあなあではまともなプログラムが書けない。
さらにオブジェクト指向分析・設計のスキル、クラスライブラリ等々
きりがない。

>>654
> 言語習得するのって、そんなに難しいかぁ?
わりと。

俺も最初は C++ の入門書をざっと読んで、

　なんだ構造体が拡張されてるぐらいじゃん

とか思っていたが、Effective C++ 読んで衝撃を喰らって、More Effective C++,
Exceptional C++ を読んで

　全然分かってなかったのね、俺

と反省しきり。その後も Generic Programming やらデザインパターンやら、日々
これ勉強ですよ。

>適材適所でイインジャネーノ？

全くその通りで誰も全部C++にしろとは言っていない。いろんな言語や開発手法、
新しい技術に臨機応変に対応できるスキルが求められる中、UNIXならCとshとawkだけで
十分、みたいになっていくオヤジはリストラまっしぐら、ということだ。＞該当者

オヤジはCGIもCとshとawkだけで書いたりするらしいね。

まあ、C++自体ようやく仕様が固まったから、これからでしょう。

C++って器用貧乏だよね。

それに分厚い言語仕様の本を抱えて仕事しなきゃならん
なんて、辞書もって外国語の会話するようなものじゃん。
悪い言語だとは思わないけど、なんとなくケチつけたくはなるな。

>>656
おれはC++使い始めて1年ぐらいになるけど、やっぱり大変だよ。
日々勉強に同意。いつになったら楽させてもらえるんだろう、、

>>658
すまん。sh+javaでcgi書いた事ある（ｗ
# もちろん自分しか使わないでっちあげcgiだけど

各論賛成、総論反対って感じの言語だな >>C++
おれも、いまやってるプロジェクトを C++で全部書き直したら
楽になるなあ、とか夢想をするけど、
きっと知らなかった言語仕様の部分とかでつまづくんだろうなあ...

>>659
>ようやく仕様が固まったから
西暦何年何月?

C と C++ を比較して、バグの収束率とか開発効率とかの
調査って、どっかの大学の先生とかやってないのかなぁ？

>>662
バグ入れちゃったときが大変だよね。
こう間違えたので、C++ではこのように動いて、
ここを直したから、これで大丈夫です。
という説明するために、言語仕様ひっかきまわし（ｗ

便利な部分だけつかえばいいのさ：）

機能の全てを使い切りたいという止み難い衝動に駆られるから無理です

ていうかvector使うだけでパンドラの箱が開いちゃう

>>668
でも、STLは使いたくなっちゃうだよ。char* にイライラしてくると、
stringとは言わないまでもvector<char>が。

人間がコードを書くと、意思とは別に
起こりうることは、まず、書いてしまいます。（ｗ
だから大きな仕様の言語だと、デバッグが大変なのです。

>>660
日々勉強だけど、勉強して身についた範囲で楽は出来てるよ。もう C には
戻りたくない。

でも複数人での開発だと、どこまで C++ の機能を使うかが問題だったり。
（バカとは一緒にコード書きたくないよな…）

>>663
> 西暦何年何月?
1998-09-01

ルーシー
モノ
ストーン！！

最近??もう3年以上前ですが。

言語の普及は、処理系の普及と同義なので、非常に時間がかかると思われ。
処理系の実装と安定、そして各サイトでのアップデート…３年では足りぬ。

>675
backward compatibilityを考えなくても良くなる
までの時間を考えると10年でも足りないかも。

>>675
Windows の世界だと 3 年は太古の昔に感じるが、UNIX だとそうでもない
気がする。

正直、Ｃですらつい最近まで K&R と ANSI 記法がまじってたくらいだしねぇ。
*BSD の原型宣言の __P() ってそのあたりで有名かな。

Windowsのクラスライブラリはせいぜい2年が賞味期限でしょ。
後は腐っているのを無理やり食べさせられている状態。

>>679
X でも GTk あたりは、バージョン上がると互換性ぶち壊してくれるからなぁ…

>>680
さすがに GTK では業務向プログラム書きたくないねぇ…

>>643
ワラタ

>680-681
GTK+ の互換性の無さはよく言われているけど、
できれば、具体例を挙げて欲しいと言ってみるテスト。
某 ML で聞いた人がいたけど、全くレスがつかなかったしな。

疑っているわけじゃなく、後学のため、反面教師にするためにね。

>>683
とりあえず、複数のバージョンの GTK を持ってきて API を比較してみましょう。

>>684
>>683の言いたいことは、たぶん、GTKだけでなく、QT-2.3.1とQT-3.0.2でも
APIが異なりソース互換性がなくイナリ互換性もない。Motif-1.2とMotif-2.1
でもAPIが異なりバイナリ互換性がない。にもかかわらず、GTKだけがなぜ
互換性を考慮していないと言われなければならないってことでは。

イナリ互換性→バイナリ互換性ね

>685 君が例に挙げてるふたつはメジャーバージョンアップ。
Gtk+はマイナーバージョンアップでAPI互換が崩れるからDQNだと言われるのだろう。

>685
えぇ、俺が言っているのは >687 で言われているマイナーバージョンでも
互換性がないということです。
やっぱり、ソースを見るしかないのかな……

>>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と同じレベルの互換性があり、互換性を考慮していない
ということにはならないはず。

ただ、1.1や1.3のような開発バージョンで全く互換性を考慮せずガンガン
変更されていたのは事実で、開発バージョンであってもちゃんとインター
フェイスを決めてから実装すべきだとは思うけど、インターフェイスの
バグ修正等で互換性を完全に保てないのは開発バージョンならしかたが
ないと思うなあ。

某 う さんがGTKをさんざん嫌っているのは、1.0と1.2の間にかなり期間が
あり、その間に1.1を対象とするアプリがたくさん開発されたため、互換性
に問題があるアプリがいっぱいできている中、やっと1.2がリリースされたと
思ったら、同じ1.2.xなのにバイナリ互換性がなくなる変更があったからじゃ
ないかな。

でも、確かこの互換性がなくなる変更というのはある関数の返り値が特定
のウィジットで間違っていて、仕様と実装に食い違いが生じていたからで
あって、仕方がない変更だったはずなんだけど記憶違いかも。ここ、確認
できる人います? 他に安定バージョンで(後方互換性が保たれていない)
互換性がない変更があったか確認できる人いますか?

あう、

...1.0.x間や1.2.x間、2.0.x間で互換性が保たれて
いるなら問題では?

問題ないんでは?

age

C++の反省のもとにJavaがあると思うのだが、Javaではダメなことには
どんなものがあるのだね？

>>693
Write Once, Run Somewhere.

まずは重いことかな？ gcjみたいなネイティブコンパイラ使えばいいのかも知れないが......

「ネイティブコンパイラ」っつうか「ネイティブバイナリを吐くコンパイラ」ね

>>695
HotSpot VMではご不満か?

>>695
比較したことないんだろなぁ、こういう人って（ｗ

JAVA標準のクラスライブラリをgcjから
使えるの?

>>698
それは比較してみれば重くないことが判るってことでしょうか。

個人的には javac ってやってヘルプ出るまでの間が耐えられん。
(VM の起動時間なのかな？)

Javaﾏﾝｾｰ
って言ってて、出来ない事が多いから初期のJavaからだいぶ様変わりしてきとるのでは。
サーバサイドで使うから今のJavaであってクライアントだったら問題外だし。
>>694で書いてる事も今はただの看板のようなもんだし。
というかなんでJavaで盛り上がるんだよー。
Java好きな人も、なんでもかんでもJava使うわけじゃなかろうて。

>>701
JNIすらしらないんだろうなぁ、こういう人って（ｗ

>>702
そこまでしてまでもJavaに拘るんだろうなぁ、こういう人って（ｗ

なんでこんな話してんのよ。ほんとにJavaOnlyﾏﾝｾｰなヤツは他の所にいるだろて。

CにできてJavaにできないことかぁ、あったかなぁ？
あ、一個だけあったヨ。

buffer over flow だけはできないや、ｸﾔｼｲー（ｗ

はいはい、どっか行っていいってばさ

Java房必死だな。
こんなところにまで出張すな。

おとなしくMC++でも始めろ。

>>707
C++ (　´,_ゝ｀) ﾌﾟｯ

>>708
頭の M が何の略か分かってない？

俺は MC++ は別にお奨めではないが、まぁ知っておいて悪くないと思うぞ。

ジョセフソン素子とガリウム砒素素子について知っている人いたら教えてくれませんか?
宜しくお願いします。

「現代用語の基礎知識」より
◆ジョセフソン素子(Josephson device)〔参照用補遺〕
ニオブなどある種の材料を絶対零度（マイナス二七三・一五℃）に近い極低温に冷やすと超電導現象が起
きて、電流の流れに対する抵抗がほとんどゼロになる。このとき二つの材料の間に、この現象による相互
作用を起こさせると、スイッチの作用を作ることができる。このスイッチの組み合わせで作るコンピュー
タの論理素子を現象の発見者の名前をとってジョセフソン素子とよび、通産省電子技術総合研究所などで
実用化に向けて基礎的な研究が進められた。
この素子の特色は、非常にスイッチ速度が速い（二○ピコ秒＝一兆分の二○秒）ことと、消費電力が極め
て少ないことである。したがって超大型の計算機に活用することが期待されている。
一九八三（昭和五八）年には、電子技術総合研究所から七ピコ秒というデータも発表された。八三年、ア
メリカＩＢＭ社の研究所は、この研究を「ほとんど中止に近い縮小」することを発表した。集積回路に作
ることの難しさ、設計上の厳しさ、などをあげ、成功の見込みの少ない研究と判断したためである。
八六年ごろから、高温で超電導を示す物質がみつけられ、研究の大きな話題となった。ジョセフソン素子
の今後は、この高温超電導材料の研究の発展にその一部がかかっている。が、その一方、新しい試みとし
て、ジョセフソン素子と、半導体ＩＣとを一体化して複合素子という形で両方の特色を生かそうという工
夫が進んでいる。例えば富士通研究所では九一（平成三）年二月、室温で動く高速のガリウム砒（ひ）素
ＬＳＩと、ジョセフソン素子とを、ひとつの基板の上にまとめることに成功、今後この方向に進歩すると、
一ギガヘルツの高速コンピュータが実現する可能性が予測される。（現代用語の基礎知識1999年版より）

「現代用語の基礎知識」より
◆ガリウム砒（ひ）素半導体〔電子工学〕
ゲルマニウムやシリコンにはみられない独特な性能をもっているので、研究開発が進められている。（１）
まず、この材料でp-n接合（→別項）を作って、p型をプラス、n型をマイナスにバイアス電圧をかけると、
レーザー発振を開始し、干渉性をもったレーザー光を放射する。これが光通信用の半導体レーザーで、ゲ
ルマニウムやシリコンでは本性上の違いで、この効果はけっして得られない。（２）次に、ガリウム砒
（ひ）素半導体の特色はその中で走る電子のスピードが、ゲルマニウムやシリコンの中よりもはるかに速
いということである。
この特色を生かして、一〇ギガヘルツ程度の高い周波数で働く電場効果トランジスタ（ＦＥＴ）を作り、
人工衛星によるテレビ放送電波受信装置が開発された。また、コンピュータなどパルス技術に使う高速の
デバイス（素子）として、ガリウム砒（ひ）素半導体が、精力的に研究されている。とくにこの場合、特
別の構造のデバイスを作ることによっていっそうこの高速の性能を引き出すため、さまざまな工夫が重ね
られている。
ガリウム砒（ひ）素半導体のもうひとつの妙味は、ガリウム、ヒ素、アルミニウムなどの元素を高い真空
の中で静かに蒸発させ好みの組成の半導体を数十オングストローム（一オングストロームは一億分の一セ
ンチメートル）の厚さで、積み重ねて成長させる技術の発展にある。とくに最近では、こういった化合物
半導体の結晶を、原子のレベルの精度（コントロール）で作り上げる技術が急速に進歩したために、これ
まで自然には存在しなかった構造の結晶を作り、またいろいろの細かい構造のデバイスさえ作れるように
なった。このため、物理学に新しい課題が生まれ、そのかかわりから、一〇年後までに何か新しい飛躍が
生まれる期待がもたれている。
ガリウム砒（ひ）素のデバイスを作るには、そのような層の成長によるが、その層を成長させる基板のガ
リウム砒（ひ）素結晶が必要で、とくにその質のよさが決定的な要因となる。この方面では日本の技術は
極めて高く、転移欠陥の極めて少ない大口径結晶スライスを世界に提供している。

お前厨だろ。MC++ なんて言わんぞ。

すまん、ム板の、しかもぜんぜん関係無いスレと間違えた…

コンパイラとかライブラリとかの互換性の問題は最近は善くなっているんですか？

C#は？

OpenOfficeはC++で書かれているそうですよ(マ板ネタですが)

数値計算をするのであれば、Fortran95がもっとも適切で機能も豊富だよ。
C++のようなポインター乱用、メモリーリーク温存しまくり、かってな
型の自動変換、うっかり間違っても関数オーバーロードが出来てしまう、
などなどの機能は危険すぎる。オブジェクト指向によるソフトウェアの
安全な記述と堅牢性の売りは、Cとの上位互換性を求めた為におじゃんに
なっていて、むしろCよりもめちゃくちゃ悪い言語に成り下がっている。
プロトタイピングには向くかもしれんが、後のデバッグや保守、ソフトウェア
の正しさの観点からは、マイナス要因だらけ。

数　値　計　算　な　ら　Java　で　き　ま　り　　

　　　　　　　　　　　　　　　　　　　　以上

Javaの利点は、プラットフォームに依存しないことだけ。
その代償として重い。
プラットフォーム非依存性の必要ないサーバーサイドにまで
Javaを使う人の気が知れん。
なんで C/C++ でがちっと書かないのだろう？

Fortran95 というのがあっても、実際数値計算やる頭の固い人たちは
FORTRAN77 なんだよね、書き方が。COMMON文乱発でどーしようもなく
モノリシックなコードになってしまってる。
で、やっぱり若い人もそういう人たちからFORTRANを教わるわけで、
結局 FORTRAN77 以上の進展がない(さすがにdo-enddoとかは使うみた
いだけど)。
FORTRAN77 的コードの書き方はとっても理解するのが簡単で、しかも
それなりのシミュレーションとかができてしまうので、　結局、
彼らはそれ以上のものを求めないわけね。

FORTRAN rots the brain.
というのがフォーチュンにあるけど、まさにその通りだと思う。

>>720
でもまぁ、数値計算だと「その程度の書き方」でも間に合う規模のプログラムが
多いし、良いんじゃないの？

>>719
サーバーサイドの場合、負荷がかかるのは RDBMS でロジックに回す CPU は
余ってるケースが多いからじゃないの？　Web がらみだと ASP, JSP, ColdFusion
などなどが主流で C, C++ で書くことは少ないよな。

>>719
パフォーマンスの悪さは金で解決できるし、開発・保守コストを含めれば
かえって安上がりだったりするんじゃないかな。

俺は(他人が)仕事で書いたC++プログラムの保守なんてやりたくない。
C++はオープンソースものに趣味で手を出すぐらいが好き。

>>720
「それなりのシミュレーション」ってどういう意味ですか？

>>722
もしくは Perl Python 等の script lang を、かなり大規模なとこでも
使っちゃうしね。

Perl とか Python とかは web front まわりだけだろとかいう人もいるかも
しれないけど、その認識は往々にして間違い。

>>719
> その代償として重い。

比較したことないんだろうなぁ。
JavaならSMP対応はもちろん、分散計算だって簡単なのにね。

>なんで C/C++ でがちっと書かないのだろう？

きちんとスタックガードしてね。
したら確実にJavaより重くなるけどね(w

>>726
ん? >>718 以降で話題になっているのは HPC 用途でしょ。んなもん、Java じゃ
Fortran に劣るに決ってい………
と思ったら 719 は web server とかの server side Java の話題をしているのか。

なぜ C/C++ で書かないのかは、719 が自分で書いてみればわかるだろうねぇ。

どうでもいいよ金さえ貰えれば

>>727
HPCだとなにか何か変わるの？

実はsolarisの/etc/rc2.dには、結構javaものが増えてきているという罠

というか、もはやJ2EEあたりまでいくと、言語というよりはフレームワークになってくるので
javaだけ知っててもCOBOLer状態になってしまうという罠

もうつかれちゃったよ・・・なんだよtomcatだのRMI/IIOPだのEJBだのって　くすん

>>730
まあ、メシの種だと思ってどんどん学習するしかないよね。
気を抜くと食われる側になっちゃうから。

って、ここC++スレなのか。

つーか、
Javaって単に重いだけじゃなく、
よく固まるし、未だに動作が不安定じゃん。
俺は一応学習した上で捨てたよ。

>>732
参考までに、環境は?

数値計算でも、最近はC++でやるケースが増えてきてるみたいですね。
CERNの素粒子解析システムなんかがいい例。

>>732
豚に真珠かぁ

>>729
Java と Fortran とで数値計算ライブラリの種類とコンパイラの最適化のことを
考えてみてね

>>736
数値計算ライブラリは豊富だろうね、 Fortranのほうが。
コンパイラの最適化はJavaが上だな、なんてたって実行時最適化だからね。

Fortranってこういう盲信者が多いよねぇ。
実際に比較もしないでさ。まさに阿呆徒卵（ｗ

>>736-737
C++ でも UNIX でもない数値計算ネタはシミュ板でよろしこ。

>>737
だいたいシミュレーションやる人は数学や物理には精通してるが、
計算機となると厨房、、、っていう人が大半のような気がするな。
#まぁ、本業は計算機ぢゃないからそれでいいのだろうけど。
こういう厨房がはびこってる間は、数値計算はFORTRANが主流って
ことになるんだろうな。
#まぁ、その方がコンパイラ作る側も楽だから。
CなりC++なりが主流になるのはいつのことやら。

>実際に比較もしないでさ。まさに阿呆徒卵（ｗ
だから、その前にFORTRANしかできないんだってば(藁

>>737
ベクトル化って知ってる?

>>737,739

シミュレーション結果を論文に書くことを考えると、
その学会でメジャーな言語を選択しておいた方が
理解されやすいって要因もある気がする。

で、現実にアプリケーションや計算ライブラリはどの言語で書かれてるんでしょう？

>>739
>だから、その前にFORTRANしかできないんだってば(藁

そうだね、５割くらいはそれで満足してるね。まさに井のなかのゆで蛙。

>>740
知ってるけど、それが何か？
そのレベルのことは普通はコンパイラにやらせない？素人馬鹿自慢ですか？（ｗ

>>742
C/C++だらけ。これが現実

C で数値計算、3000行ぐらいのをやってます。このスレ読んで、C++を
あんまり大層にとらえなくてもいいんだな、と思いました。
で、C++をBetter C として使うにあたって、これだけは覚えとけよ、
とうのがあったら教えてくれませんか。// だけじゃ寂しい…。

そりゃ、寂しいねえ、、、、

>>745
とりあえずinline

>>745
operator overloading、コンストラクタ、一時オブジェクト。計算に使うなら便利でしょ。

>>747
それって、Better Cですか?

>>747 ×
>>748 ○
です。スマン

>>749
クラス使わなくても実現可能な範囲だから、Cの延長として使うにはいいと思うけど。
そんな機能はbetterじゃないって事?

ありがとう。コンストラクタって new のアレだっけ、ぐらいに知識が
ないので、とりあえずあげられた事項を調べてみます。
と、数値計算といってもスピード命のクリティカルなやつではないので、
人間側がラクチンになれる方法希望(さきに書くんだった)。
STL というのも調べてみます。

>>752
> 人間側がラクチンになれる方法希望(さきに書くんだった)。
うん。伝わってるよ。>>748でイメージしてたのはこんな感じ↓の使い方。
vector = p(x1, y1) - p(x2, y2);

>>752
コンストラクタと new は違うでしょ。
ちなみに俺は C++ で書く時に new をあえて使わないようにしている。
（デフォルト以外の）コンストラクタは使うけど。

>>748
は、誰かが作ったクラスを使うのはアリってスタンスですかね。
それだったら、stlはまず使いたいところかな。

>>755
いや、>>753ぐらいの簡単なものならstruct + コンストラクタと
オーバーロードしたグローバル関数で実現できるから、クラスの概念を学ばずに
C気分のまま楽できるんじゃないかと。わかりにくくてｽﾏｿ

まあ、structにコンストラクタってもの微妙だけど。

多体問題のシムレーションのときにラクなのかな
思いついたのはそれだったんだけど・・・ < OOPの効用

関数の多重定義は?

>>741
論文でも、プログラムそのものは外に出さない場合が多くない？

>>742
アプリケーションの種類による。

最近公開する人多いよね。分野によるけど。
つーか、公開してくれ > 怪しい論文

>>758
それはOOPとは直交するような。
むしろgenericsに属すると思われ。

>>761

>>758 は >>745 に対する返答のつもりだったので。
OOPでなくてもいいんですよね。Better Cなら。

Javaって６４ビットアドレス空間に対応できるの？バイトコードインタ
プリタ―って、６４ビットアドレスで動く？　そもそもJavaの
ポインターとか整数とかは６４ビットマシンを想定してるのかな？

>>763
> Javaって６４ビットアドレス空間に対応できるの？

当然

>>764 Arrayのindexがintなのはちと不満かも。

C++ で書いて、 cfront 通すってのはどう？
って、自分ではまだ cfront 使ったこと無いんだけどね。

cでgccコンパイルして、C++使うほうがおすすめ。

>>765
32bitCPUでは 毎回long 使われて遅くなるよりゃいいでしょ。
int で不足になったら 286 とかと同じで
セグメントみたいなことやって回避するのかな？
それとも long な配列つくれるようにするんだろうか？

対応してなくてもJavaVM書きなおせば済む

なんせclassにはハード依存部分ないしー

# JNIで呼び出した側のことまでは知らんが

>>769
Java Virtual Machine Specification見ると、JVM自体は32bit仮想機械としか思えん。
64bit環境で動かした場合、どのくらいメリットあるんだろう。

>>770
VMのつくりによるところ大
理由：実装部分で吸収する部分がそれを体感できるはずだから

C++でUNIX系OSを見事に実装されている例があるのだろうか？
無いのだとしたら、C++の有効性には疑問符がつくな。
JavaでUNIX系OSを見事に実装されている例があるのだろうか？
無いのだとしたら、Javaの有効性には疑問符がつくな。

>>772

BeOSはC++で実装だな。
Unix系とは言えないかもしれんが。

>>772
>JavaでUNIX系OSを見事に実装されている例があるのだろうか？

あるよ、今あるJavaVMそのもの。
足りないところがあったらいってみてよ。

>>770
今(32bit 32bit)になってるとこが(64bit)になるだけ。
OSの64bit化と何も変わりませんが、何か？

＞773
Beは、C++の落とし穴に見事にはまって
苦しんでいた記憶があるが。

>>776
素の C++ を使うのは、

- メンバ変数一つ加えると、バイナリ互換性があっさり崩れる
- クラスの動的ローディングができない
- コンパイル時にクラスの実体が完全に固定されてしまう
　（あとでインターフェースが同じ他のクラスとかに差し替えられない）

と面倒があって、後方互換性が重視される OS の世界だと、いろいろ
厳しい。

Win32 の COM とか JavaVM みたいに、一段クッションを噛ませれば
良いんだけどさ。

COMはともかく、JavaVMはクッションにというには大きすぎじゃないか?

C#も似たようなものだわな

>>779
そか、.NETだとVM使うんだよな。.NETは言語非依存なのはいいけど、Win専用
というのが辛い。

>>780
FreeBSDでも動いてるYO!
Linux方面でもmonoとかいうプロジェクトでインプリメントしてるんじゃなかったっけ。

>>772
VFSってCで書いてるOSとC で書いてCに変換してるOSあんぞ

VFSのメモリオブジェクトほどOOPが効くもんないぞ、OSの世界では

他には、たとえばWindowsNTのカーネル資源のオブジェクト表現については、
OOP設計C実装のいい例なのかもしれん。

>>1
俺ら迫害されてるんだよ。
革命でも起こさないとダメさ。

なんか知らんがいつも変態扱いされてまそ

何説明しても「ふーん　よくわかんないんですけど、納期明日だから」としか応答してくれまそん

もうこんな生活嫌ぁ・・・

ふーん よくわかんないですけど、がんばってね

で、実際 UNIXで C++やるとして、何かいい参考書ないし参考ページある？ ぐぐったが
探し方が悪いらしくぱっとしたのが見つからない。

一応 Cで書いたライブラリは使い回せるとは言うものの、C++の文字列オブジェクトから
一々 char *とってたら馬鹿馬鹿しいだろうし、1から作り直すのは勘弁願いたいので適当
なできあいのライブラリで標準的なのもあると嬉しいのだが、特にネット関連(HTTPの処
理とか)。

>>786
KDEとかGNOME方面は当たってみた?

C++(KDE) vs C(GNOME) という感じがするのだが。
Qtは良くできてるので見といた方がいいかも。

Kylixは？

>>789
Objective Pascal

KylixはC++もつかるんじゃ？

3からでしょ？

>>790
最近になってDelphi languageとかいう名前に変わったな

program hoge;
begin
(* C経験者は書いててイライラするかも、Objective Pascal *)
end.

関数の最初に使う変数を宣言しなくちゃいけないから、
C++経験者としては、とってもイライラします。

使ってまだ日も浅いけど、Delphiの嫌いなとこ

・ operator overloadできない (まあ、これは許せる)
・ 所詮COM由来のinterface (Javaのinterfaceの方がしがらみなくて便利)
・ 継承classでメソッドの可視性さげられん (public -> privateとか。Singletonとか書くときメンドい)
・ namespaceが貧弱 (つーか殆んど無いに等しい)
・ virtual; abstract; の継承失敗が全部runtime errorなのはカンベン
・ Javaみたいにthrows欲しい...

まあ、重箱の隅っちゃー隅なんだけど。
# あー、あとプロトタイプ宣言、一字一句同じでないと致命的エラーなんも嫌い...

一応メモっとく。誰か使ってみた事ある?

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
だそうだ。

遅レス スマソ。前任者から引き継いだサーバがどうも変なので同僚と調べてたら rootkitが
仕込まれてやがんの(藁)。おかげで先週一杯 被害確認と復旧で死にかけてたもので。
ま、これであのクソなヤシもクビだと思うとせいせいするがな。。。愚痴スマソ。

>>787 >>788 なるほど、Qt(KDE)ね。GUIプログラムせんのですっかり抜け落ちてた。
>>797 能書き見る限りだとよさそうだな、これ。ためしにこいつベースでいじってみると
する。 サンクスコ

昨日のできごと。
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という事で、オプションが足りなかった
とかそんなつまらん問題だったんだろう。(´･ω･`)ｼｮﾎﾞｰﾝ

可憐に800get

C++マンセーあげ。

799のmainの行を見て一瞬Haskellかとおもっちったよ

>>1
GTK+ のソース見てみろよ。
全部 C で書かれているけどしっかりOOPになっている。
継承も使えるし、メンバ変数が直接見えないように工夫している。
関数の名前がやたら長いけど、、、

>>803
歯でビール瓶開けられるからって、偉くはないぞ。
栓抜き使えと。

(´･ω･`)

X もあるでよ

>>803 逆に漏れはGTK+見てC++をマジメに覚えようとオモタよ

C++以外は糞。

ずいぶんショボイ燃料だな。

UNIXだと、パイプを使ったりclient/serverにしたりして、かなり
一つ一つのプロセスを単純にするから、個々のツールが一つの
巨大なクラスとして働いていて、結果本格的なオブジェクト指向が
不必要になっている、という面があると思う。で、そのインスタンスが
プロセス。もちろん、プロセス間通信は、普通の関数呼び出しに比べれば
はるかに面倒だし、polymorphismなんかの有難味はあまり享受できない
けど、自然な設計単位を示してくれている、というのはあると思う。

それでもapacheみたいな巨大なプロジェクトでC++でなくCを選んだせいで
ACEのような既存の完成したライブラリを使用できず、似たようなライブラリを
自前で作ってるのは単なる間抜けだと思うが。

正直、C++はこれからでしょ。
boostがもっと一般的に使われるだろうし、
その時にはCとC++どっちがいいのか
なんてバカな話も出なくなるだろうし。

apacheで作られたCのライブラリが今後使われるようになる、
ってことはないの?

みんなC++使いこなせて良いですね．私なんて
gcc-3.2をコンパイルしたけどlibstdc++-v3, g++でerrorが
消えなくて(勉強するために)環境を整えることさえ
できませんて... せっかく本も買ったのに。鬱だ...

＞その時にはCとC++どっちがいいのか
＞なんてバカな話も出なくなるだろうし。

そのときは、C++とC##(架空)のどちらがよいか
みたいなバカな話が出てくるに一票

つまり無限ループね。

UNIXはとにかく早く試作品作って、テスト繰り返してってのが流儀だから
最初に設計して、再利用考えてってのは合わんのよ。
理想としては
「スモール・イズ・ビューティフル。
　ゆえに大規模プログラミング固有の問題は存在しない」。
現実は、場当たり主義で泥臭く何とか実用レベルに持っていく。

いつまで古事記みたいなこと言ってんだか

>>819
まぁまぁ、>>818はピラミッドの最下層にいるデジタル土方さんなんだよ(w

おまいら、Objective-C を忘れていますよ！



いや、使ったことないけどさ・・・

>>812 Apacheのライブラリ再利用は進んでいないが，GIMPのGTK+は（略

今後はこういう例が増えるといいね．車輪の再実装はやめたいよ・・・

MSだしてるMicrosoft Visual C++
のパッケージって、ほんとに入門用？
買うか買わぬか・・・
厨房に扱えるかなあ

>>823
それはさすがに板違いだろう。

ObjCはむしろCっていうよりSmallTalkだろ。

VC++はANSI C++ではありません。
またドトネト対応に忙しくてそんなことをするつもりもないようです。
というわけで本末転倒ですが、C++のプログラムを書きたいのなら、
gcc向けに書きましょう。

>>820
といいつつ、UNIXユーザって土方がマジョリティでしょ。

別に土方でいいじゃん。よくその話は聞くけど
土方だと何か問題があるのか？

>>818
> 　ゆえに大規模プログラミング固有の問題は存在しない
UVM のソースとか読んだこと無いんだろうな…と想像してみる。

>>828
俺はソリューションバブル (ってほとじゃないが) の現状はともかく、5 年後を
考えると仕事の単価が下がると見込んでる。

使えないシステムでも、とりあえず IT バブルにのって導入しちゃったし、メン
ツの問題もあるからメンテナンスしとくか、っつーお客さんが減ったときが勝負
じゃないかね。（っつーわけでソリューション系の業界から逃げました＞私）

プログラム言語を恋愛に例えると、

C　　　 純愛
C++　　愛人
JAVA　遊び相手
perl　　変態プレイ

だな。

>>831
C
やや古臭いが隠し事は一切なく純粋。信じることが大事。

C++
周りも自身も華やか。ちょっとインテルぶっている。
友達にプライベートを見せる一面も。

JAVA
基本的に親族にしかプライベートは見せない。
奥手だが育ちがいいエリート。

perl
packageでスコープを制限できるが、デフォルトでは
裸で歩いているのと同じ。言われればなんでもやっちゃう。

intelぶってるの？

>>833
まちがた

>>832
C も void* と static を使って隠すことがあります。親しき仲にも礼儀あり。

void*は隠してるのとは微妙に違わないか?

あぼーん

うそです

やっぱ lisp だな

とか脈略も無くほざいてみるテスト

おれの中では
C　=　Lisp
C++　=　Haskell,ML
ってな感じだな。
C++ユーザーはLispよりも型付関数型言語をやるほうがしっくりくる。

C
ｱｾに陰毛がはえた程度のいたいけな少女。
あそこの見た目はきれいだが、はまると一家心中。

C++
Cの陰毛がさらに繁茂、やりまくりでいつも濡れ濡れ悪女。
ケツの毛まで抜かれて、最後は自己破産。

Java
基本的に親族にしかプライベートは見せない。
奥手だが育ちがいいエリート。

perl
ただの馬鹿

＞ 裸で歩いているのと同じ。言われればなんでもやっちゃう。
(;´Д`) ﾊｧﾊｧ

＞ ただの馬鹿
(;´Д`) Σ

>>841
ワラタ

http://pc3.2ch.net/test/read.cgi/tech/1032438837/57n

C99はとろろ丼だの始めた吉野屋みたいなものか

煮込みハンバーグ定食だの始めたロッテリアみたいなものか

C爺さん　　　小言じいさん。アセンブリ曾じいさんにはかなわない。
C++氏　　　働き盛り。C爺さんがちょっとうざい。
Java小僧　　最近、ようやく社会人に。
C#ボウヤ　　MSの秘蔵っこ。実は、ひとりで外出できない。
Perl婆さん　裸の美女と間違えられたり、案外最強だったりする。

C++が使えないという、仕事には全く使えないうんこ共がC++に暴言を吐くスレというのは此方ですか？
漏れの心の師である、επιστημηﾀｿ程度には使いこなせてから語ってもらいたいもんです。

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.

epistemeが心の師なのかよ。

スレ違いかもしれんが、原子力発電所だのミサイルだの
やばそうな制御プログラムはどの言語で書くべきだと思う？
処理系の枯れっぷりから考えてC/C++やJavaでは書いて欲しくない。
許せる選択肢はFortranくらいしか残らん気がする。

適材適所ということを言いたかった。スレ違いすまん。逝ってきます。

>>851
Ada

だろうな

C++ や Java ならともかく、C なら別にいいんじゃないか？

C++ や Java ならともかく、ぬるぽなら別にいいんじゃないか？

ぬるぽって何？マジレス求む。

もうぬるぽ。
http://www.google.com/search?lr=lang_ja&ie=eucjp&q=%A4%CC%A4%EB%A4%DD

>>857
さんくす。

　 （　・∀・）　　　|　|　ｶﾞｯ　　　　　　　 （　・∀・）　　　|　|　ｶﾞｯ　　　　　　　 （　・∀・）　　　|　|　ｶﾞｯ
　と　　　　）　 　 |　|　　　　　　　　　　と　　　　）　 　 |　|　　　　　　　　　　と　　　　）　 　 |　|
　　 Ｙ　/ノ　　　 人　　　　　　　　　　　　Ｙ　/ノ　　　 人　　　　　　　　　　　　Ｙ　/ノ　　　 人
　　　 /　）　 　 < 　>__Λ∩　　　　　　　　 /　）　 　 < 　>__Λ∩　　　　　　　　 /　）　 　 < 　>__Λ∩
　 ＿/し'　／／. Ｖ´Д｀）/ ←>>855 　＿/し'　／／. Ｖ´Д｀）/ ←>>856 　＿/し'　／／. Ｖ´Д｀）/ ←>>857
　（＿フ彡　　　　　 　　/　　　　　 　　（＿フ彡　　　　　 　　/　　　　　　　 （＿フ彡　　　　　 　　/

http://www.terminator3.com/content/desktop_downloads/desktop_lg/t3_desktop_a01_1280.jpg
ターミネーターもC++で動いてるし（右側

でも printf

void main()かよ

windows.h とか HINSTANCE ってことは Windows なのか...
ターミネーターは定期的に再起動が必要なの？

なんかやなもんみちゃったな（ｗ

>>1
何だよ、｢Ｃ＋＋｣って。
オマエ厨臭いぞ。板違いだから削除依頼出しとけ。

>>864
マジレス14ヶ月目の法則ですか？

VIRUS NEC がずらっと並んでいるように見えるのは気のせいか？

Objective Camlとかはダメなんですか?
あまり綺麗な言語仕様とは思わないけど、実用的だと思う。
Cはもちろん、C++からでも充分乗り換える価値があると思うのだが。

言われてみればＣ使ってるな

プログラミングコンテストだとC++はMLやHaskellに負けまくりだけど
あれって、一般人だとどうなるんだろう？。コンテストに出てるやつは
まがりなりにも計算機についてちゃんと勉強したやつだろうからなあ。

どうって、どう？
一般人で ML だの Haskell だの名前だけでも知ってるほうが珍しいんでは？

>>852
Ada ってどれくらい普及してるんでしょうか？

ある程度以上普及してないと処理系は枯れないし、
アプリケーションの実装者側も変な失敗をする危険は
避けられないように思うのですが、そういう意味での
普及度・噂・実績はどんなもんでしょう？

マジレス希望。
ヤバそうなシステム開発の経験者の経験談、希望。

# スレ違いなら、どこかへ誘導してください。

>>871
ここか?
ほとんどネタスレだが。

米国国防省の標準高等言語エイダ（Ａｄａ）を語れ！
http://pc3.2ch.net/test/read.cgi/tech/1010492940/

ネタスレとネスレの区別がつかないのですが

タヌキさんですか?

>>862
Windowsのpwlファイルのビュアーかなんかのソースだろうか　MS謹製っぽいコメントが入ってるし

http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/devd/

/sbinでC++かぁ…

一瞬「ひょっとして、でぶでー(デブだな)というシャレ？」とか思った
2徹明けの午後。そろそろ寝ないとまずそうだ。。。

（＾＾）

>>873
ネッスルじゃなかったのか

ネッスルとマッスルの関係を述べよ。
サフィックスに日本がつく場合についても言及すること。

ネッスル＝ネットする
マッスル＝マッチする

つかわない　んじゃないんです

つか「え」ないんです、上の人間（会社の場合）or協力者（それ以外の場合）が

つまり、 C++ 自体には問題は無いという事だな。

ないんじゃない？
solarisのvfsなんてOOPで設計してるくらいだし

C++をOOP言語としてしか見てない香具師は
恥かしいので厨房レベルぐらいまでは勉強してください。
上のレスは見てるこっちが恥かしいです。
884がもの凄いUNIXハカーであればあるほど。

>>884
別にハカーじゃねーよ　vfsがOOPなのは誰でも知ってるよーなことだ。

本物のOOP言語についてはプログラム技術板の方がお似合いだから
ここでは言及しねーぜ、漏れは。

# OOP言語なんてのは、ホントはどこにもありゃしないのさ。

日本製でソースが公開されていて、C++で書かれていて複数人で
メンテナンスされているソフトを教えてください。

>>887
ないです。というより当分出てこないと思われます。
理由は関数型言語のメジャーなアプリケーションが
ないことと大体同じかと。5年後には変わっているの
でしょうが、今は無理でしょうね。

>>887
日本製ってのがアレだが

日本人も開発に参加してるってことなら groff (jgroff patch), Qt とか。英語圏でも
良ければ GNU source-highlight やら doxygen やらイロイロ。

>>888
関数型言語だと、むしろ Emacs Lisp が大量に。

>>889
C++を使うと大規模なソフトを見通し良く構築することができると
言われていますよね？日本のプロジェクトでそれを実践できている
ものがあればを見たいです。そのようなソフトが公開されてないなら、
何故無いのか知りたいです。

>>890
日本人C++プログラマの質が低いんじゃねえのって言いたいんだろ？
遠まわしになんだか嫌らしい奴だな。おれはその通りだと思うがな。
第一日本人がこれまでC++に関するまともな本を、何一つ書けてない
事実からしてもその程度が知れてるもんだと思うがな。

>>890
> 日本のプロジェクトでそれを実践できているものがあればを見たいです。
仕事だと、ほとんど C++ だけどねぇ。

> 第一日本人がこれまでC++に関するまともな本を、
日本でプログラミング関係の本を出しても部数捌けないから金にならんし、
米国と違って独立系技術コンサルタントのような仕事もあまりないので、
本を書く動機がないのが主因だと思うぞ。

技術者の層自体は、標準化委員会やなにかに人を出してる企業もあるし、
それほど薄くないんだが。

>>892
>技術者の層自体は、標準化委員会やなにかに人を出してる企業もあるし、
>それほど薄くないんだが
いや、それは一部分の話でしょ。おれが思うのは雑誌記事書いたりする
ライターからそれの読者までのようなレベルがcujなんかと比べると
えらく低いなと思うんだよ。そのことで別に卑屈になる必要はなくて
よいものはどんどん取り入れて追いつけばいい話なんだけど。

誤解招きそうだからあえて言っておきますが、おれもレベルの低い１人です。

>>894
おれ、って誰？

>>895
894=893。つまり書き込んでる自分のことです

>>896
その番号を 894 に書いて欲しかった・・・。
「書き込んでる自分のこと」 なのはわかるが、それが誰なのかこれじゃあわからんぞ。

業務系SE/PGの間では、もうCつかわないところ多いです
生産性・改造容易性ではやはりC++が上です　UMLきっちり書くところも多いですよ

ただ、性能を重視したいOSに近いところは、Cでかかないとダメだけど。
UNIX板で扱うものの半分はそれがあるでしょ？
名前空間検索ロスとか

でもそーでもないよーなのでもCで書いてるからフシギよね・・・

>>898
そーゆーのはJava使うんじゃないの？
これからならC#？

>>893
> おれが思うのは雑誌記事書いたりする
> ライターからそれの読者までのようなレベルがcujなんかと比べると
> えらく低いなと思うんだよ。
というか、ふつー質の高い情報が欲しければ cuj 読むのでは？　日本からでも
購読できるし。

>>899
> そーゆーのはJava使うんじゃないの？
過去の資産というやつが…

名前空間検索ロスってなあに？

>>899
マシンに充てるお金けちられること多いのでJavaは、、、正直Servletだけにしたい

（＾＾）

あぼーん

あぼーん

STLつかってると gccは糞遅くて使い物にならん。

あぼーん

あぼーん

あぼーん

GCCのC++対応は結構いい線いってるんだから，
FSF関係者はC++でアプリを書くことをあるていど考え始めた方がいいと思うな．
C++の導入がスムーズにできたら，今後の発展に大きく響くよ．
もちろん(マシンリソースが)しょぼい特殊用途の環境でがんばってる人のためには配慮がいるけど．

>10

たしかに qsort はないよな〜、バブルソートやろ。

ドライバ書いているけどC++って自動で余分なコード付いてくるから遅いんだよね。

Cにこだわり続けているやつでC++まともに使えるやついるのか？
ただ単に新しい言語を覚えるのをめんどくさがってるとしか思えん。
速度効率を考えるとCなんだろうが、
PC能力が格段にあがった今日、開発効率の方が重要な場合が多いと思うんだが。（ドライバ開発とかは除いてね）

複数人でまとまった規模のプログラムを書こうと思ったら、手続き型言語なんて効率悪いだろ。

>>911
qsortってクイックソートのこと？バブルより効率いいアルゴリズムだったと記憶しているが・・・

>>797
GNU Common C++ なら、こっちのページのほうがドキュメントがそろってるよ。
http://www.gnu.org/software/commoncpp/

リファレンスマニュアルをみると、かなり充実してるっぽい。
とくに Socket と Thread 関連が特徴かな。
http://www.gnu.org/software/commoncpp/docs/refman/html/index.html