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

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

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

1 :デフォルトの名無しさん:2001/07/23(月) 01:41
STLに、もう疲れました。
やめたいです。って人集まれ〜

2 :デフォルトの名無しさん:2001/07/23(月) 01:46
>>1
やめるならここにもくるなよ。
何がしたいわけ?

3 :1じゃないけど:2001/07/23(月) 02:20
たかがコンテナ使うごときでクソ複雑なSTL覚えるのには、
心底疲れました。何もかもがアホらしいです。

4 :デフォルトの名無しさん:2001/07/23(月) 04:28
良すれ保存上げ!

5 :デフォルトの名無しさん:2001/07/23(月) 04:31
>>1
じゃ、STL使うなそれぐらい自力で実装すれ

6 :デフォルトの名無しさん:2001/07/23(月) 04:34
C++は、もう破滅寸前。
ここらでSTLに挫折した、全体の95%相当のプログラマが
不買運動を起こし、消滅します。

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

7 :デフォルトの名無しさん:2001/07/23(月) 06:52
>>6
挫折したのはお前と根性と脳みそのないごく一部だけ。

8 :デフォルトの名無しさん:2001/07/23(月) 06:59
すいません、訂正です
>STLに挫折した、全体の95%相当のプログラマが
>STLに挫折した、全体の95%相当の厨房が
でした。ごめんなさい。

9 :デフォルトの名無しさん:2001/07/23(月) 07:52
Delphiにおいでよ

簡単だしパワフルだし

10 :デフォルトの名無しさん:2001/07/23(月) 07:56
>>9
template がない

11 :デフォルトの名無しさん:2001/07/23(月) 08:05
きにするな

12 :デフォルトの名無しさん:2001/07/23(月) 08:09
STLがいやってんならなあ。templeteがないくらいなあ。

13 :SHIGE:2001/07/23(月) 08:28
□Rubyを学んでから
男としての自信を無くしていた主人も元気を
取り戻しました。今では新婚のころを思い出して
二人で燃え上がっています。(調布・48歳 主婦)

14 :デフォルトの名無しさん:2001/07/23(月) 08:40
>>3
そんなに覚える事多いか?

15 :しゃーぷっ♪:2001/07/23(月) 09:29
やっぱ、C# なのか?
使ったことないので何ともいえないけど。

16 :大学夏厨房:2001/07/23(月) 10:35
>>1
STL なんて簡単じゃん?何がそんなに難しい?

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

17 :デフォルトの名無しさん:2001/07/23(月) 11:12
>>16
vectorとか使うだけなら簡単だけど、
拡張しようとしたりすると面倒だよね。

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

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

18 :Ruby信者:2001/07/23(月) 12:42
他言語との比較
「C++なんて問題外」
プ

19 :デフォルトの名無しさん:2001/07/23(月) 12:43
STL(テンプレート)使うの疲れたっていうならわかるけど、

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

20 :デフォルトの名無しさん:2001/07/23(月) 14:31
「STLをやめたい人が集うスレ」に変えて続行。
STL今から使おうと思ってたのに。

21 :デフォルトの名無しさん:2001/07/23(月) 17:54
C言語で充分じゃん

22 :デフォルトの名無しさん:2001/07/23(月) 18:29
死言語

23 :デフォルトの名無しさん:2001/07/23(月) 21:29
違う言語を上乗せした感じがして気持ち悪いからヤダ。>template
(C言語に対してのマクロプリプロセッサの様な気持ち悪さ)

24 :デフォルトの名無しさん:2001/07/23(月) 21:59
C++で挫折するような奴が他で役に立つんだろうか、心配ではあるな。

25 :デフォルトの名無しさん:2001/07/23(月) 21:59
stlそんなに難しいか?
拡張しようとか、内部を完全に把握しようと思うなら難しいかもしれないけれど、
使うだけなら簡単だろ。
むしろstlの無い言語は触りたくない。

26 :ヘンナ:2001/07/23(月) 22:12
>>22
死言語っておいしい。むしゃらむしゃら。
>>23
委細構わず超同感。

27 :デフォルトの名無しさん:2001/07/23(月) 22:20
使いこなせねーけど、こういうのあったらいいなあ、という参考になるから役には立つ。
自分用に機能縮小したクラス作ったりとか。

28 :Cool:2001/07/23(月) 23:11
HSPがいいよ。
ゲームとか作りやすいし。
でも、俺はVBで「モナービ」作るよ。出来たらDLよろしっく!

29 :デフォルトの名無しさん:2001/07/23(月) 23:14
>>28
マジで氏ね。今回は本気で邪魔だ。
どうやってHSP(糞)でデータ管理するんだ?ヴォケが!!
スレ違いって言うか、首吊って氏ね。

30 :デフォルトの名無しさん:2001/07/23(月) 23:15
C++ばっかり専門にやってるやつならSTL難しいとは思わないだろうけど
他の言語も色々やってると>>23みたいに感じる

31 :デフォルトの名無しさん:2001/07/23(月) 23:25
>>30
そーだな。C++と共に歩んできて、
今まで維持してたこのハイテンションは、
一体なんだったんだ?という感じに陥る。

32 :デフォルトの名無しさん:2001/07/24(火) 00:43
STLの拡張って具体的にどんなこと?????

33 :デフォルトの名無しさん:2001/07/24(火) 00:46
STL は C++ の複雑さ(主にメモリ管理)を隠蔽するためにあるので、
そもそもメモリ管理の繁雑さがない言語のユーザからみると、
なんというか無駄に難解にみえる。

34 :デフォルトの名無しさん:2001/07/24(火) 00:49
>>32
stringstream 拡張して

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

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

35 :デフォルトの名無しさん:2001/07/24(火) 00:55
fstream からファイルハンドルを奪いたくなったことはあるな。

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

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

37 :デフォルトの名無しさん:2001/07/24(火) 01:15
OS・処理系の記述言語としての原点に帰るってことね。

38 :デフォルトの名無しさん:2001/07/24(火) 02:00
あとゲームもな。
最近のゲームは10万行以上なんてザラだし、
C言語でなんてやってられん。

39 :デフォルトの名無しさん:2001/07/24(火) 02:45
>>35
あ、それ私も思ったことある。かゆい所(でも簡単な処理)に手が届かない、みたいな。

40 :デフォルトの名無しさん:2001/07/24(火) 05:01
自分で似たようなテンプレートを作れば良いジャン!
どうせ既存のテンプレートは、扱いづらい部分があるし。

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

42 :デフォルトの名無しさん:2001/07/26(木) 06:33
               ◎___
            .  //     /
              . // ソ   /
             // ラ  ./
             // ネ  /
            // /  ./
             // ヨ  /
       ∧空∧/___/
   _______ {´ ◎ `}<  ソラネーヨ
  ,ィィ,ィィ\):::::::::(
  しししし(_つ:::::::::ヽ
   ヽ__ノ::::::::::::::|二手
      (;;;;;;;;;;;;;;;;;;;)
      // >>__
    <◎:::> <::::◎ノ

43 :デフォルトの名無しさん:2001/07/27(金) 01:00
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 :デフォルトの名無しさん:2001/07/27(金) 01:53
ていうかプログラマをやめたい

45 :マジレス:2001/07/27(金) 03:11
やめてどうするんだ>44

46 :デフォルトの名無しさん:2001/07/27(金) 04:45
>>36
そこまでやったにも関わらず万能じゃないところが
C++の荒らし甲斐がある(わら)ところ。

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

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

47 :デフォルトの名無しさん:2001/07/27(金) 05:04
書く事がほぼ決まってるならC++でやるけど、
試行錯誤しながら何かする様な言語では無いと思う。

48 :デフォルトの名無しさん:2001/07/27(金) 05:15
C++なんてマイクロソフトが使ってなかったら誰も使ってないと
思うんだけど、どうでしょうか?
でも逆のことで言えば、マイクロソフトがインターフェイスが、
CのシステムでC++を無理やり使わせようとしたこと自体が、
C++が敬遠されるようになった要因かも?

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

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

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

49 :デフォルトの名無しさん:2001/07/27(金) 06:57
晒しage!

50 :デフォルトの名無しさん:2001/07/27(金) 07:04
荒らしsage!

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

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

52 :デフォルトの名無しさん:2001/07/28(土) 02:03
BeOSってAPIに相当するクラスライブラリの変更が途中で行われて、
相当混乱したらしい(伝聞)。
ソレ聞いたときは、あーあ、やっちゃったよ、って思ったね。

53 :デフォルトの名無しさん:2001/07/28(土) 04:32
コンパイラば吐き出すアセンブラコードを解説した本なんてないよね。
やっぱり一つ一つ自分で確かめるしかないんだよね?

54 :デフォルトの名無しさん:2001/07/28(土) 09:39
>>53
何を確かめたいの?

55 :>53:2001/07/28(土) 09:46
アマゾンで探したら?

56 :デフォルトの名無しさん:2001/07/28(土) 14:00
>>53
曲りなりにもOOPな言語C++で、それを望むのは愚の骨頂だぞ。
しかも実装依存ばりばりでコンパイラごとにばらばらじゃんか。
そんなに心配なら自分で気に入る(&当然だが実際きちんと動く)ような
コードが吐かれる、C++コード>asmの変換(というかコンパイラ)を自分で作れ。

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

57 :名無しさん:2001/07/28(土) 14:52
fstreamのバイナリ扱いって動作遅くないかい?

58 :名無しさん@Emacs:2001/07/28(土) 15:48
>>33
> STL は C++ の複雑さ(主にメモリ管理)を隠蔽するためにあるので、

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

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

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

59 :デフォルトの名無しさん:2001/07/28(土) 20:54
>>56
いろいろなコンパイラが吐き出すコードを見てきたけど、
仮想関数テーブルの持ち方について見た限りでは
どのコンパイラも同じような実装だった。

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

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

60 :デフォルトの名無しさん:2001/07/28(土) 23:44
>>56 >>59
ありがとうございます。今度暇を見てコンパイラの吐き出すソースを追っかけて
みようと思います。
C++ってどんなふうにコンパイルされているのか、それが分からないことには
理解したとはいえないですよね。

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

62 :デフォルトの名無しさん:2001/07/29(日) 11:00
>>58
>STLの設計は、JavaやC#のcontainerにも強い影響を与えており

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

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

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

63 :デフォルトの名無しさん:2001/07/29(日) 23:05
「VMTにアクセスする変数や関数」があると何が出来ます?

64 :>63:2001/07/29(日) 23:07
リフレクション。

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

65 :厨房:2001/07/29(日) 23:20
VMTってなんですか?

66 :デフォルトの名無しさん:2001/07/29(日) 23:24
仮想関数卓では?

67 :デフォルトの名無しさん:2001/07/30(月) 00:35
リフレクションが有効に使える場面って何があるの?
あと、それはデバッグを困難にせずに使える?

68 :デフォルトの名無しさん:2001/07/30(月) 00:52
virtual method table?

69 :デフォルトの名無しさん:2001/07/30(月) 01:03
>>67

特殊すぎるかもしらんが

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

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

デバッグの方はパス.

70 :デフォルトの名無しさん:2001/07/30(月) 01:18
>>67
・ダイナミックキャスト
・オブジェクトのシリアライズ・永続化
・開発環境との連携(フォームデザイナなど)
・テスタ・デバッガとの連携(TestingFramework, インスペクトなど)
・その他小細工

他にもあるかな?

71 :デフォルトの名無しさん:2001/07/30(月) 01:49
>>64
完璧すぎておつりが山のほうにくるフォロー感謝。
そういう概念を無理矢理一言で言い表したかったんだが、
失敗だったようだ。というわけでフォロー感謝。

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

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

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

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

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

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

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

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

72 :デフォルトの名無しさん:2001/07/30(月) 02:04
リフレクションって元々lispから生まれた概念だから
そっち調べた方が早いと思うけど。

73 :デフォルトの名無しさん:2001/07/30(月) 02:11
>>64
>C++は機能過多な割にこの辺が決定的に弱い。
ここらへんの機能をおもいきってぶち込んじゃえばいいような
後付けしたってそんなに歪な仕様にはならないと思う

74 :デフォルトの名無しさん:2001/07/30(月) 02:40
んー、COMってリフレクション支援に使えるの?
言語オタ以外の視点でのコメントを期待。

75 :デフォルトの名無しさん:2001/07/30(月) 02:42
Javaには、途中からリフレクションと呼ばれる機能が入ったと思うけど、
それを直に叩いてる人っている?
それとも、何かのライブラリがコッソリ使ってるだけ?

76 :デフォルトの名無しさん:2001/07/30(月) 03:03
OpenJava
http://www.hlla.is.tsukuba.ac.jp/~mich/openjava/
CLOS(Common Lisp Object System)の
MOP(Meta Object Protocol)もどき?が入ったJava。
Reflection機能が強化されてるらしい。
類似品にOpenC++とかがあるみたい。

77 :デフォルトの名無しさん:2001/07/30(月) 03:46
>>71
> 型がちがちにしないとデバッグが困難になる、という都市伝説は
> せいぜい3割くらいしか当たってないと思われ。

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

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

78 :デフォルトの名無しさん:2001/07/30(月) 03:56
>>74
期待age

79 :>77:2001/07/30(月) 08:43
裏付けないデータならあるよ

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

80 :デフォルトの名無しさん:2001/07/30(月) 12:44
>>74
使えるよ。ITypeLib とか IDispatch(Ex) なんかがその辺のサポートを
している。

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

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

82 :デフォルトの名無しさん:2001/07/30(月) 13:29
>>81
Delphi,C++Builderで思いっきり使ってんだけど。
これが無ければ窓一枚まともに出せないよ。

83 :名無しさん@Emacs:2001/07/30(月) 15:13
> リフレクションが有効に使える場面って何があるの?

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

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

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

84 :デフォルトの名無しさん:2001/07/30(月) 19:08
C/C++しか使えないヤツらが鬱陶しいと思うのは俺だけか?

85 :質問君:2001/07/30(月) 19:29
>>84
そいつらがどういう概念を理解すれば鬱陶しくなくなるんだい?

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

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

87 :デフォルトの名無しさん:2001/07/30(月) 21:11
>>86
URLの最後の'l'が抜けているよ。

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

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

89 :デフォルトの名無しさん:2001/07/30(月) 22:02
DelphiでもRTTI情報を含めるかどうかコンパイラスイッチで
指定するしね。TPersistentの実装をみてちょ。

90 :デフォルトの名無しさん:2001/07/30(月) 22:11
>>88
既にそうなってるんじゃない? >C++

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

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

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

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

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

92 :デフォルトの名無しさん:2001/07/30(月) 23:37
>>91
OOP云々は下手に持ち出すと言語オタが押し寄せてくるのでやめたほうがいい
sage

93 :89:2001/07/31(火) 00:20
>>91
あ、RTTIにケチを付けるつもりは全くありません。

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

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

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

95 :デフォルトの名無しさん:2001/07/31(火) 03:13
C++のclassの仮想関数テーブルってvirtualなメソッドを持っているときに自動的に付けられるよね。
自動的に付かないというのはどういう意味?
まぁデフォルトでvirtualになってもいいとは思うけど、
まだPCの速度が遅く、OOが理解されていなかった時代に、
virtualをデフォルトにしたら、それこそ今以上に非難されていただろう。

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

96 :83:2001/07/31(火) 03:25
>>88,>>91 今のC++の話してるんだよね?
VMTなんて必要なければはなっから作らないよ。

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

97 :デフォルトの名無しさん:2001/07/31(火) 07:20
みなさん、すごいですね。感心します。
昨日や今日C++やり始めたなんて感じじゃなさそうですが、
もうどれくらいやっているのでしょうか?

98 :デフォルトの名無しさん:2001/07/31(火) 16:08
俺5年

99 :デフォルトの名無しさん:2001/07/31(火) 16:32
>>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でもいいから是非欲しい。

100 :95:2001/07/31(火) 22:37
>>99
>性能や安定性(やメンテ性)を求めた結果がアレか?という…

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

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

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

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

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

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

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

101 :デフォルトの名無しさん:2001/08/01(水) 01:56
>WindowsNT系OSの安定性は驚異的

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

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

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

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

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

102 :デフォルトの名無しさん:2001/08/01(水) 02:40
よむだけで、ほかのスレより3倍くらい疲れるスレッドだな

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

103 :デフォルトの名無しさん:2001/08/01(水) 04:57
WindowsはCとC++を適材適所でつかっておる。なかなか良い。
GNOMEはC++を使うべきところまでCで書いておる。これからも安定せんかもね。

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

104 :デフォルトの名無しさん:2001/08/01(水) 05:18
でもKDE無くなりそうだね

105 :デフォルトの名無しさん:2001/08/01(水) 09:36
>>104
why?

106 :デフォルトの名無しさん:2001/08/01(水) 13:01
>>WindowsNT系OSの安定性は驚異的
>驚異的というのも言いすぎでわ…。

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

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

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

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

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

108 :突如乱入者:2001/08/01(水) 14:24
>>106
> サポートしなけりゃならないハードウェア/ソフトウェアの数を考える
> と驚異的だと思いますよ。

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

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

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

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

109 :106:2001/08/01(水) 15:49
>WinXPでカーネル統一するから無理。

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

110 :デフォルトの名無しさん:2001/08/01(水) 18:40
>>107
>それどころか今度はIISがカーネルにぶち込まれるらしいよ(藁
Linuxでは既に(機能限定)HTTPDがカーネルに入ってます。

111 :デフォルトの名無しさん:2001/08/01(水) 21:06
NT3.51以前のOSでグラフィックドライバがコケるとどうなるの?
カーネルは生きてて画面が出ないだけ?

112 :デフォルトの名無しさん:2001/08/01(水) 22:22
C++に関係なくなってきたな

113 :デフォルトの名無しさん:2001/08/01(水) 22:25
>> サポートしなけりゃならないハードウェア/ソフトウェアの数を考える
>> と驚異的だと思いますよ。
>
>では、Windows, *BSD, Linuxは全て驚異的、ということで。

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

114 :デフォルトの名無しさん:2001/08/01(水) 22:40
>>Windowsと比べたら数えるほどしかないと思うが
思ってるのは言いが、堂々と人に言わないようにね。

115 :デフォルトの名無しさん:2001/08/01(水) 22:57
>>113

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

116 :デフォルトの名無しさん:2001/08/01(水) 23:30
Windows のドライバはサードパーティが作ってんだぞ。
動かなきゃ商売にならんのだからハードメーカが対応してんだ。
アホか。

117 :デフォルトの名無しさん:2001/08/01(水) 23:38
Windowsの方がサポートされているハードウェアが多いのは当然だ。
そこを指摘してるわけじゃないだろ?阿呆。

118 :デフォルトの名無しさん:2001/08/01(水) 23:39
OSネタはもういいので、C++の話をして下さい。このスレのファンの一人として。
もしくはハードウェアを抽象化させるためにC++をどのように用いたらよいのか?
なぁーんて話でもいいです。勝ってすみません

119 :117:2001/08/01(水) 23:41
了解。ごめん。

120 :デフォルトの名無しさん:2001/08/02(木) 00:11
C++よりMFCやめたい

121 :デフォルトの名無しさん:2001/08/02(木) 00:22
「C++でOS」に話を戻すと、
一番の問題はMOPとまではいかなくてもclass objectがないから、
「これはscsi_disk interfaceを継承したclassだから」
というlogicを別に作らなければいけないこと。

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

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

122 :デフォルトの名無しさん:2001/08/02(木) 00:27
MOP とか FCOって何?

123 :デフォルトの名無しさん:2001/08/02(木) 00:52
>>122
ここ参照
http://homepage2.nifty.com/rohizuka/pa/pa_003_a.htm

124 :デフォルトの名無しさん:2001/08/02(木) 01:01
>>123
なんかへんな音してきたんですけど・・・

125 :122:2001/08/02(木) 01:02
>>123
そこ、見たことあるヨ。

126 :デフォルトの名無しさん:2001/08/02(木) 01:07
>>125
グロですか?心霊ですか?

127 :デフォルトの名無しさん:2001/08/02(木) 01:22
普通のページ>126

128 :デフォルトの名無しさん:2001/08/02(木) 01:39
FCO (first class object)
ttp://java-house.etl.go.jp/ml/archive/j-h-b/001927.html

適当にgoogleしただけ。

129 :デフォルトの名無しさん:2001/08/02(木) 02:18
>>123
マ板に帰れ。ウザイ。

130 :デフォルトの名無しさん:2001/08/02(木) 02:32
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;
};
を持つってことでどうでしょうか。
(もはや、何言語だかわからん)

131 :デフォルトの名無しさん:2001/08/02(木) 07:10
アホだぁな

132 :デフォルトの名無しさん:2001/08/02(木) 22:08
>(もはや、何言語だかわからん)

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

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

133 : ほんと?:2001/08/03(金) 21:33
ttp://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html

ちょっとしょっく。

134 :デフォルトの名無しさん:2001/08/03(金) 21:48
>>133

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

135 :デフォルトの名無しさん:2001/08/03(金) 22:10
言語拡張したけりゃlispでも使えや

136 :ほんと?:2001/08/03(金) 22:14
ネタか。まじだとおもったyo

137 :デフォルトの名無しさん:2001/08/03(金) 22:17
まじにとるやつもいるだろうね

138 :すみません:2001/08/03(金) 22:22
C++やりだしたら、Cは忘れてしまうものですか?
C++にできない、Cならではの技ってあるのですか?

139 :デフォルトの名無しさん:2001/08/03(金) 22:26
>>138
そもそもCを知っているのか?

140 :デフォルトの名無しさん:2001/08/03(金) 22:27
>>138
中1で方程式を習うと鶴亀算を使いたくなくなるような感じと思われ。

141 :デフォルトの名無しさん:2001/08/03(金) 22:55
>>133
俺はマジに取ってるけどな、言ってること間違ってないし

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

143 :デフォルトの名無しさん:2001/08/03(金) 23:07
Cの良技、荒技、神技はC++に取っての水爆である。
それはC++にはC++の使い方がある為であって
決してCの技が劣っているわけではない。

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

144 :140:2001/08/03(金) 23:46
>>142
じゃぁとりあえずこだわり抜いてみれ。
ただ、Cの言語仕様で完全に満足してしまったら、そこから先には進めないと思うから注意だ。

#俺がCを極めているかは謎だが(藁

145 :デフォルトの名無しさん:2001/08/04(土) 02:43
Cだけやってもだめだよね。汗やらないとほんとに分かったことにはならない。
C++もそうなのでは?この手の言語ってどうしてもコンパイラの仕様から離れられない。

146 :デフォルトの名無しさん:2001/08/04(土) 19:47
>>144
CをC++に置き換えて読むと面白い。
C++で満足したら先に進めない。ナイスな真理だ。

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

147 :デフォルトの名無しさん:2001/08/04(土) 19:49
>>144
CをJavaに置き換えて読むと面白い。
Javaで満足したら先に進めない。ナイスな真理だ。

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

148 :turbo type D:2001/08/04(土) 20:05
>>133のサイト
超ガイシュツ有名ページだが
ネタかマジかどちらなのか
はっきりさせている情報にはめぐり合ったことがない。

149 :140:2001/08/04(土) 21:05
>>146
まったくそのとおりだと思うよ。>>86 さんのURL参照ってことですな。

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

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

151 :turbo type D:2001/08/05(日) 18:12
>>149
英語かんべんしてよ。読むの疲れるし...
Excite翻訳しても、意味わからないなあ。参った参った。

152 :デフォルトの名無しさん:2001/08/05(日) 21:00
GT3はC++で書かれているってホント?

153 :デフォルトの名無しさん:2001/08/05(日) 22:48
>>151
本人があの記事は嘘だと言っているだけ。
数行の文ですが本当にわかんないの?ネタor何らかの意図でわからないと言っているのか?

154 :デフォルトの名無しさん:2001/08/05(日) 22:54
>C++もそうなのでは?この手の言語ってどうしてもコンパイラの仕様から離れられない
例が思いうかばないのですが、たとえばどういう感じですか?>145

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

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

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

156 :デフォルトの名無しさん:2001/08/06(月) 13:33
MOPの話をしていた皆さんの再登場期待age

157 :デフォルトの名無しさん:2001/08/06(月) 13:49
>>135
CLOS is cool !

158 :デフォルトの名無しさん:2001/08/06(月) 17:45
C++がこの先どんどんでかくなるならいっそのことLispの方がまだ分かりやすいと
思うのは気のせいかしら。。

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

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

161 :デフォルトの名無しさん:2001/08/07(火) 01:33
いつになったら独習C++レベルを抜け出せることやら・・・

162 :デフォルトの名無しさん:2001/08/09(木) 05:01
>>162
>たった1つの巨大な関数へまとめたりもできる。
まあ展開だけなら簡単だよね。lispとかの場合。

163 :デフォルトの名無しさん:2001/08/14(火) 06:21
C++の最新の仕様はどこで手に入りますか?

164 :デフォルトの名無しさん:2001/08/14(火) 06:40
C++の最新の仕様
で検索すれば

165 :デフォルトの名無しさん:2001/08/14(火) 08:14
>>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)

166 :デフォルトの名無しさん:2001/08/14(火) 08:30
ありがとう。>>165
これって標準になったやつだよね?
これが最新だとすると次のドラフト案なんてものはまだまだ
出てないってことかな?

167 :デフォルトの名無しさん:2001/08/14(火) 17:19
>>166
ドラフト以前の情報を、
http://anubis.dkuug.dk/jtc1/sc22/wg21/で読むしかないと思うよん。

168 :デフォルトの名無しさん:2001/08/16(木) 08:46
C++やめました。

169 :デフォルトの名無しさん:2001/08/16(木) 09:45
>>168
おめでとう。

170 :デフォルトの名無しさん:2001/08/16(木) 15:34
童貞捨てました

171 :デフォルトの名無しさん:2001/08/16(木) 20:14
>>170
おめでとう。

172 :デフォルトの名無しさん:2001/08/17(金) 03:59
>>170
おめでとさん。

173 :C++をやめたら:2001/08/18(土) 23:42
次はどこへゆくのですか。

174 :デフォルトの名無しさん:2001/08/19(日) 00:05
もちろんCLRです

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

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)