Ｃ++について言いたいことがあればどうぞ +++

1 ：仕様書無しさん：02/09/03 00:12

C++に関係した話題なら何でもOK。
ﾏﾀｰﾘ逝くです　　"ヽ(´▽｀)ノ"

前スレ
http://pc.2ch.net/test/read.cgi/prog/1017746969/

前々スレ
http://pc.2ch.net/prog/kako/1014/10146/1014654569.html

2 ：仕様書無しさん：02/09/03 00:12

技術的なことはム板へどうぞ。

C++相談室 part10 http://pc3.2ch.net/test/read.cgi/tech/1029315669/

3 ：仕様書無しさん：02/09/03 00:14

>>1
乙

4 ：仕様書無しさん：02/09/03 00:14

スレ建て成功。
では、マターリ逝きましょう。

5 ：仕様書無しさん：02/09/03 00:16

C++ -> supreme language

6 ：仕様書無しさん：02/09/03 00:17

>>1
サンクス & 乙カレー

7 ：仕様書無しさん：02/09/03 00:17

C++を理解しようとしない奴らにC++のすばらしさを教えてしまうのは癪だが、
こういうスレがあるとうれしい。

8 ：仕様書無しさん：02/09/03 00:21

で、delegateとpropertyとrefrectionはいつ実装されるんですか？

9 ：仕様書無しさん：02/09/03 00:26

ストラウストラップの髪がフサフサになった時。

10 ：仕様書無しさん：02/09/03 00:27

今>>9がとんでもないことをいったぞ（ｗ

11 ：びひゃーん：02/09/03 00:29

>>9
迷惑です。

12 ：仕様書無しさん：02/09/03 00:44

C++もう７年やってないけどまだあるのか？

13 ：びひゃーん：02/09/03 00:47

>>12
0点

14 ：びひゃーん：02/09/03 00:57

おれはJavaもDelphiもC#も大好きだ。特にC#にはわくわくしている。C++は好きって
訳ではないが、いちばん手に馴染んでる。C++のコードを書いてるときの自分は自信に
溢れてるような気がする。まだまだ勉強すべきことは山積みだが、ここ一番ってときは
迷わずC++を選択する。

15 ：仕様書無しさん：02/09/03 00:59

非力な構文を持つ言語はクラス・ライブラリが爆発的に増えてしまい、
プログラマはその習得に一生を費やすことになる。

16 ：びひゃーん：02/09/03 01:03

良く設計されたクラスに出会うと、勉強の苦労を忘れる。

17 ：仕様書無しさん：02/09/03 01:05

だったらC#使いなよ
洗練の度合いが違う

18 ：びひゃーん：02/09/03 01:14

>>17
うん、C#も大好き。やっぱり新しい言語は増築の跡が無いから綺麗。ただ、ランタイム
が必要ってのが．．．

19 ：仕様書無しさん：02/09/03 01:26

C# の delegate って全然知らなかったので、
http://www.atmarkit.co.jp/fdotnet/csharp_abc/csharp_abc_017/csharp_abc01.html
をちろっと見ただけなんだけど、 C++ でも同じことは
template と関数オブジェクトを使えばできる気がした。
あと、reflection はいらんけど、property は欲しいね。

20 ：仕様書無しさん：02/09/03 01:29

property も、代理クラス使えば実装できるんだけどね。
ただ面倒なのと、余分なコストかけてまで頑にメンバ関数を避ける必要も
ないんじゃないかなぁ。

21 ：仕様書無しさん：02/09/03 01:42

>>18
ランタイムなんてプログラムの実行環境と考えれば
プログラムを実行するにはＯＳが必要なのと対して変わらないよ。

22 ：仕様書無しさん：02/09/03 01:57

>>19-20
やっと関数オブジェクトの名前が出てきたか。
それを出さないでdelegateはいらないって言っているやつは馬鹿だね。

C#はC++と違って無理やり拡張して作られたわけじゃないから
templateを使わないと実装できなかったものが言語仕様に取り入れられてる。
言語仕様が洗練されているのがわかるだろ。
同じ物を書き比べてみるとさらにはっきりするだろう。

もっとも単純なものを複雑にするのが好きな奴は洗練されてるのが嫌いなんだろうけど。

23 ：仕様書無しさん：02/09/03 02:05

C++は
if文で代入できるからバグになりやすい。
switchでbreakを書き忘れてバグになりやすい。
だから嫌い。

24 ：仕様書無しさん：02/09/03 02:13

>>21
ランタイムが載ったパソコンが普及することを切に希望する。

25 ：仕様書無しさん：02/09/03 02:16

Cﾌﾟﾗﾗｰって痛い奴ばっかりだな

26 ：仕様書無しさん：02/09/03 02:16

C++は簡単なミスでバッファオーバーランしやすいから嫌い。

27 ：仕様書無しさん：02/09/03 02:17

>>24
近い将来簡単に実現しそうだよね。

28 ：仕様書無しさん：02/09/03 02:20

C++は簡単なミスでメモリリークしやすいから嫌い。

29 ：仕様書無しさん：02/09/03 02:26

>>23-28
早くC++を使わずにすむ世界が来るといいですね。

30 ：仕様書無しさん：02/09/03 02:28

ぶびちうがC#を手にしてはしゃいでいるだけ。

31 ：仕様書無しさん：02/09/03 07:03

>>29-30
反論していないってことは、どうやら図星なようだ。
事実なのだから仕方ないとはいえ、レスに悔しさがにじみ出てるぞ。

32 ：仕様書無しさん：02/09/03 07:15

若干一名がプロパティプロパティって騒いでC#の宣伝してるんだね。
ム板のドットネット宣伝要員は最近恥ずかしくて出てこれなくなった
みたいだから、社員というより、厨房なんだろうけど。

C#なってVBと一緒でWinでしか使えないだろ。（藁
そんなの言語ですらない。消えなさい。

33 ：仕様書無しさん：02/09/03 07:34

>>32
恥ずかしいやつだなぁ。そんなこと考えてるのはお前だけだよ(藁

34 ：仕様書無しさん：02/09/03 08:00

>>32
言語で反論できなくなったから今度は普及率で反論かい？
良い物を認められなくなってしまったらおしまいだね。
もし同じ機能がC++に取り入れられたら掌を返したように喜ぶんだろうね。

> C#なってVBと一緒でWinでしか使えないだろ。（藁
> そんなの言語ですらない。消えなさい。
大藁
C#は見事言語と認定されたわけだ。
C++は消えなくていいけど、お前は消えなさい。

35 ：仕様書無しさん：02/09/03 09:57

C#で開発したソフトが走る環境が、ビジネスとして成り立つレベルまで普及してから
ゆっくり取り組むことにするよ。C#の習得は簡単だから、それからでも遅くは無い。

36 ：仕様書無しさん：02/09/03 10:05

>>32
.NET Framework の意味わかってますくぁ？（ｗ

37 ：仕様書無しさん：02/09/03 10:07

ビジネスうんぬんはおいといて言語自体を比較した場合
C#の方が総合的にすぐれてるってことか。

38 ：仕様書無しさん：02/09/03 10:10

>>35
C#の習得が簡単なのは機能が少ないからではなく
すっきりしていてわかりやすいと言う利点でもある。

39 ：仕様書無しさん：02/09/03 10:29

むかし、C++マンセーな人のすすめで、独学で勉強しようと本を買ってきて
読んでみた。
なんかめちゃくちゃ分厚い本で、最初は言語の基本仕様、それから
ライブラリの解説、VC++の操作や機能の使い方、というような感じの
本だった。
それを見て真っ先に思ったのは
「○○を実現したい、というときに何をすればいいか、を知るまでがたいへん
すぎるな、これは」ということだった。
というのも、VBの本なら目次で「○○を作る」という項目を見てそこに
行けば、あとは基本項目をちょいちょい参照するくらいで何とかなるんだね、
これが。

で、「こりゃやっかいだ」と思ってたところにC#登場。で、興味を持ってその本を
読んでみたら、上記の違いでいえばVB寄り（＝わかりやすい）なんだね。
「あ、こりゃいいや」と思ったよ。
解説本の厚さもVC++のと比べたら半分以下だった。

40 ： ◆4COMPILE ：02/09/03 10:59

>>37
確かに、『言語自体』で見たら、C#は比較的優れた言語だと思う。
（少なくともJavaよりは）
ちょっと勉強しとく。

だけどねぇ、テンプレートを使い出すとC++以外やる気起きんよ。

>「○○を作る」という項目を見てそこに行けば、
このアプローチでちゃんとしたものを作れるものを解説しようとしたら
(どんな言語でも)VC++の本の厚さどころのさわぎではなくなる。
まぁプログラムになれるまではそれでいいけど。

逆にいうとわかってるべきものがわかってなくても
望む機能が実現できてしまうのは危険だし。

んで、それってVCの本でしょ。ってことは半分以上は（多分）MFCのことで
（言語てしての）C++とは関係ないよ。
VBはどこまで言語なのかどこまでライブラリなのかよーわからんけど、
C++もC#も言語とライブラリは明確に区別されとるよ。
（Javaはアレも言語に含まれるとかSunはゆーとったけど。）

41 ： ◆4COMPILE ：02/09/03 11:00

すまぬ。後半 >>39

42 ：夏厨＠残党：02/09/03 11:01

いっちょうオレの人生をMSにかけてみるか。

43 ：仕様書無しさん：02/09/03 11:22

>>40
まぁテンプレートが好きなら仕方ない。C#にはないからな。
もっともテンプレート(というかGenerics)はC#でも将来実装されそうだから
そのときになったら、それでもC++を使うか自問してくれ。

Generics for C# and .NET CLR
http://research.microsoft.com/projects/clrgen/

44 ：39：02/09/03 11:45

>>40
> 逆にいうとわかってるべきものがわかってなくても
> 望む機能が実現できてしまうのは危険だし。

いや、そうじゃないんだよ。
C#とかVBとかどの程度知ってるかわからないけど、
「わかるべきものが簡単にわかるようになってる」って
ことを言ってるわけ。

いや、もちろん、内部的にメモリがどうなってレジスタが
どうなって、というところまで理解してなきゃダメだよ、って
言うなら別だけど。それはそれで「ちゃんと希望するものが
組める」ようになってからでも遅くはないわけでしょ。
つまり、段階的に、ステップアップ方式で学んでいけるのか、
いきなり最初から聖書や電話帳みたいなものを読みこなさないと
何も作れないのか、という違いなんだよ。

> んで、それってVCの本でしょ。ってことは半分以上は（多分）MFCのことで
> （言語てしての）C++とは関係ないよ。

それはわかってる。
だから、「望むものを作るにはどうしたらいいか」ってとき、純粋な
C++の言語部分の知識だけではできないでしょ。少なくともWindows
向けのGUIアプリを作るとき。
だから上記のように「いったん全部見ないと先に進めない」ってことに
なりがちだな、と思ったわけ。

少なくともVBやC#ではそういうことはないよ。

45 ：C++使い：02/09/03 14:02

ﾊﾞｶﾊﾞｯｶ。

46 ：仕様書無しさん：02/09/03 14:19

>>45
C++厨の間違いだろ

47 ：仕様書無しさん：02/09/03 14:31

>>32である。
結構反響があったじゃねーか。１人でレス書いたのか。（ﾌﾟ
おまえ（ら）、C#スレたてろや。
冷たく無視しててやるから。

ちなみに、C#はVBと一緒で、Win以外では使えんだろ。
来年の今頃には、J++と同じ運命だよ。
ははは。

48 ：仕様書無しさん：02/09/03 14:35

C#宣伝したいなら、こんなとここないで、こっちをなんとかしろ。
惨憺たる状況じゃんか。

.NET大ブーム４
http://pc3.2ch.net/test/read.cgi/tech/1029336048/

49 ：仕様書無しさん：02/09/03 14:43

>少なくともVBやC#ではそういうことはないよ。
まあ、ブビ厨あがりが、オブジェクト指向できそうなんで舞い上がってる、に1評。

50 ：仕様書無しさん：02/09/03 14:45

>>37
>ビジネスうんぬんはおいといて
一番重要なものをおいとくなよ(W

51 ：仕様書無しさん：02/09/03 14:50

>ビジネスうんぬんはおいといて
なんだ、敗北宣言してたんですね。

52 ：仕様書無しさん：02/09/03 14:58

>>50-51
ビジネスで見たらVBの圧勝ですが何か？

53 ：仕様書無しさん：02/09/03 14:59

あとCOBOLか。

54 ： ◆4COMPILE ：02/09/03 15:01

>>44
なるほどね。まあ一理あるといえばあるかな。
C++は入門向けでないといえば入門向けでないし。

でも、VBってちょっと本読んだりはしてるけど、
いまだにあの勝手にできる "Form1" ってのが何者なのかよくわからないんだけど、
これはVBでは知らなくていいことなの？

知らないでやっていっていいことじゃないと思うんだけど、
どこにもわかりやすく書いてないよ？
VB.netではどうなってんの？

C++はコンソールアプリでmainから書いていって、
必要なところから（あるいは便利なところから）C++流儀にしていけば
ちゃんと段階的に、かつ必要なことを確実に理解していけるはずだけど、
GUIがなきゃだめだ、っていうのならC++は
>「いったん全部見ないと先に進めない」ってことになりがち
だね。確かに。

55 ：仕様書無しさん：02/09/03 15:04

>>54
> いまだにあの勝手にできる "Form1" ってのが何者なのかよくわからないんだけど、
RAD系の開発ツールなら大抵フォームができますけどなにか？
C++ BuilderとかDelphiとか。

56 ：仕様書無しさん：02/09/03 15:05

>>52
ソースは？

57 ：仕様書無しさん：02/09/03 15:08

C++はもともとが悪い。
C++自体が悪いんじゃない。
ストラウストリャープ先生は頑張ったんだぞ！なめんなよ！

58 ：仕様書無しさん：02/09/03 15:11

>>52
声がかぼそく震えてるよ。

59 ：びひゃ～ん：02/09/03 15:11

なめんなよ！

60 ：仕様書無しさん：02/09/03 15:17

>>47
>>36

61 ：仕様書無しさん：02/09/03 15:19

>>54
> いまだにあの勝手にできる "Form1" ってのが何者なのか
> よくわからないんだけど、
一種のテンプレートだよ。
設定で起動時の構成は好みに変更できるよ。

まあ、VBでまったくフォームを使わないアプリ作るやつは珍しい
だろうから、デフォルトで入ってるほうが便利だけど。

62 ：仕様書無しさん：02/09/03 15:20

>>56
Google検索結果

開発実績と
VB859
COBOL538
Visual Basic401
C++450

業務内容と
VB2,480
COBOL1,390
Visual Basic753
C++819

63 ：仕様書無しさん：02/09/03 15:21

>>60
だからあ。ドトネトはウィソでしか使えませんて。

わかった？

64 ：仕様書無しさん：02/09/03 15:23

>>58
ワラタヨ。

65 ： ◆4COMPILE ：02/09/03 15:25

いや、デフォルトで入ってること自体は問題ないのよ、
その
>一種のテンプレートだよ。
の「一種のテンプレート」って具体的に何？
どうやってできて、だれがどうやって表示してるの？
わからないの気持ち悪いんだけど。

Delphiとかは知らんけど、たとえばVC#なら
System.Windows.Forms.Formの派生クラスのインスタンスで
アプリケーションはそのクラスメソッドmainから始まって、
Application.Runにフォームのインスタンスを渡して、そこで表示される。
ってわかるじゃんよ。だからC#は嫌いじゃないんだけど。

66 ：仕様書無しさん：02/09/03 15:31

>>65
クラスメソッドmainは誰が呼んでるの？

67 ： ◆4COMPILE ：02/09/03 15:37

>>66
それは言語仕様。あんまりきれいじゃないとは思うけどしょうがないと思う。
C/C++のmainも同じ、しょうがない。けど、そういうもんだと納得はいく。

じゃあVBのForm1もしょうがないだろ、そう決まってんだよ。
っていわれればそれまでだけど、
なんかform1のLoadより前に走るコードとかもあるじゃん。
そこらへんが納得いくようになってないのが気持ち悪い。
VBではそんなこと知らんでもいいってことなんだろうけど。

68 ：仕様書無しさん：02/09/03 15:44

>>65
なんか言いたいことがよくわからんが。

FormはFormオブジェクトだよ。
んで、VBでコンパイルした実行可能ファイルって基本的には
MSVBVM60.dllからエクスポートされてる関数なりオブジェクトを
使って動かすわけでしょ。
コントロールは別個にOCX使ったりするけど。
それがわかんないってこと？

それともスタートアップがどうなってんだ、って話？
結局VBの環境がユーザの設定に応じて自動的にExeのコードを
吐いてるわけで、それはユーザが明確にコードとして書いてコンパイラ
に渡すわけじゃないけど、やってることは最終的には同じことだよ。
コンパイラにコンパイラオプション渡したりとか、そういうのと同じ感じ。
Form1からスタートもできるし、Main関数からでもできる。
Form1からスタートってことは暗黙的なMain関数の先頭でForm
オブジェクトを呼び出してるんでしょ。
別にわからないことはないけどなぁ？？

69 ：仕様書無しさん：02/09/03 15:46

>>63
いまのところはね。ﾌﾟ

70 ：仕様書無しさん：02/09/03 15:49

>>65
ていうかそこまでわからないとダメってのは
単なる個人的なこだわりじゃないかと。
「気持ち悪い」って書いてるからたぶんそうなんだろうけど。

その方向だと結局マシン語直接書けみたいな話にならんか？
高級言語の存在価値ってなによ？ってことに。

あくまで仕事上で効率よく開発したいな、っていうときに
そこまでわかってないからイヤだ、ってのは（そういう嗜好も
理解はするけど）的外れじゃないかな、と思うが。

71 ：仕様書無しさん：02/09/03 15:58

>>69
予定は未定
# Windows .NET Serverだって遅れてるし

72 ：仕様書無しさん：02/09/03 16:01

>>67
ただ単にVBをよく分かってないだけだろ。

Form1のLoadの前に走るコードって具体的に何をさしてるんだ。
それはともかく、VBもデフォルトじゃないが設定を変えればMainから始めることはできる。
設定と言う言葉が気持ち悪いならコンパイルオプションとでも言えば納得するだろう。

VBのややこしい点の一つがForm1はクラス名でありインスタンス名でもあるということ。
Dim Form1 As New Form1という宣言が見えないところにあると思えばいい。

Mainから始めた場合はそこからForm1クラスのインスタンスでも生成して表示すればいい。
このMainがForm1_Loadより前に走るコードの一つだろう。

それとは別にMainを使わず直接設定してあるフォームを表示する方法もある。(デフォルト)
そういうことができる言語仕様だからね。この方法ではVBが勝手に表示してくれる。

VBの終了条件はすべてのフォームがアンロードされコードが実行されてないとき。
そしてロードされるときに発生するイベントがLoadイベント。
Form1はクラスなのでその前に発生するイベントとしてInitializeがある。
これはC++のコンストラクタのようなもの。

長々と(手抜きして)書いたが根本的なことを理解すれば難しいことはない。
これらはMSDNライブラリを読めばわかる。もっとも初心者が簡単に
理解できるものではないだろうが。

73 ：仕様書無しさん：02/09/03 17:35

ことほど左様にVBは美しくないってことだな。

74 ：仕様書無しさん：02/09/03 18:10

>>73
使いやすさ、学びやすさも美しさのうち、とは考えないのね。

言語ｦﾀの美学ってｷﾋﾞｼｲのねぇ。

75 ：75：02/09/03 18:23

>>74

あの気色悪いシンタックスのどこが美しいんだよ。
お前、目が悪いだろ。

76 ：仕様書無しさん：02/09/03 18:30

>>75
日本語のご不自由な方ですか？

> 使いやすさ、学びやすさも美しさのうち

シンタックスがどうのこうのとか、書いてありますか？

77 ：仕様書無しさん：02/09/03 18:32

なんか一般人には簡単に操作できないような戦車を乗り回して
「戦車サイコー！」とか言ってるような感じだな、C++厨って。
んで、車体をさすりながら「ああ、おまえは何て美しいんだ（ｳｯﾄﾘ）」
って恍惚の表情か。

ｦﾀ極まれり、だな。（ｗ

78 ：仕様書無しさん：02/09/03 18:43

>>77
＞なんか一般人には簡単に操作できないような戦車を乗り回して
C++なんて一般的（職業としてやってる）なPGなら操作できるだろ。
操作できないのは一般のレベルに達してないｶｽPG。
つか、言語なんかどうでもいいだろ。
作るものや動作環境等に合わせて適切な言語を選べばいいだけと思うが
コーダーにとっては死活問題なのか？

79 ：仕様書無しさん：02/09/03 19:37

> つか、言語なんかどうでもいいだろ。
> 作るものや動作環境等に合わせて適切な言語を選べばいいだけと思うが
その通り。それで選ぶと業界にもよるがC++になることって結構少ないんだよな。

80 ：仕様書無しさん：02/09/03 19:40

>>74
> 使いやすさ、学びやすさも美しさのうち、とは考えないのね。

排卵。

81 ： ◆4COMPILE ：02/09/03 19:47

>>68
はじめて納得した。ありがとう。
Formからスタートアップとしたときは暗黙のMainができて
そこで生成されるようなものってことね。
･･･納得はした。気にくわないが。

>>70
まぁそう。個人的に気にくわないだけ。
バランスの問題かも。
C#みたいなのはいいかな、とか。

>>72
すまん。難しいといっているんじゃないんだ。
なんでそういうことを何の説明もなく行うんだ、
それらは理解しておくべきことじゃないのか、ってこと。

MSDNライブラリは軽く見たかんじだと、
プロパティにアクセスがあったときに暗黙にロードされる
ぐらいしか書いてないんで。

82 ： ◆4COMPILE ：02/09/03 19:52

>>77 >>78

だいたい >>78 に同意だけど、
テンプレート使ってコンパイル時にいろいろやるのは
まさに >>77 みたいな感じ、自分でも思う。
そういうことがもっとスマートにできる言語はほしいけど、
今のところそこらへんではC++しか選択肢がない。

83 ：72：02/09/03 20:27

>>81
何の説明もなく行うというのが良く分からんな。

MSDNにはちゃんと書いてある。俺自身VBは嫌いな方で本など買わずほとんどMSDNで学んだ。
たとえば、「Visual Basic フォームの有効期間」という項目では次のようなこと説明してある。
> Visual Basic フォームの状態の推移
> Visual Basic のフォームは、その有効期間中、通常 4 つの状態を通過します。
> 1. 作成されているが、ロードされていない。
> 2. ロードされているが、表示されていない。
> 3. 表示されている。
> 4. メモリおよびシステムリソースが完全に解放されている。
～～～～～以下説明が続く～～～～～

また「フォームに関するその他の詳細」には
スタートアップフォーム(起動して最初に開くフォーム)についての説明。
Mainからのスタート方法。アプリケーション終了の条件
などの説明がある。

もちろん他の説明もある。ただ見つけにくいというのはあるかもしれん。
「それらは理解しておくべきことじゃないのか」というが、
理解しておくべきだと思うなら調べるだろうし、そう思わないなら調べない。
これはVBとは関係なく、純粋にプログラマの意思で決まるものだと思うが。
何の説明もなく行う(というか説明も読まず)のはプログラマじゃないのか。
「何の説明もなく行う」じゃない場合とはどういうことなのか？

それはともかくVBに限らずGUIに関する部分（MFCやVCL）が行う内容を
完全に理解するのは結構時間がかかると思う。
最初はとりあえず表示してみて徐々に仕組みを理解していくものだと思うが。

(つーか、スレと全然関係ないし・・・)

84 ：仕様書無しさん：02/09/03 20:44

77は、C++が理解できなかった三流高卒PG。

85 ：72：02/09/03 20:46

>> ◆4COMPILE
ここまでの内容から勝手にVBが気に食わない点を推測するが、

１．プログラムは必ず存在するmain(かそれに代わるもの)から起動し
何もしないのにいきなりフォームが開くのが気持ち悪い。(固定観念？)

２．GUIの管理＆その他がどうなっているか知りたいときに
ソースコードを見ることができずヘルプを読むしかない。
ソースコードが見れないから何の説明もなく行うと思ってしまう。

この二点ではないか？

86 ： ◆4COMPILE ：02/09/03 22:45

すまぬ、(スレに関係ないことに)熱くなりすぎた。

>>85
OK. まさにそう。
固定観念といえば固定観念。
あと、これらの仕様がいちいち(私的)美学に反する、というのもある。

87 ：仕様書無しさん：02/09/03 22:55

84は、VBでさえ理解できなかった小学生。

88 ：仕様書無しさん：02/09/03 23:17

87は小学生相手に「俺はVBできるんだぜ」と自慢するバカ。

89 ：仕様書無しさん：02/09/03 23:27

VBの気持ちわるいところ。

72が推測する「気に食わない点」って素人みたいだな。

C/C++は、「プログラミング言語 C」「プログラミング言語 C++」を
見れば巻末に構文ルールがBNFで書かれてるから、少なくとも
シンタックスレベルでの仕様というのは一目瞭然、まあ、一目
では難しいにしても何が正しくて何が正しくないのかはわかる。

だけど、VBの構文ルールってBNFでなくても厳格に記述したものってあるか？
あったとしてもそれはMS社内のファイルサーバーに眠ってるVBのパーサの
ソースが、唯一の存在だったりしてね。

たとえば、伝統的なBASICとの互換なんだろうけど、lineメソッドの
あのBとかFってのは一体なんだ？定数でもない、変数でもない、言語の
構成要素としては何者でもない、あんな例外的なものを何も疑問もなく
受け入れられるなんて信じられない。
そして、MSDNライブラリには今でも間違って書かれてるかもしれない
けど、(x1,y1)-(x2,y2)の‘-' も変だ。
きっとVBのパーサーには、これらのクソ例外的な分岐が書かれてるんだろうな。

90 ：仕様書無しさん：02/09/03 23:28

あと、フォームはロードしなくてもいきなりFrom1.Show なんて書ける
くせに、クラスのインスタンスはNewで作ってやんないとそのインスタンスは
使えないなんていう直行性のない仕様も変だ。
だいたい、フォーム名が型であり、唯一存在するそのフォームのインスタンス
の名前として使えるなんて、おかしすぎ。
それに、

Dim hoge as New clsXXX
こうやって作ったインスタンスは

hoge.XXX(...) 'hogeを使う
Set hoge = Nothing 'barが不要になったので、消えてもらう。
hoge.YYY(...)

とNothing を設定した直後でもhogeのインスタンスが使えてしまうなんて、
72 は知ってたか？

Dim hoge as clsXXX
Set hoge = New clsXXX

こうやって作ったインスタンスならこうはならないんだけど、
一体、この仕様にどんな意味があるんだ？
変過ぎー。

91 ：仕様書無しさん：02/09/03 23:32

ここはうんこの臭さについて語り合うスレですか？

92 ：仕様書無しさん：02/09/03 23:39

>>89 >>90
いやー、おもしろい。なるほどー。
これからは、この線でブビチュをバカにしてやろう。

しかし、C使いなのに、こんなこと考えたことなかったなー、俺。
>>89は偉いよ。まじに。

93 ：仕様書無しさん：02/09/03 23:51

V B 叩きは V B 叩きスレへどうぞ

言ってる事は割と同意だけどな｡

94 ：仕様書無しさん：02/09/04 00:01

>>89-90も、それを見て喜んでる連中も、言語ヲタ。

自分が言語仕様の設計するんでもないのに、その良し悪しを
偉そうに語ってる時点で大マヌケ、ってことに気づけ。

そういう話は鉄ヲタが機関車の良し悪しを語ったり、アニヲタが
作画監督の技量をうんぬんするのと大差ないYO

95 ：仕様書無しさん：02/09/04 00:13

>>94
え？
なんで大間抜けなの？

96 ：仕様書無しさん：02/09/04 00:17

>>93
俺的には、うざいブビ厨あがりのC#厨たたきのつもりだったんだけど。
このまま泣きながら消えてくれれば、もうこの話はしない。
（ほかの人は知らんが。）

97 ：仕様書無しさん：02/09/04 00:18

>そういう話は鉄ヲタが機関車の良し悪しを語ったり、アニヲタが
>作画監督の技量をうんぬんするのと大差ないYO

ここはそういうスレだし、おまえもそういうレス書いてたじゃん。
いったいどうしたんだよ。おかしぞう。

98 ：仕様書無しさん：02/09/04 00:20

>>95-97
陰湿な煽りは煽りと(省略)

99 ：仕様書無しさん：02/09/04 00:21

>>94は典型的マヌケ｡
次は自分で家一軒建てられない奴は欠陥住宅に文句を言うな､とでも言うつもりかね？

100 ：仕様書無しさん：02/09/04 00:28

>>94
まあ確かに言語仕様の設計までやった人間なんてそうそういないだろうけど、
暗黙の了解的な部分ながら、この板では本職の人間が話してるんだから、
車作ってる人間が機関車の善し悪しを語ったり、
イラストレーターがアニメの作画監督の技量に云々言うのと
大差無いYO
別に問題無いんじゃない？

レベル低いのが混ざる事も多いけど、気にしない気にしない。

101 ：仕様書無しさん：02/09/04 00:50

ていうか、言うことが細かくて、くだらないところに
こだわりがある、って意味でヲタと比べてるんじゃ？
言語仕様が美しいとか美しくないとかで優劣論じてる
のが馬鹿くさいじゃん。

アニメのキャラの性格がどうとか生き方がどうとか熱く
語るヲタと共通項を見出す、ってのは理解できるけどな。

102 ：仕様書無しさん：02/09/04 01:04

まぁなんだな。
職人(プロフェッショナル)は道具にこだわるものさ。

「弘法筆を選ばず」とも言うけど、筆を選らばなくても結果を出せるのは
一部の超人だけ。

103 ：仕様書無しさん：02/09/04 01:10

普通こだわりくらいあると思われ。
ただこだわりすぎはよくないと思われ。
C○B○Lerみたいなのは

104 ：仕様書無しさん：02/09/04 03:55

横からレスな。
>>101 == >>94
だりょう。どう見てもる

105 ：101：02/09/04 10:51

>>104
残念、はずれ。

106 ：104：02/09/04 15:01

当たったようだな。（PuPuPu

107 ：仕様書無しさん：02/09/04 15:15

>>106
夢がさめないといいですね(^^)

108 ：仕様書無しさん：02/09/04 18:01

　　　　　　　　 _,､､､､､､､,,,,_
　　　　　 ,､-''´::::::::::::::::::::::::::::`::: ､,
　　　　／:::::::::::::::::::::::::::::::::::::::::::::::::`､　(⌒)
.　　 ,::´::::::::::::::::::::::,､::::::::,､;:::::::::::::::::::(⌒)'"ヽ.
　　/:::::::::::::::::/|::::/ !:::::/　ヽ:::::::,､::::::::｀"i!::::::::i.
　　i::::://i::::::/ |_/　i:::/　　 |::::/!!'i::::::::::::}{:::::::::!
　　｀,::| i i'!:::l'"!/`　!/　　 ‐i'/‐､i |:::::::::::i.{::::::::|
　　　ヽ!: !ヾ,,､-=､　｀　　　;;!'=､,.｀i::/::::::i!ヽ;::::i
　　　/:::::lｲ {ヾ';;;i　　　　´{ヾ';;;iヾ!;i:::,r､i 　）:il
.　　 /:::::::::!. ゝ-‐'　，　　丶--'､ //:lノ|　ﾉｿ'
　　/／|:/|:ヽ.''''''　　_, 　　 '''''''' ;〃/::::::i
　〃　 |::i |::从`'‐､､,,___,,,､､-‐;'´::::/:::人ヽ､　～ C++が一番好き ♪
　　　　ヾ !ﾉヽ;:::::::::;l　　　　{::::::ノﾉノ　丶ﾐ
　　　　　´｀,､､-‐"''´　　　　 `丶､:'ノ

109 ：仕様書無しさん：02/09/04 18:04

かわいいのであげ。

110 ：仕様書無しさん：02/09/05 12:38

>>109
アニヲタ晒しさげ。

111 ：仕様書無しさん：02/09/05 13:26

アニヲタ晒しあげ。

112 ：仕様書無しさん：02/09/05 16:30

>>110-111
過剰反応で逆にご自分の性癖がばれてますね(^^)

113 ：仕様書無しさん：02/09/05 16:42

C++の放送は、今週で終了です。
次週からのこの時間帯はC#をお送りいたします。

長い間C++をご覧くださり、ありがとうございました。

　　　　　　　　　　　　　　　　　　　　　　　　スタッフ一同

114 ：仕様書無しさん：02/09/05 16:52

C++の嫌いなとこは教祖が乱立してることかな。だれを信じていいのやら、自分のような
初心者は惑わされっぱなし。

115 ：仕様書無しさん：02/09/05 17:04

教祖を信じるな。C++だけを信じろ。

　　　　　　　　 _,､､､､､､､,,,,_
　　　　　 ,､-''´::::::::::::::::::::::::::::`::: ､,
　　　　／:::::::::::::::::::::::::::::::::::::::::::::::::`､　(⌒)
.　　 ,::´::::::::::::::::::::::,､::::::::,､;:::::::::::::::::::(⌒)'"ヽ.
　　/:::::::::::::::::/|::::/ !:::::/　ヽ:::::::,､::::::::｀"i!::::::::i.
　　i::::://i::::::/ |_/　i:::/　　 |::::/!!'i::::::::::::}{:::::::::!
　　｀,::| i i'!:::l'"!/`　!/　　 ‐i'/‐､i |:::::::::::i.{::::::::|
　　　ヽ!: !ヾ,,､-=､　｀　　　;;!'=､,.｀i::/::::::i!ヽ;::::i
　　　/:::::lｲ {ヾ';;;i　　　　´{ヾ';;;iヾ!;i:::,r､i 　）:il
.　　 /:::::::::!. ゝ-‐'　，　　丶--'､ //:lノ|　ﾉｿ'
　　/／|:/|:ヽ.''''''　　_, 　　 '''''''' ;〃/::::::i
　〃　 |::i |::从`'‐､､,,___,,,､､-‐;'´::::/:::人ヽ､　～他人を信じちゃだめ ♪
　　　　ヾ !ﾉヽ;:::::::::;l　　　　{::::::ノﾉノ　丶ﾐ
　　　　　´｀,､､-‐"''´　　　　 `丶､:'ノ

116 ：仕様書無しさん：02/09/05 23:24

>>114
ネタ？

117 ：仕様書無しさん：02/09/06 01:22

>>114は初心者なんだ。許してやれ。

118 ：仕様書無しさん：02/09/06 17:55

+ 激しくC++ +

119 ：仕様書無しさん：02/09/06 18:04

>>114
許してもらえるといいですね(^^)

120 ：コンパイルエラー（pp：02/09/07 16:07

vector<vector<int>>

121 ：仕様書無しさん：02/09/07 16:47

C++について語るなら、ぜひ一読を！
「Bjarne Stroustrup インタビュー (？)」
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html

122 ：仕様書無しさん：02/09/07 17:10

C++ってﾅﾝﾃﾞｽｶ？

123 ：仕様書無しさん：02/09/07 17:15

>121
事実だとしても驚かないね。
似たようなことはもっとあるんじゃないのかな？
某G氏の会社の製品とかね。

124 ：仕様書無しさん：02/09/07 17:16

STLは統一しよう

125 ：仕様書無しさん：02/09/07 23:22

>>123
ちょっと何年前のネタにレスしてんですか。
ビヨーンのサイト見れや。

126 ：C++使い：02/09/08 07:46

>>121
真のC++使いはあのジョークが笑える。
C++使えないやつの劣等感丸出しじゃん。

俺、このサイト見たとき、C++使えない奴らに教えまくったもん。
「ほら、おまえらのなかまがんばってるぞ」って。

127 ：仕様書無しさん：02/09/09 00:11

>>120
君はvector<vector<int> >を何の疑問も持たずに使ってるのね。
結構結構。

128 ：コピペ：02/09/09 09:51

バッファオーバーランが生じる理由
　バッファオーバーランの発生には、いくつかの前提条件があります。

・C/C++ などのタイプセーフでない言語が使用されていること。
・バッファのアクセスやコピーが安全でない方法で行われていること。
・コンパイラがバッファを、メモリ内の重要なデータ構造の隣または近くに配置していること。

バッファオーバーランは、主に C と C++ で発生する問題であり、
これらの言語は、配列の境界チェックもタイプセーフティのチェックも行わないからです。
C/C++ を使用する開発者は、メモリやマシンレジスタへの直接のアクセスなど、
マシンの構造に直結したプログラムを作成することができます。
これにはパフォーマンス上の利点があり、適切に書かれた C/C++ アプリケーションと同等の速度を持つ、
他のアプリケーションを作成するのは困難です。
バッファオーバーランは他の言語でも発生しますが、実際に起こることは稀です。
また、そのようなバグが存在したとしても、
通常は開発者の責任ではなく、実行環境に問題があります。

http://www.microsoft.com/japan/msdn/columns/secure/secure05202002.asp

C/C++ってダメダメじゃん

129 ：仕様書無しさん：02/09/09 09:57

>これにはパフォーマンス上の利点があり、適切に書かれた C/C++ アプリケーションと同等の速度を持つ、
>他のアプリケーションを作成するのは困難です。

最高じゃん。C++。
Cだと処理が面倒で、適切に書けるやつは少ないのでペケ。

130 ： ◆4COMPILE ：02/09/09 10:47

>・C/C++ などのタイプセーフでない言語が使用されていること。

"タイプセーフ"って？
バッファオーバーランとは関係なくね？本題と関係ないけど。

>>125
　　　　　　（・∀・）
（・∀・）　　 §　　
　 ≡ 　　　　§ Bjarne
￣￣￣￣￣￣￣￣￣￣￣

（・∀・）ﾋﾞﾖｰﾝ! ﾜﾙｶｺｲｲ!!

131 ：仕様書無しさん：02/09/09 11:04

>>128
これってM$のサイトにあったような･･･（ｗ

132 ：仕様書無しさん：02/09/09 11:36

＞タイプセーフ
variantっぽいものがある言語じゃないの？

133 ：仕様書無しさん：02/09/09 12:05

>>131
リンク先がモロじゃん

134 ：仕様書無しさん：02/09/09 13:20

URL見てどこのサイトかわからない>>131は
PGでないことを祈る・・・。

135 ：仕様書無しさん：02/09/10 19:54

MICROSOFTのVC++6.0のPROには、
最適化できる機能がありましたが、
VC++NETのStandard Editionには
最適化の機能がありますか？

136 ：仕様書無しさん：02/09/10 20:01

有馬千

137 ：仕様書無しさん：02/09/10 20:27

自分で組みましょ

138 ：仕様書無しさん：02/09/10 23:33

>>128
MS の言うことを信じてどうする…
FORTRAN でさえ、境界チェックするかどうかはコンパイラに依存 (オプションだったり)
するってのに。

139 ：仕様書無しさん：02/09/13 06:19

愛してる

140 ：びひゃ～ん ◆CplusNDg ：02/09/13 14:21

>>139
ありがと！私も愛してる？

141 ：仕様書無しさん：02/09/13 14:23

？

142 ：仕様書無しさん：02/09/13 14:33

適した使用用途が広い言語。

143 ：仕様書無しさん：02/09/13 15:14

なんでもできるけど(LISPのような機能以外)
馬鹿の作ったバグの範囲が特定しにくくて困る言語

144 ：仕様書無しさん：02/09/13 22:46

馬鹿を雇っている会社は如何し様も無いね。

145 ：仕様書無しさん：02/09/14 01:16

>>144
馬鹿とハサミは...ってな。
よりによってC++でコーディングさせるのが間違いなだけ。

146 ：仕様書無しさん：02/09/14 12:49

そう、よかったね。

147 ：仕様書無しさん：02/09/16 03:29

Java みたく、冷害が発生する可能性がある場合は throws をつけないと
エラーになるようにしてほしい。
標準ライブラリでなくても、標準 extension みたくして、ANSI 規格で GUI
を標準化してほしい。

garbaged class Foo {
public:
　 ...
};

みたいなことができるようにしてほしい。

148 ：仕様書無しさん：02/09/16 03:42

>>147
すまんが、何言ってんだかさっぱり判らん。

149 ：すぷーん ◆spoonCC. ：02/09/16 03:54

>>147
1は選択できるのが良いのでは？例外を使いたくない場合もあるし。
2は、、、うーん、難しいだろうね。面白くなくなるんじゃないかな。
3は不要でしょ。デストラクタ等を使って美しく実装して、うっとりしませう。

150 ：C++マンセーである：02/09/16 07:39

けど．．．。

正直、Javaみたいな、GUIの標準ライブラリはほしいっす。
GUIのためだけに、MFCとかVCLとかやるのはつらいっす。
あと、ネットワークの標準ライブラリも。
それとデータベースアクセスも。
Javaに負けてるのは、この3点だけでわ？

151 ：すぷーん ◆spoonCC. ：02/09/16 11:49

>>150
GUIを標準化するなら、おっしゃる通り外部で標準化してから取り込むことになるのかも。
漏れはGUI部分を楽チンに実装する為にMFCを使ってるんだけど。
GUI以外ならMFCの必要性はあまり感じないなぁ。

ネットワークはWinSockをクラスラッピングしたライブラリを使ってる。
Socketは簡単に使えるからいいけど232Cとかの通信をクラス化して欲しいな。
(もうクラスラッピングしたライブラリを持ってるけど)

DBは全く使わないのでよくわかりましぇん。

Javaはよく知らないんだけどWindowsで書いたGUIコードをX Windowに持って行っても
そのまま動くの？

152 ：仕様書無しさん：02/09/17 01:13

>>151
> Javaはよく知らないんだけどWindowsで書いたGUIコードをX Windowに持って行っても
> そのまま動くの？

基本的に、諸般の事情（JavaVM やファイル・システムの差異など）が影響しなければ、
そのまま動きます。

153 ：150：02/09/17 01:26

>>151
あ。マジレス恐縮です。

俺もGUIはMFCです。ネットはCSocketで。
こいつらにはだいぶ投資したので、かなり使えるようになった気にはなってます。
が、やっぱり、いつ裏切られるかわからない．．．というか、.NETでもう裏切られたというか。

で、やっぱり標準がほすぃな、という感想ですた。

154 ：仕様書無しさん：02/09/17 03:54

>>150
同意。C++は標準クラスライブラリが不足しすぎている。

155 ：仕様書無しさん：02/09/17 09:47

まさか、組み込みやOSのカーネルまで意識している言語が、
ソケットだのGUIだのを標準にはできないような。
C++ Level nみたいな感じで、プラットフォームに応じて
標準ライブラリを取り外し可能にする、という手はあるような
気はするが。今でもEmbeddedがあるんだし。

156 ：仕様書無しさん：02/09/17 10:00

まあ、GUIの標準は無理かも。
でも、プロセス間通信やソケットクラスの準標準くらいあっても。
あと、データベースインタフェースぅ。

157 ： ◆4COMPILE ：02/09/17 10:56

まぁGUIとかDBとかは誰か外部で作ったものを取り込む形だぁね。
進展の早いものだし、言語自体とはある程度直交性のあるものだし。
誰か作ってくれないかね。

>>154
微妙、漏れ的にはこれほど標準ライブラリの充実した言語はないと思ってる。
無知なだけ？　ｽﾏｿ
>>150には同意。

158 ：仕様書無しさん：02/09/17 11:00

そういう状態でもやっぱりVBは馬鹿にする、ってのは
なんかのプライドなのかな？

C++ユーザの気持ちってようわからん。

159 ：仕様書無しさん：02/09/17 16:34

VB厨の気持ちはようわからん。

160 ：仕様書無しさん：02/09/18 01:03

C++マンセー

161 ：仕様書無しさん：02/09/18 01:24

con(cut)

162 ：仕様書無しさん：02/09/18 01:48

>>157
標準ライブラリで提供されているのは数こそは多いけど
似たようなものばかり。カテゴリが少ない。

163 ：仕様書無しさん：02/09/18 03:36

VBを馬鹿にするわけじゃないけど、VBとC++で分けるより全部BCBで書いたほうが楽だからなぁ。

164 ：仕様書無しさん：02/09/20 00:47

>>158
プライドどうこうというより、たとえば Template Method パターンや
Composite パターンが作れないとか、いちいち制約が多すぎて、コードが
肥大化してやってらんないというのがある。
VB.NET は知らないけど、VB6 までは賛嘆たるものだった。

165 ：仕様書無しさん：02/09/20 00:52

>>162
そうかな？
おれは>>157に救命胴衣。
C++のライブラリは徹底的に汎用なものだから、
インスタントで使えないということはあるかも。

今日はよくC++スレの上がる日だね。

166 ：仕様書無しさん：02/09/20 02:05

DBとNetはもうRogueWaveのでいいじゃん
つーか値下げ汁

167 ：仕様書無しさん：02/09/20 10:58

>>164
ライブラリが足りないっていう苦労と比較したら、という意味で書いてる
のではないかと思うよ、>>158は。

まあ、天秤にかけた結果は個々人でそれぞれだろうけど、一方的に
他方を「馬鹿にする」ってことは、「それぞれでいい」とは思ってない
証拠だろうからね。

168 ：仕様書無しさん：02/09/20 11:15

Javaﾏﾝｾｰ

169 ：仕様書無しさん：02/09/20 17:11

C++がJavaやC#に大きな影響与えたのは事実では？

170 ：仕様書無しさん：02/09/20 17:39

そうだね。C++のおかげで悪い所・未熟な所がはっきりし、
C++の反省点をいかしてJavaやC#が作られた。

171 ：仕様書無しさん：02/09/20 18:15

ネットワークのコードを書くときはみなさんライブラリは
何か使ってます？MFCってのは無しで。

172 ：仕様書無しさん：02/09/20 18:29

C++ってネットワークのライブラリもついてないのかよ！

173 ：仕様書無しさん：02/09/20 18:40

Javaもできるのがあと3年遅ければSTLの成果を活かせたんだろうがね。

174 ：sage：02/09/20 20:19

ReflectionがないからCppUnitがイマイチ。
RubyUnitとJUnitはいいね！

175 ：仕様書無しさん：02/09/20 20:21

しくった・・・

176 ： ◆4COMPILE ：02/09/20 20:52

>>174
それは確かにそう思った。追加し忘れるっての。

177 ：名無しさん＠おひさまのよう。：02/09/20 20:54

Reflectoinは組み込みにはいいなぁ。
つーか、KVMじゃなくてJVMで組み込みつーのもやなプロジェクトだなぁ。
C/C++でやれや、ゴルァ！

と愚痴をはいてみるてすと。

178 ：仕様書無しさん：02/09/20 21:26

この際入れてばいいのになぁ。
どうせC++なんて拡張しまくりなんだから。
ずさずさ拡張してAOPも取り入れてくれ。

179 ：C++マンセー：02/09/20 21:34

>>178
うーん。そうくるか。

180 ：仕様書無しさん：02/09/21 00:19

Kylix3のC/C++対応、これどうよ？

181 ：仕様書無しさん：02/09/21 00:21

kylixマンセー

182 ：すぷーん ◆spoonCC. ：02/09/21 00:54

>>180
気になってるんだよねー、それ。
どうなんだろう。
なら、さっさとインストールして使えという話もあるが。。。

# ところでKylix = カイリックスと読んでるよね？

183 ：仕様書無しさん：02/09/21 06:04

>>182
読んでなかったんだね。

184 ：仕様書無しさん：02/09/22 00:58

キリックスじゃない・・・の？

185 ：『愛に走れ』：02/09/22 02:30

最初見た時
その昔
ロコモーションのカバーバージョンとか、
ラッキー、ラッキー、ラララララ、な歌で
で有名になった娘の名前を思い出したなぁ。
ので、なんとなくそう読んでしまった。

「きりっくす」だと、Kilyx とかになりそう。

186 ：仕様書無しさん：02/09/23 05:25

>>174
C++ Builder 用の CppUnit = BCBUnit は Reflection あるで～
らくちんやで～

普通の C++ には、επιστημηさんの Cuppa で楽しく CppUnit できるよ。
Reflection やないけど。

187 ：仕様書無しさん：02/09/25 17:17

επιστημηさん　マンセー

188 ：仕様書無しさん：02/09/25 17:30

C++の資格ってドコで取れますか？

189 ：仕様書無しさん：02/09/25 17:32

ぐぐれ。無資格でC++書いちゃいかんよ。
わが社で調べたら、コピー・代入の処理なしだの、const忘れは、
みんな無資格プログラマだった。

190 ：マーシー：02/09/25 18:25

資格はネタとして Effective C++ シリーズを理解してないやつには
C++書くな、と言いたい。

191 ： ◆4COMPILE ：02/09/25 18:31

>>186
河童詳細きぼん

>>190
それなりに同意

192 ：仕様書無しさん：02/09/25 19:07

2ch C++試験

試験範囲
　Effective C++ シリーズ

193 ：188：02/09/25 19:09

いやっ、ネタでは無いのですが…

194 ：仕様書無しさん：02/09/25 20:47

結構長くＣ++のお世話になっているけど、わざとは難しくしているんと違うんかいと
疑いたくなる所がある。
逆に、それをモノに出来た自信が他言語を見下す要因にもなっていると思う。

195 ：仕様書無しさん：02/09/25 21:50

>>194
それをモノに出来た奴が考えることが二つある。
一つは「俺難しいことがわかったから天才」
もう一つは「C++はわざと難しくしている言語。度重なる拡張で
あまりにも複雑になってしまった言語。わかりにくいのも当然」

C++を超えられないものと超えられるものの違いがそこにある。

196 ：仕様書無しさん：02/09/25 22:26

>>195
俺は違うよ。
「なんてすばらしい言語なんだ～。うっとり。」
だけど。

「俺は難しいことわかった」ははやく氏んでほしいが、
「C++はわざと難しくしている」と言う奴にも氏んでほしい。

197 ：仕様書無しさん：02/09/25 22:36

ここにもC++を超えられない奴が(藁

198 ：仕様書無しさん：02/09/25 22:39

ここにもC++に挫折した奴が（藁

199 ：仕様書無しさん：02/09/25 22:50

C++が難しいって奴は、たいてい、仕様の膨大さ（複雑さではない）を問題にして、
そんなに覚えられねーみたいなことを言うけど、その段階でまちがってると思う。
本当のところ、理解できてないのは、C++流の考え方。
別に難しくないのに、あさっての方向向いてるから、永遠にわからないんだと思う。

200 ：教授：02/09/25 23:44

Prolog的な概念が理解できるとC++なんて屁ですよ。
最近のDQNは重要なことを素っ飛ばしますからね。困り者ですヽ(´ー`)ﾉ

201 ：仕様書無しさん：02/09/25 23:46

>>199
C++が難しい・複雑ってのはC++を理解してから言ってるんですよ。
それがわからないのは本当に理解してないからでしょう。

202 ：仕様書無しさん：02/09/25 23:46

「俺は難しいことがわかったから天才」っつー奴は、
Cのポインタあたりで発生してウザイ。

構造体へのポインタを返す関数へのポインタを返す関数
を引数にする関数のうんたらかんたら。。。とか言って喜んでるヤシ。

こういのが「C++は難しすぎる」とかぬかす。

203 ：仕様書無しさん：02/09/25 23:52

>>201
（　´,_ゝ`）(ﾌﾟｯ

204 ：仕様書無しさん：02/09/25 23:53

>>203
ﾖｼﾖｼ(w

205 ：仕様書無しさん：02/09/25 23:59

C++を理解したって何を理解したのかねぇ～。
理解したことや必須と思う技術や必読の本を言ってみ。
どうせ、あれが理解できてないとかあの本を読んでない奴はモグリとか
言われるのがおちだから。まっ、こんな所にC++を理解した奴なんかいないだろうがね。

206 ：仕様書無しさん：02/09/26 00:06

>>201は今頃フトンの中で真っ赤になってブルブル震えながら油たれ流してるんだろうね。（ｸｽ

207 ：仕様書無しさん：02/09/26 00:07

>>206
（　´,_ゝ`）(ﾌﾟｯ

208 ：仕様書無しさん：02/09/26 00:14

必携書

Effective C++
More Effective C++
GoF

他には？

209 ：1分でレスかよ（ｗ：02/09/26 00:16

>>207
反応はえーな、お前。
何、ダウンロード猿ってやつ？
泣きながら、更新ボタン押し続けてるの？

210 ：仕様書無しさん：02/09/26 00:17

>>208
Modern C++ Design

211 ：仕様書無しさん：02/09/26 00:28

>>209
書き込んだのと見たのとのタイミングが合っただけ。
それよりダウンロード猿って何？お前は何を落としてんの(w

212 ：仕様書無しさん：02/09/26 00:31

>>208
ARM
Effective STL

213 ：仕様書無しさん：02/09/26 00:32

>>208 >>210 >>212
なぜ、教祖のバイボーを書かん？

214 ：仕様書無しさん：02/09/26 00:39

>>208
eXtreme Programming テスト技法
リファクタリング

C++ が難しいかについて:

C++ は難しい、というか、複雑、というか、無理がある。それから稚拙。
継承はデフォルトで public じゃないし、メンバ関数はデフォルトで virtual じゃないし、
デストラクタは忘れずに virtual にしなくちゃいけないし。
簡単なインターフェース（純仮想クラス）を作ろうとしても、デストラクタは作らないとだめ。
オーバーライドを禁止する方法がないし、オーバーライドしたつもりでシグニチャを間違えていても
警告出ないし（Delphi でいう virtual - override がほしい）。
ポインタ型にしないと多態性が使えないし、そうするといつ delete するかはっきり決めないと
メモリ・リークするし。自分のコードならいいけど、他人のコードでめちゃくちゃなのは
はっきし言って追えん。
あるインスタンスを、静的にも動的にも取れるのも煩雑。
ロジック、クラス関連以外に、そういう本質的でないところで気を遣わされる。
いちいちかったるい。

215 ：仕様書無しさん：02/09/26 00:43

>>208
C++ third.

216 ：仕様書無しさん：02/09/26 00:45

>ダウンロード猿

リロード？

217 ：212：02/09/26 01:10

>>213
いや、それは必携というより、あることが前提条件だから。

218 ：仕様書無しさん：02/09/26 02:40

そういや…D言語とかはどうなんたんだ？

219 ：仕様書無しさん：02/09/26 03:03

>>214
>ポインタ型にしないと多態性が使えないし、
うそをつくな

220 ：仕様書無しさん：02/09/26 03:05

教祖のバイボーって
プログラミング言語Ｃ＋＋かな？

私はもってないや
スコットメーさんのは３冊とも持ってるけど

221 ：（　´,_ゝ`）(ﾌﾟｯ：02/09/26 09:47

>>214
初心者は初心者質問スレへどーぞ。

222 ：マーシー：02/09/26 10:26

＞必携書

＞Effective C++
＞More Effective C++
＞GoF

GoFはちょっと傾向が違うような。
オレだったら、これははずして、
C++ FAQ
あたりを推薦する。

223 ：仕様書無しさん：02/09/26 11:41

>>222
プログラミング言語C++は暗記しているということか！

224 ：仕様書無しさん：02/09/26 12:00

214 は、C++ がマルチパラダイム言語を目指しているということが
わからないらしいな。

225 ：金田一：02/09/26 13:45

必携書で意見が割れる
　↓
人によって本の好みが分かれる
　↓
本ごとに書いてることが微妙に違う
　↓
言語仕様が曖昧なために解釈が多様になる

226 ： ◆4COMPILE ：02/09/26 14:37

>言語仕様が曖昧なために解釈が多様になる

（・∀・）？

227 ：仕様書無しさん：02/09/26 16:37

>>226
つまりAという方法もBという方法もどっちでも可能、という仕様なら、
Aを推奨する人間とBを推奨する人間とに分かれる、って意味だと
思われ。

228 ：仕様書無しさん：02/09/26 16:49

>教祖のバイボーって

バイボーって何？？

229 ：仕様書無しさん：02/09/26 16:53

バイブルの事じゃない？

230 ：仕様書無しさん：02/09/26 16:57

>>229
そっかそっか。ありがと。
意味不明な言葉使う奴いて困るよね。

231 ：213：02/09/26 17:07

レスが。
バイボーがわからんだとっ？
bibleにきまっとろうが。
アメリカ人はバイボーって．．．

て、あのその、ごめんなさい。

232 ：仕様書無しさん：02/09/26 17:08

今までCとJavaをやってきてて、昨日からVC++はじめました。
どこから手をつけたらいいのかわからんのですが。。
まず教材が理解不能デス。。

233 ：仕様書無しさん：02/09/26 17:23

お前はその程度ってこと。

234 ：仕様書無しさん：02/09/26 17:30

>>232
なんか、散漫じゃない？
C、Java、VC++？

235 ：仕様書無しさん：02/09/26 17:33

ネタはネタと(省略)

236 ：仕様書無しさん：02/09/26 17:41

そういう会社なのよ。空いた者からある案件につぎ込んでいくから。
ほとんどキャリア関係無し。VBも2ヶ月だけやったな。

237 ：仕様書無しさん：02/09/26 20:37

Ｃ＋＋は器用貧乏

238 ：仕様書無しさん：02/09/26 20:38

Ｃ＋＋はプロトタイプ

239 ：仕様書無しさん：02/09/26 21:24

Ｃ＋＋は最凶

240 ：仕様書無しさん：02/09/26 22:00

C++ってDじゃないの？

241 ：仕様書無しさん：02/09/26 22:13

「Ｃ＋＋教えます。２０分１０００円でいかが？」

242 ：仕様書無しさん：02/09/26 22:16

C++ってEじゃないの？

C D E

243 ：仕様書無しさん：02/09/26 22:20

クラス分けだのオブジェクト志向だの格好のいいこと言いながら、
よれたプロジェクトのソース見るとそんなん殆ど形になってないような。
学者連中が理想を展開するサンプルとしはいいが、現場には関係ねえだろ？

244 ：仕様書無しさん：02/09/27 00:43

>>219
悔しかったら、
ParentClass obj = ChildClass();
ってやってみろ！

245 ：仕様書無しさん：02/09/27 01:50

>>208
そのどれよりもExceptional C++が重要だと思う。

246 ：仕様書無しさん：02/09/27 01:53

>>244

class ParentClass
{
public:
    ParentClass()
        :rPc(*this)
    {
    }
    ParentClass(ParentClass& rPc_)
        :rPc(rPc_)
    {
    }
private:
    ParentClass& rPc;
};

class ChildClass : public ParentClass
{
};

void hoge()
{
    ParentClass obj = ChildClass();
}

で？

247 ：仕様書無しさん：02/09/27 01:58

>>245
時間が無いから買ってチラとしか見てないけど
あれは結構良さそう。

248 ：仕様書無しさん：02/09/27 02:01

>>246
D:\test>bcc32 test.cpp
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
test.cpp:
エラー E2034 test.cpp 22: 'ChildClass' 型は 'ParentClass' 型に変換できない(関数
hoge() )
警告 W8004 test.cpp 23: 'obj' に代入した値は使われていない(関数 hoge() )
*** 1 errors in Compile ***

% g++ --version
2.95.4
% g++ -c test.cpp
test.cpp: In function `void hoge()':
test.cpp:22: initialization of non-const reference type `class ParentClass &'
test.cpp:22: from rvalue of type `ChildClass'
test.cpp:9: in passing argument 1 of `ParentClass::ParentClass(ParentClass &)'

で？

249 ：仕様書無しさん：02/09/27 02:24

>>246のってキモイね。

250 ：仕様書無しさん：02/09/27 02:33

悔しいのだろう。

251 ：仕様書無しさん：02/09/27 10:14

でも>>244はJavaもコンパイラ通らないという罠。

252 ：仕様書無しさん：02/09/27 21:44

>>251
Java は静的にインスタンスを生成する方法がないからね（static を除けば）。

ParentClass obj = ParentClass();

は C++ の場合、ParentClass obj; と等価になる。

ParentClass obj = ChildClass();

は C++ では解釈不能になる。

ParentClass *obj = new ChildClass();

ならできるけどね。
Java はもともとプリミティブ型以外は、何かのインスタンスを指しているから、

ParentClass obj = new ChildClass();

となるね。

253 ：(；´Д｀)ﾊｧﾊｧ：02/09/28 00:02

ParentClass &obj = ChildClass();

254 ：仕様書無しさん：02/09/28 01:09

１．Exceptional C++
２．Efficient C++
３．Essential C++

この中で１冊買うなら１がいい？
前にいっそ３冊買おうとしたけど１万超えるからやめてGoF本買った
まあ、１冊１万超える本でほしいのあるんですが（汗

現在はGoF本読んでます

255 ：仕様書無しさん：02/09/28 08:39

>>254
女子高生のC++

256 ：仕様書無しさん：02/09/28 09:26

>>254
1は他の二つとはかなり毛色が違うんで、単純な比較はできないような。
2,3は同じようなネタを扱った本は結構あるけど、なかなか1みたいな
本は無いから、敢えて1冊だけ選ぶなら1かなあ。

257 ：仕様書無しさん：02/09/28 10:25

>>254
Essential C++ はだから
候補から除外していいと思う。

258 ：仕様書無しさん：02/09/28 13:36

Essential C++って記憶が間違ってなければC++の速習本だったと思うんだが。

259 ：仕様書無しさん：02/09/29 02:18

>>253
ほんとだ。ありがとう！

260 ：仕様書無しさん：02/09/29 03:11

C++は無駄なもの多すぎ。デブと一緒。

261 ：仕様書無しさん：02/09/29 03:42

C++は無駄だし、うざい機能多すぎ。混同と一緒。

262 ：仕様書無しさん：02/09/29 04:08

C++は言語を使って何かを作るのではなく、言語を学習すること自体を楽しむ言語。
中途半端に知っているもの同士が言語仕様について熱く語っているのが良く見られる。
しかも言語仕様について誰もすぐに的確なことを言えない。

263 ：仕様書無しさん：02/09/29 11:00

C++はまともなPGの普通の道具。
CはC++を理解できなかった年寄りたちの墓場。
Javaはさげすまれても引退できない人たちの避難場所。
C#はMSの新しい商売道具。（ただしまだ予定）

264 ：仕様書無しさん：02/09/29 14:54

C++はいまの時代にプリント基板にハンダごてで部品をくっつけて
ラジオを作ってるような感じ。
それはそれである意味「すごいこと」ではあるけど、だれもが
そこまでできなければいけないという錯覚を持つと危険。

災害時の避難所でラジオがないからといって「じゃあ作ればいい」
という話にはならないように、どこまで必要かに応じて考えるべき
こともあるので、なんでもかんでもC++でなきゃだめ、というのは
ある種の偏執狂である。

265 ：仕様書無しさん：02/09/29 15:36

なんでもかんでもC++でなきゃだめ。

266 ：仕様書無しさん：02/09/29 16:03

>>265=偏執狂

267 ：265：02/09/29 17:53

じゃ、Javaも可。（ｳﾌ

268 ：仕様書無しさん：02/09/29 18:19

>>263
禿しい同意。

>>264
9点。

269 ：仕様書無しさん：02/09/29 18:23

demangle mangling とかってどういう意味？辞書にも載ってない。

270 ：仕様書無しさん：02/09/29 18:28

C++の仕事なんてうちの会社にはありません。
VB厨がC++で作れば赤字にならなかったとかほざいてます。
社長はC言語が出来ればC++なんて簡単でしょ？とか言います。
クラスの説明したら関数でいいじゃんとか言われました。

271 ：仕様書無しさん：02/09/29 18:47

ﾌﾞﾋｬﾋｬ
時代錯誤も甚だしいな

272 ：仕様書無しさん：02/09/29 18:53

>>270
さっさと会社辞めれば？

273 ：仕様書無しさん：02/09/30 00:50

>>269
mangle なら載ってるんじゃ？

274 ：仕様書無しさん：02/10/02 12:15

>>271
時代錯誤＆シッタカじゃない社長ってどれくらいいるんだろ...

275 ：174：02/10/04 02:25

>>186
>C++ Builder 用の CppUnit = BCBUnit は Reflection あるで～
>らくちんやで～
みたいね。

cuppaは使ったんだけど、
コマンドラインに一々メソッド名渡してやらなあかんから、
＃このバージョン古い？たしか1.7．．．
既存のソース読ませて一気にテストコード生成とかできないんだよね。
テスト書いてからつーのが当たり前なんだけど
人のソースを扱うとね．．．
＃patch書こうとも思ったけど、
＃C++で文字列処理やるのがうざくてね。
＃構文木クラス作れと？

276 ：仕様書無しさん：02/10/08 00:51

>>275
今の cuppa ちゃんはできるようになったみたいよ。
子河童って言う方かな？

277 ：仕様書無しさん：02/10/08 01:45

>>275
そういう時にピッタリなパターンがあるでしょ。
ほら、あれ。

278 ：仕様書無しさん：02/10/08 02:07

>>277
Interpreter で Composite なクラス階層の Command を
Factory に作るんですね？

279 ：仕様書無しさん：02/10/08 11:02

>>278
違いますよ。
あれですよ。あれ。

280 ：dfdf：02/10/10 16:37

dfdfdf

281 ：仕様書無しさん：02/10/27 08:31

Ｃ++って文法よりライブラリーを習得する方が大変。
ＭＦＣやＳＴＬなど。

282 ：仕様書無しさん：02/10/27 10:21

組み込みでC++使っている現場はあるのでしょうか？
STLやデザインパターンとか使ったら
メモリ使いまくりで話にならないような気がするのですが

283 ：仕様書無しさん：02/10/27 14:14

>282
うちの会社、C++で某プロトコルスタックが組まれたのだが、
メモリはともかく速度的に話にならなかった…

284 ：仕様書無しさん：02/10/27 17:55

>>282
メモリ使いまくりにならないようにC++を使えばいいんじゃねぇの？

285 ：すぷーん ◆spoonLv.3M ：02/10/27 21:16

>>282
漏れは使ってないけど、普通に使ってるという話をここ(2ch)で聞いたことある。
よって信憑性は無し(w

286 ：仕様書無しさん：02/10/28 00:58

コンパイラがダメダメとか、思いきり勘違いしたSTLの使い方を
しているとか、そういう話だったりして。

287 ：仕様書無しさん：02/10/28 01:42

来年から就職の学生です。
内定先からJava勉強しろって言われて、渡された本一冊終わらせて、
ついでにC++ってどんなかなと思って勉強してみたら、なんかJavaよりクールに見えた。
直感的だから、どこがクールだったかとか上手にいえないけど。
それと同時に、やれ複雑だの、やれ余計な機能が多いだのという理由も１％ほどわかった。

実際仕事となると、最近はJavaばかりなんでしょうか？どーなんです？

288 ：仕様書無しさん：02/10/28 01:58

C++は、消えてなくなるだろうな。
難し過ぎだし、効率は良くないし、遅いし（OSの記述で使われてない）
いづれ「あの時代に流行った、もんだなあ」と言われるだろう
とりあえずはSTLの存在で救われている部分はあるが、そんなに
寿命は長くは無い。Perlやその他、簡単な言語に追い出されるだろうな

289 ：仕様書無しさん：02/10/28 02:02

>>287
んなもん種類によるだろ。

290 ：仕様書無しさん：02/10/28 02:14

さっさと

RogueWaveを

標準に

しろや

糞が

291 ：仕様書無しさん：02/10/28 05:48

>>282
　メモリ食いまくりって、昔の６４Ｋや６４０Ｋじゃ無いんだよ。
　メモリ食いまくりって言えば、Ｊビルダーの方が凄い。２５６Ｍでは満足な速度が得られないそうだ。

　時代が変われば、これに合わせて、価値観を変えるのが吉だな。

292 ：仕様書無しさん：02/10/28 05:53

>>288
　Ｐｅｒｌは、Ｃ++のＳＴＬのコンテナの様なことを文法レベルで解決していますね。
　Ｐｅｒｌは、使ったことが無いけど、簡単な文法の勉強はしています。
　感想は、決して簡単な言語じゃないって思いますよ。

293 ：仕様書無しさん：02/10/28 07:59

Perlってevalあるんだよね？

294 ： ◆qQ4COMPILE ：02/10/28 10:35

>>278
見込みあるな、おぬし。

295 ：仕様書無しさん：02/10/28 10:40

>>292
めちゃくちゃ簡単だと思いますが。
ちょっとかじった程度のシロウトでもCGIの改造くらいはできるんだし。

C++で作ったアプリのソースもらってもシロウトが簡単に改造、
とはいかんでしょ

296 ：仕様書無しさん：02/10/28 12:02

perlとC++は対立するもんじゃないでしょ。
俺、両方好きだよ。

297 ：仕様書無しさん：02/10/28 12:38

日本のレベルが低いのはわかるけど「C++が難しい」は無いでしょう…。
ちょっと正直ショックだった。

298 ：仕様書無しさん：02/10/28 12:45

そしてPerlは「読めない」

299 ：仕様書無しさん：02/10/28 12:46

>>297
それは単にあなたがもっと簡単なものを知らないだけの話

300 ：仕様書無しさん：02/10/28 12:54

Rubyなら他のどの言語より簡単で
しかも他のどの言語より高機能

301 ：仕様書無しさん：02/10/28 12:59

最初に覚えたのがC++という人はちょっと気の毒かも
もっと気楽にプログラミングできる言語がいくらでもあるのに

プログラミングは大変なものだという先入観が植え付けられなければいいけど

302 ：仕様書無しさん：02/10/28 13:05

少しは外国のサイトも見てみないかい？

303 ：仕様書無しさん：02/10/28 13:16

>>302
http://msdn.microsoft.com/vbasic/

外国のサイトですが、何か？

304 ：仕様書無しさん：02/10/28 13:25

>>301
ワンボードマイコン時代にコンピュータを触り始めた人は
マシン語から始めたことになるけど
そのせいでプログラミングが嫌いになったということはないだろ。

むしろ大変なものだったからこそ
ますますのめり込んだ。

305 ：仕様書無しさん：02/10/28 13:27

>>304
マシン語は単純だよ

306 ：仕様書無しさん：02/10/28 13:40

>304
301は別に嫌いになるとまでは言ってないな。

>305
複雑とは書いてないな。大変だってしか書いてない。

話がごちゃごちゃしてなんかようわからなくなってきてるな。

307 ：仕様書無しさん：02/10/28 13:42

一つ一つはね。
まあそれが1000個くらいあったら萎えまくり。

308 ：仕様書無しさん：02/10/28 13:44

マシン語が大変なものだったからこそアセンブラが発明され高級言語が発明されたんだろ。

マシン語が簡単だっていうならC++なんか使うのやめて明日からマシン語でプログラムしれ。

309 ：仕様書無しさん：02/10/28 14:00

C++が遅いって言ってる人は当然マシン語ONLYだよな？

310 ：仕様書無しさん：02/10/28 14:01

>>308
ワンボードマイコン時代云々つーから単純つったんだよ
当時のプログラムなんてそれこそ単純なもの

311 ：仕様書無しさん：02/10/28 14:24

>>309
当たり前。
開発効率・可読性・可搬性・保守なんて考えるわけねえだろ。
実行するプラットフォームに最高までに最適化されたプログラムを
アセンブラで作っていく。バイナリは最小サイズになり、無駄はゼロ。
時々ROな場所に書き込んでも気にするな。一時落ちるだけだ。

312 ：仕様書無しさん：02/10/28 14:59

アセンブラ？？
309には機械語と書いてあるが？

オブジェクトファイル形式からも逸脱したプログラミング素敵ね

313 ：仕様書無しさん：02/10/28 16:10

>>311
プログラマ辞めろ。

314 ：仕様書無しさん：02/10/28 16:37

メインフレームを動かすのは楽しかったじょー。

315 ：仕様書無しさん：02/10/28 16:40

ウインドウ描写するだけで一日終わりそうだ。

316 ：仕様書無しさん：02/10/28 16:45

Hello Worldですら一大プロジェクトになりそうだ

317 ：仕様書無しさん：02/10/28 17:01

むしろ大変だからのめりこむのだそうな

318 ：仕様書無しさん：02/10/28 19:56

>>309
Ｃでもいいんでないの？

319 ：仕様書無しさん：02/10/28 20:34

ｃ＋＋ぉながいします
0～99の数字を1秒間隔で表示。１～９で改行、表示する
こんな感じです

１　２　３　４　５　６　７　８　９
10　11　12～～～～～～～～～～～～
～～～～～～～省略～～～～～～～～
～～～～～～～～～～～～～～～～99

これのプログラムを教えてください
よろしくお願いします
もう死にそうです

320 ：仕様書無しさん：02/10/28 20:48

なら、いっそ死んでみては？
そんなことで死ぬやつはいない

321 ：仕様書無しさん：02/10/28 20:53

で、けっきょくのところ、C#はどうなのよ？

322 ：仕様書無しさん：02/10/28 21:47

++が２倍

323 ：321：02/10/29 02:09

その２倍はどうなのよ?マイナスをいくら倍にしても無駄だろう

324 ：仕様書無しさん：02/10/29 09:55

http://www.mozilla.org/hacking/portable-cpp.html
C++ portability guide

結論　C++は使いものにならない

325 ：仕様書無しさん：02/10/29 10:01

>>319で死ねるＰＧってのも禿しく嫌だな・・・
こんな奴ばっかの職場だったら(((（ ;ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

326 ：仕様書無しさん：02/10/29 10:50

C#やらなアカンのかなあ、やっぱり。
もうJavaでエエやん

327 ：仕様書無しさん：02/10/29 11:03

>>324
はぁ？

328 ：仕様書無しさん：02/10/29 11:28

英語読めますよね？（ｗ

329 ：仕様書無しさん：02/10/29 11:55

VC++ってすごくないですか？
なんか、MFCとATLとSTLが同居してると、
C++って、なんでもありなんだね。って感じがして嬉しくなります。

特に、MFCの設計思想、濃すぎだよぉ。

高速化＞＞＞＞＞＞＞＞可読性
って感じがするかと思えば、、、

趣味的汎用性＞＞＞＞＞＞＞＞高速化
って感じがするところもあったり、、、

トリッキー＞＞＞＞＞可読性
ってな感じで

読んでて飽きない、素晴らしいライブラリです。

でも、いきなりMFCから入ったプログラマにろくな奴が居ないのは
どーしてくれよう、、、、

330 ：仕様書無しさん：02/10/29 12:14

>>329
俺と赤ちゃんを作らないか？

331 ：仕様書無しさん：02/10/29 12:16

で、319 は誰？

332 ：仕様書無しさん：02/10/29 12:17

319=329

333 ：仕様書無しさん：02/10/29 12:24

中身をC++で書いてるくせに、
インターフェースはCのインターフェースで、おまけに
ハンドラ関数の指定までできるようになっているDLLは
どういう設計思想なのでしょうか？
意味わかりません。

334 ：仕様書無しさん：02/10/29 13:35

C++について一言。

最高！

335 ： ◆qQ4COMPILE ：02/10/29 13:51

>>333
（・∀・）ｶｺｲｲ!!

336 ：仕様書無しさん：02/10/29 14:00

minoru～n♪

337 ：死ね死ね団：02/10/29 14:16

！

338 ：仕様書無しさん：02/10/29 20:56

2004年春　C++滅ぶ、

339 ：仕様書無しさん：02/10/29 21:17

vector<vector<int>> a;
ってなんでコンパイルできないの？

340 ：仕様書無しさん：02/10/29 21:19

>333
マジレス。Win32の話だとすると…
DLLからC++のクラスをエクスポートすると修飾名がついたりして
ややこしい。コンパイラのバージョンが変わってインポート
できなくなっても文句は言えない。
どうしてもクラスをエクスポートしたいならCOMにすることだ。

341 ：仕様書無しさん：02/10/29 21:21

>>339
君が勉強不足だから。

342 ：仕様書無しさん：02/10/29 21:22

ポインタん(*´Д｀*)ﾊｧﾊｧ

343 ：仕様書無しさん：02/10/29 22:43

>>341
勉強不足は君。日本語の読解力をもっと付けなさい。

344 ：さっぱり解らん宿題教えてください：02/10/29 22:47

/*1秒ごとに0～99までの数値を画面に表示するプログラムを作成する。
数値は9ごとに改行し各数字の間隔は48ドット空けること*/

このプログラムに手を加えて（手直し）作ってください。お願いします
case WM_CREATE:
{
SetTimer(hWnd,1000,1000,NULL );
}
break;

case WM_TIMER:
{
HDC hdc;
char string[8];
wsprintf(string,"%d",suti);
TextOut(hdc,0,48,string,strlen(string) );
}
break;

345 ：仕様書無しさん：02/10/29 22:51

>>344
昨日より形になってるな。
どこの掲示板で教えてもらったんだよ。

346 ：仕様書無しさん：02/10/29 22:51

>>344
回答見積もり

前金１万円でどう？
振込み確認後１０分以内に回答するよ

347 ：sasame：02/10/29 22:51

>> 339
vector< vector<int> > a;
としましょう。コンパイラは>>を右シフトと思ってしまう。

348 ：仕様書無しさん：02/10/29 22:52

>>344
こういう明らかに宿題のやつが、無差別に書き込みまくるのって
最近多いな。

349 ：仕様書無しさん：02/10/29 22:57

>>348
何の為の宿題なんだと小一時間(略

350 ：339：02/10/29 22:57

>>347
あんがと。
でも、それはわかってるよ。
漏れの知りたいのは２重てんぷら>>とシフト>>が区別できない理由。
まともなコンパイラなら出来るでしょ。

351 ：仕様書無しさん：02/10/29 23:05

C++コンパイラはCPU馬鹿食いするくせに>>の区別もできません。
最悪です。

352 ：仕様書無しさん：02/10/29 23:30

Class1<Class2<int,5>>2>> a6;

353 ：仕様書無しさん：02/10/29 23:43

>>352
まともなコンパイラならそんなのコンパイルできて当然だろ。

354 ：仕様書無しさん：02/10/30 00:40

>>333
DLLっていうからUNIXじゃないだろうけど、UNIXだと
インターフェースはCにしておいた方が喜ばれるかも
しれない。

355 ：350：02/10/30 04:16

ネタか？
釣りか？

できねーに決まってんジャン。
X3J16調べろよ。

356 ：仕様書無しさん：02/10/30 10:00

>>355
352のイーブンは「C++のコンパイラはどれもまともじゃない」ということでわ

357 ：仕様書無しさん：02/10/30 10:12

>>355
仕様だとでも言いたいのか？
その仕様が腐ってるってんだろ。
明らかな欠陥なのに何でも仕様にしてしまうへなちょこPGの発想だな。

358 ： ◆qQ4COMPILE ：02/10/30 10:26

>>357　>>352の例はどうやって解釈する？

まあテンプレートパラメータに < > を使用したのは確かに間違い、
っていうか良くない仕様だったかも知らんな。

359 ：仕様書無しさん：02/10/30 11:45

>>350
こういう舌足らずのヤツが多いな。

「どうしてこうなんだ?」という質問に、
「仕様だから」という答えがあると、
「なぜそういう仕様なんだ」と言ってくる奴。

分かってるなら、最初から仕様にについての質問だって言えよ。
「どういう理由でこういう仕様になってるんだ?」みたいに。

360 ：仕様書無しさん：02/10/30 11:46

とにかくC++がややこしくてわかりにくい、という
ことだけは理解しますた。

361 ：仕様書無しさん：02/10/30 11:49

360 にとって C++ がややこしくてわかりにくい、という
ことだけは理解しますた。

362 ：360：02/10/30 12:02

>>361
そのとうりでつ。どうもでつ。

363 ：仕様書無しさん：02/10/30 12:19

>>359
そんなことしたら暇つぶしにも煽りにもならないぽん。
つまらんぽん。
ちみは２ｃｈを何など思ってるぽん？

364 ：361：02/10/30 12:22

>>362
ちなみに、漏れにとっても C++ はややこしくてわかりにくいでつ。

365 ：仕様書無しさん：02/10/30 12:44

>>363
あなたのクソ煽りはもっとつまらないにょん。
もっと上手に煽ってにょん。

366 ：仕様書無しさん：02/10/30 16:47

>>363
屑の掃き溜めで～す。

367 ：仕様書無しさん：02/10/30 18:03

荒れてきたな･･･

368 ：仕様書無しさん：02/10/30 18:11

的確な書き込みなだけになんとも言い様が無いけどな。

369 ：仕様書無しさん：02/10/30 19:23

OOPな記述がしやすく、可搬性があり、ある程度の速度が出る言語が他にない。
どいつか作って普及させろ。テンプレ遊びにゃもう飽きた。

370 ：仕様書無しさん：02/10/30 19:27

Shige召還の予感。

371 ：仕様書無しさん：02/10/30 19:46

＞＞３５７
仕様が無いよ

372 ：仕様書無しさん：02/10/30 19:54

>>369
自分が作れｳﾞｫｹ。

373 ：369：02/10/30 23:18

>>372
オレじゃ作っても普及させられないんじゃｳﾞｫｹ。
もっと気のキいたこといえねえのかｳﾞｫｹ。

374 ：すぷーん ◆spoonLv.3M ：02/10/30 23:43

(いろいろな意味で)必死だな(w

375 ：仕様書無しさん：02/10/30 23:51

>>333
C や Pascal や FORTRAN など、どんな言語からでもコールできるように
してあるだけでしょ。

376 ：仕様書無しさん：02/10/30 23:59

　　ｷｬﾊﾊﾊ
　 ∧＿∧　　／￣￣￣￣￣￣￣￣￣
　（　＾∀＾）＜　いまどき、OOPってハズカシ過ぎる。氏んでね。
　（つ ⊂ ）　＼＿＿＿＿＿＿＿＿＿
　 .）　）　）
　（_＿）＿）　　　　　（＾∀＾）ｹﾞﾗｹﾞﾗ（＾∀＾）ﾊｽﾞｶｼｰ（＾∀＾）ｹﾞﾗｹﾞﾗ

　　（＾∀＾）ｹﾞﾗｹﾞﾗ（＾∀＾）OOPだあ（＾∀＾）ｹﾞﾗｹﾞﾗ（＾∀＾）OOプー

（＾∀＾）ｹﾞﾗｹﾞﾗ（＾∀＾）ｷｬﾊﾊﾊ（＾∀＾）ｹﾞﾗｹﾞﾗ（＾∀＾）ホントにいるんだね

377 ：仕様書無しさん：02/10/31 08:03

いまどきテンプレート使えないC++プログラマなんてくずは死んでね
boostぐらいあたりまえだから。

378 ：仕様書無しさん：02/10/31 08:27

仕様が単純だったので、C++は放置しました。

379 ：仕様書無しさん：02/10/31 08:32

>>377
boostを仕事で使っている奴なんかほとんどいません。

380 ：仕様書無しさん　：02/10/31 08:54

仕事に必要ないからといって切り捨てるようなバカも死んでね

381 ：仕様書無しさん：02/10/31 09:18

>>377
boostを使えることをテンプレートを使えると言うのか？
ちみはアフォですか？

382 ：仕様書無しさん：02/10/31 10:48

滅んでください。
イージーに使う側には楽でいいです。
クラスつくって提供する側にとっては地獄な気がする。

383 ：自爆屋：02/10/31 11:16

んなごちゃごちゃ揉めてる暇あったら
素直にVB使えや、ｺﾞﾙｧ！

384 ：仕様書無しさん：02/10/31 11:18

C++って、鶴亀算で解ける問題をあえてx, yの方程式にして
解いてるような個人的イメージ。

385 ： ◆qQ4COMPILE ：02/10/31 11:24

つ･･･つるかめざん？

386 ：仕様書無しさん：02/10/31 11:25

Javaくそ

387 ：仕様書無しさん：02/10/31 11:28

>>385
鶴亀算＝なぜ答えが出るのか厳密に理屈がわかってなくても
　日常的直感だけでとりあえず答えが出せる

388 ：仕様書無しさん：02/10/31 11:31

CPUはPentium
OSはWindows
言語は、C++
みんな過去を大切にしてますね。

389 ：仕様書無しさん：02/10/31 11:49

388 は何を言いたいのかわからん。

390 ：仕様書無しさん：02/10/31 12:11

CPUはZ80
OSはCP/M
言語はBASIC
>>388よりもっと過去を大事にしてます

391 ：仕様書無しさん：02/10/31 12:13

【鶴亀算】

問：いまここに鶴と亀がたくさんいます。その頭を数えると合計で16個で、
　その足を数えると合計で46本でした。
　では、鶴と亀はそれぞれ何（羽/匹）ずついるのでしょう？

解法：いま鶴と亀がいっせいに片足を挙げたとすると、鶴は一本足、
　亀は二本足になり、地面についてる足の合計は半分の23本になる。
　この数から全部の頭数を引くと亀の数になるので、亀は23-16で
　7匹、頭数の合計から亀の数を引くと、鶴は16-7で9羽となる。

答：鶴9羽、亀7羽

// 若い世代は教育指導要領からはずれたから習ってないかもねー。

392 ：仕様書無しさん：02/10/31 12:17

かかかかかかかかかかか過去なんぞどうでもいいんじゃよぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉ！！！！！

393 ：仕様書無しさん：02/10/31 12:43

鶴亀算しらん。
俺、若い世代だったのか。

394 ：仕様書無しさん：02/10/31 12:52

>>392
今までの投資はなるべく長生きさせたいんですが。
servletくらいしか実用にならないJavaとかどうでもいいです。

395 ： ◆qQ4COMPILE ：02/10/31 12:53

>>391
（・∀・）ﾚﾝﾘﾂﾎﾃｰｼｷ？

396 ：仕様書無しさん：02/10/31 12:54

鶴亀算ってコンピュータで解くと結構難しいよね
行列計算いるっしょ

397 ：仕様書無しさん：02/10/31 12:58

> Ｃ++について言いたいことがあればどうぞ +++

氏ね

398 ：仕様書無しさん　：02/10/31 12:58

しらね、そんなの。
x + y = 16
2x + 4y = 46
-2x = -18
これで十分じゃん

399 ：仕様書無しさん：02/10/31 13:09

>>396
2×2の行列式の何処が難しいのれしょうか

400 ：396：02/10/31 13:11

角度とか

401 ：仕様書無しさん：02/10/31 13:16

> Ｃ++について言いたいことがあればどうぞ +++

愛してます。長生きして下さい。

402 ：仕様書無しさん：02/10/31 13:16

>>400
同意。

403 ：仕様書無しさん　：02/10/31 13:18

は？

404 ：仕様書無しさん：02/10/31 13:29

がんばれ～C#！。
たとえM$製でもC++よりまし。

405 ：仕様書無しさん：02/10/31 13:37

鶴亀算のたとえ、わかりやすいな。
鶴亀算＝VB、Delphi等、方程式＝C++ということで。

で、方程式が好き・得意な者はこう言って鶴亀算をバカにするわけだ。
「鶴亀算は他に応用がきかない」
「解法をいちいち覚えるのがめんどくさい」
「論理がわからなくても解けるので計算力や思考力が身につかない」
「そんなのはただの物語であって数学じゃない」
などなど・・・。

406 ：391：02/10/31 13:38

>>395
そうです。
>>398が書いてるとおり。

407 ：仕様書無しさん：02/10/31 13:43

>>405
> 鶴亀算＝VB、Delphi等、方程式＝C++ということで。

VBとDelphiを一緒にするな!

408 ：仕様書無しさん：02/10/31 13:46

そうだ、VB に失礼だ！！

409 ：仕様書無しさん：02/10/31 13:46

ここは、C++について言いたいことを言うスレです。
Microsoft Visual Studio の話しや、Delphi等の話しをするスレではありません。

ガキや子供はすっこんでろ！ぼけっ！

純粋にC++について語りましょう。

410 ：仕様書無しさん：02/10/31 13:52

持論援護な自作自演を久しぶりに見たよﾜﾗﾀ

411 ：仕様書無しさん：02/10/31 13:53

あ、鶴亀のレスのことね

412 ：仕様書無しさん：02/10/31 13:57

C++のコメントにつかわれる　「//」って、
最高に使いやすいね！

413 ：仕様書無しさん　：02/10/31 14:00

ケキョーク、中学生用の数学すら知らないバカは

ってやつですか？

414 ：仕様書無しさん：02/10/31 14:02

C++でよくつかわれる、「const」って、とてもいいね。
あれのおかげで何度助けられたことか。

C++最高！

415 ：仕様書無しさん：02/10/31 14:08

がんばれ～C#！。
たとえM$製でもC++よりまし。

416 ：仕様書無しさん：02/10/31 14:08

>>409
みんなC++の話をしてますよ。
あと「ガキや子供」って微妙に重言ですね。

417 ：仕様書無しさん：02/10/31 14:21

久しぶりに誰か数学の煽りスレ立てないかな

418 ：仕様書無しさん：02/10/31 14:22

>>414
言語に頼らないと記憶域の管理もできない素人さんですか？
可愛そうですね。

419 ：仕様書無しさん：02/10/31 14:24

>>414
はC++ユーザーを装ったC屋

420 ：仕様書無しさん：02/10/31 14:35

>>418
文書校正機能に頼らないと日本語の誤変換も防げない素人さんですか？
可哀想ですね。

421 ：仕様書無しさん：02/10/31 14:36

C にも const はあるし。

422 ：仕様書無しさん：02/10/31 14:36

>>420
釣りならいいけど、マジならなんと言って良いのかわからない…

423 ：仕様書無しさん：02/10/31 14:42

>>421
C++を覚えようとがんばったけど、
結局Cしかつかえない、厨房！

424 ：仕様書無しさん：02/10/31 14:43

>>416
>あと「ガキや子供」って微妙に重言ですね。
子供の頃、友人が「太ってる奴と痩せてる奴」という意味のことを
言おうとして、間違えて「ヤセとガリ」と言ってしまったのを
思い出しますた。

425 ：仕様書無しさん：02/10/31 14:50

雑談いんたーねっティーですか？

426 ：４１４：02/10/31 14:51

＞４１８
おいおい、その使い方はCの使い方だろ？
定数の代わりとなる使い方をするんだよ(w

もしや、学生か？
ちゃんと学校いけよ。

もし、プログラマだったら、かなり寒いな、いらねーな。

427 ：仕様書無しさん：02/10/31 14:51

あるところに無人島があって、そこに小さな家があります。
この家の扉はだれもいないのに勝手にとじたりしまったりします。
自動ドアでもなく、風もまったくありません。
どうしてでしょう？

というネタを思い出しますた。

428 ：仕様書無しさん：02/10/31 14:53

>>427
ちゃんと閉まっているから。

429 ：仕様書無しさん：02/10/31 14:59

>>428
速攻ﾏｼﾞﾚｽ・・・ﾂﾏﾝﾅｲﾖ

430 ：仕様書無しさん：02/10/31 15:04

はじめから閉まっていることを、勝手に閉じるとは言わない。

431 ：マジレス天使、名無しさん：02/10/31 15:10

はじめから閉まっていたのではなくて、
一度だけ閉まった事態のことをいっているのかなあ。
そして開くときはそれとなく、気が付いたら開いてたみたいな

432 ：仕様書無しさん：02/10/31 15:12

C言語落ちこぼれの414は……
窓際候補生？

433 ：仕様書無しさん：02/10/31 15:14

>>430
あほはっけん！！

開いたり閉じたりするものであれば、閉じた状態があるわけだから、
閉じる前の状態は関係ないよ。あんたばか？
プログラマ失格だな。

開いているとも、閉じているとも言えないドアで、
一生立ち往生してな。ばかプログラマ。

434 ：仕様書無しさん：02/10/31 15:14

>>430-431
マ板らしいといえばらしいが・・・
大人げないな。ｗ

435 ：仕様書無しさん：02/10/31 15:18

>>434
うるせー　ガキはすっこんでろっ！

436 ：仕様書無しさん：02/10/31 15:19

>>432
414はリストラ候補生だろ

437 ：仕様書無しさん：02/10/31 15:20

>>433
「勝手に」という言葉が意味不明。
また「閉じる」と「閉じている」は違う。
「閉じる」というのは開いているものがふさがるということをさす。

正確な日本語を使うならば
「この家の扉はだれもいないのに閉じています」と言うべき。
それでも「のに」という言葉の使い方に違和感が残る。

438 ：仕様書無しさん：02/10/31 15:23

　　こ　こ　は　一　体　何　の　話　を　し　て　る　ん　だ　・・・。

439 ：４１４：02/10/31 15:27

今月で、派遣の契約切れます。
みなさんいままでありがとう。
ほんと、さようなら。

ちなみに、次の仕事決まってません。
あしたから、どう暮らしていけばいいのか。。。

440 ：仕様書無しさん：02/10/31 15:29

>>439
精一杯>>414のふりをしてもバレバレですよ。

441 ：４１４：02/10/31 15:31

>>440
うるせー　ガキはすっこんでろっ！

442 ：仕様書無しさん：02/10/31 15:33

　　　,／＾ヽ‐一^＼
　　 /　＿_´_∀_｀＿)
　. |　//ノ/ ノノ＼）
　　|ﾊ|( |　∩　 ∩|)|　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　ヾ从ゝ＿▽＿从　　＜ >>414 そろそろ病院に行くよ。
　　　/丶 d　V bﾉ￣|⊃　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　｜ﾊ'＼A／ﾉ￣
　　 (___)_　　8 　 |
　　｜|^| |＿＿＿ヽ
　｢￣￣￣|||＿|
　Ｌ＿＿__」||_　|_
　　　　　|_＿_)＿)

443 ：仕様書無しさん：02/10/31 15:34

>>441
>>435のコピペですね。ネタが思いつきませんでしたか。

444 ：４１４：02/10/31 15:35

　　　　　　　　　　　(⌒＼　ﾉﾉﾉﾉ
　　　　　　　　　　　　＼ヽ( ﾟ∋ﾟ)
　　　　　　　　　　　　　(m　　　⌒＼
　　　　　　　　　　　　　　ﾉ　　　 / ／
　　　　　　　　　　　　　（　　 ∧ ∧
　　　　　　　　　　　ﾐヘ丿　∩Д｀　)　　← >>442
　　　　　　　　　　　 (ヽ＿ノゝ　＿ノ

445 ：仕様書無しさん：02/10/31 15:36

自作自演ウザイ

446 ：仕様書無しさん：02/10/31 15:37

うざ

447 ：４１４：02/10/31 15:37

>>443
．．．ｼｮﾎﾞ━（´･ω･｀）━（　´･ω）━（　　´･)━(　　　　)━（･｀　　）━（ω･｀　）━（´･ω･｀）━━ﾝ!!

448 ：仕様書無しさん：02/10/31 15:37

みんなｷｮｼﾞｿが優勝したからってそんな不機嫌にならない

449 ：仕様書無しさん：02/10/31 15:38

つーかさぁ。はじめからここって、3人しかいないじゃん。
あんたらばか？

450 ：仕様書無しさん：02/10/31 15:40

光と海と風

451 ：仕様書無しさん：02/10/31 15:40

一人目を自認していますが何か？

452 ：仕様書無しさん：02/10/31 15:47

一人目ﾜｹﾜｶﾗﾝ

453 ：仕様書無しさん：02/10/31 15:50

tu-ka　ですが何か？

454 ：仕様書無しさん：02/10/31 15:51

二人目を自認していますが何か？

455 ：仕様書無しさん：02/10/31 15:52

>>451と>>452は、自作自演なわけだが。何か？

456 ：仕様書無しさん：02/10/31 15:58

>>451と>>455は自演なわけだが。何か？

457 ：仕様書無しさん：02/10/31 15:59

友達が自殺しちゃった。マジでショック。

458 ：仕様書無しさん：02/10/31 16:00

いいかげんうざい。

459 ：仕様書無しさん：02/10/31 16:19

C++は最高。
C++が使えないのは最悪。仕事すんな。

460 ：仕様書無しさん：02/10/31 16:40

肩が凝ったわけだが、何か？

461 ：仕様書無しさん：02/10/31 16:41

見事な雑談いんたねてぃーですね

462 ：仕様書無しさん：02/10/31 17:25

>>459
C++が最高って言ってる理由は参照型変数ができたからだろ。
Cのポインタが理解できないのは最悪。仕事すんな。

463 ：仕様書無しさん：02/10/31 17:28

初期のころのC++はくそ以外の何者でもない。

464 ：仕様書無しさん：02/10/31 17:30

>>462
ハァ？(ﾟДﾟ)

465 ：仕様書無しさん：02/10/31 17:33

>>462
芸術的な釣りだな。ク、あんた光ってるぜ。

466 ：仕様書無しさん：02/10/31 17:43

>>465
釣られんなよ(ｗ

467 ：仕様書無しさん：02/10/31 17:47

　　　,／＾ヽ‐一^＼
　　 /　＿_´_∀_｀＿)
　. |　//ノ/ ノノ＼）
　　|ﾊ|( |　∩　 ∩|)|　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　ヾ从ゝ＿▽＿从　　＜ >>459 そろそろ * 恐怖症治しに病院に行くわよ。
　　　/丶 d　V bﾉ￣|⊃　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　｜ﾊ'＼A／ﾉ￣
　　 (___)_　　8 　 |
　　｜|^| |＿＿＿ヽ
　｢￣￣￣|||＿|
　Ｌ＿＿__」||_　|_

468 ：仕様書無しさん：02/10/31 17:54

もっとかわいい、理科たんｷﾎﾞﾝﾇ

469 ：仕様書無しさん：02/10/31 18:33

>>467
精神病院へお一人でどうぞ。

470 ：仕様書無しさん：02/10/31 19:41

　　　,／＾ヽ‐一^＼
　　 /　＿_´_∀_｀＿)
　. |　//ノ/ ノノ＼）
　　|ﾊ|( |　∩　 ∩|)|　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　ヾ从ゝ＿▽＿从　　＜ >>469 恐くなんかないわよ。一緒に病院いきましょ。
　　　/丶 d　V bﾉ￣|⊃　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　｜ﾊ'＼A／ﾉ￣
　　 (___)_　　8 　 |
　　｜|^| |＿＿＿ヽ
　｢￣￣￣|||＿|
　Ｌ＿＿__」||_　|_

471 ：仕様書無しさん：02/10/31 20:02

>>470
強がってないでさっさと行きなさいね。

472 ：仕様書無しさん：02/10/31 20:43

http://pc.2ch.net/test/read.cgi/linux/1035896117/l50
http://slashdot.jp/article.pl?sid=02/10/29/1244228&mode=thread

473 ：仕様書無しさん：02/10/31 21:17

　　　,／＾ヽ‐一^＼
　　 /　＿_´_∀_｀＿)
　. |　//ノ/ ノノ＼）
　　|ﾊ|( |　∩　 ∩|)|　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　ヾ从ゝ＿▽＿从　　＜ >>471 ｳﾌﾌﾌ…。初めてなのね。CAWAII。
　　　/丶 d　V bﾉ￣|⊃　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　｜ﾊ'＼A／ﾉ￣
　　 (___)_　　8 　 |
　　｜|^| |＿＿＿ヽ
　｢￣￣￣|||＿|
　Ｌ＿＿__」||_　|_

474 ：仕様書無しさん：02/10/31 21:21

　　　　　　　　　0Ｏ彡γ
　　　　　　　彡彡／＠ヾ　　　　　＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　　（__/ノﾉノﾉミヽ　　　／　
　　　　　　　|( |　∩　 ∩|)|　　＜　いっしょに病院いきましょう♪
　　　　　　　从ゝ＿▽___从　　　＼＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　／⌒┗━⌒､
　　　　　／　　┌───､ヽ
　　　　 ┗━'、　）り　かﾉ･┛
　　　 ( 　く》 └──-ｲ >　〉
　　　　＼　＼　　　 i　／
　　　　　 >　) 　　　 |く
　　　　 (_｀ノ　　　 !_〉
　　　　　ﾍ＿＿＿＿」
　　　　　 i´ 　｀Y´ 　.i
　　　　　　 |　　 ∥　　!
　　　　　 i､_＿,||､＿,l
　　　　　 !;;;;;;;;;;l !;;;;;;;l
　　　　　 {:::::::::j }:::::::j
　　　　　 f:::::::::i f:::::::j 　　

475 ：仕様書無しさん：02/10/31 21:27

結局石川はウンコするのかしないのか?

476 ：仕様書無しさん：02/10/31 21:31

pachinko no uchiawase nohohon nohohon

477 ：仕様書無しさん：02/10/31 21:37

>>474
http://mathworld.wolfram.com/EulerFormula.html

478 ：仕様書無しさん：02/10/31 21:39

りかたんとおいらー、りかたんとおいらー・・・

んー、深い繋がりがあるのですね。私には分からん

479 ：仕様書無しさん：02/10/31 21:40

石川はうんこしません。もー板では去年すでに結論がでています。
おなじ問題を蒸し返しては　　い　　け　　ま　　せ　　ん

480 ：仕様書無しさん：02/10/31 21:53

富山コンも仕事でいけねーよ・・・ﾊｧ・・・ﾘｶﾀﾝ・・・

481 ：仕様書無しさん：02/11/01 00:10

Ｃ++って分かりだした頃に、バージョンアップか、ＪａｖａやＣ＃へ。
結局、寿命の短かった言語だな。案外、Ｃ言語は健在。でも、ＧＵＩアプリからは、追い出されたな。

482 ：仕様書無しさん：02/11/01 00:24

C++

483 ：仕様書無しさん：02/11/01 14:04

>>479
そうでつか。
じゃあ腹の中にはウンコがｲﾊﾟｰｲ詰まってるンでつね？

484 ：仕様書無しさん：02/11/01 21:28

腹にウ○コ袋を下げていて、貯まってきたら取り外しまつ。

485 ：仕様書無しさん：02/11/02 00:58

だから石川にはウンコなんてものが存在しないんです。

486 ：仕様書無しさん：02/11/02 14:56

板違いだ。消えろモーヲタ。

487 ：仕様書無しさん：02/11/02 20:12

結論としては
　　C++はうんこ、
ということでよろしいか？

488 ：仕様書無しさん：02/11/02 20:44

C++は、消え逝くのみ。ばいばい！！

489 ：仕様書無しさん：02/11/02 20:51

そりゃよかったね。

490 ：仕様書無しさん：02/11/02 20:57

モーヲタが逆上

491 ：仕様書無しさん：02/11/02 20:57

private static transeind volatile synchronized final int a;

492 ：仕様書無しさん：02/11/02 21:17

C++は、消えるだけだ

493 ：仕様書無しさん：02/11/02 21:18

C++は、きえてくれ　delete [] C++;

494 ： ◆qQ4COMPILE ：02/11/02 21:23

C++はこれからだよう。

495 ：Hikky!：02/11/02 21:30

C++最高、と。

496 ：仕様書無しさん：02/11/02 21:35

C++は、うんこ～＝糞

497 ：仕様書無しさん：02/11/02 21:37

C++とガンプラは似ている。

498 ：すぷーん ◆spoonLv.3M ：02/11/02 22:46

>>497
そのココロは？

499 ：仕様書無しさん：02/11/02 22:47

C はブラジャー
C++ はエプロン
どちらも裸につける

500 ：仕様書無しさん：02/11/02 23:52

もう一度最初っから設計しなおしてください＞Ｃ＋＋

501 ：仕様書無しさん：02/11/03 00:38

設計しなおすときは変に省略した関数名を使わないようにしてね

502 ：仕様書無しさん：02/11/03 00:40

>>501
それは C++ じゃなくて C の事を言っているのか？

503 ：仕様書無しさん：02/11/03 07:13

>>501はC++に挫折したかわいそうなJava厨

Javaの長たらしい名前に慣れた厨から見れば、
なんでも「省略した」名前だろう。
こういう奴はC++使いを名乗っていても、
VectorだのStringだのと書いてばれる。

504 ：仕様書無しさん：02/11/03 08:13

>>503
#define Vector std::vector
#define String std::string
で万事 OK な罠

でもそれなら
#define CompareString strcmp
#define CopyString strcpy
で OK なような

505 ：仕様書無しさん：02/11/03 12:49

もう良いから
ほら、相互リンクしてやるからおとなしくしろよ
【JCL】メインフレーム万歳 Part2 【SUBMIT】
http://pc.2ch.net/test/read.cgi/prog/1033141207/

506 ：仕様書無しさん：02/11/03 13:48

>>499
意味わかりません。
電波表現は止めて下さい。

507 ：仕様書無しさん：02/11/03 17:45

main()
{
　inc C=0;
　C++;
　printf("%d\r\n",C);
}

508 ：仕様書無しさん：02/11/03 17:46

507はコンパイルエラー

509 ：仕様書無しさん：02/11/03 21:18

>>504
>#define CompareString strcmp
>#define CopyString strcpy

Javaにグローバル関数がないことを知らないらしいな。（ｗ
さらに言えば、メソッド名を大文字ではじめてるところでバレます。

510 ：499：02/11/04 08:42

レスついちゃったよ・・・
漏れも何故こんなの思い付いたか理解できないのに

511 ：４９９：02/11/04 12:55

Java厨からすれば、C++など
ブラの上から乳を揉むようなものだ

512 ：仕様書無しさん：02/11/04 16:20

>>503みたいなこと、おお威張りで言われてもなんとも
答えようがないよな。
「そうですか、そりゃよかったですね」と言ってほしいのだろうか？

513 ：仕様書無しさん：02/11/05 01:04

出た 0x0200 DQN
煽るほどでもないレスに煽ってるし

514 ：仕様書無しさん：02/11/05 11:30

　仕　様　が　複　雑　す　ぎ　！　！

　も　っ　と　簡　単　に　し　る　！　＞　Ｃ　＋　＋

515 ： ◆qQ4COMPILE ：02/11/05 11:44

>>514
（・∀・）ﾜｶﾀｶﾗｶｴﾚ!!

516 ：仕様書無しさん：02/11/05 12:00

複雑すぎるのは、C++の専売特許なのかもな
C++がうらでごそごそ何かやってて、メモリのコントロール
が出来ないというのは結構不安なものなんだよね。

いっそのこと、オプションでメモリのコントロールもユーザーが出来るように
すればいいのに

517 ：仕様書無しさん：02/11/05 13:15

Javaから入ったﾓﾉですが、
C++BuilderのAnsiStringは、JavaのStringのﾊﾟｸﾘですか？

Builderやら、Visualやら、いろいろ多すぎるので
ﾏﾙﾁﾌﾟﾗｯﾄﾌｫｰﾑなC++きぼんぬ
（片方のｿｰｽ、もう片方でｺﾝﾊﾟｲﾙ通らないんでしょ？）

518 ：仕様書無しさん：02/11/05 13:16

>JavaのStringのﾊﾟｸﾘですか？
ﾜﾗﾀ

519 ：仕様書無しさん：02/11/05 13:26

>>517
これネタか？

520 ：仕様書無しさん：02/11/05 13:27

C--ってないんですか？

521 ：仕様書無しさん：02/11/05 13:34

>>520
C#のことかな～？
音階的にも、Cより軽くなってます。
角度とか。

522 ：仕様書無しさん　：02/11/05 14:29

http://www.cminusminus.org/

523 ：仕様書無しさん：02/11/05 15:03

>>513=>>503 泣きながら必死

524 ：仕様書無しさん：02/11/05 15:22

499=513、!=503 ですが何か？

525 ：仕様書無しさん：02/11/05 15:55

漏れは!513、!503だが、

　　　　5　　2　　3　　必　　死　　だ　　な

526 ：仕様書無しさん：02/11/05 16:25

523は愛に飢えていますｗ

527 ：仕様書無しさん：02/11/05 16:55

C++の長所、理解してますか？

528 ：仕様書無しさん：02/11/05 17:54

はい！ template meta programming れす！

529 ：仕様書無しさん：02/11/05 18:58

>>527
メモリ管理能力落ちこぼれCプログラマでも使える。
ポインタ使用能力落ちこぼれCプログラマでも使える。
ですか？

530 ：仕様書無しさん：02/11/05 19:09

シヴィライゼーション３はおもしれーよー。おめーらもWinnyで落としてやるべき。
簡単に落とせるから。アップロードの帯域／ダウンロードの帯域：150[KB]／400[KB]
ぐらいあれば24時間もあれば手に入ります。

531 ：仕様書無しさん：02/11/06 02:19

>>530
ご報告お疲れ様でした。

532 ：仕様書無しさん：02/11/06 08:44

　*　真っ黒ｸﾛすけ

533 ：仕様書無しさん：02/11/06 09:02

　*　肛門

534 ：仕様書無しさん：02/11/06 11:34

となりのﾄﾄﾛのさつきの声優の声、
「私、声優やってます」
丸出し

535 ：仕様書無しさん：02/11/06 11:44

>>534
この人のことか？
http://sdb.noppo.com/noriko_h.htm

536 ：仕様書無しさん：02/11/06 11:45

>>534
あれが宮崎監督の好みなんだろう。きっと。

537 ：仕様書無しさん：02/11/06 11:51

>>534
宮崎監督がそのような声にしろと言っただけです。

538 ：仕様書無しさん：02/11/06 16:41

>>534
Ｃ++について言いたいことがあればどうぞ。
>>535
Ｃ++について言いたいことがあればどうぞ。
>>536
Ｃ++について言いたいことがあればどうぞ。
>>537
Ｃ++について言いたいことがあればどうぞ。

539 ：仕様書無しさん：02/11/06 16:53

>>538
Ｃ++について言いたいことがあればどうぞ。

540 ：仕様書無しさん：02/11/06 17:01

>C++

愛してます。

541 ：仕様書無しさん：02/11/06 17:07

>>539
Ｃ++について言いたいことがあればどうぞ。
>>540
(・∀・)ﾀｲｰﾎ
>>541
Ｃ++について言いたいことがあればどうぞ。
>>542
Ｃ++について言いたいことがあればどうぞ。

542 ：仕様書無しさん：02/11/06 17:57

>>541
要するに「言いたいことは書くな」と言いたいわけね。

543 ：仕様書無しさん：02/11/06 19:16

>>542
場が適切なら構わないんじゃないか？

544 ：仕様書無しさん：02/11/06 21:53

OS作るならSYSL最強。
CもC++も糞言語。

545 ：530：02/11/06 22:21

Civ3で世界制覇Vol.12～秋の夜長に世界制覇～
http://game2.2ch.net/test/read.cgi/game/1034956958/459-465n
------------------------------------------------------------------
459 ：名無しさんの野望：02/11/05 16:41 ID:0BxDZiu+
完全日本語版をAmazonで買おうと思うんだけど、ココより安いトコってあるかな？
------------------------------------------------------------------
460 ：名無しさんの野望：02/11/05 16:57 ID:1UPkfo+X
>>459
（　・∀・）＜WinMX
------------------------------------------------------------------
465 ：名無しさんの野望：02/11/05 20:19 ID:/psHt1/U
ヴァカは放置しるー

>460
timekill入ってるからヤメトケー(698.516.973)。着火させられたらアボーンダヨ。
------------------------------------------------------------------
マジか…。俺は2002/10/22からやっているんですが…。今のところなんとも無い
んですよねえ…。サイズもぴったりの698,516,973ですが…。しっかしこえー。
最悪の事態を想定してバックアップ作業に取り掛かろう…。

546 ：仕様書無しさん：02/11/06 22:39

>>545
ご報告お疲れ様でした。

547 ：仕様書無しさん：02/11/07 12:06

STLがあればnewとdeleteはマジでいらん！

＃STLの中でnew,deleteしてるからね。

548 ： ◆qQ4COMPILE ：02/11/07 12:10

>>547（・∀・）？

549 ：仕様書無しさん：02/11/07 14:26

>>547
(ﾟДﾟ)ﾊｧ?

550 ：仕様書無しさん：02/11/07 15:11

どうみてもネタじゃん。放置しろよ。

551 ：仕様書無しさん：02/11/07 15:19

ネタスレなのにネタ放置と言われても・・・。

552 ：仕様書無しさん：02/11/08 00:11

C++によるプログラミング≠OOP

553 ：仕様書無しさん：02/11/08 00:45

Javaによるプログラミング≠OOP

554 ：仕様書無しさん：02/11/09 04:29

C++によるプログラミング＝(ﾟдﾟ)ｳﾏ-

555 ：仕様書無しさん：02/11/09 16:36

>>554がいいこと言った。

556 ：530：02/11/10 21:49

天帝クリア二回目。勝ちパターンも分かってきたし、ここいらで止めるかなあ。

557 ：仕様書無しさん：02/11/10 21:55

Ｃ＋＋なんか、だいっきらいだ～～～！！

558 ：仕様書無しさん：02/11/11 00:39

>>556
ご報告お疲れ様でした。

559 ：仕様書無しさん：02/11/11 16:16

Javaによるプログラミング＝(ﾟдﾟ)ｳﾏ-

560 ： ◆qQ4COMPILE ：02/11/11 16:30

Javaによるプログラミング＝(ﾟДﾟ)ﾊｧ?

561 ：仕様書無しさん：02/11/11 21:14

Javaによるハミング＝（*ﾟーﾟ）ﾗﾗﾗ♪

562 ：仕様書無しさん：02/11/11 22:07

C++って素敵だね。C++ Primerを楽しく読んでいます。
でも、実際プログラムを作る気にはならないなあ。
オブジェクト志向をこうやって実装するのかあ、ってのを満喫した
だけでおなかいっぱい。

563 ：仕様書無しさん：02/11/11 22:50

>>562 貴様！学生だな！？
　　　　∧ ∧_
　　　_(,,ﾟДﾟ)ヾ＿＿__　　　　　　　　　　　　　　　　　　∧∧
　　　 | ∨/|￣　　 < |つ||━━━━━━　　　　　　　(ﾟдﾟ,,)
　　 i | //　|　 i_　 < |　　　　　　　　　　　　　　　　　　 |つつ　　
　 ○|||//. 　| 　 |￣￣　　　　　　　　　　　　　　　　 @|　　|
　　 | ||=∞=|　　 |　　　　　　　　　　　　　　　　　　　　 ∪∪
　　l_|　 i　　|＿＿|
　/ 　　|　　　ヽ
　L＿＿⊥＿＿_」
　 /Ｙ_ｌ　　〈_Ｙヽ

564 ：仕様書無しさん：02/11/12 01:12

オブジェクト志向、ってなんか威勢のいい言葉だな。

565 ：仕様書無しさん：02/11/12 12:53

>>562
ネタであることを祈る。

566 ：仕様書無しさん：02/11/12 21:02

>>565
ネタじゃありません。正直な感想です。

567 ：仕様書無しさん：02/11/13 01:15

俺なんか未だにオブジェクト試行ずら。

568 ：仕様書無しさん：02/11/13 08:17

オブジェクト嗜好・・・

569 ：仕様書無しさん：02/11/13 16:29

クラス名に１時間悩んでるけどいいのが思いつかん

570 ：仕様書無しさん：02/11/13 17:00

class1、class2 にしる。

571 ：569：02/11/13 17:02

>>570
ラジャー！

572 ：570：02/11/13 17:13

>>571
マジですか・・・（；´Д｀）

573 ：仕様書無しさん：02/11/13 17:26

cllaass
cclasss
clllass
ccclaas
おすすめ。

574 ：仕様書無しさん：02/11/13 19:17

>>573

575 ：仕様書無しさん：02/11/13 19:39

　　　　　　　　　　0Ｏ彡γ
　　　　　　　　　彡彡／＠ヾ
　　　　　　　　　（__/ノﾉノﾉミヽ
　　　　　　　　 |( |　∩　 ∩|)|　　　／￣￣￣￣￣
　　　　　　　　从ゝ＿ー＿从　＜　　うんちー
　　　　　　　　／）)ヽ----イ（　＼　＼＿＿＿＿＿
　　　　　　　　/　/（　　　　　）ヽ　＼　　　　　._________
　　　　　　　. （ ξ. ）ミ　　彡　(　/ξ.. ) 　　　..／　　／_|
　　　　　　　 ./ |　 |ヽ､______,／　|　 |　　　　(￣/￣◎ﾉ
　　　　　 .　 | 　|　 |　　　,　　　 .|　 .|　　　　 W￣￣
　　　　　　　＼|￣ |　 ((ﾟ)) 　　/|.￣ |
　　　　　　　　　|　　|＿)*(＿／. |　　.|　　　　ﾌﾞﾘッ!
　　　　　　　　（　⌒）　∥　　　（　⌒）　　　　　　ﾌﾞﾘﾌﾞﾘ
￣￣￣￣￣￣￣￣　.人　　　　￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　　（＿＿）
　　　　　　　　　　（＿＿＿＿）
　　　　　　　　　（＿＿＿＿＿＿）

576 ：仕様書無しさん：02/11/13 20:56

C++は血塗られた道。

577 ：仕様書無しさん：02/11/13 22:24

>>575
ついに頭イカれたか？

578 ：仕様書無しさん：02/11/15 03:56

　 ∧＿∧ 　　
　（　´∀｀）＜　ぬるぽ

579 ：仕様書無しさん：02/11/15 17:23

あふぇ

580 ：仕様書無しさん：02/11/15 17:32

え？C++使えん？
あそ。帰っていいよ。
ん。そ。も、いいから。
そそそ。じゃ。な。

581 ：仕様書無しさん：02/11/15 17:51

　（　・∀・）　　　|　|　ｶﾞｯ
　と　　　　）　　 |　|
　　Ｙ　/ノ　　　人
　　　 /　）　　 < 　>__Λ∩
　＿/し'　／／. Ｖ｀Д´）/ ←>>578
　（＿フ彡　　　　　　　/

582 ：仕様書無しさん：02/11/20 08:51

サーバサイドはＣ＋＋のみで、Ｗｅｂサイト作ってみてください。

583 ：仕様書無しさん：02/11/20 14:44

わかりました、サーバサイドはC++のみで新しい言語を実装してWebサイトを作ります。

584 ：仕様書無しさん：02/11/20 15:03

♪　　　　　　　　　　♪　　　　　　　　　♪
　♪　∧∧　 ∧∧　　∧∧　　∧∧♪　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　( ﾟДﾟ)　( ﾟДﾟ)　.( ﾟДﾟ)　 ( ﾟДﾟ)　　＜　カステラ一番　電波は２ちゃん
　　.⊂　　つ⊂　　つ⊂　　つ⊂　　つ　　 |　３時の駄スレは晒しage～♪
　～（つﾉ～（つﾉ～（つﾉ～（つﾉ　　 .　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　（/　　　（/　　　（/　　　（/

585 ：仕様書無しさん：02/11/20 15:38

C?++ コンパイラは C++ のみで作ってください。

586 ：仕様書無しさん：02/11/20 16:02

I understand.

587 ：仕様書無しさん：02/11/20 16:29

C?++ コンパイラって何だろう・・・。凄そうだけど。

588 ：仕様書無しさん：02/11/20 17:39

>>587
正規表現だろ。C#++とか。

589 ：仕様書無しさん：02/11/20 21:47

++ or C++ ？

590 ：仕様書無しさん：02/11/21 03:18

Do C++, or die.

591 ：530：02/11/21 22:59

例：都市の商業収入 40・汚職 10[%]・配分は科学に 5・図書館と大学と研究施設とコペルニ
　　クスの天文台とニュートンの学士院と SETI 計画がある場合の科学研究収入
　　　都市の商業収入＝ 40
　　　汚職を考慮＝ 40 × 0.9 = 36
　　　配分を考慮＝ 36 × 5 ／ 10 = 18
　　　図書館と大学と研究施設の増加分＝ 18 × 1.5 ＝ 27
　　　コペルニクスの天文台の増加分＝ 18 × 1 ＝ 18
　　　ニュートンの学士院の増加分＝ 18 × 1 ＝ 18
　　　SETI 計画の増加分＝ 18 × 1 ＝ 18
　　　最終的な科学研究収入＝ 18 ＋ 27 ＋ 18 ＋ 18 ＋ 18 ＝ 99

592 ：仕様書無しさん：02/11/22 10:42

ワイルドカードと正規表現は違う。

593 ：仕様書無しさん：02/11/22 13:20

ワイルドなエッチと正攻法四十八手とはわけが違う

594 ：仕様書無しさん：02/11/22 17:02

性器表現？

595 ：仕様書無しさん：02/11/22 19:37

関西３文字
関東４文字

596 ：仕様書無しさん：02/11/22 19:43

めことまんこ

597 ：仕様書無しさん：02/11/22 20:52

めこと FORTRAN

598 ：仕様書無しさん：02/12/01 09:37

C++によるプログラミング＝(ﾟдﾟ)ｱﾗｰ

599 ：仕様書無しさん：02/12/01 10:41

C++は唯一神というわけか。

600 ：仕様書無しさん：02/12/01 13:17

最近C++の勉強してるんですが（独習C++）
ソース（本の通りに打ったもの）によってはVC++ではコンパイルで警告出て、実行するとエラーで終了してしまうのに
bcc32だとすんなりコンパイル通って、きちんと実行できるということが何度かありました。
Cの時はそういう事態に直面したことがないので少し戸惑っています。
よくあることなんでしょうか？
実際に開発に携わってる人たちってどうしてるんですか？いくつかコンパイラを使い分けてるとか。

601 ：仕様書無しさん：02/12/01 13:30

で、VCで警告やエラーになるソースってどれよ？

602 ：仕様書無しさん：02/12/01 13:30

C++ﾏﾝｾｰ
ついでに01130ｹﾞｯﾄｰ

603 ：602：02/12/01 13:31

　　 ||　　　　　
　∧||∧　　
（　 ⌒ ヽ
　∪　　ﾉ　
　　∪∪

604 ：仕様書無しさん：02/12/01 13:33

ANSI C++ に100％準拠してる処理系って何があるの?

605 ：仕様書無しさん：02/12/01 13:37

ISOとANSIじゃ何が違うのかな？

606 ：仕様書無しさん：02/12/01 17:59

ISOとUSOじゃ何が違うのかな？

607 ：仕様書無しさん：02/12/01 18:33

>>600
VC++ は標準から外れてるからねぇ。(.NET ではどうか知らないけど)

608 ：仕様書無しさん：02/12/01 18:43

Microsoft の言によると、準拠律 90% だそうだけど。

609 ： ◆qQ4COMPILE ：02/12/02 09:58

なるほど、１０分の１は独自仕様なわけか･･･

なにをもって率計算するのか良くわからんが。

610 ：仕様書無しさん：02/12/02 15:53

(･∀･) ◆4compile!

611 ：仕様書無しさん：02/12/02 16:00

蒸着！！

612 ： ◆qQ4COMPILE ：02/12/02 16:24

｡･ﾟ･(ﾉД`)･ﾟ･｡

613 ：仕様書無しさん：02/12/02 17:11

>609-612
ﾜﾗﾀ

614 ：仕様書無しさん：02/12/04 07:35

>>604

　準拠したら、コマンドライン処理しかできないのでは？
　Windowsなど、拡張Ｃ/拡張Ｃ++/拡張ＢＡＳＩＣ/拡張ＰＡＳＣＡＬ

615 ：仕様書無しさん：02/12/04 07:44

MS拡張を無効にするオプションはあるし、それさえ使えば
.NETのC++コンパイラはかなり準拠できてると思うが・・・。

616 ：仕様書無しさん：02/12/04 07:47

>>607
どこがかわかってるか？

>>614
準拠した範囲だけだとGUI処理がめんどくさいだけ。できないことはない。
もちろんC標準ライブラリだけではコマンドライン処理しかできないが。

617 ：仕様書無しさん：02/12/04 08:14

MSのC++拡張の中には、
標準化してほしいと思うくらい便利な機能が山ほどあるけどな。

COM関連とか、managed C++。
でも標準化委員会みたいなところからは嫌われそうな機能だから
標準化はされないと思うけど。

618 ：仕様書無しさん：02/12/04 08:19

>>614
“標準に準拠する”ことと、“独自の API やクラスライブラリを使用する”ことは
背反しないよ。

>>616
俺がそれを判っているかどうかが関係あるのか？

一番目に付くのは

　　for (int i=0; ...)

の i が for の外でも有効になる件だな。マクロで逃げてるけど。
あとはテンプレート廻りか。内部エラーで VC++ こけると萎える。

619 ：仕様書無しさん：02/12/04 08:21

MSのやることやつけるものってまちがいはないんだよね。

620 ：仕様書無しさん：02/12/04 08:23

そんな長い関数つくんなよ

621 ：仕様書無しさん：02/12/04 08:58

>>618 .NETのC++はその辺のスコープを標準に準拠させることができるよ。

622 ：仕様書無しさん：02/12/04 13:09

>>618
昔のANSIはスコープがfor文のブロック外に及ぶことになってたよ。
最新はブロック内だけど…
なので、どっちもANSI準拠。

623 ： ◆qQ4COMPILE ：02/12/04 13:47

>>622
ようは古いわけよね。
VC6は４年も前のコンパイラだし。

624 ：仕様書無しさん：02/12/04 14:37

国際標準!

625 ：仕様書無しさん：02/12/04 14:52

>COM関連とか、managed C++。
>でも標準化委員会みたいなところからは嫌われそうな機能だから
>標準化はされないと思うけど。

この発言から勘違い臭を嗅ぎ取るのは私だけでしょうか？

626 ：仕様書無しさん：02/12/04 14:54

え？何か勘違いしてると思うか？
便利だけど標準化されない拡張だろ？

627 ：仕様書無しさん：02/12/04 14:59

C++にGCを使えるオプションがついたら、迷わずC++使い続けるが。

そゆ意味でmanaged C++ はえらい。マジでえらい。
ただ、.NET Framework必須なのがやな感じだけど。

628 ：仕様書無しさん：02/12/04 15:09

>>627
boost知らないの？？

629 ：仕様書無しさん：02/12/04 15:11

boostはただの拡張テンプレートでしょ。

managed C++はコンパイラそのものがGCに対応している。
同じ水準で語られちゃ困るぜｗ

630 ：仕様書無しさん：02/12/04 15:26

GC付けたら性能悪くなるじゃん？
デメリットが一つもないならあったほうがいいと思われ。

631 ：仕様書無しさん：02/12/04 15:48

重要なのは、GCの使用をこちらが自由に選択できるところ
なんだけどな。

パフォーマンス重視の開発はGCなしで、
開発効率重視の開発はGCありってのはなかなかいいよ。
意味があるかはわからんが、両方のコードを混ぜることもできるし。

そういった点でVC++.NETは最強かもしれんと思っている今日このごろ。
こういう機能が異端扱いされるのはちょっともったいないね。

632 ： ◆qQ4COMPILE ：02/12/04 16:18

そうそう、まなげどはいいっぽい。
__GCのクラスのオブジェクトは
自分でdeleteすることもでき、ほっといたらGCが削除してくれるらしい。
ぶつうにスタックにおくこともできるし。

633 ：仕様書無しさん：02/12/04 16:33

>>629
テンプレートだろうとGCだろうとプログラミングする側から見たらいっしょじゃん。
それだけの理由でポータビリティのないmanaged C++はえらいといか言われても
ちょっと・・・。

634 ：仕様書無しさん：02/12/04 16:37

>>633
「いっしょ」じゃないだろ？じっくり吟味したか？
むしろ同一視できちゃうのは問題のような。
吟味が足りてないとしか思えない。

635 ：仕様書無しさん：02/12/04 16:45

>>634
どう違うの？
インスタンスの削除をプログラマが気にしなくていいって意味じゃ同じような気がしますが。

（煽ってるわけじゃないです。マジご教授ください）

636 ：仕様書無しさん：02/12/04 16:50

templateってC++の？

637 ： ◆qQ4COMPILE ：02/12/04 17:11

>>635
>インスタンスの削除をプログラマが気にしなくていいって意味じゃ同じような気がしますが。
確かにそういう見方だと同じかも知らんが、いろいろ違う。
っていうか、もうちょっと便利。

ポインタ側でどうこうするのでなくて、
オブジェクトのほうをコンパイラがちゃんと回収してくれる。

638 ：仕様書無しさん：02/12/04 17:13

コンパイラが、オブジェクトの所在に応じて最適化できるところが
コンパイラサポートの優位点です。>>635

テンプレートや外部ライブラリによるサポートではそれはできません。

639 ：仕様書無しさん：02/12/04 17:17

>っていうか、もうちょっと便利。

そのもうちょっと便利な部分を教えて。

参照カウント付きスマートポインタを使えば　GCは全く必要ないって思ってので
ちょっと意外。

640 ：仕様書無しさん：02/12/04 17:24

循環参照

641 ： ◆qQ4COMPILE ：02/12/04 17:43

まず、>>640さんののいうように、参照カウンタだと循環参照を開放できない。
A が B を、B が A を参照してて、ABともに他からは参照されてないとき
それが削除されない。
GCなら削除できる。

次、ポインタがあくまで生のポインタ(first class)であること。
// extention * だけど、コンパイラは生ポインタと同じサポートをしてくれる。

スタック上とヒープ上の両方のオブジェクトを同じようにポインタで受けられるし、
継承構造に沿った正確なアップキャストもしてくれる。

642 ：仕様書無しさん：02/12/04 19:02

0.05 秒で蒸着できる。

643 ：仕様書無しさん：02/12/04 19:52

boostのことを理解してたら、コンパイラサポートがどれほど
有利かなんて、言うまでもなく理解できるだろう。

あと、コンパイラサポートのもう一つの利点を挙げるなら、
コンパイラが進化する分野がさらに広がったというところかな。
最適化の面などで。

boostはあくまでテンプレートライブラリであって、
コンパイラの進歩にはさほど利するところがない。

644 ：仕様書無しさん：02/12/04 19:59

boostより簡潔に書ける。

645 ：仕様書無しさん：02/12/04 19:59

デバッガで追跡する際に、テンプレートの奥に入り込む回数が少ない。

646 ：仕様書無しさん：02/12/04 20:03

もちろん、標準ではないのでboostからmanaged C++に移れと
薦めはしません。
ただ、コードを書く人にとってメリットがないと考えているなら
それは誤りだ、と主張しておきますね。

ではでは。帰ります。

647 ：仕様書無しさん：02/12/04 20:04

(ﾟдﾟ)ｳﾏ- スレから誘導されてきた人は正直に手を挙げて。

648 ：仕様書無しさん：02/12/04 20:06

C++ (ﾟдﾟ)ｳﾏ-

649 ：仕様書無しさん：02/12/04 20:08

テンプレート・・・コードサイズが膨れ上がる。
個人的には使用するときにちょこちょこ書かないといけないのが嫌。

650 ： ◆qQ4COMPILE ：02/12/04 20:10

>>645
(・∀・) ｲｲ!!

651 ：仕様書無しさん：02/12/04 20:17

managed C++は　C#に比べて何がいいの？
*とか->とか::とか使い分けるのめんどくさいぞ

652 ：仕様書無しさん：02/12/04 20:22

>>651
過去の遺産が生かせる・・・かもしれない。
VBに対するVB.NET、Javaに対するJ#みたいな位置付けでしょ。

653 ：仕様書無しさん：02/12/04 21:27

boost って、C++の素晴らしさと共にC++の限界を僕らに知らしめているんだよ。

654 ：仕様書無しさん：02/12/04 21:29

C#は managedしか使えない VC++ だと思われ。
VC++の最狂の利点はこれらのコードの混在が可能なところ。

655 ：仕様書無しさん：02/12/04 21:38

でも　C#のほうがずっときれいにプログラミングできるよね？

656 ：仕様書無しさん：02/12/04 21:38

managedコードオンリーならC#が環境への親和性が最もあるね。
それは間違いなさそう。

いつも、どこでもいわれてることだけど、使い分けが肝心。

657 ：仕様書無しさん：02/12/04 21:41

managedコードとnativeコードの混在が有益か、
nativeコードの速度が必要か、
C#よりC++に馴染んでいるか、
過去の資産を遣いたいか・・・・。

このあたりがC++を選ぶ理由になると思いますが。
あと、比較的単純なベンチマークですら、
C#はmanaged C++に負けることが多いから・・・・。

658 ：仕様書無しさん：02/12/04 21:43

正直言うと、デリゲートをネイティブサポートしているC#は美味しい。
使いたい。でも漏れの仕事ではC++の速度が必要だからだめだったりする。

659 ：仕様書無しさん：02/12/04 23:04

C# -> C or C++へのトランスレータ書け。

660 ：仕様書無しさん：02/12/04 23:24

cflow の C++ 版みたいなソフトってない？

661 ：仕様書無しさん：02/12/04 23:50

>>660
コレ？
http://www.cc.fuk.kindai.ac.jp/doc_link/Ja_JP/a_doc_lib/cmds/aixcmds1/cflow.htm

662 ：仕様書無しさん：02/12/05 07:59

>>659 それは美しくないかも。手間もかかるし。

663 ：仕様書無しさん：02/12/05 20:11

亀レスだが、

boost と managed C++ の差が理解できない奴って、
Cで十分だからと言ってC++を理解しない年寄りと、思考回路が同じだよ。
C++とC#の関係においても同じことが言える。

使うかどうかは別問題だが、それぞれの長所・短所くらいは理解しとけや。

664 ：仕様書無しさん：02/12/05 20:32

つまりC#は要らなくて、VBとC++だけあればいいってことだね。
今までと激しく同じ（・∀・）ｲｲ！！

665 ：仕様書無しさん：02/12/05 21:12

C++ﾏﾝｾ!
さーてC++コンパイラでも作るか。

666 ：仕様書無しさん：02/12/05 22:20

>>662
おめーにVC++を上回るオプティマイザが書けるのかｳﾞｫｹ。

667 ：仕様書無しさん：02/12/06 02:24

>>666 へー。そういう意味に取るんだ。
お前の友達は大変そうだなｗ

668 ：仕様書無しさん：02/12/06 02:30

>>666
C#⇒C/C++のトランスレータ作成って、
大体自分でやったこともないんだろ？自分でやってから言えよな。

C#が持っていてC++が持っていない機能をコンバータに実装すること
考えたら、途方もないとは思わないのだろうかｗ
そっちのほうが効率良いのなら、ハナからMSはその機能を実装すると
思われ。

ちなみに、普通のC++じゃなく、ただのmanaged C++ にコンバートする
くらいなら、C#のままビルドしてもいいじゃねーかよ。

669 ：仕様書無しさん：02/12/06 02:49

つうか、C#とC++のコンパイラってある程度のところから
コード共有してるよな？？

670 ：仕様書無しさん：02/12/06 03:19

>C#⇒C/C++のトランスレータ作成って、
>大体自分でやったこともないんだろ？自分でやってから言えよな。

んで？　おまえはやったことあんの？　そのトランスレータの作成を

>C#が持っていてC++が持っていない機能をコンバータに実装すること
>考えたら、途方もないとは思わないのだろうかｗ
>そっちのほうが効率良いのなら、ハナからMSはその機能を実装すると
>思われ。

まさか効率の良し悪しでC#が出来たと？
Sunに訴えられてムカついただけという世間一般の意見は無視ですか？

>ちなみに、普通のC++じゃなく、ただのmanaged C++ にコンバートする
>くらいなら、C#のままビルドしてもいいじゃねーかよ。

（　´_ゝ`）ﾌｰﾝ
　　つ　　ま　　り　　トランスレータの作成どころか、そんなことすら妄想で語ってたんだ（ぷ

671 ：仕様書無しさん：02/12/06 09:28

警報が鳴っています

672 ：仕様書無しさん：02/12/06 10:23

>>670 お前程度低いなぁ。
馬鹿と無知の混同攻撃でつか？

673 ：仕様書無しさん：02/12/06 10:27

折角だから格好悪く煽りレスしてみよう。

＞んで？　おまえはやったことあんの？　そのトランスレータの作成を

最初から>>668はそれが無意味だと主張しているよ。
無意味なことはやるわけねーじゃん。

＞Sunに訴えられてムカついただけという世間一般の意見は無視ですか？

それはJ#でつなｗ

＞　　つ　　ま　　り　　トランスレータの作成どころか、そんなことすら妄想で語ってたんだ（ぷ

トランスレータを作るのがｲｲって言ったのは>>659で、
それに反論したのは>>662で、
わけのわからない煽りをはじめたのは>>666で、
電波ゆんゆんしてるのが>>670ですが何か。

トランスレータ作成なんて無意味だから普通しないよなぁ。ｗ
君はしっかり作ってくれ。アセンブラからC++のトランスレータとか、
VBからC++のトランスレータとか。

674 ：仕様書無しさん：02/12/06 10:30

>>667
複数の意味でとられるような書き方をするお前が馬鹿。

>>668
馬鹿でつか？コンパイラの原理くらい勉強してから書けよ。阿呆。

675 ：仕様書無しさん：02/12/06 10:33

>>674 おまいは勉強したのかい？ｗ

676 ：仕様書無しさん：02/12/06 10:36

変なのが居る（・∀・）！！

677 ：仕様書無しさん：02/12/06 10:42

自分の能力で実現できないこと＝必要のないこと、と思い込みたい
３流PGがいるのはこのスレッドでつか？
C# -> C++トランスレータごとき、さくっと書けないPGっていったい
何のために生きてるの？死んだ方が良いんじゃないの？

678 ：仕様書無しさん：02/12/06 10:45

なんだ、>>677はC#使いこなしてないんだな。
C++でデリゲートとかGCはどうする？
あれが簡単だって言うのかい？
マジなはなしとして。

あと、話の流れとして、managed C++と標準C++は区別しろよ。
C++と書いたら標準C++な。

679 ：仕様書無しさん：02/12/06 10:48

＞何のために生きてるの？死んだ方が良いんじゃないの？

この辺に冬厨のにおいを感じます。
そろそろ季節ですかねぇ。

680 ：673：02/12/06 10:50

>>677
＞C# -> C++トランスレータごとき、さくっと書けないPGっていったい
＞何のために生きてるの？死んだ方が良いんじゃないの？

少なくとも、トランスレータを書くためではないことは間違いないな～ｗ

681 ：仕様書無しさん：02/12/06 10:53

>>677は今ごろデリゲートとGCの意味を調べているところと見た。

682 ：678：02/12/06 10:57

ついでに言うと、C#とC++のトランスレータを書くためには、
はるかヘッダの奥深くまで変換しないとだめなわけで、
それを簡単とかいうｱﾌｫがいたら見てみたいわけですよ。漏れは。

683 ：682：02/12/06 11:01

ヘッダ、っつーか using の中な。

684 ：仕様書無しさん：02/12/06 11:03

using はともかく、#include を展開するのは別に何も難しくないと思う。

685 ：仕様書無しさん：02/12/06 11:10

そこが簡単でも、
C#->C++のトランスレータを書く上では何ら助けに
ならないと思われ。

686 ：仕様書無しさん：02/12/06 11:21

usingとGCとデリゲート以外にも、
サイズ不定の多次元配列とかどうするつもりなんだろう。
まさか全部vectorのネストにするつもりじゃないだろうなｗ

687 ：仕様書無しさん：02/12/06 11:27

C#で書けることをわざわざC++に直す必要あるのか？

688 ：仕様書無しさん：02/12/06 11:27

>>677反撃食らって引込んでるの（・∀・）ｶｺﾜﾙｲ!!

689 ：仕様書無しさん：02/12/06 11:29

>>687
ないない。全くない。

690 ：仕様書無しさん：02/12/06 13:24

NullPointerException を「ぬるぽ」と呼ばない理由があるのか？

691 ：仕様書無しさん：02/12/06 14:03

>>677 おまいがサクッと書いたトランスレータをどこかにうｐしる！！

692 ：仕様書無しさん：02/12/06 15:55

>>691
sed 's/C#/C++/g'

693 ：仕様書無しさん：02/12/06 15:59

>>692 いまいち。もーすこしおもろいのをｷﾎﾞﾝﾇ

694 ：仕様書無しさん：02/12/06 16:26

sedが使えるだけでじゅーーーーぶん偉い。

695 ：仕様書無しさん：02/12/06 16:58

rm -rf /

696 ：仕様書無しさん：02/12/06 17:22

>>695
ちっとも面白くない。

697 ：仕様書無しさん：02/12/06 17:24

sedだけで偉いの？マジ？

698 ：仕様書無しさん：02/12/06 18:41

ls -R /

699 ：仕様書無しさん：02/12/06 19:42

>>698
だから、それと C#→C++ トランスレータに何の関係があるんだよ。

700 ：仕様書無しさん：02/12/06 20:01

GetKiriban(700);

701 ：仕様書無しさん：02/12/06 20:14

>>700
失格。

702 ：仕様書無しさん：02/12/06 20:58

Boolean IsKiriban(int num)
{
if(num%100==0) return(true);
else return(false);
}

703 ：仕様書無しさん：02/12/06 21:07

まあ、677が作るトランスレータなんて、おおかた
-> を . にするとか、 :: を . にするとか、そんなもんだろｗ
もう哀れだから許してやるとしよう。

あと、>>674（=>>677 多分）が
C#のコンパイラがC++に変換してると大胆な勘違いをしているっぽい
ところも忘れてあげるとしよう。

今日も1日楽しかったよ。

704 ：仕様書無しさん：02/12/06 21:08

C++がCへのトランスレータであることを辞めたのっていつぐらいから？

705 ：仕様書無しさん：02/12/06 21:11

例外は C で実装できるのか？

706 ：703：02/12/06 21:13

随分前だと思うぞ。Windowsの世界ではとりあえず、
VC++2.0はトランスレータではなくなっていた。
それ以前は知らないけど、VC++1.0ももしかすると
トランスレータではなかったかも。

漏れがはじめて買った入門書では、
まだC++コンパイラはCへのトランスレータとして扱われていた。
もう10年少々前だと思う（うろ覚え）

707 ：仕様書無しさん：02/12/06 21:27

win2Kです
USB(オンチップ)が認識されません(挿してもドライバのインストールが始まらない)
デバイスマネージャでいったん削除しましたが、改善されませんでした
BIOSも確認しましたが、Enabledになっていました
どのような原因が考えられるのでしょうか？
(知人の自作マシンで、知人はUSBを問題なく使用していたとのことです)

708 ：仕様書無しさん：02/12/06 21:28

>>707 おまえが>>677に見えるのはなんでだろうな。

709 ：仕様書無しさん：02/12/06 21:48

C# -> C++へのトランスレータすら書けないDQNが集まるスレッドは
ここですか？GC？あの程度の処理すら書けないの？頭悪いね。

710 ：仕様書無しさん：02/12/06 21:53

>>709
だから using や delegate その他をどーするってんだよ。

711 ：仕様書無しさん：02/12/06 22:18

GCしかC#を知らない程度の奴が何を言っても無駄。

712 ：仕様書無しさん：02/12/07 02:01

>>677ｷﾀｰ
精一杯の煽りご苦労！！>>709
で、どうでもいいけどアホ剥き出しで愉快だぞ。
その調子でどんどん白痴度を披露してくれたもれ。

とりあえず、C++で using と delegate と不定多次元配列あたりを
C#からさくっとトランスレーションしてくれ。GCだけじゃC#を網羅できないよ。
もちろんC#より速い奴よろしくな～。

713 ：仕様書無しさん：02/12/07 02:04

というか、むしろここ半日のここの会話を理解できないから
ココまで無知蒙昧でいられるのだろうなぁ・・・。

>>677がコテハンなら、ある意味プチ勇者くらいの称号は得
られたかもな。

714 ：仕様書無しさん：02/12/07 02:18

GC調べて戻ってくるのに半日かかっちゃいましたってやつですか？

715 ：仕様書無しさん：02/12/07 03:15

C#をC++にする？つーかそんなものかいてどうすんの？
はぁ？
頭大丈夫？
よく寒い奴っていわれるでしょ？
べつのことやったほうが頭よさそうだよ。

716 ：仕様書無しさん：02/12/07 04:45

C++は標準ライブラリが膨大＆高度すぎて
ついていけない。Ｃの標準ライブラリは簡潔で
4000円くらい出せばリファレンスが購入できたのに。

みなさん、どーしてます？

717 ：仕様書無しさん：02/12/07 05:12

>>716
ヘッダを読む

718 ：仕様書無しさん：02/12/07 09:34

MSDN

719 ：仕様書無しさん：02/12/07 12:22

>>715
誰相手のメッセージでつか？
漏れには君が>>677の自作自演に見えますた。
（ちがったらｽﾏｿ）

720 ：仕様書無しさん：02/12/07 13:02

最近はリファレンス本は開かないなぁ。ＭＳＤＮでかなり十分。

721 ：仕様書無しさん：02/12/07 15:09

>>704
かなり前。

722 ：仕様書無しさん：02/12/07 15:36

MS-C/C++7.0(VC++1.0の1つ前)の時点で既にトランスレータでは
なかったと思うが…
つか、トランスレータなC++コンパイラ見た事ないよ。

723 ：仕様書無しさん：02/12/07 17:47

他スレッドからこちらのスレッドを紹介されました。

OSはWin98SEですが、自己展開式のフリーウェア・シェアウェア(95から
XPまでwin全般対応)のインスト時に出ます。リソース関係の設定が悪い
と思いろいろいじりましたが全くダメだったので、HDをフォーマット後
OS(Win98SE)をインストールしましたがダメです。OSがサラの状態でも
でます。(マザボが故障でしょうか？)分かる方よろしくお願いします。

デバイス
cpu;セレ900+下駄
マザボ;P3V4X(3年近く使用。寿命?）
メモリ;PC100.CL2.256M
HD;ATA66_4.3G

724 ：仕様書無しさん：02/12/07 18:11

>>723
マルチしね

725 ：仕様書無しさん：02/12/07 18:21

> スレッドを紹介されました

もうちょっとマシな文面を考えろな。

726 ：仕様書無しさん：02/12/07 20:37

>>677はよほど悔しかったと見えるｗ

727 ：仕様書無しさん：02/12/07 20:54

>>723
屁でも出たのか？

728 ：仕様書無しさん：02/12/07 22:55

状況的に、このスレだけに嫌がらせくさいコピペするのは
>>677しかありえん。
頭悪すぎ。
　　↓
悔しいのでマ板全体を荒らし始める
　　↓
アク禁

729 ：仕様書無しさん：02/12/11 05:47

どこに飛ぶかわからん

730 ：仕様書無しさん：02/12/11 17:47

ぶわーっはっはっはっは！！
うらうら、メモリリークだぞう！！
どぅーだ My ったかっ！！くわっ！！

731 ：仕様書無しさん：02/12/11 20:06

>>729
ティッシュでくるんでからすると、あちこち飛ばないので衛生的ですよ。

732 ：仕様書無しさん：02/12/11 20:51

>>729
トイレでやれば？

733 ：仕様書無しさん：02/12/11 21:40

さむい・・・

734 ：仕様書無しさん：02/12/11 23:36

C のプログラムを、Test Case を作って確認しながら、段階的に C++ に移行して
行こうと提案したら、「客先が読めないから新しい言語はだめ」とのこと。
やる気なくす。
というか、納品するドキュメントはすべて関数名を抜き出したもの。
何をする関数かも書いていない。
マネージャーいわく、「どうせ読まないんだから」だって。

735 ：仕様書無しさん：02/12/11 23:50

（　´_ゝ`）ﾌｰﾝ
君はCとして設計されたものを、OOトレーニングすら満足に受けていないような素人がC++に段・階・的に移行しているのを見て、なにも言わないんだ？
俺なら、その素人考えにやる気なくすがね。
今まではCtags一発ですむような仕事だったのに、わざわざ専用のクラスブラウザ使わなきゃならないようにしたいんだ、へー。
やっぱり、俺だったら君殺すかも。
アホのせいで仕事が増えて、その上給料上がらずじゃシャレにならないからね。

736 ：仕様書無しさん：02/12/11 23:57

パラダイムが違うものに段階的に移行出来るか…？
それともOOでないC++でもやるのか…？

737 ：仕様書無しさん：02/12/12 00:07

>>735-736
できる。
幸い、各関数が非常にシンプルに設計されていた。
関連のある関数群と構造体群は、すぐにでもクラスに
直せるぐらいだ。
いくつかのクラス候補が見つかった。非常にシンプルだ。
もっとも、変更に当たっては Test Case がないと、一定以上の
安心は得られないが。
まず、拡張子を .cpp にして、Test Case がすべて通るかどうかを
検証し、C と C++ との微妙な使用の差異による動作の変更が
発生しなかったかどうかを調べる。
K&R スタイルの関数定義は通らないから、このときに直す。
次に、Better C としてリファクタする。
それから、テストを OO 用に作成してから、クラスにまとめるに
ふさわしい関数群をまとめて、クラスにする。
C++ の何がいいって、ポインタ演算関係を STL 等で安全に排除できる
こと。
リファクタリングが格段にしやすくなること。
既存の Test Unit の動作が安定していること。

738 ：２９歳童貞：02/12/12 00:48

>>731
コンドームを使うとｲｲよ！

使い方の練習にもナルし！

739 ：仕様書無しさん：02/12/12 00:58

Java ならともかく、C++ すなわち OO というのは・・・

740 ：仕様書無しさん：02/12/12 01:00

>>735
君は、何かを間違えているとしか思えない。特に
> 今まではCtags一発ですむような仕事だったのに、
> わざわざ専用のクラスブラウザ使わなきゃならないようにしたいんだ、へー。
このへん。

741 ：仕様書無しさん：02/12/12 01:07

>>737
C++使ったことも無い連中相手にMixed Languageは、あんまり
オススメできないねぇ。新規開発でやった方が良いんじゃないか
と思うが。

742 ：仕様書無しさん：02/12/12 02:01

その程度でなくす程度のやる気ならプロ辞めちゃえよ。

743 ：仕様書無しさん：02/12/12 14:07

multi-paradigm programming!

744 ：仕様書無しさん：02/12/12 14:46

Ctag って、C++ 対応していませんでしたっけ？
かなりいろんな言語に対応していた気がする。Emacs あまり
使わないから知らんけど。

745 ：仕様書無しさん：02/12/12 14:49

Ctags か。
クラスブラウザなら Eclipse とか対応してない？
お手軽には doxygen だね。

746 ：仕様書無しさん：02/12/14 00:04

doxygen で充分かな。
でも、私の場合、ソースたどってクラスの関係を把握しちゃう方が多いけど。
クラス・ブラウザはあればあったでいいけどね。
ある程度ソースごそごそとやっても、どうにもわからないクラス関係のソースって
ほとんど見たことない。
ただ MFC はようわからんですね。VCL はわりかし綺麗。
J2SDK なんかはすごくシンプルですね～
クラス図がついてなくても、普通困らんわなあ。

747 ：仕様書無しさん：02/12/14 00:08

dokyungenってDQNを作るんですか？

748 ：仕様書無しさん：02/12/14 00:11

>>747
みんなは、ソースを見て、イメージとして関数構造なり、OO ならクラス構造なり
ビジュアライズできひんのかな。
そうしないと仕事になれへんで。
ものすげー長い、脈絡のないソースなら別だけど。

749 ：仕様書無しさん：02/12/14 00:13

>>748
ここは、C++ がわからなくて「C++ について言いたいことがある」ひとが
集うスレだから、まともな話はよした方が……

750 ：仕様書無しさん：02/12/14 00:17

>>748
小さいソースを一人でやっているアマチュアさんに用はありません。

751 ：仕様書無しさん：02/12/14 00:21

>>748
可読性のかけらもないソースを書いて
回りに迷惑かけてるなんちゃってプロさんに
用はありません。

752 ：仕様書無しさん：02/12/14 00:26

なんちゃってプロ≒アマチュア

753 ：仕様書無しさん：02/12/14 00:26

つーか、748 は内容的に 747 へのレスとして間違っているんだが。。。

754 ：仕様書無しさん：02/12/14 00:40

なんちゃってプロ < アマチュア

755 ：仕様書無しさん：02/12/14 14:48

>>748
その言葉使いで俺を責めてください(；´Д｀)ﾊｧﾊｧ

756 ：仕様書無しさん：02/12/14 14:57

VB厨、JAVA厨のための、Ｃファミリーの概念的入門言語、C--登場！
デクリメントだけあって、糞コード必至のDQN言語。
つーか、構造化手続き型とOOを同時に学べるってあーた、どうよ！

というスレが、うっぷん晴らしAAに荒らされてる夢をみた。
・・・疲れてるよな、実際。

757 ：仕様書無しさん：02/12/14 14:58

>>755
でるっ、でますぅ～の関西弁バージョンキボンヌ。

758 ：仕様書無しさん：02/12/14 15:46

>757　あ、あかん、でるっ、でてまう～！
使うたことあらへんけどな。

759 ：とある江戸っ子：02/12/14 16:36

「まう～」は現在進行形だっけ？

760 ：仕様書無しさん：02/12/14 22:06

未来形

761 ：仕様書無しさん：02/12/15 00:41

>>748
ソースが大きくて読みきれないというのは、クラス間の依存性が
密になっているということですね。
リファクタリングして、充分な粒度にパッケージ化しませう。

762 ：仕様書無しさん：02/12/15 00:52

プログラムが肥大化しているから、ツールなしでは読めないって
状況なのね。
かわいそうに。
設計が悪いんだよ。
プログラムの大きさと、理解しやすい単位に分けて設計する、
というのは別問題だね。
どんなに大きくなっても、理解しやすい粒度で、結合を疎にしておけば、
プログラムが大きい＝読めないとはならない。
まあ、そんな発想するのは土素人だけだろうけど。

763 ：仕様書無しさん：02/12/15 04:32

> まあ、そんな発想するのは土素人だけだろうけど。
その通り。自分で書いた綺麗なものを読むだけなら誰にでも出来る。
時には他人が書いた汚いものを(直すために)読まなきゃいけない。
技術力が乏しい新人も参加する。
そしてビジネスでは正確さとスピードとチーム力が必要。
頭の中で想像して自分ひとりで完結するなんてもってのほか。

764 ：仕様書無しさん：02/12/15 04:36

> 他人が書いた汚いもの

破棄しましょう。

765 ：仕様書無しさん：02/12/15 14:31

>>763
「他人が書いた汚いもの」でも、読んでいるうちに、その人の
思考パターンというか、そういうのが見えてきて、「ああ、
これはこの人なりのスタイルなんだな」って思うことは
良くあるよね。
そうすると、後のコードもかなり読みやすくなるよ。

766 ：仕様書無しさん：02/12/15 14:54

>>764
ドキュメントが残っており時間があってグローバル変数やフラグを多用
していない場合はそうするけどね。

767 ：仕様書無しさん：02/12/18 08:34

> 他人が書いた汚いもの

逃げましょう。

768 ：仕様書無しさん：02/12/20 12:34

新しいリビジョンの仕様書はいつでますか？

769 ：仕様書無しさん：02/12/20 12:40

ヌルッポ

770 ：仕様書無しさん：02/12/20 12:54

最近のC++の例外処理ってのがよくわからん。
C++のプログラマはエラー処理は全部アレ使ってるんですか？
main関数全部をTRYで囲むんですかね？

771 ：仕様書無しさん：02/12/20 13:01

>>770
そうです。エラーコマンドライン引数とエラー処理は
全てmainでやるのが正しいのです。

772 ：仕様書無しさん：02/12/20 13:07

>>770
ON ERROR GOSUBはわかるのに？

773 ：仕様書無しさん：02/12/20 13:16

>>771-772
どうも。関数で簡単に実装できそうなのにって
思っちゃうんですよね。
TRYのネストとか例外の再投入とか、ややこしい。

ON ERROR GOSUB ってBASIC?

774 ：仕様書無しさん：02/12/20 14:48

C++でCのキャスト使いまくるやつってナニ考えてるの？

775 ：仕様書無しさん：02/12/20 14:54

その場しのぎにタイプ数を抑えたいとかよからぬ考えを持っているんじゃないの。
ていうかC++のキャスト知らないとか。

776 ：仕様書無しさん：02/12/20 14:55

C++のキャストって何？
役に立つの？

777 ：仕様書無しさん：02/12/20 14:58

>>776 立つ。

そして俺は777ゲット。

778 ： ◆qQ4COMPILE ：02/12/20 15:14

>>774
何も考えていない、

考えているとしたら、『警告がでるから』ぐらい。

779 ：仕様書無しさん：02/12/20 15:30

アセンブラーからＣ＋＋に乗り換え中です。
Ｃのソースみて思ったこと、
わ！ほとんど割り込みばっかだ！
なんじゃこりゃ！？

リファレンスみてＩＮＴが型指定だとわかった！
どうりで、わけわからんソースやと思ってたで。

780 ：仕様書無しさん：02/12/20 15:48

#define private public
#include <Hoge.h>
#undef private

int main()
{
　CHoge hoge;
　hoge.m_strPrivate = _T"げへへへ";
　return 0;
}

ｳﾏｰ

781 ： ◆qQ4COMPILE ：02/12/20 15:56

// Hoge.h

#include <string>

class CHoge{
std::string m_strPrivate;

public:
CHoge();
};

782 ：仕様書無しさん：02/12/20 21:48

warata

783 ：仕様書無しさん：02/12/21 02:32

>>780
あの～、_T って C++ 言語じゃないんですけど、それが何か？

784 ：仕様書無しさん：02/12/21 02:34

>>783
T_T

785 ：仕様書無しさん：02/12/21 02:50

class *_T = new T_T();

786 ：仕様書無しさん：02/12/21 02:59

C++とそのユーザーからは何でも馬力と追加機能で解決しようとする
反知性的な香りがﾌﾟﾝﾌﾟﾝしてくるよな｡

787 ：仕様書無しさん：02/12/21 03:52

それは、あさはかCユーザーのことでは？

深いCユーザーはそんなことはないけど

788 ：仕様書無しさん：02/12/21 10:56

>>785
趣旨は、

class T_T{};
T_T m_m = new T_T;

てな感じかな？ワラタよ。

789 ：仕様書無しさん：02/12/21 17:13

キャストオペレータが宣言してあるクラスでは、
なぜかCキャストを使いたくなる。

790 ：仕様書無しさん：02/12/22 04:12

>>788
補足ありがとです。

m_m->UoU();

791 ：788：02/12/22 09:45

>>790
ぐはっ。まちげーたよ。
T_T *m_m = new T_T;
でやんの。はじかし。

792 ：仕様書無しさん：02/12/23 16:20

質問。VC++の本を買ってみたら、「VC++は、C++とは全然違う。VC++は、C++に、さらに複雑な要素を詰め込んだもので、一番難しい言語とさえ言われていて、普及しそうもない。」と、かなり否定的なことを書かれていた。

・VC++は、普及すると思う？
・VC++を、覚えた方が、いいと思う？

793 ：仕様書無しさん：02/12/23 16:22

・VC++は既に普及している。
・目的も無く覚えるのは時間の無駄。

794 ：仕様書無しさん：02/12/23 16:23

初版は何年？

795 ：792：02/12/23 16:33

本は「ゲーム作りで始めるMFC」
初版：平成14年 9月25日

目的はスキル向上であり、何かを始める目的としては、一番多いもの。

796 ：仕様書無しさん：02/12/23 17:51

そんなクズ本、さっさと捨ててしまえ。

797 ：仕様書無しさん：02/12/23 20:48

>>792
ム板のスレみたら判断できるんじゃないの？

798 ：仕様書無しさん：02/12/23 21:12

>>797
・C++
・VC++
・MFC
それぞれ全く異なるモノを指す言葉だ。

「VC++を覚える」のは用法として正しくない。
ソフトの使い方を覚えることを指してしまう。
普通、「車の運転を覚える」ことを「マニュアル車を覚える」とは言わないだろ。

「VC++でMFCを覚える」は正しい。
また「VC++でC++言語を覚える」も正しい。

＞普及しそうもない。
これはVC++ではなく、厳密にはMFCのことを指している。
MFCはかなり普及してるが将来性は微塵も無い。
マイクロソフト自身も.Netに移行して、MFCを捨てたようだし。
今から新たに覚えても無駄。

>>795
MFCはかつて無いほどにゲーム作りに向いていないフレームワーク。
ゲームが作れても技術的価値は無いので、そんな本捨ててしまえ。

ゲームが作りたいなら、
DirectXの初心者本でも買って、「VC++でC++言語を覚える」ことをお勧めする。
少なくとも漏れはそれでC++を覚えた。

ゲームは思いのほか、オブジェクト指向の設計練習に向いている。

799 ：798：02/12/23 21:13

ｽﾏ
>>792
の間違いだ。

800 ：仕様書無しさん：02/12/23 21:40

>>798

ありがとう。

801 ：仕様書無しさん：02/12/23 21:47

>>798
根拠のないことを書くなよ。
MFCはどう考えてもなくならないぞ。
.netで管理されたソフト以外を作る手段としての第1候補がMFCなのに。
しかもCOMやActiveXを作るときにMFCがいらなくなるわけがない。
ATLCOMを作るのならいらないが。

802 ：仕様書無しさん：02/12/23 22:17

MFCから.NETを使ったプログラムへの移行期でもあり、また今はまだVC++ .NET情報が少ないので貴重と思います。ただ内容は浅めです。

この本には、これまでの本のようなMFCやスケルトンは一切載っていなくて、.NET時代への移り変わりを感じさせるかも。個人的にMFCが「過去」のものとあっさり切り捨てられているのに驚いた(^_^;
マイクロソフトの.NET Frameworkに移行させたいという気持ちがよくわかった一冊でした（笑）

http://www.amazon.co.jp/exec/obidos/ASIN/4891002832/249-0208608-5523516

803 ：仕様書無しさん：02/12/24 15:29

MFCや.NETなんてどうでもいいじゃん。
そんなにのしがみ付いてるのはタダの職業プログラマか低脳だけなんだし。

804 ：仕様書無しさん：02/12/24 17:14

MFC使うのってそんなに大変なのか？
文句があるのは分るが、それに対して
必死になってるやつはなんか勘違い
してるんじゃないのか？（藁

805 ：仕様書無しさん：02/12/24 17:18

>>スレタイに
　別にありません。

806 ：仕様書無しさん：02/12/24 21:36

>根拠のないことを書くなよ。MFCはどう考えてもなくならないぞ。

いや、もういいいよ。オマエ、哀れすぎるから、自殺してくれ。オマエみたいなクズがいるせいで、プログラマー全体の質が落ちる。

807 ：仕様書無しさん：02/12/24 21:40

どっちもどっち。

808 ：仕様書無しさん：02/12/24 21:45

MFC って COBOL なんですか？

809 ：仕様書無しさん：02/12/24 21:48

ところでIEってMFC使ってるの？

810 ：仕様書無しさん：02/12/24 21:48

現代のCOBOLといえば、普通、Javaのことです。

811 ：仕様書無しさん：02/12/24 21:59

現代の COBOL が Java なら、MFC は 1 世代前の COBOL ですか？

812 ：仕様書無しさん：02/12/24 22:05

　現在、「Windowsプログラミングの基礎知識」で
MFCを使ったプログラミングの勉強をしてるんですが
Visual C++でWinアプリを作ろうとすると、ベースにな
るソースに自動的にMFCが使われてしまいます。

　Visual C++で開発する場合、MFCを使わないと
相当手間がかかりませんか？

813 ：仕様書無しさん：02/12/24 22:09

> Visual C++でWinアプリを作ろうとすると、ベースにな
> るソースに自動的にMFCが使われてしまいます。

んたこたーない。

814 ：仕様書無しさん：02/12/24 22:11

WTLつかえや

815 ：仕様書無しさん：02/12/24 22:13

MFCの批判はよく聞くのですが、具体的に
どの辺に問題ありなのでしょう？

個人的には幾重にもクラスを継承してブラックボックス化が
激しくて、逆に何をやっているのか分かりづらい印象を受け
ました。

816 ：仕様書無しさん：02/12/24 22:18

>>812
VC++ 6.0 に限って言えば、MFC/非MFC/Console の 3種類から選べる筈です。

817 ：仕様書無しさん：02/12/24 22:22

>>816
しかし ANSI C++ はきたいできない。

818 ：仕様書無しさん：02/12/24 22:33

>>817
816 へのレスには見えないが？

819 ：仕様書無しさん：02/12/24 23:03

>>815
まったくブラックボックスになっていない。
なにをしているか知りたかったらソース見ろよ。
まず、MFCによるWindowsプログラムを熟読しろ。

820 ：仕様書無しさん：02/12/24 23:09

>819
むしろホワイトボックスなのが問題なんだよな、MFC は…。

821 ：仕様書無しさん：02/12/24 23:09

>>817
おまえはANSIC++の仕様を極限まで利用し尽くすようにPGを組んでいるのか？

822 ：仕様書無しさん：02/12/24 23:11

> ANSIC++の仕様

完全には確定してないし。

823 ：仕様書無しさん：02/12/24 23:13

>>820
それがいいと俺は思うが。
SDKプログラムを忘れないですむし。
それに巷で言うほどMFCって悪くないと思うが。
サブクラス化があんなに簡単にできるなんてちょっと感動したし。

824 ：仕様書無しさん：02/12/24 23:13

まあVC6のANSI対応はひどすぎたよ。
別に極限じゃなくても、ちょっとした入出力でバグってた。
VC7はいいかんじだよ。

それがなんでマネゲドだのドトネトなんだかわからんが。

825 ：仕様書無しさん：02/12/24 23:14

>>824
英語の勉強したほうがいいですよ。

826 ：仕様書無しさん：02/12/24 23:15

VC++にはそもそもMFCのソースコードが付属してるはずなのだが。

827 ：仕様書無しさん：02/12/24 23:16

>>824
VC++6.0の出荷時期とANSI C++の確定時期考えれば対応してるほうがおかしいだろ。

828 ：仕様書無しさん：02/12/24 23:19

>>827
現ANSIC++は1998年。VC6の出荷はいつ？

829 ：仕様書無しさん：02/12/24 23:22

>>828
ソース出せや。ゴルァ！

830 ：仕様書無しさん：02/12/24 23:23

>>828
たしかANSIの確定より前に出たのは確かだよ。
なんかの本でも書いてたし。

831 ：仕様書無しさん：02/12/24 23:25

>現在、「Windowsプログラミングの基礎知識」で
>MFCを使ったプログラミングの勉強をしてるんですが
>Visual C++でWinアプリを作ろうとすると、ベースにな
>るソースに自動的にMFCが使われてしまいます。
>　Visual C++で開発する場合、MFCを使わないと相当手間がかかりませんか？

おまえ、本格的にアホだな。今さらVC++覚える奴はいないぞ。VC++もMFCも絶滅する。C# とVB.NET に統合されるに決まってるだろ。
オマエみたいなアホと仕事できるか。

832 ：828：02/12/24 23:29

>>830
ふーん。勉強になったよ。
#風の谷から出てきていいこともあるんだな。

833 ：仕様書無しさん：02/12/24 23:31

>>all
831はネタなので放置してください。お願いします。

834 ：仕様書無しさん：02/12/24 23:32

Windows98が出たちょっと後ぐらいだったはず＜VC6

835 ：仕様書無しさん：02/12/25 00:02

Visual Studio 6 セットアップ CD 1 の VC98\BIN\CL.EXE は 1998/07/06 だった。
ISO/IEC 14882_1998 の日付は 1998/09/01 だった。

僅差に見えるが、コンパイラを実際に作る時間を考えると「ずいぶん後」と言っても
差し支えなさそうだ。

836 ：仕様書無しさん：02/12/25 00:06

ところで、ISO/IEC 14882 のことを ANSI と呼んでいいものか？

837 ：仕様書無しさん：02/12/25 01:18

ただし言語仕様なんてDraftあんは96年ぐらいにほぼ出来上がってたような

838 ：仕様書無しさん：02/12/25 01:35

>836
プログラミング言語の規格に関しては、ISO, ANSI, JIS はどれも致命的な違いは
ないから、良いんじゃないの。

839 ：仕様書無しさん：02/12/25 05:58

>>837
そのドラフト '96 は、14882_1998 と比べてどんなもんだった？

840 ：仕様書無しさん：02/12/25 14:42

ISO
International規格準拠に決まってんだろ！
ANSI？
アメリカ内だけなんてだめ。
一つの国に篭るな。鎖国反対！ヒキコモ日本！

841 ：仕様書無しさん：02/12/25 19:12

アメリカの規格に対応したぞ、って言い張ったってあんまり偉くないじゃん。
実質同じだったとしても。
ISO C++ とか標準 C++ （STD C++）とかの方がいい。

もしくは、 USO C++、、、

842 ：仕様書無しさん：02/12/27 01:38

C++ビルダーはなんと読みますか？「シープラプラビルダー」ですか？「シープラスプラスビルダー」ですか？
派遣はいつも「シービルダー」と呼びます。
助けて！！アルゴマン！！

843 ：仕様書無しさん：02/12/27 01:47

BCB

844 ：仕様書無しさん：02/12/27 01:49

しーたすたす

845 ：仕様書無しさん：02/12/27 03:08

しーひくいち

846 ：仕様書無しさん：02/12/27 17:43

ビルダー捜査官

847 ：仕様書無しさん：03/01/07 10:08

age

848 ：仕様書無しさん：03/01/07 15:25

思えば一年前。.net frameworkの正式リリースもあって
ここ2chでもC++はかなり叩かれてたんだよなあ。
普通のアプリなら全てC#やJava。ドライバやUNIXアプリはCや汗。
C++ってどこで使うの??みたいな調子に。
おれの見るところによるとModernC++DesignとそれのためのGenerativeスレ。
これの影響、インパクトはでかかったね。
猫も杓子もLokiやboostを落して使い始めた。
今じゃC++マンセー板になりつつある。感慨深いです。
これからC++を勉強するひとはストラウストラップの本と一緒に
Alexandrescuの本を買い、boostのニュースグループを読みましょう。

849 ：!：03/01/07 15:28

え？糞Cってどこで使うの？

850 ：仕様書無しさん：03/01/07 17:50

未だにBjarneの読み方が分からん…
ｸﾞｸﾞって見る限りでは、
ビョーン
ビヤーン
ビアルネ
…

851 ：仕様書無しさん：03/01/07 18:32

>>850
ミヤーンが正解

852 ：仕様書無しさん：03/01/07 20:52

>>850
びやぁね、かな? ここで本人の発音が聞ける
http://www.research.att.com/~bs/bs_faq.html#pronounce

853 ：仕様書無しさん：03/01/07 21:10

Link
http://pc.2ch.net/test/read.cgi/prog/1040716778/l50

854 ：仕様書無しさん：03/01/07 21:17

>>852
おお、thx！
Be-ar-neh Strov-stroop
と発音すれば良さそうね･･･

855 ：：03/01/11 22:18

>>848
boost について簡単に紹介して。何それ?

856 ：仕様書無しさん：03/01/11 22:32

>>855 そのくらい自分で調べろや。
っつーか、C++スレを見るくらいなら聞いた事ぐらいはあるだろう。

857 ：仕様書無しさん：03/01/11 22:38

>>855
バカには触れないように

858 ：仕様書無しさん：03/01/13 08:51

ソースファイルの拡張子って、.C .cpp .cc .cxx .c++て
あったけど（他にもある？）VC++が勝手に.cppで
ファイル生成するから.cppが主流になってくんだろうか
ヘッダファイルを.hppにする人も居るね

859 ：仕様書無しさん：03/01/13 09:08

C++標準のヘッダファイルが拡張子無しになってて、
関連づけで困る。

860 ：仕様書無しさん：03/01/13 09:17

そろそろCとの腐れ縁は断ち切りたいところ
実際にC++をCの延長線上にあるものと考えてる
ようなプログラマにろくなのはいないし、
歴史的な順序抜きに二つ並べて考えた方が
すっきりする。

861 ：仕様書無しさん：03/01/13 12:25

>>860
いや、所詮は延長線上でしかないんだが…

862 ：仕様書無しさん：03/01/13 14:54

>>861
分かれた女にいつまでも未練がましい男だな。
いい加減、諦めろ。

863 ：仕様書無しさん：03/01/13 15:58

延長というか改良というか

864 ：仕様書無しさん：03/01/13 16:02

改良というか改悪というか

865 ：仕様書無しさん：03/01/13 22:49

ばんばん機能追加しているが、「改」ではないだろ。

866 ：仕様書無しさん：03/01/13 23:31

C++がCの延長上にあるなんて言ってる奴はダメダメだよ。

867 ：仕様書無しさん：03/01/13 23:57

つーか、ANSI C自体C++からのバックポートだしな。

868 ：仕様書無しさん：03/01/14 01:12

C++ が C のスーパーセットである限り、延長というのは間違い無いだろう。
ただ、その延長線上で、ほとんど別の言語として振舞うことはできる。

869 ：仕様書無しさん：03/01/14 01:33

C++美「あたしはC子の代わりじゃないわ！」

870 ：仕様書無しさん：03/01/14 01:54

3P で解決

871 ：仕様書無しさん：03/01/14 07:02

C++をCの延長線上にあるものとしてみること「は」できるけど、
そういう見方から生まれるコードはあまりお勧めできるようなものじゃない。
どう見るかはどうでもいいことのように思うけど、実はそれはスタイルに
かなり影響する。Perlをお手軽C、お手軽Lisp、お手軽Javaと、どう考えて
組まれたかによってプログラムの書式から構造まで全然違うものが出来上がる。
Perlの場合は言語設計者の考えもあって、それぞれ好きなようにいろんな
やり方を認める向きがあるけど、C++はそういうものじゃないと思う。
言語のシンタックス（マクロはあえて除く）によって可能なことをフルに使い
パフォーマンスとコードの見通しの良さを同時に目指す。
これがC++の考え方だと思う。でもこれってCだってそういう風に考えられて
来たわけだよね？こういったストイックな姿勢はC文化から受け継いだものだ。
その意味でC++とCの延長線上にあると考えるのは正しい。
だけど元Cプログラマの何人かは、Cに対して保っていたその誇るべき姿勢を
C++と向かい合ったとたん投げ捨ててしまう。なぜなんでしょうか？

872 ：C++厨：03/01/14 12:50

延長というかC++がCを抱合している

873 ：仕様書無しさん：03/01/14 22:15

>>872
微妙に重なってない部分があるから、厳密には包含関係になってない。
まー、微妙だから気にしなくても良いけど。

874 ：仕様書無しさん：03/01/14 23:35

で、立て読みの仕方の解説は？

875 ：山崎渉：03/01/15 17:05

（＾＾）

876 ：仕様書無しさん：03/01/15 21:47

ということにしたいのですね：）

877 ：仕様書無しさん：03/01/19 05:08

>>842
お店に並んでいる C++ Builder のパッケージに
「シープラスプラスビルダー」って書いてあるよ。

878 ：仕様書無しさん：03/01/19 05:21

Ｃ＋＋人間はＣプログラマーに比べて、
プログラムをなめてる。
ＶＢでもやってる間隔。

879 ：仕様書無しさん：03/01/19 05:28

たしかにそれは言えてるかも。かならず汗で確認しろとまでは
言わないにしても、自分の使ってるSTLのソースぐらいは
見ておくべきだな。そのためのテンプレートライブラリでも
あるだろうし。

880 ：仕様書無しさん：03/01/19 05:31

STLなんてブラックボックスでいいんだよ｡
あんな汚いコード読めるか｡

881 ：仕様書無しさん：03/01/19 06:13

>>880
同感。:-)

高級言語遣いはライブラリ等の上位概念をソース参照以外の方法で
理解することを覚えるべきだ。
ポインタを間接アドレス参照のことだとか、
イテレータはポインタと同じだとか、
下位の概念でしかマッピングできないのは高級言語の価値が薄れる。
ターゲットにあったレイヤを使いこなしてこその高級言語。

882 ：仕様書無しさん：03/01/19 10:23

>>878
そんなこといいはじめりゃ、Cプログラマはアセンブラプログラマに比べて
プログラムなめてんのか。
アセンブラ遣いは回路設計に比べてコンピュータなめてんのか。

レイヤが違うんだよ。ターゲットにあった言語を選択して、
それにあったコーディングスタイルで望むことが重要なの。
CとC++が違うのは当たり前。優劣をつけようとしている時点で
あんたの力量の狭さを露呈するようなもんだからやめときな。

883 ：仕様書無しさん：03/01/19 11:00

>アセンブラ遣いは回路設計に比べてコンピュータなめてんのか
これは正解だろ

884 ：仕様書無しさん：03/01/19 11:05

>>882
アセンブラも使えないようではCプログラマとしては食っていけない。

885 ：仕様書無しさん：03/01/19 11:10

>>884
食っていくことはできるよ。
現実問題としてアセンブラレベルでの内容が理解できてなきゃできない、って仕事はそれほど多くないし。
でも個人的にはプログラマーならアセンブラや回路設計にも興味もって欲しいとは思うけど。

886 ：仕様書無しさん：03/01/19 11:18

>>885
同感。アセンブラの知識があるとCを覚えやすいってのはわかる。
だけど、実際の現場でそこまでナノ秒とかの精密さを要求されるものはすでに
ライブラリなどになっていたりするし。

887 ：仕様書無しさん：03/01/19 13:28

>>880
> あんな汚いコード読めるか｡
確かに STL や Boost のコードは、もはや一般のプログラマが読むものとは
思えん……

>>886
> だけど、実際の現場でそこまでナノ秒とかの精密さを要求されるものはすでに
> ライブラリなどになっていたりするし。
ライブラリを「書く」側に回りたいなら、アセンブラの知識は必須だけどな。別に
ライブラリ屋さんが偉いってわけじゃないけど。

888 ：仕様書無しさん：03/01/19 14:29

高級プログラマと､低レベルコーダを区別してもらわないとね｡
両方一緒くたにされるのは迷惑だよ｡

889 ：仕様書無しさん：03/01/19 23:49

>>888
はぁ?
みなさーん、あほがいますよー!!(w

890 ：仕様書無しさん：03/01/20 00:05

みなさーん!

・・・(ﾟ∀ﾟ≡ﾟ∀ﾟ)みんなどこ？

891 ：仕様書無しさん：03/01/20 01:02

STL で書かれたコード、シンプルじゃん。
STL のインクルード・ファイルやエラー・メッセージが出たときは
なれないと？？？だけど、すぐ慣れるし。

892 ：仕様書無しさん：03/01/20 01:09

STL のエラーメッセージは、コンパイラによっては本気で読めんだろ…

vector 使ってる程度ならともかく STL アルゴリズムと boost::bind, boost::compose_*
とか組み合わせてると、なかなか厳しいものがある。

893 ：仕様書無しさん：03/01/20 01:17

http://pc.2ch.net/test/read.cgi/prog/1042990782/l50
お願いします。　

894 ：仕様書無しさん：03/01/20 01:20

他言語がより洗練されたSTL相当のライブラリをサポートしたら
C++は果たして生き残れるのだろうか・・・

895 ：仕様書無しさん：03/01/20 01:29

そういや C# は次のバージョンで Generics サポートらしいね。

896 ：仕様書無しさん：03/01/20 01:30

Javaﾓﾅ

897 ：仕様書無しさん：03/01/20 05:38

HSPﾓﾅ

898 ：仕様書無しさん：03/01/21 01:15

COBOLﾓﾅ

899 ：仕様書無しさん：03/01/21 06:00

Bﾓﾅ

900 ：仕様書無しさん：03/01/23 18:00

「ぷらぷら」って言うとポコチン連想してﾏｽﾞｰ（ﾟДﾟ）

901 ：C++厨：03/01/28 14:18

連想しねーよ

902 ：仕様書無しさん：03/01/28 19:52

もっとまともなC with classを再設計して
世界中に広めてあげたいなと思う今日この頃｡

903 ：仕様書無しさん：03/01/28 20:02

ほとんどの関数にvirtual,virtual,const,const...
もうぬるぽ

ぬるぽが欲しいぽ

904 ：仕様書無しさん：03/01/28 20:18

>もっとまともなC with classを再設計して
いらねえよ。そんなのやるぐらいならMLとか
もっと良さそうな言語が既にあるだろ。

905 ：仕様書無しさん：03/01/28 21:13

Genericsって何だよ！！ウワーーン！！！

906 ：仕様書無しさん：03/01/28 23:55

>>904はMLが何であるかもよくわかっていないｱﾌｫ

907 ：仕様書無しさん：03/01/29 00:05

メーリングリストがどうかしましたか？

908 ：仕様書無しさん：03/01/29 09:29

>>906
MLはしらねえが、お前のC with classなどより
よっぽどいいだろう。第一それはC++と何が違うのか
説明してみろ。カス。

909 ：仕様書無しさん：03/01/29 09:35

>>908
> MLはしらねえが
要するに知りもいないで適当なことを言っていたのですね。
間抜けもいいところですね:-P

910 ：仕様書無しさん：03/01/29 09:40

>>909
うるせーな。Haskellに挫折したんだよ！。
未だにHakell Reportよんでんだよ。悪かったな。

で、C with classなんだ？説明できないものに
ついて自慢してんじゃねえよ。氏ね。

911 ：仕様書無しさん：03/01/29 09:43

>>910
説明できないということにしたいのですね。

912 ：仕様書無しさん：03/01/29 09:45

>>911
説明しないのならできないも一緒だな。俺にとっては。

913 ：仕様書無しさん：03/01/29 09:47

>>912
一緒にしておいたほうが都合が良さそうですもんね:-)

914 ：仕様書無しさん：03/01/29 09:47

>>913
日下部もどき、キモイから氏ね

915 ：仕様書無しさん：03/01/29 09:53

つかお前日下部か？その妙な冷静さと粘着さは本人そのものだぞ、ぉぃ!!(藁

916 ：仕様書無しさん：03/01/29 09:55

なんだよ、voidさん来てるんならちゃんと言ってくれないと

917 ：仕様書無しさん：03/01/29 10:11

http://gigahz.net/ml/java/archive/

918 ：C++厨@void：03/01/29 13:14

　　　　　　　 _l＼ヾ
　　　　/⌒/　　 l　　＋　激しくvoid　＋
　　　　（ヽヽ＿/ﾉ
　　　⊂(__∪ｰ∪

> で、C with classなんだ？

Cとクラスです (@▽@

919 ：仕様書無しさん：03/01/29 22:09

>>904はGoogleの使い方もよくわかっていないｱﾌｫ

920 ：仕様書無しさん：03/01/29 22:19

で、C with classってなに？

921 ：仕様書無しさん：03/01/30 01:01

うーん…
http://www.google.co.jp/search?q=%22C+with+class%22

922 ：仕様書無しさん：03/01/31 00:33

はつみみです。

923 ：仕様書無しさん：03/01/31 00:57

http://www.google.co.jp/search?hl=ja&ie=Shift_JIS&c2coff=1&q=%22C+with+class%22+%93%FA%89%BA%95%94&lr=

924 ：仕様書無しさん：03/03/04 23:12

今ANSI C++に一番適応率の高いコンパイラってどれだろう…

925 ：仕様書無しさん：03/03/04 23:20

**Cに解明すべき。そのくらいポインタ。

926 ：仕様書無しさん：03/03/30 20:56

hosyu

927 ：仕様書無しさん：03/03/30 22:11

C++って楽しいな。

928 ：伝聞スマソ：03/04/04 10:40

>>924
Code Warriorだって聞いたことがある。

929 ：仕様書無しさん：03/04/04 11:02

>>927
禿げ胴

930 ： ◆r0p/Rg8RZU ：03/04/04 15:17

もういや・・・

void DX3DVertexBuffer::Unlock()
{
if( m_pBuffer != NULL )
m_pBuffer->Unlock();
}

こいつには、引数というものがないのかと小一時間・・・
そもそもテクスチャクラスがひつようなのかと小二時間
テクスチャひとつひとつにインスタンスが必要なのかと小三時間

本人いわく：ライブラリです。

931 ：これは許せん！！！！：03/04/04 15:33

ほんとの話です！！！！
女の子が４０日間渡って監禁され、計１００人ぐらいに強姦、朝から晩まで超暴力と超陵辱された。ヤクザ顔負けのリンチで、天井に血が飛び散っていた。（深くかかわったのは５，６人）
膣を灰皿代わりにされ、自慰(オナニー)を強制され、
真冬に裸で外（ベランダ）に出され、裸で踊らされ、手足を押さえつけられ、膣やお尻の穴に鉄の棒を突っ込まれ、お尻の穴に花火を入れ爆発させ、２０キロの鉄アレイを身体（裸体）になんども落とされ、瞼（まぶた）に熱いろうそくをたらされ、
手足を押さえつけて、膣にマッチ棒を入れられ燃やされ、膣の中のや裸体をライターで火あぶり、精液を大量に飲まされ、５００ccの尿を飲まされ、基礎の他むちゃくちゃ。（生きてるか死んでるかわからないが）ゴキブリも食わされたそうだ。
女の声だが、人間とは思えない叫び声（悲鳴）(絶叫)を上げ続けた！
殺された彼女の親友が言うには、監禁され殺される一日前、幽霊(生霊)となって「助けて！」と親友に助けを求めたが、親友はどうすることもできず、泣きじゃくった。
「狂宴犯罪」は　一ヶ月以上　続いた　。
そして(失禁して)死んだ。（殺された）i78i78i78i
専門家によると自死（あまりのつらさに耐え切れず、脳が死ぬことを選択した。（命令した。）らしい。（死体にの脳は溶けていたらしい）
死体の顔は目の位置がわからないほど、変形し、親でも誰かわからず、原型をとどめてないほどで、性器のほうは顔よりもっとひどく完全に破壊されていた。死体には髪がなくなっていた。
40日間の監禁で極度のストレスのあまり全部髪が抜け落ちた
死体の膣(マンコ）にはオロナミンC２本、入っていた。
　　　　　　　　　
「裁判記録」は死ぬほどエグイ内容であった。「コンクリート詰め事件」で検索すればわかる。
（俺は何時間も涙が止まらず、夜も何日も眠れなかった。たとえ９９．９％の人が幸せでも残る０．０１％の人が(超)不幸なら、そんな世の中、絶対承認しない！！！！！そんな世界いらない！！！！！絶対、絶対いらない！！！！！絶対認めない！！！！！）
l;ok;l(私の心の底からの叫びでした。)
ｂｆｂｆｂｆｂｂ

932 ：仕様書無しさん：03/04/04 16:03

> ほんとの話です！！！！

ソースも引用せずにそんな事を訴えられてもな。

漏れ的にはこっちのが許せん。
http://love.2ch.net/test/read.cgi/gender/1044191799/

933 ：なんか：03/04/04 17:22

「ほんとの話」とか「！！！」とか見ていると
マルチの勧誘っぽいな。しつこくコピペしまくるのも
マルチの勧誘っぽいし。なにが目的なわけ？

934 ：仕様書無しさん：03/04/06 16:09

C++で　ｇｅｔｅｎｖ（　？？？）の？？？はどこに
設定するんですか。ちなみにＵＮＩＸ使用です。

935 ：仕様書無しさん：03/04/06 16:13

>>934
シェルは何使ってんの?

936 ：仕様書無しさん：03/04/07 00:31

>935
ケーシェルってやつだと思います。

937 ：仕様書無しさん：03/04/07 00:32

>>933 もｺﾋﾟﾍﾟっぽいが.........

938 ：仕様書無しさん：03/04/07 00:56

>>937
非常にもっともな突っ込みになってるので、
別にコピペでもいいよ。
こんなに短くて当たり前の内容のものを
わざわざコピペするとは思えないけど。

939 ：仕様書無しさん：03/04/07 01:22

>>934
何が言いたいのか判らん…環境変数の事か？

940 ：仕様書無しさん：03/04/08 00:08

>939
そうです。

941 ：仕様書無しさん：03/04/08 00:35

>>940
getenv に C も C++ もないんだが。つか、ｽﾚ違いだ。
ksh なら、実行する度に
　　???=hoge 実行ファイル
とするか、いつも使うものなら ~/.profile に
???=hoge; export ???
て入れとけ。
あーもうほんっっとにｽﾚ違いだ。

942 ：仕様書無しさん：03/04/08 02:09

++C;

943 ：山崎渉：03/04/17 12:19

（＾＾）

944 ：山崎渉：03/04/20 06:16

　　 ∧＿∧
　　（　　＾＾）＜ぬるぽ（＾＾）

945 ：仕様書無しさん：03/05/06 05:20

hosyu

946 ：仕様書無しさん：03/05/10 18:46

今Ｃ＋＋勉強中なんですが
テキストの通りにiostreamとかやった方がよいでしょうか
そんなんやる必要ないって聞いた事あるので。。。
ちみみに６年前のテキストでつ。

947 ：仕様書無しさん：03/05/10 18:55

STL の前にやることはたくさんあります。

948 ：仕様書無しさん：03/05/10 18:58

protectとprivateの使い分けができないワテは死んだほうがいいのでしょうか？

949 ：仕様書無しさん：03/05/10 19:11

947の言わんとする事が全然理解できないので
とりあえず今はテキストの通りにiostream.h、cout、cinつかっときまつ。
やたらファイルがでかくなってキモイ感じしますけど

950 ：山崎渉：03/05/28 17:11

　　　　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾）＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

951 ：仕様書無しさん：03/05/30 19:55

Cを10年ぐらいやってたんだけど、C++の
コンストラクタが理解出来ない俺はアフォですか？

952 ：仕様書無しさん：03/05/30 19:58

>>951
> Cを10年ぐらいやってたんだけど、
だったらautoとかスタックについてはわかるよね？

それがわかってなかったらもうアフォｹﾃｰｲですが。

953 ：仕様書無しさん：03/05/30 20:05

>>952
記憶クラスのことだよね?
registerとかexternalとか。

それとコンストラクタとどうリンクするのかな。

954 ：仕様書無しさん：03/05/30 20:07

>>952
お前がアフォｹﾃｰｲ

955 ：仕様書無しさん：03/05/30 20:12

最上位クラスがないのは何かの嫌がらせですか?
例外クラスの基底クラスのデザインもへんてこりんだし。

956 ：仕様書無しさん：03/05/30 20:21

というかCを10年もやってたんならアセンブラも分るだろうから、
一つ一つアセンブルソースで確認してもいいような。

957 ： ◆qQ4COMPILE ：03/05/30 21:36

>最上位クラスがないのは何かの嫌がらせですか?
構造体を継承できるから、

>例外クラスの基底クラスのデザインもへんてこりんだし。
同意

958 ：仕様書無しさん：03/05/30 23:04

>最上位クラスがないのは何かの嫌がらせですか?
いいえ。

>例外クラスの基底クラスのデザインもへんてこりんだし。
どこが？

959 ：951&953：03/05/31 01:12

来週から初めてC++で開発やるってんで、今日C++の勉強したんだけど、
コンストラクタの概念的なものがイマイチ掴めないんだよな。
まぁ適当にコーディング&ビルドしてけば解るだろうけど。

>>956
Cやってるからってアセンブラ分かるとは限らないよね？
OS/390アセンブラなら10年前やってたけどwin系の
アセンブラは本気でやったことない。
(今年で32なので、アセンブラのソース追うパワーが無いです)

960 ：仕様書無しさん：03/05/31 01:15

>>959
C++のコンストラクタなんて所詮は構造体alloc+vtbl初期化

961 ：959：03/05/31 01:20

>>960
アドバイスありがとう。
来週から頑張ります。

962 ：仕様書無しさん：03/05/31 01:25

>>960
概念がつかめてない人にいいかげんなことを吹き込まないで下さい。

963 ：960：03/05/31 01:29

俺がいい加減だと思うなら>>961にもっと良いアドバイスしてやってください

964 ：仕様書無しさん：03/05/31 01:48

ttp://www.parashift.com/c++-faq-lite/ctors.html#faq-10.1
「コンストラクタはゴミからオブジェクトを構築する。
　コンストラクタは初期化関数に似ている。
　不定なビットの塊を生きたオブジェクトへ変える。
　少なくとも内部で使用するフィールドを初期化する。
　リソース（メモリ・ファイル・セマフォ・ソケットなど）を割り当ても行うかもしれない。」

965 ：r：03/05/31 01:53

[constructor]

const に ract するもの。
定数ラクタ。

966 ：仕様書無しさん：03/05/31 01:56

>>965
概念がつかめてない人にいいかげんなことを吹き込まないで下さい。

967 ：_：03/05/31 01:58

http://homepage.mac.com/hiroyuki43/hankaku01.html

968 ：965：03/05/31 01:58

俺がいい加減だと思うなら>>968にもっと良いアドバイスしてやってください

969 ：仕様書無しさん：03/05/31 02:51

コンストラクタ：建造する者
デストラクタ：破壊する者

でもね、最近じゃぁ誰もコンストラクタからクラス生成しないんだよ♪

970 ：仕様書無しさん：03/05/31 05:42

勘違いsingleton中毒のお馬鹿は、一生singleの方向で。

泥臭い言い方をすると、コンストラクタは割り当てられたオブジェクトのための
メモリ領域（ヒープだろうとスタックだろうと）を初期化するものだ
が、既出の通り、概念的にはコンストラクタを呼ぶことでインスタンスを得る
（コンストラクタを明示的に呼ぶと、実際にインスタンスが得られる。コンパイラ依存かも知れないが）
要らないと判断するなら、わざわざ自分で作らなくてもいい。
デフォルトコンストラクタが提供されるので、インスタンスは生成される。
初期化されないだけ。

ただしコンストラクタには、 X( const X& x ) のシグネチャを持つ
コピーコンストラクタなどもあるからナメてかかると痛い目に遭う
またコンストラクタが隠蔽されると、クラスを生成できなくなる

971 ：仕様書無しさん：03/05/31 07:12

c++　はcで作るより楽だ

ちょっと複雑なデータ構造とか　複雑なプログラムとか
ほんとに助かるよ　もっと良い言語ができたら勉強しよう
でも新しい言語は普及しないと実務では使わないことが多いし
いまのところ一番良いかな　C++が・・
javaもまあまあ良いけど、、、

972 ：直リン：03/05/31 07:13

http://homepage.mac.com/yuuka20/