C++は難しすぎ

1 ：デフォルトの名無しさん：03/07/20 13:26

あんなの理解できるハズないだろ！
わかりやすいプログラミング言語をつくれないBjarne Stroustrupにはげんあり

2 ：デフォルトの名無しさん：03/07/20 13:26

超絶はげどう

3 ：デフォルトの名無しさん：03/07/20 13:28

>>1
がんばれ

4 ：デフォルトの名無しさん：03/07/20 13:29

C++、ま、基礎的な文法は理解してるけど
これでコーディングはしたくない。

5 ：デフォルトの名無しさん：03/07/20 13:31

その意見を誰一人否定しないと思うが使えんるんだよアレ
とりあえず単発禁止、削除依頼だしとけ。

6 ：デフォルトの名無しさん：03/07/20 13:33

Javaの方が１０倍くらい楽。
JavaがだめになったらC#に移行する。

7 ：デフォルトの名無しさん：03/07/20 13:35

C++でゲームは作れるが、チームプロジェクトでもしない限り、
VisualBasic等の方がすぐ作れて楽しいと思う。

8 ：デフォルトの名無しさん：03/07/20 13:35

Write once, compile anymore.

9 ：デフォルトの名無しさん：03/07/20 13:35

>>1
> あんなの理解できるハズないだろ！
そうかなぁ。

10 ：デフォルトの名無しさん：03/07/20 13:37

今からはC++の時代じゃない。ハードウェアの性能が上がった今はC++など
やっていても仕方がない。

（個人でちょこちょこっとやる場合は。）

11 ：デフォルトの名無しさん：03/07/20 13:38

これからはひまわりの時代

12 ：デフォルトの名無しさん：03/07/20 13:43

>>1
お前が頭悪いだけだろう。人のせいにすんな

13 ：デフォルトの名無しさん：03/07/20 13:43

>>6
template が使いこなせるようになれば世界が変わるかもよ
C++の殆ど全機能が使いこなせるようになるとJavaも必ずしも楽でもないと分ると思うが・・・

14 ：デフォルトの名無しさん：03/07/20 13:51

>>13
テンプレートは、Javaでも来年頃サポートされるらしい。

15 ：デフォルトの名無しさん：03/07/20 13:52

Javaのtemplateは使い物にならねぇよ

16 ：デフォルトの名無しさん：03/07/20 14:04

まぁC++が強力なのは否定せんが
俺は非力でも言語仕様の簡単なものの方が良い。
オートマ車で十分だよ。

17 ：デフォルトの名無しさん：03/07/20 15:29

誰かが言ってたな。
昔のプログラマが不幸だったのは、Cを覚えないと何もできなかったことだって。
今の言語なら、JavaでもVBでも、他の言語で大概潰しが利くから、
無理してC++覚えなくてもいいんじゃないか？
C++じゃないとできない事をやろうとしているなら別だけど。

18 ：デフォルトの名無しさん：03/07/20 15:35

なんか「STL使ってるプログラムは読みにくい」とへたれに言われた
のですが、ここのへたれ方々もそういったことをほざくのでしょうか？

typedef vector<int> IntArray;
IntArray ia;
ia.push_back(10);

これってやっぱ読みにくいんですか？

19 ：デフォルトの名無しさん：03/07/20 15:38

>>18
つーか,テンプレ知らない。

20 ：デフォルトの名無しさん：03/07/20 15:43

どんなことでも知っている人にしかわからないよ

でC++だけど俺も最初あんな物は開発者にしか分からないとか思っていたんだが
暇を見て解説書を眺めていたら今やもうSTLもBoostも手放せなくなっている

21 ：デフォルトの名無しさん：03/07/20 15:44

>>18
テンプレートというか、iaという変数名に対して小一時間問い詰めたい。
おまえはなぜ変数名に2文字しか使わないのかと。
誰かに「この変数、何？」って聞かれて得意づらするキモオタなのかと。

22 ：デフォルトの名無しさん：03/07/20 15:50

まぁ今の時代、UMLとか覚えることが増えすぎているし
OOだと分析・設計に手間を食うわけだから
なるべく言語は簡単な方がいいな。

23 ：デフォルトの名無しさん：03/07/20 15:51

18ではないが IntArray で変数名が ia なら見ての通りだと思うが、
これで解らないなら脳がヤバイよ。

24 ：デフォルトの名無しさん：03/07/20 15:52

>>18
俺もSTL使ってるけどキタネェなって思うときはあるよ。
ポインタの配列をvectorでもっておいて
容量を増やしつつ新しく作ったものを格納して初期化
って良く使う流れを行うとなんか汚くなるんだけどみんなどう書いてる？
俺がSTLかじっただけでアホなやり方してるだけかもしれないけど。

25 ：デフォルトの名無しさん：03/07/20 15:57

3行しかないサンプルでどんな意味のある変数名
付ければ >>21 は満足なのか。

26 ：デフォルトの名無しさん：03/07/20 15:58

>>24
汚くなったコードを晒してくれれば添削できるかもしれない。

27 ：デフォルトの名無しさん：03/07/20 16:35

>>26
携帯なので書きにくいんだ。
手順をいうと要素を増やすのに
・サイズを取得する
・リサイズして１増やす。
・newで生成したものをいれる。
・今作ったもの初期化する。

てやってるんだけど
これが汚いんだ本当。
末尾に追加とかあると思うけどリサイズで済むなら別にいいやとか思ってたりする。
一番末尾にある要素にもsize()-1とかやってたりする。

28 ：デフォルトの名無しさん：03/07/20 16:37

>>6
>JavaがだめになったらC#に移行する。
（ﾟДﾟ）ﾊｧ? 時代はD言語への移行だろ

29 ：デフォルトの名無しさん：03/07/20 16:48

v.push_back(new hoge("hoge"));
なら１行で済むはずなんだが...。

30 ：デフォルトの名無しさん：03/07/20 16:55

>>15
おまえはここへ逝け

【猿が】JavaﾆGenericsﾊ不要【ｿｰｽ汚す】
http://pc2.2ch.net/test/read.cgi/tech/1055519583/l50

31 ：デフォルトの名無しさん：03/07/20 17:10

>>1
その気持ちは理解できなくも無いが、全ての機能を覚えなくても良い、
どんな機能があるか概要だけ知っておいて、詳細は必要になったときに
覚える、というスタンスでやればいいんでないの？

32 ：デフォルトの名無しさん：03/07/20 17:15

>>1
ttp://hp.vector.co.jp/authors/VA000092/jokes/strup.html

33 ：デフォルトの名無しさん：03/07/20 17:43

>>31
そういう人はよく見かけるけれど、C++に限ってはそれは危ないよ

34 ：１８：03/07/20 17:47

＞＞２１
ぎゃはははははは（ﾜﾗ

ちゅうがくせいはなつやすみのしゅくだいでもやってろって（ﾜﾗﾜﾗ

( ｀_)乂(_´ ) 勝負！＼(^o^)／
☆○（゜ο゜)ｏぱ～んち、☆（゜o(○=（゜ο゜)ｏバコ～ン!!( ﾟ▽ﾟ)=◯)`νﾟ)
･;'パーンチ　（＞＿＜）いてっ！
ダメ!! ゛o(≧◇≦*)oo(*≧◇≦)o″ダメ!!
(☆o☆)きゃ～～(@_@;)やられた～～(o_ _)o ドテッ　ガ━━（ﾟДﾟ;）━━ン！
(+_+) 気絶中。。。｡･ﾟﾟ･o(ｉДｉ)o･ﾟﾟ･｡うぇぇん <(゜ロ゜;)>ノォオオオオオ!!　∑(ﾟ□ﾟ；ハウッ！
なあんて（#⌒▽⌒#）こんな私っ！σ(^_^)だけど、（／／／▽／／／）
お友達になってm(_ _)mくださいませませ♪('-'*)フフ
ﾄﾞｶﾞ━━━Σ(ll◎д◎ll)━━━━━ﾝ　ということで。(^-^)vじゃあね～～～♪
(⌒0⌒)／~~ ほんじゃo(゜▽゜ヽ)(/゜▽゜)o レッツゴー♪

35 ：デフォルトの名無しさん：03/07/20 17:50

>>33
具体的にどんなことでしょうか？

俺なんかは多重継承なんて、できることは知っててもC++始めて数年間、やり方を
知りませんでした。
今でも全く、と言っていいほど使わないけど。

36 ：デフォルトの名無しさん：03/07/20 17:54

>>28
アメリカのアホーにも載ってない言語誰が使うかと。
ネタにマジレス。

37 ：デフォルトの名無しさん：03/07/20 17:57

D言語
http://www.digitalmars.com/d/

38 ：デフォルトの名無しさん：03/07/20 18:08

>>35
多重継承とかならキャストの問題とか、
他にも代入を定義していないと、構造体としてコピーされるとか
explicit をつけないと勝手にキャストされて謎の挙動になるとか
ようするに、全部把握していないと簡単に落とし穴に簡単に落ちるってところ。
C++歴史があるので、積み上げに積み上げた無理のある言語仕様になっていますからね。
言語仕様ではないが所有権共有リファレンスカウンタ式スマートポインタを何も考えずに使ってしまう人とかも危険。
また、実際使うときにも、話題によく上がっているようにtemplateなんかは、
細かい仕様を理解していないと上手に使えないから、
C++本来のおいしい所が使えなくて、なんだこりゃ具合の悪い言語だって事になってしまいます。

とはいっても、いっぺんに全部とは絶対に行かないので、少しづつ憶えざるをえないですが、
それでも最終的には全部知らないとよろしくないと思います。

39 ：デフォルトの名無しさん：03/07/20 18:08

>>29 例外安全にしる。

40 ：デフォルトの名無しさん：03/07/20 18:14

>>29
追加したあと追加した要素を初期化したいときなんかは
リサイズ使うときとあんまり変わらなくないですか？

ところで末尾の要素ってどうやってアクセスしてますか？

41 ：デフォルトの名無しさん：03/07/20 18:17

vector::back()

42 ：デフォルトの名無しさん：03/07/20 18:20

>>40
> 追加したあと追加した要素を初期化したい
ここらへんが間違ってないか？

43 ：デフォルトの名無しさん：03/07/20 18:21

>>38
> 言語仕様ではないが所有権共有リファレンスカウンタ式スマートポインタを何も考えずに使ってしまう人とかも危険。

これってなにか落とし穴があるの?

44 ：デフォルトの名無しさん：03/07/20 18:24

>>43
巡回参照問題とかでさがしてみ

45 ：あぼーん：03/07/20 18:24

http://homepage.mac.com/hiroyuki44/

46 ：デフォルトの名無しさん：03/07/20 18:28

循環参照て言わないか

47 ：デフォルトの名無しさん：03/07/20 18:30

>>41
ありがとうございます

>>42
なんで駄目なんですか？
自分じゃどこが悪いのか全くわかりません。

48 ：デフォルトの名無しさん：03/07/20 18:31

難しいのは同意だが、代わりがないのも事実。
Java も C# も D も上っ面は似てるけど、対応分野が違うし、
(特にJavaは次世代COBOLの座が確定状態な上にGenericsがあれではC++で培われたテクニックが何も使えん)

というわけで C -> C++ の流れの次の言語の登場を待たれい！
俺は今そんな目的でトランスレータを作ってるが、こないだやっと数値リテラルをトークン化できるようになったトコロなので
完成は１０年後くらいだ！！

49 ：デフォルトの名無しさん：03/07/20 18:31

高校２年のときVBがはじめて３年後半からC++にあがって今大学３年、C++以外使う気にならないな。
VBからC++にうつったときはこんなもん使えるかよバカ、：：ってなんだよボケとか思ったが・・・
しかしC++なのにポインタばっかり使って参照は滅多に使わないな。なんでだろう。
まあ継続してやっていけば年々理解が深まるからいずれ使えるようになるさ。
良著と呼ばれる本をあさって読もう。

50 ：エスパー伊藤ギャビン：03/07/20 18:32

サイキックシェアードポインタ最強！

51 ：デフォルトの名無しさん：03/07/20 18:34

>>18
つーかSTL無いと困るよね。とくにvector。一回STL本に目を通せば別に読みづらくないのに。

52 ：デフォルトの名無しさん：03/07/20 18:36

>>47
未初期化なオブジェクトがコンテナに含まれているタイミングがある。
マルチスレッドだと深刻な問題になり得る。

new のあとにさらに初期化が必要なのが、もっと根本的な問題。

53 ：デフォルトの名無しさん：03/07/20 18:36

Effective C++
More Effective C++
Efficient C++
Exceptional C++
More Exceptional C++
Modern C++ Design
こんなトコかな？これくらいこなせば中級者くらいにはなれる。

54 ：デフォルトの名無しさん：03/07/20 18:40

あと、
Effective STL
C++ FAQ
C++標準ライブラリ　チュートリアル＆リファレンス
憂鬱

55 ：デフォルトの名無しさん：03/07/20 18:41

>>40
コンストラクタでの初期化と再初期化のこと？
格納したクラスの仕様書に載ってるはずだが...。

iteratorって知ってる？
*(v.end())

もう少し基本的なことを調べたほうが近道だと思われ。
explicit,コンストラクタ初期化子,iterator,
Effective C++,STL標準講座,boost,DeepC++(MSDN templateの話題),Modern C++

56 ：デフォルトの名無しさん：03/07/20 18:42

> *(v.end())
未定義

57 ：デフォルトの名無しさん：03/07/20 18:46

More Effective C++ は翻訳が悪いらしいが本当？

58 ：デフォルトの名無しさん：03/07/20 18:49

c++はどんなにSTLやtemplateその他の機能が理解できてもしょせん
根っこのほうを理解していないと一人よがりなコーディングになるのがオチ。

59 ：デフォルトの名無しさん：03/07/20 18:52

*(v.end()-1)
end()は末尾の一つ後だったね...。

60 ：デフォルトの名無しさん：03/07/20 18:53

>>57
たしかに読みにくかったけど、まあしょうがないでしょう。
嫌なら原著嫁って事で。

>>58
>1 の書き方だと他の言語はしっかりわかるみたいだけど。
ところで根っこの方って何？ぼいんﾀﾝ演算とかそういう古臭いCの知識だったらむしろはじめは無い方がいいとすら思う事もあるけど。

61 ：デフォルトの名無しさん：03/07/20 19:03

>>52-55
初期化ってコンストラクタですべてやりきるものなんですか？
そもそもtryとcatchを職場で使っている人間がいなかったりします。
initとかありますよ。
紹介してもらった本よんで頑張ります。

62 ：デフォルトの名無しさん：03/07/20 19:52

>>60
ポインタ演算くらいは古臭いとかじゃなくてC系の言語を使うものの常識して欲しいと思うが・・・
C++を使うって時点で特殊なターゲットを相手にする確率はメチャメチャ高いわけだし。
とはいっても、知らないと一人よがりになる根っこの方って何だよと思うのは同感。

63 ：60：03/07/20 21:07

>>62
ポインタはほとんどオブジェクト参照としてしか使ってないのでね。
大抵は配列の書式で間に合うし。
CやっててC++できないって人の多くが、「今までのやり方==正しいやり方」っていう勘違いの為に
C++使えないでいると思う。
だから下手するとCとか知らないほうがC++マスターするにはいいんではないかと。
ちなみに漏れはBASIC系育ちだが、もはや母語がC++になってまった感があります。
(もちろんポインタ演算もたまにしますよ、パフォーマンスが気になる部分で、ポインタ演算使っても複雑怪奇にならない所だけだけど。)

64 ：デフォルトの名無しさん：03/07/20 21:10

>>63が良いこと言った！

65 ：デフォルトの名無しさん：03/07/20 21:30

イテレータがあればポインタいらない

66 ：デフォルトの名無しさん：03/07/20 21:52

>>63
でもCからC++に行った人で、「今までのやり方 != 使ってはいけない悪しきやり方」と
思い込む余りにC++の全てを覚えることに焦って破綻、ってパターンもあると思うが。

67 ：デフォルトの名無しさん：03/07/20 21:53

>>66
!= じゃなくて == だった。

68 ：デフォルトの名無しさん：03/07/20 22:29

>>63
「今までのやり方!=正しいやり方」はもちろん「近年のやり方!=正しいやり方」です、
こんなものは時代ととも学者が適当に理由をつけて代わる物だし、貴方も勘違いです、多分。
なお、ポインタを使うことにより、使わないよりスッキリしたプログラムを書くことができる場合
それを使わないで執拗にこだわれば、それは裸の王様という物です。
ポインタ演算がパフォーマンスのためだけにあると思うのであればそれは間違いなく勘違いでしょう。

69 ：デフォルトの名無しさん：03/07/20 23:00

ポインタはつかわない。
参照！コンテナ！イテレータ！
おわり。

70 ：デフォルトの名無しさん：03/07/21 01:50

>>68
釣られんなよC親父。

71 ：デフォルトの名無しさん：03/07/21 01:53

>>70
今さら「釣り」か。悔し泣きカコイイな( ´,_・・`)ﾌﾟｯ

72 ：デフォルトの名無しさん：03/07/21 02:29

>>68==71
哀れだな。管理職にもなれず３０歳定年説を覆しつづけて現場の若造から
ウザがられ続けているC親父というのは。

73 ：デフォルトの名無しさん：03/07/21 02:35

うわーわかりやすい。
「釣り」っていうごまかしを看破されて何も言い返せないもんだから、
苦し紛れの妄想を水増しして間に合わせてるよコイツ。
だっさ。

74 ：デフォルトの名無しさん：03/07/21 02:56

>>68==71==73
どうしてムキになっているのですか？
怖がらなくてもいいのにー:p

75 ：デフォルトの名無しさん：03/07/21 03:43

>>74
あー、今度は日下部の真似ね。よしよし。
でも下手糞ｗ

さ、次はどうやって自分の火病をアピールする？

76 ：デフォルトの名無しさん：03/07/21 03:51

>>75
ご苦労様。うん、君が正しいね。よかったね。

77 ：!= 75：03/07/21 07:44

>>68
>時代ととも学者が適当に理由をつけて代わる物
学者の意見なんて誰も聞いていない。だいたい学者なんているの？
スパハカの人たちがテクニックを開発し、それが広まる。

>ポインタを使うことにより、使わないよりスッキリしたプログラムを書くことができる場合
C++では、そんな場合は、まずない。
そんなこと言ってるようじゃ、やっぱりC親爺とよばれても（ｒｙ

78 ：デフォルトの名無しさん：03/07/21 10:20

68 だけどね、普段からポインタを使っているわけではないよ、基本はスマートポインタだ。
いずれにしてもあんたらよりはC++を使いこなしている自信はあるよ。

>>77
>C++では、そんな場合は、まずない。
と思っているからいつまでたっても使えないのさ。

79 ：デフォルトの名無しさん：03/07/21 10:31

>いずれにしてもあんたらよりはC++を使いこなしている自信はあるよ。

へー。使いこなしてるんだー。すごいですねー。
スマートポインタですか。ふーん。
年を取っても若いものには負けてないんですね。

俺たちもがんばろうな。（ｗ

80 ：デフォルトの名無しさん：03/07/21 11:41

＞なお、ポインタを使うことにより、使わないよりスッキリしたプログラムを書くことができる場合

すまんが、コード例とかで示してくれんか。俺には思いつかんのであげ

81 ：デフォルトの名無しさん：03/07/21 12:00

68じゃないけど。こういう書き方ってどうなんだろ。

struct a_type
{
unsigned char a : 2;
unsigned char b : 4;
unsigned char c : 2;
}

void* const addr = (void*)0x420000;
reinterpret_cast<a_type*>(addr)->b = 0x1234;

すっきりしてないかも。

82 ：デフォルトの名無しさん：03/07/21 12:04

厨房の頃プログラミングしようと思って、VC++6買ったはいいが買ったその日に挫折した。

83 ：デフォルトの名無しさん：03/07/21 12:09

でも、今なら出来そうな気がする。。
あのときに買ったVC++6Proのアカデミック版、探してみよう。

84 ：デフォルトの名無しさん：03/07/21 12:15

>>81
a_type& a = *reinterpret_cast<a_type*>(0x420000);
a.b = 0x1234;

85 ：デフォルトの名無しさん：03/07/21 12:46

>>82
できるか！Ｃ＋＋は数学と同じ積み重ねが必要なんだぞ！

86 ：デフォルトの名無しさん：03/07/21 12:49

VB→Delphi→C#と、それぞれ中途半端に積み重ねたので。

87 ：デフォルトの名無しさん：03/07/21 13:44

a_type& a = *reinterpret_cast<a_type*>(0x420000);

88 ：デフォルトの名無しさん：03/07/21 14:45

>>68はどこに逃げた？
ﾌﾟｹﾞﾗって書いてもいいか？

89 ：デフォルトの名無しさん：03/07/21 15:03

>>88
あなた79？
反応もらえるような内容のあるレスじゃないと思うけど・・・。

90 ：デフォルトの名無しさん：03/07/21 15:46

>>85
本当か？

91 ：デフォルトの名無しさん：03/07/21 16:01

16 人中、1人の方が、｢このレビューが参考になった｣と投票しています。

似非オブジェクト指向開発者にお勧め, 2003/05/23
レビュアー：カスタマー　東京都 Japan
この本ほど素人から絶賛され，そうでない人から無視される本も珍しいの
ではなかろうか．ざっと見ただけでも，プログラミングパラダイムが完全に
１～２世代前のものだということが伺える．10年前ならいざしらず，2000年
も過ぎた今になってもこのような本が絶賛される辺りに，日本のソフトウエア
産業の人材枯渇という深刻な問題が伺える．

ｳﾎｯ

92 ：デフォルトの名無しさん：03/07/21 16:06

スマートポインタはポインタの6倍遅い(boost::shared_ptr)

93 ：デフォルトの名無しさん：03/07/21 16:10

スマートポインタなんて循環参照も手動で解決しなきゃいけない糞ショボイもの使わないで、
GCライブラリ使おうぜ。w3mだって使ってるんだから。

94 ：デフォルトの名無しさん：03/07/21 16:15

>>91
何の本？

95 ：デフォルトの名無しさん：03/07/21 16:20

憂鬱

96 ：デフォルトの名無しさん：03/07/21 16:26

>>95
ありがとう、見てきた。マジだｗ

97 ：デフォルトの名無しさん：03/07/21 16:29

1人は本人だな

98 ：デフォルトの名無しさん：03/07/21 16:35

どんな本だか逆に読みたくなってきてしまった。きっと次に本屋でみたら買ってしまう
ttp://www.amazon.co.jp/exec/obidos/ASIN/4881356194/ref=lm_lb_3/250-0725465-7120222

99 ：デフォルトの名無しさん：03/07/21 17:16

>>98
憂オブだな。いまのところOOを理解するのにこれが一番手っ取り早い。
俺は３回読んだ。
これに目を通さずして、OOを身につけたという人は、よほどのプロだと推測される。

100 ：デフォルトの名無しさん：03/07/21 17:25

似非オブジェクト指向開発者ｷﾀ━━━━(ﾟ∀ﾟ)━━━━ｯ!!

101 ：デフォルトの名無しさん：03/07/21 17:30

まぁこの本はUMLで表記されていないというだけで
本質的なところは役に立つ、と推測される。

102 ：デフォルトの名無しさん：03/07/21 17:31

似非オブジェクト指向開発者２人目ｷﾀ━━━━(ﾟ∀ﾟ)━━━━ｯ!!

103 ：デフォルトの名無しさん：03/07/21 17:33

まぁこれを読んで開発スタイルが変わったというわけではないが、
今まで何となくやっていた作業が明確に記されているという点は特筆される。

104 ：デフォルトの名無しさん：03/07/21 17:45

C++は簡単すぎるね。
もっともっと複雑な方が学習の楽しみが長く続いて良かった。

105 ：デフォルトの名無しさん：03/07/21 17:55

>>104
言語以外にも学習すべきことは山ほどあるので、まだお楽しみは続く。
UML2.0とか。

106 ：デフォルトの名無しさん：03/07/21 17:57

>>104
Modern C++ Designやboostのソースがスラスラ読めるって事ですか？

107 ：104：03/07/21 18:02

>>105
でもそれってC++に限定したことではないから
まあまあ面白いのは認めるが別の話ね

>>106
スラスラまでは読めないけど、なんていうのかな
もう新しいことを学ぶ面白さのピークの部分は過ぎちゃって
後は細かくてつまらないところが残っているという感じだな
最初にこのつまらない細かい部分に目が行くと
「C++は難しすぎ」という感想になるんだろうな

108 ：デフォルトの名無しさん：03/07/21 18:04

てゆーか、ろくにオブジェクト指向について考えないで
テンプレートとかの悪用および勘違い技術ばっかり身につけてる奴ってどうよ。
始めは継承もテンプレもなかったんだからオブジェクト指向がどんなもんかそこからわかるはずなんだが。
いや、別に使うなってことじゃないよ。
どうも変な方向で覚えてる奴が多いんだよな。
STLやらBoostやら覚えることにはやけに熱心だけど
肝心のオブジェクト指向はさっぱりわかってなくて
設計が絶望的にヘタクソってのがいてちょっと心配。

109 ：デフォルトの名無しさん：03/07/21 18:06

設計がうまくなるには経験と　あと何が必要？

110 ：デフォルトの名無しさん：03/07/21 18:10

>>109
経験とちょっとかぶるけどカン。だろうね。

OO に限って言えば
よく「デザパタはコミュニケーションツールに過ぎない」って意見を見るけど
それは違うと思う。
デザパタを覚えていくと、そこに共通してある設計のセンスとかが汲み取れて
単純にゼロから経験するよりも、カンの働きが鋭くなるまでの道のりが短縮できると思う。

111 ：デフォルトの名無しさん：03/07/21 18:31

>>108
Genericsはオブジェクト指向ではない。有用性も和歌欄奴が吠えるな。

112 ：デフォルトの名無しさん：03/07/21 18:44

>>111
>>108さんが果たしてどうなのかってのはとりあえず別にして

＞Genericsはオブジェクト指向ではない

C++ のテンプレートはもはや Generic programming の為だけのものではありませんよ。

113 ：デフォルトの名無しさん：03/07/21 18:54

>>112
オブジェクト指向でいくならJavaのようにシンプルにいったほうがいい、
テンプレート駆使してオブジェクト指向をすると変になるよ。

114 ：112：03/07/21 18:58

>>113
C++ はオブジェクト指向一本の言語じゃないんですよ。
C++ にとってのオブジェクト指向っていうのは、使える方法論の一つに過ぎないんです。

こういうと気分を害されるかもしれませんが

＞テンプレート駆使してオブジェクト指向をすると変になるよ。

多分、OO も Generic programming も Generative もまだちゃんと理解されてないのだと思います。
私の場合は上記３つ＋(昔からの)構造化の４本槍ですが、
何一つ変なことにはなってないです。

115 ：デフォルトの名無しさん：03/07/21 19:06

C++機能が足りねーよ。
とりあえず明日までにlambdaとプロパティつけてくれ。
この二つはテンプレートではちとキビシイ。

116 ：デフォルトの名無しさん：03/07/21 19:11

VBは難しすぎ
ってスレは需要あるかなぁ？

117 ：ルナちゃん：03/07/21 19:12

>>1
同意

118 ：デフォルトの名無しさん：03/07/21 19:18

>>114
>C++ はオブジェクト指向一本の言語じゃないんですよ
私もそう思うよ。
でもね、統一性のないのは良くないと思うな、そういうのは自分はいいと思っていても
はたから読むと恐ろしく読みにくいものです。
気づいていないのは自分だけですよ、てゆうかオレがそうなんで人のことは言えないんだが・・・

template を使って OO するなら、例えばガベコレのないC++のことですから、
これをスマートポインタにしたりとか型安全の範囲で使うのがいい。
たとえば型の写像を追うようなマネはするべきではないと思う。
しかし Generic programming を中心にすえるなら、それもありだよね。

119 ：デフォルトの名無しさん：03/07/21 19:24

> そういうのは自分はいいと思っていても
> はたから読むと恐ろしく読みにくいものです。

そりゃオブジェクト指向しかわかってない香具師にも
Genericsしかわかってない香具師にとっても恐ろしく読みにくいだろうな。

120 ：デフォルトの名無しさん：03/07/21 19:38

俺はガベージコレクタやスマートポインタが必要になるのは
設計が腐ってるからだとしか思えない。

121 ：デフォルトの名無しさん：03/07/21 19:42

>>120
俺はお前の設計論が腐ってるとしか思えないですよ。
なんでそんな考えに至ったのかその経緯をお教え願いたい。

122 ：デフォルトの名無しさん：03/07/21 19:46

>>121
ある程度まで単純なプログラム(といってもこれには現実的なソフトウェアの7割8割が含まれるような気がする)しか
組んだことなければ、そういう考えに至ってもおかしくない。

もっとももっと複雑な場合には参照カウント式スマートポインタとかだと中途半端だったりするのも事実。(帯に短し白線流し)

でも例外使うときは auto_ptr は使いましょうね。あれは俺の中では基本すぎてスマートポインタには入ってないんだけど。

123 ：122：03/07/21 19:47

最後の一行は >>120 へ向けての文でした。まぎらわしくてスマソ

124 ：デフォルトの名無しさん：03/07/21 19:59

スマートポインタも結構ややこしいし、
言語サポートガベコレ付き new と専用ポインタが欲しい今日このごろ

125 ：デフォルトの名無しさん：03/07/21 20:05

ガベージコレクションが必要ってことはどっかに漏れがあるってことで場合によっては危ないプログラムでは？

126 ：デフォルトの名無しさん：03/07/21 20:09

はあ?

127 ：デフォルトの名無しさん：03/07/21 20:11

いまやメモリリークしないアプリケーションの方が希少
積極的にガルベージコレクタを使うべき

128 ：江東支店：03/07/21 20:13

http://elife.fam.cx/a007/

129 ：デフォルトの名無しさん：03/07/21 20:14

>>121
クラスを作ると必ず依存関係ってものが生まれると思うんですよ。
基本的にnewで作ったときと同じクラスでdeleteをするようにすれば問題ないですよね。
で、複雑になるのが
ある一つのインスタンスを複数のインスタンスが必要としてるとき
ですよね。
これをスマートポインタとかいうただの実装技術で回避するのは少々強引ではないか。
ってことです。
明らかに設計段階で考慮するべきことではないか
っていいたいわけです。

130 ：デフォルトの名無しさん：03/07/21 20:27

>>129
よくわかんねー
じゃーどうやって回避すんの？
複数から参照される場合どうしたらいいの？

131 ：デフォルトの名無しさん：03/07/21 20:52

>>130
そこが設計の魅せ所です。
そこでわからないとか言わないでください。
解決方法はとりあえず二つは浮かぶでしょう。
一つは、必要とされる側を必要とする側より早く消すことができないような構造にしてしまうこと。
もう一つは、管理クラスを間において直接アクセスを許さない構造にすること。
です。
一つ目のやり方は必要とされる側が必要とする側より明らかに生存期間が長い場合です。
二つ目のやり方はどちらも生存期間がわからずその状態によって動作を変えるときです。
こんなんでどうでしょうか。

132 ：デフォルトの名無しさん：03/07/21 20:55

いやです。

133 ：デフォルトの名無しさん：03/07/21 21:01

>>131
スマートポインタを使ったほうがスッキリした構造になるんじゃねーの？

134 ：デフォルトの名無しさん：03/07/21 21:04

>>131
そういうやり方が有効な時もあるんだろうけど、
だからってスマートポインタ使った設計を否定しちゃいけないよな。設計云々語る以上さ。

っていうか、あんたの提示した「１つめのやり方」は曖昧だし、
他の要因次第で使えない可能性は高いよな？
で「２つ目のやり方」の場合、いつ誰がトリガーを押すのかが問題になる。
それは結局C++以前の「すべてプログラマが管理する」時代への逆行を意味するのでは？
これを解決しようとするとC++ではデストラクタ経由スマートポインタ行きの船に乗ることになる。

実装の前に設計なし、設計の前に実装なし。
とりあえず否定するまえに挑戦してみろ。

135 ：デフォルトの名無しさん：03/07/21 21:21

C++ 専門バカ
VB　業務で仕方なくやっている人
C ハード密着　又は　時代遅れの人
Java　普通の人

136 ：デフォルトの名無しさん：03/07/21 21:22

COBOLは？

137 ：デフォルトの名無しさん：03/07/21 21:36

winアプリを無駄なく構築できるのはＣ＋＋。winグラマならＣ＋＋は必須かつ基本的な知識。

138 ：デフォルトの名無しさん：03/07/21 21:38

>>134
また、わけがわからないこというなぁ。
じゃあ聞くけど設計って何するものよ？
破綻してる設計をどうしてスマートポインタなんかでごまかして満足なのよ。
スマートポインタが必要な時点で設計ミスってるってわかるでしょう。
実装と設計でどっちが優先かなんて馬鹿でもわかること説明させないでよ。

ね？設計が絶望的にヘタクソなくせにテンプレばっか熱心に覚える奴っているでしょ？
くすくすくすくす笑
この分じゃオブジェクト指向だって理解してねーだろ？

139 ：直リン：03/07/21 21:38

http://homepage.mac.com/maki170001/

140 ：デフォルトの名無しさん：03/07/21 21:41

すべての設計が完璧ならこの世はどれだけ幸せでしょう

141 ：デフォルトの名無しさん：03/07/21 21:43

> スマートポインタが必要な時点で設計ミス
これは大変興味があるところだ。

142 ：デフォルトの名無しさん：03/07/21 21:47

> スマートポインタが必要な時点で設計ミス
Javaはどう見ればいいんだ？

143 ：デフォルトの名無しさん：03/07/21 21:59

>>138=>>108 だね
テンプレートにやけに恨みがあるご様子。

>ね？設計が絶望的にヘタクソなくせにテンプレばっか熱心に覚える奴っているでしょ？
今までのやりとりでなんで、さも↑の証明が出来ただろ？と言わんばかりに勝ち誇れるのか解りません。

144 ：デフォルトの名無しさん：03/07/21 22:09

>>143
俺は設計がヘタクソなくせにテンプレを悪用してそれに気付かない奴が大嫌いなんだ。

145 ：デフォルトの名無しさん：03/07/21 22:09

来てね
ttp://ainenjyukai.hp.infoseek.co.jp/

146 ：デフォルトの名無しさん：03/07/21 22:10

オブジェクトに参照カウント機能を持たせるように設計した。
実装では参照カウントを自動でやってくれるスマートポインタを使った。

これは破綻している設計ですか？

147 ：デフォルトの名無しさん：03/07/21 22:10

>>142
スマートポインタはないでしょ。

148 ：デフォルトの名無しさん：03/07/21 22:20

>>137
MFC:無駄だらけ
WTL:なくなりそう…

149 ：デフォルトの名無しさん：03/07/21 22:21

設計 != >>138の脳内の設計の定義
に 10000GoF

＞じゃあ聞くけど設計って何するものよ？
＞スマートポインタが必要な時点で設計ミスってるってわかるでしょう。

どうやら>>138の脳内の設計とは
スマートポインタを使わずに済ますことらしい。

150 ：デフォルトの名無しさん：03/07/21 22:29

(´-`).｡ｏＯ(・・・訳の解らんことを主張している>>138・・・）

(´-`).｡ｏＯ(・・・>>138がオブジェクト指向理解してなさそう・・・）

151 ：デフォルトの名無しさん：03/07/21 22:44

>>150
きっと表現力で勝てない事をひがんでるJava厨だよ。

と、書くとJava使ってる人全般に対して喧嘩売ってるみたいに見えるから補足。
JavaもJava使ってる人も悪くない。悪いのはJavaが全分野でNo1じゃなきゃ気がすまない厨ね。

152 ：デフォルトの名無しさん：03/07/21 22:47

やっぱOOPLはSmallTalkが一番だと思うのですよ。

153 ：デフォルトの名無しさん：03/07/21 22:49

>>138
C++だけでなくJavaとかC#とかをやってみたらいいと思う、
多分、無理やりクラスとか使って、オブジェクト指向が解らないのが自分で解ってないんだと思う。
解れば別にスマートポインタがメモリー管理だけでなく、デストラクトの順序を保障するとか
もっともっと重要な部分が解ってくると思うよ。
みんな貴方が一番OOが解ってないと解ってるんだけど、貴方だけがわかってないみたいでちょっと見ていてイタイです。

154 ：デフォルトの名無しさん：03/07/21 22:51

OOPLでガベコレが無いのってC++くらいでしょ。

155 ：デフォルトの名無しさん：03/07/21 22:54

>>154
残念ながらC++はOOPLではありません。マルチパラダイム言語です。

156 ：デフォルトの名無しさん：03/07/21 22:55

>>154
Objective-C

広義のガーベジコレクションはあるけどね。

157 ：デフォルトの名無しさん：03/07/21 23:04

C++にガベコレは必要ない。
そもそもガベコレの無い言語は必要なのだ。

なぜならガベコレ自体をガベコレがある言語では記述できないから　（つかしても意味が無いから

158 ：デフォルトの名無しさん：03/07/21 23:10

> そもそもガベコレの無い言語は必要なのだ。

だからといって C++ にガベコレが要らないというわけにはなりませんね。

159 ：デフォルトの名無しさん：03/07/21 23:13

>>158
じゃーmanaged C++使えばいいんでないの？ごめんなさいよく知りません。
もしくはBで始まるC/C++で使えるガベコレ導入するとか？ごめんなさいよく知りません。

160 ：デフォルトの名無しさん：03/07/21 23:16

managed C++は移植性可搬性に大きな問題がある。
Bで始まるガベコレは所詮ライブラリ。

161 ：デフォルトの名無しさん：03/07/21 23:19

C++(C)はポインタをかなり自由に使えるからごみ判別自体が難しいだろう

162 ：デフォルトの名無しさん：03/07/21 23:20

Bで始まるガベコレってコードが貧雑になるからやだ。
やっぱ言語自体が実装してくれないとね。

163 ：デフォルトの名無しさん：03/07/21 23:24

>>160
それは不思議な意見だ。
コンパイラの独自拡張に任せればどうやったって可搬性はなくなるし、
仕様に含めて強制すれば恐ろしくパフォーマンスを低下させる。

164 ：デフォルトの名無しさん：03/07/21 23:29

俺はガベコレは参照カウンタで十分だと思う
起きる問題って循環参照だけっしょ？

165 ：デフォルトの名無しさん：03/07/21 23:35

>>164
十分だと思う、それがあると構造のあるコンテナがまともに作れん。

166 ：デフォルトの名無しさん：03/07/21 23:36

>>163
いや、だから規約内でガベコレうまくやろうやって方向が正しいんじゃあ？

cyclic_shared_ptr はどうなの？誰かboost追っかけてる人の感想ラゴンヌ。

167 ：デフォルトの名無しさん：03/07/21 23:58

難しすぎなC++を理解し終わって
もっと機能が欲しいという人たちにこのスレは占拠されました。

C++を理解できない人たちはそもそも頭が弱いので反論もできません。

168 ：デフォルトの名無しさん：03/07/22 01:22

Ｃ使いとしては、>>1 に同意
難しいというより使いにくい。

169 ：デフォルトの名無しさん：03/07/22 07:20

C++は、難しいのではなく、複雑(煩雑)なのだと思う
つー訳で、STL使いたくない香具師は、STLを使わなければ良いだけだし
漏れみたいに、演算子のオーバーロードが、(便利な時もあるけど)あまり好きでない香具師は
演算子のオーバーロードを、あまり使用しなければ良いし
スマートポインタが…(略)

170 ：デフォルトの名無しさん：03/07/22 07:39

>>153
何度も言うけど設計の時点でミスってるものをなんで誤魔化そうとするものを使うの？
きちんと設計すればそんなものいらないでしょ。
こんな基本的なこともわからないで設計段階で何を考えてるのよ。
それと言語の性質みたいにいわないでよ。
JavaやC#を使うとインスタンスの依存関係も管理ができなくなるのか？
違うでしょ。
スマートポインタが必要ってのは明らかに設計ミスなんだよ。
最近の生成と破棄に関しての実装技術はなんか信用できない。
使ってもちっとも便利になった気がしない。
解決するべき問題が違う方向にいってる。

171 ：デフォルトの名無しさん：03/07/22 07:42

キター！

「スマートポインタが必要ってのは明らかに設計ミスなんだよ。」

の理由を述べてください。
もう前提条件が間違っているとしか言えません。

172 ：デフォルトの名無しさん：03/07/22 07:44

スマポって何ぞよ？

173 ：デフォルトの名無しさん：03/07/22 07:46

>>172
大乱闘スマッシュ○○ぽ…

174 ：デフォルトの名無しさん：03/07/22 07:50

オブジェクト自身にそれ自身の管理をさせる参照カウンタは設計ミスになりますか？

175 ：デフォルトの名無しさん：03/07/22 09:09

ここまでくると悲惨としか言いようがないな(^^;

176 ：デフォルトの名無しさん：03/07/22 09:22

参照カウンタの加減が間違ってる腐った実装ならあるかもしれないな。

177 ：デフォルトの名無しさん：03/07/22 10:42

設計ミスって言ってる時点で妄想家だよね。

178 ：デフォルトの名無しさん：03/07/22 11:12

「設計ミス」の定義が明らかでないと
「明らかな設計ミス」がどういうことだかわからん。
しかも「なんか信用できない」って激しく感覚的だな。

179 ：デフォルトの名無しさん：03/07/22 11:29

で、どうなのよ。本当に大手企業でも設計ミスしてないのか？本当は全部のプロジェクトで設計ミスは必ず１つはあｒんじゃないのか

180 ：　：03/07/22 12:37

コンポーネントオブジェクトモデルとかインタフェイス志向のプログラムでは、
あるコンポーネントへの参照（あるいはインタフェイス）については「参照が
存在する」間は寿命が継続する、ということにしとかないとクライアント側が
いちいち実装についての知識を持つ必要があって面倒なわけで、そういったも
のを使うときはスマートポインタの類は便利だと思う。ダイナミックに委譲先
が生成・消滅する場合なんかもあるし。

181 ：デフォルトの名無しさん：03/07/22 12:40

設計ミスと言うより
設計当時の技術力の
限界といった方がいいね。

182 ：デフォルトの名無しさん：03/07/22 12:42

設計ミスねぇ

C++の言語仕様そのものが設計ミスだと思うけど

183 ：デフォルトの名無しさん：03/07/22 12:45

C++の設計は時代に合わない。

184 ：デフォルトの名無しさん：03/07/22 12:54

スマートポインタが無いと、インスタンスをnewしたブロックで
例外を吐きうる関数とか呼んだりする時、極めてめんどくさいんですが。

185 ：デフォルトの名無しさん：03/07/22 13:09

ＧＣがあれば簡単に解決するのにね。
やっぱりC++は設計が腐ってるよ。

186 ：デフォルトの名無しさん：03/07/22 13:10

ガベコレを仕様に含めたC++<<<<<<<<<<<<<<<<<<<<<<<<<<<<Java
ガベコレを仕様に含めたC++<<<<<<<<<<<<<<<<<<<<<<<<<<<<今のC++
Java⊥C++

187 ：デフォルトの名無しさん：03/07/22 13:25

>>185
そのうち追加されるんじゃねぇの、16ビット時代の far near のように属性でもつけりゃ上位互換で拡張はできるし、
Microsoft 流に class に属性つけてもいいし、やり方はいくらでもあるし
個人的には細かめの機能で template を使って実装、小細工をユーザー側でてきるようなのがいいな。

188 ：デフォルトの名無しさん：03/07/22 13:32

追加されてもM$は絶対に無視するだろうなぁ

189 ：デフォルトの名無しさん：03/07/22 13:34

メモリ以外のリソースを掴むオブジェクトを扱う時は非同期ガベコレは会わない気が

190 ：デフォルトの名無しさん：03/07/22 14:08

ガベコレはメモリを扱うものですよ。
それ以外のリソースは関係ありません。

それ以外のリソースは今まで通りで、
メモリに対してアドバンテージがあるのです。

191 ：デフォルトの名無しさん：03/07/22 14:56

直感的にだが、デストラクタとガーベジコレクタって
共存させると、極めて煩雑になりそうな気がする...

192 ：デフォルトの名無しさん：03/07/22 15:07

>>190
リソースじゃなくてリソースを掴むオブジェクトの話だろ
ガベコレでオブジェクトが破棄されればそれが持ってるリソースも同時に開放されるだろ

193 ：デフォルトの名無しさん：03/07/22 15:54

まあ、M$的にはC♭移行を推奨して終了だろう。

194 ：デフォルトの名無しさん：03/07/22 17:00

C++の欠点はオブジェクトの管理よりテキストベースの#includeだと思うがどうよ。
privateなメンバを変更するだけで参照しているプログラム全部コンパイルしなおすのはかなり嫌だ。
実装をさらけ出したうえ、１メソッド=１機能にしようにも複数のメソッドに分割すればするほど再コンパイルの可能性が上がるし。
pImplイディオムとかしょうも無いことやら無きゃいけなくなる・・・

195 ：デフォルトの名無しさん：03/07/22 17:10

そんなあなたにD言語

と言いたくなるんだけど、正直Dってどうよ？

196 ：デフォルトの名無しさん：03/07/22 18:10

>>1
「げんあり」ってなに？

197 ：デフォルトの名無しさん：03/07/22 18:48

まだ知らない人もいるみたいなんで、これ貼っておきますね

Bjarne Stroustrup Interview about C++
http://hp.vector.co.jp/authors/VA000092/jokes/strup.html

198 ：デフォルトの名無しさん：03/07/22 18:49

197=最近知って嬉々として貼り付けてます

199 ：デフォルトの名無しさん：03/07/22 18:56

C++が難しいんじゃない
VC++が糞なだけだ

200 ：デフォルトの名無しさん：03/07/22 19:04

VC++のクソな原因をあげたら
それはC++がクソなせいというオチ

201 ：デフォルトの名無しさん：03/07/22 19:05

VC++が糞なのはMFCが糞だからだ

202 ：デフォルトの名無しさん：03/07/22 19:06

>>192
でも、ぼくはガーベジコレクションが走るまでリソースを確保しっぱなしに、なんてできないんです。

203 ：デフォルトの名無しさん：03/07/22 19:10

BCBはうんこしないよ

204 ：デフォルトの名無しさん：03/07/22 19:15

>>194
いまさらincludeを無くすという訳にもいかんだろうし、やるとしたら
プリコンパイルヘッダの規格化が良いと思う。

205 ：デフォルトの名無しさん：03/07/22 19:53

>>194
ヘッダファイルまとめてインクルードしてない？

206 ：あぼーん：あぼーん

あぼーん

207 ：デフォルトの名無しさん：03/07/22 19:55

今更っぽいけど、「スマートポインタが必要な時点で設計ミス」
というのは結構賛成。本当の意味で、対等に共有されている
オブジェクトというのも存在するけど、基本的には、オブジェクトが
誰の下請けとして動いていて、誰と心中すべきかということは
はっきりしているでしょ。意味論的に死ぬべきオブジェクトが、
間違って参照されていて、たまたまそれで動いていても、
それはバグであって、GCがあると単に落ちないだけ。
だから、auto_ptrは使うけど、shared_ptrとなると、vectorに
突っ込む場合に使う程度で、積極的に使うことはほとんど無かったり。

208 ：デフォルトの名無しさん：03/07/22 19:58

>>207
激しく同意

209 ：デフォルトの名無しさん：03/07/22 19:59

>>203
BCBってあのC++にはない拡張構文をふんだん使ったあれ？
完全C++ライブラリのOWLが死んで、
C++に(ついでにobject pascalにも)ないclosureという
デリゲートもどきプロパティもどきやAnsiStringを使いまくった
VCLが生き残っているのは皮肉だな。

結論、C++はクソ

210 ：デフォルトの名無しさん：03/07/22 20:01

>>207
そんな所有関係がはっきりしているような状況はそもそも話題にもなりゃしないだろ。
あくまでオブジェクト同士が対等の場合の話に限るべき。

211 ：デフォルトの名無しさん：03/07/22 20:03

開店セール見に来てーーーーーーーーーー！DVDを見ようー！GO！
▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼
開店セール1枚　500円より→→→http://www.dvd-exp.com　
アダルトDVDが激安販売→→→http://www.dvd-exp.com　
アダルトDVDの価格はなーんと1枚900円→→→http://www.dvd-exp.com　
最短でご注文いただいた翌日にお届け！→→→http://www.dvd-exp.com　
セルビデオ店の人気商品が24時間お買い物が出来ます。
　　　　　　　　時間をかけてゆっくり選んでください！
　　　　　　　　　　http://www.dvd-exp.com←へGO！
　　　　　　　　　　　DVDエクスプレス

212 ：デフォルトの名無しさん：03/07/22 20:11

スマートポインタがあると、単純に可読性があがるのでいいと思うんだが。
(宣言すると同時にスコープをはずれた瞬間、破棄されることが保証される)

shared_ptrでいまいち寿命がはっきりしないケースというのは、
設計上、特に注意すべきポイントだとは思う(単純にスマートポインタを
つかえばすべての問題が解決するわけではない)が、設計ミスとは
いえないと思う。

213 ：デフォルトの名無しさん：03/07/22 20:17

>>212
可読性はあがんねーだろ？
現状、Boost知らない奴のが多いんだから。

214 ：デフォルトの名無しさん：03/07/22 20:18

C++厨って技術先行型だね。
用途は無視してとりあえず作ってみました。
使ってね。って感じ。

「Longhornではインドウがグニャグニャ動いてすごいだろ。」
「それをなんに使うの？」
「・・・」
と同じ感じがする。

215 ：デフォルトの名無しさん：03/07/22 20:19

生成したらキッチリどこで削除されるのか把握するのがプログラマだろが。smartpointerなんか使うな。デフォルトのポインタで勝負しろ。

216 ：デフォルトの名無しさん：03/07/22 20:19

なんかもう自作自演が始まってるから相手にしないほうがいいよ

217 ：デフォルトの名無しさん：03/07/22 20:23

>>214
ダブルバッファリングになって3Dアクセラレータが使えるようになっただけだっけ？
凝ったことするとゲーム屋ご用達になるけど基本は変わらないでしょ？
GUIまわりだけ？

218 ：デフォルトの名無しさん：03/07/22 20:50

こんな煽りスレが勢いよく伸びていること。
その一方で、C++相談室は、荒れもせずもくもくと進んでいること。
この2つを見ただけで、C++という言語の性質がわかるような気がする。

219 ：デフォルトの名無しさん：03/07/22 20:55

>>215
GCでは使用されなくなったらGCが起動した時点で削除されます。

あなたはどこで削除されるのか分からないのですか？
GCぐらい使いこなしましょう。

220 ：デフォルトの名無しさん：03/07/22 21:01

>>219
アホか。ＧＣにたよらないとリーク起こすようなプログラムを書く詰めが甘い奴はプログラマ辞めろってこと。

221 ：デフォルトの名無しさん：03/07/22 21:05

対等のオブジェクトの相互参照をGCを使わずスマートかつエレガントに実装してみてくれ。

222 ：デフォルトの名無しさん：03/07/22 21:12

>>221
散々でている参照共有スマートポインタがそれなのでは？

223 ：デフォルトの名無しさん：03/07/22 21:16

>>220
えぇそういうプログラマは辞めたほうがいいですね。
同時にGCの便利さが分からないプログラマも辞めたほうがいいです。

ちなみに私はGCに頼らなくてもリークを起こさないプログラムを書けて
GCの便利さを認めています。

もしかしてあなたはプログラマ失格者ですか？

224 ：デフォルトの名無しさん：03/07/22 21:17

>>222
あれじゃスマートかつエレガントに実装できない。

225 ：デフォルトの名無しさん：03/07/22 21:17

>>222
ゴメン、参照共有スマートポインタってなに？

226 ：デフォルトの名無しさん：03/07/22 21:19

>>221
対等のオブジェクト同士を無理に関連づけようとするからうまくいかないんだよ。
上の方でだれかがいってた、一つ上に管理クラスを用意する方法が一番綺麗じゃないかな？

227 ：デフォルトの名無しさん：03/07/22 21:20

それがガベージコレクタじゃねーの？

228 ：デフォルトの名無しさん：03/07/22 21:28

>>225
誰もアクセスしなくなったあるオブジェクトを自動的に削除するために
そのあるオブジェクトを生成すると同時に削除用オブジェクトを生成する、
そこには参照カウンタなるものがあって、参照する人が一個増えたらカウントアップ
減ったらカウントダウン、でカンウタが 0 になったら、そのあるオブジェクトを削除して
削除用も自滅するって感じかな。
= オペレータをオーバーロードして、ポインタがコピーされたときに参照カンウタをいじくる仕掛け。
-> オペレータもオーバーロードしてあって、見掛けは普通のポインタ。
Pythonの簡易ガベコレの実装がそうだって聞いているけど詳しいことは知らない。
完全にメモリーリークを防げないのでガベコレとは言えないかも。

229 ：デフォルトの名無しさん：03/07/22 21:29

対等のオブジェクトの相互参照？
class unko
{
public:
unko* p;
};
unko* u1,*u2;
u1=new unko();
u2=*u1;
u1->p=u2;
u2->p=u1;
ってこと？

230 ：デフォルトの名無しさん：03/07/22 21:31

メモリリークなんてVCにみつけてもらってるよ

231 ：デフォルトの名無しさん：03/07/22 21:33

>>230
サンクス。一つ賢くなった。

232 ：231==225：03/07/22 21:34

(;´Д｀)誤爆
>>230×
>>228○

233 ：229：03/07/22 21:34

まちがった。

234 ：デフォルトの名無しさん：03/07/22 22:09

デリートすんのめんどいからshared_prtr
でもいくらめんどうでも、ＧＣはどうだろう？
パフォーマンスにそれほど影響なければ入れてくれ。

235 ：230：03/07/22 22:09

>>231
まちがってなーい！
なに×つけてんだゴルァ！

236 ：デフォルトの名無しさん：03/07/22 22:12

★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★
☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆
★☆　　　　　　　　　　　　　　　　　　　　　　　
☆★　送料激安！！　　送料激安！！　　送料激安！！
★☆　　　　　　http://www.get-dvd.com　　　　　　
☆★　　激安アダルトＤＶＤショップ　　　　　　　　
★☆　　　　お買い得セール1枚500円～980円！急げ！
☆★　　　　インターネット初！「きたぐに割引」　　
★☆　　　　北海道・東北の皆様は送料も激安！　　　
☆★　　　　　　http://www.get-dvd.com　　　　　　
★☆　　　　　　　　スピード発送！　　　　　　　　
☆★　　　　　　http://www.get-dvd.com　　　　　　
★☆　　　　　　　　商品が豊富！　　　　　　　　　
☆★　　　　　　http://www.get-dvd.com　　　　　　
★☆　　　　　　　　　　　　　　　　　　　　　　　
☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆

237 ：デフォルトの名無しさん：03/07/22 22:17

もしかして236みたいな奴ってあるタイミングで一番上にあったスレに自動で貼られるのか？

238 ：デフォルトの名無しさん：03/07/22 22:24

>>36
> アメリカのアホーにも載ってない言語誰が使うかと。
> ネタにマジレス。
JavaがだめになったらC#に移行するという考え方が現実的でない
ということだろ。だめになったらむしろC++かD言語に移ったほうが
特定環境への依存度を控えめにすることができるってことだろ。

どこかに知られている知られていないを基準にして受動的に言語を選ぶなよ。

>>48
>Java も C# も D も上っ面は似てるけど、対応分野が違うし、
>(特にJavaは次世代COBOLの座が確定状態な上に
これは悪い意味で言っているのか良い意味で言っているのか激しくよくわからん。
「COBOLのシェアを奪う」ので良い意味なのか、
「COBOLと同じようにスパゲティコード吐きまくって
嫌われる言語になる(おれにはとてもそうは思えん。
それだったらC++のほうがよっぽど嫌われやすい)」びで悪い意味なのか
よくわからん。

239 ：デフォルトの名無しさん：03/07/22 22:25

>GenericsがあれではC++で培われたテクニックが何も使えん)
JavaでGenericsを使うにはCollection系の型キャストの問題を
解決できれば十分で、それ以上のスパゲティ化につながる
C++独自のtemplateのテクニックの必要性を感じないと思うがどうよ。

10年経ったら「Javaは遅い」ともさすがに思わないだろうし
C++の必要性も、ソースコードを汚してまで
細かいポインタ演算や細かいメモリ管理をしてまで使うことも少なくなり
淘汰されると思うが。

うーむ、これはC++信者に対する煽りなのだろうか？
それでもJavaの速度に不満があるなら(10年計画で)独自のJavaChipを自作するなり
C/C++/アセンブラなどを使ってJVMを独自に改造するなりしてパフォーマンスをあげてみるのがいいんじゃないかな。

これからのプログラムは、各CPUにあわせてその場でコンパイルして実行する形式
になる、それでいいんじゃないかと。

240 ：デフォルトの名無しさん：03/07/22 22:25

>>105
> >>104
> 言語以外にも学習すべきことは山ほどあるので、まだお楽しみは続く。
> UML2.0とか。
UMLは使うだけなら「学ぶ」ほどのものではないと思われ。
しかしUMLの資格試験を取るなら学ぶしかない。

241 ：デフォルトの名無しさん：03/07/22 22:25

>>108
同感。C++の余計な機能はおまけとして学んでおいて
Javaでもできることもちゃんと学べよ。

242 ：デフォルトの名無しさん：03/07/22 22:25

>>98
結城浩の「デザインパターン」本のほうが
オブジェクト指向を素早く理解できそうな気がするが。

243 ：デフォルトの名無しさん：03/07/22 22:26

>>114
> C++ にとってのオブジェクト指向っていうのは、使える方法論の一つに過ぎないんです。
その「オブジェクト指向」による再利用性、拡張性、移植性を無視した
C++プログラマがわんんさかいて後継者が大変な思いをしているんだよ。

244 ：デフォルトの名無しさん：03/07/22 22:28

10年たってもクライアントサイドでのJavaのシェアはきわめて0に近い悪寒
速度以前に改善すべき点があるんじゃないのか？

245 ：デフォルトの名無しさん：03/07/22 22:35

>>218
> こんな煽りスレが勢いよく伸びていること。
> その一方で、C++相談室は、荒れもせずもくもくと進んでいること。
> この2つを見ただけで、C++という言語の性質がわかるような気がする。
どういう性質なのかあなたの意見を聞いてみたい。
おながいしますわ

246 ：デフォルトの名無しさん：03/07/22 22:36

>>244
> 10年たってもクライアントサイドでのJavaのシェアはきわめて0に近い悪寒
> 速度以前に改善すべき点があるんじゃないのか？
じゃ、D言語を普及させておくれよあんた。
C#なんかに乗せられたくないし。

247 ：デフォルトの名無しさん：03/07/22 22:36

>>188
> 追加されてもM$は絶対に無視するだろうなぁ
M$の流れに合わせる必要があんのかと小一時間
M$に自分の将来を左右される必要があるのかと小一時間

248 ：デフォルトの名無しさん：03/07/22 22:38

このスレでわからない単語
template
スマートポインタ
GC
STL
Generic programming
...

おまいら日本語しゃべってください

249 ：デフォルトの名無しさん：03/07/22 22:43

>>248
マジレスすると、無視しても何の問題もないよ。

250 ：デフォルトの名無しさん：03/07/22 22:43

>>244
> 10年たってもクライアントサイドでのJavaのシェアはきわめて0に近い悪寒
JavaWebStartで自動ダウンロード、自動インストールが売りだと思う。
J2EEと連動しないと動かないクライアントサイドJavaプログラムを
作ってしまえば普及するかな。かえって普及しなくなるかな。

> 速度以前に改善すべき点があるんじゃないのか？
しかし、これは釣りか？
実際シェア0ってことがあるのかと問い詰めてみたいものじゃ。

改善すべき点と何かね？ C#厨がJavaと比較してC#の宣伝に使っている
あの中途半端な変な機能をJavaに追加するんならばC++やったほうがいい
ともいえるが、そういうものでもないかね？

それとも、JavaはもっとSmalltalkライクな言語にすべきかね？

251 ：デフォルトの名無しさん：03/07/22 22:43

>>248
日本語に翻訳したらかえって分かり辛くなる気がする

252 ：デフォルトの名無しさん：03/07/22 22:45

>>243
C++にもクラスライブラリーを揃えてOOをしようという動きはあったんだが、
とこが、STLをみて考えが変わってそのライブラリーは捨てられ、そしてSTLが標準になって今に至ったんだと。
C++でクラスライブラリーを作っても使い物にならないという結論となった。

っていう話を聞いたことがある。

253 ：デフォルトの名無しさん：03/07/22 22:46

>>195
> そんなあなたにD言語
> と言いたくなるんだけど、正直Dってどうよ？
C++やJavaがだめになったらC#に以降だなんて最悪。
M$に左右されてversion upするたびにソースコードを無駄に改変する手間は
かけたくない。そんなときD言語に期待。

254 ：デフォルトの名無しさん：03/07/22 22:49

>>252
標準に仮想デストラクタを持った基本クラスを決めてくれてれば
いろんなところが便利になったんじゃないかと思う。

255 ：デフォルトの名無しさん：03/07/22 22:51

C#やJavaよりCやC++のほうが超絶に簡単だと思うんだが・・・。
色々な情報に惑わされてねーか。
あとC++とC#とJavaでは用途が違うんでねーか・・・。

256 ：デフォルトの名無しさん：03/07/22 22:52

>>248
検索するしかないのう。
Javaに関連があるものはtamplateが少し、
GC(ゴミ収集車)がおもいっきり(しかし自動なので意識する必要性がほとんどない)、
STLがtemplate周りで少し(JavaのCollection系ライブラリにも追加されんのかね?)
Generic Programmingが時期Javaでおもいっきり。

スマートポインタ？　こんなのしか知らん。
http://www.panasonic.co.jp/pc/prod/note/l1es/spointer3.html

こんなサイトを見つけた。
スマートポインタの落とし穴
http://www9.plala.or.jp/dequartet/new_page_4.htm

スマートポインタ
ポインタ編のおまけとして、スマートポインタについて解説します。
スマートポインタは例外処理やＪａｖａの存在で、必要不可欠な存在にな
りつつあると思います。まだよく知らないという方のための簡単な解説ということで。
http://www.kab-studio.com/Programing/Codian/Pointer/12.html

よく見るとスマートポインタはJavaの常識だすのう。
しかし「スマートポインタ」は死語にみえてしまうのでおじゃる。

257 ：デフォルトの名無しさん：03/07/22 22:54

>>255
初心者がC/C++の本を読んだら、実際に動かしたときに
ポインタ演算のところとエラーメッセージのわかりにくさと
バッファオーバフローの判別のしにくさなどで
ひるんでしまいそうだが。

258 ：デフォルトの名無しさん：03/07/22 22:55

>>255
「マイクロ」が付く2つの会社にだまされているのですか？

259 ：デフォルトの名無しさん：03/07/22 22:58

C++はさぁ、
一番最初に

#include ...
#include ... // この辺は簡単に理解できる

using namespace std; // まったく理解不能

int main() // Cで関数の知識が無いと理解不能
{
　cout << "Hello World!" << endl; // いきなり行儀の悪い演算子オーバーロード、まったく理解不能。
　　　　　　　　　　　　　　　　　　// しかもまともな説明なしであっさり通り過ぎる
}

拒絶反応起こすって

260 ：デフォルトの名無しさん：03/07/22 22:59

>>255
JavaやC#の利点はObjectクラスの存在だと思うわけよ。
すべてのクラスの頂点（親クラス、基底クラス、スーパークラス）は
森羅万象を構成するObjectクラスなのさ。

しかし使い方を誤るとVBのバリアントやperlの型の曖昧さのように
恐ろしいものになる諸刃の剣。しかしこれも次期JavaのGenericsで解決。
C#も時期に解決するらしい。

261 ：デフォルトの名無しさん：03/07/22 23:01

>>259
別にK&RのHello Worldでいいじゃん、C++なのだから stdio.h を使っていけない理由はない。
むしろ最初は便利なCで勉強するのが正しい。
ついでその main は C++としては間違っている。

262 ：デフォルトの名無しさん：03/07/22 23:05

>>259
> C++はさぁ、
> 一番最初に
>
> #include ...
> #include ... // この辺は簡単に理解できる
>
> using namespace std; // まったく理解不能

import javax.servlet.*;
import org.jakarta.....
.とか出たら同じように最初は誰でも混乱すると思うがどうよ？

> int main() // Cで関数の知識が無いと理解不能

JavaやC#にもおまじないのように
public class { public static void main(String[] args)
とある（C#は若干異なる）んだから
おんなじだとおもうんじゃが。
しかし return 0 や getchar() は初心者には理解不能だと思う。

> {
> 　cout << "Hello World!" << endl; // いきなり行儀の悪い演算子オーバーロード、まったく理解不能。

しかし、これはつかわずprintf()やputs()をつかっちゃえばいいじゃん？
と思うがどうよ？
C++の書籍にはたいていこういうのが載っているけどさ。

263 ：259：03/07/22 23:08

>>261
え゛っどっか間違ってた？

264 ：デフォルトの名無しさん：03/07/22 23:08

STLなんて思いついたときに使えばいい、クラスもなんも知らないうちから
そんなもん持ち出すな、っていうか教本が悪いんだけどな・・・。

265 ：デフォルトの名無しさん：03/07/22 23:11

C++は急ぎすぎる教本が多いのは確かだな

266 ：デフォルトの名無しさん：03/07/22 23:12

CやC++でわからなくてJavaやC#ならわかるのかよ・・・。
どうせファンクションキーでも押してヘルプ読むんだろ。

267 ：デフォルトの名無しさん：03/07/22 23:14

>>262
import java.lang.*;
とか
using System;
とかならまだわかりやすいんだよ。
問題はnamespace。
慣れればなんてこと無いけど、はじめは何じゃそりゃって感じ。

268 ：デフォルトの名無しさん：03/07/22 23:17

namespaceなんぞ知らなくてもC++のプログラムは書ける。
つーか、.NETにもnamespaceあるんじゃねーの？

269 ：デフォルトの名無しさん：03/07/22 23:19

>>268
using namespace std;
　　　　↑このnamespaceのことのつもり

270 ：デフォルトの名無しさん：03/07/22 23:21

>>269
そんなものが気になるのはあんただけだと思うよ(汗
知らない人なら、一個増えても変わらない。

271 ：デフォルトの名無しさん：03/07/22 23:21

えー、じゃあ using std; なら納得すんの？

272 ：デフォルトの名無しさん：03/07/22 23:24

>>267
Javaではnamespaceの代わりにキーワードにpackageを使用し、
UMLでもJavaに習ってpackageという用語を使っているのもかかわらず

C#はJavaより後発でありながらなぜかいまだにnamespaceというキーワードを
使っているようじゃ。

M$はあれでC++プログラマをJavaではなくなんとか
C#にひきつけようとしたつもりだったんだろうか。

それともXMLの "名前空間" の真似でもしてるんだろうか？

俺もC++の本を読んでnamespaceの項を読んでみたら
クラススコープの外側にnamespaceというスコープによる厨括弧がついて
なんじゃこりゃ？

っておもった。確かにJavaのpackageのほうがわかりやすい。
ひとつのディレクトリ==ひとつのpackageとし、
ひとつのファイル内には二つ以上のpackage宣言をつけることを禁止し、
package宣言はそのファイル内になるすべてのクラスに適用されるという
すっきりきれいさっぱりしたJavaの発想（元がJavaの発想?）はわかりやすい。

namespaceは変な使い方をすると括弧の数が増えて混乱するといえば混乱しちまいますな。
いくらJavaより制限をゆるくしたといっても反ってソースコードを汚しちまいかねないな。

273 ：デフォルトの名無しさん：03/07/22 23:25

using std;
だとstdという名前の機能を使う、っていう風に解釈して（正確ではないが）自分を納得させられる。

おまじないって、よく、できる奴が出来ない奴に教えるときに使うけど、
教えられてる側からすると流れがつかめなくなってかえって混乱することもある。

274 ：デフォルトの名無しさん：03/07/22 23:33

C#もnamespace は中括弧囲ってあるが別に読みにくくはないよ。
馴れのせいだと思う

275 ：デフォルトの名無しさん：03/07/22 23:34

なんだ、あれか、言語の完成度や数学的な芸術性を求めてるわけか？

276 ：デフォルトの名無しさん：03/07/22 23:34

あああああああああああああああああああああああああああ

277 ：デフォルトの名無しさん：03/07/22 23:38

あ～あ
火病になった、荒らすなよ(藁

278 ：無料動画直リン：03/07/22 23:38

http://homepage.mac.com/miku24/

279 ：デフォルトの名無しさん：03/07/23 00:26

>namespaceは変な使い方をすると括弧の数が増えて混乱するといえば混乱しちまいますな。

いいかい。最初から最後まで、括弧の数は増やしちゃいけないんだよ。
小学校でそう教わらなかったかい？
おまえみたいな奴は、namespaceとか言う前に、ループだのifだので
ふかーいインデント出しまくりなんだろ。
おまえみたいなド素人がコードを書くから混乱するんだよ。

280 ：　：03/07/23 02:34

>>261
>別にK&RのHello Worldでいいじゃん、C++なのだから stdio.h を使っていけない理由はない。

cstdio じゃない？

281 ：48：03/07/23 02:44

>>238
>>Java も C# も D も上っ面は似てるけど、対応分野が違うし、
>>(特にJavaは次世代COBOLの座が確定状態な上に
>これは悪い意味で言っているのか
YES, 存在意義上、馬鹿を受け入れる言語(COBOL, VB の仲間)にならざるを得ない…
……とこのスレを見てるとJavaはもう馬鹿を受け入れてるみたいだが。

>>239
>>GenericsがあれではC++で培われたテクニックが何も使えん)
>JavaでGenericsを使うにはCollection系の型キャストの問題を
>解決できれば十分で、それ以上のスパゲティ化につながる
>C++独自のtemplateのテクニックの必要性を感じないと思うがどうよ。
知らないことを全て否定するな。GenericsはGeneric Programmingはできても
その先ができない。その先はスパゲッティだという根拠を示して！
(示してくれないと、スパゲッティになってるのは、未知の存在に怯える君の思考だっていう結論に達するよ)

>C++の必要性も、ソースコードを汚してまで
>細かいポインタ演算や細かいメモリ管理をしてまで使うことも少なくなり
>淘汰されると思うが。
ネイティブ吐ける言語は何か一つは必要。これからはCとC++の親子ガチ勝負がはじまる予感。
この試合は長引けば長引くほどC++有利になるからCは早期決戦で勝つしかない。

>独自のJavaChipを自作するなり
Java成立当初の話とか知らない？結局 JVM ネイティブなチップは性能上不利って結論。
「バイトコードの仕様」っていう足枷があるかぎりそうじゃないチップに絶対に勝てない。

282 ：実は48==114：03/07/23 02:52

>>242
>> C++ にとってのオブジェクト指向っていうのは、使える方法論の一つに過ぎないんです。
>その「オブジェクト指向」による再利用性、拡張性、移植性を無視した
>C++プログラマがわんんさかいて後継者が大変な思いをしているんだよ。
君、後継者なんでしょ？多分立場は俺と同じ。「君がやるんだよ。」
もしかして３０前後の人達にOOのスペシャリストである事を期待してる？
無理無理。みんなCで入って、C++使い始めた人達で、この人たちが
Cしか認めんっていう人達と戦ってくれたから、今の俺たちの土俵があるんだよ。
次は俺たちがやる番。
そうそう、たしかにこの世代の人達ってSTLに対しては妙に興味津々だったりするね。
で、OOのテクニックが未熟なままGeneric Programming先行してたりするのが許せないのかな？
どちらにしても、俺たちが変えなきゃ変わらないし、
別にテンプレートのテクニックが悪いわけじゃない。時代と環境が違うだけなんだ。
戦う相手を間違っちゃいけないよ！！

283 ：デフォルトの名無しさん：03/07/23 09:37

本質的な相違はライブラリに関する価値観でしょ。
C++ではライブラリは常に一から書き直してナンボという立場をとる。
Javaではその対極で一度書かれたライブラリは書き直される必要など無い
という考え方をとる。

284 ：デフォルトの名無しさん：03/07/23 12:20

>>279
> >namespaceは変な使い方をすると括弧の数が増えて混乱するといえば混乱しちまいますな。
>
> いいかい。最初から最後まで、括弧の数は増やしちゃいけないんだよ。
> 小学校でそう教わらなかったかい？
> おまえみたいな奴は、namespaceとか言う前に、ループだのifだので
> ふかーいインデント出しまくりなんだろ。
> おまえみたいなド素人がコードを書くから混乱するんだよ。
それをいうならC#を作ったマイクロソフトに言えド素人。
俺様はStateパターンなどを使って無駄なインデントを極力減らす努力を
怠っちゃいねえんだよオブジェクト指向のド素人が。

285 ：デフォルトの名無しさん：03/07/23 13:51

C++が腐っているせいで
long longなんてネタみたいな
型が出来てしまった（ｗ

286 ：デフォルトの名無しさん：03/07/23 14:31

> Javaではその対極で一度書かれたライブラリは書き直される必要など無い
> という考え方をとる。

java.nio

これは何だ！正直に父さんにいってみなさい！

287 ：デフォルトの名無しさん：03/07/23 14:34

＞Stateパターンなどを使って無駄なインデントを極力減らす努力

OO ってインデントを浅くするためのテクニックだったのか
知らなかった。

288 ：デフォルトの名無しさん：03/07/23 14:36

C#のnamespaceは入れ子にする必要が無いからカッコは最大でも1個しか増えないぞ

289 ：デフォルトの名無しさん：03/07/23 14:36

ダブルディスパッチって何のためにする必要があるの？

290 ：デフォルトの名無しさん：03/07/23 14:40

>>288
オブジェクト指向を使って少しでもインデントを減らす努力を日々怠っていない
Java の達人達にとってはその1個も許せないみたいだよ。
一緒にJavaのオブジェクト指向の達人とは一緒に仕事したくないね。

291 ：デフォルトの名無しさん：03/07/23 14:41

>>289
馬鹿には読めないコードを作るため

292 ：デフォルトの名無しさん：03/07/23 14:42

Stateパターンなんて無駄な派生クラスが増えるだけ

293 ：デフォルトの名無しさん：03/07/23 14:57

まだやってたのかこのスレは？
学生っぽい能書きが多くてうざったくね？
C++が難しいなら、できる人を雇ってもらえよ。
じゃなきゃ外注にだせ。

294 ：デフォルトの名無しさん：03/07/23 15:43

Stateパターンってどこが状態遷移の管理すんの？
どうもそこらへんがめんどーなんだけど。

295 ：デフォルトの名無しさん：03/07/23 15:50

>>293
外注→害虫

296 ：デフォルトの名無しさん：03/07/23 16:19

>>287
お！それいいな。
そんで、構造化プログラミングがインデントを深くするための方法？

意外とただしいかも。

297 ：デフォルトの名無しさん：03/07/23 16:32

で、おすすめの書籍は？

298 ：デフォルトの名無しさん：03/07/23 16:35

>>297
断然モダC++なわけだが何か？

299 ：デフォルトの名無しさん：03/07/23 17:40

http://www.genpaku.org/realprogrammerj.html
>本物のプログラマは構造化プログラミングを共産主義者の陰謀だと考えている

300 ：デフォルトの名無しさん：03/07/23 17:46

>>281
> >>238
> >>Java も C# も D も上っ面は似てるけど、対応分野が違うし、
> >>(特にJavaは次世代COBOLの座が確定状態な上に
> >これは悪い意味で言っているのか
> YES, 存在意義上、馬鹿を受け入れる言語(COBOL, VB の仲間)にならざるを得ない…
> ……とこのスレを見てるとJavaはもう馬鹿を受け入れてるみたいだが。
しかしだな。C++はポインタ演算馬鹿を受け入れる以上悪い意味でCOBOL同様
嫌われる存在にならざるを得ない。
……とこのスレを見てると抵抗勢力C++はもうスパゲティ馬鹿を受け入れてるみたいだが。

301 ：デフォルトの名無しさん：03/07/23 17:49

C++プログラマはニクソン大統領みたいなものだ。

ニクソンのせいでその後の大統領が大変な後始末を強いられるわけだ。
迷惑としか言いようがない。

302 ：デフォルトの名無しさん：03/07/23 17:58

> C++はポインタ演算馬鹿を受け入れる
受け入れてません。それはC親父です。

とこのスレを見てると C++ を理解できなかったかわいそうな人は分身の術とか使えるみたいだが

303 ：デフォルトの名無しさん：03/07/23 18:05

>>302
> > C++はポインタ演算馬鹿を受け入れる
> 受け入れてません。それはC親父です。
アホですか。受け入れることができるように設計されているわけだが。
C#もな。

304 ：デフォルトの名無しさん：03/07/23 18:06

C++はOSやVM生成専用言語で十分。
それ以外の用途に何が何でもC++を使いたいという香具師は
もはや時代遅れ。

305 ：10年後の現実：03/07/23 18:10

Javaは事務処理専用言語で十分。
それ以外の用途に何が何でもJavaを使いたいという香具師は
もはや時代遅れ。

306 ：デフォルトの名無しさん：03/07/23 18:11

> アホですか。受け入れることができるように設計されているわけだが。
> C#もな。
構文糖衣厨キター

307 ：デフォルトの名無しさん：03/07/23 18:14

JavaはC++で作られています

308 ：デフォルトの名無しさん：03/07/23 18:23

そう思っていたい>>304なのでした

309 ：バファリンのCMより：03/07/23 18:27

バッファの半分は領域破壊チェックの為に確保されています。

310 ：デフォルトの名無しさん：03/07/23 18:34

>>309
座布団。

311 ：309(庶民派高級風レストランチェーン)：03/07/23 18:38

>>310
貰えるの？抜かれるの？

312 ：デフォルトの名無しさん：03/07/23 19:29

C++普通に使うにはそんな糞でもないでしょ。
ただ人が書いたのを何とかする時に面倒なだけで。

313 ：詩想：03/07/23 19:31

http://floatin-web.hp.infoseek.co.jp/sisou.shtml
俺のHPだ、カッコイイだろ、イカスだろ、ナイスだろ
お前ら雑魚のHPとは大違いだろ
俺は今からお前らｵﾀｯｷｰ2chネラー全員に県下を挑む
俺のHPの特に掲示板あたりをあらせるもんなら荒らしてみろ
荒らせないで、「めんどい」「厨だな」とかいったら負け犬とみなす
悔しかったら荒らしてみろや、一人じゃあ何も出来ない2chネラー諸君
このことは2chネラー同士でどんどんうわさながしていいよ
お前らオタクが何人でかかってこようとも俺には勝てないってことを教えてやるさ
ｷﾞｬﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊﾊ
ﾌﾟ
せいぜ、負け犬なりにがんばりな
荒らせたら土下座してあやまってやらぁ
ﾌﾟ

314 ：デフォルトの名無しさん：03/07/23 19:53

どの言語もアホが書くと最悪。それとGCいらん、負の発明、悪の枢軸。
デバッグしながら編集できないVB.NETはいらん、VB6のほうがマシ。
C++はCの文法で書きつつ必要なときにクラス使う程度が便利。

315 ：デフォルトの名無しさん：03/07/23 20:57

>デバッグしながら編集
こういう事やってる時点でショボイプログラマ確定

316 ：デフォルトの名無しさん：03/07/23 22:31

>>302
ポインタにやけに恨みがあるようだがC++はポインタを明らかに受け入れているよ、受け入れられないのは
あ・な・た

なんで最近になって int32_t といったポインタ演算をする為だけといって過言で無いサイズ固定化した型をわざわざ規格化したか解るか？
必要なんだよ、ポインタ演算は。

317 ：デフォルトの名無しさん：03/07/23 22:34

>なんで最近になって int32_t といったポインタ演算をする為だけといって過言で無いサイズ固定化した型をわざわざ規格化したか解るか？

はぁ？コイツは馬鹿ですか？

318 ：デフォルトの名無しさん：03/07/23 22:38

「C++ は習得コストがむちゃくちゃ高い」のは真だと思うが、
「C++ の開発コストがむちゃくちゃ高い」のは偽だと思う。

C++ に対する毀誉褒貶は、「むちゃくちゃ高い習得コスト」を払ってしまった人か、
そうでない人かでわかれる気がするんだけど、どうだろう？

319 ：デフォルトの名無しさん：03/07/23 22:38

>>316
> なんで最近になって int32_t といったポインタ演算をする為だけといって過言で無いサイズ固定化した型をわざわざ規格化したか解るか？
そいつは標準Cだし。規格上は標準C++じゃ使えないし。
ポインタ用なのはそれじゃなくてintptr_tとuintptr_tだし。

320 ：デフォルトの名無しさん：03/07/23 22:42

>>318
> C++ に対する毀誉褒貶は、「むちゃくちゃ高い習得コスト」を払ってしまった人か、
> そうでない人かでわかれる気がするんだけど、どうだろう？
激しく同意せざるを得ない。
知らない(知る気がない)＝できない
と即断してしまう人はもったいない。

ところで毀誉褒貶(きよほうへん)が読めなかったです。＜ヘタレ

321 ：デフォルトの名無しさん：03/07/23 22:43

「憂鬱」はみなさん的にどうなの？
俺的は文章はともかく、サンプルコードで激しくひいてしまった感じなんですが。

322 ：デフォルトの名無しさん：03/07/23 22:45

C++だと思うと難しい。Cだと思えば便利この上ない。
但し他人のソースが読めない罠。

323 ：デフォルトの名無しさん：03/07/23 22:50

憂鬱は簡単だけど内容もいい。サンプルコードなんてたいした難しいの無かったと思ったが。

324 ：デフォルトの名無しさん：03/07/23 23:01

つまらない手順書き（下っ端コーダ）としての毎日が、
C++のおかげで謎掛けのようなコーディングを楽しむささやかな毎日にかわりますた。

325 ：デフォルトの名無しさん：03/07/23 23:02

>>323 = 似非オブジェクト指向開発者

326 ：デフォルトの名無しさん：03/07/23 23:07

>>321
憂鬱はいい本だと思う

327 ：デフォルトの名無しさん：03/07/23 23:09

オブジェ苦闘嗜好
難しすぎ・・・

328 ：デフォルトの名無しさん：03/07/23 23:11

>>３２１
今読み返したけど、やっぱり難しいコードなんてないじゃん。

329 ：デフォルトの名無しさん：03/07/23 23:17

>>328
難しいから駄目なんじゃなくて、
糞だから駄目なんじゃないの？

330 ：デフォルトの名無しさん：03/07/23 23:44

憂鬱はおいらのバイブルさ。

331 ：デフォルトの名無しさん：03/07/24 00:00

「憂鬱」を理解できなくてあばれてる奴って、一人だけだろ。

332 ：デフォルトの名無しさん：03/07/24 02:32

憂鬱って今から読み返して見ると基礎の基礎だね。
ほんと入り口にすぎない。
実際あのように考えてやってたらうまくいかない。
デザパタの理解しつつ応用力つけるほうが大事だと思った。

333 ：デフォルトの名無しさん：03/07/24 02:34

OOを始める上で最初に読むには良い本。
いきなりGoF本読んでもその場では理解できても、
実際にプログラム作るとなるとうまく活用できないだろうし。

334 ：デフォルトの名無しさん：03/07/24 02:35

だね。憂鬱はクラスの存在価値を知るための本として読んだほうがいい。俺もこれを読むまではなんでクラスが必要なのかわからなかったから。

335 ：デフォルトの名無しさん：03/07/24 03:41

> 俺もこれを読むまではなんでクラスが必要なのかわからなかったから。
えっ？高校のときのオレでさえ分かったのに。
参考書はTurbo C++(DOS)のマニュアルくらい。

336 ：デフォルトの名無しさん：03/07/24 03:49

誰でも初心者のときに読んだ本はたいてい良本だと言うので当てにならない。

337 ：デフォルトの名無しさん：03/07/24 03:58

> いきなりGoF本読んでもその場では理解できても、
天才ﾊｯｹｿしますた！

ちなみに漏れは結城先生のJavaデザパタ本が本格的にOO使い始めたきっかけだね。
今でも心のバイブルでつ。
まだ２年しか経ってないのか…。今や思考の基礎になっちゃってるから
もっとずっと前から使えてた気がしてしまう。

って書いてるオイラは今やC++でテンプレートを駆使する事が生きがいなわけですが、
上の方でOOとそれ以外を組み合わせるのはよくないって言ってる輩はどう考えても
勉強不足か何かかわいそうな境遇で排他的OO至上主義を啓蒙するようになっちゃっただけにしか
思えないんですが。

338 ：デフォルトの名無しさん：03/07/24 06:09

>>319
>規格上は標準C++じゃ使えないし
どこに書いてありました？初耳だ。
intptr_tとuintptr_tはポインタ演算用ではなくてポインタの格納用だと思うが？

>>337
>OOとそれ以外を組み合わせるのはよくないって
まあ、２年しかやってないならそんなものでしょう。
５年やるとわかります、自分以外が付いてこれない、めちゃくちゃ独りよがりなプログラムになっているのです。
他人と合わせるというのはとても重要なのですよ。
もっとも、一人でプログラムをしているなら一向に構わない別ですが・・・

339 ：駄目人間を自白する337：03/07/24 06:33

＞まあ、２年しかやってないならそんなものでしょう。
＞５年やるとわかります
年数だけで決められるんですか？たしかに私はまだまだ勉強する事がたくさんありますが、
それでもOOについてはそれなりに理解して(というか、あまりにも楽しくて、これはすぐ極めねばと
仕事辞めて半年プーしながら毎日朝から晩までコーディングしてたので経験量は単純な時間に比べてかなり多いです)、
非OOの時からのパラダイムシフトほどの大きな成長はなさそうな気配なので、
あなたとそれほど大きく知識、経験が離れているとは思いませんが。

＞自分以外が付いてこれない、めちゃくちゃ独りよがりなプログラムになっているのです。
これはあなたの能力でしょう。他人にもわかるようにという気遣いをしながらコーディングしてください。

＞他人と合わせるというのはとても重要なのですよ。
＞もっとも、一人でプログラムをしているなら一向に構わない別ですが・・・
これには同意。
仕事には*まだ*使えませんね。でもそれは時間が解決する事(周りがついてくるのを待つだけ！)だし
何よりも一歩先を見ている事で、それ以前の問題に対して冷静かつ的確な対処ができるようになると思いませんか？
ひどい例えな気もしますが、子供の頃、掛け算を覚えたとたんに
それまで必死にやっていた足し算引き算が急にあたりまえのようにできるように
なったりした経験はありませんか？

進歩を否定する事は、自らの限界を設定するようなもので、
それこそ頑固親父へ一直線の、エンジニアとしては自殺行為だと思います。
今持っている物だけで安心したいというのなら「常に過渡期の」コンピュータ業界からは
足を表われた方がいいんじゃないですか？

340 ：デフォルトの名無しさん：03/07/24 12:24

>>339
OOもそれ以外も2年もあればマスターできるが、
周りが馬鹿ばっかでついてこれないことに気づくのに5年かかるってことだろ。

341 ：　：03/07/24 14:21

C++ 嫌いな人の言うことって全然わかんない（←理解力がないから）。

確かにクリティカルな処理が全体に占める割合って少ないから、そこだけ
(C++じゃなくて) C でもアセンブラでも使えば良いって気もするけど、
一つの言語で抽象化の度合いの高いところも書けるのはラクだし、いちいち
JNI とかやるのってムダだと思うし。

実時間でのフィードバックや高速処理が必要ない分野では、そもそも批判の
対象になるほど C++ なんて使われてる気がしないしなぁ。。。

342 ：デフォルトの名無しさん：03/07/24 14:51

>>338
> >規格上は標準C++じゃ使えないし
> どこに書いてありました？初耳だ。
int32_tはC++98より後に決まったC99で定められてるから、
C++98のどこにも「書いていない」。だから「規格上は」使えない。
処理系によっては使えるでしょうけど、そういう話はしていないので。

> intptr_tとuintptr_tはポインタ演算用ではなくてポインタの格納用だと思うが？
御意。

ところでptrdiff_t(C89)はポインタ演算結果の格納用ですが、じゃあポインタ演算用の型って何？

343 ：デフォルトの名無しさん：03/07/24 14:56

C++はバグをとってもまたすぐにバグが出るからうんざりだ。
それに比べてJavaはバグとりが楽チン。
うちの会社は半分以上のプロジェクトをＪａｖａでこなしてるよ。

344 ：デフォルトの名無しさん：03/07/24 15:00

>>343
バグを入れるのはプログラマです。

345 ：デフォルトの名無しさん：03/07/24 15:03

いまどきC++だけしか使えない人っているんかいな？

346 ：デフォルトの名無しさん：03/07/24 15:07

C++とCだけならいるだろう。

347 ：デフォルトの名無しさん：03/07/24 15:11

■□■□おもちゃ屋本舗■□■□
アダルトグッズの激安販売店！
ピンクローターなんと１９０円！！
ペペローション360ｍｌが５３０円！
ヌーブラ入荷いたしました！
護身用の警防、スタンガン、催涙スプレー、激安ＤＶＤ、ビデオ、壁マイク、
盗聴器、ダッチワイフ等その他の商品も激安販売しております。
他店と比べてください！ホントに激安！！
http://www.king-one.com/

348 ：デフォルトの名無しさん：03/07/24 15:40

まあひとついえることは、C++使える人間がそれ以外の言語がわからないなどということは無いってことだ。
他の言語が理不尽だ、不便だ、クソだとは思うかもしれないが。

349 ：デフォルトの名無しさん：03/07/24 16:00

>>348
いきなり結論かよ？
>>346の意見と反対だぞ。
>>345=348の自演っぽいな。

350 ：デフォルトの名無しさん：03/07/24 16:12

C++しか使えない奴もいるだろうが、他の言語しか使えない奴に比べると
かなり少ないんじゃないかな。
C++はサラダボール状態だからC++が使えるならたいていの手続き型言語はすぐに使えるようになるし。

俺は他の言語を非力だと感じたことはあるが糞だと思ってことは無いな。

351 ：デフォルトの名無しさん：03/07/24 16:17

C/C++とアセンブラができれば殆どの言語はすぐ覚えられるだろ

352 ：デフォルトの名無しさん：03/07/24 16:26

そしてその「ほとんどの言語」には、
本当に価値のある関数型言語や論理型の言語などは含まれないのだ。

353 ：デフォルトの名無しさん：03/07/24 16:29

>>352
本当に価値のある言語？
たかが道具になに言ってんだおまいは。
(　ﾟдﾟ)､ﾂﾊﾞﾍﾟｯﾍﾟｯ

354 ：デフォルトの名無しさん：03/07/24 16:32

なるほど。憂鬱を叩いている香具師は
憂鬱が読めない奴だったということは分かった。

355 ：デフォルトの名無しさん：03/07/24 16:50

憂鬱が読めないと、例えばどんな本が読めますか？

356 ：デフォルトの名無しさん：03/07/24 16:54

一時売れ筋チャートに載っていた
「オブジェクト指向に強くなる」を図書館で読んだ感想は、
「詰め込みすぎの端折りすぎ」で×。
最近見かけた「オブジェクト脳の作り方」だっけ、同じ翔泳社の、あれはどうですか。

357 ：デフォルトの名無しさん：03/07/24 17:28

自己レス。オブジェクト脳～は目次からしてあまり良さげでないことは分かった。
買おうかと思ってたがやめた。

358 ：_：03/07/24 17:36

http://homepage.mac.com/hiroyuki44/

359 ：デフォルトの名無しさん：03/07/24 17:36

歌と違って本は買う前に内容がわかるわけじゃないから売り上げランキングやチャートは何の意味も無いぞ。
タイトルや宣伝しだいだ。

同程度のスキルの奴からの口コミが一番。

360 ：デフォルトの名無しさん：03/07/24 17:39

わかるだろ

361 ：デフォルトの名無しさん：03/07/24 17:50

>>359
うむ。世間の連中が同程度のスキルだと思って・・・いたが
俺が少しレベルアップしてしまったようだ。
ただチャートを見ると最近の傾向が分かるので重宝してる。
オブジェクト指向技術関連については、
世間の連中がようやく重い腰を上げて勉強しだしたことが伺える。

362 ：デフォルトの名無しさん：03/07/24 17:50

こういっちゃ何だが、例外とか、継承とかは関数言語のテクニックや、
言語仕様の後追いだよな。

363 ：デフォルトの名無しさん：03/07/24 17:57

>>362
関数言語?
オブジェクト指向の言語を参考にしたんじゃね?
(例外は、どの言語が最初に発明したか知らないけど)

364 ：　：03/07/24 18:20

PL/I, LISP, Ada あたり。

365 ：デフォルトの名無しさん：03/07/24 18:20

OO厨の多くは関数型言語については何もしらないのに
それについて敵意剥き出し、コンプレックス丸出しだな。
知らないなら、おれみたいに無関心装えばいいのに。

366 ：デフォルトの名無しさん：03/07/24 18:21

つーか使えない関数型言語のテクニックの使える機能を
持ってきて有効活用しているといったほうがいいと思う。
所詮関数型言語は当て馬

367 ：デフォルトの名無しさん：03/07/24 18:22

>>365
何も知らないで敵意剥き出しでコンプレックス
丸出しなのはお前だけ（ｗ

368 ：デフォルトの名無しさん：03/07/24 18:24

>>367
コンプレックスはそりゃあるが、
知らないことを知らないと言うぐらいの賢さは持ち合わせてる。

369 ：デフォルトの名無しさん：03/07/24 18:24

関数型言語って何？C++あれば他はいらないんじゃないの？

370 ：デフォルトの名無しさん：03/07/24 18:28

Javaは純粋なオブジェクト指向言語？
SmallTalkみたいに、ループとかがオブジェクトじゃないのに？

371 ：デフォルトの名無しさん：03/07/24 18:31

関数型言語勉強したいのにLispとか記号の羅列にしか見えなくてダメぽ

冗長でもいいから目に優しい関数型言語が欲しい

372 ：デフォルトの名無しさん：03/07/24 18:31

>>370
C++よりは純粋。
俺の場合、比較対象がC++なもんで。

373 ：デフォルトの名無しさん：03/07/24 18:45

>>369
釣りだろうが。
適所適材ってものがあるだろ。

374 ：デフォルトの名無しさん：03/07/24 18:48

>>371
純粋に関数型の部分を勉強したいのならLispは不向き。
ML系やHaskellがお勧め。
どちらもこの板に専用スレがあるのでどうぞ。

375 ：デフォルトの名無しさん：03/07/24 19:08

>>373
関数型言語は頭の体操用じゃないの？

376 ：デフォルトの名無しさん：03/07/24 19:11

必死に時間や金かけてC++学んだ連中には悪いが、俺もC++はゴミだと思う。
習得に時間かかりすぎ。コードの可読性低すぎ。バグ産みやすすぎ。
自由度高すぎて他人のコードが理解しずらいったらありゃしない。
そのうえ未だにSTL周りなどコンパイラの互換性すら怪しい。
言語仕様の設計思想は理解できなくもないが、業務では使いたくない。
趣味で使いたい奴だけが使う言語にとっととなりさがって欲しい。
忌々しきStroustrup。

377 ：デフォルトの名無しさん：03/07/24 19:16

>>375
大規模ソフトウェアの証明支援として関数型言語や論理型言語が使われるね。
君だってサーバサイドだと、C++じゃなくて普通JAVA使うだろ。

378 ：デフォルトの名無しさん：03/07/24 19:25

＞習得に時間かかりすぎ

おまえの頭が悪いだけ

379 ：デフォルトの名無しさん：03/07/24 19:26

sscliのソースを見ても、ありゃC++じゃなくてCだ。
COMというなにやらオブジェクト風のエッセンスで
包んだとはいっても、中身は殆どCまがいのコードで
書かれているような気がする。

380 ：デフォルトの名無しさん：03/07/24 19:29

>>376の理想の言語は自由度が低くて可読性が高くバグをうみださない。
習得が容易で処理系間での互換性がたかい。
つまりその言語とは！

381 ：デフォルトの名無しさん：03/07/24 19:32

>>380
COBOLだな

382 ：デフォルトの名無しさん：03/07/24 19:39

http://hp.vector.co.jp/authors/VA000092/jokes/strup.html
このStroustrupインタビュー記事、かなーり現場の的を射ているよな。
まあネタだけど。

383 ：デフォルトの名無しさん：03/07/24 19:56

382=最近知って嬉々として貼り付けてます

384 ：デフォルトの名無しさん：03/07/24 19:59

Stroustrupって名前からして
訳分からんこと仕出かしそうだよな。

385 ：デフォルトの名無しさん：03/07/24 20:09

言語がどうとかじゃなくてオブジェクト指向を理解してない奴が多すぎ。
覚えてもそれにそって書くことが全然できてない。
そーゆー奴は大抵テンプレートの悪用や趣味の悪い継承なんかをやりだす。
オブジェクト指向は言語の仕様やデザパタを覚えてもどうにもなんねーぞ。
ホントこればっかりはセンスとしかいいようがないような感じ。
わかんねー奴はホントわかんねーみたいだし。
こんなの5分で理解しろよ！
って地団駄踏みたくなる。
憂欝本が切り札だったがわからない奴は読むのをやめる。
効果は少ない。
あーどうしたもんか

386 ：デフォルトの名無しさん：03/07/24 20:20

>>385
アナタが設計して、実装だけやらせればよろしい。
って実装でもある程度のOOPの知識はいるのか・・・

387 ：デフォルトの名無しさん：03/07/24 20:22

>>386
コピペだよ

388 ：デフォルトの名無しさん：03/07/24 20:22

>>376
かな～り禿同。

389 ：デフォルトの名無しさん：03/07/24 20:23

OOPったって、ただ物事の本質を見抜いて言語の制限とOSにとうまく折り合いをつければいいだけ

390 ：デフォルトの名無しさん：03/07/24 20:26

MSX-BASICとCとC++とZ80、68000、x86、R3000アセンブラとCOBOLとLISPが使える
漏れからしたらJavaムズい・・・、イメージわかねぇ・・・。

391 ：デフォルトの名無しさん：03/07/24 20:29

>>388
あなたにはコボルをお勧めする。

392 ：デフォルトの名無しさん：03/07/24 20:35

393 ：デフォルトの名無しさん：03/07/24 20:38

>>378
禿同

>>381
禿同

>>391
かな～り禿同

そりゃ英文法も英単語も知らない人間にゃ英作文は難しいやねヽ（´ー｀）ノ
ハードとOSの動きと、言語仕様・制限を知ってればCもC++そんなに難しくは無い
つか、最近の高級言語はオブラートに包まれてやりたいことが出来ないのが多過ぎ。
出来てもソレやるのには面倒なことせにゃならんし。

そんな漏れはコボラー・・・_|￣|○ Cﾂｶｲﾃｰﾖ...

394 ：デフォルトの名無しさん：03/07/24 20:39

”物事の本質”って何だよ。

395 ：デフォルトの名無しさん：03/07/24 20:45

C++は.NET Frameworkのクラスライブラリが使えないのでWindowsアプリを作るのは不向きです。

396 ：デフォルトの名無しさん：03/07/24 20:48

＞＞３９４
考えてごらん

397 ：デフォルトの名無しさん：03/07/24 20:49

>>389
あなたにはコボルをお勧めする。

398 ：デフォルトの名無しさん：03/07/24 20:54

>>396
コボルが真のプログラム言語という結論に達した。

399 ：デフォルトの名無しさん：03/07/24 21:54

汗書けないのにC++できますっつうのはどうよ？
個人的に信用できないんだが。

400 ：デフォルトの名無しさん：03/07/24 21:57

>>399
俺は汗かけないよ
勉強すれば出来るだろうけど必要性を感じないからやってない、デバッグのために読めれば十分だと思ってる

401 ：デフォルトの名無しさん：03/07/24 21:57

>>399 は汗っかきのデブハゲ

402 ：デフォルトの名無しさん：03/07/24 22:16

C++がちゃんとしたアセンブラに最適化してくれます。

403 ：デフォルトの名無しさん：03/07/24 22:17

つーかテンプレートの悪用ってどういう使い方を指してるわけ？

404 ：デフォルトの名無しさん：03/07/24 22:38

>>401
禿てるが、デブじゃない

405 ：デフォルトの名無しさん：03/07/24 22:39

C++プログラマは禿ていなくてはいけない

406 ：デフォルトの名無しさん：03/07/24 22:40

&C++

407 ：デフォルトの名無しさん：03/07/24 22:40

禿げてないC++プログラマは偽者

408 ：デフォルトの名無しさん：03/07/24 22:45

つか、おまえらも禿げろ

409 ：デフォルトの名無しさん：03/07/24 22:49

ただいま急速にハゲ進行中
父親も祖父もハゲ・・・・((((；ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

ハ、ハゲは人類の進化系だよね・・・・

410 ：デフォルトの名無しさん：03/07/24 22:57

おまえら暇だな。

411 ：デフォルトの名無しさん：03/07/24 22:58

>>405はビヤーネ

412 ：デフォルトの名無しさん：03/07/24 22:58

>>410
ｵﾏｴﾓﾅｰ

413 ：デフォルトの名無しさん：03/07/24 22:59

Kylix3 ﾏﾝｾｰ

414 ：デフォルトの名無しさん：03/07/24 23:08

貼っておくか
http://hp.vector.co.jp/authors/VA000092/jokes/strup.html

415 ：デフォルトの名無しさん：03/07/24 23:13

>>409
いいからさっさと禿げきれ( ﾟ,_・・ﾟ)ﾌﾟｯ

416 ：デフォルトの名無しさん：03/07/24 23:19

私の自信作だよ♪電気を消して見てね♪

http://nuts.free-city.net/index.html http://www2.free-city.net/home/angelers/page008.html

417 ：デフォルトの名無しさん：03/07/25 00:40

C++を極めるとこうなります。
http://www.research.att.com/~bs/Bjarne.jpg

418 ：デフォルトの名無しさん：03/07/25 00:40

「定数」が無いCは糞。
(C++も結局Cの呪縛からは逃れられないので存在価値なし）

419 ：デフォルトの名無しさん：03/07/25 00:41

>>418
VB厨は帰っていいよ。

#define
const

420 ：デフォルトの名無しさん：03/07/25 00:57

418みたいな間違った知識ってどこから仕入れるんだろう？
使えない先輩もしくは教授の痛い批判　→　弟子の418が真に受ける　→　間違った受け売り

421 ：デフォルトの名無しさん：03/07/25 02:32

>>419
使い方は一緒かもしれないが、似ている様で違う物だぞそれらは。

422 ：デフォルトの名無しさん：03/07/25 02:37

>>421
>>418の2行に合わせて
「定数」が無いCは糞。…#define
(C++も結局Cの呪縛からは逃れられないので存在価値なし）…const
って事だろ。

423 ：デフォルトの名無しさん：03/07/25 03:05

>>422
CとC++のconstは違うってばよ。

424 ：423：03/07/25 03:06

あ。ごめん。良く読んでなかった。

425 ：デフォルトの名無しさん：03/07/25 10:01

C++を使いはじめて10年以上になるが、
これまでC++をC++として使える奴って未だ見た事がない。
このスレでC++を絶賛している奴は本当にC++を使いこなしているのか疑問。

426 ：デフォルトの名無しさん：03/07/25 10:02

>>425
　　 ∧＿∧　　／￣￣￣￣￣
　　（　´∀、）＜　オマエモンアー
　　（　　　　）　＼＿＿＿＿＿
　　｜｜　|
　　（_＿）＿）

427 ：デフォルトの名無しさん：03/07/25 10:06

>>425
あなたにはCOBOLをお勧めする。

428 ：　：03/07/25 12:03

Java が良いっていう人のなかには、言語仕様よりもそのフレームワーク志向っぷり
（固有のロジック以外の部分はライブラリやら JNI とかで他人がやってくれ（て）
る）が良い、って人も居るような気がする。

C++ でも STL とか使うし、そういう態度を否定するわけじゃないけど、VM 以外は
Java がイイ！！なんての読むと net やら awt の実装は誰がしてると思ってんじゃ
とか、デバイスドライバとか動画処理系を書いてる漏れって死ねってこと、とか、
やはりなんとなく気分悪い。

429 ：デフォルトの名無しさん：03/07/25 12:32

>>428
別に死ななくていいよ。Javaでデバドラ書く人はあまりいないと思うし。

430 ：デフォルトの名無しさん：03/07/25 12:33

C++の例外仕様よりもJavaの例外仕様の方がいいと思う。

431 ：デフォルトの名無しさん：03/07/25 12:34

>>４２９
なんか違わないか？

432 ：デフォルトの名無しさん：03/07/25 12:34

あとInterfaceが無いC++は糞。
JavaにもObject Pascalにもあるのに。
クラスで代用しろって？
だから多重継承だらけになるんだよ。

433 ：デフォルトの名無しさん：03/07/25 12:44

C＋＋インターフェースあるよ。interface unko{}で定義できるよ。

434 ：デフォルトの名無しさん：03/07/25 12:48

あ、ATLだけなのか

435 ：デフォルトの名無しさん：03/07/25 13:15

多重継承を行うのにInterfaceを使う奴は糞

436 ：デフォルトの名無しさん：03/07/25 13:18

こうして延々各言語信者の戦いが続いていくわけだが。

437 ：デフォルトの名無しさん：03/07/25 15:38

小文字大文字で同じ名前を使い分けるなんてカス。

438 ：デフォルトの名無しさん：03/07/25 15:46

Class Hoge
{
};

Hoge hoge;

とかやらないの？

439 ：デフォルトの名無しさん：03/07/25 17:07

シングルトンとかあるから、いいんじゃねぇかと

440 ：デフォルトの名無しさん：03/07/25 20:41

よく言われることだけど
C++の難しさ　＝　VisualC++の難しさ
なんじゃないのか？

C++そのものはそれほど困難ではない。
しかしVisualC++のMFCやらWinAPIやら
その他色々なことを覚える時点でもう嫌になる。

VisualC++じゃないC++から入って、
それでもC++があまり馴染まなかった人っている？

441 ：デフォルトの名無しさん：03/07/25 20:48

よく言われてることだけど
440はうんこ
なんじゃないのか？

442 ：デフォルトの名無しさん：03/07/25 22:31

↑コボラーはアホなので言語の話では場に加われないんだってさ

443 ：デフォルトの名無しさん：03/07/26 00:44

ボーランドのC++をVB.NETが追い越しちまったよ。言語能力的に。

444 ：デフォルトの名無しさん：03/07/26 01:04

440うんこ

445 ：デフォルトの名無しさん：03/07/26 01:05

ｳﾝｺｰ

446 ：Visual COBOL++：03/07/26 01:16

>425
いるいる！
Visual C++を、MFCを、C++でなく殆どCのみで組むやつ。
MFCで使わざるを得ないオブジェのみC++で仕方なく組むけど、
自分で作って使用する関数は全てCのみってやつ多い。

447 ：321：03/07/26 01:33

「憂鬱」は、途中までは楽しく読めたんだけど、最後に出てくるエイトクイーンの
コード読んで、ちっともエレガントじゃないやん！って感じちゃったのよ。
なんか、前に C で書かれたソース見た時の方が、よっぽど感動したよ！みたいな。

構成もうまいし、広く浅くいろいろな視点で描かれていて、入門書として
悪くはないとは思うんだけど、具体的な事例の紹介まできっちりやろうとして、
結果として「玉に瑕」になってしまっていて、なんかもったいないなぁ、
って気がしたんだけど、そんなことない？

うーん。俺的に「オブジェクト指向とはこうゆうことなんだ！」って理解した
気になった後に読んだので、変に反発しちゃっただけかもしれのだけど。

448 ：デフォルトの名無しさん：03/07/26 01:54

「俺は C++ できるぜ！」って主張している連中の中で、ちゃんと
「C++ の標準ライブラリ」を理解できてる奴がほとんどいないことが、
C++ に対する意味不明な批判の元になっている気がする。

俺の周りだけかもしれんけど、「C++で、いちいち delete の管理をしなきゃ
いけないのが面倒」とかいう奴に限って std::auto_ptr 知らなかったり、
「C++ のストリームは遅いよね」って言う奴に限って stream_iterator
知らなかったりするんだけど。(蛇足だけど std::auto+_ptr とか steram_iterator も
万能ではない！、という意見には俺も前面的に賛成するぜ！けど今はそれ以前の話)

なんか、C のイディオムを C++ に無理矢理持ち込む奴大杉な気がする。
１０年前にはその時代遅れな C 言語固有のテクニックも通用したのかもしれんけど、
C++ なら無意味なだけでなく有害なのでやめてください、みたいなコードが
はびこってて、若僧の俺が「ここはこうした方がいいんじゃないですか」とか言うと、
「いや！これはこれで正しいのだ！」とかロートルな親父に目の色変えて怒らるのは
もうううんざりって感じ。

Java のうらやましい点のひとつは、余計な過去のイディオムを無効化した
点にある気がする。いっぽうで、いまさら OO に特化してしまった点で、
正直目新しさはないけど。private 継承ができないのもむかつく。

＃うう。長文ごめんね。

449 ：デフォルトの名無しさん：03/07/26 02:06

>>447
あのコードはクラス図、シーケンス図を忠実に翻訳したものです。
俺的には、設計結果をコードに落とす方法が分かって良かったが。

450 ：デフォルトの名無しさん：03/07/26 02:09

>「C++ のストリームは遅いよね」って言う奴に限って stream_iterator知らなかったりするんだけど

お前も「C++ の標準ライブラリ」を理解できて無いね。

「C++ のストリームは遅いよね」って言う奴にstream_iteratorの存在を教えても何の解決にもならねｰよ

451 ：デフォルトの名無しさん：03/07/26 02:25

↑反論するならちゃんとその訳を書け。
さっぱりわからん。

452 ：448：03/07/26 02:28

>> 450
指摘されてる点は多分理解できてるけど、たぶんそれ以前のレベルで俺は
苦労してる感じ。そう言い切れちゃう君の環境が正直うらまやしい。

前に誰かが言ってたけど、C++ は習得コストが高すぎて、結局(馬鹿も
阿呆も受け入れられざるおえない)多人数プロジェクトには向いてない、
ってのが俺のいる環境なのかも。

453 ：448：03/07/26 02:39

>>451

俺の理解する範囲内では、stream_iterator の存在意義は、
例えば、std::copy() の引数として利用できる点にあって、
別にパフォーマンスを求めた結果として導入された仕様ではないだろーってのが、
450 の主張したいことだと思う。

一方で、>>448 での俺の主張は

while(os) {
char c;
os >> c;
}

が遅いって抜かす奴が、stream_iteratorの使いかた知らないのはいかがなものかと、
というすごくレベルの低い話。ふつーは、 stream_iterator 使った方が、
全然早いはず。でもまぁ、実はこれも実装環境に依存するのかも。
なんか、いまひとつピントの外れた例を挙げてしまったような気もする。

454 ：448：03/07/26 02:45

う。>>450 は、sterambuf_iterator だろうが！ってツッコミだったのかも。

ええと、要するにですな。
かくのごとく「C++ は難しすぎ」って話なわけで...。
うう。俺かこわるい。

455 ：デフォルトの名無しさん：03/07/26 03:06

要するに、馬鹿をプロジェクトに入れるなと。

456 ：質問：03/07/26 03:16

標準C++ではstd::string s;で
ストリームに　<<　や　>>　はできますか？
できないよね？

in >> s;
out << s;

457 ：デフォルトの名無しさん：03/07/26 03:35

>>456
できるが・・・

458 ：質問：03/07/26 04:17

>>457
VC++6.0を使っているができない。
コンパイルエラーになる。
インクルードしているヘッダーは
#include <iostream.h>
#include <fstream.h>
#include <string>
なのだが。。。
まだ足りないのだろうか？

459 ：デフォルトの名無しさん：03/07/26 04:26

とりあえず.hをはずせ

460 ：デフォルトの名無しさん：03/07/26 05:08

・Java使いらしい
・憂鬱本でオブジェクト指向に目覚めたらしい
・テンプレートは理解できないから嫌いらしい
・理解できない物は嫌いらしが、OOは唯一理解できた(つもり)でOO至上主義者になった
・貶し言葉は「憂鬱本が理解できない奴は～」らしい
・「1÷2は0.5だ」と言う相手に「0余り1だ、小数なんて邪道だスパゲティだ」と言うのが恥ずかしくないらしい。
・最後に、分身の術が得意らしい

461 ：デフォルトの名無しさん：03/07/26 05:39

・Java使い・・・○
・憂鬱本で・・・×　Javaによるオブジェクト指向入門とかそんな本だ
・テンプレート・・・×　憂鬱本に解説が載っている
・理解できない・・・×　構造化プログラミングは分かっている
・貶し言葉・・・○　あの程度が理解できないんじゃね
・１÷２・・・１／２
・分身の術・・・×　別に分身しているわけではないのでご安心あれ

462 ：デフォルトの名無しさん：03/07/26 05:46

・Java使い・・・×
・憂鬱本で・・・×
・テンプレート・・・×
・理解できない・・・×
・貶し言葉・・・×
・１÷２・・・0.4999999999999999999999999999999…
・分身の術・・・○　現在分身中

463 ：デフォルトの名無しさん：03/07/26 12:01

道具に使われてる連中が多いな、このスレ。

464 ：デフォルトの名無しさん：03/07/26 13:34

C++は、OOとは全く関係ないところで難しい。
OO自体は単純明快なのに、だ。

465 ：デフォルトの名無しさん：03/07/26 13:51

親クラスのコンストラクタの呼び出し方が変なのはOOと関係ないのか？

466 ：デフォルトの名無しさん：03/07/26 13:59

>>462
いったい何進数の計算なんだ > 0.499..

467 ：デフォルトの名無しさん：03/07/26 14:04

>>466
お前真性のバカだろ

468 ：デフォルトの名無しさん：03/07/26 14:24

>465 名前：デフォルトの名無しさん[sage] 投稿日：03/07/26 13:51
>親クラスのコンストラクタの呼び出し方が変なのはOOと関係ないのか？

Javaと違うから変とか言うのはやめてください。

469 ：デフォルトの名無しさん：03/07/26 15:07

>>464
C++に挫折して恨み骨髄液。
Javaがなんとかわかって、OOがわかったつもり。
C++さえなくなれば、過去の傷を消せる。
消えろ、C++。ちくしょう。C++さえなければ。
俺は、恨みを忘れん。

というタイプの人ですね。;-)

470 ：デフォルトの名無しさん：03/07/26 15:24

>>468
Object PascalもJavaも同じ様な呼び出し方でC++だけ極端に違います。
つーか何アレ？

471 ：デフォルトの名無しさん：03/07/26 15:36

--- うちで受けてるオブジェクトの案件なども、組み込みを除くとほとんど Java ですよ。
C++ はもう壊滅状態です。

C++ は難しいからですかね。やっぱり。

--- そうですね。あれだけ簡単にオブジェクトぼこぼこ作れたらいいですよね。
私、MS の .NET のセミナーに行ったんですけど。彼らももう、C++ は進めてないですよ。

http://www.ogis-ri.co.jp/otc/hiroba/others/OORing/interview08.html

472 ：デフォルトの名無しさん：03/07/26 16:18

C++はわいの会社も壊滅状態じゃ。

473 ：デフォルトの名無しさん：03/07/26 16:32

まるで
Algol≒C++≒PL/I≒言語仕様が巨大で複雑
Pascal≒Java≒該当無し≒言語仕様が簡素で単純

歴史は繰り返すのか

474 ：デフォルトの名無しさん：03/07/26 16:34

いいとこどりの折衷案にみえて巨大過ぎたPL/I = .NET

475 ：デフォルトの名無しさん：03/07/26 16:44

C++の仕事がどんどん減ってるんだけどどうすればいいの？
このままじゃリストラされちゃうよ～～～。
隣にはJavaがめちゃくちゃできる奴がおる。
誰か助けてぇ～～～～～。

476 ：デフォルトの名無しさん：03/07/26 16:45

>>467
?

477 ：デフォルトの名無しさん：03/07/26 16:50

まずい飯をそのままにOOの味付けをまぶして古今東西の珍味を盛りつけた言語≒C++

478 ：デフォルトの名無しさん：03/07/26 16:56

ふー、C++挫折してJavaに移行しといて
辛うじて生き延びたって感じだな。
世の中平均的な頭の持ち主が多いのだ。
彼らにC++は難しすぎる。

479 ：デフォルトの名無しさん：03/07/26 16:56

http://homepage3.nifty.com/coco-nut/
ヌーブラってエロくねーか？

480 ：デフォルトの名無しさん：03/07/26 17:04

>>476
462でも467でも無いが、
0.499... = 0.5 だろってことじゃね？

↓に同じ
1/3 = 0.333...
0.333... * 3 = 0.999...
1/3 * 3 = 1
ゆえに
0.999... = 1

481 ：デフォルトの名無しさん：03/07/26 17:05

>>475
Javaに乗り換える||プログラマの上位職種を目指しコード書きは止める||古い言語の保守要員になる||廃業
でどう？

482 ：デフォルトの名無しさん：03/07/26 17:08

C++よりJavaの方が楽チンだし安全だし開発も早いが、
C++の方が面白いと思わないか？
Javaって楽だけど面白くない。

483 ：デフォルトの名無しさん：03/07/26 17:14

>>482
確かにJavaはC++より面白くない。
なので、面白がりたかったら俺はLinuxで遊ぶね。

484 ：デフォルトの名無しさん：03/07/26 17:21

今のC++は、core languageに限って言うと、かなり安全側に
倒してあるわけで、ほとんどの罠は引っかかってもコンパイル
エラーで済むと思うが。例外安全ばかりは知らないと仕方
無いけど、これは言語に依らないし。まあそこら中で例外が
起こる分やりにくいのは確かだけど。
それよりライブラリが・・・

485 ：デフォルトの名無しさん：03/07/26 17:56

>>482
絶対Javaの方が面白い。
なにせC++には標準で3Dどころか2DのGUIさえ存在しないから。

486 ：デフォルトの名無しさん：03/07/26 18:10

Javaは面白いというか、生き延び戦略で移行したからな。
第一に、簡素なOO言語である。
第二に、クラスライブラリがOSに依存しないので、何が来ても馬鹿の一つ覚えでいける。

っつーね。

487 ：デフォルトの名無しさん：03/07/26 20:50

DelとかC#とかいじると、どうしても言語仕様の古くささを感じてしまうね。

488 ：デフォルトの名無しさん：03/07/26 21:10

>>487
新しい部分もあるじゃん、もちろん古い部分もあるが。
おめめ節穴ですか？

489 ：デフォルトの名無しさん：03/07/26 22:50

>>471のページってひどくねーか。

これってインタビュー記事だよなあ。
それなのに、C++は壊滅だとか、MSはC++を進めてないだとか、
インタビューされてる人じゃなくて、インタビューしてる人の話でしょ。
そんなこと言いたいなら、インタビューでやるなよって。
インタビューされてる人は、ただ無難に答えてるだけじゃん。

OGISは糞だってよく聞くけど。ほんとに糞だね。

490 ：デフォルトの名無しさん：03/07/26 23:04

>>489
インタビューなんてみんなそんなもん、自分の書く記事に都合の良い方向に持ってくんだから。

491 ：デフォルトの名無しさん：03/07/26 23:11

ひでぇ。読んでみてびっくりした。
確かに、インタビューワが糞だわ。

OGISはコピー機のファームがC#と.NETで書けるとでも思ってんのか。

492 ：デフォルトの名無しさん：03/07/27 01:11

妬みが激しいでつ。

493 ：デフォルトの名無しさん：03/07/27 02:04

Javaの人はもうC++をライバル視するのやめれ。
もともと住んでる世界が違う。
JavaのライバルはあきらかにC#、VB.NET、Del.NETなんかだろ。
まあ、せいぜい、WEBサービスの利権を取られないようにがんばりなさいませ。

494 ：デフォルトの名無しさん：03/07/27 07:20

>>493
うむ。時代はJava vs .NETだからな。
UNIX陣営対Windows陣営の果てしなき戦いは続く。
・・・まぁどっちがきても大丈夫なようにVB.NETでもやっとくかな。

495 ：デフォルトの名無しさん：03/07/27 07:43

VB.NETなど1日あれば覚えられる自信があるから必要になったときに覚えればいい

496 ：デフォルトの名無しさん：03/07/27 11:42

C++ なぞ３年８ヶ月もあれば覚えられる自信があるから必要になったときに覚えればいい

497 ：デフォルトの名無しさん：03/07/27 12:02

明日がある、明日がある、明日があるさ～♪

498 ：デフォルトの名無しさん：03/07/27 16:22

C0x
C++0x
っていつごろ？

499 ：デフォルトの名無しさん：03/07/27 18:46

>>496
必要になってからじゃ遅いじゃん。

500 ：デフォルトの名無しさん：03/07/27 18:55

>>499
こんなに自信もってこれ書き込むのはじめてかも

ネタにマジレスｶｺｲｲ!!

501 ：デフォルトの名無しさん：03/07/27 19:28

大体お前らな。
C++で書く時にCのライブラリつかうからいけねぇんだよ。
オブジェクト指向の言語に手続き型のライブラリ使ってどうすんだよ。
手続き型の関数でクラス設計してどうすんだよ
そんなことするから予測しないバグが多発するんだよ。

そうしておいて、C++がダメだダメだだって?
そりゃ、あんたらが真のC++を使ってないからだろ。

CとC++は全く違う言語だとC++の開発者自身が一番最初に述べてるんだよ
Cに似てるのは見かけ上であって、CとC++が混在できる訳ないんだよ。
考え方がまるっきり違うんだからな。

これからはstdio.hじゃなくてiostreamを使えよ

502 ：デフォルトの名無しさん：03/07/27 19:31

>>501
Cライブラリなんかメソッド内に隠蔽されて使うだけなんだから設計には影響しないだろ

503 ：デフォルトの名無しさん：03/07/27 19:40

Cライブラリを使う危険性が判ってない
にわか信者がまた一人・・

504 ：デフォルトの名無しさん：03/07/27 19:43

>>502
じゃあ、お前はC++の中にCOBOLの関数だろうがLispの関数だろうがXMLのタグだろうがPrologだろうがなんでも入ってていいんだな?
隠蔽されて使うだけだから・・・・

そうじゃない。言語ってそういうものじゃない。
もちろん組み込み型が重要な訳だけど
その言語の標準ライブラリはその言語の方向性を決めるものだよ。

どこか別の言語から持ってくればいいって訳じゃない。

505 ：デフォルトの名無しさん：03/07/27 20:27

>>504
>じゃあ、お前はC++の中にCOBOLの関数だろうがLispの関数だろうがXMLのタグだろうがPrologだろうがなんでも入ってていいんだな?
>隠蔽されて使うだけだから・・・・
そういうもんだよ、C++って奴は。
そいいうのがあっても良くなければ、C++の本来の利点は出てこない。
それを取り除いたら、C++なんて言語なぞ使わずJavaなりC#なり使ったほうがはるかに便利だ。
無茶が効くからこそのC++だよ、それをやるのがダメだというなら、あんたのやっていることは途方のない無駄だよ。
そういう目的なら今はもっと良い言語が沢山ある。

506 ：デフォルトの名無しさん：03/07/27 20:37

>>505
違うよ。そういうもんじゃない。これはC++に限らない。
C++はあくまでC++の中でやるべき。
C++の作者はprologを使ったことがないだろうし、Lispもたぶんないだろう。
C++はC++の枠の中だけで有効だよ。
他の言語もね。

それに、お前はC++の本来の利点を分かってないよ。
C++の本来の利点は高機能なオブジェクト指向言語というところ。
Javaにはできない複雑な継承とか、他の言語には真似できない高機能なテンプレートとか、それがC++の真髄だよ。

決して、他の言語を受け入れるような組み込みの汎用性を提供してる訳じゃない。

だから、お前がそういう考えでC++をやってるなら、それこそ無駄だよ。

あと、
>そういう目的なら今はもっと良い言語が沢山ある。
ということのようだが、ないね。
C++の前に存在していたLispが唯一だろ。
lispはC++をはるかに超えて高機能だからね。
C++のテンプレがLispのマクロにはかなわない
プログラムをデータのようにして扱うことでさえできてしまう。
lispはたしかにC++を超えるだろうね

507 ：デフォルトの名無しさん：03/07/27 20:39

>>506

×C++のテンプレがLispの...
○C++のテンプレはLispの

508 ：デフォルトの名無しさん：03/07/27 20:41

>>506
extern "C" と asm が言語規格に存在する意義を認めないということですか？

509 ：デフォルトの名無しさん：03/07/27 20:43

>>505 >>508
C++で他の言語を想定したライブラリ使うと、
例外機構とかがうまく機能しなくなったりする。
これはC++から恒常的に使えるＣライブラリでさえ当てはまる。
こういう違反が頻発していると、
C++ベースでライブラリ書く事が無駄に思えてくる。

510 ：デフォルトの名無しさん：03/07/27 20:45

これらの違反は、C++という仕様の中では防げない。
作成者側が気をつけるしかない。

511 ：デフォルトの名無しさん：03/07/27 20:49

>>506
interface もない言語なのにか？
ムチャクチャ言うなよ

512 ：デフォルトの名無しさん：03/07/27 20:51

お前は lisp を使ったことがあるのかと小一時間問い詰めたい発言内容だ。

513 ：デフォルトの名無しさん：03/07/27 21:03

テンプレートとかについてLISPのマクロに敵う言語はないと俺も思う。
C++はコンパイル時にそれに近い事をしているという意味では
よくやってるが、いささか煩雑だね。
ここでLISPの話をしてもしょうがないと思う。知らない人ばっかりだし。

514 ：デフォルトの名無しさん：03/07/27 21:12

>>506
ならば貴方はC++を止めてlispでプログラムすべきだね、
最近はlispも高速な実行方法が研究されているし実用にもなるだろう。その方がいい。
C++については、みんな貴方のような使い方は目的としていないよ。

515 ：デフォルトの名無しさん：03/07/27 21:14

にわかC++信者はこれだから困る。

516 ：デフォルトの名無しさん：03/07/27 21:14

>>514
>C++については、みんな貴方のような使い方は目的としていないよ。
それは>>514だけの意見だろ

517 ：デフォルトの名無しさん：03/07/27 21:16

boostはLISPを目指してる様にも見えるが。

518 ：デフォルトの名無しさん：03/07/27 21:16

たぶんLISP信者とか言われて一蹴されるんだろうな。

519 ：デフォルトの名無しさん：03/07/27 21:21

>>514
＞最近はlispも高速な実行方法が研究されているし実用にもなるだろう。その方がいい。
昔っからLispは速いよ。特に商用は。

520 ：デフォルトの名無しさん：03/07/27 21:21

>>516
そんなことは無いよ、C++ユーザーの八割方は組み込みユーザーだからね。
標準ライブラリを入れるとバイナリサイズが大きくなりすぎて困ることは当たり前のようにある。
libc(stdioとか入っているライブラリ)すら取り除くことがあるんです、仕事でやっているなら常識ですね。

521 ：デフォルトの名無しさん：03/07/27 21:22

>>520
>C++ユーザーの八割方は組み込みユーザーだからね。
(ﾟдﾟ)ﾊｧ?

522 ：デフォルトの名無しさん：03/07/27 21:26

組み込みユーザーって何？
人柱って事？

523 ：デフォルトの名無しさん：03/07/27 21:32

514=520=C上がりの覚えたて厨
でした・・・

524 ：デフォルトの名無しさん：03/07/27 21:36

>>523
始めて10年まだまだ憶えたてです、この言語ときたら進化が止まらんのでね。

525 ：デフォルトの名無しさん：03/07/27 21:37

>520

はぁ？コイツは馬鹿ですか？
恐れ入るよ。

526 ：デフォルトの名無しさん：03/07/27 22:08

>>520
本日のマイフェイバリットトリビアです。

527 ：デフォルトの名無しさん：03/07/27 23:28

C+=2まだー?

528 ：デフォルトの名無しさん：03/07/28 03:37

ストラウストラップは禿げすぎ

529 ：デフォルトの名無しさん：03/07/28 09:06

まあ嫁

Java と C++ との違い
JavaはC++を親言語として設計されていますが、いくつか削除した点、
改良した点、追加した機能があります。以下にＣ＋＋との変更点を挙げます。
http://www2g.biglobe.ne.jp/~yoshi/java/JavaGate/Chapter1/difff.html

530 ：デフォルトの名無しさん：03/07/28 13:06

>>458
遅レスだけど
using namespace std;
が足りない

531 ：デフォルトの名無しさん：03/07/28 18:42

Javaはgoto文が使えないくせにgotoが予約語に入っている
とんでもない駄作

532 ：デフォルトの名無しさん：03/07/28 18:43

>>531
goto 使いたいのか？

533 ：デフォルトの名無しさん：03/07/28 18:52

int ito, goto, sato;

534 ：デフォルトの名無しさん：03/07/28 18:55

Java とか C# だと
int 伊藤, 後藤, 佐藤;
とか出来るし…

535 ：デフォルトの名無しさん：03/07/28 18:59

James P. Gotoさんとかはどうしろってんだ!

536 ：デフォルトの名無しさん：03/07/28 19:00

自作自演？

537 ：デフォルトの名無しさん：03/07/28 19:04

>>535
Goto は予約語じゃないから使えるけど。

538 ：名無し＠沢村：03/07/28 21:15

おまいらよ、C++でＴＶウェアをつくらないか？

http://pc2.2ch.net/test/read.cgi/tech/1059262203/l50

539 ：デフォルトの名無しさん：03/07/29 17:46

CやJavaのプログラマは少なくとも言語処理系に対して少しは興味を
持ってたけど、C++は標準化に携わってる人もプログラマも
コンパイラ製作者のことなど何も考えてないのが問題な気がする。
もう他人事。

540 ：デフォルトの名無しさん：03/07/30 00:34

>> 539

あら。どちらかというと、俺は Java プログラマに対して「言語処理系」に
対する理解がじぇんじぇんない、って印象があるよ。Java だと組み込み型と、
標準ライブラリの堺があいまいだからそうなるんかなぁ、とか思ったり。

単に俺の回りがレベル低いだけかもしれんけど、Java プログラマで、
このコードがどんなバイトコードになるか、とかいちいち理解している人って
割りとふつーなの？

541 ：デフォルトの名無しさん：03/07/30 06:32

> Java だと組み込み型と、標準ライブラリの堺があいまい
？？？

> 単に俺の回りがレベル低いだけかもしれんけど
そーなんじゃない？本人のレベルも(以下略)

542 ：デフォルトの名無しさん：03/07/30 13:35

>>541
String クラスなんか、言語仕様に食い込んでるじゃん。

543 ：デフォルトの名無しさん：03/07/30 20:55

>540
いずれはそういった知識が現在のアセンブラのように
「知る必要のない知識」になるんじゃないの？

ただ、今はまだそこまでの段階ではないけどね。

544 ：デフォルトの名無しさん：03/07/30 22:30

ていうかなんですかcoutの<<って？　
ビットシフトの演算子にわざわざ別の機能割り当てるなんて
技術屋以外に理解できないようにするための細工ですか
女子高生の意味不明単語みたいに。

545 ：デフォルトの名無しさん：03/07/30 23:22

>>544
出来た当時のセンス的にはかっこよかった。
今にして思えば演算子オーバーロード悪用の典型例になっちゃったけど。

546 ：デフォルトの名無しさん：03/07/30 23:26

>>544
Cでは確かに<<は単なるビットシフトだ。
しかしC++ではストリーム演算子の意味にもなる。ただそれだけだ。
新しい言語で新しい演算子が一つや二つ増えるのがそんなに不思議か？

547 ：デフォルトの名無しさん：03/07/30 23:38

>>546
ある場面ではシフト、ある場面ではストリーム入出力と、
場面によって違う意味で使われてるというのはあまりいいことではない。

だから、C# では演算子をオーバーロードできるけど、
<< をストリーム入出力には使ってない。

548 ：デフォルトの名無しさん：03/07/30 23:47

int *p,i;
p+1とi+1の+は果たして同じ意味か？

549 ：デフォルトの名無しさん：03/07/31 00:05

同じ意味でしょう。

550 ：デフォルトの名無しさん：03/07/31 00:11

#ifdef _NDEBUG
#define TRACE(in)
#else
#define TRACE(in) std::cout << in << std::endl
#endif //_NDEBUG

TRACE("i = " << i << "k = " << k);

みたいに、適当に突っ込めてかつ可変数引数とれて便利だと思うがな。

551 ：デフォルトの名無しさん：03/07/31 00:12

>>548
例が悪いよ、++/--にしとけ。

552 ：デフォルトの名無しさん：03/07/31 00:12

f()と1+(1)の()は？

553 ：デフォルトの名無しさん：03/07/31 00:18

>>546
今までC++の<<は気に食わなかったがすっきり納得した。
2chでは>>がレス先を意味するのと同じようなもんだな。

554 ：デフォルトの名無しさん：03/07/31 00:20

static_cast< int >( a, b );と
myoriginal_cast< int >( a, b );の

,は意味が違うな

555 ：デフォルトの名無しさん：03/07/31 01:08

Φ's

556 ：デフォルトの名無しさん：03/07/31 04:08

>>550
>>、<<は既存の演算子の意味を上書きするというのがまずい。
文字列に対する+（連結）も同様。
構文唐としては悪性だ。

新たな演算子シンボルを定義できるべきだろう。

557 ：デフォルトの名無しさん：03/07/31 04:46

int statjc_cast,doubIe;

statjc_cast<doubIe>(3);

558 ：デフォルトの名無しさん：03/07/31 04:51

おまいはベクトル積にドットやクロスを使うなと主張するタイプですな。

559 ：デフォルトの名無しさん：03/07/31 06:11

別に既存の演算子の意味を上書きしててもかまわないと思うけどな。

560 ：デフォルトの名無しさん：03/07/31 08:52

そんなに気になるなら、
ソース群から演算子オーバーロードしてる部分を
リストアップするようなツールでも自作しておけばいい。
古い頭でいらつく事を言わないでくれな。もっと柔軟に他人とうまくやってくれ。

561 ：デフォルトの名無しさん：03/07/31 22:15

>>559
それが直感的に分かりやすい場合にはまあいいんだけどな。
元の意味とあまりにも意味が違うオーバーロードの仕方は避けた方がいい。

cout << の場合、なんとなく出力っぽい(見た目が)って点では問題ないんだけど、
元の << の意味と全然違うって部分は問題。
俺の私見としては、cout << の用法はぎりぎりセーフってところかな。
悪くはないけど、見習うべきものではない。

562 ：デフォルトの名無しさん：03/07/31 23:35

A a;
B b;

printf("%s\n", a.print());
printf("%s\n", b.print());

考えただけで面倒。
Ｃ＋＋なりに表現力を高めようと努力してんだしいいじゃん。

>元の意味とあまりにも意味が違うオーバーロードの仕方は避けた方がいい。
偉そうに言ってるが当然の話。でも、あんたの考えはあまりにＣオンリーになってるし、
もっと他の言語にふれて表現方法を学んできてもいいんじゃないの？

563 ：デフォルトの名無しさん：03/08/01 00:50

cout("hoge1","hoge2","hoge3!,...）;
で別に良いじゃん。

564 ：デフォルトの名無しさん：03/08/01 01:03

>>563
型情報がなくなるのでそれは無理。

565 ：デフォルトの名無しさん：03/08/01 01:48

ビヤーネ先生のバイブルによれば、

最初は入力も出力も "=" にしようと思ったけど、ほとんどの人は入力と出力の
演算子が異なっているほうがよさそうだったし、おまけに右結合なので不都合だった。
で、"<" と ">" も試してみたのだけど、人々の頭には「より大きい」「より小さい」という
意味が強く刷り込まれていて適当ではなかった。
その点 "<<" ">>" ならそこまでの絶対的な刷り込みは無く、図形的な対称性の点でも
バッチリなので、これに決定した。

のだとか。C++学習時に既に強い刷り込みのあった人はお気の毒。

566 ：デフォルトの名無しさん：03/08/01 02:40

java だと算術右シフトか論理右シフトのどっちかが >>> だけど
C++はどうだったっけ？
別に何も定義されてないなら <<< と >>> でよかったのに。

567 ：デフォルトの名無しさん：03/08/01 03:22

>>566
モラルハザードですか・・・

568 ：デフォルトの名無しさん：03/08/01 04:21

>> 545

俺も同意見だ。
けど、oHello World レベルで、この話が出てきてしまうあたりは、
いろいろと戦略ミスだったような気もする。

569 ：デフォルトの名無しさん：03/08/01 11:34

最初からCは、同じ記号の演算子に複数の意味を与えてたからなぁ。
++や--は前置・後置で異なる動作をするし、
*は間接参照演算子だったり、掛算の演算子だったりする。
&もビット積だったり、アドレス演算子だったり。
,は順次演算子だったり、引数のセパレータ(?)だったり。

C++のストリームの<<とかは、Cの伝統を引きずってるだけだと思われ。

570 ：デフォルトの名無しさん：03/08/01 11:45

あんま関係ないが、Perlの<=>演算子は好きだ。

571 ：デフォルトの名無しさん：03/08/01 12:50

C++は柔軟すぎる仕様が逆に難しくしているよな

572 ：デフォルトの名無しさん：03/08/01 13:09

基本理念が柔軟性＞容易さだからしょうがない。

573 ：デフォルトの名無しさん：03/08/01 14:44

なんでC++(Javaもだけど）にはVBのwithに相当する機能が無かったのだろうか

574 ：デフォルトの名無しさん：03/08/01 15:22

VBは知らん。PASCALのwithと同じか？

575 ：デフォルトの名無しさん：03/08/01 15:58

>>573
んなもん要らないじゃん。
必要なら参照なりポインタなりを保持する一時変数を使えばいいんだから。

つーか、多用されたら見難いだけじゃん。

Java? んなもん知らん。

576 ：デフォルトの名無しさん：03/08/01 16:03

>>575
禿道。

with が乱立して　場合によってはwithが100行ぐらいあると、もうどっちがどっちだか混乱の元。

VBで不思議だと思うのは、配列が LBound と UBound 形式なところ。アフォかと馬鹿かと
For などのループに continue がないところ。if行が増えてインデントが画面の右端に達する馬鹿をなんとかしろと

577 ：デフォルトの名無しさん：03/08/01 16:06

俺はWith相当のものは欲しいがなあ。
見づらいだの分かりにくいだのは、#if とかも使い方によっては同じでしょ。
それじゃ理由にはならない。
必要ないと思う人は使わなきゃいいだけだし。

578 ：デフォルトの名無しさん：03/08/01 16:40

>>577
#if は無いと大変なことになる・・・
無い方がソースが汚くなる。

VBに関しては、別にソースなんか汚くて当然ぐらいの勢いを開発環境やツールやらからヒシヒシ感じるけど。

579 ：デフォルトの名無しさん：03/08/01 17:31

コンパイル遅すぎなのは困る。
ＶＣ＋＋でリビルド間違ってクリックしちまった時には泣けてくる。
いやぁ。いまビルド中なんで２ｃｈやってんだけどね。

580 ：デフォルトの名無しさん：03/08/01 18:30

>>579
同志よ。

581 ：デフォルトの名無しさん：03/08/01 18:53

>>573
Pascalでは変数宣言を途中でできないから、withという苦しいものを持ち込ん
だんだと思う。
Cはブロックの先頭なら変数を定義できるし、一緒に初期化もできる。
withなんてまったく必要ない。
むしろネストしたときの可読性の悪さを考えれば、百害あって一利なし。

582 ：デフォルトの名無しさん：03/08/01 18:56

>>579
激烈に同意

>>573
withはいらね。
どうしても欲しいなら
#define with(exp) if(exp)
とでも汁

with( hoge* obj = 長ったらしい式 )
{
　obj->...;
　obj->...;
}
else
{
　nullだったときのエラー処理。
}

みたいに書けるぞ。

nullのときは自動的に処理をスキップできるうえきれいな構文でエラー処理できる、オブジェクト名にコンテキストにふさわしい名前を自分で選べるし、入れ子も可能だ。
操作対象を毎行明示するので可読性も損なわれない。

583 ：デフォルトの名無しさん：03/08/01 19:46

オーバーロードと標準変換(特にポインタ)って相性悪くない？

#include<iostream>
using namespace std;
void f(void*){ cout << "void*" << endl; }
void f(const char*){ cout << "const char*" << endl; }

int main()
{
f((int*)0);//void*
f((char*)0);//const char*
}

584 ：デフォルトの名無しさん：03/08/01 19:52

>>582

おえ

585 ：デフォルトの名無しさん：03/08/01 19:52

オーバーロードは関数だけにしましょう

586 ：デフォルトの名無しさん：03/08/01 19:57

Windowsは「本当に」C++で作られているので
難しいのは仕方ない。あきらめれっ

587 ：デフォルトの名無しさん：03/08/01 20:01

Cじゃないの？

588 ：デフォルトの名無しさん：03/08/01 20:04

漏れ的にはリファレンスｲﾗﾈ

589 ：デフォルトの名無しさん：03/08/01 20:05

マニュアルもｲﾗﾈ

590 ：デフォルトの名無しさん：03/08/01 20:07

人生ｲﾗﾈ

591 ：デフォルトの名無しさん：03/08/01 20:07

ヘルプはﾀﾞｲｽｷ

592 ：デフォルトの名無しさん：03/08/01 20:08

Longhornって.NETなんでしょ
だったらC#でつくられてるの？

593 ：デフォルトの名無しさん：03/08/01 20:10

>>587
見た目C++を使っていてもCみたいなもんだろ。
手続き型とオブジェクト指向を両方学んだ人は、どうしても一方の影響を受ける訳で

594 ：デフォルトの名無しさん：03/08/01 20:49

>579
>581

Pascalは変数の途中宣言を禁止しているから
コンパイルが速いのだ。
Delphiのコンパイルは爆速だよ。
オレは数行書くごとにコンパイルしてるしｗ

595 ：デフォルトの名無しさん：03/08/01 20:50

DelphiこそXP時代の救世主だね

596 ：デフォルトの名無しさん：03/08/01 20:59

> Pascalは変数の途中宣言を禁止しているから
> コンパイルが速いのだ。

そんなに変わるか？

597 ：デフォルトの名無しさん：03/08/01 21:00

俺はCOBOLが全く理解できないんですけどSEになれますか？
秋にある２種は言語埋まんないと受かんないしなぁ

598 ：デフォルトの名無しさん：03/08/01 21:02

ついでに最適化もろくにしてないから速いんだよ：P

599 ：デフォルトの名無しさん：03/08/01 21:03

後、前方参照も不可だしね（一部例外あり）。
左辺代入のみに統一していることも覚えておけば初心者には有益だ。

これらを爆速の一因に加えといてね。
むかしのVBマガジン呼んでいたら、インチキをしているので早いんだ、という記事が
書いてあったワ。これにはさすがに(^^;)

600 ：デフォルトの名無しさん：03/08/01 21:04

get！

601 ：デフォルトの名無しさん：03/08/01 21:39

>>594
途中宣言はほとんど関係ない。
Pascalのコンパイルが早い理由は１パスだからだ。

602 ：デフォルトの名無しさん：03/08/01 21:44

C/C++も大量の#includeさえ無ければそれなりに速いと思うぞ

603 ：デフォルトの名無しさん：03/08/01 21:46

今までプログラムをしてきて、演算子をオーバーロードして読みやすくなるときと読みにくくなるときっていうのは、
演算の意味よりも、関数の性質による所が多いような気が最近しています。
行儀の悪い演算子オーバーロードの今ある説はあんまり受け入れたくないって最近思ったりしたり・・・
というのは、
たとえば足し算でみると

add( a , add( b , c ) ) == a + b + c

なのですが、

a + b + c == b + a + c == c + b + a ...

といった性質があるわけで、これを上記の関数で表現されてしまうと
これを整理して考えてみよとか言われると訳ワカメって感じです。

数学でいうところの
結合法則とか交換法則とか分配法則とか左右を入れ替えると符号がひっくり返るとか(外積)
こういった性質が関数にあるときに、これを演算子や優先順位に反映しておくと、見通しが良くなるのでこれを中心にして考えたほうが良いと思う。
関数名を真ん中に置く、演算子に優先順位をつける(分配法則用)、これが重要意味を持つときに演算子オーバーロードを考えるのが正しいと思う。

出力に関しては例えば、一旦文字列に変換する形式をとれば、
これには
"a" + ( "bc" + "def" ) == ( "a" + "bc" ) + "def"
のように結合法則があるのでこれは良いと思います。
ひと工夫すれば入出力ともにかなり面白いことができそうな気がしています。(出力形式を分配するとか)
いずれにしても、最近は演算子の意味が違うからダメという意見には賛成できないです。

604 ：デフォルトの名無しさん：03/08/01 21:47

ちなみにこんな物が欲しい

// 演算子の優先順位定義、さすがに宣言以下ファイル中全部に反映は厳しい。
operator VectorOperator
{
　　infixl 2 `op` : Vector Vector::outerProduct( const Vector & , const Vector & ) ;
　　infixl 1 + : Vector ::operator + ( const Vector & , const Vector & ) ; // 最近どの演算子が使われるかあいまいで困るので
　　infixr 0 = : Vector & _( Vector & a , const Vector & b ) { a.Let( b ) ; return a ; } // 直接書けても良いと思う
} ;

// 利用の仕方
void test()
{
　　using operator VectorOperator ;
　　Vector a ;
　　Vector b ;
　　Vector c ;
　　Vector d ;
　　d = a `op` b + c ;
}

605 ：デフォルトの名無しさん：03/08/01 21:48

>>601
運用上どう考えても速くはならないよ。
プリコンパイルなしだと地獄。

606 ：デフォルトの名無しさん：03/08/01 21:48

>>602だった。

607 ：デフォルトの名無しさん：03/08/01 21:50

>>603-604
ML使えば幸せになれるぞ。たぶん。

608 ：デフォルトの名無しさん：03/08/01 21:52

>>607
C++でやれなきゃヤダ

609 ：デフォルトの名無しさん：03/08/01 22:05

そういうプリプロセッサを作ればいい
前にLISPで作ったよ

610 ：デフォルトの名無しさん：03/08/01 22:06

>>609
プリプロセッサじゃtemplateが使えないからヤダ

611 ：デフォルトの名無しさん：03/08/01 22:07

そろそろママ怒りますよ？(ﾍﾞｼｯ

612 ：デフォルトの名無しさん：03/08/01 22:08

>>611
うえーんママの意地悪～

613 ：デフォルトの名無しさん：03/08/01 22:16

プリプロセッサというか、トランスレーター作るという案は悪くない。

614 ：デフォルトの名無しさん：03/08/01 22:30

yaccなりbisonなりで好きな文法からC++コードを生成するようにすればいいじゃん

615 ：デフォルトの名無しさん：03/08/01 23:14

今、参考書のダイテル(C++)の本をやっているんでつが、この本は答えが
載っていない！
なので単独スレ[ダイテルの(C C++ Java)の練習問題の答え]を立てよう
と思っているんだがどう？
又そんな過去スレがあれば情報キボンヌ

616 ：デフォルトの名無しさん：03/08/01 23:38

VB/Delphi は IDE 上のエディタ中で随時字句解析をやっちゃうから速いのだと思ってんだが、違うのか？

617 ：デフォルトの名無しさん：03/08/02 00:02

>>616
違～う

618 ：デフォルトの名無しさん：03/08/02 00:11

>>615
単発スレを立ててたっぷり叩かれてくれ。

619 ：デフォルトの名無しさん：03/08/02 00:14

>>616
Delphiは、コマンドラインでコンパイルしても速いからそれはないかな。
エディタで編集するとディスクキャッシュにひっかかって速くなるってのはあるだろうけれど。
ディスクアクセスは思った以上に遅いからね

620 ：529：03/08/02 00:17

Javaのコンパイルってちょっぱやなきがする。
IBMのVisualAgeを使った感想...

621 ：616：03/08/02 00:22

>>617
違うのか。認識改めてきます。

>>619
> Delphiは、コマンドラインでコンパイルしても速いからそれはないかな。
やっぱそうか、PASCAL は LR(2) がうんにゃら LL(1) がうんにゃらで
ユニット方式でうんにゃらとかよくわからん話を聞いたことがあるので、それで速いのかもしれないすね。

> ディスクアクセスは思った以上に遅いからね
というか、今の時代のボトルネックは多分ここですよね。ビルド中はアクセスランプつきっぱで
CPU利用率は思ったほど高くないみたいな。

622 ：616：03/08/02 00:26

>>620
JVM のバイトコードは Java からコンパイルし易いようにできてるとか。できてないとか。
そんな話を聞いたことがあるような、ないような。

623 ：デフォルトの名無しさん：03/08/02 00:26

おまえらRAMディスク使え
今はメモリ安いからガンガン積める

624 ：616：03/08/02 00:42

>>623
Win32 用のRAMディスクドライバってある？
DOS 時代は使ってたけど(640KB超えてる分)
たしかに今の時代にこそ欲しい仮想デバイスな気がしますね。

625 ：デフォルトの名無しさん：03/08/02 01:20

ファイルをマップして使っても変わらない？

626 ：デフォルトの名無しさん：03/08/02 01:28

Google Search: RAMディスク windows
http://www.google.com/search?lr=lang_ja&q=RAM%83f%83B%83X%83N+windows

627 ：デフォルトの名無しさん：03/08/02 01:58

>>620
VAJって変更箇所しかコンパイルしないよ。(インクリメンタルコンパイルって奴)
あれ、オレ違うこと言ってる？
ちなみに、VAJのVMはUniversal Virtual Machineってので、VisualAge Smalltalk
とかと同じ。何でVAJアボーンしたんだろ。プンプン。

628 ：デフォルトの名無しさん：03/08/02 02:02

> 何でVAJアボーンしたんだろ。プンプン。
極悪企業 S*N の陰謀。
SU* は MS 以上の殿様企業

629 ：山崎渉：03/08/02 02:03

（＾＾）

630 ：デフォルトの名無しさん：03/08/02 11:33

>>624
今どきの OS だと、仮想記憶サブシステムや標準のキャッシュシステムが
充実してるから、わざわざ手作業で RAM ディスクを作るメリットは少ない
と思うぞ。

631 ：デフォルトの名無しさん：03/08/02 11:58

いまどきのコンパイラだと、ファイルの読み込み時間はコンパイル時間のうちの僅かでしかないよ。
RAMディスクなぞ使わず、通常利用のメモリーのままにしておくが吉、それよりキャッシュ大量に積め。
最近のＣＰＵ⇔メモリー間のスピードのギャップは半端じゃないぞ、今時のＣＰＵは殆ど空回りだからな。

632 ：デフォルトの名無しさん：03/08/02 12:47

>>616,620
IBM のコンパイラだから速いんだと思うよ。
Sun の javac だと結構遅い。というか Sun のが遅すぎ。

633 ：デフォルトの名無しさん：03/08/02 12:56

c++ってhファイルの宣言とcxxファイルの定義別に書くけどあれは非常に面倒くさくて嫌い。
C#とかJavaはそこが楽だと思う。

634 ：デフォルトの名無しさん：03/08/02 13:28

しかし見通しが悪くなると言う諸刃の剣

635 ：デフォルトの名無しさん：03/08/02 14:55

>>634
その辺は JavaDoc なり XML Documentation なりを。

636 ：デフォルトの名無しさん：03/08/02 15:30

サビ残の徹底取り締まりを実現するスレ
http://society.2ch.net/test/read.cgi/soc/1058709814/

637 ：デフォルトの名無しさん：03/08/02 16:12

>633

Java、C#など→定義と実装を同時に書く
→そのためにコーディングは楽だが定義を一覧しづらい

Delphi、C++→定義と実装を別に書く
→そのためにコーディングで面倒な面がある。
　　ソースを読むのは楽。

ていうのがあるんですが、
どちらにしろ、ツールを使えば解決する問題なわけで。。。

上の場合→定義を一覧できるIDEを使えば何の問題もない
下の場合→クラスウィザードなどを使えば、コーディングは上の場合と同じ

これからの時代は、プログラミング言語を語る時は
ツールの存在を前提として語るべきではないか？
テキストエディタでコーディングする時にどちらが便利か、
という議論は無意味でしょう。

638 ：デフォルトの名無しさん：03/08/02 16:42

IDEのクラスビューはそこそこ便利なんだけど、
クラスが多くなってくると重くなったり、メンバが名前順にソートされたり、
（普通メンバって関連するものをまとめて近くに書くじゃん？宣言の順番が理解の助けになったりする）
コメントも反映されないし。
ソース直接見た方がわかりやすいって事もある。

俺は最初Java風がいいと思ったけど最近はC++風を見直し中。

639 ：デフォルトの名無しさん：03/08/02 16:59

ある程度高機能なエディタを使いこなす奴は言語が変わっても巧く対処するが、
特定のIDEに特化した開発スタイルの香具師に限って他の環境に弱い罠。

640 ：デフォルトの名無しさん：03/08/02 18:41

ところがＲＡＭディスクは再起動するとデータが消滅するという特性を生かして
作業場所とか出力先をこれにしておくと結構便利な罠。スピードのメリットはない。

>>637
Delは定義と実装別だけど、同じファイルの中に書くよ。

641 ：デフォルトの名無しさん：03/08/02 22:54

>>635
ソース見づらくても Doxygen なり JavaDoc なりでドキュメントを
書けばいいじゃんというのは、ドキュメント見てるだけで済む内は
幸せ。でもドキュメントを読みつつ、いざそのコードに手を入れよ
うと思うと、結局は手作業でソースを探して対応する行に飛ぶとい
う作業が発生するから、根本的な解決にはならない。

>>637
VC++.net の IDE は割とよくできてると思うけど、それでも
template 絡むとまだまだ。C++ template の仕様が逝ってる
のは確かだけど、あの複雑さは訳あってのことだから、俺には
非難できん。

俺のトコロだと、結局は C++ を素のエディタで書いてる。
ctags, etags あたりは必需品だけど。

642 ：デフォルトの名無しさん：03/08/03 00:42

>>639
まげしく同意同意。
IDE でしか作業した事ない香具師は他の IDE に馴染むのに時間かかるよね(過去の漏れ)。
汎用のテキストエディタである程度やってみると、いろんな IDE を意外と拒絶反応なく受け入れられるようになるよね。

643 ：デフォルトの名無しさん：03/08/03 08:27

でもVC,VBの　Ctrl+R≠検索　だけは納得いかない。

644 ：デフォルトの名無しさん：03/08/03 08:47

検索はCtrl-sだな

645 ：デフォルトの名無しさん：03/08/03 10:00

646 ：デフォルトの名無しさん：03/08/03 11:07

ここに居るのは、２０～３０歳代の連中がほとんどだと思うが、
お前らの上司は、ちゃんとC++理解してるか？
オブジェクト指向なプログラミングも含めて。

647 ：デフォルトの名無しさん：03/08/03 12:00

バリバリの現役COBOLerですが何か？

でもCOBOLerの「実力」が発揮されるのはRDBMS開発の時だと言ってみる。

648 ：デフォルトの名無しさん：03/08/03 13:55

>>646
上司は理解できていませんが、開発には携わらないので無問題です。
つーか、現場トップは私だ。文句なんか言わせるもんか。

649 ：デフォルトの名無しさん：03/08/03 16:46

上司クラスになっちゃえばもう全然パラダイム違うから問題なしでしょ。
お互い違う世界に生きてる事を自覚してるし。
問題なのはちょっと上の先輩クラス
差分プログラミングとかを OO だと勘違いしてたりする。
藻舞頼むからそこに virtual 付けとけと小一時間。

650 ：デフォルトの名無しさん：03/08/03 16:55

上司がC++を禁止してCで組むことを強制する職場もあるわけだが
C++を間違った知識で批判してるし
説明しても聞いちゃいねぇ　もー絶滅してケロ

651 ：デフォルトの名無しさん：03/08/03 17:18

何だかなー。
「C++はダメ。Javaを使え」
というのは分かるが
「C++はダメ。C言語を使え」
というのはよく分からないな。

652 ：646：03/08/03 17:53

>>648
> >>646
> 上司は理解できていませんが、開発には携わらないので無問題です。
> つーか、現場トップは私だ。文句なんか言わせるもんか。

　そういう環境は、問題ないね。
　理解出来てない上司の方が有難い。

653 ：デフォルトの名無しさん：03/08/03 17:54

>>649
> 上司クラスになっちゃえばもう全然パラダイム違うから問題なしでしょ。
> お互い違う世界に生きてる事を自覚してるし。

　自覚してれば、どっちにしても問題ないだろうけどね。

> 問題なのはちょっと上の先輩クラス
> 差分プログラミングとかを OO だと勘違いしてたりする。
> 藻舞頼むからそこに virtual 付けとけと小一時間。

　そういう先輩クラスの人間が上司だったら、
　最悪なんだな。

654 ：646：03/08/03 17:57

>>650
> 上司がC++を禁止してCで組むことを強制する職場もあるわけだが
> C++を間違った知識で批判してるし
> 説明しても聞いちゃいねぇ　もー絶滅してケロ

　やはり、そういう上司のいる会社があるんだなぁ。
　いやー、可愛そう。

　え、オレ？
　オレは、上司も部下もいないから、好き放題。

655 ：646：03/08/03 18:09

で、職場開発中に分からないことがあった場合、
仲間に教えてもらうのか？
上司に内緒で 2chしてるとか？
C++が難しいと思うのは、本当に初心者だろうか？
確かに言語としては初心者にとっては難しいだろうけど、
ｏｏは、初心者にとっては、そんなに難しくないと思う。
手続き型言語での開発実績がある経験者の方が
考え方を切り替えられなくて、難しいんじゃないかな。
で、650のような事言いだす、上司が現れたりする。

656 ：デフォルトの名無しさん：03/08/04 00:44

C**という言語を作ってみようと思う。
・・・シェルから実行できないな。

657 ：デフォルトの名無しさん：03/08/04 02:50

C!!のほうがいい

658 ：デフォルトの名無しさん：03/08/04 13:30

C[[がいい

659 ：デフォルトの名無しさん：03/08/04 16:35

C{}だろ？

660 ：デフォルトの名無しさん：03/08/04 16:51

(C)

661 ：デフォルトの名無しさん：03/08/04 18:49

662 ：デフォルトの名無しさん：03/08/04 19:21

ネタスレになりました。。。

663 ：デフォルトの名無しさん：03/08/04 21:04

>>662
はじめからネタスレです。。。

664 ：デフォルトの名無しさん：03/08/04 21:17

>>655
> C++が難しいと思うのは、本当に初心者だろうか？
> 確かに言語としては初心者にとっては難しいだろうけど、
> ｏｏは、初心者にとっては、そんなに難しくないと思う。
> 手続き型言語での開発実績がある経験者の方が
> 考え方を切り替えられなくて、難しいんじゃないかな。
このへん同意。

665 ：デフォルトの名無しさん：03/08/04 22:13

>>664
キチガイ発言に同意すんなよ

666 ：デフォルトの名無しさん：03/08/04 23:23

どの辺がキチガイなのさ？
逃げないで教えてくれ。マジで頼む。

667 ：664 (!=666)：03/08/04 23:26

漏れも聞きたいな。

668 ：デフォルトの名無しさん：03/08/04 23:35

>>666,667
自分に理解できないものを理解できる奴を羨んで言ってるだけだ、スルーしる

669 ：デフォルトの名無しさん：03/08/05 07:33

変な煽りと自作自演なところ

670 ：オカマ=ザピ：03/08/05 15:34

ジサークジエン！

671 ：C++マンセー：03/08/05 18:02

あなた、いつまでも変わらないのね。
ああ、僕はconst型だ。

672 ：C++マンセー：03/08/05 18:02

この箱には何でも入る。

673 ：646：03/08/05 18:03

653は、ハンドル 646 を入れ忘れたけど、
それ以外は、646付けてるからね。

頭の固い上司は、部下への指示そのものが、
手続き型言語でのコーディング的な指示をしてそうだな。
あれしろ、これしろ、と、いちいちやり方をうるさく指図しそう。

OOが分かってる上司は、あれとこれと組み合わせて、
適当にやっとけ、あれとこれさえしっかり押さえておけば、
後でなんとでもなるからな。
というような指示を部下に出しそうだな。

674 ：デフォルトの名無しさん：03/08/05 18:17

漏れの上司は
「プログラマーにもっとも必要な能力は責任感、そして無精であることだ」
と堂々と言う。

675 ：デフォルトの名無しさん：03/08/05 18:18

俺も>>664の引用に同意・・・

676 ：C++マンセー：03/08/05 18:18

>>673
ああ、
新しい仕事の仕様書は

びっくりするほど手続き型。

びっくりするほど手続き型。

びっくりするほど手続き型。

ﾁｸｼｮｳ

677 ：デフォルトの名無しさん：03/08/05 19:49

あ～あ、こわれちゃった

678 ：デフォルトの名無しさん：03/08/05 20:06

>>674
上司正しいよ

無精であることは重要

679 ：デフォルトの名無しさん：03/08/05 20:28

C++が難しいのはVCのせいだと思うんです
VBみたいなC++ってないですか？

680 ：デフォルトの名無しさん：03/08/05 20:32

>>679
VC++.NETはVBみたいな(以下略

681 ：デフォルトの名無しさん：03/08/05 20:58

>>679
VBみたいなの意味がわからないけど、
RADということなら、BCB、VC++.NETがそれにあたる。
コードでGUIを作るのは確かに難しい。ポトペタが楽。

682 ：デフォルトの名無しさん：03/08/05 21:31

>>679
あってると思う。
C＋＋が難しいのではなくてVC＋＋が難しい。

ボタンとかも作りにくいし
変数とか、関数を作るのにも、ツール操作で作り自動的に
コードを書いて便利なはずだが、初心者にとってはいい迷惑なだけで
まったく理解できなくなる。
コードがいっぱいかかれ、「mainはどこだよ！？コン畜生！」と思いVC++断念。
ダイアログを出してメッセージのやり取りまでがなんと難しいこと。

だから自分は、すべてフリーのBCB5.5＆秀丸でアプリケーション作成している。
こっちのほうが楽？

683 ：デフォルトの名無しさん：03/08/05 21:32

C++Builderってそうなんじゃないの？
C++のVB版(？)って聞いたような･･･

684 ：デフォルトの名無しさん：03/08/05 21:34

ドスケベホイホイで逝ってしもた
http://www.boreas.dti.ne.jp/~keitarou/

685 ：デフォルトの名無しさん：03/08/05 21:35

>>682
フリーのBCB5ってなんだよ？
ちゃんと金払え。

686 ：GET! DVD：03/08/05 21:35

★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★
☆★☆★☆★　新商品　ゾク・ゾク　入荷　☆★☆★☆
★☆　　　　　　　　　　　　　　　　　　　　　　　
☆★　送料激安！！　　送料激安！！　　送料激安！！
★☆　　　　　　http://www.get-dvd.com.tw　　　　　　
☆★　　激安アダルトＤＶＤショップ　　　　　　　　
★☆　　　　お買い得！！　1枚500円～　急げ！　　　
☆★　　　　インターネット初！「きたぐに割引」　　
★☆　　　　北海道・東北の皆様は送料も激安！　　　
☆★　　　　　　http://www.get-dvd.com.tw　　　　　　
★☆　　　　　　　　スピード発送！　　　　　　　　
☆★　　　　　　http://www.get-dvd.com.tw　　　　　　
★☆　　　　　　　　商品が豊富！　　　　　　　　　
☆★　　　　　　http://www.get-dvd.com.tw　　　　　　
★☆　　　　　　　　　　　　　　　　　　　　　　　
☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆

687 ：６８２：03/08/05 21:37

>>685
アホか、フリーのコンパイラがあるんだよ。

688 ：デフォルトの名無しさん：03/08/05 21:37

>>682
> C＋＋が難しいのではなくてVC＋＋が難しい。
でも結局そうなってしまったのはライブラリがC++で作られていたからだったりする。
BCBなんてOWL(C++ライブラリ)を捨ててVCL(Delphiライブラリ(not object pascal))使っているしな。

689 ：直リン：03/08/05 21:38

http://homepage.mac.com/maki170001/

690 ：デフォルトの名無しさん：03/08/05 21:39

>>687
アホはおめーだ。フリーのコンパイラはBCCだ。
ついでに言えばGUIライブラリはついておらず
GUI作成はMFC以上に難しいぞ。
メッセージボックス出す程度なら簡単だがな。
お前フォーム作れないだろ。

691 ：６８２：03/08/05 21:45

>>690
なるほどね、多分もっともな意見だ。

フォームは難しいが、VC++でお絵かきするとスクリプトが吐き出されるだろ。
拡張子は忘れたが、そのファイルから、切り取って持ってくる。

GUIを作る際に秀丸で一から書き上げることで、俺の気がつかないうちに
VC++が勝手に邪魔しないですむ。だから全て動作を把握できる。

正直お勧めできない。

692 ：デフォルトの名無しさん：03/08/05 21:49

援交女をビデオに収録
当然モザイクなし！
ちゃんと確認できるよ
http://www.cappuchinko.com/

693 ：デフォルトの名無しさん：03/08/05 21:52

玄人にもお勧めできない

694 ：デフォルトの名無しさん：03/08/05 21:59

秀丸って辺りが難だが・・・
VC++が難しいのではない、MFCの仕様が変なのだ。

695 ：デフォルトの名無しさん：03/08/05 22:00

BCBだと１日の仕事が、
VC++だと一週間以上の仕事になったりする。
それがGUI。
恐るべし。

696 ：デフォルトの名無しさん：03/08/05 22:35

C++なら、GUIは自分でライブラリ組んで作ってみろ。
ちなみに俺は全てのメッセージで"Onなんとか"メソッドを呼び出すWindowのクラスを作り
それから派生させてButtonとかGroupBoxとか作ってる。必要な仮想関数をオーバーライドして。
一回ライブラリを作れば楽だよ。
ちなみにウインドウは
RWindow r;
r.Create(NULL,"aiueo","class1",0,0,200,200);
これだけで出る。(Rは僕の名前のイニシャル)。まあ何もしないウインドウを出すなんてまれだけど。
あとはC#のようにWindowクラスを継承した新しいWindowクラスを作り、そこにButtonやGroupBoxをメンバ変数として宣言する。
そいつらからのメッセージは最初のRWindowで定義されたOnCommand(RWindow* r)等のメソッドで全て拾うことができる。
この親ウインドウに送られてくるメッセージには発生したクラスのポインタが入っていて、上手い具合にRWindowにポリモーフィズムして、Javaのようにsender(引数) == &Button1（メンバ変数）というふうに比べることができる。
まあ、こんなスペースでは全てを語ることはできないけど、メッセージの処理を上手く表現することが天国への鍵だね。
ちょっと工夫すれば面倒くさいウインドウプロシージャの定義は1個だけで済む。
最近は自作GUIも作ったりなんかしてるね。おもしろいよ。
はっきり言ってダイアログエディタでダイアログ作って個別にウインドウプロシージャ定義してDialogBoxで表示なんて、馬鹿のすることだよ。

697 ：デフォルトの名無しさん：03/08/05 22:39

＞一回ライブラリを作れば楽だよ。
そのまともなライブラリを作るのが大変なんじゃないかぁ。
それにコントロールのレイアウトどーすんだよ・・・。

698 ：デフォルトの名無しさん：03/08/05 22:41

>>697
レイアウトなんて紙に書けばいいんだよ。
ちなみにこのライブラリはゲームのエディタ作ろうかと思い立って3日で書いたけどライブラリとしてそれなりの形になったよ。

699 ：デフォルトの名無しさん：03/08/05 22:42

>>695
VC++だと可能なことが、
BCB/BC++だと不可能であったりもする。

700 ：デフォルトの名無しさん：03/08/05 22:45

おれは基本的にダイアログベースアプリだが。
これで別に不自由したおもいはないね

701 ：デフォルトの名無しさん：03/08/05 22:50

へーそうですか。

702 ：696：03/08/05 22:51

ま、ダイアログベースにも良い所はある。
バカは言い過ぎた。
俺はなんでもかんでもカプセル化してしまう性質だから。

703 ：デフォルトの名無しさん：03/08/05 22:54

公開してくれ

704 ：６８２：03/08/05 23:11

>>696
肝心な部分は非公開で、ライブラリだけずらずら載せてあった"使えない本"で>>696
と同様に、Windowsの初期画面をクラス化していたので自分も試みたが出来んかった。
以下の関数部分をクラスのメンバーに出来なかった。

int WINAPI WinMain(HINSTANCE hInstance , HINSTANCE hInstance ,PSTR pstr, int c )

LRESULT CALLBACK WndProc(HWND hwnd , UINT msg , WPARAM wparam , LPARAM lparam)

どうやっているのか俺も興味あります。
キボンヌ。

705 ：デフォルトの名無しさん：03/08/05 23:16

>>704
696じゃないけど、単にstaticにするだけだよ

706 ：デフォルトの名無しさん：03/08/05 23:17

>>704
おっと、WinMainはスタートアップから呼ばれるんだから無理だよ？

707 ：696：03/08/05 23:21

>>704
俺はMainはそのまま使ってる。

WndProcは、メソッドを直接RegistWindowに渡すのではなく、まず１つだけ普通の関数として定義する。
LRESULT WndProc(HWND hwnd , UINT msg , WPARAM wparam , LPARAM lparam)
{

}
で、ウインドウクラスの中に
LRESULT MyWndProc(HWND hwnd , UINT msg , WPARAM wparam , LPARAM lparam)
というメソッドを作るの。
そして、さっき定義したProc↓の中で
LRESULT WndProc(HWND hwnd , UINT msg , WPARAM wparam , LPARAM lparam)
{
window->MyWndProc(hwnd,msg,wparam,lparam);
}
と直接ウインドウクラスのメソッドにパラメータを渡してやるわけ。
俺はウインドウクラスをvectorで持ってHWNDが一致したウインドウクラスのMyWndProcを呼び出してやってる。
705はもっと良いアプローチなのかもしれないけど、これはこれでいける。

708 ：696：03/08/05 23:23

return window->MyWndProc(hwnd,msg,wparam,lparam);
ね。

709 ：696：03/08/05 23:26

何度もスマソ
static LRESULT CALLBACK WindowProc(HWND hWnd,UINT uMsg,WPARAM wParam,LPARAM lParam)
{
return window->MyWndProc(hwnd,msg,wparam,lparam);
}

710 ：デフォルトの名無しさん：03/08/05 23:27

>>707
>window->MyWndProc(hwnd,msg,wparam,lparam);
そのwindowはどっから引っ張ってきた？
やっぱGetWindowLong？
内部定義ありの言語(Schemeとか)だと
直接上位のローカル変数とか見えるんだけどね。

711 ：６８２：03/08/05 23:29

>>706
WinMainなしで、どうやってGUI画面起動するのでしょうか？

それがよく分からない。

だから、WinMainをクラスの外部に置いて・・と、いろいろやったけど

>>707
なるほど。
WinMainはむき出しですね・・？
本のサンプルは、
include "win.h"

main(){
WIN win;
win = new Create(...)
}

みたいな感じ。これだとすっきりして美しいと思う。
>>705さんが言ってるのはこういうのことなのかな？

712 ：696：03/08/05 23:30

>>710
WindowListっていう全てのウインドウのハンドルへの参照を保持するクラスがあって、forで回して一致したものを持ってくる。
上のコードはその辺略してるけど

713 ：デフォルトの名無しさん：03/08/05 23:34

Delphiなら10分でできるGUI設計に
JavaやVisualC++だと数時間かかる。。。。

これを不条理と呼ばないで何と呼ぶのか。。。。

714 ：デフォルトの名無しさん：03/08/05 23:35

>>712
なるほど。
その作りは窓増えるとオーバヘッドが気になってくる。
そろそろコールバックも言語機能の一部になって欲しいね。
GUIでは必ずと言っていいほど使う仕組みだし。

715 ：デフォルトの名無しさん：03/08/05 23:47

VCLが楽でいいね

716 ：デフォルトの名無しさん：03/08/05 23:51

>>713
C#でも10分・VBでも10分・Forte(Java)でも10分

717 ：デフォルトの名無しさん：03/08/05 23:56

>>713
それは単にあなたがDelphiに慣れているだけかも知れない。

718 ：デフォルトの名無しさん：03/08/05 23:58

Delphiは独自＆後発だけあって自由度高い（＝某の思うが侭）ね。
実質Windowsでしか使えないけど。

719 ：デフォルトの名無しさん：03/08/06 00:00

C#は独自＆後発だけあって自由度高い（M$の思うがまま)ね。
実質Windowsでしか使えないけど。

720 ：デフォルトの名無しさん：03/08/06 00:00

Javaは独自＆後発だけあって自由度高い（M$の思うがまま)ね。
クロスプラットフォームだけど。

721 ：デフォルトの名無しさん：03/08/06 00:01

>>714
C# の event がそうじゃない？

>>718
ヘジたんがM$に買収されちゃったから
そのDelphiの精神も今はC#に受け継がれてるわけで。

722 ：713：03/08/06 00:12

ていうか。。。

C++のSTLなんかは「意味のある複雑さ」なんだけど
VisualC++のGUI設計（というかMFCの出来？）は
何の意味のない複雑さなんだよな。。。

オレはVisualC++をやって挫折して、
その後Delphiに移ったんだけど、
VisualC++で色々考えるべき複雑な部分は
何の意味もない複雑さだったと気づいた。。。

723 ：デフォルトの名無しさん：03/08/06 00:15

MFC(VC)はWin32APIに精通していなければ使えない代物だが
VCL(BCB,Delphi)はそれだけで十分使える

724 ：デフォルトの名無しさん：03/08/06 00:18

C#もそれだけで使える。ライブラリもVCLより強力。

725 ：デフォルトの名無しさん：03/08/06 00:20

そうか、C#に手を出してみるか

726 ：デフォルトの名無しさん：03/08/06 00:20

C#は残念ながらスレ違いだなあ。
Delphiも。

727 ：デフォルトの名無しさん：03/08/06 00:40

>>726
まあ、ある意味、このスレで叩かれまくってるような部分に
嫌気が差したから Delphi やら C# が開発されるに至ったわけで。

728 ：デフォルトの名無しさん：03/08/06 01:10

でさ、MFC掲示板なんかでよく見かける
「これくらい初歩ですから自分で調べてください」
ってコードがWin32APIばりばりだったりするんだよね。

APIなんか叩きたくないからMFC使ってるのに、
MFCでもできることをなんでAPIでやらないかんのかね。
#おまけにそういうコードに限ってC(=C++の機能を使わない)だし。

729 ：デフォルトの名無しさん：03/08/06 01:39

いまだにVC++を使い続けている会社が沢山あり
顧客はVC++での見積もりと比較してくれるから
おいらはDelphiを使って余裕で仕事ができます

感謝、感謝

730 ：デフォルトの名無しさん：03/08/06 02:02

エンドユーザは素人だし、
一次受けはVC++の見積もりでエンドユーザから仕事を取ってくる。
お蔭で私はVC++のために確保された期間を使ってのんびり仕事ができるわけです。

731 ：713：03/08/06 02:33

CodeProjectというVisualC++のサイトがあるんだが
ここに「Outlookスタイルの3ペインのサンプルソース」というのがあって、
VisualC++を始めた頃、そのソースを見て必死で真似ようとしてた。

で、Delphiに移ると。。。。

同じことが10分でできるやん。。。。
VisualC++をやってた頃の苦労は何だったのか。。。。

732 ：デフォルトの名無しさん：03/08/06 02:34

codeguruのほとんどのコードは無駄な気がする

733 ：デフォルトの名無しさん：03/08/06 02:41

>>731
VC++.NETなら5分だぞ。

734 ：デフォルトの名無しさん：03/08/06 06:05

>>733
どーゆー意味なの？
VC#.NETのまちがい？
それともmaneged？
VC++.NETでも結局MFCじゃないの？

735 ：デフォルトの名無しさん：03/08/06 07:32

>>734
Managed C++ 使えば C# や VB.NET と大差ないってことじゃない？
素人さんにはネイティブ C++ と Managed C++ の違いなんて分からないと。
まあでも、VC++ .NET って MFC アプリ作成ウィザードも使いやすくなってるよ。

736 ：デフォルトの名無しさん：03/08/06 08:05

>>735
便乗質問だけど、VC++.NETでMFCアプリを作って、
ビルドしようとすると、「それは古い形式です」みたいな警告でない？
あれって、「ネイティブにコンパイルしますよ」って意味なのかな。

737 ：デフォルトの名無しさん：03/08/07 01:07

Blake Stowell: C++ is one of the properties that SCO owns
today and we frequently are approached by customers who wish
to license C++ from us and we do charge for that. Those
arrangements are done on a case-by-case basis with each
customer and are not disclosed publicly. C++ licensing is
currently part of SCO's SCOsource licensing program.

http://mozillaquest.com/Linux03/ScoSource-02_Story03.html

C++もおしまいですね。

738 ：デフォルトの名無しさん：03/08/07 01:22

>>737
英語読めないけどなんとなく。。。

C++ってライセンスフリーじゃないってこと！？
よーはgif, mp3の悪夢到来！？

739 ：デフォルトの名無しさん：03/08/07 08:53

>>738
大丈夫大丈夫。SCOといえばLinuxのコードに盗用があるとか言って訴訟を起こしているが、そのせいで誰も信用してないし

740 ：デフォルトの名無しさん：03/08/07 11:33

14 名前：いやく部門投稿日： 2003/08/06(水) 17:52
Blake Stowell: SCOは現在、C++の所有権を有している。
SCOは顧客から、C++をライセンスしたいとの相談を受けることがよくあり、
そのような場合、ライセンス料を徴収している。
このような処置は顧客ごとにケースバイケースで行われており、
公に公開されたものではない。
C++のライセンシングはSCOのソースライセンスプログラムの一環である。

15 名前： Kent.N 投稿日： 2003/08/06(水) 17:54
Blake Stowell:C++はSCOが今日所有する資産の一つで、
我々からC++のライセンス供与を受けたいというお客様は
ひっきりなしにいらっしゃるので、実際にそうしています。
具体的な内容はお客様ごとにcase-by-caseで、第三者に
明らかにしない方針とさせていただいています。
C++のライセンス供与は現在SCOのSCOsource licensing programの
一部になっております。

http://jbbs.shitaraba.com/computer/bbs/read.cgi?BBS=5651&KEY=1049123895&START=13

741 ：デフォルトの名無しさん：03/08/07 18:01

VCとかBCCのC++もSCOのらいしぇんす必要ですの？

742 ：デフォルトの名無しさん：03/08/07 18:20

>>741
どんなC++にも必要ない訳だが

743 ：デフォルトの名無しさん：03/08/07 21:27

>>736
VS.NETは翻訳をゴミ（プログラマに非ず、VSを一度も使ったこともありません）に委託してしまったためそこらじゅうに誤訳がちりばめられてるだけ。

744 ：デフォルトの名無しさん：03/08/09 03:21

>>547
> だから、C# では演算子をオーバーロードできるけど、
> << をストリーム入出力には使ってない。
というか、C#の==勝手なオーバーロードは余計なお世話でウザイ

745 ：デフォルトの名無しさん：03/08/09 03:30

>>620
Eclipseにしろや。
保存と同時にコンパイルだ

746 ：デフォルトの名無しさん：03/08/09 03:50

>>632
> >>616,620
> IBM のコンパイラだから速いんだと思うよ。
> Sun の javac だと結構遅い。というか Sun のが遅すぎ。
Eclipse使えばそんなことほとんど気にしないのだが。
いまどきVisual Age for Javaは使わない。

そんなに遅いと感じるとは、J2SEのバージョンが古いだけなんじゃないかね。

747 ：デフォルトの名無しさん：03/08/09 05:02

>>745,746
EclipseはSunのコンパイラではなく内部で独自コンパイラを使っている。

そもそもjavac以外にjikesとか使ってベンチマークとったことあるかい？
５～１０倍は違うぞ。

748 ：デフォルトの名無しさん：03/08/09 09:40

>>747
まるでEclipseがJ2SEを一切使っていないかのような発言。
IBM JDK使っては最新版JDKにあわせたコードをEclipseでコンパイルできるかおい。

その5～10倍も、2秒が0.2秒になった程度ならまったく苦にならん。

749 ：デフォルトの名無しさん：03/08/09 10:45

JDKとコンパイラが同じ物だと思ってる？

750 ：デフォルトの名無しさん：03/08/09 11:27

複数のバージョン違いのJDKを入れていれば
どれを使うか選択できそれにあわせてコンパイルするが。

751 ：デフォルトの名無しさん：03/08/09 11:41

一連の発言を見ると「C++は難しすぎ」というスレには、
大量のJava厨がいるということでよろしいですね。

752 ：デフォルトの名無しさん：03/08/09 11:55

>>751
同意
ていうかJavaは余所のスレに逝ってやれﾎﾞｹ共。

753 ：デフォルトの名無しさん：03/08/09 11:58

EclipseでC++ってどうよ

754 ：デフォルトの名無しさん：03/08/09 12:02

話にならない

755 ：デフォルトの名無しさん：03/08/09 13:21

>>751-752
C++ に挫折していなければこんなスレ来ないからな。
まあたしかに C++ は(平均的プログラマには)難しすぎだとは思うけど。

756 ：デフォルトの名無しさん：03/08/09 13:26

自分の現状のスキルを割り切って妥協できる人でないと
(C++ を使うのは)難しぃ。

割り切りつつも知らない部分を自主的に勉強できる人でないと
(C++ を C++ として使いつづけるのは)難しぃ。

757 ：デフォルトの名無しさん：03/08/09 14:36

>>748,750
J2SDKの入っていない環境にEclipseだけ入れてもコンパイルできるのは知ってていってる？

758 ：デフォルトの名無しさん：03/08/11 00:30

>>751
まあチミにとっては「俺様はポインタ演算でも
メモリリークでもバグ大量生産でもなんでも悪循環おこすことができるから
Java厨よりも偉い」と思い込み勘違いしたいのだろうな。

759 ：デフォルトの名無しさん：03/08/11 00:55

>>755
> >>751-752
> C++ に挫折していなければこんなスレ来ないからな。
> まあたしかに C++ は(平均的プログラマには)難しすぎだとは思うけど。

いや違う。俺様は>>6や>>15のなどのような発言に納得できないからレスしているだけだ。
おぬしも勘違いするな。

それから、スパゲティしか掛けない奴が「C++はJavaよりも
低レベルなことでなんでもできるからJavaより上だ」
とか勘違いしている香具師の傲慢さが疳に障る。

そのような勘違い発言は
このスレを見ているこれからプログラミングをしようとするものに誤解を与える。

プログラマは、自分だけわかればいいというCOBOLer的な独りよがりな
コーディング、あるいは、わざとソースコードを読みにくくする戦術を用いて
チームや引継ぎ人にプログラムの解析に時間を掛けさせるようなコーディングを
すべきではない。C++ではそれが簡単にできてしまう。たとえチーム内でC++の
コーディング規約を定めたとしても人間のアナログ的なミスでコンパイラが規約
を簡単に破ることができてしまう。人間は機械より信用できない。

また、C++は、皮肉にもソースコードをわざとい無駄に複雑にし
読みにくくすることで自分のプログラミングスキルをごまかすことも容易である。

このスレッドのC++厨には「分割し、統治せよ」の原則などを知らないものが多い。
XPやRUPが有名になってきている今となっては、考えられないことだ。

C++よりも高度なセキュリティモデルを持つJavaでは、コンパイラのチェックが
厳しいためこのような陰湿なことはやりにくい。
C++ではこのようなごまかしが簡単にできてしまう。
GNUオープンソースではこれらのようなC++特有の誤魔化しは許されないことだ。

760 ：デフォルトの名無しさん：03/08/11 00:58

このスレのC++厨には「反復型開発」を知らないものが多いw

761 ：デフォルトの名無しさん：03/08/11 02:00

「うまいプログラマは複雑な物をシンプルに書き、
　ヘタクソはシンプルな物を複雑に書く。」

どうもC++プログラマはJavaを貶そうとすると
シンプルな物を複雑に書く「ヘタクソ」とJavaプログラマに思われるみたいだぞ。

762 ：デフォルトの名無しさん：03/08/11 02:01

>>759
言語に優劣をつけてそれがあたかもその言語を扱うプログラマの優劣であるかのようにえばりちらすのは残念ながらJava厨の得意技だ

763 ：デフォルトの名無しさん：03/08/11 03:31

jikesが速いのはC++で書いてるからだろ。

764 ：デフォルトの名無しさん：03/08/11 05:47

>void foo(int &n);
>void bar(int *n);
なんと難解でコ汚い言語ですな(ﾌﾟ

765 ：デフォルトの名無しさん：03/08/11 06:04

人付き合いはいいけど底が浅くて分かりやすい香具師より
ちょっととっつき難いけど懐が深くて切り口も多い奴の方がいいなぁ。

766 ：デフォルトの名無しさん：03/08/11 07:11

オレもＣ＋＋勉強中だけど、そんなに難解かなぁ？
独習C++やってて思ったけど、VC++を前提にしたC++の本は
確かに難解だと思う。
素直にCの拡張版と考えて、まずは標準入出力で一通り覚えるべき。

C++を勉強してて、グっときたのが汎用関数（汎用クラス）。
ちょーかっちょえーっすよ、コレ。

767 ：デフォルトの名無しさん：03/08/11 07:43

>>759
> 自分だけわかればいいというCOBOLer的な独りよがりな
COBOLer は馬鹿に徹して頑張れば誰でもわかるようなソースを書くよ。
残念ながら藻舞は何も知らん若造ということよ。

> また、C++は、皮肉にもソースコードをわざとい無駄に複雑にし
> 読みにくくすることで自分のプログラミングスキルをごまかすことも容易である。
同意できる反面、知らない文化をこう言って逃げる香具師が多くいるのも事実。
C++ のマルチパラダイム性の産んだ悲しい事実だ。
とは言え俺もいつでもどこでもポインタ演算厨は好きではないのであまり偉そうにはいえぬが。

768 ：デフォルトの名無しさん：03/08/11 07:45

>>766
独習C++ぐらいで・・・・　何を偉そうに・・・・
Exceptional C++ / Modern C++ Design あたりを
読んでC++の深さを知るが良し

769 ：767：03/08/11 08:09

忘れておったが
> > 自分だけわかればいいというCOBOLer的な独りよがりな
> COBOLer は馬鹿に徹して頑張れば誰でもわかるようなソースを書くよ。
> 残念ながら藻舞は何も知らん若造ということよ。
COBOLer が難解なソースを書く場合の多くは
初心者のプログラムと同じで、まともなスキルを持っていないだけの場合がほとんどだよ

770 ：デフォルトの名無しさん：03/08/11 09:02

>>768
了解しますた。
次のターゲットとして読ませていただきます。
日本語版が出ている事にほっとしているあたり、
我ながらダメダメですが。

テンプレートって、概念がすごくカッコイイじゃないですか。
「どんな相手だろうが、女を口説くってのは結局こういうことさ」
とのたまうバーの渋い中年みたいで。

でもそのシブイ中年の台詞を生んだ背景を考えると、
さんざん同じこと繰り返して、いまさらそんなこと気づいても
ってころになって、突然使えるようになる機能なんだろうなー、
とも予想されるけど、オレの考え方間違ってますか？

771 ：デフォルトの名無しさん：03/08/11 09:13

>>770
まちがってる。
テンプレートは凝ると難しいけど凝らなきゃ簡単なので、
> さんざん同じこと繰り返して、いまさらそんなこと気づいても
> ってころになって、突然使えるようになる機能なんだろうなー、
ってことはない。

テンプレートは、それがあなたにとって有益なうちに、
じょじょに使えるようになって行きます。

772 ：デフォルトの名無しさん：03/08/11 09:59

最初は先人の作ったテンプレートを利用するところから入り、
そのうち作りまくるようになり、
いずれポイントを弁えるようになる。

そこまでいけば、渋い中年だ。ｗ

773 ：デフォルトの名無しさん：03/08/11 11:13

>>771
なるほど、そうするとC++にテンプレートを組み込んだ
プログラマ的には・・・

「Exceptional C++」をさっそく買ってきたつもりが、
読んでみると独習C++と大差ない、
っていうか独習のほうがくわしかったような・・・

・・・て、これ「Effective　C++」じゃんッ！
朝一番から3800円やられたッッ！

774 ：デフォルトの名無しさん：03/08/11 12:15

しつもーん

VCって１００％C++の仕様でつか？

775 ：デフォルトの名無しさん：03/08/11 12:30

>>766,>>770,>>773
おまえ中学生だろ

776 ：デフォルトの名無しさん：03/08/11 12:47

やはりプロのコーディングは演算子を定義しまくり
演算子で全てを処理するのがスマートなコーディングと
言える

777 ：デフォルトの名無しさん：03/08/11 13:15

>>776
いいすぎ。
釣りか？

778 ：デフォルトの名無しさん：03/08/11 15:00

>773
「Effective　C++」は、買って損はないです。つーかC++プログラマには必読書のひとつだと言われています。
初心者向けにC++の文法を網羅した独習書ではないので、くわしくないように見えるかもしれませんが、いずれこの本のすごさを知るときがきます。
「more Effective　C++」という続編がありますが、こちらは残念ながら訳がひどい！
「Modern C++ Design」は、「Effective　C++」とつながりがあります。
究極のテンプレート活用術という扉の言葉に嘘はありません。まさに眼からうろこのテクニックがつまっていてテンプレートの奥の深さを思い知らされます。「Effective　C++」の著者Scott meyersさえ同じ感想を漏らしています。
ただこの本は難解ですので、ある程度立ち読みして、自分が内容を理解できるレベルに達しているかどうか確かめてから購入するほうがいいです。

779 ：デフォルトの名無しさん：03/08/11 15:56

いくら一生懸命覚えたところでJavaのが生産性が高いんだけどな(藁

780 ：デフォルトの名無しさん：03/08/11 16:03

さぁ、燃料が補給されました

781 ：デフォルトの名無しさん：03/08/11 16:04

日本語が不自由な人にとってはね。

782 ：デフォルトの名無しさん：03/08/11 16:09

javaチューキター・・・

783 ：デフォルトの名無しさん：03/08/11 16:20

オクタン価が･･･ｗ

784 ：デフォルトの名無しさん：03/08/11 16:35

C++はオーバーヘッドが大きすぎて完璧主義者の俺には使えない
アセンブラ以外は音楽で言うと大衆音楽って感じ
俺の使ってるアセンブラは芸術作品って感じがする
アセンブラはバッハC++はテクノjavaはスマップbasicはみんなの歌って感じ

785 ：デフォルトの名無しさん：03/08/11 16:36

あと、デルファイとかのボーランド系のは演歌や民謡

786 ：デフォルトの名無しさん：03/08/11 16:38

暑いな・・・

787 ：デフォルトの名無しさん：03/08/11 16:41

クーラーﾎｽｨ…

788 ：デフォルトの名無しさん：03/08/11 16:46

コンピュータを冷やすためにクーラー入ってるだろ
端末部屋には無いのか？_|￣|○

789 ：_：03/08/11 16:48

http://homepage.mac.com/hiroyuki45/

790 ：デフォルトの名無しさん：03/08/11 17:00

>>788
田舎をなめるなよこんちくしょー。

しかし風が出てきて涼しくなった。助かった…。

791 ：デフォルトの名無しさん：03/08/11 17:23

C++ってホントに難しい。

792 ：デフォルトの名無しさん：03/08/11 17:41

C++ってグローバル変数使わないとダメなんてキモイ

793 ：デフォルトの名無しさん：03/08/11 17:50

>>792 お前の限界。

794 ：デフォルトの名無しさん：03/08/11 17:53

>>793
DirectXのチュートリアルでグローバル変数使ってます
ソレより何よりmain関数がクラスじゃないなんてキモすぎます

795 ：デフォルトの名無しさん：03/08/11 18:16

>>794
1. チュートリアル作った奴の問題なだけ
2. むしろエントリポイントがクラスである必要もないな。

796 ：デフォルトの名無しさん：03/08/11 18:25

グローバル変数を使わないほうがいいというは間違った考え方
使ったほうが便利なのでドンドン使おう

797 ：デフォルトの名無しさん：03/08/11 18:27

>>778
そうなのでつか。了解しました。夜読んでみます。

自分は研究室の実験機器を制御できたら、と思ってCを選んだのですが、
Windowsでのドライバ開発って金かかるんですね･･･

798 ：デフォルトの名無しさん：03/08/11 18:30

>>772
20代で中年扱いは早すぎ

799 ：デフォルトの名無しさん：03/08/11 18:33

>>796
> グローバル変数を使わないほうがいいというは間違った考え方
> 使ったほうが便利なのでドンドン使おう
それは危険な思想だ。
しかしそれは釣りだよな

800 ：デフォルトの名無しさん：03/08/11 18:38

グローバル変数は絶対に使ってはならないもの。

801 ：デフォルトの名無しさん：03/08/11 18:54

グローバル変数は
あんまり本に書いてあることとか鵜呑みにしないほうがいいよ
ある程度プログラムが組めるようになると使える事が分かる
directxの例でもわかるようにアメリカでは使うの常識
それに比べて日本は遅れてるようだね

802 ：デフォルトの名無しさん：03/08/11 19:00

>>801
お前の脳が古いだけだな。

803 ：デフォルトの名無しさん：03/08/11 19:52

ま、使わなかったからってどうかなるものでもないし　>>グ口―バル変数

804 ：デフォルトの名無しさん：03/08/11 19:56

グローバル変数なんて使わずシングルトンにすべき！！

805 ：デフォルトの名無しさん：03/08/11 20:05

シングルトンってなに？

806 ：デフォルトの名無しさん：03/08/11 20:06

>>805
グローバルインスタンス

807 ：デフォルトの名無しさん：03/08/11 20:08

グローバル変数の代わりに、
スタティックなオブジェクトを生成して
そのメンバを全てpublicにすれば無問題。

808 ：デフォルトの名無しさん：03/08/11 20:17

>>801はシングルトンを使っているプログラムを書くのが
アメリカでは常識といっているのだろう。

シングルトンは使い方を間違えるとグローバル変数のように
恐ろしいものになる。

>>801はなかなか引っ掛けたな。

809 ：デフォルトの名無しさん：03/08/11 20:18

お前らのIQの総和は256くらいだろ。

810 ：デフォルトの名無しさん：03/08/11 20:18

>>805
まあデザインパターンの本かサイトでも嫁

811 ：デフォルトの名無しさん：03/08/11 20:19

>>809
中にIQがマイナスになっている香具師がいるみたいだね。

812 ：デフォルトの名無しさん：03/08/11 20:45

>>807
それってグローバル変数と変わらないじゃん

813 ：デフォルトの名無しさん：03/08/11 22:15

>>807はnamespaceを知らない知障

814 ：デフォルトの名無しさん：03/08/11 22:34

>>812
カプセル化するとあとでいいことあるよ。

815 ：デフォルトの名無しさん：03/08/11 22:55

Delphi、C#、VB.NETに比べてVC++は意地悪であんな仕様にしてるとしか思えない

816 ：デフォルトの名無しさん：03/08/11 23:06

しかし不正アクセスされたらもとも子もない罠。
言語仕様で制限かけれてもこれには歯が立たないだろう。

817 ：デフォルトの名無しさん：03/08/12 00:27

Del,VB.NETは移植性も互換性も必要ないし、開発ツールに都合が良いように作られているからな。

C++BuilderのDelphiに対する「コンプレックス」をみると泣けてくる…

818 ：デフォルトの名無しさん：03/08/12 00:29

>>807はpackageを知らない知障

819 ：デフォルトの名無しさん：03/08/12 00:31

>>813はメール欄を読めない(以下略

820 ：デフォルトの名無しさん：03/08/12 00:31

>>818も(以下略

821 ：デフォルトの名無しさん：03/08/12 00:40

>>807==>>819-820はtulip

822 ：デフォルトの名無しさん：03/08/12 03:41

>815
VisualBasicとVisualC++でプログラマに
階層を作るためにわざとそうしたのです。

VisualBasicでしかプログラムできないプログラマを増やし、
一方でマイクロソフト製品には決してVisualBasicを使わず、
難解なVisualC++でしか書かない、という戦略で
プログラマを支配するマイクロソフトの戦略なのです。

。。。だったら凄いなｗ

823 ：デフォルトの名無しさん：03/08/12 05:30

今、ディスプレイにジクモが張り付いております。
マウスカーソルを興味深そうに眺めるくしぐさは面白い。
あまり追いかけてはこないけど、くるくる回すと、クモもクルクル回るのが楽しい。
でもクモから５センチほどカーソルと離すとクモの反応が鈍くなるんだよな。
どこだどこだ？とキョロキョロカーソル探し始めるし。

１時間ほどクモと遊びました

824 ：デフォルトの名無しさん：03/08/12 06:04

寝ろよ

825 ：デフォルトの名無しさん：03/08/12 10:50

>>822
.NET戦略なんてそんなもんだろ。
馬鹿なブビ厨を救うためにわざわざVB.NETなんて作ったもんだし
C#もあれだし

826 ：デフォルトの名無しさん：03/08/12 11:03

>>807 程度で釣ろうとするのも
実際に釣られたりするのも
暑さのせいですね、きっと。

827 ：デフォルトの名無しさん：03/08/12 13:29

>>822
> 。。。だったら凄いなｗ
スティーブバルマー（ＭＳのＣＥＯ）が、会場で
「ア～イラ～ブジィ～スカンパニ～！イエェェイ！」
「デヴェロォップ、デヴェロォップ、デヴェロォップ」X２０回ほど
と汗でびしょびしょのシャツを来て叫ぶパフォーマスはもっとすごいです。

828 ：デフォルトの名無しさん：03/08/12 13:33

何の会場だよ。

829 ：デフォルトの名無しさん：03/08/12 14:15

>>828
ネタかどうか自分の目で確認して見ろ。
http://www.ntk.net/ballmer/mirrors.html

830 ：デフォルトの名無しさん：03/08/12 14:29

ぐへぇ。
で、これはいったい何の会場?

831 ：デフォルトの名無しさん：03/08/12 19:55

http://www.zdnet.co.jp/news/0108/24/e_cooper.html

832 ：デフォルトの名無しさん：03/08/12 23:17

M$もおかしくなったな

833 ：デフォルトの名無しさん：03/08/13 00:43

SUNはもとからおかしいわけですが。
SUNに騙されつづけるJAVA厨はもっとおかしいですね

834 ：デフォルトの名無しさん：03/08/13 08:47

>>833
また必死な豚ブビ厨の釣りか。

SunとJavaとの関係はM$とC#やVBとの関係と比べると非常に薄いわけだが。
キミにとってはIBMが作ったJava製品やJakarta Projectのソフトウェアは
Sunが作ったものだと思い込みたいのかね(藁

835 ：デフォルトの名無しさん：03/08/13 09:03

>>834
>>833じゃないがそりゃ実装の話だろ。大人しく引き篭もってろよ厨房。

836 ：デフォルトの名無しさん：03/08/13 12:17

>>834
一時期、SUN がクレームつけてきたせいで
IBM が自社独自 VM つめなくて困ってなかったっけ？

Solaris 以外の OS では IBM 自社独自 VM の方が
SUN 純正よりも数倍早かったのに。

837 ：デフォルトの名無しさん：03/08/13 12:49

というか>>833に>>834以上に誰も突っ込まないのは気のせいか？

>>831, 832はSunの話題を一言もいってないのに

>>833は MSを批判されるとそれを無理やりSunとJavaに結び付けている

ことに誰も「おや？」とは思わないのが不思議。

838 ：デフォルトの名無しさん：03/08/13 12:53

>>837
つーか、元々どうでもいいし。

839 ：デフォルトの名無しさん：03/08/13 13:36

まあ、ＭＳも終わりだしね。

840 ：デフォルトの名無しさん：03/08/13 13:40

というか>>1の

>わかりやすいプログラミング言語をつくれないBjarne Stroustrupにはげんあり

の意味がわからない

げんあり？

厳蟻？

841 ：デフォルトの名無しさん：03/08/13 13:49

>>840
げんなりだろ
gennariって打ったらローマ字変換ルールによってはげんありになるし

842 ：デフォルトの名無しさん：03/08/13 18:32

841=1

843 ：833：03/08/13 22:13

>>834
ブビ厨じゃないです。C++エキスパートです。
でも釣りは正解。
>>837
「おや？」と思ったのは普段から自演して神経過敏かつ疑心暗鬼になっている君だけです。

844 ：デフォルトの名無しさん：03/08/13 22:54

↑はC++スレ常駐の騙りだと思う。

845 ：デフォルトの名無しさん：03/08/13 23:21

>>843
C++エキスパートだってよﾌﾟ
Visualに染まったVisualC++厨だろﾌﾟ

VisualがつくM$製品はみな糞

846 ：デフォルトの名無しさん：03/08/13 23:23

>>843
根拠なく自演とかいってるあたりが
普段から自演して罪悪感を感じている>>843の心境を表しているw

M$の工作員が必死にC++エキスパートを演じているw

847 ：デフォルトの名無しさん：03/08/13 23:40

ところでc++の案件って減ってたりすんの？

848 ：デフォルトの名無しさん：03/08/14 10:42

>>847
私の周囲では、Javaに取られて減った分UnixCから移行して増える感じ。

849 ：デフォルトの名無しさん：03/08/14 17:36

取り敢えず釣られちゃった人は、次回から
ﾒｰﾙ欄まで確認するようにしましょう。

850 ：デフォルトの名無しさん：03/08/14 17:53

最近はメール欄に「釣り」と保険をかけてレスするのは
負け犬だという風潮がはびこっているようですが。

851 ：デフォルトの名無しさん：03/08/14 19:14

つーか、釣り云々言い出すヤツはそもそも負け犬

852 ：デフォルトの名無しさん：03/08/14 20:56

5年前まで仕事でC++使ってて
今日久しぶりにC++でプログラムしようとしたらびっくり。
結構仕様が変わってるのね。

#include <iostream.h>
一発目からだもんなぁ･････

853 ：デフォルトの名無しさん：03/08/14 21:05

<iostream.h>⇒<iostream>って事？

854 ：デフォルトの名無しさん：03/08/14 22:12

namespaceも枷になってるな。
見事に。

855 ：デフォルトの名無しさん：03/08/15 00:41

＜＜差分プログラミング時代の人(>>852)がこのスレに来ました！＞＞

856 ：デフォルトの名無しさん：03/08/15 00:50

だからメール欄で逃げるな。

857 ：デフォルトの名無しさん：03/08/15 00:52

>>856
おまえつまんないやつだな。

858 ：デフォルトの名無しさん：03/08/15 01:12

メール欄は保険
旗色悪くなったら
釣れた釣れた～
そういうやつは
煽りも下手糞だ

859 ：デフォルトの名無しさん：03/08/15 01:13

釣れた言う奴は負け犬。

860 ：デフォルトの名無しさん：03/08/15 03:51

C++は既に破綻している!!

861 ：デフォルトの名無しさん：03/08/15 09:39

>>860
ということにすると使いこなせない言い訳が立って安心できるんですね ;-P

862 ：デフォルトの名無しさん：03/08/15 10:10

おまえらちょっとまて！！
異議あり！
http://www.reset931.net/saiban/Obj_Nar.swf?inputStr=%96%A1%91X%8F%60%82%CC%82%C6%82%C8%82%E8%82%C9%82%CD%81@%81@%81@%81@%81@%81@%81@%81@%81@%94%92%82%A2%82%B2%94%D1%82%C5%82%C8%82%AF%82%EA%82%CE%82%C8%82%E7%82%C8%82%A2%81I

863 ：デフォルトの名無しさん：03/08/15 10:13

ついでだから
異議あり！！
http://www.reset931.net/saiban/Obj_Kar.swf?inputStr=%95%D9%8C%EC%90l%82%CC%8F%D8%8B%92%95i%82%CD%83%7C%81%5B%83N%83r%83b%83c%95%C0%82%E6%81I%81I

864 ：デフォルトの名無しさん：03/08/15 10:15

さらに
異議あり！！！
http://www.reset931.net/saiban/Obj_Mit.swf?inputStr=%83o%83i%83i%82%CD%82%A8%82%E2%82%C2%82%C9%8A%DC%82%DC%82%EA%82%C8%82%A2%81@%81@%81@%81@%81@%8E%A9%96%BE%82%C8%8E%96%82%BE%81I

865 ：デフォルトの名無しさん：03/08/15 13:31

>>862-864
http://www.reset931.net/saiban/Obj_Nar.swf?inputStr=藻前らスレ違いです！

http://www.reset931.net/saiban/Obj_Mit.swf?inputStr=どうせこのスレ終わっています！

エンコードするのめんどくせ

866 ：デフォルトの名無しさん：03/08/15 13:48

http://www.reset931.net/saiban/Obj_Mit.swf?inputStr=%88%D3%8B%60%82%C8%82%B5%81I%81I

867 ：山崎渉：03/08/15 15:15

　　　 (⌒V⌒)
　　　│ ＾＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

868 ：デフォルトの名無しさん：03/08/15 17:16

hosyu

869 ：デフォルトの名無しさん：03/08/15 20:18

>>866
最高

870 ：デフォルトの名無しさん：03/08/21 19:34

Javaは難しすぎ
http://pc.2ch.net/tech/kako/1022/10226/1022667056.html

871 ：デフォルトの名無しさん：03/08/23 21:57

>>870
まじでそんなスレがあった？
知らなかった。
このスレがオリジナルだったとは。

Javaは難しすぎ
1 名前：デフォルトの名無しさん投稿日： 02/05/29 19:10

あんなの理解できるはずないだろ！！
わかり易いプログラム言語を作れない James Goslingは逝ってよし

872 ：デフォルトの名無しさん：03/09/01 23:32

>>871
> このスレがオリジナルだったとは。

日付も読めないんですか？
それとも連体詞の適切な用法もわからないんですか？

873 ：デフォルトの名無しさん：03/09/02 17:36

C++やJavaが難しいなら Cを使え
思わず射精しちゃうくらいイイぞ

874 ：デフォルトの名無しさん：03/09/02 17:54

今日某からC#Builderの案内が届いた。M$に寝返ったか某・・・・

875 ：デフォルトの名無しさん：03/09/02 18:20

>>873
出ちゃった...

876 ：デフォルトの名無しさん：03/09/02 22:12

>>874
BolandもJBuilderだけで売り上げを伸ばすのはもう長くない。

IBMがEclipseをオープンソースとして世界にばら撒いてから
Bolandの運命は揺れ動いた。

877 ：デフォルトの名無しさん：03/09/06 13:27

C++の継承で実際にコンパイラが吐くポインタ計算のコードを考えてると
めちゃ難しいと思うよ。

878 ：デフォルトの名無しさん：03/09/06 15:47

厳しい型チェックを導入した割に、自動的な型変換のせいで、
結局バグが発生しやすいのはどうかと思う。特に演算子多重定義。
なんかC++って設計に一貫性がなくてちぐはぐなんだよね。
使っていて気分が悪くなる。

879 ：デフォルトの名無しさん：03/09/06 15:59

ま、Cの構造体と関数ポインタから強引にオブジェクト指向の概念を導入して、
整合性が取れなくなった部分を場当たり的に機能拡張で対処していったら、
こんな複雑怪奇な言語になりました、ってのがC++だから当然の結果か。

880 ：デフォルトの名無しさん：03/09/06 17:17

オブジェクト指向拡張の部分はキャスト関係以外はごくシンプルと思うが。
メンバ初期化は単純に馬鹿な作りだが。
それより、テンプレートとかオーバーロードとかで、暗黙的に何でも
やりすぎたのが問題で、めちゃくちゃに複雑なルールが必要になっている。
もし俺がC++を作り直していいと言うなら、テンプレートを真っ先に直すよ。

881 ：デフォルトの名無しさん：03/09/06 17:26

>>878
型変換で発生するバグって、スライシングのこと？　ふつー、ポリモーフィック
な型は copy, assign 不可にしてポインタで受け渡すモノだと思うが……。

> もし俺がC++を作り直していいと言うなら、テンプレートを真っ先に直すよ。
具体案ぷりーず。

882 ：デフォルトの名無しさん：03/09/06 17:55

>>880
> もし俺がC++を作り直していいと言うなら、テンプレートを真っ先に直すよ。

それで作り直され完成したものがJavaGenericsなのでした

883 ：デフォルトの名無しさん：03/09/06 18:44

Java Generics は specialization がなく動的結合だから、失ってるモノも
多いぞ。

884 ：デフォルトの名無しさん：03/09/06 18:55

私だったら真っ先に記号の扱いを整理するなぁ。

たとえば不等号の扱いとか。
vector <vector <string> > と vector<vector<string>>は違うって言われてもねぇ。
#いや、理由は知っているのだが。
おまけに、#include でも不等号を使うし。

885 ：デフォルトの名無しさん：03/09/06 19:14

それなら、まずトライグラフの廃止だろう。っつか、かなり枝葉末節やね。

886 ：デフォルトの名無しさん：03/09/06 21:04

> もし俺がC++を作り直していいと言うなら、テンプレートを真っ先に直すよ。

それで作り直され完成したものがD言語のGenericsなのでした

887 ：デフォルトの名無しさん：03/09/06 21:40

STL便利すぎる

888 ：デフォルトの名無しさん：03/09/06 23:33

D言語のGenericsはまだ不安定というかうまく動かない

889 ：デフォルトの名無しさん：03/09/07 00:16

二重人格になって、もう一人の自分として、あえてC++のやり方に合わせる考えにならんと、C++はできそうにないな。

890 ：デフォルトの名無しさん：03/09/07 01:41

もし俺がJavaを作り直していいと言うなら、Genericsを真っ先に直すよ。
VMの互換性を犠牲にしてでも。

891 ：デフォルトの名無しさん：03/09/07 01:48

C++のtemplateは馬鹿正直だっ・・・・！
静的に変換するしか脳がないっ・・・・！
無駄に膨れ上がる実行ファイルっ・・・・！
JITで需要に応じて、というわけには、
とてもいかない・・・・！

892 ：デフォルトの名無しさん：03/09/07 02:08

>>891
そうだね。（ﾌﾟ

893 ：デフォルトの名無しさん：03/09/07 03:39

exportしる

894 ：デフォルトの名無しさん：03/09/07 03:57

>>880 >>890
それぞれ、何を直すの？

895 ：デフォルトの名無しさん：03/09/07 04:16

難しいのはまだ許せる。理解しづらい仕様なのが嫌。

896 ：デフォルトの名無しさん：03/09/07 04:17

C言語を理解できない莫迦な＞１がＣ＋＋を理解できる訳がない。
Ｃ言語をちゃんと理解しているなら、Ｃ＋＋は簡単さ。
Ｃの概念を便利に拡張しただけなのだから。

897 ：デフォルトの名無しさん：03/09/07 04:20

おまえら、
classとか、publicとかprovateとかvartualとかのキーワードに振り回されて
本質をまったく理解していないから、理解できないんだよ。
Ｃ＋＋言語の本質を理解していればＣ＋＋は簡単。

898 ：デフォルトの名無しさん：03/09/07 04:20

private
virtual

899 ：デフォルトの名無しさん：03/09/07 04:28

>>897
先生！全く説得力ありません・・・

900 ：デフォルトの名無しさん：03/09/07 05:07

おまえら、Ｃ言語を使用していて、とても不便に感じた部分ってどこだ。
ここが不便だーーーと感じている部分がある香具師ならＣ＋＋も理解できるだろう。
そこまでの理解ができていない家具師なら、Ｃ＋＋の習得の道のりはまだ遠い。

Ｃが根本的に不便な部分を改良したのがＣ＋＋の本質なのだから。

901 ：デフォルトの名無しさん：03/09/07 05:23

>>900
まぁ、同意。漏れはC++から始めたから知らんが、
もはやCで組む気がしない罠。

クラス、テンプレート、STL、boostマンセー。

902 ：デフォルトの名無しさん：03/09/07 05:41

>>901
C++と言ってもその程度

903 ：デフォルトの名無しさん：03/09/07 06:16

>>902
何か足りないものでも？

904 ：デフォルトの名無しさん：03/09/07 07:41

>897
一瞬ネタかと思ったぞｗ

905 ：デフォルトの名無しさん：03/09/07 11:44

>>903
リフレクションは欲しいと思うことが、しばしば。イテレータの種類によって
std::advance() の動作を変える (forward iterator なら ++i を繰り返し
random access iterator なら i += n で一気に飛ぶ) とか、わざわざ
タグディスパッチを用意するのも面倒だし。

あと、同じアルゴリズムで引数の数が違うものも書くのが面倒。Loki の
TypeList とか使えばできるけど、あれももう少し素直に書けるとねぇ。

基本的には C++ には満足してるよ。

906 ：880：03/09/07 12:48

>>894
型の置き換えなんていう、曖昧性の出やすい仕組みじゃなく、
きちんとしたメタ言語として独立させる。あくまでもコンパイラの
中で実行するから、型の情報とかは利用できて、でもそれ以外は
単なるコードジェネレータ(put "*${p1}++ = *${p2};"なんて調子)
の世界、というのを考えている。それなら猿でも書けるし、
言語使用も簡単に厳密化出来ると思う。

907 ：デフォルトの名無しさん：03/09/07 12:55

C++をC以外のところから入るのは邪道だとおもう、理解不十分でトラブル発生の元。
増築言語である以上切り離せないんだし、それで理解したと考えるのは危険極まりないとおもう

908 ：890：03/09/07 14:32

>>894
どこを変えるていうか、全部。少なくともC++テンプレートに出来る事は全部できるようにしたい。
まずは typedef の導入からか？もしかなうなら名前は変えるけど
(typedefって今となっては誤読しやすい名前だと思う。)

事実上新しい型が現れた時点でその型に対するGenericコードの
コンパイルの全工程withoutパースをするような仕様にするだろうな。

909 ：デフォルトの名無しさん：03/09/07 14:43

>>907
(はじめからC++を使うつもりなら)
C++をCから入るのは邪道だと思うけど。

根本的にパラダイムが違うし、C使いとC++使いのコードの癖も違うし。
結局Cの古い流儀を引きずってC++をうまく使えなくなる要因になりかねない。
必要な低レベル知識はC++をC++として使いながらでも十分身につけられると思う。
まして今の時代はC使いからみてC++の難しい部分(OO拡張)は
JavaだのC#だのでとっくに理解済みなわけで、C++を理解しようとする時の
壁になる部分が昔とはまったく違う。
壁になるのは低レベルな知識だろ、そういうのはC言語のレベルの話だから……。

ごめん、やっぱり正しいかな。
C++習得への最短距離は
Java→C#→C→C++
でいい？

910 ：　：03/09/07 15:26

考える前に書き込む癖は直そうぜ。

911 ：デフォルトの名無しさん：03/09/07 16:02

ネタにマジレス=短小包茎

912 ：デフォルトの名無しさん：03/09/07 16:02

>>907
どこから「切り離す」という言葉が出てきたか知らんが、
Cとの共通部分とC++独自の部分を勝手な順番で学習して
何か不具合でもあるのか？

913 ：デフォルトの名無しさん：03/09/07 19:10

>>909
そう、それがC++の最大の欠点。中途半端にC言語の機能を引き継いでいるからか困る。
C言語との互換性なんてばっさり切り捨てたほうがいい。
なけりゃないで普及もしなかったんだろうけどね・・・

914 ：デフォルトの名無しさん：03/09/07 19:14

>>883
ポインタ演算ができないから
それができない言語は失っている、
とでもいいきるのかい？

915 ：デフォルトの名無しさん：03/09/07 19:43

Javaのgenericsは非力すぎで
僕たちがあの日感じた、大切な何かを失ってるよ

916 ：デフォルトの名無しさん：03/09/07 19:57

勝手に僕たち、って決め付けるなよ（ｗ

917 ：デフォルトの名無しさん：03/09/07 20:04

究極的にはLISPのマクロになると思うけど、
JavaにはEPPというのが既にあった気がする。

918 ：デフォルトの名無しさん：03/09/07 20:09

JavaのGenericsは所詮STL以前のtemplateの模倣でしかないから、
結局もう一度拡張されて旧仕様との互換でぐっちゃぐちゃになると予想。
どうせパクるならAdaとかML系とか参考にすりゃいいのによぅ。

919 ：デフォルトの名無しさん：03/09/07 22:09

Genericsって看板に偽りなし。
C++のテンプレートの技法はもうジェネリックプログラミングより先の世界に行ってるから、
ジェネリックプログラミングしかできない Java Generics は非力に見える。

920 ：デフォルトの名無しさん：03/09/07 22:13

メタプログラミングってやつかな

921 ：デフォルトの名無しさん：03/09/07 22:23

C++でJava見たいに中間言語を生成すればどのプラットホームでも…

って奴が .Net だな。

922 ：デフォルトの名無しさん：03/09/07 23:02

メタプログラミングとジェネリックプログラミングってどう違うの？

923 ：デフォルトの名無しさん：03/09/07 23:24

メタ＝超　高次　自己の客観視
ジェネリック＝一般的な　総称的な　汎用の

924 ：デフォルトの名無しさん：03/09/08 01:16

>>923
よくわからん。
STLつかうのはジェネリック？
modern C++ designの内容もたぶんジェネリック？（副題にジェネリックって書いてるし）
で、メタプログラミングって具体的に何？マクロとか？
boost::spiritみたいなの？

925 ：デフォルトの名無しさん：03/09/08 01:22

'n'　これは文字

'\n' これはメタ文字

926 ：デフォルトの名無しさん：03/09/08 11:40

>924
STLはジェネリック。
Modern C++ design (Loki) は、実はジェネリックつうよりジェネラティブ。

927 ：デフォルトの名無しさん：03/09/08 12:08

少なくともこの場合の「メタプログラミング」は
boost::mplとかのことを指してるはず。

928 ：デフォルトの名無しさん：03/09/09 08:04

直交性指向のスレはここれすか？

929 ：デフォルトの名無しさん：03/09/09 08:29

>>909
C++を最初からやる気なら最初の言語はやさしい言語ならなんでも良いと思う。
C++には低レベルな部分の難解さと、色々な概念を取り込んだ結果の高レベルの難解さが混在する
全部を相手にするときりがないから、一個づつ解決するのが良いが最初は低レベルを解決しておくのが良いと思う。
高レベルは機能を一通り見ておいてから、どう使えばうまく使えるかを知るのが良いと思う。

(VB,Java,C#等プログラム入門言語)→C→C++→(OO系をやっていなければ Java等)→関数型言語
が個人的にはお勧め。

そのリストの中に関数型が抜けているのが少し気になった、それだけだとうまく使いこなせないと思うよ。
導入はやさしければ別にOOPである必要性はないと思うよ、
それはC はOOの習得の障害になると言われるが、同様OOは関数型等の考え方を習得するときの障害になってtemplateの使いこなしが変になる。
結局何処から入っても何処かに障害ができるからね。
ただし関数型は導入向きとは到底いえず、C++の機能で最もややこしいtemplateを使うノウハウになるから最後。

930 ：デフォルトの名無しさん：03/09/09 21:13

Cは要らない。

931 ：デフォルトの名無しさん：03/09/09 21:19

ModernC++Designの流し読みを一年間も続けてりゃ
わざわざ関数型言語やらなくても嫌でも覚えるよ。

932 ：デフォルトの名無しさん：03/09/10 00:10

おいおい・・
fplとC++じゃ天と地ほど違うよ
変態本一冊読んで解った気になってりゃおめでたいよ

933 ：デフォルトの名無しさん：03/09/10 00:41

C++と並行して関数型言語を学べばいいのでは？

934 ：デフォルトの名無しさん：03/09/10 02:07

>>932
重要なのはC++は関数型言語じゃないって事だ。
C++をC++として使うための知識を得るのに関数型言語をやらなければならないというのはおかしい。
つまり、天と地ほど違おうが関係ない。C++にあるのが地だけなら、C++だけ使う分には地で十分なのだ。

935 ：デフォルトの名無しさん：03/09/10 21:14

>>931
それはないと思うよ
Cのような構造化言語からOOに入った人ならまず分ると思うけど、JavaやC#のような言語をやらないとOOは身につきません。
思考形態がまったく変化して、ある日突然見えた!となる日があります。
C++だけだとどうしてもそこには辿り着けず、クラスいじりに終始します。
それと同じようなことが関数型言語にもあって、一旦、C++の機能を全部排除した状態でどこまで出来るのか見てみないと、正体が見えてきません。
template はそこが分ると世界が変わります。
ModernC++Design は良い本だとは思います、多分C++の書籍の中では最高峰であることは認めます。
しかしModernC++Designだけで分るかというと、ちょっと難しいかと・・・

936 ：デフォルトの名無しさん：03/09/10 21:23

>>935
> 思考形態がまったく変化して、ある日突然見えた!となる日があります。
> C++だけだとどうしてもそこには辿り着けず、クラスいじりに終始します。
俺はC++でこれが起きてOOを憶えたわけだが。
Java, C# の方がよりたどり着きやすいだろうけど、C++では無理というのは飛躍しすぎ。

937 ：デフォルトの名無しさん：03/09/10 22:26

最初からC++な俺には「何言ってんだか>>935の馬鹿は」ってカンジかな

938 ：デフォルトの名無しさん：03/09/10 22:49

Ｃ＋＋程度を理解できない知能指数の香具師は
ろくなプログラムなど作ることはできないということだけは
はっきりしている。

939 ：デフォルトの名無しさん：03/09/10 23:16

>>938
C++のどの辺りを理解できないといかんのかね？
理解できてもいい加減なC++プログラマが書いた
ソースコードを解読できない奴が多いだろう。

読めない奴のスキルに問題がないとは限らないが
解読容易性は
ソースコード書く奴のオブジェクト指向設計スキルにも依存するぞ。

940 ：デフォルトの名無しさん：03/09/10 23:18

>>919
C++のテンプレートはなんでもありでなんでもできすぎて
ポインタ演算のようにソースコードを汚すという欠点があろう。
その問題を避けるためにJavaGenericsは機能を限定している。

941 ：デフォルトの名無しさん：03/09/11 02:22

>ポインタ演算のようにソースコードを汚すという欠点があろう。

(ﾟДﾟ)ﾊｧ?

942 ：デフォルトの名無しさん：03/09/11 06:39

>>941
(ﾟДﾟ)ﾊｧ?

943 ：デフォルトの名無しさん：03/09/11 06:59

>>942みたいにオウム返ししか能の無い奴には
C++は難しすぎる模様

944 ：デフォルトの名無しさん：03/09/11 07:01

>>940,>>942
○○（ ´,_ゝ｀）

945 ：デフォルトの名無しさん：03/09/11 08:32

単にVM互換性の為に不便な仕様になっただけだろ。
万が一強力なジェネリックの仕組みを作ると、
お得意の「それはシンタックスシュガー」が
間違いだったという事が多くの末端プログラマにバレるしな。

946 ：デフォルトの名無しさん：03/09/11 09:59

仮にJavaGenericsをC++template並に使いこなせるようにするとすると
何が起こるか想像できるかな？

947 ：デフォルトの名無しさん：03/09/11 10:08

>>935
JavaやC#がC++よりOOらしい言語だというのは認めるとして、
その差は専らライブラリの差だろ。
C++だって良いライブラリを見ていればやっぱりOOは分かる。

948 ：デフォルトの名無しさん：03/09/11 10:12

>>947
違う違う。Javaでプログラミングしてみればわかる。
エラーメッセージの出方、細かく非常に厳しい型チェック、
セキュリティチェック、なにもかもコンパイラやVMが吐き出すメッセージは
C++よりもうるさい。残念ながらC#はJavaよりも緩く、セキュリティも弱い。

それが面倒くさいという香具師もいるが、この厳しさのお陰で
堅牢なプログラミングができるわけだ。

配列の取り扱いも多重継承の取り扱いも型の扱いもJavaのほうが断然安全だ。

949 ：デフォルトの名無しさん：03/09/11 10:16

あ、ついでに言うと、C++はポインタも構造体もテンプレートもあるから、
OOが使われにくい面があるけど、逆にOOの適用対象を絞ることで、
OOを純化できるという面もあると思う。餅屋と米屋と菓子屋があって、
競合するからこそ、「餅は餅屋」が成立する。

950 ：949：03/09/11 10:17

949は947の続きな。

>>948
> エラーメッセージの出方、細かく非常に厳しい型チェック、
> セキュリティチェック、なにもかもコンパイラやVMが吐き出すメッセージは
> C++よりもうるさい。残念ながらC#はJavaよりも緩く、セキュリティも弱い。
それは重要な機能ではあるが、OOとはあまり関係ない。

951 ：デフォルトの名無しさん：03/09/11 10:23

>細かく非常に厳しい型チェック
Object型ってのはvoidでしょ。どこが厳しいの？

952 ：デフォルトの名無しさん：03/09/11 10:30

おまえすべての引数や戻り値にObject型つかってるのか？

953 ：デフォルトの名無しさん：03/09/11 10:32

当然だろう

954 ：デフォルトの名無しさん：03/09/11 10:37

>>950
OOらしいプログラミングを実現しやすくなるということが
関係しているのだよ。

>>951がJavaをやるときはぜひともJavaGenericsを
使ってもらいたい。
じゃなきゃコレクション系も使うなと。

void? variantの間違いか？

955 ：デフォルトの名無しさん：03/09/11 11:28

954にとってのOOとは型安全のことらしい。

956 ：デフォルトの名無しさん：03/09/11 12:16

憶測だけでレスすることしかできない
腐った釣り師は黙ってろと　
　

957 ：デフォルトの名無しさん：03/09/11 12:19

そんなに刺激されちゃったんだ、この憶測で。

958 ：デフォルトの名無しさん：03/09/11 18:27

>>954
「OOらしい」の定義から考え直した方が良いよ

959 ：デフォルトの名無しさん：03/09/11 20:09

Javaの型チェックが厳しいってのはどういう部分で？

boolean周りのこと？

960 ：C/C++マンセー：03/09/11 21:50

Java使う気になれない。

961 ：デフォルトの名無しさん：03/09/11 21:51

ジャバ男って何の漫画のキャラだっけ？

962 ：C/C++マンセー：03/09/11 21:54

テンプレートはVectorくらいしか使ったことない。
基本的にテンプレートは使わない姿勢。
あれって結構環境依存だから、いろんなOSで移植を考えた場合
オリジナルライブラリがアンパイ。

俺の知ってる人もテンプレートを使わない、というか、人が作ったものを信用できるかって・・
あんたが作ったのよりはマシじゃないの？とか思ったりしたけど、基本的に
同意だな。

963 ：デフォルトの名無しさん：03/09/11 22:01

962にとってテンプレートとはSTLの事らしい。

964 ：C++＆STL＆Boostマンセー：03/09/11 22:03

>>962
お前のいうテンプレートとはSTLのことか？
そんなんでC++マンセーかよ。
STLなしのC++なんて、たこの入っていない
たこ焼きみたいなもんだよ。

std::string / std::wstring も使ってないんだろうね。
文字列型は、やっぱ自作か？

965 ：963：03/09/11 22:05

俺としたことがもっと重要なツッコミポイントを見逃していたよ。

＞人が作ったものを信用できるかって
じゃあコンパイラも信用できないから自分で作るんですか？
OSも信用できないから自分で作るんですか？
CPUも信用できないから自分で作るんですか？

いちばん信用ならないのはどこの馬の骨ともしらない女に作られて
その股の穴から出てきた>>963なんじゃないですか？

966 ：デフォルトの名無しさん：03/09/11 22:15

そのとおりですね。

967 ：C++＆STL＆Boostマンセー：03/09/11 22:17

>>965
自爆し㌦…（藁

968 ：デフォルトの名無しさん：03/09/11 22:23

なに釣られてんだよ。ｱﾌｫ

969 ：デフォルトの名無しさん：03/09/11 22:26

いまどき、STLが信用できないなんていうバカはアマチュアにだっていないぞ。
そんなこと言うのはdjbぐらいなもんだ。

>>962 はぜったいに釣りだ。

970 ：デフォルトの名無しさん：03/09/11 23:17

みんなはRTTIって使ってる？

971 ：C/C++マンセー：03/09/11 23:18

>>964
もち、自前。

すまん、テンプレート＝STLかと思っていた、
既存のライブラリがあっても、あえて使わず１から作るタイプだ、俺は。

972 ：デフォルトの名無しさん：03/09/11 23:21

CArrayにCArray入れるとはねるのに
ポインタ入れると通るというのが気持ち悪い

973 ：デフォルトの名無しさん：03/09/11 23:27

>>967
メール欄

974 ：デフォルトの名無しさん：03/09/11 23:29

>>971
> もち、自前。
そんなﾊﾞｸﾞだらけのライブラリ使う奴の気が知れねーよ。マジで。

975 ：デフォルトの名無しさん：03/09/11 23:31

テンプレート使わずにライブラリ作る奴の気が知れない。
あとC++とMFCの区別がついていない奴はこのスレから出てってWin3.1からやり直してきてほしいと思います。

976 ：デフォルトの名無しさん：03/09/11 23:42

ここは厨隔離スレなので追い出すのは止めてください。
仲良く煽りあってください。

977 ：デフォルトの名無しさん：03/09/11 23:54

>>971
＞既存のライブラリがあっても、あえて使わず１から作るタイプだ、俺は
一々自作したものをテストするのか? 仕事じゃ使えないな。

そうか、先日修正を依頼されたソースはきっと>971みたいな奴が書いたんだろうな。
200行もあってバグってたから作り直したらsprintf()一個で終わったからな。

978 ：デフォルトの名無しさん：03/09/11 23:55

>>975
クラスとインターフェースの区別つかない奴も逝ってよし。
てかC++言語の記述上は明確な区別はないんだけど考え方として。。。

979 ：デフォルトの名無しさん：03/09/11 23:55

>>975

今時CObArray使う奴がいるんだ。なんとかしてくれ。

980 ：デフォルトの名無しさん：03/09/11 23:55

いや、一緒だろ
vectorにvector入れると通らないじゃん
もしかして違ってるか？

981 ：デフォルトの名無しさん：03/09/11 23:57

>>980
???

vectorにvector入れるって何が言いたいんだ?

982 ：デフォルトの名無しさん：03/09/11 23:58

vector<std::vector<int>> a;
とか

983 ：デフォルトの名無しさん：03/09/12 00:00

>>982
なるほど、それじゃ通るわけがない。