この板見てるとＣ＋＋良いって意見ばっかなんだが

1 ：デフォルトの名無しさん：2008/01/04(金) 12:49:16

実際そうなの？

2 ：デフォルトの名無しさん：2008/01/04(金) 12:56:31

>>1は騙されている

3 ：デフォルトの名無しさん：2008/01/04(金) 13:00:31

JAVA最高

4 ：デフォルトの名無しさん：2008/01/04(金) 13:25:15

>>1
×C++は良い
○会社から与えられたものは良い。

会社に逆らう奴は許されない。会社が白いと言えばカラスも白い。

5 ：デフォルトの名無しさん：2008/01/04(金) 13:39:23

環境も含めてなら多少は同意する

6 ：デフォルトの名無しさん：2008/01/04(金) 13:48:43

Javaよりはマシ

7 ：デフォルトの名無しさん：2008/01/04(金) 13:51:28

>>1
そんな意見は初めて聞いたな
おまえの意見か

8 ：デフォルトの名無しさん：2008/01/04(金) 13:59:57

C++は一番レベル高いからね

9 ：デフォルトの名無しさん：2008/01/04(金) 14:00:06

割と何でも出来るからどれか一つ選ぶとしたら
C++ってことなんじゃねーの

10 ：デフォルトの名無しさん：2008/01/04(金) 15:19:19

ガベコレが無いなんて嫌だー、って人にはありえない選択なわけだが

11 ：デフォルトの名無しさん：2008/01/04(金) 15:36:12

そんなもの自分で考えられない奴には、そりゃ使えないだろ

12 ：デフォルトの名無しさん：2008/01/04(金) 15:40:19

嘘を嘘と見抜けない香具師はC++を使うのは難しい。

13 ：デフォルトの名無しさん：2008/01/04(金) 16:06:47

柔軟な心を忘れないまま、アセンブリとCとC++のコツを全部抑えたら何でも作れる

14 ：デフォルトの名無しさん：2008/01/04(金) 19:45:10

アセンブリとCがあるならC++いらね

15 ：デフォルトの名無しさん：2008/01/04(金) 19:56:56

変態のおもちゃ化していることは認める。

16 ：デフォルトの名無しさん：2008/01/04(金) 22:33:04

JavaってさーC++のダメなとこを直したって宣伝してるけど
C++のダメなとこって具体的にどこでそれをどう直したんだろうな

17 ：デフォルトの名無しさん：2008/01/04(金) 22:42:24

JavaってC++に近づいてる

18 ：デフォルトの名無しさん：2008/01/04(金) 22:55:42

>>16
ポインタ
goto文
関数
構造体
多重継承
演算子オーバーロード
プリプロセッサ

19 ：デフォルトの名無しさん：2008/01/04(金) 23:02:43

>>18
そこに挙げてるのってどれも必要不可欠だと思うけど
それらがどう悪くてどう直したんだ？

20 ：デフォルトの名無しさん：2008/01/04(金) 23:40:50

結局のところ言語なんて慣れたもん勝ちなんだから、作法や作るうえでのプロセスなんか関係なくて、
実現できることと、できないことと、どのような用途に使われているかなどの実績を比べないと意味ないよね。

21 ：デフォルトの名無しさん：2008/01/04(金) 23:45:45

まあ言えるのは、JavaのVMはCとかC++で書かれてるよ。
ちょっと比較するにはレベルが違う言語かな。

22 ：デフォルトの名無しさん：2008/01/04(金) 23:56:46

>>20
その考えでよければオブジェクト志向なんでパラダイムは出てこなかったんじゃね？
派遣でもバイトでもできるだけ考える事をさせずにコーディングさせようぜってがJavaの考え方

ってか、プログラマってソフトウェア工学に関する専門書とか読んだりしないのか？
基本中の基本だと思うんだけど。
普通は>>20見たいなレスはウンコ漏れでもしない。

23 ：デフォルトの名無しさん：2008/01/05(土) 00:03:53

比較するというよりも得意分野のベクトルが逆なので、
C++/Javaの両刀使いが断然お得だな。

24 ：デフォルトの名無しさん：2008/01/05(土) 00:07:00

>>22

25 ：デフォルトの名無しさん：2008/01/05(土) 00:14:10

C++じゃないとまずいっていう用途をあげてみよう。

26 ：デフォルトの名無しさん：2008/01/05(土) 00:32:58

ウンコ漏れるほどテンプレート使いたいとき

27 ：デフォルトの名無しさん：2008/01/05(土) 00:51:26

リアルタイム性が必要なシステムとかメモリをきっちり把握して作りたいプログラムとかだな
具体的にはOS,コンパイラ,インタプリタ,デバッガとかか

28 ：デフォルトの名無しさん：2008/01/05(土) 01:27:02

>>22

読んだりするがマトモなコーディングすると上から煙たがられるｗ
バイトでもメンテできるように高度な実装技術は排除ｗ

29 ：デフォルトの名無しさん：2008/01/05(土) 03:43:23

良いも何も、仕事でＣ＋＋やれって言われたらやるし
仕事でＪＡＶＡやれって言われたらやる

俺みたいな雑魚に選択権は無いから、良いも悪いもどーでもいいぜ

30 ：デフォルトの名無しさん：2008/01/05(土) 15:22:03

>>27
C++を使うならCで十分だと思う

31 ：デフォルトの名無しさん：2008/01/05(土) 15:26:27

再利用性（笑）

これは本当に（笑）をつけたくなる

32 ：デフォルトの名無しさん：2008/01/05(土) 15:44:45

>>29
C++でやれって言われたら、その妥当性を検討して
（=今後発生する問題を想定し列挙して）
妥当でなければ妥当な案を提案する。おそらくは
却下されるんで指示通りにやる。で、あとで問題が
起きたときあのときこういう提案をしていました、と
主張して、問題の対処において、こちらが有利になる
ような交渉の布石とする。

逆も同じ。

33 ：デフォルトの名無しさん：2008/01/05(土) 17:32:12

なにか一つと言われればC/C++だし、複数でもC/C++とJavaかLLかみたいな
感じだからなあ。。
5年以上プログラムやるつもりならやってもいいというかやるべきだと思うけど、
プログラムは2,3年で卒業みたいな上流工程の人はやらない方がいいだろうね。

34 ：デフォルトの名無しさん：2008/01/05(土) 17:39:47

死ぬまでやるさ
これしか残ってないからな

35 ：デフォルトの名無しさん：2008/01/05(土) 19:05:30

C++でできてCでできないことってあるの？

36 ：デフォルトの名無しさん：2008/01/05(土) 19:08:48

あります。

37 ：デフォルトの名無しさん：2008/01/05(土) 20:02:55

アプリケーションの機能としては無いっていってもいいんじゃね？
ユーザーからはC/C++のどちらで開発されててもわからんわけだし。

38 ：デフォルトの名無しさん：2008/01/05(土) 20:07:28

オブジェクト指向風のことはCでもできる。
マニアックなテンプレート相当なことはCだと無理かな。
それ以外なら、若干めんどいけどCでも頑張れると思う。

39 ：デフォルトの名無しさん：2008/01/05(土) 20:29:36

Javaだと簡単にできるのにC++じゃすっげーめんどいことってなんかある？
ガベコレ以外で

40 ：デフォルトの名無しさん：2008/01/05(土) 20:30:44

馬鹿に使わせる

41 ：デフォルトの名無しさん：2008/01/05(土) 20:48:02

C++ではできて、Cではできないことなんて無いんじゃないの？
オブジェクト思考なんて、Cで別言語を書いてそこで使えばできないわけじゃないし。

そういう話じゃない？

42 ：デフォルトの名無しさん：2008/01/05(土) 20:54:52

javaとC++のスレでなんでCとC++の話してんだ？

43 ：デフォルトの名無しさん：2008/01/05(土) 20:55:41

他人のソース解読とか面倒

44 ：デフォルトの名無しさん：2008/01/05(土) 21:53:09

>>39
C++はリフレクションが貧弱すぎて困るな。
マクロとかで型ごとにリフレクション実装コード書けば
ある程度のことはできるが、めんどいし汚い。

45 ：デフォルトの名無しさん：2008/01/05(土) 23:00:54

C++でリフレクション相当のことをやりたい場合にはtraits使ったりtemplateを駆使したりと大変だわな

46 ：デフォルトの名無しさん：2008/01/05(土) 23:17:32

そもそもネイティブ前提の言語で動的リフレクション実装されてるのってそうそう無い罠。

47 ：デフォルトの名無しさん：2008/01/05(土) 23:31:01

一粒で二度おいしい思いをするのがC/C++コンパイラ
マシン移行面を考えるとC++は不利。

48 ：47：2008/01/05(土) 23:34:20

追記：
GUIのアプリケーションの開発にはC/C++はJavaより不経済。
ファームウェア（カスタムLSIへの実装ソフト）向けにはC/C++がJavaより有利。
更に、高速性を求めるならばC。

49 ：デフォルトの名無しさん：2008/01/05(土) 23:50:53

WindowsのGUIアプリ作るなら、個人的にはSwingは無い。
JavaのGUIはSwingしか知らんのだが、挙動が遅すぎる。

LinuxならJava使うかなぁ。楽だから。
WindowsでGUIなら今はC#＋.NETを推したい。楽だから。

.NETも重たいアプリ作るとモッサリするんだよなぁ・・・。

50 ：デフォルトの名無しさん：2008/01/05(土) 23:52:44

>>22
ソフトウェア工学に関する専門書をあげてみてくれんか？できたら日本語のを頼む。
たまたま見たソフトウェア工学らしき本は、クライアントの要求に対してどうのこうのという内容だった。
でもこれは22がいうものと違うんだと思う。

51 ：デフォルトの名無しさん：2008/01/05(土) 23:52:46

そらそうだ

52 ：47：2008/01/06(日) 00:04:15

>>49
やっぱそうだよね。
セカンドマシンで一気にLinux＆Ooo＆JVM。

53 ：デフォルトの名無しさん：2008/01/06(日) 00:08:03

OOoじゃないのか。

54 ：47：2008/01/06(日) 00:10:04

>>53
済まん、そうだった

55 ：デフォルトの名無しさん：2008/01/06(日) 00:18:16

JavaのGUI使ったアプリなんて見たこと無いけどな

56 ：47：2008/01/06(日) 00:24:23

>>55
そこらじゅうにある。
携帯のゲームもそうだし。

57 ：47：2008/01/06(日) 00:30:05

OSのないプロセッサ上でもCならアプリを構築できる

58 ：デフォルトの名無しさん：2008/01/06(日) 00:40:36

>>55
マッカー相手にJavaのGUIアプリ作ってる人いた
その人にC++とJavaってどうなの？みたいな質問したら、
C++に比べるとJavaは馬鹿でもおｋみたいな返答だった。
バグの原因の大半＝メモリ管理のどうので

59 ：デフォルトの名無しさん：2008/01/06(日) 00:45:25

>>55
Eclipse はどうなってしまうんでしょうか ...

60 ：47：2008/01/06(日) 00:48:22

>>58
C++でGUIアプリの開発をLinuxの元でやってやれなくは無いが、
高度なスキルが要求される。
C++ &　Qt　にてGUIアプリを構築というのは知っている。
当然、DBはPostｇｒｅＳＱＬだな。
組込みのばらまきの世界なんてそんなもの。

61 ：47：2008/01/06(日) 00:51:39

>>59
その話が出てくるのを待っていた。

ＥｃｌｉｐｓｅはＩＢＭ陣営
ＮｅｔＢｅａｎｓはＳｕｎ陣営

俺はＮｅｔＢｅａｎｓの方が好み。

62 ：デフォルトの名無しさん：2008/01/06(日) 00:53:51

>56
携帯ゲームだけじゃん
クライアントがwindowsならjavaのguiは出番がない。
１０年前、アプレットは絶対流行るかと思ったけどなぁ、ぜんぜん流行らなかったなー

63 ：デフォルトの名無しさん：2008/01/06(日) 00:59:57

バカでも使えてバカしか選ばないのがJava
バカには使えないけどバカしか選ばないのがC++

64 ：デフォルトの名無しさん：2008/01/06(日) 01:00:03

>>62
＞携帯ゲームだけじゃん
だろうなｗ　
技術者の活躍の場が偏在なんだろｗ　電話会社に多く捕まった
（厳密には、ゲームソフトメーカー）

＞クライアントがwindowsならjavaのguiは出番がない。
やって見て解ったんだが、起動が遅い。
出番がないと言う表現は確かにぴったりだな。

65 ：デフォルトの名無しさん：2008/01/06(日) 01:00:15

>>56
JavaGUI代表的なアプリを聞かれてうさんくさい携帯のオモチャ出すようじゃJavaの擁護にならなくねーか？

>>59
eclipseのGUIはJavaだけどJavaじゃないのよね

66 ：デフォルトの名無しさん：2008/01/06(日) 01:03:08

JUDEってJavaだよね。
起動が遅いし、時々すんげー固まる(GC?)
まあ、素直にC++の方がいいような。

67 ：デフォルトの名無しさん：2008/01/06(日) 01:05:33

>>65
なにが言いたいのかよくわからんｗ
Ｊａｖａの擁護って何？

68 ：デフォルトの名無しさん：2008/01/06(日) 01:09:17

>>65
Ｊａｖａは何向けの言語か解ってるのかな？

69 ：デフォルトの名無しさん：2008/01/06(日) 01:09:59

意図的でなければ全角混ぜるのはやめてくれ。

70 ：デフォルトの名無しさん：2008/01/06(日) 01:13:07

>>69
なんで？

71 ：62：2008/01/06(日) 01:14:43

＞64
実は最新のＪＡＶＡだと結構早いっていう噂を耳にしたことがある（Java6か7か8。どれか忘れた）
実状はどこも1.3.1とかだから遅すぎてやってられんです
ちなみにjavaでC/S型のwindowsアプリのプロジェクトやったことあるけど、ＶＢ6と比べて圧倒的に負けていたよ

72 ：デフォルトの名無しさん：2008/01/06(日) 01:15:03

しょぼいブラウザで閲覧してるのか？しょうがない奴だな>>69

73 ：デフォルトの名無しさん：2008/01/06(日) 01:15:17

>>70
気持ち悪いから。

74 ：デフォルトの名無しさん：2008/01/06(日) 01:15:43

>>72
専ブラでも分かるから。

75 ：デフォルトの名無しさん：2008/01/06(日) 01:16:43

>>71
クラスライブラリの効果だろうね。

76 ：デフォルトの名無しさん：2008/01/06(日) 01:18:22

>>73
改行にもこだわる奴もいるけど、馬鹿扱いされるよ。
そんな本筋から逸脱したレスばかりしてると。

77 ：デフォルトの名無しさん：2008/01/06(日) 01:20:31

君のテクニックで倍角を半角に変換するアドオン作っちゃよ？
君ならできるだろ？　>>73

78 ：デフォルトの名無しさん：2008/01/06(日) 01:20:54

>>76
そうだね。おやすみ。

79 ：デフォルトの名無しさん：2008/01/06(日) 01:21:35

>>71
J2SE7ではSwingのF/WがEoD的な改善されるようだけど、パフォーマンス的に改善は触れてないよ
JSRでもそこら辺無くない？

80 ：62：2008/01/06(日) 01:24:59

ハロワの求人票に「ＪＡＢＡ」と書く企業もあるから全角くらいで気にするな

フリーワード検索に「ＪＡＢＡ」で検索すると１５件も引っかかる（お試しあれ、半角不可の仕様だから「ＪＡＢＡ」は全角で検索して）

81 ：71：2008/01/06(日) 01:28:38

>79
すまん、噂で聞いただけだから私は詳しいことは知らんのですよ。
バージョンがあがる度に速度が上がっていると聞きました

82 ：デフォルトの名無しさん：2008/01/06(日) 01:46:16

javaだと簡単に作れてC++だと作れないものってある？

83 ：デフォルトの名無しさん：2008/01/06(日) 01:51:38

C++ を改善したのがJavaだがｗ

84 ：デフォルトの名無しさん：2008/01/06(日) 02:27:34

×改善した
△改悪した
○馬鹿でも使えるよう改造

85 ：デフォルトの名無しさん：2008/01/06(日) 02:30:28

>>84
じゃあ、俺は○に1億ｗ

86 ：デフォルトの名無しさん：2008/01/06(日) 05:25:30

C++が良いのは認めるとして
>>1はこの板のどこをどう見て「C++良いって意見ばっか」ととったのだろうか

87 ：デフォルトの名無しさん：2008/01/06(日) 06:53:24

ほんとは言語なんて一つでいいんだけどね。できることはかわらんし。

88 ：デフォルトの名無しさん：2008/01/06(日) 06:59:06

そうだね。Rubyさえあれば他は要らない。

89 ：デフォルトの名無しさん：2008/01/06(日) 07:05:28

いやVBだ

90 ：デフォルトの名無しさん：2008/01/06(日) 10:14:17

Brainf*ck

91 ：デフォルトの名無しさん：2008/01/06(日) 11:21:04

>>63
C++とJavaのどちらを選ぶかって話なら、Javaを選ぶのが正解ってわけか。
実際C++は趣味で使うなら面白いけど仕事でなら勘弁して欲しい言語だし。

92 ：デフォルトの名無しさん：2008/01/06(日) 12:02:58

ここまで来ても煽りばっかりでjavaがc++よりどう優れてるのかが全然出てこないのな

93 ：デフォルトの名無しさん：2008/01/06(日) 13:12:17

Java がバカでも使えるというのは十分長所だと思うな。
見ず知らずの奴と C++ でプログラムを作り合う気はしない。

94 ：デフォルトの名無しさん：2008/01/06(日) 13:32:53

バカをつっこんだら余計に開発が遅れるなんて
人月の神話にも出てくるソフト開発マネジメントの超基本じゃん。
C++程度も使いこなせないアホと仕事をせにゃならん時点で
そいつの能力、管理者の頭の程度、仕事の程度の低さなんかがよくわかるよ。

95 ：デフォルトの名無しさん：2008/01/06(日) 14:00:28

まずJavaの方がC++より古い言語だというのを確認すべきだ

C++は学者が作ったので色んなパラダイムを吸収できる柔軟性がある
そのためにのんびり次の規格を模索できる
イマ足りないものはboosterがなんとかしてくれる

Javaは現場のバカが作ったので柔軟性がないので
ガンガン機能を追加していくほかない
しかし、その精神はC++のそのものだな

96 ：デフォルトの名無しさん：2008/01/06(日) 14:02:35

>>94
仕事は金を稼いでなんぼなんです。プログラムスキルの有無なんて二の次なんです。
仕事を趣味のプログラムの延長上としか考えてない奴と一緒に仕事する他の人のことももっとよく考えてやって下さい。

97 ：デフォルトの名無しさん：2008/01/06(日) 15:09:55

>>96
仕事は金を稼いでなんぼなんです。プログラムスキルの有無も他人の苦労も二の次なんです。

98 ：デフォルトの名無しさん：2008/01/06(日) 15:12:32

仕事は生活をするためにしてるんです。会社なんて二の次なんです。
プログラムを仕事でしかやりたくない奴と一緒に仕事する他の人のことももっとよく考えてやって下さい。

99 ：デフォルトの名無しさん：2008/01/06(日) 15:57:20

C++にBoostがあるのはいいのだが、
CPANのように質より量的なリポジトリを作ろうという動きは無いのかね？

100 ：デフォルトの名無しさん：2008/01/06(日) 16:42:44

>>62
アプレットは流行らなかったかも知れないが
しぃペインターの様な物はなかなか面白い

101 ：デフォルトの名無しさん：2008/01/06(日) 16:51:15

>>99
boost file vault
boost sandbox
この辺がそれにあたるかも

102 ：デフォルトの名無しさん：2008/01/06(日) 18:04:41

>>99
C++はライブラリ化が難しいんだよなあ。ユーザの要求するパフォーマンスとか
機能とかが高いから、誰もが満足するものが作りづらい。

103 ：デフォルトの名無しさん：2008/01/06(日) 19:26:09

>>1
むしろ、なんでわざわざ素人が趣味で作ったしょぼい仮想マシンの上で、
がんばって低速にプログラムを動かそうとしてるのか。

104 ：デフォルトの名無しさん：2008/01/06(日) 22:26:42

カシオのポケコンCインタプリター使え

105 ：デフォルトの名無しさん：2008/01/06(日) 22:45:44

高校で使ってたがあれはなかなかメモリ制限がきつかった

106 ：デフォルトの名無しさん：2008/01/06(日) 22:50:10

OS無しでﾃﾞﾌｫはBASIC

107 ：デフォルトの名無しさん：2008/01/06(日) 22:56:14

8ビットマイコンでしょうか

108 ：デフォルトの名無しさん：2008/01/06(日) 23:00:51

16ビット

最初に買ったシャープのポケコンは8ビット。～大昔なので忘れた。
それで、消費者金融の支払い管理ソフトをBASICで作成していたな。

109 ：デフォルトの名無しさん：2008/01/06(日) 23:04:34

>>108
悪事に加担するのはさぞかし
気持ちが良かったでしょうな

110 ：デフォルトの名無しさん：2008/01/06(日) 23:14:04

その逆の立場だったんだけどorz

アパート含めて支払先17箇所の管理はやっぱコンピュータ使わないと。
ワープロ専用機全盛の時代。

当時としては、１つのプロジェクト仮に１０名程度いたとすると、個人でPCを
持ち込んでいたのは１名程度、２～３台のPCをオフラインで替わりばんこ
に使用orz

その頃はK&RのC、をよく使ったもんだ。

111 ：デフォルトの名無しさん：2008/01/06(日) 23:49:17

486DOSPC用のソフト開発にはTurboPascalとTurboC++とLSI-C試食版のどれがいいだろうか‥‥

112 ：デフォルトの名無しさん：2008/01/07(月) 00:07:16

ターボパスカルコンパイル速いからね！

113 ：デフォルトの名無しさん：2008/01/07(月) 00:07:53

よし、TurboPascal5.5落としてくる

114 ：デフォルトの名無しさん：2008/01/07(月) 02:54:07

これなんか、かなり良かったのでリンク貼って置くね。

体感的にはボーランドより早かった。

http://www.digitalmars.com/

115 ：デフォルトの名無しさん：2008/01/07(月) 18:21:08

>>22
はやくしろクズ

116 ：デフォルトの名無しさん：2008/01/07(月) 22:14:22

マジレスすると最近はC++の評価悪いよ。擁護派も関数型とかに寄り道してんじゃね？
でもこの釣られ具合は奇妙。やっぱりC++に対するなんかはあるんだよな。

117 ：デフォルトの名無しさん：2008/01/07(月) 22:47:59

誰がどこでどういう基準で評価したんだろうね

118 ：デフォルトの名無しさん：2008/01/07(月) 22:48:54

Windows系はC++で開発された。
Ｕｎｉｘ系はCで開発された。
C++が流行ったのは今から20年前。
今は、JavaとCが流行り。

119 ：デフォルトの名無しさん：2008/01/07(月) 22:52:46

処理速度
Ｃ＞C++ ＞Java
ﾌｧｰﾑｳｪｱはCに依る開発が主流。

120 ：デフォルトの名無しさん：2008/01/07(月) 23:12:43

コンパイル速度
Java > C > C++
C++ は何で? っていうくらい時間が掛かる時があるね

121 ：デフォルトの名無しさん：2008/01/07(月) 23:12:48

今の流行りがjavaとcなんて初めて聞いたぞ
cはともかくjavaなんてとっくにブームは過ぎてるし

122 ：デフォルトの名無しさん：2008/01/07(月) 23:17:19

>>121
そこで頑張っても意味無くね?

123 ：デフォルトの名無しさん：2008/01/07(月) 23:18:02

cもjavaも需要があるからいいさ
初心者にやたらとC#とjavaばかり薦める奴はいるが

124 ：デフォルトの名無しさん：2008/01/07(月) 23:21:49

C/C++なんて進めても
現代を生きるボーイは投げ出すだけ

125 ：デフォルトの名無しさん：2008/01/07(月) 23:23:42 BE:209677267-2BP(294)

>>121
求人サイトで、JavaとかCとかVBとか言語で検索かけると、どこのサイトもたいがいJavaが一番ヒット件数多いぞ。

126 ：デフォルトの名無しさん：2008/01/07(月) 23:37:57

うんざりなんだよ
CだJavaだVBだRubyだ
そんな話はもう
そんなことを話せば話すほど俺たちは浅ましく醜く這い回ってることになる
そんな仕組みを考えた馬鹿野郎がほくそえむ
悔しくねえのかよおおおおおおおお

127 ：デフォルトの名無しさん：2008/01/07(月) 23:40:04

javaが流行ったのって2000年前後だろ
その次の流行りがC#とruby
今はなんだろhaskellとかschemeの関数型言語全般か

128 ：デフォルトの名無しさん：2008/01/08(火) 00:01:02

流行ってるってどの界隈での話なんだよ。
業務なのか、趣味グラマの間でなのか。

129 ：デフォルトの名無しさん：2008/01/08(火) 00:01:56

>>127
>その次の流行りがC#とruby

C# が流行ったなんて聴いた事が無い。Haskell や Scheme が
流行ったのはだいぶ前。Erlang が流行る前くらいでしょ。
Ruby の前には Python がかなり持ち上げられていた。

今は言語の流行り廃りと言う観点では無風状態だね。

130 ：デフォルトの名無しさん：2008/01/08(火) 00:03:55

良い物は残る
今は黙してれば良いのじゃ

131 ：デフォルトの名無しさん：2008/01/08(火) 00:05:56

HaskellやらSchemeなんかよりはC#の方が明らかに流行ってるし

132 ：デフォルトの名無しさん：2008/01/08(火) 00:09:32

関数型はそんなには受け入れられない
C#やJAVAとは違うユーザ層というかね
用途もC#やJAVAの方が幅広いんじゃないのかね
単純には比べられまい

133 ：デフォルトの名無しさん：2008/01/08(火) 00:10:23

スイーツ(笑)な奴がいるな。
メディアに踊らされるのは勝手だが脳内で程ほどにな。

134 ：デフォルトの名無しさん：2008/01/08(火) 00:12:12

という事にしたいのですね:-)

135 ：デフォルトの名無しさん：2008/01/08(火) 00:13:22

なんかもう新しい汎用言語ってでなさそうな感じなのかな?

136 ：デフォルトの名無しさん：2008/01/08(火) 00:15:37

C#とjavaはスポンサー企業がいて提灯記事を書く御用メディアがいるから流行ってるように見えるんだよ
で、その提灯記事を本気にしちゃう程度の奴が信者になって考えるのを止めるんだ

137 ：デフォルトの名無しさん：2008/01/08(火) 00:16:41

妄想もここまで来ると怖いな

138 ：デフォルトの名無しさん：2008/01/08(火) 00:20:45

IFが単純でパフォーマンスなんてどーでもいいような
オーダーメイドのビジネスアプリを
ハイスペックなPCやサーバでごりごり動かしてる分には
使い勝手がよろしかったと思うが

139 ：デフォルトの名無しさん：2008/01/08(火) 00:28:43

そういう意味では、今のコンピュータはどれを買っても超ハイスペックだよね

140 ：デフォルトの名無しさん：2008/01/08(火) 00:33:02

C 0x として C にオブジェクト指向風のシンタックスシュガーを
加えた言語が出来たら C++ を捨てられる

141 ：デフォルトの名無しさん：2008/01/08(火) 00:46:41

本当は一つの言語をもっと深く使い込む社会が一番理想だと思う。
もちろん分野や用途によってさまざまな言語や技術の特化があっても良いが。
一番悪いのは「新しい技術で市場を独占してやろうぜ」みたいな営業根性で
糞技術を無理やり普及させようとする流れ。言語で言うとC＃かな。

142 ：デフォルトの名無しさん：2008/01/08(火) 01:20:38

>>141
プログラム書くと、入出力とか状態の処理とかで、気がつくとなんかのインタプリタを
書いているようなことってない？
そういうとき、処理に適した処理系が生であったらなぁと思うのは自然だと思うんだけど。
で、そういうのって結構通信とか、I/Oとかのアーキテクチャに左右されると思うので、
やっぱり時代時代で異なる言語が使われるのはある程度予想できるかなと思う。

143 ：デフォルトの名無しさん：2008/01/08(火) 01:26:28

別にC#は糞言語じゃないだろ。
M$の今のVSでもwin32api直叩きでコード書いても
特に問題無い訳でM$の方針としては
ネイティブでないと書けない物はネイティブで
それ以外のGCにまかせても問題無いような
プログラムは.net化しようという方針であって
それでもunsafeも化としてるんだから

まぁ、その、要はwindows使う限り
M$様にしたがえって事だろ。

144 ：デフォルトの名無しさん：2008/01/08(火) 02:24:51

>>120
119に対する皮肉かな？　つか俺が119なんだがｗ
コンパイル速度を気にするような立場なのか？
俺は立場上、処理速度を重視し言語の選定もやってる訳だがｗ

最近の学卒の子は大概Javaは使える用に飼い慣らされて来ているが
Cの解析やらせると、関数へのポインタ辺りで分けワカメが多い。

145 ：デフォルトの名無しさん：2008/01/08(火) 02:27:26

関数はmain()のみって奴よりはマシだけどな。

146 ：デフォルトの名無しさん：2008/01/08(火) 02:33:49

せっかくC++使わせてるのにCライクなコーディングをしてくれるorz
まあ、俺には良くわかるけどなしかし、・・・・・

147 ：デフォルトの名無しさん：2008/01/08(火) 02:44:38

LBのWin軽快ツールズ入れたら却って処理が重くなったし、セキュリティソフト
と干渉してPCが不安定になった。
全く、ツールに監視系の機能を持ち込むなよなｗ

148 ：デフォルトの名無しさん：2008/01/08(火) 06:14:41

最近はファンクタのおかげで処理速度はC++>Cなんだがな

149 ：デフォルトの名無しさん：2008/01/08(火) 08:40:45

ガベコレは構文がシンメトリーでないから糞

150 ：デフォルトの名無しさん：2008/01/08(火) 08:42:17

それは無いわ。C++ は LL ばりに無駄な処理が多いからな。

151 ：デフォルトの名無しさん：2008/01/08(火) 08:42:57

150 は >>148 へのレスね

152 ：デフォルトの名無しさん：2008/01/08(火) 08:55:13

C++なんか窓以外では永久にニッチ言語のままだろw

153 ：デフォルトの名無しさん：2008/01/08(火) 09:23:00

>>150
無駄な処理って例えば何かな？言えるかな？
c++とc++コンパイラは無駄な事なんて一切しないぞ。コードに明示してないことはやるが。
あとc++をcより速くすることは可能だ。これはファンクタがどうこうじゃなくてinlineの力だ。

154 ：デフォルトの名無しさん：2008/01/08(火) 12:26:06

派遣も派遣同士で慰めあってほしいよな。
正社員に申し込んでくるなんて図々しいにも程がある。

155 ：デフォルトの名無しさん：2008/01/08(火) 14:00:37

Windows VS UNIX
(C++) (C)

156 ：デフォルトの名無しさん：2008/01/08(火) 14:03:02

某超一流企業で委託社員ですが、何か？

157 ：デフォルトの名無しさん：2008/01/08(火) 14:04:43

同じ本流ですが、正社員の平均賃金以上はしっかり稼いでる委託社員ですが、何か？

158 ：デフォルトの名無しさん：2008/01/08(火) 14:38:08

結局、ＵＮＩＸの尻ぬぐいはＷｉｎｄｏｗｓと言うことで

159 ：デフォルトの名無しさん：2008/01/08(火) 19:13:59

上手くやれば最後の境界のmallocを特別処理するだけで済むけどね。

160 ：デフォルトの名無しさん：2008/01/08(火) 19:15:48

ごめん誤爆。

161 ：デフォルトの名無しさん：2008/01/08(火) 20:30:26

>>140
Objective-Cですか

162 ：デフォルトの名無しさん：2008/01/08(火) 20:39:41

>>153
inlining は C++ だけじゃなく C だって Lisp だって出来るよ
C++ で作ったアプリを C 並みに速く起動する事は無理だけどね
C 並みに小さいバイナリを生成するのも無理

>>161
仕方が無いけど ObjC は C++ より遅いからなあ...

163 ：デフォルトの名無しさん：2008/01/08(火) 20:43:31

std::sortはqsortより速いというのはよく聞く話。
Cはさすがにコールバックをインライン化して展開するとか㍉だからねぇ。

C++がCより起動が遅いというのは意味がわからん。
初期化オブジェクトが増えてるから、という話か？

164 ：デフォルトの名無しさん：2008/01/08(火) 21:13:52

テレビで女子アナが腹筋してるけど
喘ぎ声に聞こえなくもない

165 ：デフォルトの名無しさん：2008/01/08(火) 21:27:20

>>163
何でわからんの?

166 ：デフォルトの名無しさん：2008/01/08(火) 21:45:12

アプリの起動とC++かCかってのは全然別の話だろ

167 ：デフォルトの名無しさん：2008/01/08(火) 22:01:10

>>166
C++＝バイナリを小さく出来ない＝起動が遅い
あとマングリングとかもキモイ
仕様もでかすぎ
コンパイル超遅い
ソースコードがキモイ
シンタックスが汚すぎ
仮想関数遅い
テンプレート変態過ぎ

168 ：デフォルトの名無しさん：2008/01/08(火) 22:01:57

cin, wcinあたりの初期化のぶんはCよりよけいに時間がかかるな

169 ：デフォルトの名無しさん：2008/01/08(火) 22:06:37

C++はどんどん変態言語になりつつあるな

170 ：デフォルトの名無しさん：2008/01/08(火) 22:07:57

言うまでもないが変態は最上級の褒め言葉

171 ：デフォルトの名無しさん：2008/01/08(火) 22:09:18

そういうレベルのことが気になるんならCを使ったらいいんじゃないの

172 ：デフォルトの名無しさん：2008/01/08(火) 22:10:24

変態というか露悪趣味的だな

173 ：デフォルトの名無しさん：2008/01/08(火) 22:26:13

彼らが脇目も振らずに変態道を突き進んでくれたおかげで
今日の『脱 C++ 化』が進んでくれて嬉しいよ。
おかしな勘違いをして美しい言語なんかを目指していたら
今頃 C を使う人間なんていなかっただろうと思うと、
本当に良かった。

174 ：デフォルトの名無しさん：2008/01/08(火) 22:29:37

>>167
1つ気になった。
仮想関数呼出をあれ以上速くできるの？

俺には、同じ仮想関数を複数回呼ぶときにはキャッシュすることくらいしか思い付かない……。

175 ：デフォルトの名無しさん：2008/01/08(火) 22:34:18

javaでC++のtemplateと同じことが出来るなら今すぐjavaに乗り換えるんだが

176 ：デフォルトの名無しさん：2008/01/08(火) 22:53:18

>>143
俺的にはC#はそこそこ綺麗な言語だと思うが、.NET2.0は糞だ。
機能的にカバーしてる範囲が狭すぎて存在意義が感じられない。

177 ：デフォルトの名無しさん：2008/01/08(火) 23:00:26

c++って満足できるコンパイラすらないってどっかで見たけど。

boost ってやつを使うとき限定だったかな？

178 ：デフォルトの名無しさん：2008/01/08(火) 23:28:00

.NETもVB6と同じで使い込むほどに増えるAPI定義の山

179 ：デフォルトの名無しさん：2008/01/08(火) 23:32:36

C++/CLIなら殆どのことは#include <windows.ｈ>で…

180 ：デフォルトの名無しさん：2008/01/09(水) 00:22:30

>168
別にiostream使わないなら初期化はさぼれるでそ。
自分でスタートアップルーチン書けばいいんだから

181 ：デフォルトの名無しさん：2008/01/09(水) 00:22:58

>>174
それ以前に、ちゃんと
「C++が仮想関数を使ってやることをCのやり方でやった時」と比べて「遅い」
と言ってるのかどうかが気になるところ。

182 ：デフォルトの名無しさん：2008/01/09(水) 04:10:42

仮想関数の機能の本質は処理の切り替えであって、switch-caseのコストと同等。
問題は仮想関数はインライン化できないことであって・・続きはEfficientC++で。
C++はCを含んでるんだから、仮想関数が遅い場面ではFunctor・インラインswitch-case
とかを選べばいいわけで、その辺のパフォーマンス調整の自由度の高さが魅力。
他の言語は普通仮想関数とかはそれなりに隠蔽されてて、いじれんからねぇ。

183 ：デフォルトの名無しさん：2008/01/09(水) 08:48:13

そんなとこ普通いじらんでいいよ
最適化方法は他にも沢山あるんだから

184 ：デフォルトの名無しさん：2008/01/09(水) 14:02:15

C++はiostreamが嫌ならstdio使えばいいだけの話だからねぇ

185 ：デフォルトの名無しさん：2008/01/09(水) 14:05:07

イオス！

186 ：デフォルトの名無しさん：2008/01/09(水) 14:05:57

スターディオ！

187 ：デフォルトの名無しさん：2008/01/09(水) 14:06:52

いや、stdioって切り替えできない標準入出力じゃん。
Windowsアプリでstdio弄ってるソース（←オプソ系が結構使ってる）はコンパイルリンクできないし。

188 ：デフォルトの名無しさん：2008/01/09(水) 14:07:44

ウブントゥ！

189 ：デフォルトの名無しさん：2008/01/09(水) 14:18:26

えす、ティー、エゥ！

190 ：デフォルトの名無しさん：2008/01/09(水) 16:39:54

リダイレクトで別に立ち上げたサーバーアプリ上に作ったストリームに対して出力
とかも出来るんだろうなぁ
stdioって以外と凄そう

191 ：デフォルトの名無しさん：2008/01/09(水) 17:38:39

＞stdioって以外と凄そう

いや、Windowsならできない。

192 ：デフォルトの名無しさん：2008/01/09(水) 18:19:06

>>191
できないわけないだろ。パイプ作ってCreateProcessの引数で渡すだけ。

193 ：デフォルトの名無しさん：2008/01/09(水) 19:26:44

Windowsで、明示的にやりたければ_openoshandleして_fdopen。VC++限定だけど。

194 ：デフォルトの名無しさん：2008/01/09(水) 19:43:13

>>184
何か自虐的だね
そんな事をしても結局 C には追い付けないのに

195 ：デフォルトの名無しさん：2008/01/09(水) 19:47:29

>>194
と、C++に挫折したC厨が悔し紛れに呟いております

196 ：デフォルトの名無しさん：2008/01/09(水) 20:05:10

>>177
Comeauとかどうよ

197 ：デフォルトの名無しさん：2008/01/09(水) 20:06:53

>>195
挫折ってのは、素晴らしい物に到達出来なかった時に使う単語だぜ。

198 ：デフォルトの名無しさん：2008/01/09(水) 20:12:17

>>191
初期状態でコンソール開いてないだけで
Windowsかどうかは関係ないだろ

199 ：デフォルトの名無しさん：2008/01/09(水) 20:14:55

JavaだったらOSがどうこう無視してオブジェクト間通信ができるぜ

200 ：デフォルトの名無しさん：2008/01/09(水) 20:26:34

C++ で書かれた有名なソフトウェア

Firefox
Thunderbird
OpenOffice.org
iTunes
Java VM

MS と Adobe は C++ が多そうだな

201 ：デフォルトの名無しさん：2008/01/09(水) 21:23:22

windows用として店に並んでるソフトはことごとくそ++じゃないか？

202 ：デフォルトの名無しさん：2008/01/09(水) 22:57:25

>>201
g++ですか?

203 ：デフォルトの名無しさん：2008/01/09(水) 23:05:43

MSがJava陣営じゃない=ソフトウェア開発はJavaではなくVisualなんちゃら

204 ：デフォルトの名無しさん：2008/01/09(水) 23:20:04

>>201
かな入力ですか？

205 ：デフォルトの名無しさん：2008/01/09(水) 23:49:37

こんなところに名探偵が

206 ：デフォルトの名無しさん：2008/01/10(木) 04:07:39

パウロが

207 ：デフォルトの名無しさん：2008/01/10(木) 05:03:56

C++09 ではガベコレが使えるようになるのかな？

208 ：デフォルトの名無しさん：2008/01/10(木) 06:30:19

>>207

ならんだろ。
Javaみたいにサンドボックスないとできないんだから。
それに、GB勝手に走られて困るケースも多い。

209 ：207：2008/01/10(木) 06:52:31

>>208 こんなのがあったのでちょっと期待していた

State of C++ Evolution (Toronto 2007 Meeting)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2336.html

Transparent Programmer-Directed Garbage Collection for C++
Hans-J. Boehm Michael Spertus
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2310.pdf

210 ：デフォルトの名無しさん：2008/01/10(木) 08:50:36

201

その昔、delphiってのがあってだな。。。

211 ：デフォルトの名無しさん：2008/01/10(木) 08:59:19

残念、今でもある。

212 ：デフォルトの名無しさん：2008/01/10(木) 09:00:52

パッケージソフトでDelphiってそんなにあるかね？

213 ：デフォルトの名無しさん：2008/01/10(木) 09:21:36

パッケージソフトに多いっぽい。
使われてるビットマップボタンとウィンドウの挙動で分かる。

214 ：デフォルトの名無しさん：2008/01/10(木) 17:07:05

BCBじゃねーの？
pascalなんてはやんねーよ。

215 ：デフォルトの名無しさん：2008/01/11(金) 14:39:28

>>207
C的に考えると、メモリ管理は言語仕様でするべき事柄じゃない気もするが、
new演算子などというものを言語仕様に取り込んだC++は言語仕様の責任でメモリ管理するべきな気もする。
だとすると、ポインタを使うのはナンセンスなので参照にして。。。Javaじゃん

216 ：デフォルトの名無しさん：2008/01/11(金) 21:09:30

>>215
現状、auto_ptr, tr1::shaed_ptr

217 ：デフォルトの名無しさん：2008/01/12(土) 00:26:19

真にマンセーしかない言語はscheme

218 ：デフォルトの名無しさん：2008/01/12(土) 15:44:13

C#ってJAVAの人気にマイクロソフトが慌てふためいて、作った言語だよね。たしか、、
これって使ってる人多いの?

219 ：デフォルトの名無しさん：2008/01/12(土) 16:04:27

>>218
慌てふためいたというよりも、Javaを皮肉ってJavaを超える言語に
したって感じだな。ISO/IECにも規定される位だからよく考えられている。

220 ：デフォルトの名無しさん：2008/01/12(土) 16:59:36

>>219
M$社員乙

221 ：デフォルトの名無しさん：2008/01/12(土) 17:09:00

gccのC#フロントエンドってもうあったりする？

222 ：デフォルトの名無しさん：2008/01/12(土) 17:20:09

Monoしかねーだろ

223 ：デフォルトの名無しさん：2008/01/12(土) 17:48:45

>> 219
その規格ってやつだが、普通のC/C++のように、
はじめに言語仕様ありきではないところに激しく違和感。
付属書として定義された「標準ライブラリ」はそのまんま.netだし、
System.Stringなしではエントリポイントさえ書けないし、
ようするに汎用言語じゃないんだぜ。
ソースファイルの文字コードとか、
コメントの書き方（付録として）までとやかく言うんだぜ。
未来を担う言語になるというのであれば、
各プラットフォーム用のCLIをMicrosoftが責任を持って作るべきです。

224 ：デフォルトの名無しさん：2008/01/12(土) 17:54:53

CLIはあるだろ。実装がないだけで。

225 ：デフォルトの名無しさん：2008/01/12(土) 18:13:03 BE:209677267-2BP(294)

>>223
Cの規格こそ、実装が先にありきだろ。

226 ：デフォルトの名無しさん：2008/01/12(土) 18:15:39

んなこと言ったらJavaだって汎用言語じゃねぇーですよ

227 ：デフォルトの名無しさん：2008/01/12(土) 18:28:10

System.string 使ってるから汎用言語じゃないって理屈が分からん。
Microsoft.String とかだったらわかるけど。

228 ：デフォルトの名無しさん：2008/01/12(土) 18:58:00

Windows.Formsなんかは標準化から外されて入っていないけど、
逆に入ってた方が他OS用のクローンは作りやすかったんじゃないの？

229 ：デフォルトの名無しさん：2008/01/12(土) 19:21:15

処理速度で比べるならアセンブリが最強
しかし移植性・生産性共に最悪
アセンブリでゲームとか作る廃人いたらおもしろそう

230 ：デフォルトの名無しさん：2008/01/12(土) 19:27:46

CとASMはまだ判るけど、C++は難しすぎだ。

231 ：デフォルトの名無しさん：2008/01/12(土) 19:59:38

>>230
CとASMが判るなら、C++も判ると思うのだが...

232 ：デフォルトの名無しさん：2008/01/12(土) 20:05:37

>>230
別に難しくねーよ。慣れの問題。

233 ：デフォルトの名無しさん：2008/01/12(土) 20:43:06

>>223
昔と違って、最近の技術の規格ってのは企業が自社技術を広める上で
「ハクを付ける」ために取得するのがほとんど。
広まって派生が増えてから「統一するため」に作るのが規格だと思ってるなら、
広まる前から「広めるため」に作る規格には違和感あるかもね。

>>225
で、「言語仕様ありき」ってのは、C/C++の規格は
「広まった物を規格化(統一)するための規格」ってことじゃないのかな。

>>223が言ってることの具体的な部分は、
ANSIでC/C++の規格が決まった時には、その規格に基づいて実装されたコンパイラは無かった。
C#の場合、自社で作った時の規格をそのままISOに持っていっただけだから
今のMSが出してるC#のコンパイラはISOの規格に基づいて実装されてる(と言えるかもしんない)
っつーことか？

234 ：デフォルトの名無しさん：2008/01/12(土) 20:50:50

>>228
ControlクラスにはWndProcなんてメソッドがあるくらい、
物凄くWin32ベッタリだぞ。

235 ：デフォルトの名無しさん：2008/01/12(土) 21:03:53

WndProcのどこがMS依存なんだよ

236 ：デフォルトの名無しさん：2008/01/12(土) 21:11:52

メッセージを処理するプロシージャ、って別にWindows特有の概念でもないよな。

237 ：デフォルトの名無しさん：2008/01/12(土) 22:15:46

ハロウィーン文書とか読んだらとてもC#を推す気にはなれない

238 ：デフォルトの名無しさん：2008/01/13(日) 01:32:27

いまさらわざわざC++が良いなんて意見もあんまりないような・・
良くも悪くももう超実用だからねぇ

239 ：デフォルトの名無しさん：2008/01/13(日) 01:43:24

C++ の数少ない評価ポイントだよな >> 実用されている

240 ：デフォルトの名無しさん：2008/01/13(日) 01:46:29

だが実際潰しの効く言語は飯の種になる。

241 ：デフォルトの名無しさん：2008/01/13(日) 01:46:48

JavaとかC#はJITコンパイラを通してももっさりしているから
キビキビ動くC++は重宝してんだろ

242 ：デフォルトの名無しさん：2008/01/13(日) 01:50:13

OS（カーネル）を作れる言語はどうやっても生き残る。

243 ：デフォルトの名無しさん：2008/01/13(日) 01:51:26

>>235
どこまでのメッセージに対応するか次第だろうね。
IME関連とか単純にメッセージ投げるだけでは、あっても意味ないでしょ。

244 ：デフォルトの名無しさん：2008/01/13(日) 01:51:36

C++ でカーネル?
BeOS の事か

245 ：デフォルトの名無しさん：2008/01/13(日) 01:53:26

>>244
あ、C++に限らずって話でした。

俺OSっぽいやつならちらほら見かける>C++カーネル

246 ：デフォルトの名無しさん：2008/01/13(日) 02:16:28

WindowsもC++っぽくないか？
DLLのサイズとか見てるとそう思える

247 ：デフォルトの名無しさん：2008/01/13(日) 02:22:55

kernel 本体は exe じゃないの?

248 ：デフォルトの名無しさん：2008/01/13(日) 02:25:36

kernel本体はkernel32.dllだと思ってたが。

249 ：デフォルトの名無しさん：2008/01/13(日) 02:32:54

ntoskrnl.exeだっけ

250 ：デフォルトの名無しさん：2008/01/13(日) 07:30:11

WIN.COMしか知りません

251 ：デフォルトの名無しさん：2008/01/13(日) 10:18:35

え？お前ら自分でOS書いてみたりしないの?

252 ：デフォルトの名無しさん：2008/01/13(日) 16:04:12

マイクロカーネルに本体も糞もない

253 ：デフォルトの名無しさん：2008/01/13(日) 16:21:36

ある程度規模の大きいシステムを作るってのは目標ではあるけど
RPGゲームのベースシステム以上のものは作った事が無い俺でした

254 ：デフォルトの名無しさん：2008/01/13(日) 16:25:58

おれもメガバンクのバンキングシステムよりでかいのは作った事ないな。

255 ：デフォルトの名無しさん：2008/01/13(日) 16:28:25

amazonには5000万行のC++コードがある、って聞いたよ

256 ：デフォルトの名無しさん：2008/01/13(日) 16:42:36

>>255
どんだけぐちゃぐちゃな重複コードだらけなんだろうな・・

257 ：デフォルトの名無しさん：2008/01/13(日) 16:47:12

255のソースはバベル案内かな。
それによれば、かなりひどいことになってたらしい。

258 ：デフォルトの名無しさん：2008/01/13(日) 18:57:41

>>235
Windows以外のOSにもWndProcという関数があったのか（笑）
もちろん同じメッセージIDが送られてくるんだよな？

259 ：デフォルトの名無しさん：2008/01/13(日) 19:43:39

名前は自由だろ

260 ：デフォルトの名無しさん：2008/01/13(日) 23:36:34

「C++ オブジェクト指向プログラミング」って面白いよね、あのぶ厚い専門書。
今まで読んだプログラム関係の専門書で一番面白かった。

261 ：デフォルトの名無しさん：2008/01/13(日) 23:44:18

>>260
Amazonで検索したけど、そんな本ないよ。

262 ：デフォルトの名無しさん：2008/01/14(月) 00:09:07

>>261
「最新ANSI C++オブジェクト指向プログラミング」だった。

263 ：デフォルトの名無しさん：2008/01/14(月) 00:13:33

C++は言語のお勉強だけでお腹いっぱいになっちゃうのがいいところでもあるし悪いところでもある

264 ：デフォルトの名無しさん：2008/01/14(月) 00:19:37

>>262
前から気になってたけど良さそうだから買ってみるわ。

265 ：デフォルトの名無しさん：2008/01/14(月) 00:34:55

>>262
ぐげっ。
俺その本持ってるわ。
実際のプログラムが数多く載せてあるが、一通り試してみて
結構難しいと思った。

この本がきっかけでデザパタに興味を持ったんだけどね。

266 ：デフォルトの名無しさん：2008/01/14(月) 01:03:05

>>194
なんで？同等になるんじゃないの？

267 ：デフォルトの名無しさん：2008/01/14(月) 01:10:11

ならないよ

巨大な libstdc++ をロードしなきゃいけないし
例外機構とか余計な物が沢山入る

268 ：デフォルトの名無しさん：2008/01/14(月) 01:11:49

組み込み用途にはEmbedded C++とか使わないと苦しいけど
一般のPCやWSではC++でもCと同等以上。

269 ：デフォルトの名無しさん：2008/01/14(月) 01:17:00

言うだけなら幾らでもどうぞ

270 ：デフォルトの名無しさん：2008/01/14(月) 01:22:02

どうぞCでいつまでも苦しんで下さい。

271 ：デフォルトの名無しさん：2008/01/14(月) 01:24:20

面白い冗談だな。君も C++ のゴミコードに埋もれて楽しんでくれ。

272 ：デフォルトの名無しさん：2008/01/14(月) 01:27:29

君はCのゴミほどの価値もない糞コードにまみれて苦しんでくれ。

273 ：デフォルトの名無しさん：2008/01/14(月) 01:29:39

今度のレスは工夫が無くてつまらんな。
他に言う事が無いなら C++ の話に戻ろうぜ。

274 ：デフォルトの名無しさん：2008/01/14(月) 03:02:14

C++覚えた後に、Cでプログラム組めと言われても困るのは確かだよね
クラスもテンプレートも使わないでプログラムしろって、どんな罰ゲームですかみたいな

275 ：デフォルトの名無しさん：2008/01/14(月) 06:59:37

俺もそう思っていたが、関数型言語に触れてみてクラスは必須ではないことに気付いた。

276 ：デフォルトの名無しさん：2008/01/14(月) 07:14:37

・C++はゴミの塊だけど、他に使い物になる言語も無いし、仕方なく使うよ
・C++は変態のおもちゃだけど、自分は変態だから使うよ
・C++は最強のプログラミング言語だ！　他は糞

最近は一番下は絶滅したと思っていたけど…

277 ：デフォルトの名無しさん：2008/01/14(月) 10:01:21

まあ、オブジェクト指向言語ってGUIの為にあるって言っても過言でないからね。

反論は認める。

278 ：デフォルトの名無しさん：2008/01/14(月) 10:10:42

>>274
はやくmallocした構造体に関数ポインタを詰める作業に戻るんだ。

279 ：デフォルトの名無しさん：2008/01/14(月) 11:00:46

>>275 >>277
全然オブジェクト指向プログラミングを理解してないんだね
かわいそうに
それじゃC++もtemplateもboostもSTLも理解できなかったでしょ

280 ：デフォルトの名無しさん：2008/01/14(月) 11:00:57

>>274
C++が使えない環境に、C++のコードを移植したときは途方に暮れた。
テンプレートや仮想関数を手で展開したんだもんだ。２度とやりたくねえ。

281 ：デフォルトの名無しさん：2008/01/14(月) 11:05:28

>>275
オブジェクト指向言語を使った後、再び関数型言語に触れてみて、クラスって必須だなと感じた。

282 ：デフォルトの名無しさん：2008/01/14(月) 11:27:40

C++とCをどちらも仕事で使っているが、Cでも構造体をクラス風に使うようになった。
# メンバ関数に相当する関数(アクセッサなど)は一つのソースに閉じ込める感じ。
流石に、公開用と内部用に構造体の宣言を分けるところまではしていないが、Cしか知らない頃よりは見通しがよくなった。

283 ：デフォルトの名無しさん：2008/01/14(月) 11:31:38

chaos ppとかboost preprocessorを知ってからCのコードが酷い事になった

284 ：デフォルトの名無しさん：2008/01/14(月) 11:38:58

>>275
なんでそう思ったのかな？煽りじゃなくて、純粋に興味ある。聞かせてくれないか

285 ：デフォルトの名無しさん：2008/01/14(月) 11:39:29

Webサイト作る時はJavaかなぁ
その他ではC/C++が殆どだなぁ
業務ではないけど、捨てツールは気分次第でC#になったりする

286 ：デフォルトの名無しさん：2008/01/14(月) 11:48:16

>>282
そういうのは一人で書いている分にはいいんだけどねぇ。
チームだと言語仕様上強制力がないのでどうしても割れ窓発生→破綻となるのが俺んとこのパターン。

287 ：デフォルトの名無しさん：2008/01/14(月) 11:49:43

結局Javaの圧勝だな

288 ：デフォルトの名無しさん：2008/01/14(月) 11:52:49

>>284はプログラムにはクラスが必須だとでも言うつもりか？

289 ：デフォルトの名無しさん：2008/01/14(月) 11:53:17

>>287
お前みたいのがいるからJavaが格下に見られるんだろうなw

290 ：デフォルトの名無しさん：2008/01/14(月) 12:00:21

>>288
お前それ、プログラムに関数が必須か？　と言ってんの変わらんぞ
あまりにも低脳すぎるだろ

291 ：デフォルトの名無しさん：2008/01/14(月) 12:09:39

>>288
文脈が読めない子？
＞関数型言語に触れてみて
っていう前提があるんだけどｗ

292 ：デフォルトの名無しさん：2008/01/14(月) 12:45:07

Cでオブジェクト指向プログラミングをやるなら最初っからC++を使えばいいじゃない

293 ：デフォルトの名無しさん：2008/01/14(月) 12:51:03

Boostでスマートポインタ使うなら最初からJavaを使えばいいじゃない

294 ：デフォルトの名無しさん：2008/01/14(月) 12:53:23

C言語のソースは読みやすいとか聞くけどCoreUtilsのソースよりboostのコードの方が読みやすい気がするのは
慣れの問題でしょうか？

295 ：デフォルトの名無しさん：2008/01/14(月) 12:54:17

>>292
C++のないワンチップマイコンってあるんだよね。そんな時は泣きながらオブジェクト指向風Cコーディングをする。

296 ：デフォルトの名無しさん：2008/01/14(月) 13:11:08

QuickBasicでいいよ

297 ：デフォルトの名無しさん：2008/01/14(月) 13:13:56

名前空間だけでもCよりC++使う意味があるというもの
だから俺は古いlispが嫌い

298 ：デフォルトの名無しさん：2008/01/14(月) 13:20:55

>>295
C++ から C へのトランスレータって今は無いの？
はじめの C++ コンパイラってそうだったんだよね。

299 ：デフォルトの名無しさん：2008/01/14(月) 13:25:05

ARMの頃にはもうトランスレータはなかったような

300 ：デフォルトの名無しさん：2008/01/14(月) 13:50:43

Cにどっぷり浸かった技術者がC++を新たに勉強と言うのも疲れる話だぞｗ

301 ：デフォルトの名無しさん：2008/01/14(月) 14:09:10

あー、名前空間だけでもCに導入して欲しいなあ。まーバイナリの互換性の問題で無理っぽいけど

・・関数名の最初に名前空間を表す接頭子をくっ付ける作業はもういやだお

302 ：デフォルトの名無しさん：2008/01/14(月) 14:22:51

大丈夫
C++を使っててもクラス名やファイル名に名前空間くっつけろって言われるだけだからおんなじだよ

303 ：デフォルトの名無しさん：2008/01/14(月) 16:24:58

>>279,281
まあまあ落ち着け
君たちには他人の意見を受け入れる度量の大きさが必要だ

>それじゃC++もtemplateもboostもSTLも理解できなかったでしょ

それじゃ君の愛するステパノフの言葉に耳を傾けたまえ
http://www.stlport.org/resources/StepanovUSA.html

304 ：デフォルトの名無しさん：2008/01/14(月) 16:28:04

>>298
昔のC++と今のC++はほとんど別物

305 ：デフォルトの名無しさん：2008/01/14(月) 16:48:36

>>292
それが嫌な人間がそれなりに居るから CoreFoundation やら Glib やら
Objective-C やら Xlib が現存しているのでしょう

オブジェクト指向はしたいけど、悪には手を染めたくないみたいなね
転んでしまった方が楽な場合もあるけど

306 ：デフォルトの名無しさん：2008/01/14(月) 16:54:24

>>297
R5RS も嫌い?

307 ：デフォルトの名無しさん：2008/01/14(月) 16:54:57

Xlibなんて、Ｘ用のライブラリだね。
Ｗｉｎｄｏｗｓ系とＵＮＩＸ系ではＷｉｎdowシステムが大きく異なるからね。
お仕事で強いられているのならば、やむおえないよねｗ

308 ：デフォルトの名無しさん：2008/01/14(月) 16:55:47

>>307
話見えてないでしょ?

309 ：デフォルトの名無しさん：2008/01/14(月) 16:58:42

はぁ？

310 ：デフォルトの名無しさん：2008/01/14(月) 17:01:29

やむおえない

311 ：デフォルトの名無しさん：2008/01/14(月) 17:02:05

ＭＡＣ難民がごねておりますねえ。

312 ：デフォルトの名無しさん：2008/01/14(月) 17:02:58

Media Access Controlのことでしょうか

313 ：デフォルトの名無しさん：2008/01/14(月) 17:03:14

よくわからないけど、全角の方は入院したほうがいい

314 ：デフォルトの名無しさん：2008/01/14(月) 17:04:49

マッキンﾄｯｼｭ使用者のことです。

315 ：デフォルトの名無しさん：2008/01/14(月) 17:09:25

>>313
全角にこだわるのは、なんか意味があるのでつか？

316 ：デフォルトの名無しさん：2008/01/14(月) 17:11:32

>Ｗｉｎｄｏｗｓ系とＵＮＩＸ系ではＷｉｎdowシステムが大きく異なるからね。

情緒不安定としか思えない。

317 ：デフォルトの名無しさん：2008/01/14(月) 17:14:11

おまいら手厳しいな…

318 ：デフォルトの名無しさん：2008/01/14(月) 17:14:27

Cって使ってるうちに、クラスみたいなことやるよね。
スタラクトに関数のポインタ持たせて、オブジェクト化するみたいな事。
struct data {
int val;
char *str;
.
.
int (* init)();
int (* func)(int a,int b);
};
自分はこれよくやってたもんで、C++がすんなり馴染めてC++のが楽だな
と思った。

319 ：デフォルトの名無しさん：2008/01/14(月) 17:15:16

うんこしてくるよ

320 ：デフォルトの名無しさん：2008/01/14(月) 17:28:36

構造体で定義した型の変数もオブジェクトだし、int型の変数もオブジェクトだけどな
あんまりオブジェクトオブジェクト言ってると勉強不足のアホが寄ってきてレベルが下がる

321 ：デフォルトの名無しさん：2008/01/14(月) 17:31:48

そりゃオブジェクトの定義による。
JavaのIntegerはオブジェクトだが、Cの組み込みintはオブジェクトとは「普通」言わない。

322 ：デフォルトの名無しさん：2008/01/14(月) 17:36:59

オブジェクトの定義によるから、C の int は OOP 的なオブジェクトとは
普通言わないけど、K&R 的にはオブジェクトって事でねーの

K&R じゃなかったかもしれんが

323 ：デフォルトの名無しさん：2008/01/14(月) 17:39:28

みなさん定義にうるさいんですね。

324 ：デフォルトの名無しさん：2008/01/14(月) 17:40:00

宣言にもうるさいですよ。

325 ：デフォルトの名無しさん：2008/01/14(月) 17:49:32

いや、JISの規格にも「オブジェクト」って書いてあるし、
Cのintやら配列やらは「普通に」オブジェクトと言うよ。

が、>>318は文脈から分かるし、320の国語力が低いだけだろ。

とネタにマジレスしてみる。

326 ：デフォルトの名無しさん：2008/01/14(月) 17:55:30

>>315
全角にこだわらないのは、なんか意味があるのでつか？

327 ：デフォルトの名無しさん：2008/01/14(月) 17:57:42

>>325
確かにそうだけど、よく見ると>>318も相当酷かった
このコードは誤解を招いても仕方が無い

328 ：デフォルトの名無しさん：2008/01/14(月) 18:27:14

Cのつらいところは、スタック上に確保したオブジェクトのデストラクタが
スコープぬけてもよばれないところだよなぁ。

だから関数の最後に

EXITFUNC:
　　if (ptr1 != NULL) {
　　　　free(ptr);
　　}
　　if (ptr2 != NULL) {
　　　　free(ptr2);
　　}
みたいなのがズラズラと・・・。

329 ：デフォルトの名無しさん：2008/01/14(月) 18:46:25

>>328
え？スタック上にあるオブジェクトに対して free()/delete　が必要なのですか？
デストラクタが別のことをするのなら（リンクの張りなおしとか）その処理は必要だとは思いますが。

330 ：デフォルトの名無しさん：2008/01/14(月) 18:50:40

オブジェクトと実スタックの現在のアドレスをpushするスタックを別に容易すればおｋ
再度そのスタックが参照される時、現在の実スタックのアドレスと比較して大きいものを全てpopする。
このとき、対応するオブジェクトに属するデストラクタを呼べばハッピー。分かるかな？

331 ：デフォルトの名無しさん：2008/01/14(月) 18:51:26

現在のアドレス→現在のスタックトップのアドレス

332 ：デフォルトの名無しさん：2008/01/14(月) 19:04:50

全角にこだわるのは２ちゃん暦浅い奴

333 ：デフォルトの名無しさん：2008/01/14(月) 19:35:00

>>332
>>326

334 ：デフォルトの名無しさん：2008/01/14(月) 20:05:08

>>326と>>333はアホだな。
国語やり直して来いよ。

335 ：デフォルトの名無しさん：2008/01/14(月) 20:09:45

反論できないときに、用語の使い方とか文法にケチをつける奴ってよくいるけど、
「国語やり直して来いよ」
この返し方はアホすぎるだろ。

336 ：デフォルトの名無しさん：2008/01/14(月) 20:25:30

じゃあまぁ書くけど、
意味があるからこだわるわけであって、こだわる理由を聞くのはわかるが、
どうでも良いからこだわらないのであって、こだわらない理由を聞くのって
文脈が理解出来ないアホの子だろ。
ここまで言わんと分からんか。

337 ：デフォルトの名無しさん：2008/01/14(月) 20:46:05

>>329
いやいやオブジェクト自体はスタック上に確保してても、オブジェクトの
メンバはヒープ上にあるかもしれないでしょ。もしメンバの解放をデストラクタ
でやってるなら、C++なら自動で解放される。

>>330
メンドクセーシ、わかりにくい。

338 ：デフォルトの名無しさん：2008/01/14(月) 20:56:49

スコープ抜けるタイミングでデストラクタが呼ばれる言語ってC++くらいじゃね?
あとはDとか。
C#はusingがあるけど、あれはネストが深くなるから使いにくい。

339 ：デフォルトの名無しさん：2008/01/14(月) 21:03:38

てか、スコープ抜けてデストラクタが呼ばれないのはGCあるからだろ？
スコープ抜けてもデストラクタ呼ばなくて良いようにするってことは、
自前でGC実装する方が良いってことか？

340 ：デフォルトの名無しさん：2008/01/14(月) 21:05:35

DはGCあるけど、スコープ抜けるタイミングでデストラクタが呼ばれるようにすることもできる。

341 ：デフォルトの名無しさん：2008/01/14(月) 21:44:37

>>336
マ板に来てて全角と半角にこだわる理由がわからない人の方が
アホの子だと思います！

342 ：デフォルトの名無しさん：2008/01/14(月) 21:51:36

既出だしみんな読んでると思うけど、バベル案内は結構面白かった

http://www.aoky.net/articles/steve_yegge/tour_de_babel.htm

343 ：デフォルトの名無しさん：2008/01/14(月) 21:57:28

外国語もプログラミング言語を習得するのも段階はよく似ている。
途中までは全く理解できずにひたすら文法を勉強するのみ。
そのうち自分でいろいろ読み書きしていき、たどたどしいながらも
使えるようになってくる。

しかし、本当に理解の瞬間がやってくるのは突然だ－それはある日
全く何の予告も無しにやってくる。頭でやっていた作業が体に染み付いた
瞬間だ。

344 ：デフォルトの名無しさん：2008/01/14(月) 22:02:21

>>341
>>315と>>326と>>333、みんなアホな子で良いじゃん。
大差ない。

345 ：デフォルトの名無しさん：2008/01/14(月) 22:34:14

半角英数なんか使ったら文屋なら即首だぞ

346 ：デフォルトの名無しさん：2008/01/14(月) 22:39:36

そういう硬直的な社会では仕方が無い

347 ：デフォルトの名無しさん：2008/01/14(月) 23:51:18

清書する時点で全置換すりゃいいでしょ。めんどくさければマクロでもくんどきゃいい。
掲示板に書く部分で全角半角とかどうでもよくね？ソースコードにはやめてほしいが。

348 ：デフォルトの名無しさん：2008/01/15(火) 00:13:35

>>344
>>313も入れてあげれば？

349 ：デフォルトの名無しさん：2008/01/15(火) 00:24:08

ネットワーク帯域利用、CPU時間等々が2倍になり、積もり積もって温暖化に繋がる。
ま、こんな糞議論してる時点で、人も機械も無駄なエネルギー使いまくりだけどw

350 ：デフォルトの名無しさん：2008/01/15(火) 01:25:24

>>326
君はいつもあべこべ君やってくれてるね？
うんこしたあとに集ってくる銀蠅そのものだよｗ

351 ：デフォルトの名無しさん：2008/01/15(火) 01:27:10

一応言っておくけど、>>313は全角英数を使っていることに突っ込んでいるわけじゃないぞ
>>315が勝手に勘違いしてるだけ

352 ：デフォルトの名無しさん：2008/01/15(火) 01:28:26

>>345
おまえ馬鹿か？
文屋の掲示板にでも池

353 ：デフォルトの名無しさん：2008/01/15(火) 01:36:12

>>328
デストラクタの機能はC++が元祖。
Cには素からありませんぞｗ。

354 ：デフォルトの名無しさん：2008/01/15(火) 02:13:45

C++が元祖かどうかは疑問。
絶対にCにはなかったけど。

355 ：デフォルトの名無しさん：2008/01/15(火) 02:30:57

事実に対して疑問をもたれてもねぇ。。

356 ：デフォルトの名無しさん：2008/01/15(火) 04:04:07

ソース無き「自称事実」が疑問を持たれるのは仕方ないな。

357 ：デフォルトの名無しさん：2008/01/15(火) 04:08:09

無かった事を証明する"悪魔の証明"ですか？

358 ：デフォルトの名無しさん：2008/01/15(火) 04:45:01

まぁ、そこまで話を厳密にすれば、「証明しようがない」って結論になって
話題そのものを流せちゃえるから、逃げるのには便利だろうけど、
ここで現実的に求められているのは、「353が一人で勝手に言ってるわけではないというソース」だな。

359 ：デフォルトの名無しさん：2008/01/15(火) 04:59:04

いやC++登場以前から何らかの言語にデストラクタの機能があった事を示せばいいんだよ

360 ：デフォルトの名無しさん：2008/01/15(火) 06:28:51

それは「C++が元祖ではない」という意見の人間がやることだけど、
とりえずこの場にはそういう意見は無いぞ。
「C++が元祖だという意見」と、「本当にそうなのかどうか疑問だという意見」があるだけ。

361 ：デフォルトの名無しさん：2008/01/15(火) 06:29:25

Simulaあたりが該当しそうだけど、あれもガーベジコレクションだったっけねぇ。
SimulaのGCとかnewが遅いからC++はスタックにしたらしいけど・・なんか
あんまし30年前から変わってない話題だなあ

362 ：デフォルトの名無しさん：2008/01/15(火) 06:54:36

×ガーベジコレクション
○ガベージコレクション

363 ：デフォルトの名無しさん：2008/01/15(火) 07:36:06

検索すると、あんまり結果の量は変わらないな。
ガーベージも結構ある。ガッベージとガッベジは少ない。
まぁ、俺も書くときはガベージだけどね。

364 ：デフォルトの名無しさん：2008/01/15(火) 08:09:55

garbage をどうカタカナに転写するかで 100 レス使うつもりか?

365 ：デフォルトの名無しさん：2008/01/15(火) 08:16:44

なに大仰に構えてんの。馬鹿かいな。

366 ：デフォルトの名無しさん：2008/01/15(火) 08:22:52

(・∀・)ﾆﾔﾆﾔ

367 ：デフォルトの名無しさん：2008/01/15(火) 11:38:41

うにころどほ知らないのか

368 ：デフォルトの名無しさん：2008/01/15(火) 13:31:51

>>359
＞いやC++登場以前から何らかの言語にデストラクタの機能があった事を示せばいいんだよ
自分で調べろよ、物臭な奴だなｗ

369 ：デフォルトの名無しさん：2008/01/15(火) 13:49:57

デストラクタって、メモリ管理機能の貧弱なCにオブジェクト指向を追加したから必要になったんだろ?
メモリ管理が出来ている他の言語でデストラクタが必要なのか?

370 ：デフォルトの名無しさん：2008/01/15(火) 13:59:04

違うだろ。

コンストラクタとデストラクタがあれば便利。

ドトネトみたくメモリ開放のタイミング取れないものはカス。

371 ：デフォルトの名無しさん：2008/01/15(火) 14:12:35

>>368
ahosugi

372 ：デフォルトの名無しさん：2008/01/15(火) 15:07:53

デストラクタのお陰でtry-catchを書かずに済む

373 ：デフォルトの名無しさん：2008/01/15(火) 15:37:26

それ、ﾁｶﾞ。
デストラクタじゃなくて、実体宣言のじゃね？

374 ：デフォルトの名無しさん：2008/01/15(火) 22:39:26

>>369
メモリ管理じゃない。リソース管理を行うために必要な機能。

375 ：デフォルトの名無しさん：2008/01/15(火) 23:54:05

↑こいつら、松田区　ちんぽの無い連中だなｗっっっっっっっっっっっｗ

376 ：デフォルトの名無しさん：2008/01/16(水) 00:40:17

ニャッキ(ll )))))))

377 ：デフォルトの名無しさん：2008/01/16(水) 16:26:56

例外って使わないほうがいいの？

378 ：デフォルトの名無しさん：2008/01/16(水) 17:50:36

濫用せずに必要最小限に使うのがよい。

379 ：デフォルトの名無しさん：2008/01/16(水) 17:54:02

うそつけ。

戻り値判定をヤメテ、throwに変えるべき。
上位はcatchすれば良いだけだから。

ただ、例外で躓くのは、クラスライブラリが独自例外クラス定義してたり、
組み込みコンパイラが文法対応してないことくらい。

380 ：デフォルトの名無しさん：2008/01/16(水) 17:59:36

コンストラクタで使うとゾンビになるとか何とか

381 ：デフォルトの名無しさん：2008/01/16(水) 18:03:02

例外は遅いのでエラー処理の時だけにすれ。

382 ：デフォルトの名無しさん：2008/01/16(水) 18:03:50

　↑
ちょ、それ逆。
例外は速い。

383 ：デフォルトの名無しさん：2008/01/16(水) 18:05:40

＊何に比べて＊速いというの？
まさか、戻り値と条件分岐？

384 ：デフォルトの名無しさん：2008/01/16(水) 18:17:04

>>382
実験してみれ。

例外で戻るのとただの値を返す関数をそれぞれ10000000回ほどずつ
繰り返してみな。あまりの違いに歴然とするはず。

385 ：デフォルトの名無しさん：2008/01/16(水) 18:43:03

Cのerrnoの代わりに使ってる

386 ：デフォルトの名無しさん：2008/01/16(水) 19:52:34

ぶっちゃけ例外のありがたみを感じたことがない。

387 ：デフォルトの名無しさん：2008/01/16(水) 19:57:55

>>384
デストラクタとかそういう細かいの無視するから？
アセンブラ見ろとか言わないでｗ

388 ：デフォルトの名無しさん：2008/01/16(水) 20:17:57

C++が書けることは自慢にはならないが書けないと恥ずかしいことではある

389 ：デフォルトの名無しさん：2008/01/16(水) 20:57:31

例外と失敗の区別がつかない奴はすっこんでろ

390 ：デフォルトの名無しさん：2008/01/16(水) 21:03:08

>>387
More Effective C++ 項目15を読むか、次のプログラムを実行してみよう。

#include <iostream>
#include <ctime>

void func() {}

int main()
{
　const int ITER = 1000000;
　std::clock_t ct;

　ct = std::clock();
　for (int i = 0; i < ITER; i++)
　　func();
　std::cout << "関数呼び出しのclock = " << (std::clock() - ct) << std::endl;

　ct = std::clock();
　for (int i = 0; i < ITER; i++) {
　　try {
　　　throw 1;
　　}
　　catch (int) {}
　}
　std::cout << "例外処理のclock = " << (std::clock() - ct) << std::endl;
}

391 ：デフォルトの名無しさん：2008/01/16(水) 21:08:16

>>390
More Effective C++を会社におきっぱだから明日呼んでくる。
そのコードを実行したところで早い理由は一切わからないと思うんだが・・・

392 ：デフォルトの名無しさん：2008/01/16(水) 21:24:04

ttp://www.cmagazine.jp/src/kinjite/cpp/exception.html
プログラミングの禁じ手Web版 - C++編例外に関するパターン

393 ：デフォルトの名無しさん：2008/01/16(水) 21:59:05

>>392
＞コンストラクタ内で例外を起こす
＞
＞深刻度：★★★ - 重い深刻度

こんなウソの記事だすなよ

394 ：デフォルトの名無しさん：2008/01/16(水) 22:09:51

さんざん既出。真紀俊男だからしかたがない

395 ：デフォルトの名無しさん：2008/01/17(木) 01:27:04

>>393
やべえコンストラクタでメモリ確保できねぇw

つーかデストラクタでの例外と「同じ」深刻度かよ。
この記事書いた奴の頭が深刻な事になってんじゃないの。

396 ：デフォルトの名無しさん：2008/01/17(木) 05:52:25

そもそも秒単位の時間で100万回の例外ってどんな状況よ

397 ：デフォルトの名無しさん：2008/01/17(木) 06:10:33

>>396
いいから例外が遅いって事はわかっただろう

398 ：デフォルトの名無しさん：2008/01/17(木) 07:30:11

コストの大半はthrow時の生成が原因
throwの部分をコメントアウトして測定すると一気に処理時間が短かくなることからわかるけど
int型をthrowする場合でもtryブロックの前後のトラップとは比べものにならんぐらいコストがかかる
だから例外があくまで例外であるという程度の頻度で発生するなら殆ど問題無い程度のコストになるんじゃないかな？
100万回回してきっちり100万回例外になるようなのなんてどうみてもロジックミスだし

399 ：デフォルトの名無しさん：2008/01/17(木) 07:34:14

>>398
いやそれは初めからわかってる事
D&Eにも例外はコスト無しで実装できると書いてある

400 ：デフォルトの名無しさん：2008/01/17(木) 18:14:55

>>393
雑誌という公文書よりトイレの落書き2chが正しいとでも？

401 ：デフォルトの名無しさん：2008/01/17(木) 18:40:00

>>400
良くそういうことあるお。

Ｍ＄のチョウチン記事よりかマシ。

402 ：デフォルトの名無しさん：2008/01/17(木) 18:56:41

Response and Balance 2600cc Double over head cam Electric Twin Turbo

403 ：デフォルトの名無しさん：2008/01/17(木) 21:56:23

try-catchで囲むことはほぼコストにならない。throwは秒間100万レベルとかに落ちる。
つまり正常系に利用しなければおｋ。
その他、リソースリークの問題があるからRAIIや例外中立など知識とノウハウが
結構求められるのが実情。うっかり使うと色々リークが起きて痛い目に合う。
けどそれらを乗り越えれば、コード省力化とエラーハンドリング周りの
余りあるメリットを享受できる。

404 ：デフォルトの名無しさん：2008/01/17(木) 21:58:49

>>403
だからそれは初めからわかってるって。
俺が言っているのは例外を投げるとすごく遅いって事だけだから。

405 ：デフォルトの名無しさん：2008/01/17(木) 22:21:19

だってさ

406 ：デフォルトの名無しさん：2008/01/17(木) 23:45:02

ttp://www.kijineko.co.jp/tech/superstitions/dont-throw-exception-from-constructor.html
コンストラクタから例外を送出してはならない

407 ：デフォルトの名無しさん：2008/01/17(木) 23:58:47

実際問題try-catch使ってプログラム組んでる人いるの?

408 ：デフォルトの名無しさん：2008/01/18(金) 00:01:17

throwが遅くて困る状況が想定不能

409 ：デフォルトの名無しさん：2008/01/18(金) 00:08:50

>>407
はいよ、使っているよ。

410 ：デフォルトの名無しさん：2008/01/18(金) 00:17:21

例外まったく使わない。標準ライブラリのiostreamもつかわん
（これナニが便利なの？）、全部Cのライブラリで書く。

だれか、例外がホントウに便利だと感じられる具体例をオシエテクレ。

411 ：デフォルトの名無しさん：2008/01/18(金) 00:18:05

newも極力使わない。ほぼスタック上にオブジェクトは確保する。

412 ：デフォルトの名無しさん：2008/01/18(金) 00:19:37

STLは使う

413 ：デフォルトの名無しさん：2008/01/18(金) 00:31:33

大半の仕事はMFCかATLかAPIとDirectXだなー

414 ：デフォルトの名無しさん：2008/01/18(金) 00:39:31

>>410
毎度mallocの戻り値をNULLチェックする必要がなって、コードがすっきりする。

415 ：デフォルトの名無しさん：2008/01/18(金) 00:43:58

>>414
ぜんぜん便利じゃない。Cのマクロですむはなしだし、
例外ハンドリングの記述と、マクロ処理の記述は大差ない。

416 ：デフォルトの名無しさん：2008/01/18(金) 01:41:03

>>410
激しく楽になるってば。。
例外なしで戻り値タイプだと普通関数の中ってこんな感じになるでしょ？
int OrzFunc(){
　if((ret = GetMonyomonyo()) != 0){
　 perror()
　}
　if((ret = GetFugafuga()) != 0){
　 perror()
　}
・・・
　return ret;
}

んで関数呼ぶたびにうだうだ戻り値チェックして・・ってだるいでしょ。
それが例外にするとこれだけで済むわけだ。
void OrzFunc(){
　GetMonyomonyo();
　・・・
　GetFugafuga();
　・・・
}
なにが楽ってtry-catchは「必要がない場面ではいらない」わけだよ。
コールスタック上ではだーってはっしょって書けて、いざ画面とかログに
出すとか例外中立にする場面とかで書けばいいだけ。
最悪mainにだけcatch書いてメッセージ出したっていいわけだ。

417 ：デフォルトの名無しさん：2008/01/18(金) 02:02:36

システムやゲームソフト書いてるならともかく
例外によるオーバーヘッドなんか瑣末なもんじゃないの？
アホなI/Oやオブジェクト確保とかのがよっぽど癌。

418 ：デフォルトの名無しさん：2008/01/18(金) 02:09:35

>>416
管理しきれる戻り値の伝播の手間と、管理しきれない例外の伝播の手間を
考えれば、俺は前者のほうが楽だと思うし、その例でなにか便利に
なったとは到底感じられません

419 ：デフォルトの名無しさん：2008/01/18(金) 02:11:54

>>417
例外によるオーバヘッドは全然瑣末じゃない。

がしかし、あなたが作成するアプリケーションの領域によっては、
ユーザ（顧客）の満足度を勝ち取れるだけの十分な競争力を
うみだせれば、瑣末なこと。

これは例外だけじゃなくて、言語もそうだし、HWもそう。

420 ：デフォルトの名無しさん：2008/01/18(金) 02:17:15

#define _Ex(func) if((ret = func()) != 0) perror()

int OrzFunc(){
　_Ex(GetMonyomonyo());
　_Ex(GetFugafuga());
・・・
　return ret;
}

これで。

421 ：デフォルトの名無しさん：2008/01/18(金) 02:58:05

Cだとライブラリの数だけエラー処理の方法があり、それを把握するのが面倒。
NULL返し、真理値返し、-1か正常値返し、GetLastError() (Win32), HRESULT (Win32), etc...

例外処理を持っている言語だと、みな例外処理へ収束する。
CのAPIを直接叩く機会の多いC++だと、あまりそうとは感じられないけれど。

422 ：デフォルトの名無しさん：2008/01/18(金) 03:25:40

ほんとは例外は使う使わないじゃなくって必須の処理なんだけどね・・
まあnew/operator/castとかの例外処理はまともに扱われてないのが実情。

423 ：デフォルトの名無しさん：2008/01/18(金) 03:50:40

確実に連続稼働していること求められるシステム以外で、
newとかmalloc失敗するときってexitしちゃだめですか？もちろんダメなケースはありますが。

みなさん成功しなければプログラムが機能しないというnewとかmallocに失敗したときはどうしてます？

424 ：デフォルトの名無しさん：2008/01/18(金) 07:47:12

再起動する。

425 ：デフォルトの名無しさん：2008/01/18(金) 08:39:36

メモリプールを使ってるときに断片化が進んでもnewやmalloc(というかrealloc?)は失敗するんじゃね？
でそういうときは例外処理を使ってコンパクションを行なったりと選択範囲が広がりそう

426 ：デフォルトの名無しさん：2008/01/18(金) 08:43:37

>>420
マクロだと関数が入れ子になったとき対応できないんじゃ…

sqrt(pow(asin(x), 2) - pow(acos(y), 2))
みたいなのとか、errnoの代わりに例外投げてくれたらなーとか思ったことない？

427 ：デフォルトの名無しさん：2008/01/18(金) 08:49:42

じゃinline関数で

428 ：デフォルトの名無しさん：2008/01/18(金) 10:49:42

阿呆ですか。

429 ：デフォルトの名無しさん：2008/01/18(金) 10:57:37

#define _Ex(func) if((ret = func()) != 0) perror()

template< class Func >
inline void _Ex2(Func const& f) { if (f() != 0) perror(); }

430 ：デフォルトの名無しさん：2008/01/18(金) 11:59:45

例外使うと失敗したときと成功したとき両方の

431 ：デフォルトの名無しさん：2008/01/18(金) 12:04:21

>>416
そもそも、例外の来ないAPIなんか使うときは、前者で毎回戻り値チェックしてthrowするしかないだろ。

432 ：デフォルトの名無しさん：2008/01/18(金) 12:11:52

Win32って関数の数だけエラーチェックの作法があるよね。

433 ：デフォルトの名無しさん：2008/01/18(金) 12:13:49

SEH

434 ：デフォルトの名無しさん：2008/01/18(金) 12:14:33

そうでもない。
戻り値という１作法。

関数の数だけあるのは、呼び出し順序ルール。

435 ：デフォルトの名無しさん：2008/01/18(金) 12:17:18

EnterCriticalSection
Windows 2000/NT: In low memory situations,
EnterCriticalSection can raise an exception.

436 ：デフォルトの名無しさん：2008/01/18(金) 12:52:06

結局、例外で投げるものはお前らで考えろ。だから普及する分けないよ。

437 ：デフォルトの名無しさん：2008/01/18(金) 13:44:36

え”？

クラスライブラリのエラーって全部例外投げてくるんだけど。。。

438 ：デフォルトの名無しさん：2008/01/18(金) 18:57:33

クラスライブラリも言語仕様から見れば「おまえら」

439 ：デフォルトの名無しさん：2008/01/18(金) 19:09:24

どんな用途にもC++が最高！とかいうつもりは毛頭ないが，
最終的にピンチに陥った時に頼れる言語だと思う．

440 ：デフォルトの名無しさん：2008/01/18(金) 19:28:26

言語仕様で決められる例外って…

441 ：デフォルトの名無しさん：2008/01/18(金) 21:13:18

お前らちゃんと例外くらい勉強しろよ・・
そんなだからメモリ足りなくなったら落ちたり、オーバーフローでおかしく
なったりするんだよ

442 ：デフォルトの名無しさん：2008/01/18(金) 21:39:38

今のOSでmallocが失敗することなんかあるの?
昔の65kしかなかった頃は、malloc失敗することあったよね。

443 ：デフォルトの名無しさん：2008/01/18(金) 21:58:18

>>441
メモリたりなくなっておちることはない。システムが許容可能な、最大負荷と
メモリ量を稼動前に計算するから。システムに搭載されているメモリで
受付可能に制約をかける。

メモリ不足例外が起こりうるシステム自体そもそも問題でしょ。

444 ：デフォルトの名無しさん：2008/01/18(金) 22:05:44

newの例外はメモリ不足例外とは言わないと言いたいの？

445 ：デフォルトの名無しさん：2008/01/18(金) 22:13:58

>>444
メモリ不足例外というよ

446 ：デフォルトの名無しさん：2008/01/18(金) 22:34:30

>>443が作るプログラムには一切のバグが含まれないらしい。
素晴らしいな。

例外処理なんて半分ぐらいフェイルセーフだろよ。

447 ：デフォルトの名無しさん：2008/01/18(金) 22:44:58

>>446
フェイルセーフのためというのであれば、メモリ不足例外をいっしょくたにして
扱うのは全然フェイルセーフではない。オブジェクトごとに最大負荷において、
消費するオブジェクト数をあらかじめ評価しておいて、万が一足りない事態が
発生したら、そのオブジェクトに対して復帰する手段を仕掛ける必要がある。

これって、結局例外ハンドリングであろうが、Cの戻り値評価であろうが同じ
なのよね。だから、俺は例外がありがたいなんて思ったことはない。

448 ：デフォルトの名無しさん：2008/01/18(金) 22:57:31

WindowsのSEHて使わなくてもいいの？

449 ：デフォルトの名無しさん：2008/01/18(金) 23:14:56

447みたいにきちんと対処する人なら、
確かに例外処理のありがたみなんて感じないこともうなずける。

平均的なプログラマはろくにチェックなんてやらないということが、
例外処理のなかったC++での、newハンドラ導入の理由としてD&Eで挙げられている。

450 ：デフォルトの名無しさん：2008/01/18(金) 23:49:49

何でもかんでもあちこちでチェック必要な構成になってたら、
それはそれで効率悪そう

451 ：デフォルトの名無しさん：2008/01/18(金) 23:53:41

>>450
本来は、なんでもかんでもあちこちでチェックは必要なのだよ。

だから仕事用じゃなくて、自分限定とか知り合い限定のプログラムで
「例外おきた？ワリィワリィ、後で直すわ」ですむプログラムがなんと
心地よいことよ。しかもRubyで書いてたら最高。

452 ：デフォルトの名無しさん：2008/01/19(土) 08:45:10

> 確かに例外処理のありがたみなんて感じないこともうなずける
あほやねぇ。。ExceptionalC++読んでから一年くらい例外モデルで
コードを書きまくってみな。まったくありがたくもない概念がなぜ
近年の言語にはみな導入されているのかが見えてくるはず。

453 ：デフォルトの名無しさん：2008/01/19(土) 09:22:40

止まっちゃいけないシステム作ってるけども、例外は扱いが難しいから使うなって指令が来て使えないぜ

454 ：デフォルトの名無しさん：2008/01/19(土) 10:13:00

Windowsで止めないためにはSEH使うしかないだろ。
ゼロ割とか。

455 ：デフォルトの名無しさん：2008/01/19(土) 10:30:16

なんでもできる言語って言ったらアセンブリだろう
アセンブリにできないことはＣＰＵにもできないわけで

456 ：デフォルトの名無しさん：2008/01/19(土) 12:18:51

経験不足を書籍類で補うのはいいんだが、経験に昇華してから発言して欲しいと思う。

457 ：デフォルトの名無しさん：2008/01/19(土) 12:31:40

コンストラクタで例外使うとcatch中にデストラクタと同じコードが必要になるんじゃないの？

458 ：デフォルトの名無しさん：2008/01/19(土) 13:09:15

>>457
スマートポインタにオブジェクトの管理をさせておけば片付け処理は不要
ってMoreEffectiveC++に書いてあった
コンストラクタの例外なんて経験無いから書籍で補ったもんだけどな

459 ：デフォルトの名無しさん：2008/01/19(土) 13:11:08

>>457
要らないぞ
メンバ変数も、またデストラクタに任せればいい。

class hoge
{
hoge() : p(new int), q(new int) {}

boost::scoped_ptr<int> p, q;
};
qの初期化で例外が投げられても、pはきちんと解放される。

460 ：デフォルトの名無しさん：2008/01/19(土) 13:22:14

例えば、HFILEとかHGDIOBJみたいな、メンバが生のリソースだったらどうするの？

461 ：デフォルトの名無しさん：2008/01/19(土) 13:25:03

包む

462 ：デフォルトの名無しさん：2008/01/19(土) 13:31:57

例外わかんねーとかはあまりに致命的な経験不足だな

463 ：デフォルトの名無しさん：2008/01/19(土) 13:41:04

悪かったな。
俺も、try とcatch　はピンとこないよ。

464 ：デフォルトの名無しさん：2008/01/19(土) 13:54:19

まぁ、書いてみろ。いいもんだ。

465 ：デフォルトの名無しさん：2008/01/19(土) 13:56:36

漏れもテンプレートと例外なしとかじゃもう書けねー

466 ：デフォルトの名無しさん：2008/01/19(土) 14:02:29

要するに、割り込み処理や、エラー処理をすっきりさせたのが”try とcatch”ってことか。

467 ：デフォルトの名無しさん：2008/01/19(土) 14:05:55

>>466
>割り込み処理

せめてコンピュータの常識くらい身につけようぜ

468 ：デフォルトの名無しさん：2008/01/19(土) 14:06:28

C++でＤＢ２のＡＰＩ持ってるかどうか知ってる奴いるか？

469 ：デフォルトの名無しさん：2008/01/19(土) 14:07:47

なんだ割り込み処理も知らないのか？
お前偉そうなこと言っても無知じゃん　>>467

470 ：デフォルトの名無しさん：2008/01/19(土) 14:08:46

ということにしたいのですね:-)

471 ：デフォルトの名無しさん：2008/01/19(土) 14:11:29

おや、割り込みが入ったようですな

472 ：デフォルトの名無しさん：2008/01/19(土) 14:16:55

>>469
いや、割り込み処理とtry, catchを結び付けようとするのは、
非常識だといいたいのだけどなぁ

473 ：デフォルトの名無しさん：2008/01/19(土) 14:18:37

分からないのではない。
存在そのものが矛盾しているから使わないだけ。

474 ：デフォルトの名無しさん：2008/01/19(土) 14:22:59

構文解析ルーチンが作り出したようなお粗末なレスだな　>>472-473

475 ：デフォルトの名無しさん：2008/01/19(土) 14:24:29

まぁ>>469は、ドライバとか書いたことないのだろうけど。

476 ：デフォルトの名無しさん：2008/01/19(土) 14:28:25

>>475
何のドライバをかきましたか？
全部一人でかけましたか？

477 ：デフォルトの名無しさん：2008/01/19(土) 14:29:38

暇だからＤＢ２　Ｌｉｔｅでも買ってくるかな。
ＡＰＩはもう解ったし。

478 ：デフォルトの名無しさん：2008/01/19(土) 14:30:23

>>476
（たくさんの）オーディオチップ、Etherコントローラ、Timer、UART、SDなどなど。。。
全部一人で書いたよ。

479 ：デフォルトの名無しさん：2008/01/19(土) 14:32:24

無理しなくてもいいよｗ　

480 ：デフォルトの名無しさん：2008/01/19(土) 14:32:55

>>479
してないってｗ

481 ：デフォルトの名無しさん：2008/01/19(土) 14:37:51

あり得ないだろ？
全部一人なんてｗ
いったい何歳なんだ？ｗ
今は平成だぞｗ

482 ：デフォルトの名無しさん：2008/01/19(土) 14:40:48

書ける人は書けるだろ。

483 ：デフォルトの名無しさん：2008/01/19(土) 14:42:16

>>481
何があり得ないんだ?
割と普通じゃないの

484 ：デフォルトの名無しさん：2008/01/19(土) 14:44:04

んむ。普通だｗ

485 ：デフォルトの名無しさん：2008/01/19(土) 14:44:37

横レスだが、C++でドライバ書けるOSって例えば？
LinuxとBSDのドライバしか見たことないんでよく知らないんだが。。

あとどうでもいいけどQt、wxともに例外は投げてこないよね確か。

486 ：デフォルトの名無しさん：2008/01/19(土) 14:45:48

>>485
そういやC++のスレだったなｗ

Symbianとかそうなんじゃない？使ったことないけど。

487 ：デフォルトの名無しさん：2008/01/19(土) 14:46:05

>>466の「割り込み処理」から発展した話であり、誰もC++でドライバとか言ってないし。

488 ：デフォルトの名無しさん：2008/01/19(土) 14:46:15

>>483
流用してんだろ？既存類似のプログラムから。

489 ：デフォルトの名無しさん：2008/01/19(土) 14:49:22

>>483 みたいな奴は偽装もやってそうだなｗ
　　　　（組込み用語の偽装なｗ）
　　　　

490 ：デフォルトの名無しさん：2008/01/19(土) 14:49:32

>>488
ドライバって、チップ依存だから、毎回チップの仕様書よみながら書く必要があるのよ。
チップの種類によってドライバの構造は似ているというのはあるけど。

491 ：デフォルトの名無しさん：2008/01/19(土) 14:50:00

>>486
なるほど盲点ですた。確かにそうでなきゃおかしいなww
ﾄﾝ

492 ：デフォルトの名無しさん：2008/01/19(土) 14:52:00

ドライバにもＧＵＩを伴ってる奴もあるのに、何とレベルが低い。

493 ：デフォルトの名無しさん：2008/01/19(土) 14:52:36

>>489
面白くない文章は、草を生やしても面白くならない

494 ：デフォルトの名無しさん：2008/01/19(土) 14:55:31

ハンドラとドライバとエンジンの区別もつかない奴がいるな。
こりゃまいったｗ

495 ：デフォルトの名無しさん：2008/01/19(土) 14:58:10

>>493
面白いスレでも逝けば？

496 ：デフォルトの名無しさん：2008/01/19(土) 14:59:58

>>485
Mac OS X の IOKit は Embedded C++

497 ：デフォルトの名無しさん：2008/01/19(土) 15:16:58

>>496
調べたらそうみたいですね。スゲエ。

498 ：デフォルトの名無しさん：2008/01/19(土) 15:42:26

窓もC++とCOMじゃね？

499 ：デフォルトの名無しさん：2008/01/19(土) 16:36:28

>>485
Qtの中でbad_allocが起きたらそのままやってくる

500 ：デフォルトの名無しさん：2008/01/19(土) 16:40:30

>>499
そりゃそうだが。。それはQtが投げてるとは言わないと思うんですがどうなんでしょう。

501 ：デフォルトの名無しさん：2008/01/19(土) 16:56:19

まあQtの実装でthrowしてなくても言語がthrowするからねぇ、くらいな
感じで・・外から見たらQtのthrowかbad_allocかの違いはあんま関係ないかなと。
そうこと聞いてんじゃないんだっけ？

502 ：デフォルトの名無しさん：2008/01/19(土) 17:08:50

>>485
最近のWindowsのユーザーモードドライバがC++で書ける。
IUnknownとか使うとってもCOMだし、見かけはただのDLLのようだ。

ドライバなんて1個も書いたことないけど。

503 ：デフォルトの名無しさん：2008/01/19(土) 17:46:38

>>501
おおすいません。
例えば、MFCだとCMemoryExceptionとかCFileExceptionとかフレームワーク独自の例外投げてくる
じゃないすか、でユーザは当然それをキャッチすることが求められると。
Qt、wxとかはそういうライブラリ内部のエラー処理のための独自の例外は投げませんよね確か、って事を
言いたかっただけです。
みなさんQtとかwx使う時bad_allocはcatchしてます？僕は今まで完璧スルーですたお。。。ｽﾏｿ

あとFirefoxも確か例外は使ってなかったような。。

>>502
ヘェーWindowsスゴイっすね。。

504 ：デフォルトの名無しさん：2008/01/19(土) 18:30:46

いや別にすごくはないだろ

505 ：デフォルトの名無しさん：2008/01/19(土) 18:54:43

catch(...)で不明なエラーが発生しました的に処理しちゃうのが実情っぽい
感じだよね。

>あとFirefoxも確か例外は使ってなかったような。。
前見たmozillaのコーディング規約はすごかったなあ。あらゆるコンパイラで
動かそうとすると例外・テンプレートは禁止らしい。その他も色々あって
もうC++じゃないじゃんみたいな。。俺はVCとgccくらいで動けばいいや

506 ：デフォルトの名無しさん：2008/01/19(土) 20:09:00

>>503
MSってこれだから嫌なんだよ
なんでもかんでもMSルールで染め上げようとするんだもの

507 ：デフォルトの名無しさん：2008/01/19(土) 20:54:08

まあMFC作った当時に、
std::exceptionが確固としていたとも思えないけどな。

508 ：デフォルトの名無しさん：2008/01/19(土) 20:57:02

例外クラスもCObject派生にしたかったんだろーね
C++の型システムがしょぼいから仕方ない気もすこしする

509 ：デフォルトの名無しさん：2008/01/19(土) 21:01:55

std::exceptionの品揃え見りゃ最初から作ったほうが速いと思うだろ普通。
どーせSTLにGUI支援なんか微塵もないんだし。

510 ：デフォルトの名無しさん：2008/01/19(土) 21:09:50

ゴ　ゴ　ゴ　ゴ　ゴ　ゴ　ゴ　ゴ　　　
　　　／＼　 /｜　
　　／ /| ＼/ ｜(＼ /)
　／　/ | 　＼｜( ﾟーﾟ) <全力でGCCを捨てVCに移行せよ
／　 /　| 　 __〃｀ヽ〈＿　
　　/ γ´⌒´-－ヾｖーヽ⌒ヽ　
　 /／⌒　ｨ mfc ｀ｉ´cli ）; ｀ヽ
　//　　　ﾉ＾､＿__￥＿_人　　|
/ !　　,,,ノ爻＼_　_人　ﾉｒ;＾ >　）
/ （　　 <_ ＼ﾍ､,, __,+､__ｒﾉ/　　/
　　ヽ_　　＼）ゝ､__,+､_ｱ〃／
　　　ヽ､___ ヽ.=┬─┬〈　ｿ、
　　　　　〈J　.〉､|　　 |,　|ヽ-´
　　　　　　/"" 　|ATL|:　|
　　　　　　ﾚ　　 :|:　　 |　ﾘ
　　　　　/　　ﾉ|＿＿|　|
↑　　　／|　,,　ｿ　ヽ　　）
　＼＿／ .,ゝ　）　　ｲヽﾉ
　　　　　ｙ　｀ﾚｌ　　〈´　ﾘ
　　　　 /　　ﾉ　　　|　　 | .
　　　　ｌ　　/　　　　ｌ;;　 |
　　　　〉　〈　　　　〉　 |
　　　 /　　::|　　　　（_ヽ　＼､
　　　(｡ｍｎﾉ　　　　　｀ヽｎｍ

511 ：デフォルトの名無しさん：2008/01/19(土) 21:16:14

ttp://www.geocities.jp/ky_webid/cpp/library/027.html

まーMFCに採用する意味はないよねー

512 ：デフォルトの名無しさん：2008/01/19(土) 21:18:54

API包んだライブラリに移植性も糞もないだろ

513 ：デフォルトの名無しさん：2008/01/19(土) 21:36:43

SDLやJAVAのUIみたいにすれば出来なくはないけど。

関数のラップが薄いから、その気になれば
Win32API直書きの勉強もできるのが、MFCのメリットじゃないかと。

514 ：デフォルトの名無しさん：2008/01/19(土) 22:41:34

シリコンバレー技術者の平均年収が8万5000ドルを突破--
CおよびC++の人気は変わらず
http://blog.japan.zdnet.com/dp/a/000419.html

ここ十年でいろんな言語が出てきたけど、やっぱC/C++がいいやという流れに
なりつつある

515 ：デフォルトの名無しさん：2008/01/19(土) 22:50:07

CEventのコンストラクタから例外投げてほしかったな
インスタンス作った後にGetLastError呼べって…なにそれ

516 ：デフォルトの名無しさん：2008/01/19(土) 22:52:56

ATLはSTL連携機能が少しあった希ガス

517 ：デフォルトの名無しさん：2008/01/19(土) 22:57:07

コレクション周りがちょこっとにょ

518 ：デフォルトの名無しさん：2008/01/20(日) 00:18:12

>>514
まあシリコンバレーから見たら日本全体が奴らが作ったもの使って
仕事してる下請みたいなもんだからな

519 ：デフォルトの名無しさん：2008/01/21(月) 06:28:13

>>518
みたいなもん，じゃなくてその通りなわけだが．
そして俺は孫請けなわけだが．

520 ：デフォルトの名無しさん：2008/01/21(月) 13:38:42

一介のプログラマーが何大袈裟なこと語ってるんだｗ
日本全体がシリコンバレーって洒落かよｗ
確かに国内はシリコンが豊富だが‥‥‥

521 ：デフォルトの名無しさん：2008/01/21(月) 13:51:26

std::exceptionってwchar_t無視の糞設計じゃん

522 ：デフォルトの名無しさん：2008/01/21(月) 13:58:05

そんなもの使うのはNTだけだ。

523 ：デフォルトの名無しさん：2008/01/21(月) 13:58:45

設計 != 実装

524 ：デフォルトの名無しさん：2008/01/21(月) 14:01:31

>>522
今はそうでもない。

525 ：デフォルトの名無しさん：2008/01/21(月) 14:17:42

>>520
日本語でおｋ

526 ：デフォルトの名無しさん：2008/01/21(月) 16:47:36

>>525
その言葉は、519,518にも言いたい

527 ：デフォルトの名無しさん：2008/01/21(月) 17:36:28

さいきんは専ら自然言語で仕事だわい

528 ：デフォルトの名無しさん：2008/01/22(火) 05:09:49

プログラマも政治を覚えなきゃ生きていけないから自然言語は必須だよな。

529 ：デフォルトの名無しさん：2008/01/22(火) 07:27:23

上司=禿とか書いたら即人生ダウンだからな。
メモリーリークなんかよりはるか深刻な不具合だ。

530 ：デフォルトの名無しさん：2008/01/22(火) 08:27:37

上司.頭髪 = 禿;
上司.ヅラ = true;

531 ：デフォルトの名無しさん：2008/01/22(火) 13:08:35

if(俺.指摘(社長.頭髪.ズレ) == 社長.激怒)
　会社.解雇(俺)

532 ：デフォルトの名無しさん：2008/01/22(火) 20:21:00

そのelseは何なんだ？昇進か？まさかな・・・

533 ：デフォルトの名無しさん：2008/01/23(水) 01:22:51

>>532
会社.一生窓際(俺)

534 ：デフォルトの名無しさん：2008/01/23(水) 01:39:39

一生窓際で保証されてるのか？
羨ましい。　
俺と変わってくれ。

535 ：デフォルトの名無しさん：2008/01/23(水) 01:42:49

俺の場合は、会社.一生瀬戸際(俺) だな...

536 ：デフォルトの名無しさん：2008/01/23(水) 11:57:36

VC++6.0だけは勘弁勘弁

537 ：デフォルトの名無しさん：2008/01/23(水) 12:09:28

いや、MFCは勘弁勘弁

538 ：デフォルトの名無しさん：2008/01/23(水) 13:15:51

例外を使えないわけじゃないよ。
C++の例外が使い物にならないのだ。

539 ：デフォルトの名無しさん：2008/01/23(水) 13:53:33

例外を、単なる別のエラー処理技法のように扱ってはいけません。
エラーコードを返したり、グローバル変数の設定したりすることと
同レベルだと思ってはいけません。例外は、それを取り巻くコードの
構造と意味を、根底から覆します。例外は、プログラムの実行時
セマンティックを一時的に繋ぎ変え、通常実行しているコードを迂回し、
こういう状況でなければ決して実行されないコードを動作させます。
例外は、エラー状態を認知させ、プログラムの死という罰則を用いて
その状態を改めようとします。

このように、例外には単純なエラー処理を超えた特性があります。
これらの特性を必要としない、理解しない、あるいは文書化したく
ないなら、例外をスローしてはいけません。
例外以外のエラー処理技法を探してください。

540 ：デフォルトの名無しさん：2008/01/23(水) 13:59:41

＞プログラムの死という罰則を用いて

catchして握り潰すだけじゃね？

541 ：デフォルトの名無しさん：2008/01/23(水) 14:07:33

まあ、ｔｒｙ　ｃａｔｃｈ　無理して使うこともないだろ

542 ：デフォルトの名無しさん：2008/01/23(水) 14:26:04

逆だろ。

戻り値判定無理して使えば、開発者の１人判定忘れで大騒ぎ。

543 ：デフォルトの名無しさん：2008/01/23(水) 14:48:15

まあ、ｔｒｙ　ｃａｔｃｈ　無理して使うこともないだろw

544 ：デフォルトの名無しさん：2008/01/23(水) 14:49:04

まあ、ｔｒｙ　ｃａｔｃｈ　無理して使うこともないだろw

545 ：デフォルトの名無しさん：2008/01/23(水) 15:55:50

STLみたいなうんこが標準ライブラリ気取ってる時点であれ。

546 ：デフォルトの名無しさん：2008/01/23(水) 15:56:58

まあ、ｔｒｙ　ｃａｔｃｈ　無理して使う気がない。

547 ：デフォルトの名無しさん：2008/01/23(水) 15:58:30

STLより線形リストがうんこ

548 ：デフォルトの名無しさん：2008/01/23(水) 16:27:26

Winみたいなうんこが標準OS気取ってる時点であれ。

549 ：デフォルトの名無しさん：2008/01/23(水) 16:34:40

窓にはシェアという既成事実があるが
STLはどうかな

550 ：デフォルトの名無しさん：2008/01/23(水) 16:50:39

例外を使うか使わないか
そんな問答はナンセンス
明らかに有害なので使うべきではない

551 ：デフォルトの名無しさん：2008/01/23(水) 16:58:47

＞STLはどうかな

STLにシェアは無くても良い。

とにかく、charでなくてstringを使うし、vectorも絶対使う。

552 ：デフォルトの名無しさん：2008/01/23(水) 17:01:42

>>541-546が何かの歌詞に見えた

553 ：デフォルトの名無しさん：2008/01/23(水) 17:04:38

C++でbyte array使う時ってみんな
new char[size]
みたいにしてる？
それともvector使ってる？

554 ：デフォルトの名無しさん：2008/01/23(水) 17:05:59

stringだろ。

char *として参照するなら、string::c_ptr() があるし。

555 ：デフォルトの名無しさん：2008/01/23(水) 17:26:36

std::basic_string<TCHAR>

556 ：デフォルトの名無しさん：2008/01/23(水) 17:27:53

stringだと'\0'が入ってた時どうすんの？

557 ：デフォルトの名無しさん：2008/01/23(水) 17:28:11

CAtlString

558 ：デフォルトの名無しさん：2008/01/23(水) 17:30:04

>>553
vector

>>554
c_str()のことなら、返り値はconst char*だ。書き込みは保証されない。

559 ：デフォルトの名無しさん：2008/01/23(水) 17:30:08

stlに不備があるからboostとか持てはやされるんじゃないの？

560 ：デフォルトの名無しさん：2008/01/23(水) 17:31:06

System::String

561 ：デフォルトの名無しさん：2008/01/23(水) 17:32:49

std::wstring

562 ：デフォルトの名無しさん：2008/01/23(水) 17:54:59

>>556
長さは別途保持しているから、別にどうもしない。

563 ：デフォルトの名無しさん：2008/01/23(水) 18:17:37

vector<BYTE>

564 ：デフォルトの名無しさん：2008/01/23(水) 20:15:42

vector<uint8_t>

565 ：デフォルトの名無しさん：2008/01/23(水) 20:16:46

らっぱ～　かませば、皆同じ。

566 ：デフォルトの名無しさん：2008/01/23(水) 20:23:21

>>554
stringｗｗｗｗｗｗｗｗｗｗｗ

一回vectorと速度比較してみろって。

567 ：デフォルトの名無しさん：2008/01/23(水) 20:56:15

boost::scoped_array

568 ：デフォルトの名無しさん：2008/01/23(水) 21:25:16

どうして配列がベクトルなの？

569 ：デフォルトの名無しさん：2008/01/23(水) 21:41:25

>>521
STLのヘッダ類の前に
#define char wchar_t

570 ：デフォルトの名無しさん：2008/01/23(水) 21:52:38

ドトネトのSystem::Generics::Listはヒドいとおもた。

571 ：デフォルトの名無しさん：2008/01/23(水) 23:48:15

QValueVector< QString >

572 ：デフォルトの名無しさん：2008/01/24(木) 00:11:55

STLのコンテナとアルゴリズムよりエレガントな設計のコンテナなんて見たことねーぞ

573 ：デフォルトの名無しさん：2008/01/24(木) 00:22:41

>>506
そもそも、MFCの前身が作られた時期には、STLは未だ承認されていない。

574 ：デフォルトの名無しさん：2008/01/24(木) 00:27:35

ぁゃι ぃ

575 ：デフォルトの名無しさん：2008/01/24(木) 00:33:17

MSC7.0が1992だっけか

576 ：デフォルトの名無しさん：2008/01/24(木) 01:41:10

>>572
美しさと効率は、必ずしもいっちしない

577 ：デフォルトの名無しさん：2008/01/24(木) 01:59:50

でも、STLってそんな効率悪い実装をせざるを得ない仕様だったっけ？

578 ：デフォルトの名無しさん：2008/01/24(木) 06:03:34

中身までちゃんとみてないが、vectorは単に[]で
アクセスするだけでも、ただの配列の2倍以上は遅い。
ａｔ()だとさらに遅い。
DEBUGビルドだとさらに10倍くらい遅い。

何でもかんでもvector使うのはさすがにアレだな

579 ：デフォルトの名無しさん：2008/01/24(木) 07:43:43

馬鹿がいる。

580 ：デフォルトの名無しさん：2008/01/24(木) 12:26:29

>>578

んなぁーこたない。

581 ：デフォルトの名無しさん：2008/01/24(木) 13:39:31

>>573

そうだとしてもSTL完成した時点で揃えりゃいいだろ？

582 ：デフォルトの名無しさん：2008/01/24(木) 15:36:44

>>580
こんな感じで時間計ると、Debugビルド(最適化なし)で100倍くらい差が付く。
最適化ありのReleaseビルドでも3倍は差がつくんだが、何か俺が間違ってるのか？

std::vector<int> vec(2);
int ary[2];
DWORD time1, time2;

ary[0] = 1;
vec[0] = 1;

time1 = GetTickCount();
for(int i=0; i < 10000000; i++) {
ary[0] += 1;
ary[1] = ary[0];
}
time1 = GetTickCount() - time1;

time2 = GetTickCount();
for(int i=0; i < 10000000; i++) {
vec[0] += 1;
vec[1] = ary[0];
}
time2 = GetTickCount() - time2;

583 ：デフォルトの名無しさん：2008/01/24(木) 16:09:57

>>581
何故MFC3.0以上にもなって互換性犠牲にして使われてもいないSTLに擦り寄る必要があるんだ?

584 ：デフォルトの名無しさん：2008/01/24(木) 16:10:51

vectorがはやったったぞ
#include <iostream>
#include <vector>
using namespace std;
main(){
std::vector<int> vec(2);
int ary[2];
DWORD time1, time2;

ary[0] = 1;
vec[0] = 1;

time1 = GetTickCount();
for(int i=0; i < 10000000; i++) {
ary[0] += 1;
ary[1] = ary[0];
}
time1 = GetTickCount() - time1;

time2 = GetTickCount();
for(int i=0; i < 10000000; i++) {
vec[0] += 1;
vec[1] = ary[0];
}
time2 = GetTickCount() - time2;
cout<<time1<<" "<<time2;}

585 ：デフォルトの名無しさん：2008/01/24(木) 16:12:26

>>583
おまいばかじゃね？
Ｍ＄がＭＦＣを亡き者にしてドトネトに逝こうしてるのに。
ＭＦＣ終焉。

586 ：て：2008/01/24(木) 16:19:07

1994年にドトネトはない

587 ：デフォルトの名無しさん：2008/01/24(木) 16:20:28

STL.NET

588 ：デフォルトの名無しさん：2008/01/24(木) 16:23:53

>>587
劣化パチモン

589 ：デフォルトの名無しさん：2008/01/24(木) 18:54:17

>>582
Visual C++か？
それならSTLの仕様ではなく、実装の問題。
セキュリティ対策で範囲チェックが入るから、素の配列に比べて遅くなる。
_SECURE_SCLを0に定義しておけば範囲チェックは無くなる。
また、&vec[0]でポインタを得て操作するという手もある。

俺もVC++ 9でそのコードをコンパイルしてみたが、
/O2や/Oxだと配列のループは消滅する。
ダミーの関数呼出を入れて、_SECURE_SCL 0定義してやれば/O2や/Oxで両者互角だった。

Cの関数と違って_sみたいな見た目の違いが出ないから見た目わからないけど、
C++ライブラリも安全対策へ注力しているのが近頃のVC++。

590 ：デフォルトの名無しさん：2008/01/24(木) 18:57:35

>>589
なるほど、そういうことだったのね。

591 ：デフォルトの名無しさん：2008/01/24(木) 19:11:17

MSってこれだから嫌なんだよ
なんでもかんでもMSルールで染め上げようとするんだもの

592 ：デフォルトの名無しさん：2008/01/24(木) 19:28:57

何もしなければ、セキュリティ対策がなっていないと叩かれるネタになる。
やってもやらなくても叩かれるMS涙目ｗ

593 ：デフォルトの名無しさん：2008/01/24(木) 21:37:05

人気者だから仕方ないんじゃね？信者もアンチも人気の証。

594 ：デフォルトの名無しさん：2008/01/25(金) 01:00:08

Dinkumware?(もう忘れた。確かVC++に付属してる奴)それともSTLport？
自分は直接試してないから強くは主張できないけどね。

でも、STLってかなりよくできてると聞いたけど最適化についてはわからない。
案外、ライブラリによってはIntel C++と相性が悪いかもしれないどろうけど
どうだろ？

少なくともValarrayよりはましだと思うけど。

595 ：デフォルトの名無しさん：2008/01/25(金) 01:02:11

↓qsort対std::sortネタが振られる

596 ：デフォルトの名無しさん：2008/01/25(金) 01:37:52

ここでPrologに一票ｗｗ

597 ：デフォルトの名無しさん：2008/01/25(金) 08:35:55

>>596
プロローグ？プロログ？どっちが正しいん？

598 ：デフォルトの名無しさん：2008/01/25(金) 08:42:48

Windowsには期待するけどVC++には期待しません。

Vi$taはｶﾞｶｰﾘだたので、Win7頑張って。

599 ：デフォルトの名無しさん：2008/01/25(金) 23:28:52

というか、at()があるのにoperator[]も範囲チェックするってどんだけ馬鹿なの。

600 ：デフォルトの名無しさん：2008/01/25(金) 23:52:23

iostream ｷﾓﾁﾜﾙｽ

601 ：デフォルトの名無しさん：2008/01/26(土) 01:49:08

>>599
それだけプログラマが当てにされない現実。

602 ：デフォルトの名無しさん：2008/01/26(土) 02:12:16

>>597
プロログ

603 ：デフォルトの名無しさん：2008/01/27(日) 13:07:15

>>599
>>601
at()は範囲チェックで例外、operator[]はassertじゃなかったっけ。

604 ：デフォルトの名無しさん：2008/01/27(日) 13:46:58

>>603
なるほどね。メモリ保護に任せると割当単位によってはSEGVにならないし、reserveして書くみたいな馬鹿コードも検出できるからまあ確実ではあるか>assert

605 ：デフォルトの名無しさん：2008/01/27(日) 23:57:36

>>582
その手のテストは最適化効いてコード消されてて速くなってる場合もあるぞー。
実際俺のとこだとそのintの配列はReleaseだとアセンブリはごっそりなく
なっててループしてない。
vectorの方はoperatorとか通るからか、勝手な最適化は効かないでご丁寧に
ループしてる。

606 ：デフォルトの名無しさん：2008/01/28(月) 00:11:05

てかさ、vectorの利点というのは実体が&vec[0]から連続して
並んでいることが保障されていることでしょ。

だから、普通はループ処理とかで、vec[0]=とかやらないって。
ポインタ取り出して操作するに決まってるじゃない。

607 ：デフォルトの名無しさん：2008/01/28(月) 01:17:39

>>582
参照されないint配列のfor操作とかは最適化されて消える。
後ろで配列内の値を参照(sum取って表示とか)するようにすると同一になるはず。
というか試してみたがvectorとint配列の[]で速度に差は出ない。

608 ：デフォルトの名無しさん：2008/01/28(月) 09:11:37

vectorのポインタが変わってしまうのは要素数が増えたとき、
でしたっけ？

609 ：デフォルトの名無しさん：2008/01/28(月) 10:01:06

先頭の要素が削除されたら？

610 ：デフォルトの名無しさん：2008/01/28(月) 11:29:06

>>608 >>609
いいえ。

611 ：デフォルトの名無しさん：2008/01/28(月) 14:43:24

要素数がリザーブサイズを超えたときに再配置かな。

612 ：デフォルトの名無しさん：2008/01/28(月) 22:23:34

stringの[]遅い・・
string 7813
vector 1594
char[] 1578
こんな感じだった

613 ：デフォルトの名無しさん：2008/01/28(月) 22:36:13

VC6においては、
stringの reference operator[](size_type _P0)
{if (_Len < _P0 || _Ptr == 0)
return ((reference)*_Nullstr());
_Freeze();
return (_Ptr[_P0]); }

vectorの[] reference operator[](size_type _P)
{return (*(begin() + _P)); }

614 ：デフォルトの名無しさん：2008/01/30(水) 01:52:50

いつまでもふたりこのままで
いっしょにいたいとねがうように
それはほんのいっしゅんで
ひかるほしにかわってゆく
だれよりもいちばんちかくで
えがおのゆくへをだきしめたい
めぐりあえたこのきせき
ずっとずっとゆめのなかからさめないように

615 ：デフォルトの名無しさん：2008/01/30(水) 02:02:01

いいそひだえめず？

616 ：デフォルトの名無しさん：2008/01/30(水) 03:05:17

でょほほりのあず

617 ：デフォルトの名無しさん：2008/01/30(水) 04:04:14

抗しろああしろざま

618 ：デフォルトの名無しさん：2008/02/01(金) 18:58:09

けっきょく九割くらいはMFC書いてるだけだろ

619 ：デフォルトの名無しさん：2008/02/02(土) 18:52:30

M$の中の人ですか

620 ：デフォルトの名無しさん：2008/02/02(土) 21:46:17

流れぶった切るけど、ネームスペースのエイリアス切れる機能が便利だと思う。
シンボル名単体か、フルパッケージ名をタイプするしか選択肢がない言語に戻ると
ちょっとキツい。
結果的に、同時に使いそうなクラスのこと考えて結構長いクラス名になりがちな気がするし。

621 ：デフォルトの名無しさん：2008/02/02(土) 23:50:04

流れどころか、最近は澱んでた印象。

622 ：デフォルトの名無しさん：2008/02/02(土) 23:55:40

>>620
マクロ定義すれば、なんとかなるんじゃね。

623 ：デフォルトの名無しさん：2008/02/03(日) 02:44:54

そういえば、Javaで１００以上もある分岐条件とかってどうやって表現する？
具体的にはネットワークプログラミングで受け取ったパケットの先頭8ビットを見て処理を分けるような場合。
CやC++だったら、構造体と、関数ポインタがあるから、例え分岐条件が1万あったとしても

for (int i = 0; i < sizeof(構造体A); i++) {
if (構造体A[i] == receiveData) {
構造体A[i].処理();
}
}

ってかなり短く表現できるじゃん？これって他の言語だとどうやるんだ？
スレ違いかもしれんが、前々から疑問だった。

624 ：623：2008/02/03(日) 02:46:52

あ、しばらくCを書いてないからバグってるや。
if分の比較は以下に修正。、

if (構造体A[i].data == receiveData) {

625 ：デフォルトの名無しさん：2008/02/03(日) 03:07:24

>>623
Windowsメッセージのように数千あるメッセージをswitch/caseで処理するのだ。
これが最速。後は好みでその上にクラスでもかぶせりゃいい。

626 ：623：2008/02/03(日) 03:42:34

>625
返事ありがとう。私もJavaではif/elseもしくはswitch/caseで書いている。
でもその方法、最速なのはわかるけど、コード量増えるよね。
コピペミスとかもおきやすいし。
条件が増えてcaseの後にダラダラと条件がつくと理解しにくいと思う。

構造体で条件を一元管理すると、Excelからコピペで持ってこれるし、
ソースで見ても、きれいで見やすいし
条件が一個増えたとしてもすぐに対応可能だから、
なんで構造体使えないのかと思うわけですよ。

条件が一個増えた場合↓
if ((構造体A[i].data == receiveData) && (構造体A[i].state == state)){

100以上ある、switch/caseで条件の数がcaseごとに違うのとかって
バグっているんじゃないかと不安になる。

627 ：デフォルトの名無しさん：2008/02/03(日) 03:55:50

構造体、クラスを比較しろよ

628 ：デフォルトの名無しさん：2008/02/03(日) 04:21:33

>>623
for (int i = 0; i < クラスA.length; i++) {
if (クラスA[i].isEqual(receiveData)) {
クラスA[i].処理();
}
}

629 ：デフォルトの名無しさん：2008/02/03(日) 04:25:02

その構造体の関数ポインタに処理をセットする部分はswitch/caseと同程度の
コード量になるはずじゃないのか？

630 ：デフォルトの名無しさん：2008/02/03(日) 04:26:34

メッセージマップみたいなのをExcelの仕様書から自動生成するんじゃね？

631 ：デフォルトの名無しさん：2008/02/03(日) 04:39:27

switch/caseを自動生成させても同じじゃないのか？

632 ：デフォルトの名無しさん：2008/02/03(日) 06:53:48

for if を展開してコンパイラに渡せばよい

633 ：623：2008/02/03(日) 11:30:34

>628
クラスAの配列ってことは、receiveData と比較する、
クラスAのインスタンス変数dataに値を設定する箇所が必要だよね？
あと、呼ばれるメソッド名を、きれいにクラスに渡せる？

>629
struct test
{
int a[2];
void (*pf[])();
};

const struct test test1[] = {
　　　　　　　　　　　　　　 {0x0001, funcPointer1},
　　　　　　　　　　　　　　 {0x0002, funcPointer2},
　　　　　　　　　　　　　　 {0x0003, funcPointer3}
　　　　　　　　　　　　　　};

分岐条件が増えたとしても

const struct test test1[] = {
　　　　　　　　　　　　　　 {0x0001, 0x0003, true, false, funcPointer1},
　　　　　　　　　　　　　　 {0x0002, 0x0003, true, false, funcPointer2},
　　　　　　　　　　　　　　 {0x0003, 0x0003, true, false, funcPointer3}
　　　　　　　　　　　　　　};
どんどん増えていくけど、私には一覧で見えるのですごく見やすい。

634 ：デフォルトの名無しさん：2008/02/03(日) 12:07:38

C++なんてどんどん使われなくなってくだろ

635 ：デフォルトの名無しさん：2008/02/03(日) 12:22:05

LLになれるとC++なんて二度と使いたくないって気になる。

636 ：デフォルトの名無しさん：2008/02/03(日) 12:25:23

普段は LL で、性能が気になる所だけ C のモジュールを作るというのが良いよね
LL 拡張専用言語として使うなら C++ より C の方が効率的だし活用範囲が広い

637 ：デフォルトの名無しさん：2008/02/03(日) 12:25:51

C++ってLispだなって思うｗ

638 ：デフォルトの名無しさん：2008/02/03(日) 12:35:40

Lisp くらいパースが簡単で、Lisp くらいマクロが強力で、
REPL が備わっていたら良いんだけどね。

639 ：デフォルトの名無しさん：2008/02/03(日) 13:57:55

Ｊａｖａのガーベッジコレクションは欠陥設計
そもそも、スタティック領域を持つことが
許されているんだから、誰かがグローバル域に
オブジェクト参照持ち続けてたら、どんどんメモリーを
圧迫していく。
最悪なことにＪａｖａはメモリー管理を意識しなくて良いような
嘘がまかり通って、知的障害者がぼこぼこオブジェクトを作っては
放置していく。
はっきり言ってC/C++の方がよっぽどまし。
素人を使ってＷＥＢアプリとか作るって頭おかしいでしょ（ｗ

640 ：デフォルトの名無しさん：2008/02/03(日) 14:01:23

＞６２３
Ｃ/C++の関数ポインターってvirtualで表現できるだろ
根本的に抽象化してないオブジェクト設計がおかしい

641 ：デフォルトの名無しさん：2008/02/03(日) 14:32:15

LLとC（C++）があればJavaの出番はないんじゃないかって最近思う

642 ：デフォルトの名無しさん：2008/02/03(日) 14:33:53

趣味でLLを作るときはC++が良い感じｗ

643 ：デフォルトの名無しさん：2008/02/03(日) 14:46:48

>>639
他の言語を貶しても誰も褒めてくれないよ。
不服なら、その言語スレで、解決方法を提案してみなされ。

644 ：デフォルトの名無しさん：2008/02/03(日) 15:20:55

>>633
interface func {
  public abstract void func();
}
class test {
  public int data;
  func func;
  public test(int data, func func){
    this.data = data;
    this.func = func;
  }
}
class func1 implements func {
  public void func() {}
}
final class funcs {
  static final test[] test1 = {
    new test(0x001, new func1()),
    new test(0x002, new func2()),
    new test(0x003, new func3())
  };
}

645 ：デフォルトの名無しさん：2008/02/03(日) 15:58:05

> LLになれるとC++なんて二度と使いたくないって気になる。

中高生向け学習用言語で誰でも書けるhtml出力コードを安い労働単価で
書き続けていてください。

646 ：デフォルトの名無しさん：2008/02/03(日) 16:04:42

>>645
中高生相手にムキになるなよ。

647 ：デフォルトの名無しさん：2008/02/03(日) 16:15:32

LOGOの時代がきます。

648 ：デフォルトの名無しさん：2008/02/03(日) 16:20:23

>>647
http://dolittle.eplang.jp/index.php?Logo%BE%F0%CA%F3%BC%BC
>LOGOは過去の言語です。ロゴ坊もすでに開発を終えていますので、
>興味のある方は後継のプログラミング言語「ドリトル」など新しい言語をお使いください。

過去の言語になってるじゃねーかｗｗｗ

649 ：デフォルトの名無しさん：2008/02/03(日) 16:22:48

そういう評価の質は評価者の質と対になっている物だよな。
ドリトルを勧める評価者の評価ってどうなんだろう。

650 ：デフォルトの名無しさん：2008/02/03(日) 16:33:31

>>649
しらねｗｗｗ

651 ：デフォルトの名無しさん：2008/02/03(日) 16:38:13

OS開発に採用された時点でC/C++はもう勝ち組言語。
OSのあらゆる機能に容易にアクセスできるわけで。

実際ここ数十年は結局、オブジェクト指向とか関数型とか簡単とかを
売り文句にした一山いくらの言語がはやりすたりしただけで、どれも
C/C++の薄いラッパーに過ぎないね。

652 ：デフォルトの名無しさん：2008/02/03(日) 16:41:12

つまり FFI で OS のあらゆる機能に用意にアクセス出来る Lisp は最強と言う事か。
ラッパーも要らんし。確かに C は OS 開発言語として不動の位置を占めているが、
C++ は C があるからいつ居なくなっても困らんな。

653 ：デフォルトの名無しさん：2008/02/03(日) 16:46:51

>>649
変な意見も、無知が見れば結構まともっぽく見えちゃうから危険だよな。

654 ：デフォルトの名無しさん：2008/02/03(日) 16:47:27

>>652
Lisp最強にするには、まずはLispマシンはやらせるとっからじゃね。

655 ：デフォルトの名無しさん：2008/02/03(日) 16:55:04

JavaもC#も、夢を叶えようと頑張ってC++の仕様から色々引き算してシンプルさを意識したけど、
だんだん「広く深く濃く」使われていくうちに、現実をちゃんと見なきゃいけなくなって
結局はどんどん複雑怪奇になっていってる。

「俺が世界の支配者ならこの世は理想郷に限りなく近いのに」と思ってた思春期のボーヤが、
働き始めて数年経ってようやく、自分がツバ吐きかけてたものがいかに「現実を切り抜ける」ために
有効だったか思い知り始めたという感じ。

656 ：デフォルトの名無しさん：2008/02/03(日) 16:59:46

まあWin32APIもLinuxのシステムコールもインターフェースがCだからね。
C/C++以外はどれもラッパーが必要になる。

ただまあ難しい事やらない限りは言語なんてどれでもできること同じだし、
なんつーか言語なんてOSとかアルゴリズムを利用するためのインターフェースに
過ぎないんだよね。

657 ：デフォルトの名無しさん：2008/02/03(日) 17:00:40

>>655
そこで妥協したら負けかなと思ってる。

658 ：デフォルトの名無しさん：2008/02/03(日) 17:07:18

>>656
それはそうだけどさ、デモ用の簡単なツールとか、自分が楽するための
ツール作成にはＬＬって限りなく便利。で、Ｐｅｒｌはもともとそのための
言語じゃなかったのだろうか。

Ｊａｖａが目指した理想は素晴らしいものだったけど。

659 ：デフォルトの名無しさん：2008/02/03(日) 17:11:43

>>655
それでもC++よりは余計な機能が削ぎ落とされてていいと思う

660 ：デフォルトの名無しさん：2008/02/03(日) 17:18:08

>>656
WindowsはPASCAL呼び出しじゃね。

661 ：デフォルトの名無しさん：2008/02/03(日) 17:40:56

>>659
君の思うC++の余分な機能ってなによ？

662 ：デフォルトの名無しさん：2008/02/03(日) 17:46:52

そもそも作るものによって言語変えること自体がすげー不便。
せいぜいC++とPerlくらいでいいよ。

663 ：デフォルトの名無しさん：2008/02/03(日) 17:52:35

>>659
余計な機能は使わなければいい。C++はそれができる。

たとえば、パフォーマンスが理由で特定のメンバ関数を仮想関数にしたくないならそれが自由にできる。
文字列処理も、パフォーマンスを理由に固定長のバッファにしたいとか、好きなレベルの処理を自由に実装できる。
自由なんだ。

664 ：デフォルトの名無しさん：2008/02/03(日) 17:58:12

>>662
Perlはなぁ・・・本当に自分しかソースさわらないもの限定ならいいけどさｗ

665 ：デフォルトの名無しさん：2008/02/03(日) 18:08:13

>>661
C++というものの性格上しょうがないとはいえ、まずdelete
ようはガベージコレクションのありなしで、これを解決するには
ライブラリの知識を得る必要がある
そして、STLでも頻繁に使われる演算子オーバーロード
これも可読性を下げる
個別にあげつらうことは出来ないが、複雑怪奇な文法のせいで
IDEのエラー検出機能や補完機能が制限されるのもマイナス

666 ：デフォルトの名無しさん：2008/02/03(日) 18:09:47

>そして、STLでも頻繁に使われる演算子オーバーロード
>これも可読性を下げる

バカまるだし

667 ：デフォルトの名無しさん：2008/02/03(日) 18:14:11

>>660
typedef追っかけてくと最終的に__stdcallに辿り着くよ

668 ：デフォルトの名無しさん：2008/02/03(日) 18:16:09

>>660
stdcall
引数のスタックの積み上げは右から左＝C(cdecl)
スタックポインタの引き戻しはサブ側で行う＝PASCAL∴可変長引数は×

669 ：デフォルトの名無しさん：2008/02/03(日) 18:17:16

>>666
標準入出力の<<などは、意味を知ってるから便利に思えるものの、
初見で見たら多くの人は戸惑うのではないか？
演算子オーバーロードの乱用を誘発する悪しき例とも言える
演算子オーバーロードの乱用で可読性が下がるってのは良く言われてること
馬鹿だけが言ってるわけではない

670 ：デフォルトの名無しさん：2008/02/03(日) 18:17:39

>>665
演算子のオーバーライドが可読性を下げるというのは、使い方間違ってないか？。
deleteもガベージコレクタが無いから、ライブラリが補ってるって事で、余計な機能ではない。ライブラリの選択で必要な機能だけを追加してるのだ。

671 ：デフォルトの名無しさん：2008/02/03(日) 18:19:31

>>670
逆に言えば、ガーベッジコレクションがないということで、deleteや
ライブラリのポインタの機能など余計な機能をくっつけざるを
得なかったってことだろ

672 ：デフォルトの名無しさん：2008/02/03(日) 18:26:46

余計な機能は使わなければいいって言うが、他人が使う以上そうも言ってられないんだよな

673 ：デフォルトの名無しさん：2008/02/03(日) 18:28:29

言語の組み込み機能が増えるよりいいだろ
実際不自由してないし

674 ：デフォルトの名無しさん：2008/02/03(日) 18:30:02

C++が設計されたときにもうGCはあったの。C++が参考にした言語は
GCがついてて遅すぎたの。実用性を重視してGCを外したの。で、一番使われる
ようになったの。
コンピュータ速くなってきたからJavaはうっかりGCで設計しちゃったの。
でも、また結局遅い遅いと叩かれちゃったの。
だからね、言語みたいな基本的なところは速くなくっちゃいけないの。

675 ：デフォルトの名無しさん：2008/02/03(日) 18:30:03

>>671
ガベージコレクションってよしあしじゃない？プログラマが本当の意味で、
メモリを管理できない。スマートポインタで十分なように思う。

で、プログラマって本当にいわれるようにメモリが管理できないもの？
メモリリークで痛い目見た経験はあるけど。本当に数えるくらいしかない。

676 ：デフォルトの名無しさん：2008/02/03(日) 18:34:57

>>674
そんな経緯はどうでもいい
C++が今現在余計な機能を持っていると思うことに変わりはない

>>675
例えば、スマートポインタも、auto_ptr、shared_ptr、weak_ptrといろいろあって
それぞれの特徴、使い方を覚えなくてはいけない
その時点でかなり「余計な機能」だと思う
正直言って、weak_ptrだけで十分
あと、良し悪しなのは当然で、余計かどうかは個人個人の主観でしかない
もともと好き嫌いを話してるだけなのだからこれは当たり前

677 ：デフォルトの名無しさん：2008/02/03(日) 18:34:59

俺はoperator<<<とかoperator===とかもOKにしてもらいたいくらいだぜ

System.out.print("Hello");
より
cout << "Hello";
でおｋ

678 ：デフォルトの名無しさん：2008/02/03(日) 18:38:04

>>677
まあ確かに<<は便利な点もあると思う
しかし、<<の意味がわかってる今だからいいだけで、
最初は戸惑うだろうし、真似して変な文脈で<<を
使い出す馬鹿が続出するという欠点もある

679 ：デフォルトの名無しさん：2008/02/03(日) 18:46:54

C++は多重継承とテンプレートがどうかと思うな
二つを組み合わせたりするから意味わからん

680 ：デフォルトの名無しさん：2008/02/03(日) 18:54:51

>>676
経緯を知らないからお前の知識が浅いんだと思う

681 ：デフォルトの名無しさん：2008/02/03(日) 18:58:35

>>680
ちなみに、C++と設計と進化は読んでて、ガーベッジコレクションの
経緯は知っていたが

682 ：デフォルトの名無しさん：2008/02/03(日) 18:59:01

>>676
それはGCとか余計な機能が無いって事ではないのか？

683 ：デフォルトの名無しさん：2008/02/03(日) 19:00:08

>>682
どっちを余計と捉えるかという主観の問題だね
量的にも後者にまつわるルールの方が多いと感じるが

684 ：デフォルトの名無しさん：2008/02/03(日) 19:00:52

くくって書くととエラーになる

685 ：デフォルトの名無しさん：2008/02/03(日) 19:04:25

なんかGCを基本機能に入れるかどうかなんて古典的な議論だな。
新しい言語作るからどうしようって言うんならわかるが、C++はなしだし、
Javaはありだしって事実について言いあってなにを発見したいんだ？

686 ：デフォルトの名無しさん：2008/02/03(日) 19:29:25

>>675
GC をプログラマの負担低減だけで捕らえるとそうなる
スループットの向上やフラグメンテーション対策と考えると
必要性が見える。なんで鯖向けに向いているかも

687 ：デフォルトの名無しさん：2008/02/03(日) 19:38:26

<<676
今はauto_ptrしか無いぞ。
あと次の標準ではauto_ptrはdeprecatedになるから安心しろ。

688 ：デフォルトの名無しさん：2008/02/03(日) 19:42:17

んなこた知ってるよｗ

689 ：デフォルトの名無しさん：2008/02/03(日) 20:04:03

力比べでつか？

690 ：デフォルトの名無しさん：2008/02/03(日) 20:07:18

>>686
なるほど。オモシロイ。

http://edocs.beasys.co.jp/e-docs/jrockit/geninfo/diagnos/tuning_tradeoffs.html

691 ：デフォルトの名無しさん：2008/02/03(日) 20:10:03

こっちのほうがええか
http://www.ibm.com/developerworks/jp/java/library/j-jtp01274/

692 ：デフォルトの名無しさん：2008/02/04(月) 09:12:17

C/C++用のガベージコレクタライブラリなんてのもあるのな。

693 ：デフォルトの名無しさん：2008/02/04(月) 10:54:06

あの，友人が「プロトタイプベースの言語最高」とか
叫んでいたんですが，それってクロージャで代用
できたりしませんか？

C++の次の規格でにラムダ式とクロージャが使えるように
なったら，「C++最高」って叫んでもいいですか？

694 ：デフォルトの名無しさん：2008/02/04(月) 11:59:21

それって何ていう、「C++ってCで代用できたりしませんか？」

できません。

695 ：デフォルトの名無しさん：2008/02/04(月) 22:03:03

boostのラムダは苦しすぎるしうまいこと言語に入れてもらいたいもんだね

696 ：デフォルトの名無しさん：2008/02/04(月) 22:15:23

プロトタイプ・ツール作成用にLL、本格アプリ用C++の２つマスターすればよいでFA？

697 ：デフォルトの名無しさん：2008/02/04(月) 23:28:25

>>696
それだけでいいって言われたら、あなたは満足してそれだけで学ぶことをやめてしまう
だろうから、「それだけでは不十分」といってあげる。俺って、なんて優しいのだろう！

698 ：デフォルトの名無しさん：2008/02/04(月) 23:59:31

皆はやっぱBASICからはじめたんだよね。もちろん。

699 ：デフォルトの名無しさん：2008/02/05(火) 01:45:48

>>696
C++ の代わりにその LL の実装言語 or 拡張言語をやっておくと良いよ
ま、大抵は C だけど

700 ：デフォルトの名無しさん：2008/02/05(火) 04:31:45

>>696
それなりの経験があると、C++のノウハウが高いのでプロトタイプ作るのに
言語変える方がめんどくさいんだよな。
えーっとPerlでBase64はどうするんだったっけな・・CPANのなんかだっけ・・
より、OreBase64 b64(buf); b4.Decode();とか、えーっとRubyでソケットは
Socket.new(・・第一引数はSocket::AF_INETだっけ・・・あれ？selectとか
使えたんるんだっけRubyは？、えーっとよりOreSocket s; s.Connect("google");
とかになっちまうんだよな。
さらにプロトならGUIつけることも多いから困るんだよな。PerlでGUIか・・
VBの方がいいかな・・っつーとやっぱ、よいしょOreWindow w; w.Show();
ってやるんだよなあ。

昔、ノウハウとかライブラリが貧弱だったころはスクリプトよく使ってたん
だけど、最近はプロト作る用途でもほとんど必要なくなっちまったよ。
まあ俺みたいな10年選手のおっさんにはこういうやつ結構いるんだがさ。

701 ：デフォルトの名無しさん：2008/02/05(火) 05:21:58

「プロトタイプベースの言語」という言葉を理解しているレスが
一つしかない。気がする。

702 ：デフォルトの名無しさん：2008/02/05(火) 05:32:16

と693が言ってるぞ

703 ：デフォルトの名無しさん：2008/02/05(火) 06:33:13

ざっくりプロト作るぜ、のプロトじゃねーよ。
おっさんだから仕方ないとは思うけど。

察するにJavascriptの話だろ、693は。

704 ：デフォルトの名無しさん：2008/02/05(火) 06:45:31

よく読めよ・・696はざっくりプロトの方なわけだが

705 ：デフォルトの名無しさん：2008/02/05(火) 06:52:42

おっさんごめん

706 ：デフォルトの名無しさん：2008/02/05(火) 07:01:58

だてに禿げてねーんだぞ

707 ：デフォルトの名無しさん：2008/02/05(火) 09:39:31

>>696のプロトの話は>>693のプロトの話と関係ないよね。

>>700のおっさんの言ってることは分かるなあ。
昔はよくC++と俺ライブラリで何でもやってた。
最近はC#と.NETで事足りてるから俺ライブラリ使わないけど、
.NET禁止環境に配布するときだけは引っ張りだすこともある。

708 ：デフォルトの名無しさん：2008/02/09(土) 19:55:14

そういう高機能な俺ライブラリにかわるようなもので
一般的な奴ってあるの？

709 ：デフォルトの名無しさん：2008/02/09(土) 20:44:19

ATL/WTL
MFC

710 ：デフォルトの名無しさん：2008/02/09(土) 20:51:37

gladeはどう?
mm版もあるようだが、わざわざmm版使うくらいならqtでいいような気もするけどw

711 ：デフォルトの名無しさん：2008/02/09(土) 21:45:51

そういやトロールテックどっかに買収されたな。

712 ：デフォルトの名無しさん：2008/02/09(土) 22:22:13

qtっていくらすんの？

713 ：デフォルトの名無しさん：2008/02/10(日) 09:30:18

[KDE/Qt]Qtについての疑問を教えあうスレ 3
http://pc11.2ch.net/test/read.cgi/tech/1194158506/

714 ：デフォルトの名無しさん：2008/02/13(水) 01:03:27

>676
>>正直言って、weak_ptrだけで十分
shared_ptr使わないでweak_ptrだけ使うって・・・
boostのそれを指しているのならば意味が分からん。

誰か解説ヨロ。

715 ：デフォルトの名無しさん：2008/02/13(水) 02:22:39

shared_ptrなんてバグの温床だから使うなよ。

shared_ptrは悪くないだ、俺が悪いんだ、、、

716 ：デフォルトの名無しさん：2008/02/13(水) 11:04:51

>>714
weak_ptrに汎用的な機能を持たせるって意味だろ

717 ：デフォルトの名無しさん：2008/02/13(水) 11:29:39

代入しようとすると deep copy してくれる scoped_ptr ってないの？
自分で作ったの使ってるけど，標準的なのがあれば
そっち使おうと思って．

718 ：デフォルトの名無しさん：2008/02/13(水) 11:38:59

optionalでどうよ

719 ：デフォルトの名無しさん：2008/02/13(水) 11:44:34

>>1
良くネーよ、複雑になりすぎてまともに使える人間が居ない
挙句、オブジェクト指向がわかって無いからできないとか抜かすアホまで現れ始める始末だし。
そんな使い方したらC++はJava以下じゃねーかとか思いながら、そんなタコが現れるのも無理も無いと思うので
C#なりJavaなりにとっとと移行すべきだと思うのである。

>>717
どうやって作ったの？
代入演算子がアレなC++では無理があると思って諦めていた、ちょっと教えてくれ

720 ：デフォルトの名無しさん：2008/02/13(水) 11:53:10

>>676
組み合わせて使う事を前提にした weak_ptr のみで一体何をしようというのだ、使い道つーか使い方ワカンネーよ
設定すら出来ないポインタに存在価値はあるのかwww

721 ：デフォルトの名無しさん：2008/02/13(水) 15:20:28

だから全部weak_ptrにして汎用的にするんだろ

722 ：デフォルトの名無しさん：2008/02/13(水) 15:40:27

>>721
悪い事は言わないからもっともっと使いこなしてみろ、使い方次第ではガベコレ方式より遥かに強力な shared_ptr/weak_ptr だ
その能力は、単なる生存管理にとどまらないという事を知るべきだ。
お前みたいなタコが増えてくるから、もうJavaでいいよなんて事になるんだよ。

723 ：デフォルトの名無しさん：2008/02/13(水) 17:38:31

RAD使わなきゃdelphiが一番難しいんだろ？

724 ：デフォルトの名無しさん：2008/02/13(水) 18:02:22

DelphiからRADを取っちゃったら何も残らないじゃないか

725 ：デフォルトの名無しさん：2008/02/13(水) 18:03:29

pascalコンパイラとしては使えるだろう。

726 ：デフォルトの名無しさん：2008/02/14(木) 00:02:19

>721
>>だから全部weak_ptrにして汎用的にするんだろ
意味がわからん。
weak_ptrはshared_ptrと対になって、尚且つ使い分ける事に
意味があるのに。もっと馬鹿にも分かるように説明してくれ。

727 ：デフォルトの名無しさん：2008/02/14(木) 00:13:42

>>726
基本的にインスタンスは全部自動変数で、参照はweak_ptrで渡せば、
スコープで寿命が来ても参照が残らない。

728 ：デフォルトの名無しさん：2008/02/14(木) 00:14:59

>>721じゃないけど、shared_ptrも何もかも、ポインタが全て
weak_ptrに統一されて、Javaが実装している参照のような
弱い参照を用いた実装になるってことじゃないかな

729 ：デフォルトの名無しさん：2008/02/14(木) 00:28:31

Javaの参照だって4種類もあるよ。

730 ：デフォルトの名無しさん：2008/02/14(木) 00:29:51

>>717
特定のクラスのサブクラスしか格納できないboost::anyみたいなもの？
需要あると思うけど、ネーミングをするのが一番難しいと思う。
名前さえ決まれば、boostに追加されそうな気がしないでもない。

>>719
代入演算子じゃなくて、テンプレートコンストラクタでどうにか汁。

731 ：デフォルトの名無しさん：2008/02/14(木) 00:50:41

>727
「汎用的にする」の一例という解釈でOK？
「全部weak_ptrにして」のほうも解説よろ。
特に「全部」が何をさしているのか。

>728
Javaの弱参照は通常参照と区別して使用することに意義があるんじゃないの？
それが正しければshared_ptrと使い分けできない（統一された）weak_ptrに存在意義は
ないとおもわれ。

732 ：デフォルトの名無しさん：2008/02/14(木) 00:58:48

なんか電波がピピっときて理解できた気がする。
C++の生ポインタが全部weak_ptrになっちゃって、あるweak_ptrをdeleteしたり、
参照してた自動変数がスコープアウトで消え去ったりした場合、
同じオブジェクトを参照してるweak_ptrがみんな０になるとちょい便利かも
みたいなはなしじゃないのかひょっとすると。

733 ：デフォルトの名無しさん：2008/02/14(木) 01:01:53

>>732
正解
電波のスキルがうｐしたねｗ

734 ：デフォルトの名無しさん：2008/02/14(木) 01:27:42

>>732
どんだけランタイム情報が充実してんだよｗｗｗ

735 ：デフォルトの名無しさん：2008/02/14(木) 01:46:35

自動変数がスコープアウトで消え去ったのを weak_ptr で捕捉するのは
そのままでは無理では？捕捉される側のオブジェクトのデストラクタなりで
何らかの notification を行わないと

736 ：デフォルトの名無しさん：2008/02/14(木) 02:16:14

>>735
そうだね。
被参照オブジェクトの側でweak_ptrのリストを持っていて、
デストラクタでweak_ptrに通知するしかないね。

737 ：デフォルトの名無しさん：2008/02/14(木) 02:34:00

だったら言語仕様かえて、型なんてなくしちゃえよ

738 ：デフォルトの名無しさん：2008/02/14(木) 02:40:18

>>737
ぶっちゃけ俺言語にでも走った方が楽しいかなと思うときもある。
でもそういうのは仕事で使えないからなー。

739 ：デフォルトの名無しさん：2008/02/14(木) 09:43:48

weak_ptrとかshare_ptrとか見ると
namespace pointer
{
　class werk;
　class share;
}
の様にアンダースコアで区切られ微妙な名前になるより、
長くても名前空間で区切られる方が有り難いと思うのは、俺だけ？

740 ：デフォルトの名無しさん：2008/02/14(木) 09:56:46

>>739
uint8_tとかwchar_tとかと同じ類

741 ：デフォルトの名無しさん：2008/02/14(木) 10:05:56

>>740
クラスと単純な型では違う気ガス。
基本的な型は、どこのスコープからでも見えた方がよいからね。

742 ：デフォルトの名無しさん：2008/02/14(木) 11:08:35

>>741
作った人は、そういう基本的な型と同じカテゴリーだと考えていたのだろう。
好みの問題だから、どちらが正しいという論争に答えはないよ。

743 ：デフォルトの名無しさん：2008/02/14(木) 11:34:24

全部 shared_ptr で循環参照に対して対策を施すというのならまだ話がわかるが、全部weak_ptrって、、訳わからんな。
脳みそばらして中身覗かせてくれよ

744 ：デフォルトの名無しさん：2008/02/14(木) 13:00:09

どっちも同じに見えるのは気のせいか
違いを解説してくれ

745 ：デフォルトの名無しさん：2008/02/14(木) 14:15:23

>>744
理解しているとはとても信じられないが、仮に理解しているとして、だ
まず、weakとsharedの意味を辞書で引いてどちらがふさわしいか考えてみろと

746 ：デフォルトの名無しさん：2008/02/14(木) 14:39:19

>>745
ただのポインタ(char*など)　＋　weak_ptrで循環参照が解決すると思ってたんだ
俺が間違ってたのか？

747 ：デフォルトの名無しさん：2008/02/14(木) 14:46:54

>>746
少なくともboostのweak_ptrは、boost::shared_ptrに格納されているものにしか機能しない。

748 ：デフォルトの名無しさん：2008/02/14(木) 16:34:45

コピーは自由にできるが一つでも消えたら全部道連れということかね。
それって便利か？

749 ：デフォルトの名無しさん：2008/02/14(木) 16:50:47

auto_ptr以下だなw

750 ：デフォルトの名無しさん：2008/02/14(木) 19:43:10

単にdeleteしたりスコープから外れたりして、
使えなくなったオブジェクトを扱おうとすることを弾けるというだけだな。
デバッグ時には無条件に便利かも。

751 ：デフォルトの名無しさん：2008/02/14(木) 20:17:51

コンテナにauto_ptrすら入れられない
ライブラリが標準名乗ってるのがそもそもの間違い。

752 ：デフォルトの名無しさん：2008/02/14(木) 20:25:57

確かに、なんでshared_ptrが最初から入らなかったのか不思議。

753 ：デフォルトの名無しさん：2008/02/14(木) 20:46:22

>>752
templateに対する理解が進んだのはSTLがでてからそこそこ経った後だから仕方なかろう。
ATLの時代ですら、不十分な理解のまま巨大ライブラリを作って、あの有様だし。

754 ：デフォルトの名無しさん：2008/02/14(木) 20:52:38

コンパイラ製作者であるハゲの人の意図すら超える内容があった template は今後も重要な概念になると思いますよ。
破滅的になってきたC++が維持できるかどうかは別として

755 ：デフォルトの名無しさん：2008/02/14(木) 21:19:51

>>753
そう言われると、あの時代にSTLが作られたということが奇跡的に思えてくる。
アロケータとかアレなところはあるけど。

756 ：デフォルトの名無しさん：2008/02/14(木) 21:44:58

書籍で読んだ限りではSTLは作られたんじゃなくて別の言語から移植された物なんだよ、どこかに歴史がかかれていないかな？
元々はオブジェクト指向ベースのクラスライブラリになる予定だった。
さらにSTLで納得できない人たちが集まって作ったのが boost
templateの驚愕の事実はLokiライブラリの作成と、そこでのメーリングリストのやり取りより始まる。
それにしても不思議、不思議だな、僅かな規則を決めたら、そこから知らない事実が次々とでてくるというのは。
言語やライブラリというものは、人間の作ったものだけけど、
このテンプレートと来たら、まるで元々そこにあって、自分たちはそれを掘り出しているような気分になる。
彫刻家が仏像を彫るときに、仏像は木の中にいる、自分はそれを掘り出しているだけだという
なんとなくその気持ちがわかる。

757 ：デフォルトの名無しさん：2008/02/14(木) 22:17:06

>>756
STLはAdaから移植された物らしいね。
それはあまりに巨大な物だったのでC++の言語仕様に取り入れる
時にバッサリコンパクト化した。

758 ：デフォルトの名無しさん：2008/02/15(金) 17:05:26

wikipedia見たけど、メタプログラミングやりたかった奴が実現できる環境がAdaしかなかったのでそっちで初めたけどC++に鞍替えしたという感じじゃん。
どっちも同一人物が作ってるし。

759 ：デフォルトの名無しさん：2008/02/15(金) 19:55:30

Cという言語があったその昔、std::vectorみたいに育つ配列作ったら、上司に思いっきり笑われたのを今でも思い出す。

760 ：デフォルトの名無しさん：2008/02/15(金) 20:18:56

ttp://up2.viploader.net/upphp/src/vlphp139808.jpg

761 ：デフォルトの名無しさん：2008/02/15(金) 23:38:48

Cにvectorはいらない。

762 ：デフォルトの名無しさん：2008/02/16(土) 03:12:49

仕事で人のCのコードを見ると必ず自前のvectorが使われている。
一度メモリリークしているものも見たことがある。
指摘したら客からクレームはないとスルーされた。

763 ：デフォルトの名無しさん：2008/02/22(金) 16:28:21

そこで始まる前から終わってしまったC99の出番ですよ

764 ：デフォルトの名無しさん：2008/02/22(金) 17:36:32

C99によりC++とCの互換性が無くなってしまった。
そりゃ終わるだろ。

765 ：デフォルトの名無しさん：2008/02/24(日) 22:54:18

レベル１：　育つ配列として使える構造体（vector）を作る
レベル２：　vectorをポインタで受け渡しする
レベル３：　vectorに関数ポインタを持たせる
レベル４：　確保したメモリ領域を管理し、使用量をデバッグできるようにする
レベル５：　安全に、全ての確保メモリを解放できる
レベル６：　様々なアルゴリズムに特化したvectorを作る
レベル７：　あれ？もしかしてコレC++使えばよくね？と思い始める

766 ：デフォルトの名無しさん：2008/02/25(月) 01:10:33

>>764
C++0xでまた互換性がある程度は復活するんじゃね？

767 ：デフォルトの名無しさん：2008/02/25(月) 02:07:16

最初からC勉強しても結構無駄骨折るよな？

768 ：デフォルトの名無しさん：2008/02/25(月) 08:23:49

ツェーペーペー

769 ：デフォルトの名無しさん：2008/02/26(火) 10:22:11

自分は今仕事ではC#とかJavaです。C++はお勉強は少しだけしたことがありますが、
自力でアプリ組むのはできないと思います。

自分のようなC++素人から感じるのは、

-----------------
・危険度が高い

ハードに近い部分にアクセス可能なので、とんでもない惨事をもたらすコードが書けてしまう。

・規則に例外が多い

こうも書ける、ああも書ける。そしてこう書くと実はこういう動きをする。～には実はこんな意味がある
とか規則がスッキリしていない。

シンプルな基本ルールから演繹してソースコードを書くというよりも、上記のような事例を沢山記憶して
いないとアプリが作れない。
-----------------

ってことなんですが、実際どうなんでしょうか。C#やJavaは上の2つについては不十分かも知れませんが
前進していると思います。一定のパフォーマンスや自由度が犠牲にしてますが。

770 ：デフォルトの名無しさん：2008/02/26(火) 12:31:53

>>769
規則に例外が多いとは感じたことないな。vector<bool>くらいか
実装に依存する差異はJavaやC#に比べて多いとおもう

771 ：デフォルトの名無しさん：2008/02/26(火) 12:43:35

危険度もまともなOSで動かす分には変わらない。
変なことをしようとするとOSに止められる。
それはC#やJavaだとVMが担っている役割だな。

もちろんやろうと思えば危ないこともできるけど、
それはプログラマが意図的にそういうプログラムを書かないとやれるわけがない。
ウィルスとかワームとかがそう。

規則に例外が多いってのは、どの言語でもそうだと思う。
JavaやC#だとEqualsと==演算子とか最初何あれって思ったよ。
慣れればなんてことないんだけど。

772 ：769：2008/02/26(火) 13:28:42

なるほど、C++知らない人間が想像で怖がってるだけなのかも知れませんね。

どうも自分は、統一感があるのがC#やJavaで、C++ってのは今までの経緯というか
文脈というか、言語の細かい「事情｣に通じてないと使えないという印象を持ってました。

あとメモリ管理を意識するというのも大変そうだなぁと。ソースコードが何をやって
いるのか、ではなくて、マシンのメモリ上のどの部分をいじってるのか、ということを
意識するというのは、実際に工数が膨らんでしまう＆大きな不具合が生じる可能性が
高まるんじゃないか、と思うのです。

773 ：デフォルトの名無しさん：2008/02/26(火) 13:41:53

メモリ管理を意識ってのはほとんど寿命の問題。
普通にやってるぶんにはマシン上のメモリ配置など意識する必要はない。
触りもせず杞憂もほどほどにしとけ。

774 ：デフォルトの名無しさん：2008/02/26(火) 13:56:29

スマートポインタ使っとけ

775 ：デフォルトの名無しさん：2008/02/26(火) 13:56:40

C++使いの私からすれば、一々newしないといけないJavaの方が面倒だと思う。
データ構造はSTLのコンテナを使えば済むし、オブジェクトは普通にローカル変数で済むからね。

776 ：デフォルトの名無しさん：2008/02/26(火) 14:22:13

>>775
Javaでもローカル変数ぐらいはあるが、
C#でいうところの値型（struct）がないのが面倒ってこと？

777 ：デフォルトの名無しさん：2008/02/26(火) 15:10:36

GCのほうか余計に気を使う。

778 ：デフォルトの名無しさん：2008/02/26(火) 15:24:06

自分も>>769と同意見で、C++は注意することが多すぎると思う。
メモリ管理、スライシング、仮想関数テーブル、多重継承、Cスタイルとの混同、ヘッダの衝突etc...
STLも、さらにBoostも覚えて使えとか、うちではMFC使ってますとか、
組み合わせて使うときにはまた注意事項が増えて・・・。
Javaや.NETではほとんど意識しないことばかりだから、ストレスが溜まるよ。

779 ：デフォルトの名無しさん：2008/02/26(火) 15:49:07

そうかのう。
必要に応じて取捨選択すればいいだけ。
むしろ、俺はJAVAでGUIどうやって書けば良いのかわかんね。
EclipseにGUIエディタとか入れてるはずなのに出てこねーし。
まあ、作れてもJudeみたいに糞遅いプログラムじゃ悲しいけどね。

780 ：769：2008/02/26(火) 16:28:57

自分の基本的なプログラムに対する考えは、「富豪プログラミング」的なものです。

つまり、分かりやすい、間違えにくいというのが最優先であって、実行効率やそのための
裏技的な知識は2次的なもの、という考えですね。

富豪的でも「難解」なコードはあり得るでしょう。アルゴリズムのようなものです。しかし、
C++が難解なのはそういう意味ではなくて、>>778に書いていただいたような、文脈を
色々知らないとコードが書けないってことなのです。

>>779
ちょっとお聞きしたいのですが、C++っていうと、WinのGUIアプリっていうつながりが
やはり定番なんでしょうか？逆にそれ以外の用途って、どんなものがありますでしょうか。

781 ：デフォルトの名無しさん：2008/02/26(火) 16:34:23

C++の言語の仕様が詰め込み杉ってのを否定する奴はまずいないだろうね

782 ：デフォルトの名無しさん：2008/02/26(火) 16:56:47

>>780
普通にシミュレーション系のプログラムを書く分にはGUIなんて要らないし、
C++でも>780の言うところの富豪プログラミングができると思うけどねぇ。

783 ：デフォルトの名無しさん：2008/02/26(火) 16:57:02

ライブラリの仕様が延々書いてあるから多く見えるだけのような…
個人的にはいらない機能もあるけどね

784 ：デフォルトの名無しさん：2008/02/26(火) 17:09:30

Windowsに関していえば、
GUIなどは.NET、速度を要求するところだけC++のハイブリッドが望ましい。
部分的にアセンブラを使うような感覚で。

785 ：デフォルトの名無しさん：2008/02/26(火) 17:43:03

文化なのか何なのか知らんが、Windows プログラマが C++ を使うような場面で
Unix や Linux のプログラマは C (含 gcc 拡張) を使うケースが多いよね。

>>780のように言語自体が難しいのはアレだろという意見は昔からあるわけで、
C が使える環境でも Fortran だの COBOL だのを好んで使う人も昔からいた。
perl で短く書けるものを sh や awk で長く書く人とかも同類か。

786 ：デフォルトの名無しさん：2008/02/26(火) 17:56:51

>>785
短く書けるからと言って、awkで読み易く書けるものをperlでわざわざ読み難く書くこともなかろう。

787 ：デフォルトの名無しさん：2008/02/26(火) 18:00:37

awkは知ってるが、perlは知らん。
awkで不足するようならC++に飛んじゃう。

788 ：779：2008/02/26(火) 18:02:21

>>780
いんや、GUIなんて殆ど作りません。
JAVAやC#は覚えることが少いとか言う人がいるんで、
C++でやってきた人間にはJAVAも覚えることだらけだよと言いたかっただけです。

789 ：デフォルトの名無しさん：2008/02/26(火) 19:00:35

Cで多態とかやろうとするよりはC++でやったほうがシンプルに書けるとかもあるんで
Cだから簡単だとは一概には言えないよ
それと、全部やるなら覚えることが多いのは確かだけど
使わないでいいならクラスもテンプレートも覚える必要ないし

790 ：デフォルトの名無しさん：2008/02/26(火) 19:18:23

慣れた言語が一番使いやすいから、ある用途で優れてる言語と分かっていても、
自分にとっては慣れてないせいで結構細かい言語仕様、ライブラリを調べないと
何も書けないというのもある。

791 ：デフォルトの名無しさん：2008/02/26(火) 20:32:05

C++が目指した道も「分かりやすい、間違えにくい」ということだったはずなんだけど、
結果は、そこに至るまでの道がかなり長い方になってしまった、と自分は思っている。

792 ：デフォルトの名無しさん：2008/02/26(火) 20:32:49

C++だってわざと難しくなるようにできているわけじゃなし、少なくともプログラム言語ひとつ捕まえて、複雑だの何だの言って怖がってるうちは一山いくらのアルバイト程度のプログラマであることを自覚した方がいい。

793 ：デフォルトの名無しさん：2008/02/26(火) 20:48:04

Java の人には、きっとプログラマじゃない人（実装することの専門家を目指してない人）も結構いるんじゃない？

794 ：デフォルトの名無しさん：2008/02/26(火) 20:55:28

C++は全用途向け言語ってことを忘れてる奴が多すぎる
安全性を理由にプログラマが実行可能なことを減らしてはならない
邪悪なハッキングだって時には必要な事だから禁止されてはいないのだ

795 ：デフォルトの名無しさん：2008/02/26(火) 21:08:19

JavaやC#よりも面倒なのは俺も思う。
それに、IDEの補完機能の賢さやコンパイルの速さでは本当にC#やJavaが羨ましい。

796 ：デフォルトの名無しさん：2008/02/26(火) 21:32:11

C++は標準の例外がクソ過ぎる。

と俺は思っています。

797 ：デフォルトの名無しさん：2008/02/26(火) 21:39:45

標準ライブラリ全般がくそで貧弱です。
TR1では到底足りません。Boost全部入れたって足りるようなものではありません。

798 ：769：2008/02/26(火) 22:20:42

>>788
そうですか。現状のC++の用途というとWinGUIアプリが中心なのかな、と思ってました。

あと、C++ができる人にとって、JavaやC#は楽勝であるというのは事実でしょ？自由度が
Java/C#よりも大きいのですから。

>>792
問題は、C++が知識量を必要とするということなんですね。ちょっと極端な例かも知れませんが、
Schemeのように実に単純な文法から森羅万象を生成するというのではなく、覚えておくべき
知識を要求してくるのがC++じゃあないかと。

JavaやC#はその辺Scheme程ではないですが、シンプルです。変数の扱い、スコープ、基本的な
構文、クラス関連の表記方法と意味が分かればよい。あとは、いかに無駄無く綺麗に書けるかに
なってくるわけで、これは知識とはちょっと違います。

799 ：デフォルトの名無しさん：2008/02/26(火) 22:40:01

>>798
というか君は、CもC++もロクに使ったことが無いんだろう。
ちょっと触れたぐらいで多くを語るなｗ

800 ：デフォルトの名無しさん：2008/02/26(火) 22:40:02

Schemeとまではいかないまでも、LLから勉強してある程度
プログラミング覚えてからCやC++やったほうがいいと思うんだけど…

801 ：デフォルトの名無しさん：2008/02/26(火) 23:35:06

C++→C#と入ったが、楽勝ではなかったぞ。
あの大量のライブラリ、初めは適切なキーワードもわからずググれない。
それ以外の言語を始めるのと大してハードルは変わらなかったと思う。

一通り使えるようになった今だから言えることだけど。

楽勝だなんてC#にもC++にも失礼だ。

802 ：デフォルトの名無しさん：2008/02/26(火) 23:57:17

ライブラリの学習コストはどの言語でも大変。
.netはそれを統一してくれた。

803 ：デフォルトの名無しさん：2008/02/27(水) 00:00:05

一人でプログラム作るんならC++を使うけど、
数人でプログラム作るんならCやJavaを使う。

804 ：デフォルトの名無しさん：2008/02/27(水) 01:35:56

>>798
Java は Java で標準添付のクラスの量に初心者はびっくりするよ。
どれをどう組み合わせて使えば良いのか判らない。
そういう意味では情報量は必要だよ。

805 ：デフォルトの名無しさん：2008/02/27(水) 05:26:41

>>797
そうか、きみの使っている言語は準標準レベルで
マルチスレッドと構文解析機とシリアライズと非同期通信とグラフ理論と行列計算
をサポートしているというのか。それはすごい。

806 ：デフォルトの名無しさん：2008/02/27(水) 06:07:35

キレのある皮肉のつもりなんだろうな～、きっと。

807 ：デフォルトの名無しさん：2008/02/27(水) 07:29:41

つーか、matlabがかなり近い?

808 ：デフォルトの名無しさん：2008/02/27(水) 09:27:46

一度C#をやろうとしたとき、ヘルプを見ても欲しい情報がなかなか見つからなかったのがつらかったな
C++は十年以上かけて覚えたけど、どんどん仕様が変わっていったのがつらかった

809 ：769：2008/02/27(水) 10:38:58

>>799
> ちょっと触れたぐらいで多くを語るなｗ

あはは。いや、お勉強ならしたことあるんですがが、C++の実際の実装ではそんなのあまり
役に立たないと感じたわけです。結局、低レベルの、OSだったりメモリ管理だったり
の知識が必要となるんじゃないですか。

>>802 >>804 >>808

ライブラリの学習って言いますが、あれは覚えるものではなくて辞書の引き方を知るだけで
よいのです。大きな本屋へ行って、目当ての本を探す際に書店の分類を参考にしてその書棚へ
向かうのと同じですよ。検索エンジン使うのとも似てます。

810 ：デフォルトの名無しさん：2008/02/27(水) 10:49:24

>>809
> 結局、低レベルの、OSだったりメモリ管理だったり
> の知識が必要となるんじゃないですか。

なる場面もあるしならない場面もある。
デバドラ書くならOSの知識は必要だけど単純なファイル操作だけとかならほとんどいらない。
スクラッチでメモリ管理を書く必要があるなら知識は必要だけど、
アプリで使う程度のメモリ管理ならコンテナとスマートポインタで簡単にできる。
C++は両方の局面で使えるってことだね。

811 ：デフォルトの名無しさん：2008/02/27(水) 10:52:11

>>809
＞結局、低レベルの、OSだったりメモリ管理だったり
Win32APIとかそのへんの話か？
そこらへんだったら言語の問題とはベクトルが違うぞ。
言語と環境を一緒くたにするな。

812 ：デフォルトの名無しさん：2008/02/27(水) 11:11:32

でもC++のコンテナとかでトラブルが起きると
デバッガでマシン語眺めないと原因がわからないことが多いような。
.NETとかだと～Exceptionの意味を調べれば終わりだけど。

813 ：デフォルトの名無しさん：2008/02/27(水) 11:36:38

なんでやねん

814 ：デフォルトの名無しさん：2008/02/27(水) 14:29:23

>>809
その辺りは考え方の違いで、
・C/C++ はメジャーなので多くのプラットフォームがネイティブでC/C++から呼べるAPIを
　用意している。のでC/C++で何か書く場合には、それを使えるし使うことが多い。
・Java は OS 側からのサポートが超貧弱。代わりにライブラリを用意。
　それで出来ないことについてはJNI 等に頼らざるを得ない。
という見方もできる。

いずれにせよ、ライブラリの問題なら言語仕様とは関係ないし、ライブラリを除外して考えるなら、
Java で簡単にできることはそのほとんどが C++ でも同様に簡単（かつ難解でなく）できると思う。

815 ：デフォルトの名無しさん：2008/02/27(水) 16:59:59

>>809
趣味なら構わんが仕事なら役立たずPGの烙印押されるよ。
よくC++10年使ってましたというPGがMFCやATLが理解できなくて
テスターにしか使えないとかよくある。あるいは、
1時間でできるコーディングを調べながらやって1週間かけるPGとかいる。
コーディングスピードはできる人とできない人で100倍以上の差があるなんてのはよくある。

816 ：デフォルトの名無しさん：2008/02/27(水) 17:50:36

tteいうか、JavaでもC#でもちょちょっと調べてさらっと書ける人なら
Symbian だろうが Win32 だろうが C++ でコード書くくらい楽勝だよなぁ・・・
DI等のマイナーなくせにお約束だらけの世界も少ないし。

生産性において MATLAB と比べられたらさすがに分が悪いけど。

817 ：デフォルトの名無しさん：2008/02/27(水) 18:47:52

std::vector<std::auto_ptr<hoge>> kusolib;

818 ：デフォルトの名無しさん：2008/02/27(水) 18:51:22

>>814
JavaにOS側のサポートが多かったら、Javaの理念に合わないんじゃないのか?

>>815
C++を10年使っている事と、MFCやATLが判らない事は何の関係も無いと思うんだ

819 ：デフォルトの名無しさん：2008/02/27(水) 20:08:55

815の言う「MFCやATLが理解できない」というのは、
いま現在知っているかどうかだけでなく、「今は知らないが必要ならすぐ使えるようになるレベル」
も含めた、広い枠組みでの有能・無能の話だと思うよ。

820 ：デフォルトの名無しさん：2008/02/27(水) 21:23:03

ATLはCOMが手軽に扱えて便利だったがMFCの存在価値はまったく理解できない

821 ：デフォルトの名無しさん：2008/02/27(水) 21:47:37

ただ、MFCを作ったプログラムという資産は山ほどあるわけで。

822 ：デフォルトの名無しさん：2008/02/27(水) 23:01:11

MFCよりWTLがいい

823 ：デフォルトの名無しさん：2008/02/27(水) 23:29:13

オブジェクト指向言語でライブラリを理解するということは
フレームワークのお作法を理解するということで、理解するにはやはり時間がかかる。
特にMFCみたいにマクロだらけのものは。まぁ便利だけど。

824 ：デフォルトの名無しさん：2008/02/28(木) 01:17:53

>>816
Javaは基本的に公式ドキュメントあれば事足りるから
調べ物にはあんまり困らないよ。
突っ込んだ仕様は調べる必要あるけど。

C++は何故か必要な情報になかなかたどり着けねえ…。

825 ：デフォルトの名無しさん：2008/02/28(木) 09:28:24

Javaは学習しやすいけどランタイムの信頼性が低いのがネック

826 ：デフォルトの名無しさん：2008/02/28(木) 10:51:34

>>824
どういう情報にたどりつけないのだ？
C++の仕様として読み込まれていることならC++の仕様を見るだけでわかるだろ。
MFCだったらC++の仕様じゃないんだから、MFCの仕様を探せば良いわけでな。
本来、OSや環境サイドで決めるものの仕様まで言語仕様に読みこんでるものはすかん。

827 ：デフォルトの名無しさん：2008/02/28(木) 12:48:39

>>824
>Javaは基本的に公式ドキュメントあれば事足りるから

いくらなんでもこれはないだろう。
トイ・プログラム程度しか書いたことないんじゃ・・・

828 ：デフォルトの名無しさん：2008/02/28(木) 16:09:00

基本的だから別にいいんじゃね？仕事的にはアウトだけど。
どんな言語やライブラリ、処理系だってバグがないものなんてないから、嵌るときは嵌る。

829 ：デフォルトの名無しさん：2008/02/28(木) 20:26:10

僕は神になる為に駅前ギャンブル場に行った
そしてトイレにこもり続け、店員に注意された----

僕「店長を呼んでくれないか」
賭博主が何事かと、のこのこやってきた

僕はロープ、ベルトをもっている

僕「お前のせいで借金地獄だ　自殺しようと思う
暴力団に殺されるより楽にしにたい」
賭博主「え!?　そんなことしたら、営業妨害で訴えますよ？」
僕「それがどうした　これから死のうってのに
警察呼ぶか？　出てきたら店の真ん中で死ぬ」
賭博主「それは困るッ・・・どうすれば？」
僕「借金は１０００・・・万近く・・・あるのだが」

死神「こんな場所が日本に１万以上あるのか　うめ～」

これを繰り返し、僕は神となった！（大富豪になった）

830 ：デフォルトの名無しさん：2008/02/29(金) 00:56:09

C++って好きなんだけど洗練されてないと思うぜ。
かといってJavaはやりすぎだしC#はイっちゃってる。
結局戻る所はC++だわ。

でも洗練されてるC++って見てみたいなぁ。
言語仕様見て感動したい。

831 ：デフォルトの名無しさん：2008/02/29(金) 01:01:06

洗練か…そこんとこDはどうなの？
弄ったことないからD使いの人宣伝してくれ

832 ：デフォルトの名無しさん：2008/03/01(土) 12:32:09

VerilogでASICとか作ってたんですが、今回はSystemCをやると言い出す人がいて
先週からUMLとC++のコード書いてます。
UMLは好きになりましたが、まだあまりC++が好きになれません。
昨日は演算子のオーバーロードを考えた人を絞め殺したくなりました。
こんな俺をC++大好きっ子にするコメントお願いします。

833 ：デフォルトの名無しさん：2008/03/01(土) 12:59:23

>>832
C++として使うから嫌いになるんじゃね。C＋便利機能（クラスとか
STLとか）くらいで使えばきっと好きになると思う。

834 ：デフォルトの名無しさん：2008/03/01(土) 13:20:35

SystemCだからといっても、無理やりC++機能をフル活用しようと
思わずに、ベタベタにCでかいてもいいし、クラスとか必要な
とこだけC++の機能使えばいいんじゃないかなぁ。

835 ：デフォルトの名無しさん：2008/03/01(土) 14:56:28

>>832
string jangdonggun = string("あなたのことが") + string("好きだから");

836 ：デフォルトの名無しさん：2008/03/01(土) 16:22:19

>>832
> 昨日は演算子のオーバーロードを考えた人を絞め殺したくなりました。
誰か他の人が書いたトンデモ・オーバーロードに振り回されたのかな。
だとしたら、気持ちはわかるけど、それはその書いた奴が悪いｗ
まともな奴は心得た使い方をしているし、その範疇の中で語るなら、
演算子オーバーロードが無かったら逆に困るんだよね。色々と。

基本的にC++は、初心者（機能を知らない）を支えたり、身の程知らず（後先考えず機能を使いまくる）を
窘めたり、といった努力を一切放棄した言語。
「上手く扱える奴が得られる幅と力」重視で設計されていて、初心者とか、職場に身の程知らずが居るとか、
そういう人には厳しいと思う。

837 ：デフォルトの名無しさん：2008/03/01(土) 16:33:31

行列計算とかは演算子オーバーロードがないときついな。

838 ：デフォルトの名無しさん：2008/03/01(土) 16:42:58

数学側で演算子がどんどんオーバーロードされるのに、
プログラミング言語側でサポートされないと読みにくいコードになるしな。

839 ：デフォルトの名無しさん：2008/03/01(土) 23:51:36

演算子オーバーロードは何でもありだから、プログラムを書いたやつのセンスが問われるな。
そもそも、演算子オーバーロードの代表格、iostreamの演算子なんて、考えようによってはひどすぐる。
cout << a;
なんて、代入系演算子でもないのにcoutを書き換えちゃうしな。
副作用のある処理は副作用があると明示的にわかる演算子を使うべきのような。

840 ：デフォルトの名無しさん：2008/03/01(土) 23:54:28

C++標準のiostreamなんて、使おうとして一瞬で捨てたぜ！
クソスギデショ。

841 ：デフォルトの名無しさん：2008/03/02(日) 00:02:22

シェルの追記リダイレクトがヒントだったのかね。逆だけど。

842 ：デフォルトの名無しさん：2008/03/02(日) 01:17:52

>>838
数学世界では、破廉恥なオーバーロードがすでにまかり通っていますからね。

843 ：デフォルトの名無しさん：2008/03/02(日) 01:25:02

>>840
STL誕生前のライブラリだけあって、他からひどく浮いてるしな。

844 ：デフォルトの名無しさん：2008/03/02(日) 18:58:48

>>1-843
要するにC最高ってことだな？

845 ：839：2008/03/03(月) 15:04:32

代入が演算子ってのがものすごく気持ち悪くなってきた。
数学的な演算子って言うのはあくまで1つ以上の値や関数等を演算した結果を返すものだよね。
関与したオブジェクトそのものを変更したりはしないはず。
関数f(x)を積分したところで、それは積分した関数を返す演算であって、f(x)自体を変更するものではない。

Cは平気で++や=などの副作用のある演算子が出てくる。
C++に至っては、オーバーロードで+などの一見副作用のない演算子に副作用を込められる。
キショイ。
つーか、演算とはオブジェクトも値も関係無く適用されるべきものであるのに、副作用型演算子はオブジェクトにしか使えないし。
そもそも参照渡しが関数や演算子の定義を見ないと渡したオブジェクトが変更される可能性があるのかどうかわからん時点でキショイな。
こういうことを考えると関数型言語とやらに興味が出てくるのだろうか。

846 ：デフォルトの名無しさん：2008/03/03(月) 15:41:36

演算子を定義できるようにするとかどうよ
さらにホワイトスペースのオーバーロードも出来ます

847 ：デフォルトの名無しさん：2008/03/03(月) 16:15:11

申し訳ないが、>845は「参照渡し」や「演算子オーバーロード」を理解できないで挫折した香具師が、
精一杯虚勢を張っているようにしか見えない。

848 ：デフォルトの名無しさん：2008/03/03(月) 16:16:06

「包丁で人が殺せるから料理ってキショい」とか言われても同意できないよな
殺さなきゃいいんだよ

849 ：デフォルトの名無しさん：2008/03/03(月) 16:20:44

言いたいことはわからなくもないが、今更どうでもいいって感じ。
演算子オーバーロードってC++だけの機能じゃないしな。
Javaはできなかったっけ？

850 ：デフォルトの名無しさん：2008/03/03(月) 16:21:04

> 副作用型演算子はオブジェクトにしか使えない
これは、もしoperator =や[]などがクラスのメンバとしてしか
定義できないということであれば、0xから解消され、
非メンバとして定義できるようになる。

851 ：839：2008/03/03(月) 17:39:41

>>847
すまんが、並列計算数値解析プログラムをCやC++で書いてるのだが。
C/C++の最適化効率の悪さが念頭にあって、副作用のある演算子もその大部分を占めてるなと思ったわけだが。

852 ：デフォルトの名無しさん：2008/03/03(月) 17:43:03

>>851
だからね、その実績が>845で台無しになっているってことよ。
# 尤も、その実績のどこに「参照渡し」や「演算子オーバーロード」が関係しているのか判らないけれど。

853 ：デフォルトの名無しさん：2008/03/03(月) 17:43:47

それは言語の仕様じゃなくてコンパイラの性能だろ

854 ：839：2008/03/03(月) 17:54:09

>>852
まあ、ふと立ち止まって考えたときに、「演算子」というもののありかたがどうなのかと。
Cは「高級」言語じゃないからしかたないが。
>>848のように殺せる道具を殺さないように使えば良いわけだし。

855 ：839：2008/03/03(月) 17:56:34

>>853
コード以上の文脈を読みとるのはコンパイラにとって大変だろ。
同じ振舞いをするコードでも、プログラマの意図したことがわかればより最適化できるケース(エイリアス問題など)があるしね。

856 ：デフォルトの名無しさん：2008/03/03(月) 18:00:23

だからそれはコンパイラの性能だろ。仕様のせいにするなよ。

857 ：839：2008/03/03(月) 18:01:31

>>856
仕様のせいだよ。
エイリアス問題なんてまさに仕様のせい。

858 ：デフォルトの名無しさん：2008/03/03(月) 18:12:33

そう思うならC++以外の言語使えよ

859 ：デフォルトの名無しさん：2008/03/03(月) 18:18:15

要するに参照透明性でしょ。Haskell あたり使えばいいんじゃない？

860 ：デフォルトの名無しさん：2008/03/03(月) 18:22:51

__declspec(noalias)に__attribute__((const))とか
C++標準とは別に、統一を図る場があってもいいとは思う。

861 ：デフォルトの名無しさん：2008/03/03(月) 18:29:29

>>845
君は、きっと関数型言語もきしょいと思うようになるだろうから
演算子の存在しない言語を利用した方が良いと思うんだ
アセンブラでも演算子は出てくるから、ここは一つ、バイナリで直接プログラムを書く人になるんだ
まあ、CPUが変わると命令が変わるが、そんな細かいことは気にするな
きしょい演算子と永遠に縁を切れることを考えたら安い投資だ

862 ：デフォルトの名無しさん：2008/03/03(月) 18:40:57

>>858
C++の仕様に問題があると、なにか問題があるの？

863 ：デフォルトの名無しさん：2008/03/03(月) 18:45:10

>>845
それだと、
関数型言語でも代入はメチャクチャ使いまくるから結局キショいと思うと思うよ。

schemeのset-car!とかset-cdr!とか、call/ccで継続を変数に代入する所とか。

864 ：デフォルトの名無しさん：2008/03/03(月) 19:32:09

>>863
代入が悪いのではなく、代入が演算子になっているのが悪いのでは？
func(a=b)とか出来る所とか。

865 ：デフォルトの名無しさん：2008/03/03(月) 21:49:35

mov a,b って書きたいってことか。

866 ：デフォルトの名無しさん：2008/03/03(月) 21:58:11

:= がほしいとか？違うか

867 ：デフォルトの名無しさん：2008/03/03(月) 23:04:07

Hoge hoge = GetHoge();

の = のところで何が起きるかここだけ見て分からないのはかなり嫌かも。

・GetHoge() が Hoge& を返していた場合
・Hoge に変換できる全く別の型を返していた場合
・Hoge のコンストラクタが受け取る全く別の型を返していた場合
・代入演算子がオーバーロードされていた場合

こうやって見てみると
auto hoge = GetHoge();
は型変換を伴うような変な副作用が無くていいのかな。

868 ：デフォルトの名無しさん：2008/03/03(月) 23:05:37

余計なことを考えず、「= と ++ と -- は特別」って覚えておけばいいのでは。

869 ：デフォルトの名無しさん：2008/03/04(火) 00:06:12

プログラムを書くことを諦めるってのも一つの方法だぜ？

870 ：デフォルトの名無しさん：2008/03/04(火) 01:43:08

>>845
君、Haskell がオイデオイデしてるよ。

>>863
let や再帰を駆使すりゃある程度は…。

871 ：デフォルトの名無しさん：2008/03/04(火) 10:02:10

>>868
そういうレベルじゃなくて、理解した上でのそもそも論でしょ。

872 ：デフォルトの名無しさん：2008/03/04(火) 11:41:00

他人の作った言語なんだから、いつまで使っても馴染まない部分てのは
多かれ少なかれどの言語にもあるかもなぁ。
そんな時、PG的には自分で俺言語を作るべきなんじゃないのかｗ

873 ：デフォルトの名無しさん：2008/03/04(火) 12:31:37

>>871
そうすると、この話題は「物事に例外が存在するのはキショイ」というだけのもので、
ディテールにはまったく意味が無いと思う。論ですらないよ。

874 ：デフォルトの名無しさん：2008/03/04(火) 12:37:14

>>873
このスレ的にはC++は良いって意見ばっかじゃないという意見が出たらダメということか。

875 ：デフォルトの名無しさん：2008/03/04(火) 12:39:49

演算子オーバーロードの害悪の話が出てきて、
その害悪とは元来の意味とは異なるオーバーロードが可能ということと、
さらには元来副作用をもたらさない演算子に副作用を仕込めるという話になって、
そもそもCの演算子からして副作用を持つ演算子というのは数学的で言う演算子からかけはなれている、
という流れだろ。

おとなしく使えとかそういう話じゃないはずだがw

876 ：デフォルトの名無しさん：2008/03/04(火) 14:10:51

>>874
どういう電波を受信すると、そうなるんだ？
相手が「馬鹿なことを言ってる」ことにしたくてたまらない
二十歳前後の自称論客みたいな話の運び方すんなよなｗ

877 ：デフォルトの名無しさん：2008/03/04(火) 21:28:53

C++って言語仕様だけが一人歩きしちゃっててかわいい。

878 ：デフォルトの名無しさん：2008/03/04(火) 23:35:10

演算子の一般的な意味とかけ離れた定義が可能なことで、それが糞仕様にはならんと思うよ。
関数名だって自由にデタラメな名前つけれるし。
納品済みのコードでtest1()とかaaaa()とか見たことあるし。

879 ：デフォルトの名無しさん：2008/03/04(火) 23:45:33

演算子は元々言語仕様で意味が決まってるのに、オーバーロードで勝手にそこから踏み出すわけだ。
関数名は元々言語使用で勝手につけてよいと決まっているので、演算子の場合と一緒にすべきではないな。

880 ：デフォルトの名無しさん：2008/03/04(火) 23:46:47

aaaaという関数名はもともとC/C++に存在しない単語だけどoperatorはそうではないという違いはあるけどね。
文字列の連結がoperator-だったり、行列の積がoperator[]だったりしたら発狂しそうだｗ

881 ：デフォルトの名無しさん：2008/03/04(火) 23:49:13

>>880
やってみれば判るが、実は文字列の連結にoperator-()を使うのは意外に収まりがいい。
寧ろ、Basicを真似てoperator&()なんかにされたら泣ける。

882 ：デフォルトの名無しさん：2008/03/04(火) 23:51:07

>>879
漏れが設計して漏れが実装してるクラスにおける「代入」や「大小関係の比較」の実装は
漏れができるようになってないと使い物にならないじゃん・・・

Java だって equals に「引数をファイルに出力する」とかいう実装を与えられるわけだし。

883 ：デフォルトの名無しさん：2008/03/04(火) 23:52:43

表記の一般的な意味とは異なる実装するから困るって話じゃないの？
Add()関数作って実際は引き算の処理されるのと
文字列の連結がoperator-するのと問題は同じと思うが。

884 ：デフォルトの名無しさん：2008/03/04(火) 23:53:24

VBAをちょこっと触ってる自分はoperator&のほうがまだしっくりくるわ・・・

885 ：デフォルトの名無しさん：2008/03/05(水) 00:35:46

<<よりはまだ&のほうがいいような

886 ：デフォルトの名無しさん：2008/03/05(水) 00:37:39

>>885
それなんてboost::archive

887 ：デフォルトの名無しさん：2008/03/05(水) 00:48:09

MFCもそんなのあったな。

888 ：デフォルトの名無しさん：2008/03/05(水) 14:30:25

>>881
"ABCDBC" - "BC"
この結果は、
"ADBC"だと納得行くが

"ABCDBCBC"なら、「なんでやねん!!!」と思うよ

889 ：デフォルトの名無しさん：2008/03/05(水) 14:39:04

寧ろ、"ABCDBC-BC"になってくれたら何かと便利。

890 ：デフォルトの名無しさん：2008/03/05(水) 15:00:03

便利じゃないよｗ

891 ：デフォルトの名無しさん：2008/03/05(水) 21:24:42

>>888の状態で16進演算してくるなら便利。でもstringの仕事じゃないよな。

892 ：デフォルトの名無しさん：2008/03/06(木) 13:16:10

>>891
stringの仕事じゃないね
16進演算なんて普通に
int i = 0x0a - 0xf0;
で出来るんじゃね?

893 ：デフォルトの名無しさん：2008/03/06(木) 21:06:05

>>892
ファイルから文字列として読み込んだときとかの話ねｗ

894 ：デフォルトの名無しさん：2008/03/06(木) 23:01:55

そうだとして"90" - "1" が"8F"とかありえないでそ（ｗ

895 ：デフォルトの名無しさん：2008/03/07(金) 01:03:40

weirdString foo = "-" + "|";
assert(foo == "+");

896 ：デフォルトの名無しさん：2008/03/07(金) 21:29:28

kidsString foo = "1" + "1";
assert(foo == "田");

897 ：デフォルトの名無しさん：2008/03/09(日) 11:25:37

オペレータでどうにかするんじゃなくて
STL的にはイテレータでどうにかすべき問題ではないの？

898 ：デフォルトの名無しさん：2008/03/19(水) 00:51:46

Cだと
int main()
{
printf("%d", 1);
}

c++だと
int main()
{
std::cout << 1;
}

で、最近のコンパイラは使ってない関数は出力ファイルに入らないように削除してくれるらしい。
これをリンク時ガベージコレクションって言うんだっけ？

それで、上記プログラムだとCの場合にprintf全体をリンクする(doubleを文字列化する処理も含まれる)が
c++だとstd::cout::operator << (int)をリンクするだけでOKだ。

後はc++のほうを例外処理無し、RTTI無しのオプションを付けてコンパイルすればCのプログラムより小さくなると思う。

気が向いたら実験してみる。

899 ：デフォルトの名無しさん：2008/03/20(木) 23:40:57

そんなわけなかろうｗ

900 ：デフォルトの名無しさん：2008/03/20(木) 23:47:57

>>898
ostreamの実装がprintfの実装より小さくなれる気がしないんだが…
とりあえず結果報告キボン

901 ：デフォルトの名無しさん：2008/03/21(金) 06:59:09

>>900
フォーマット文字列の解析が要らないから小さくなるかもなぁ。

902 ：デフォルトの名無しさん：2008/03/21(金) 12:46:04

ヒント:淫乱

903 ：デフォルトの名無しさん：2008/03/21(金) 12:52:17

インリンじゃないの？

904 ：デフォルトの名無しさん：2008/03/21(金) 14:59:25

Cだからってprintfのパーサの実装が綺麗だと思うなよ!

905 ：デフォルトの名無しさん：2008/03/22(土) 00:02:15

>>898
の実験結果を発表します(ｼﾞｬｼﾞｬｰﾝ)

実験環境
OS:windowsVista
gcc ver3.4.4 @cygwin

cs.cとcs.cppの内容は>>898に#includeを追加したのと同じ内容です。

gcc cs.c
a.exeの大きさは8873byte
gcc -Os cs.c
8683
gcc -O cs.c
8873
gcc -O3 cs.c
8873

g++ cs.cpp
477682
g++ -Os cs.cpp
477014
g++ -O cs.cpp
477577
g++ -O3 cs.cpp
477014

906 ：デフォルトの名無しさん：2008/03/22(土) 00:06:22

>>905
勝負になっていないように見えるが？

907 ：デフォルトの名無しさん：2008/03/22(土) 00:25:25

visual studio2005 sp1のcl.exe

cl cs.c
53,248
cl /Os cs.c
53,248
cl /Ot cs.c
53,248
cl /Ox cs.c
53,248
cl /Ox /Oi /Ob1 /GL /Oy cs.c
53,248

cl cs.cpp
135,168
cl /Os cs.cpp
131,072
cl /Ot cs.cpp
135,168
cl /Ox cs.cpp
131,072
cl /Ox /Oi /Ob1 /GL /Oy cs.cpp
131,072

908 ：デフォルトの名無しさん：2008/03/22(土) 00:31:26

今回の実験ではc言語で書いたプログラムのほうが小さくなった。
でも十分大きなプログラムではこの差はほぼ無視できるレベルになるのではないだろうか。
気が向いたら実験してみる。

909 ：デフォルトの名無しさん：2008/03/22(土) 00:41:22

VCなら/MDを付ければいいんだよ。

910 ：デフォルトの名無しさん：2008/03/22(土) 00:51:21

vc9 /Os /MD
cs.c: 7,168
cs.cpp: 7,680

vc9 /Os /MT
cs.c: 53,248
cs.cpp: 129,024

gcc(4.1.2) -Os
cs.c: 8,330
cs.cpp: 8,827

gcc(4.1.2) -Os -static
cs.c: 615,580
cs.cpp: 1,306,095

-----

サイズの最適化しかやってないけどこんな感じだった

911 ：デフォルトの名無しさん：2008/03/22(土) 10:16:35

ためしにC#版もやってみた、オプティマイズなし
class App {
　static void Main() {
　　System.Console.WriteLine( "{0}" , 1 ) ;
　}
}
csc cs.cs : 3,072
ildasm で調べたら Main() のコードサイズは17バイト
コンストラクター 7 バイト、あわせて 24 バイト
その他の容量は、動作しない環境で実行したときのエラーメッセージ用実行コードその他
サイズが気になるなら、マネージド系が圧倒的に有利です

912 ：デフォルトの名無しさん：2008/03/22(土) 11:16:34

ランタイムが別なんだからそりゃそうだ

913 ：デフォルトの名無しさん：2008/03/22(土) 11:48:09

ランタイム別としても17バイトはすごいと思うよ
C だと、スタックフレームの構築だけであっさり17バイト突破するよ

914 ：デフォルトの名無しさん：2008/03/22(土) 19:09:34

ランタイム(VM)に丸投げなだけだろ禿

915 ：デフォルトの名無しさん：2008/03/22(土) 20:58:55

だからその丸投げの度合いがすっげえなって話だろ？
とっくに折り込み済みのことを突っ込みの手段に使うのって馬鹿丸出しだよ。

916 ：デフォルトの名無しさん：2008/03/22(土) 21:06:49

17Byte中に文字列 "{0}" = 8byte も込みだったりするのがまた恐ろしい。

917 ：デフォルトの名無しさん：2008/03/22(土) 21:07:28

>>913
マイクロソフトC++ V14.0でO1で最適化するとCでも14

918 ：デフォルトの名無しさん：2008/03/22(土) 21:13:01

>>913
マイクロソフトC++ V14.00でO1で最適化するとCでもmainのコードサイズは17バイトだ
スタックフレームは必要ない
最適化なしのスタックフレーム付でも22バイトにしかならん
コードサイズだけ比較しても意味ないがね

919 ：デフォルトの名無しさん：2008/03/22(土) 21:15:50

コードサイズを小さくしようという話の流れじゃないのかwww

920 ：デフォルトの名無しさん：2008/03/22(土) 22:10:24

初学者はとりあえずＣやっとけ
極めなくてもいいからやってればC++なりJAVAなりいくらでも替えがきく

921 ：デフォルトの名無しさん：2008/03/23(日) 05:42:49

Cは勉強用／拡張用には良いかも知れんが、やりたいことを実現するまでが長いのがなあ。
俺はあんまり勧められない。

922 ：デフォルトの名無しさん：2008/03/23(日) 07:58:35

確かにCじゃ画面に線一本引くのでも苦労するが、
本格的な学習の前の基礎知識を学ぶという点では良いね。

でもCの前にASMをほんのちょっとで良いから勉強してみるのも良いかも。

923 ：デフォルトの名無しさん：2008/03/23(日) 09:19:23

>確かにCじゃ画面に線一本引くのでも苦労するが、

苦労も何もCにそんな機能はない。

924 ：デフォルトの名無しさん：2008/03/23(日) 09:23:16

楽勝
putchar('-');

925 ：デフォルトの名無しさん：2008/03/23(日) 09:24:24

と思ったが標準出力が画面に出力される保証は無いんだった

926 ：デフォルトの名無しさん：2008/03/23(日) 09:25:13

C言語と追加機能を使って線を書くの略だろう

927 ：デフォルトの名無しさん：2008/03/23(日) 09:42:41

追加機能がOKならinclude1つと関数呼び出し一回で線を引ける処理系だってあるし

928 ：デフォルトの名無しさん：2008/03/23(日) 09:57:28

だから逆に言えば簡単に描けない処理系もあるわけで

929 ：デフォルトの名無しさん：2008/03/23(日) 09:59:04

標準ではかけない

930 ：デフォルトの名無しさん：2008/03/23(日) 10:13:34

FreeBSDのSSCLIでも簡単には線を引けないしCに限った話ではないな

931 ：デフォルトの名無しさん：2008/03/23(日) 11:53:03

画面のある任意の処理系に簡単に書ける言語ってあるの？

932 ：デフォルトの名無しさん：2008/03/23(日) 11:57:04

処理系に書く、ってどういう意味だろう。

933 ：デフォルトの名無しさん：2008/03/23(日) 12:00:26

グラフィックが簡単にできる言語があるかという質問では?

934 ：デフォルトの名無しさん：2008/03/23(日) 12:02:20

画面上に線が簡単に書ける言語といえばLOGOだな

935 ：デフォルトの名無しさん：2008/03/23(日) 12:16:09

グラフィックが簡単な言語というならFlash/ActionScriptだな
時点は xaml、ドキュメントとデザイナがもう少しまともになれば間違いなくコレかと。

936 ：デフォルトの名無しさん：2008/03/23(日) 13:53:03

N88

937 ：デフォルトの名無しさん：2008/03/23(日) 13:54:58

旧VBもフォームに一行書くだけで線引けるよ。

938 ：デフォルトの名無しさん：2008/03/23(日) 14:02:49

X1turbo BASIC

939 ：デフォルトの名無しさん：2008/03/23(日) 17:26:50

<hr>

940 ：デフォルトの名無しさん：2008/03/23(日) 19:03:19

>>939 ﾌｲﾀｗｗｗ

941 ：オガちゃん萌え ◆tyvkWCNtzY ：2008/03/23(日) 21:12:17

>>923
ガキの頃、Quick Cを使ってグラフィックライブラリでビデオメモリに線を引いたりしてたんだが、
あの頃はCの標準ライブラリと非標準ライブラリの違いなんぞ知る由もなかった
PC98シリーズでいかに高速な描画をやるかって、インラインでアセンブリを書きまくるとか
アーキテクチャニュートラルなコーディングなんか微塵も考えてなかった

942 ：デフォルトの名無しさん：2008/03/23(日) 21:18:50

その頃にアーキテクチャニュートラルなグラフィックのコーディングを
しようとしたら、なんだろ。X-WindowとかMotifとかかな

943 ：デフォルトの名無しさん：2008/03/23(日) 21:19:32

当時は毎回全コードを捨て去って新規に作っても十分いけるし、コードの品質も毎回向上したからね
実際、非互換の方が高速な上にすばやく作れて、となれば互換性など考える理由は無かったかと。
正しいソフトウェアは時代次第でどんどん変化する訳だ。

944 ：オガちゃん萌え ◆tyvkWCNtzY ：2008/03/23(日) 22:15:44

>>943
それだ！
だいたい、当時のPCは性能が今と比較するととんでもなく低かったんだよな
intel系は640KBのメモリとEMSメモリ、ビデオメモリの余りやらを駆使してているソフトなんかがよくあった
互換性よりも動作速度のほうが重要だったのかも
いや、移植先なんてなかったんだ、当時のPC98のシェアは日本国内の90%を越えていたしｗ

それが今じゃなんだ、ランゲージニュートラルでアーキテクチャニュートラルでUML駆動モデルで
ロバストネス分析→設計モデル。リソースは無限であるという前提ときたもんだ
下回り(デバドラやハード制御)を知らないのも困りもんだが…

945 ：デフォルトの名無しさん：2008/03/24(月) 02:37:58

Javaやってるとクローン作らないで参照戻すくせに
カプセル化がどうの言うの奴とかいるのよ
始めにCとかC++やってればそのへん安心

946 ：デフォルトの名無しさん：2008/03/24(月) 04:07:26

>>945
malloc() の返り値を呼び元でfree() してもらうのは、だめですか..........。

947 ：デフォルトの名無しさん：2008/03/24(月) 09:02:50

>>946
後処理用の関数を用意してあげるのが親切かも

948 ：オガちゃん萌え ◆tyvkWCNtzY ：2008/03/24(月) 18:51:57

JAVAやらドトネトとかRuby、Python、Perl、PHPなんかを最初の言語に選んでしまうとC/C++は
ハンパじゃなく分かりづらい言語になりそうだな

949 ：デフォルトの名無しさん：2008/03/24(月) 21:04:20

C/C++を最初の言語に選んでしまった場合は？

950 ：デフォルトの名無しさん：2008/03/24(月) 21:20:31

C/C++を選んだからといって、他の言語の学習が楽になるわけではない。

951 ：オガちゃん萌え ◆tyvkWCNtzY ：2008/03/24(月) 23:12:15

>>949
>>950の言うとおりなのだろうかと
だけど、C/C++を最初にやってると、そうでないよりはC/C++学習が楽かも
そんな俺はx86アセンブラ→Turbo Pascal→Quick Cだった

952 ：デフォルトの名無しさん：2008/03/24(月) 23:15:57

学習が楽かどうかは言語仕様よりもIDEのサポートが重要な気がする。

そりゃまあ、昔はmakeとemacsだけでなんでもやってた気がするけどサ。

953 ：デフォルトの名無しさん：2008/03/24(月) 23:33:35

漏れなんか今でも linux や Solaris では vi だなあ・・・

954 ：デフォルトの名無しさん：2008/03/24(月) 23:39:42

>>952
いまでも仕事の大半は、makeとVimで済ませてるな。デバッガもよっぽどの
ことがないと使わない。ファンクショントレースとcoreファイル開いてバックトレース
すればバグの9割以上は1瞬で解決するし。1瞬で解決しない場合は、
２，３のprint文入れればそれで解決する。

システムテストやらででてくる再現性の低い不具合とか、ハード起因の
不具合とかでは、デバッガ重宝するけど。

IDEサポートって本当にそんなに重要か？インテリセンス（笑）なんてVimだって
備えてるぜ？Unitテストなんて、Rubyでは言語のライブラリとして豊富な機能が
提供されてるぜ？VSSよりSVNのほうが便利だぜ？メトリクスツールは、
もはやフリーでも転がってるぜ？

IDEのメリットって何だ？

955 ：デフォルトの名無しさん：2008/03/24(月) 23:49:09

環境の構築が容易

956 ：デフォルトの名無しさん：2008/03/24(月) 23:53:01

>>954
VisuaｌStudioとかのC++BuilderのIDEは使うけど、ほかのIDEはエディタがいまいちなのが多くてmake作成用にしか使わない感じ。

957 ：デフォルトの名無しさん：2008/03/25(火) 00:00:08

>>955
環境の構築の容易さにアドバンテージがあるとしても、IDEを習得するための
労力と時間、一社のIDEに依存してしまうリスク、汎用性の喪失、費用などを
考えると、俺にはIDEの方がいいなんて、現時点では到底思えないな。

Eclipseも数時間で捨てた。VisualEditorだけは使うけど。
VC++使う羽目になりそうだったので、Glade+Rubyで押し切ったわ。

958 ：デフォルトの名無しさん：2008/03/25(火) 00:04:07

まあ、makeでビルド出来る時点で、変人だからねぇ

変人の普通が、普通の人の普通かって話だよなぁ...

959 ：デフォルトの名無しさん：2008/03/25(火) 00:07:15

つーかさ、makeでビルド出来るなら、VC++使っててもいいんでないの?
MFCやATL使わなきゃ環境依存なんて無いでしょ

960 ：デフォルトの名無しさん：2008/03/25(火) 00:11:32

>>959
GUI作ることになった（といっても、社内ツールだが）。VC++使ってくださいと
言われたのだけど、そのツールLinuxでも使うことが想定されたから、
「今後他プラットフォームに移植することを想定するなら、最初からそれを
考慮したほうがいいですよ」といって、Ruby+Gladeで落ち着いた。

横から「Pythonは？Pythonでいきましょうよ！」っていうPython厨がいて
驚いたが、華麗に無視

961 ：デフォルトの名無しさん：2008/03/25(火) 06:41:13

＞Python厨
ソイツは大事にしとけｗ

962 ：デフォルトの名無しさん：2008/03/25(火) 09:17:05

インテリセンス（笑）なんてVimだって備えてるぜ？

963 ：デフォルトの名無しさん：2008/03/25(火) 09:22:37

VCのインテリなら単語補完に毛が生えた程度じゃない？

964 ：デフォルトの名無しさん：2008/03/25(火) 10:09:59

>>960
> 横から
> 華麗に無視
比較的まともであると言われるPython使いの「横から目線」に、
横柄・傲慢で知られるRuby使い特有の「上から目線」で対応したわけですね？

「結果」は現場の力関係に依存するからともかくとして、
Python使いとRuby使いが登場する「人物描写」としては、実にお約束だと思いました。

965 ：デフォルトの名無しさん：2008/03/25(火) 23:46:07

ここでPython対Rubyをやるなよ…。
やるならLLバトルロワイヤルでどうぞ。

966 ：デフォルトの名無しさん：2008/03/25(火) 23:57:43

個人的に軽い社内のツールでVC++とRuby、Pythonなら
Python＞VC++＞Rubyだなぁ。

特に若い人がPython使いたいって言うなら、自分の趣味は切り捨てて
そっちを優先させるし、特にないならマルチプラットフォームでお手軽(?)なJava
選択するけど。

967 ：デフォルトの名無しさん：2008/03/30(日) 23:05:33

>>963
何を言っとる。
最近のインテリセンスはコーディング中にプリプロセス走らせるぞ。
おかげでビルドターゲットの切り替えが重い重い…。切りたくても
切れないし。

968 ：デフォルトの名無しさん：2008/03/31(月) 01:53:51

>>967
マイクロソフトからすれば、ハードウェアの進化に即した
ソフトウェアを提供しなければ、バージョンアップしてもらえ
なくなるかも、他OSに乗り換えられてしまうかも、という恐怖
が付きまとっているのだから仕方がない。

ソフトはユーザエクスペリエンスを無視して、「重い処理」を
作りこまなければ意味がない。デスクトップアプリ全盛は
それでもよかった。

Web全盛の時代、ユーザは「よりよいエクスペリエンス」が別の
ところにあると気づいてしまったのだな。そして「それで満足」
してしまいそうになっている。

まぁこれからはMSもおもてなしに移行せざるを得ないだろう。

969 ：デフォルトの名無しさん：2008/03/31(月) 01:56:15

そしてIEの改良に注力せずに、他ブラウザの追従を許してしまったことは
致命傷になるかもしれない。シルバーライトを声高に叫んだところで、
さんざんFUDで痛い目を見てきた開発者達はAIRを選択することは
目に見えている。

MS終焉の序章ですな。

970 ：デフォルトの名無しさん：2008/03/31(月) 01:57:43

頼みの綱は、WMPlayerによるDRM動画流通のしくみが豊富なとこくらいか。
はてさてDRM頼みがいつまで持つことやら。

971 ：デフォルトの名無しさん：2008/03/31(月) 03:26:57

>>968
「おもてなし」を使うということは中島さん？

972 ：デフォルトの名無しさん：2008/03/31(月) 08:19:02

つかMSの方針とかどうでもいいし
このスレで許されるMSの話題はVisual C++だけだ

973 ：デフォルトの名無しさん：2008/03/31(月) 08:56:02

vimでも～とか言ってるやつはC#のインテリ使ったことないだけだろ

974 ：デフォルトの名無しさん：2008/03/31(月) 22:41:51

>>973
C# は確かに凄い。ここまで補完が優秀だと、片手でプログラミング出来る程だな。
仕事で VC++ 使ってると、C# が羨ましくてしょうがない。
「インテリセンスを更新しています･･･」が表示されて、激重な時は特に。

975 ：デフォルトの名無しさん：2008/04/03(木) 08:32:25

>>974
C#楽なんだけどさ、propertyとかいう変なの使ってgetter/setterするのはどうも…
ついでに、インデクサって悪の枢軸じゃなかろうか？
ってか、.NET Frameworkそのものが業務アプリ作るには不十分な希ガス
.NETでGUI作って、処理部はネイティブ言語でAPIコールが生産コスト安そうだ
あとは、俺が古い考えなだけなんだが、ガーベージコレクションの恩恵を受けると、C++に戻った
ときに危うくdeleteするのを忘れそうなんだがｗ

976 ：デフォルトの名無しさん：2008/04/03(木) 08:47:22

>>975
明示的にdeleteしているならC++を使えていないと言うことだ。
auto_ptrやsmart_ptrを使うか、さもなくばデストラクタでdeleteすればいいのだから。

977 ：デフォルトの名無しさん：2008/04/03(木) 11:05:18

基本に従ってればdeleteは完璧に抹殺できるよな

978 ：デフォルトの名無しさん：2008/04/03(木) 17:03:15

VB6、VB.NETのインテリもまともなんだが
なんでVCだけタコなんだ

979 ：デフォルトの名無しさん：2008/04/03(木) 17:20:05

>>975
ttp://journal.mycom.co.jp/articles/2007/05/16/java7/

980 ：デフォルトの名無しさん：2008/04/03(木) 22:29:10

ぱくりぱくられだな