C++をやめたい人が集うスレ

STLに、もう疲れました。
やめたいです。って人集まれ〜

>>1
やめるならここにもくるなよ。
何がしたいわけ？

たかがコンテナ使うごときでクソ複雑なSTL覚えるのには、
心底疲れました。何もかもがアホらしいです。

良すれ保存上げ！

>>1
じゃ、STL使うなそれぐらい自力で実装すれ

C++は、もう破滅寸前。
ここらでSTLに挫折した、全体の９５％相当のプログラマが
不買運動を起こし、消滅します。

ありがとうC言語！そしてC++さようなら！（^_^)また会えるといいね！

>>6
挫折したのはお前と根性と脳みそのないごく一部だけ。

すいません、訂正です
＞STLに挫折した、全体の９５％相当のプログラマが
＞STLに挫折した、全体の９５％相当の厨房が
でした。ごめんなさい。

Delphiにおいでよ

簡単だしパワフルだし

>>9
template がない

きにするな

STLがいやってんならなあ。templeteがないくらいなあ。

□Rubyを学んでから
男としての自信を無くしていた主人も元気を
取り戻しました。今では新婚のころを思い出して
二人で燃え上がっています。（調布・48歳　主婦）

>>3
そんなに覚える事多いか？

やっぱ、C# なのか？
使ったことないので何ともいえないけど。

>>1
STL なんて簡単じゃん？何がそんなに難しい？

煽りじゃなくって、マジレス。
って、オイラが表面だけしか見てないだけかもしれないけど

>>16
vectorとか使うだけなら簡単だけど、
拡張しようとしたりすると面倒だよね。

あと、エラー出たときは正直困る。
templateのエラーはわかりにくい。

さらに、バグもちのSTLが結構あるから、ついSTLを疑いたくなる。
所々コンパイルできないところがあるのも困る。
iterator_trats（スペル自信なし）とかをコンパイルできるコンパイラを見たことがない。

他言語との比較
「C++なんて問題外」
ﾌﾟ

ＳＴＬ（テンプレート）使うの疲れたっていうならわかるけど、

挫折する奴はそんなにいないと思われ。

「STLをやめたい人が集うスレ」に変えて続行。
STL今から使おうと思ってたのに。

Ｃ言語で充分じゃん

死言語

違う言語を上乗せした感じがして気持ち悪いからヤダ。>template
（C言語に対してのマクロプリプロセッサの様な気持ち悪さ）

C++で挫折するような奴が他で役に立つんだろうか、心配ではあるな。

stlそんなに難しいか？
拡張しようとか、内部を完全に把握しようと思うなら難しいかもしれないけれど、
使うだけなら簡単だろ。
むしろstlの無い言語は触りたくない。

>>22
死言語っておいしい。むしゃらむしゃら。
>>23
委細構わず超同感。

使いこなせねーけど、こういうのあったらいいなあ、という参考になるから役には立つ。
自分用に機能縮小したクラス作ったりとか。

HSPがいいよ。
ゲームとか作りやすいし。
でも、俺はVBで「モナービ」作るよ。出来たらDLよろしっく！

>>28
マジで氏ね。今回は本気で邪魔だ。
どうやってＨＳＰ(糞)でデータ管理するんだ？ヴォケが！！
スレ違いって言うか、首吊って氏ね。

C++ばっかり専門にやってるやつならSTL難しいとは思わないだろうけど
他の言語も色々やってると>>23みたいに感じる

>>30
そーだな。C++と共に歩んできて、
今まで維持してたこのハイテンションは、
一体なんだったんだ？という感じに陥る。

STLの拡張って具体的にどんなこと?????

STL は C++ の複雑さ(主にメモリ管理)を隠蔽するためにあるので、
そもそもメモリ管理の繁雑さがない言語のユーザからみると、
なんというか無駄に難解にみえる。

>>32
stringstream 拡張して

cdbg << "hoge" << std::endl;

ってすると、OutputDebugString するってクラスなら作ったことがあるよ。

fstream からファイルハンドルを奪いたくなったことはあるな。

確かに、C++は万能にこだわりすぎて、シンタックスやライブラリを含めた処理系
が過度に複雑になった感がある。
柔軟なデータ処理をしたければ、動的型付けができるスクリプト言語の方が
いいだろうし、大量のデータを扱うんなら、データベースを使うのがいい。

が、スクリプト言語やデータベース自身を何で記述するかと言われれば、
CかC++になるのもまた事実。

OS・処理系の記述言語としての原点に帰るってことね。

あとゲームもな。
最近のゲームは１０万行以上なんてザラだし、
Ｃ言語でなんてやってられん。

>>35
あ、それ私も思ったことある。かゆい所（でも簡単な処理）に手が届かない、みたいな。

自分で似たようなテンプレートを作れば良いジャン！
どうせ既存のテンプレートは、扱いづらい部分があるし。

ここにあるプログラム等はすべて無保証です。 プログラムの実行などの際、何か不幸な事態が起きても私は責任持てません。ファイルのバックアップを取るなど、原状を回復させるための手段を必ず確保して、よく確かめた上でお使いください。またお使いの際は必ず独自のアレンジ・拡張・改造をしてください。そのままはいけません。

　　　　　　　　　　　　　　　◎＿＿＿
　　　　　　　　　　　　.　　//　　　　　/
　　 　　 　　　　　　　　. //　ソ　　 /
　　　　　　　　　　　　　//　ラ　　./
　　　　 　　　　　　　　//　ネ　　/
　　　　　　　　　　　　//　/　　./
　　 　　　　　　 　 　//　ヨ　　/
　　　　　　　∧空∧/＿＿＿/
　　 _______　｛´ ◎ `｝＜ 　ソラネーヨ
　 ,ィィ,ィィ＼）:::::::::（
　　しししし(_つ:::::::::ヽ
　　　ヽ＿＿ノ::::::::::::::|二手
　　　　　　（;;;;;;;;;;;;;;;;;;;）
　　　　　　／／　＞＞__
　　　　＜◎:::> ＜::::◎ノ

allocatorを作ろう

http://www.codeproject.com/cpp/blockallocator.asp?print=true
http://www.edm2.com/0508/stl.html
http://home.camelot.de/langer/Articles/C++Report/Allocators/Allocators.html
http://www.josuttis.com/cppcode/allocator.html
http://www.remus.dti.ne.jp/~seigo13/stl.html
http://allocator.sourceforge.net/

ていうかプログラマをやめたい

やめてどうするんだ>44

>>36
そこまでやったにも関わらず万能じゃないところが
C++の荒らし甲斐がある(わら)ところ。

今からメタクラスの仕掛けを搭載することは「無理」だろ。
他の機能がそれを邪魔するから。

頑張れば万能になれるって思うのは大間違いで、
定方向進化にはまってしまえば専門馬鹿の道以外残ってない
という当たり前の原理の体現者が1つ増えただけ。

書く事がほぼ決まってるならC++でやるけど、
試行錯誤しながら何かする様な言語では無いと思う。

C++なんてマイクロソフトが使ってなかったら誰も使ってないと
思うんだけど、どうでしょうか？
でも逆のことで言えば、マイクロソフトがインターフェイスが、
CのシステムでC++を無理やり使わせようとしたこと自体が、
C++が敬遠されるようになった要因かも？

CとC++なんてまったく別の言語みたいなもんだから、
OSのインターフェイスからそれを使わないと中途半端だよね。
今からOS書くんだったら絶対C++で書くべきだと思うんだけど。

BeOSが普及していればみんなC++をやっていたと思うけどね、おれは。
ネイティブのアプリを作るときにシステム記述言語と同じ言語で
アプリが作られることが多い。この事実の前にC++は消えうせるのかな？

今さらUNIXってのもなんだかねぇ。
別にキライじゃないからいいんだけど、
UNIX/Cって組み合わせはあと何十年続くことやら。
むかしあったLinuxをC++で書き換える計画はどこへいったんだろう。
書き換えてよ！＞AlanCox
おれみたいなヘタレには無理だから、頼むよｗ

晒しage!

荒らしsage!

>>48
動的リンクの仕掛けが弱いから
(なぜならメタクラス的な機能が無いから)、
OSを作ったら悲しいことになるぞ。
新しい種類(既存methodのoverrideだけじゃなくて新規methodを含む)の
ドライバのクラスを追加したいと思うたびにOS全体をmakeしなおしだ(わら
それじゃUNIX(しかも古典的な)と何らかわらない。

ObjectiveCにしとけって。NeXTやMacOSXみたいなもんだ。

BeOSってAPIに相当するクラスライブラリの変更が途中で行われて、
相当混乱したらしい（伝聞）。
ソレ聞いたときは、あーあ、やっちゃったよ、って思ったね。

コンパイラば吐き出すアセンブラコードを解説した本なんてないよね。
やっぱり一つ一つ自分で確かめるしかないんだよね？

>>53
何を確かめたいの？

アマゾンで探したら？

>>53
曲りなりにもOOPな言語C++で、それを望むのは愚の骨頂だぞ。
しかも実装依存ばりばりでコンパイラごとにばらばらじゃんか。
そんなに心配なら自分で気に入る(＆当然だが実際きちんと動く)ような
コードが吐かれる、C++コード＞asmの変換(というかコンパイラ)を自分で作れ。

リンクの名前規約は存在するけどさ。

fstreamのバイナリ扱いって動作遅くないかい？

>>33
> STL は C++ の複雑さ(主にメモリ管理)を隠蔽するためにあるので、

それはかなり勘違い。美しいcontainer libraryの研究から生まれた。
最初はAdaで実装されていた。

実際STLのややこしい部分はC++の仕様や流儀からもたらされている。
templateばりばり使っているので、エラーメッセージはやっぱり分かりにくいと思う。

STLの設計は、JavaやC#のcontainerにも強い影響を与えており、
新しいframework設計流儀を生み出した。学ぶ価値があると思う。

>>56
いろいろなコンパイラが吐き出すコードを見てきたけど、
仮想関数テーブルの持ち方について見た限りでは
どのコンパイラも同じような実装だった。

とにかくコンパイラが出力した結果を見てみると勉強になる。
解ってしまえば単純な実装ばかりだけれど、
不安がなくなるというのは大きい。

C++ほど実装が丸見えなOO言語は珍しい。
アセンブラの知識があればほとんど把握できるぞ。

>>56 >>59
ありがとうございます。今度暇を見てコンパイラの吐き出すソースを追っかけて
みようと思います。
C++ってどんなふうにコンパイルされているのか、それが分からないことには
理解したとはいえないですよね。

>>60
ああ、そういう目的なの？
Object modelが書いてある本が翻訳されているよ。
「注解 C++ リファレンスマニュアル」(通称ARM)
CFrontを実装していた人のは「C++オブジェクトモデル」だったかな。

>>58
>STLの設計は、JavaやC#のcontainerにも強い影響を与えており

影響というほどの影響があったかなあ？
javaとかはtemplateなんて使わずに実現してるから
かなり大きな差が有ると思うけど。

一方でtemplate使うかどうかと別の問題については、
コンテナ系なんてどうせ誰が実装しても似たような定番の
クラス＋メソッドになるようだし。

>>61
C++のObjectモデルは糞。
あそこまでやっておきながら、なぜあと一歩、
「VMTにアクセスする変数や関数」を
用意しなかったのかが、謎すぎ。

「VMTにアクセスする変数や関数」があると何が出来ます？

リフレクション。

正確にはVMTを直接アクセスするわけではないし、
VMT以外にも動的にクラス・インスタンスの情報に
アクセスしないといけないんだけど。
C++は機能過多な割にこの辺が決定的に弱い。

VMTってなんですか？

仮想関数卓では？

リフレクションが有効に使える場面って何があるの？
あと、それはデバッグを困難にせずに使える？

virtual method table?

>>67

特殊すぎるかもしらんが

C++で綺麗に書いたアプリケーションに、そのアプリを操作する
独自のスクリプト言語を実装したい場合なんかどう？

Windowsならまだしも、UNIXでそれやろうとするとわりと鬱

デバッグの方はパス.

>>67
・ダイナミックキャスト
・オブジェクトのシリアライズ・永続化
・開発環境との連携(フォームデザイナなど)
・テスタ・デバッガとの連携(TestingFramework, インスペクトなど)
・その他小細工

他にもあるかな？

>>64
完璧すぎておつりが山のほうにくるフォロー感謝。
そういう概念を無理矢理一言で言い表したかったんだが、
失敗だったようだ。というわけでフォロー感謝。

>>67
>デバッグを困難にせずに

型がちがちにしないとデバッグが困難になる、という都市伝説は
せいぜい3割くらいしか当たってないと思われ。
それよりも、型がちがちだとどうしても必要になる記述が
実はかなりの部分が「無駄」だったのだと気付くことは
開発効率について新たな視点を体得するためには重要。

それにJavaみたいな言語構成ならば、型がちがちとリフレクションとを
うまく住み分けさせられるから、C++系言語に馴染んだ目にも
あんまりきつくないと思うぞ。

>>69
面白い試みだとは思われ。
JavaやObjectiveCでやってみる価値あるかも。
あ。Javaで実装されたPythonなどがもしかして既にやってるかも。

WinってもしかしてCOMとかの話っすか？
あれはOS自体がリフレクションばりばりな言語(のバックエンド)を
支援してるようなもんっすね。
unixだとGNOMEやKDEがそれを目指そうとしてるところ。

>>70
そそ。それそれ。どもども。
というか、それらは互いに密接に結びついてるよね。
DYNキャストが出来るからこそシリアライズで楽が出来るし、
シリアライズが出来るからフォームデザイナで楽が出来る。

#ここでいう楽とは、全てのクラスにいちいちメソッドの実装を作らなくてもいいという意味。
#全部のクラスで使えるシリアライズメソッドとかが一発で書けてしまう。

あ。デバッグが「却って」楽になる、というのは言えてると思う。
というか逆にいえば、VC++のデバッガのObject表示なんざ
なんぼ涙ぐましい努力をしてるんだろう？と思うと合掌しちまう。
あんなのリフレクションがあれば一発楽勝で実装できるんだが。

リフレクションって元々lispから生まれた概念だから
そっち調べた方が早いと思うけど。

>>64
>C++は機能過多な割にこの辺が決定的に弱い。
ここらへんの機能をおもいきってぶち込んじゃえばいいような
後付けしたってそんなに歪な仕様にはならないと思う

んー、COMってリフレクション支援に使えるの？
言語オタ以外の視点でのコメントを期待。

Javaには、途中からリフレクションと呼ばれる機能が入ったと思うけど、
それを直に叩いてる人っている？
それとも、何かのライブラリがコッソリ使ってるだけ？

OpenJava
http://www.hlla.is.tsukuba.ac.jp/~mich/openjava/
CLOS(Common Lisp Object System)の
MOP(Meta Object Protocol)もどき？が入ったJava。
Reflection機能が強化されてるらしい。
類似品にOpenC++とかがあるみたい。

>>71
> 型がちがちにしないとデバッグが困難になる、という都市伝説は
> せいぜい3割くらいしか当たってないと思われ。

> それよりも、型がちがちだとどうしても必要になる記述が
> 実はかなりの部分が「無駄」だった

興味ある主張なんだけど、これを裏付けるデータってある？

>>74
期待age

裏付けないデータならあるよ

型なし言語逝ってよし
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=986355498

>>74
使えるよ。ITypeLib とか IDispatch(Ex) なんかがその辺のサポートを
している。

ごく単純なCOM (CoCreate, QueryInterface, AddRef, Release) の
約束事を一歩でると(出る方向にもよるけど)リフラクションをするための
機構に即出会う。ただ、C++ は呼び出し規約の動的なナニソレにネイティブで
対応していない - また、しにくい - 言語だから、コーディングのときには
埋め込み SQL のノリで VBS を埋め込みたくなる。

>>75
シリアライズとかORBとかBean関係とかの裏方でバンバン使われてるけど
普通のアプリじゃそれほどお世話にならない
(一応コンパイラ言語?だからリフレクションっていっても
ほとんど情報の参照のみだし。)

>>81
Delphi,C++Builderで思いっきり使ってんだけど。
これが無ければ窓一枚まともに出せないよ。

> リフレクションが有効に使える場面って何があるの？

AbstractFactoryやFactoryMethodをもっとsimpleに記述できる。
というような用途には今すぐにでも使いたい。

ただ、OS kernelの記述も視野に入れたruntimeの効率も重要な課題であるC++に、
reflectionを入れるのはまだ早いと思う。今後の研究課題。

# ちなみにOpenC++ってのはMOP喋るよん。

C/C++しか使えないヤツらが鬱陶しいと思うのは俺だけか?

>>84
そいつらがどういう概念を理解すれば鬱陶しくなくなるんだい？

http://www.shiro.dreamhost.com/scheme/trans/beating-the-averages-j.htm
LISPはともかくとして、この記事の「ほげ言語」のパラドックス
あたりを読んで、肯定的、あるいは否定的でも構わないが
物事にはいろんな見方があるし、いろんな意見がある、ってことを
分かってくれればそれでOKかな。

他言語には見向きもせず、C++マンセーとか逝っている連中は、
ちと疲れるところがある。

>>86
URLの最後の'l'が抜けているよ。

ようするに井戸の中のでかい顔の蛙が嫌い、ってことか。

>ただ、OS kernelの記述も視野に入れたruntimeの効率も重要な課題であるC++に、
>reflectionを入れるのはまだ早いと思う。今後の研究課題。
うーむ、いまさら今後の課題とか言われてもね。
Rubyみたいに抱き合わせで無理やり使わせる必要なんて無くって、
昔のTurbo Pascalみたいにvirtual使わなければvmtなんて作らないというように
オプショナルにしとけばいいんでない？

DelphiでもRTTI情報を含めるかどうかコンパイラスイッチで
指定するしね。TPersistentの実装をみてちょ。

>>88
既にそうなってるんじゃない？ >C++

>>89
でも、そんな(RTTIつきでコンパイルされた)TPersistentクラスが
標準装備ライブラリのめちゃめちゃ中核を成すクラスである、
という点もまた、謀らずもRTTIの普遍的役立ち度を
物語ってるんじゃないかと思うが。

>>90
というかそれは最適化の範疇だよね？
不要かどうかはコンパイル段階にわかるわけだし、
「誤って」virtualなクラスで設定オフにしたら困ったことになるわけで、
自動的に切り替えるべきものと思われ。

ruby(やObjectiveC(わら))がRTTIを抱き合わせにしてるのは、
(釈迦説法とは思うが)Objectの構造自体がC++と違うせいでしょう。
静的な構造をもつ構造体の延長としてClassを作っている言語とは
成り立ちが違うって奴。

ただ、rubyなんかの速度(速くもないが遅くもない)を見てると、
RTTIとの縁を少なめにするというリスク(?)と引き換えにしてまで
静的っぽいClassアーキテクチャを採用することのメリットが
どれだけあるか？というと、かなり…うーん…と思わざるを得ない。

それにしても、RTTIはともかくVMTすら無い「OOP」って
OOPと呼べるんだろうか？
欲しくなったときに何時でも気兼ねなくVMTを使ると限らない
(という設計を強いる必要がしばしばある)ような状況を
OOPと呼ぶんだろうか？

>>91
OOP云々は下手に持ち出すと言語オタが押し寄せてくるのでやめたほうがいい
sage

>>91
あ、RTTIにケチを付けるつもりは全くありません。

DelphiはすべてのクラスにRTTI情報を強制的に付加するのではなく
TPersistent派生クラスに限ってRTTI情報を付加していますよね。

だから>>83のいう効率とRTTIは両立可能であると言いたかったのです。

>それにしても、RTTIはともかくVMTすら無い「OOP」って
>OOPと呼べるんだろうか？
例えば高速に処理する必要のあるようなプリミティブなクラス「ごとき｣に
RTTIだのVMTだのOOPだの動的生成だのなんて持ち出す必要はない。
C++の位置付けを無視して動(or Ruby)的でないって批判は見当違いだよ。

C++のclassの仮想関数テーブルってvirtualなメソッドを持っているときに自動的に付けられるよね。
自動的に付かないというのはどういう意味？
まぁデフォルトでvirtualになってもいいとは思うけど、
まだＰＣの速度が遅く、OOが理解されていなかった時代に、
virtualをデフォルトにしたら、それこそ今以上に非難されていただろう。

JavaやC#やEiffelはいい言語だ。
でもCやC++は、そういう高級言語と、アセンブラの間を埋める言語なんだよ。
今のWindows2000があるのはC++があるからだろう。
Cで作られたGNOMEや、ObjectiveCで作られたMacOS Xは、重くて不安定だし、
Javaで作られていたら劇重だろうね。

>>88,>>91 今のC++の話してるんだよね？
VMTなんて必要なければはなっから作らないよ。

>>93
RTTIと両立できるのは今や誰でも分かってるし、そもそもC++のRTTIはそう設計された。
RTTIじゃなくてMOPの話してたの。Class, instance, slot, VMT等がfirst class objectになって、
それらの振舞いが記述できる、ってことなんだけど。

みなさん、すごいですね。感心します。
昨日や今日C++やり始めたなんて感じじゃなさそうですが、
もうどれくらいやっているのでしょうか？

俺5年

>>95
>でもCやC++は、そういう高級言語と、アセンブラの間を埋める言語なんだよ。
>今のWindows2000があるのはC++があるからだろう。

それはダウトだなあ。本当にそう機能してるの？
性能や安定性(やメンテ性)を求めた結果がアレか？という…

>Cで作られたGNOMEや、ObjectiveCで作られたMacOS Xは、重くて不安定だし、

GNOMEは(COM並に)動的だ(から重い＆不安定)っていう話？
だとしたらW2kの上で動くCOMだのOLEだのの立場をどう説明したらいいのだろう？

#ところでNeXTは重くて不安定だったんでしょうか?そりゃ重さは当時じゃ言うまでも無かったろうけど。

GNOMEやOSXは単に実装がこなれてないだけでわ。
むしろMSが、15年も前から存在するC++を使っても、そこそこ安定なOSが今まで作れなかった、
と解釈するほうが合っているような気がする。

ともかく、C++の(Cに比べて)OOPっぽい構文チェック能力は欲しいと思う
(バグはしばしばそこに潜むわけで)が、それでコンパイルし生成される
Objectモデルも同時に欲しいと思うかどうかはまた別だな。
ユーザーが選択できるようになってたら理想だったかも。

あるいは、javaかdelphi(わら)程度の複雑度と柔軟度を持ったC系Native言語、だったら
良かったのでわないかと。

>Javaで作られていたら劇重だろうね。

Javaはまた別の問題でしょう。

>>96
>RTTIじゃなくてMOPの話してたの。Class, instance, slot, VMT等がfirst class objectになって、
>それらの振舞いが記述できる、ってことなんだけど。

そうだったの？＞話
ただ、その手のFCOが欲しいってのは、覇夏至く同意。
ClassObjectなんて、ReadOnlyでもいいから是非欲しい。

>>99
>性能や安定性(やメンテ性)を求めた結果がアレか？という…

おれはWindowsNT系OSの安定性は驚異的だと思うけどね。
ネットワークカードとマザボの相性でブルースクリーンが出て、
OSが原因だと思い込むような厨房たちが騒いでいるだけ。

>GNOMEは(COM並に)動的だ(から重い＆不安定)っていう話？
>だとしたらW2kの上で動くCOMだのOLEだのの立場をどう説明したらいいのだろう？

そうではなく、COMだOLEだと積み込みながら、速度と安定性を両立しているのは
C++が効果的だからではないか、という話。

>#ところでNeXTは重くて不安定だったんでしょうか?そりゃ重さは当時じゃ言うまでも無かったろうけど。

当時から重かったけれど、Display PostScript だからしかたがないわな。
評価できるほど使ってないので安定性がどうこう言うことはできないけれど、
ハングアップしてマウスカーソルしか動かなくなることはあった。
ネットワークに繋がっているNeXTが一斉にハングしたこともあったな。

>むしろMSが、15年も前から存在するC++を使っても、そこそこ安定なOSが今まで作れなかった、
>と解釈するほうが合っているような気がする。

例外もテンプレートもSTLも仮想関数すらもなく、規格も定まっていなかった１５年前のC++と比べてもねぇ。
それに10年前のMSにはオブジェクト指向を理解している技術者が少なかったのではないかと思う。
WindowsNT4を作る頃になってようやくC++やJavaを使えるようになってきたところでは。

>WindowsNT系OSの安定性は驚異的

驚異的というのも言いすぎでわ…。

>例外もテンプレートもSTLも仮想関数すらもなく、規格も定まっていなかった１５年前のC++

逆にいうとOLEってそんなに新しかった？
Javaよりは古かったのでわ…

どっちかってーとリファクタリングというかDailyBuildというか(今風に言えば)の
効果のほうを高く評価すべきなんじゃないか…と思うが、どうせソースが見れるわけ
でもないんで(わら)憶測に留まる。

#セキュリティを捨てることでどれだけ速度が稼げるのかは知らない(わら

よむだけで、ほかのスレより３倍くらい疲れるスレッドだな

さっぱり意味がわからない

WindowsはCとC++を適材適所でつかっておる。なかなか良い。
GNOMEはC++を使うべきところまでCで書いておる。これからも安定せんかもね。

で良い？
良いならGNOMEの何処をC++で書くべきか意見希望。
KDEは全部C++ですね。

でもKDE無くなりそうだね

>>104
why?

>>WindowsNT系OSの安定性は驚異的
>驚異的というのも言いすぎでわ…。

サポートしなけりゃならないハードウェア/ソフトウェアの数を考える
と驚異的だと思いますよ。

NT3.51->NT4.0での設計変更がなければもっと安定していると思いますが。
# サーバ版ではグラフィックはカーネルから外して欲しいなあ。

>逆にいうとOLEってそんなに新しかった？

OLE2はWin3.1からだから10年くらい前ですか？
基本的なアーキテクチャはその時からほとんど変わってないですね。
その頃はOLEでもCでの実装がメインだったんじゃないでしょうか。

>NT3.51->NT4.0での設計変更がなければもっと安定していると思いますが。
># サーバ版ではグラフィックはカーネルから外して欲しいなあ。
WinXPでカーネル統一するから無理。
それどころか今度はIISがカーネルにぶち込まれるらしいよ(藁

>>106
> サポートしなけりゃならないハードウェア/ソフトウェアの数を考える
> と驚異的だと思いますよ。

では、Windows, *BSD, Linuxは全て驚異的、ということで。

ただ、「ソフトウェアの数」が問題になる所は、

> NT3.51->NT4.0での設計変更がなければもっと安定していると思いますが。
> # サーバ版ではグラフィックはカーネルから外して欲しいなあ。

と同じように、Windowsがlow-level interfaceを重要視するOSで、
「驚異的」を返上しないといけない所だな。

>WinXPでカーネル統一するから無理。

いや、だからサーバ版だけ。それならサーバ版とワークステーション版
(正式な名前忘れました)の値段が違っても納得できる:-P

>>107
>それどころか今度はIISがカーネルにぶち込まれるらしいよ(藁
Linuxでは既に（機能限定）HTTPDがカーネルに入ってます。

NT3.51以前のOSでグラフィックドライバがコケるとどうなるの？
カーネルは生きてて画面が出ないだけ？

C++に関係なくなってきたな

>> サポートしなけりゃならないハードウェア/ソフトウェアの数を考える
>> と驚異的だと思いますよ。
>
>では、Windows, *BSD, Linuxは全て驚異的、ということで。

*BSDやLinuxがサポートしているハードなんて
Windowsと比べたら数えるほどしかないと思うが。
メルコのUSB接続の無線LANが使えるなら教えてくれ。
使うから。

>>Windowsと比べたら数えるほどしかないと思うが
思ってるのは言いが、堂々と人に言わないようにね。

>>113

108は、Windows と Linux/*BSD の supported hardware の数を比べて
ないだろ。比べることが目的の発言ではない。

Windows のドライバはサードパーティが作ってんだぞ。
動かなきゃ商売にならんのだからハードメーカが対応してんだ。
アホか。

Windowsの方がサポートされているハードウェアが多いのは当然だ。
そこを指摘してるわけじゃないだろ？阿呆。

OSネタはもういいので、C++の話をして下さい。このスレのファンの一人として。
もしくはハードウェアを抽象化させるためにC++をどのように用いたらよいのか？
なぁーんて話でもいいです。勝ってすみません

了解。ごめん。

C++よりMFCやめたい

「C++でOS」に話を戻すと、
一番の問題はMOPとまではいかなくてもclass objectがないから、
「これはscsi_disk interfaceを継承したclassだから」
というlogicを別に作らなければいけないこと。

そこがOO風にならなければ「C++的OS」ではないので。

// 「C++をやりたい人が集うスレ」になっているのは問題ないのか？
// 俺的にはない。C++を止めるつもり全くないので。templateマンセー！

MOP とか FCOって何？

>>122
ここ参照
http://homepage2.nifty.com/rohizuka/pa/pa_003_a.htm

>>123
なんかへんな音してきたんですけど･･･

>>123
そこ、見たことあるヨ。

>>125
グロですか？心霊ですか？

普通のページ>126

FCO (first class object)
ttp://java-house.etl.go.jp/ml/archive/j-h-b/001927.html

適当にgoogleしただけ。

>>123
マ板に帰れ。ウザイ。

class variant
{
// variantって名前から想像がつくとおり、どんなデータ型でも格納できるごった煮クラス
};
を定義して、クラスのメソッドは
typedef variant (*method)(const map<string, variant>& in, map<string, varint>& out)
に統一し、
各クラスは
class
{
map<string, method> method_table;
map<string, variant> member_table;
};
を持つってことでどうでしょうか。
（もはや、何言語だかわからん）

アホだぁな

>（もはや、何言語だかわからん）

てゆーか、(C++使って)新しい言語を自作してるに過ぎないのでわ…(^^;;;;

そこまで必要になってしまう状況においては、C++では足りない、
という話になると思われ。

ttp://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html

ちょっとしょっく。

>>133

ものすごく有名でこの板でも何度もがいしゅつのネタ（Joke）

言語拡張したけりゃlispでも使えや

ネタか。まじだとおもったyo

まじにとるやつもいるだろうね

C++やりだしたら、Cは忘れてしまうものですか？
C++にできない、Cならではの技ってあるのですか？

>>138
そもそもCを知っているのか？

>>138
中1で方程式を習うと鶴亀算を使いたくなくなるような感じと思われ。

>>133
俺はマジに取ってるけどな、言ってること間違ってないし

>>139
レスありがとうございます。
かろうじて齧ってる程度です。はじめての言語で、Cによってプログラミングのおもしろさを初体験したから、未練というか、Cにこだわり抜くという道もありかなと。それだけにまた、C++がCの上位互換なら、C++を自分のスタンダードに据えなおすべきかも、、、とも思ったりするのです。
>>140
レスありがとうございます。
そんな感じですか。ふうううむ、、、

Cの良技、荒技、神技はC++に取っての水爆である。
それはC++にはC++の使い方がある為であって
決してCの技が劣っているわけではない。

神よ、お許しください。
私はC++に溺れるあまり、Cでの地道な愛を忘れてしまいた。
アーメソ
　　　　　　　　　　　　　　　　　　　　　　　　　　2001/08/03 ぢょん

>>142
じゃぁとりあえずこだわり抜いてみれ。
ただ、Ｃの言語仕様で完全に満足してしまったら、そこから先には進めないと思うから注意だ。

＃俺がＣを極めているかは謎だが（藁

Cだけやってもだめだよね。汗やらないとほんとに分かったことにはならない。
C++もそうなのでは？この手の言語ってどうしてもコンパイラの仕様から離れられない。

>>144
CをC++に置き換えて読むと面白い。
C++で満足したら先に進めない。ナイスな真理だ。

「C++の先」を考えてない真性C++厨毒な奴がいたら、謹んで排除してあげましょう。

>>144
CをJavaに置き換えて読むと面白い。
Javaで満足したら先に進めない。ナイスな真理だ。

「Javaの先」を考えてない真性Java厨毒な奴がいたら、謹んで排除してあげましょう。

>>133のサイト
超ガイシュツ有名ページだが
ネタかマジかどちらなのか
はっきりさせている情報にはめぐり合ったことがない。

>>146
まったくそのとおりだと思うよ。>>86 さんのURL参照ってことですな。

>>148
http://www.research.att.com/~bs/bs_faq.html#IEEE
は？

>>144
レスありがとうございます。
こだわり抜いてみようかな。。。そうする価値はありそうで、まだ知らないCのおもしろさはまだまだありそう。
一方C++にも関心があるから、、、とりあえずC++についてはせめてコードを読めるようになりたい。。。120%厨房なわたくしです。
ひとつの言語を極めている方、いくつもの言語をあやつる方、、、あゝそういう方々には世界がどのように見えるのだろう．．．。
（あ。あと汗も気になりますね。）

>>149
英語かんべんしてよ。読むの疲れるし...
Excite翻訳しても、意味わからないなあ。参った参った。

GT3はC++で書かれているってホント？

>>151
本人があの記事は嘘だと言っているだけ。
数行の文ですが本当にわかんないの？ネタor何らかの意図でわからないと言っているのか？

>C++もそうなのでは？この手の言語ってどうしてもコンパイラの仕様から離れられない
例が思いうかばないのですが、たとえばどういう感じですか？>145

おしえてください(C++書きですが汗しりません)。

>>151
英語読むまでもないと思うぞ。
C++作者が「真のハッカー」ならば、たとえどんなにCoolだったとしても所詮JOKEに過ぎないもの(=C++)を
15年以上も自らFollowし続けるとは思い難い。ハッカー(の自覚が有る人)なら
ハッカーは芸人じゃないということくらい気付いているだろうからね。

ちなみに真のハッカーでなかったならば、最初からC++は却下(わら

MOPの話をしていた皆さんの再登場期待age

>>135
CLOS is cool !

C++がこの先どんどんでかくなるならいっそのことLispの方がまだ分かりやすいと
思うのは気のせいかしら。。

読むのCより簡単だったりして…　Cのコード読むのって　呼び出した関数の機能
をしっかり把握しなくちゃ条件が多くなると何回も読み直したりするじゃん
糞みたいな名前付けてて訳わかんなくなるし
C++だとオブジェクトの性質をいくらかまとめているからその文把握しやすい
オブジェクト指向のオのじも無いコードだとCより悪い

lispとかschemeはコードの最適化をユーザーレベルでも行なえる。
処理系が用意したオプティマイズ機能使うだけでもいいけど、
自分で都合の良い様に構文を作ったり、効率の良いコードに変換
するプログラムを作ると、それを言語の機能の一部として使える。
応用すれば、プログラムの全ての関数をインライン展開して、
たった１つの巨大な関数へまとめたりもできる。
（展開しまくると、人間には到底把握できそうにないコードの
固まりになるけど、ちゃんとしたlispプログラム。そのまま配布にも使える。）
関数型としてプログラムを組む場合は、OO機能は特に必要ないけど、
必要ならそういうコーティングもできる。

いつになったら独習C++レベルを抜け出せることやら･･･

>>162
>たった１つの巨大な関数へまとめたりもできる。
まあ展開だけなら簡単だよね。lispとかの場合。

C++の最新の仕様はどこで手に入りますか？

C++の最新の仕様
で検索すれば

>>163
http://www.ansi.org/ から検索したところ、次のドキュメントが見
つかりました。中身確認してないけど、これじゃないかな。

http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%2D1998

ISO/IEC 14882-1998
Information Technology - Programming Languages - C++
(US$ 18)

ありがとう。>>165
これって標準になったやつだよね？
これが最新だとすると次のドラフト案なんてものはまだまだ
出てないってことかな？

>>166
ドラフト以前の情報を、
http://anubis.dkuug.dk/jtc1/sc22/wg21/で読むしかないと思うよん。

C++やめました。

>>168
おめでとう。

童貞捨てました

>>170
おめでとう。

>>170
おめでとさん。

次はどこへゆくのですか。

もちろんCLRです