C++は難しすぎ難易度:2

C++は難しすぎ難易度 ..

75:デフォルトの名無しさん
04/01/12 07:46
＞いい解説ページか本
Modern C++ design しかない！

>>74
そのテンプレートはModern本を読み進めて行かなければ
ほぼ理解不能だと思われる。
loki風のテンプレートの用法に慣れちゃえば
極めて普段どおりのやり方になるので、まずはModernの読破を。

76:デフォルトの名無しさん
04/01/12 15:57
>>73
shared_ptr のコンストラクタにある、template< class Y > は、

shared_ptr< void* >( new Object() ); とかやっても
きちんと Object のデストラクタを呼び出すための仕掛け。

大雑把に書くと以下のようなコード。

struct deleter_base
{
　virtual void destroy() = 0;
　virtual ~deleter_base(){}
};
template< class T > struct deleter : public deleter_base
{
　deleter( T * p ) : p_(p)
　void destroy() { checked_delete( p_ ); }
　T * p_;
};
struct shared_count
{
　template< typename Y >
　shared_count( Y * p ) : pd_( new deleter<Y>( p ) ) ... { ... }
　// カウンタが 0 を示したときに pd_->destroy を呼ぶような処理
　//　これで、Y は正しく delete される。
　deleter_base * pd_;
};

みたいなの。

77:デフォルトの名無しさん
04/01/13 23:13
templateをしっかり学習したければHaskellを
覚える事をお勧めする。

78:デフォルトの名無しさん
04/01/14 09:57
>>77
TypeListを処理するのに再帰を使用するとかが
関数型言語っぽいっていう理解はＯＫ？
その他、あれば解説よろしく

79:デフォルトの名無しさん
04/01/14 13:50
>>78
アダプタとか関数オブジェクト廻りの技術が関数型っぽい。
あと演算子のオーバーロードも関連も型クラスとの関連が。
後、boostとかだとそのままずばりlambdaがある。

80:デフォルトの名無しさん
04/01/16 18:07
まだ勉強中なんでツッコミ歓迎。

C++のtemplateとかoperatorって>>73,76みたいな
「きちんと面倒見るためにはそこまでしなきゃ(考えなきゃ)いけないのかよ」
ていうのが実務上嫌いなんだが、反面そこが趣味的には面白かったりする。
やっぱり簡単な使い方以外のC++はヲタク用言語という感じがぬぐえない。

で、ちょっと質問。
ランダムアクセス可能なiteratorで出力を加工することは可能かどうか。

template< class T > my_iterator {
private: T * current;
public: T & operator*(){ return *current; }
};

関係の無いところを端折ると上のように書いているんだが、例えば

public: T & operator*(){ return 1 + *current; }

は戻り値がT&だから出来ない。かといって戻り値をTにすると代入が出来ない気がする。

81:デフォルトの名無しさん
04/01/16 18:20
>>80
すぐ考え付くのは、

template <class T> my_iterator {
private:
　　　　T * currrent;
　　　　struct T_ref {
　　　　　　　　T_ref(T &r) : ref(r){}
　　　　　　　　operator T() {return ref + 1;}
　　　　　　　　template <typename U>
　　　　　　　　T_ref &operator=(const U &u) {ref = u; return *this;}
　　　　　　　　T &ref;
　　　　};
public:
　　　　T &operator*() {return T_ref(*current);}
};

色々問題がありそうだが。

82:デフォルトの名無しさん
04/01/16 18:52
>>81
operator T()なんて使い方が出来るのか。サンクス。
ただ加工に使う「+ 1」の値がmy_iteratorに入ってると
T_refのメンバにmy_iteratorへの参照も入れなくちゃいけなくて複雑になりそうだな。

そもそも加工をoperatorに頼っちゃいけないのだろうか。

83:デフォルトの名無しさん
04/01/17 00:29
プロキシオブジェクト使わないと厄介なところだな。
「参照じゃないと書き換えられない」みたいな問題は
More Effective C++（だっけ）の二重配列クラスの実装なんか
まさしく参考になると思う。

84:hiraoka
04/01/20 02:12
>>76
補足すると、継承したクラスのポインタに対応するため｡
>>80
boost::transform_iteratorがおすすめ。
自分で書きたければ、
T& operator*()と
T operator*() constを定義する方法もあると思う｡

85:hiraoka
04/01/20 02:13
>>76
補足すると、継承したクラスのポインタに対応するため｡
>>80
boost::transform_iteratorがおすすめ。
自分で書きたければ、
T& operator*()と
T operator*() constを定義する方法もあると思う｡

86:デフォルトの名無しさん
04/01/20 04:48
URLﾘﾝｸ(hp.vector.co.jp)

87:デフォルトの名無しさん
04/01/21 00:27
「C++は難しすぎ」 byコンパイラメーカ一同

88:デフォルトの名無しさん
04/01/21 18:41
コンパイラ屋さんってC++コンパイラを書くときに言語は何を使ってるんですかね？
Cなのかな？C++なのかな？
Cだと大変そうですね。

89:デフォルトの名無しさん
04/01/21 21:58
最初のC++はCに変換するプログラムで、Cで書かれていたそうだ。
最初のCはアセンブラで書いたそうだ。
最初のアセンブラは機械語で書かれた。バイトコードに直すのは人力でやった。

最近の商用のは知らんが、ほとんどCで書かれているんじゃないか？

90:デフォルトの名無しさん
04/01/22 00:47
“yacc”とか“コンパイラコンパイラ”でぐぐれ。

91:デフォルトの名無しさん
04/01/22 07:03
まともなエラー処理を書こうと思ったらyaccじゃ無理だろ。

92:デフォルトの名無しさん
04/01/22 16:16
まあ、yaccはあくまでコンパイラ作成を支援するものだし。

93:デフォルトの名無しさん
04/01/22 16:34
じゃあなんでコンパイラ・コンパイラなんて大仰な名前がついてるんだ？

94:デフォルトの名無しさん
04/01/22 17:45
ｽﾚﾘﾝｸ(tech板)

続きはこちらでどうぞ。

95:73
04/02/01 17:05
>>75,76,77

急に忙しくなってレスが遅れましたが、参考になりました。
ありがとうございます。

96:自称C++厨をクビにせよう運動
04/02/09 10:20
ｸﾞｺﾞｺﾞｺﾞｺﾞｺﾞ!!!

いまこそ、プログラマ革命を起こすときだ！
（亜ぼーんする愚か者には核ミサイル無量大数本分の死を！）

　～　自称C++厨の化けの皮をはがせ！運動展開中！　～　
(本当は自称C++厨なんてたいしたことがない、上辺だけなのだ！　真実を見よ！)
大半のC++厨はインチキ詐欺師の卑怯者！
オブジェクト指向も知らなければデザインパターンも知らない悪い奴である。
しかも悪名高いウォータフォール信者と来た！　許せん！　今こそ正義の一撃を！
大半のC++厨は汚いコードを書いてチームをわざと混乱させメンテナンスの手間を増大させる悪魔なのだ！
大半のC++厨は自己保守的で官僚的で革新性が無く
自分のスキルの程度を誤魔化すためにわざとソースコードを読みにくくしているのだ！
(こいつらはわざと読みにくくすれば他人が解読するのにに手間がかかるので
凄いと思いこまれると勘違いしている馬鹿どもなのだ)

こんな卑怯者が許されるか！

蓋を開けてみればただのＣ言語しかできないとんでもない低脳である。

こんな悪魔のような給料泥棒なやつが金をもらっていることは絶対に許されるべきではない！
即刻減給するかクビにしてやるべきである！

このような卑怯なC++厨の行為は宣戦布告と見なさなければならない行為であり
大義名分を持って即刻解雇すべきである！

自称C++厨の化けの皮をはがせ！　自称C++厨の化けの皮をはがせ！
自称C++厨の化けの皮をはがせ！　自称C++厨の化けの皮をはがせ！
自称C++厨の化けの皮をはがせ！　自称C++厨の化けの皮をはがせ！

正義は勝つ！悪の枢軸・自称C++プログラマをこの世から抹殺せよ！

97:デフォルトの名無しさん
04/02/09 11:08
>>96
暴れるのはマ板だけにしとけ知的障害者。

98:デフォルトの名無しさん
04/02/09 19:38
>>96
ただのＣ言語すらできないヒトはどうすればいいですか？

99:デフォルトの名無しさん
04/02/09 19:42
>>98
それは俺様のことか？

100:デフォルトの名無しさん
04/02/09 19:50
>>98
(ﾟДﾟ)

>>99
そうだ

101:デフォルトの名無しさん
04/02/10 01:39
>>96
おまえもHaskelとかScheme勉強しろよ。

102:デフォルトの名無しさん
04/02/10 02:20
HaskelやSchemeを勉強しても仕事の役に立つとは思えない

103:デフォルトの名無しさん
04/02/10 02:39
デザインパターン勉強しても仕事の役立つとはおもえない。

104:デフォルトの名無しさん
04/02/10 02:49
Modern C++ Designが仕事の役に立つとは思えない。

105:デフォルトの名無しさん
04/02/10 03:04
仕事が俺の役に立つとは思えない。

106:デフォルトの名無しさん
04/02/11 18:52
松戸ナルドがおいしいとは思えない。

107:デフォルトの名無しさん
04/02/11 18:55
松戸にもマクドナルドがあったのか

108:デフォルトの名無しさん
04/02/11 20:55
イノセンス、それは　いのき

109:デフォルトの名無しさん
04/02/11 23:34
土佐、それは高知

110:デフォルトの名無しさん
04/02/12 00:50
北関東の県が必要だとは思えない。

111:デフォルトの名無しさん
04/02/12 12:15
>>110
群馬栃木茨城というわかりやすい駄目トリオがなくなると、
神奈川埼玉千葉のどんぐりの背くらべトリオによる
No2争いが激化する。

112:デフォルトの名無しさん
04/02/12 13:35
横浜＞神奈川
ディズニーランド＞千葉
さいたま＞埼玉

113:デフォルトの名無しさん
04/02/15 22:15
>>107
あるよ。まんまえに。いってみ

114:デフォルトの名無しさん
04/02/22 21:06
テムプレートってどういうときに使うんでつか？
難しすぎて頭がおかしくなります。
たとえば１から１００まで足すプログラムに使いませんよね？

115:デフォルトの名無しさん
04/02/22 21:14
使えますが

116:デフォルトの名無しさん
04/02/22 21:18
#include <iostream>
template <int n> struct Sum {
enum { X = Sum<n-1>::X + n };
};

template<> struct Sum<1> {
enum { X = 1 };
};

int main()
{
std::cout << Sum<100>::X;
return 0;
}

117:デフォルトの名無しさん
04/02/22 21:19
>>2
15歳ですべて悟った俺は変人でしょうか

118:デフォルトの名無しさん
04/02/22 21:47
テンプレートを使いこなしたかったら Modern C++ Design を読むべし、そうしなければ全く始まらない。
テンプレートはOOその他従来のパラダイムのように、プログラムを書くための物ではない(もちろん使えるが、そういうやり方は古いやり方)
Modernなテンプレートプログラムとは、プログラムを生成するプログラムを書くのだ。
例えばデザインパターンのパターンを見て、そのパターンを実装するのが従来のやり方。
テンプレートを使う場合は、そのパターンを生成するプログラムを書くのだ。
一つ上のステージからプログラムを見下ろす様にプログラムをするんだ。

119:名無し募集中。。。
04/02/22 22:01
>>115-116
それは１から１００まで足すプログラムというより、
１から１００まで足してある数値を取り出すプログラムでは？

120:デフォルトの名無しさん
04/02/22 22:17
実行時に足すかコンパイル時に足すかの違いでしかない。

121:デフォルトの名無しさん
04/02/22 22:30
コンパイラに足させるプログラム

122:デフォルトの名無しさん
04/02/22 22:37
template<int i> class sum
{
public:
int operator() {
return i + sum<i - 1>()();
}
};

template<> class sum<1>
{
public:
int operator() {
return 1;
}
};

じゃあこうすれば良いのか

123:デフォルトの名無しさん
04/02/22 22:55
>>122
オプティマイズがかかったらやっぱりコンパイル時に足していそうだな(藁

124:デフォルトの名無しさん
04/02/22 23:22
オプティマイズは考えなくていいんじゃないか？
設定やコンパイラによっても違うし。

コンパイル時に計算させるか、実行時に計算させるかの意図がコードに現れてればいいんじゃないかな。

125:デフォルトの名無しさん
04/02/22 23:31
どうしてもというのなら

template<int i> class sum
{
volatile int v;
public:
sum() : v(i) { }
int operator() {
return v + sum<v - 1>()();
}
};

126:デフォルトの名無しさん
04/02/22 23:32
sum<i - 1>()();

こうじゃなきゃだめだな

127:デフォルトの名無しさん
04/02/22 23:35
おまいら >>114 の質問に答えてないよ。

「使いませんよね？」と聞いているのに、「使える」という答えはおかしい。
いつもそうゆうコードを書くかどうかを聞いているので、可能不可能を聞いているのではない。

漏れの答えは、そんなことには多分使わない。

128:デフォルトの名無しさん
04/02/23 00:28
どうでもいいけど、
int operator() {
の宣言は、
int operator()() {
でないとコンパイル通らなくないか？

勘違いだったらｽﾏｿ

129:デフォルトの名無しさん
04/02/23 00:34
yes

130:デフォルトの名無しさん
04/02/23 00:40
>>127
どう使うかって事にもよるね、例えばその計算結果から型を選択するとかいった処理なら
テンプレートを使うしかないし・・・
最近はJavaやC#の場合、リフレクションとかもあるので無茶な事をすれば実行時にもできるかもしれんが、余りやりたくは無いねぇ。

131:デフォルトの名無しさん
04/02/23 00:45
リフレクションいいよね。

Ｃ＋＋で実現したいんだけど、どっかに参考になるコードないかなぁ。

132:デフォルトの名無しさん
04/02/23 08:37
むかーしリフレクションっぽいコードをC++で書いた。
お前のコードじゃねえだろどこで派食ったといわれて結構へこんだ。
まああれだ、スマートに書くか効率良く書くかの二者択一になるからやめとけ。

133:デフォルトの名無しさん
04/03/01 13:32
C++厨のレベルの低さが垣間見えるスレですね

134:デフォルトの名無しさん
04/03/03 18:26
これからなんだよ、まだこれからこのスレはすんげぇ面白くなるんだよきっと。
きっと1さんがこのスレを優良スレにしてくれるんだよ。
1さんがこのスレを名スレにしてくれるんだよ。
1さんが素晴らしいネタを提供してくれるんだよ。
だからみんな、これからの1さんの書き込みを楽しみにしようよ。
これからこれからこれからこれからまだまだまだまだ…

135:デフォルトの名無しさん
04/03/04 18:37
1さんって俺じゃねーか。おまえらまだスレの連番付け間違えた事チマチマ恨んでるのか？
でもせっかくだから盛り上げていくか？

>>133
а≧○иξ⊃ＸγΘ△Φ？

136:デフォルトの名無しさん
04/03/04 19:09
>>135
a=＄д゜【＠（）πr2+3.14

137:デフォルトの名無しさん
04/03/05 23:13
>>136
Пкδ＼Δν⊃∃ю！

138:デフォルトの名無しさん
04/03/06 02:10
>>114
『Effective C++』の41項参照。

例えばWin32の各種ハンドル型をデストラクタでクローズするラッパクラスを作るときに使った。
型は違う（HANDLE・HINTERNET・SC_HANDLEなど）。でも処理は同じ（最後にクローズする）。

『Modern C++ Design』の書き方を許してくれる職場は少ないと思う。
理解できる人間がいなくてメンテナンス性が下がるため。（理解さえできていれば本当は上がってるんだけどね。）
そういうときは仕方ないので宣言マクロ／実装マクロにする。それなら理解できる人も多い。

あとは標準ライブラリのコレクションを使えないときに（車輪を再発明するために）使った。
このときはメモリの動的確保をしないという制限があった。
（Allocatorを書く方法もあるが、上と同じ理由でそれが許されることは少ないと思う。）

139:デフォルトの名無しさん
04/03/07 20:04
>Allocatorを書く方法もあるが、上と同じ理由でそれが許されることは少ない
随分厳しいですな

もうちょっと分りやすい構造になればいいんですがね > template
漏れはもう boost から戻れない体になってしまいました。

140:デフォルトの名無しさん
04/03/15 11:12
三大悪の枢軸国の紹介
　C++帝國(北朝鮮)　← C++厨代表の正体は、何と！　金正日だった！
　VB帝國(イラン)　←　VB厨代表はイランに潜伏していいた！
　Perl帝國(イラク)　← Perl厨代表フセインがついに逮捕された！

141:デフォルトの名無しさん
04/03/15 13:59
>>140
C++が分らなくて火病でも起こしたか？

142:デフォルトの名無しさん
04/03/18 16:38
Java帝国(オウム) ← Java厨代表は何と！地図夫(趣味:ソフマップ通い)だった！

143:デフォルトの名無しさん
04/03/29 19:49
鯖削除は難しすぎ

144:デフォルトの名無しさん
04/04/02 08:21
Modern C++ Designって簡単なことしか書いてないのにね。
それを難しいというのはよほどの馬鹿なんだろうね。
そんな馬鹿がソフトウェア開発にたずさわるのは社会的な悪だね。
医者だと無免許医は摘発されるのに
自動車だと無免許運転は摘発されるのに
プログラマーだけ低能でもやっていけるというのが諸悪の根源。

C++難しいとかいう脳障害の低能は
そもそもプログラミングに向いてないんだから
とっとと転職しろっつーの。

145:デフォルトの名無しさん
04/04/02 09:01
＞プログラマーだけ低能でもやっていけるというのが諸悪の根源。
大工よりまし。

146:デフォルトの名無しさん
04/04/02 09:32
>>144
> 医者だと無免許医は摘発されるのに
> 自動車だと無免許運転は摘発されるのに
ま、低能が免許持ちまくりなんだけどな、どっちも。

147:デフォルトの名無しさん
04/04/02 10:18
確かに免許制にして一定水準以上の者でないと開発に関われないとしてもいいかな。

その方が学ぶ側も採用する側も分かりやすくていいと思う。

148:デフォルトの名無しさん
04/04/02 11:27
>>146
なんなら私が手術してあげましょうか？

149:デフォルトの名無しさん
04/04/02 21:40
C++は難しくないけどC++厨はオナニーしすぎ

150:デフォルトの名無しさん
04/04/02 22:37
またわけのわかんないレスが来たな

151:デフォルトの名無しさん
04/04/03 15:52
難しいかどうかなんて問題じゃないんだ。
問題は出来るか出来ないかだろ？
ま、簡単だと言ってる奴ほど実は何も出来ない
というのはよくあるけどな。

152:デフォルトの名無しさん
04/04/04 08:53
ペーパードライバーならぬペーパープログラマーだな

153:ラインプリンタ
04/04/04 09:23
呼んだ？

154:デフォルトの名無しさん
04/04/21 05:09
普通、電気系のエンジニアはソフト"も"書けるがソフト屋はソフト"しか"書けないんだろ？
ちゃんちゃらおかしいね。それでもエンジニアか？あぁ？
ソフトぐらい文系あがりのねぇちゃんでも書くぜ。
人生の敗北者が下る職業
タクシー運転手，塾の講師，ソフト屋
だろ？

155:デフォルトの名無しさん
04/04/21 05:31
↓アビバ資格者

156:デフォルトの名無しさん
04/04/21 09:59
>>154 は、あまり難しいコードを見たことがないそうです。

157:デフォルトの名無しさん
04/04/21 20:12
ここで俺の登場！！！

158:デフォルトの名無しさん
04/04/22 11:48
と言われても…どちら様？

159:デフォルトの名無しさん
04/04/22 16:38
そのおかたをどなたとこころえる！？

160:デフォルトの名無しさん
04/04/23 20:30
1ですね。

161:デフォルトの名無しさん
04/04/28 22:53
URLﾘﾝｸ(page4.auctions.yahoo.co.jp)

162:デフォルトの名無しさん
04/04/28 23:06
OL５０人

163:デフォルトの名無しさん
04/04/28 23:10
難しいプログラムならバカでも書ける。
いかにサボり、楽をするために間単に書くかが私の人生のスタンスと一致していてすばらしい。

164:デフォルトの名無しさん
04/04/29 23:48
>>147
学生さん？
現場じゃそんな子と逝ってられませんよ？

165:デフォルトの名無しさん
04/04/30 14:35
C++はメモリ管理機構がないからムズカシイとかよく言われるけど、
言語側が暗黙のうちにGC用意してくれるよりもライブラリとして用意されるべきなんじゃないかな
と最近思うんだけどどうなんだろ。
影でこそこそ処理されると気持ち悪い。

166:デフォルトの名無しさん
04/04/30 15:05
ライブラリとして、だと
「わざわざ使わないといけない」だから
面倒な人間は何をしてくれるか予想がつかない。

167:デフォルトの名無しさん
04/04/30 18:00
つかjava使ってて思ったのが

＿|￣|○　＜　頼むから、俺にメモリ解放処理をさせてくれ

だった。

168:デフォルトの名無しさん
04/05/01 02:28
これからコンパイル後がどうなるかなんて何も考えずに、やらせたい処理だけ
便利なAPI使って記述すればいいって時代が到来するんだろうな。
低レベルな処理なんて組み込みだけ・・なんてことになるのかなぁ。
C++でﾊｧﾊｧする奴にとってはツマラナイ世界かも。

169:デフォルトの名無しさん
04/05/01 10:41
メモリ管理を自分でしないと気持ち悪いって人はあれかな、
実生活でもマメに掃除とかする香具師？

俺みたいに部屋は散らかし放題で
極限まで汚れたら渋々掃除するタイプはダメだ。
取ったメモリの解放まで面倒見てらんねえ。

170:デフォルトの名無しさん
04/05/01 10:58
>>169
漏れの場合，部屋は散らかりまくりだがヒープは絶対片付ける．

171:デフォルトの名無しさん
04/05/01 11:27
俺は後々片付けるのが嫌で
物理的な参考書とか資料とか極力本棚から持ち出さない人。

172:デフォルトの名無しさん
04/05/01 16:38
散らかっているかどうかよりもむしろ、物の位置や処遇が
「自分の手の内に入って」いないと気が済まないかどうか、に近い気が。

173:デフォルトの名無しさん
04/05/01 20:15
>>165
＞影でこそこそ処理されると気持ち悪い。
高級言語は、多かれ少なかれどこか影でこそこそやってます。
本当にそれが嫌なら、アセンブラで組めｗ

174:デフォルトの名無しさん
04/05/01 21:20
>>173
そうとも限らないだろ。

175:デフォルトの名無しさん
04/05/01 22:03
>>174
どういうところが限らないんですか？
内容無しの反論なら誰でも出来ます。

176:デフォルトの名無しさん
04/05/01 23:49
>>175
＞高級言語は、多かれ少なかれどこか影でこそこそやってます。
証明できないからじゃない？

177:デフォルトの名無しさん
04/05/02 00:51
>>175
「高級言語では」何が「影でこそこそ」に当たるの？

たとえばa = b + c * d; が
tmp = c * d;
a = b + tmp;
とかに分解される事？

マクロアセンブラでも、
ラベルがアドレスに展開されたりする事は
影でこそこそに当たらないの？

たとえば、Cでは何が影でこそこそしてる？Pascalでは？
どっちも高級言語じゃないのか、スマンな。

178:デフォルトの名無しさん
04/05/02 01:04
>>177
GCの話じゃねーのか？

179:デフォルトの名無しさん
04/05/02 02:50
言語が高級になればなるほど、コンピュータがやってくれることが増えるってだけだろ。
コンピュータは元から人間の手間を省く道具。だからそれは自然なこと。
それが嫌いならアセンブラ（よりも機械語のほうがいいか？）を使えってことだろ。

180:デフォルトの名無しさん
04/05/02 05:06
>>178-179
影でこそこそが気持ち悪いって言う人間に
考えもなしにアセンブラで組めなんていう煽りを何のするなということだ。
177で正論ぶってるから、更に気になっただけだ。

181:デフォルトの名無しさん
04/05/02 05:07
×考えもなしにアセンブラで組めなんていう煽りを何のするなということだ。
○何の考えもなしにアセンブラで組めなんていう煽りをするなということだ。

編集ミスった。

182:デフォルトの名無しさん
04/05/02 05:07
×177
○175

、、、orz

183:デフォルトの名無しさん
04/05/02 11:50
アセンブラは全く知らないんだけどメモリ解放はどうするの？
やはりプログラマによる手動解放？

184:デフォルトの名無しさん
04/05/02 12:51
>>183
mallocに相当するコード自分で買い解け

185:デフォルトの名無しさん
04/05/02 14:25
brkとかHeapAllocとかOS提供のAPIを呼ぶ
あとは、cのライブラリをリンクするとか。

186:デフォルトの名無しさん
04/05/03 23:09
C++を覚えるっつーか、使いこなすレベルになるころには
管理職をやらされるのが日本のコンピューター業界。
そして新人は今日もまたメモリリークしまくりのコードを量産する。

187:デフォルトの名無しさん
04/05/03 23:15
>>186
年取ると新しい考え方を受け入れられくなったり、徹夜の仕事
がとても続けられなくなるからそれでいいのよ。

188:デフォルトの名無しさん
04/05/04 09:42
>>187
若い頃から徹夜仕事しなかったし、この歳になっても睡眠時間3時間ですが何か。
あーでも、役職はついてるし部下もいるなぁ。

189:デフォルトの名無しさん
04/05/04 11:47
>>188
過労死すんなよｗ

190:デフォルトの名無しさん
04/06/12 19:50
過労死しそうな人が出るほど C++は難しすぎ

191:デフォルトの名無しさん
04/06/15 06:24
>>190
激しく同意

192:デフォルトの名無しさん
04/06/18 14:54
c++の何が難しいのかがわからない。
難しいこともできるって話じゃないのか？

俺的にはVBの方が難しい（めんどい）ような
あと、パールとかはキャストがきもい。

193:デフォルトの名無しさん
04/06/18 15:26
Perlのキャスト？

194:デフォルトの名無しさん
04/06/18 18:52
俺も、Javaや、VBのほうが、よっぽど難しい。

195:192
04/06/18 21:30
>>193
いや、だいぶ前にちょろっとやっただけだからうろ覚えだが、
c++なら明示的にキャストして、キャストできないようならコンパイル時にエラーでるしょ？
パールって何でもかんでも、暗黙的に型変換してるイメージあって、怖い。

196:デフォルトの名無しさん
04/06/18 21:37
perlがCGIの筆頭であり続けるのは、そのきもいキャストのおかげなのだが。

197:デフォルトの名無しさん
04/06/18 21:39
perlに型はありませんよ

198:デフォルトの名無しさん
04/06/18 21:43
コード中に型宣言が無いだけで実行時にはどの言語には型判断されてるでしょ
バリアント型ってそういうもんだと思われ

199:デフォルトの名無しさん
04/06/18 21:45
×言語には
○言語でも

200:デフォルトの名無しさん
04/06/18 21:49
なぜそこでVB?

201:デフォルトの名無しさん
04/06/18 21:50
バリアント型ってVBだけか？jsとかのvarもそれだろ？

202:192
04/06/18 22:10
いや、そのキモイキャストがいやだってだけ・・・。筆頭であろうが気にしない。

実行時判断っていうのが怖いわけで、例外とかめんどくさ。

俺が個人的にVB嫌いなのは、ポインタ取得とかめんどくさいから。
あと、まぁ、なんか色々めんどくさい。とc++になれてるとそう思う。

203:デフォルトの名無しさん
04/06/18 22:11
>>201
その気になればC++だってValiantクラスとか作れるだろう
class Valiant
{
public
　operator (int)();
　operator (char)();
　operator (short)();
　operator (long)();
　operator (long long)();
　operator (float)();
　operator (double)();
　operator (long double)();
　operator (char *)();
　operator (wchar_t *)();
・・・

204:192
04/06/18 22:17
>>203
boost::anyとかあるけどね。
ATL系とかでも。

でもboost::anyの場合、
代入するときはともかく、値を取得するときは明示的にキャストして
失敗したら例外送出だからなぁ。
なんつか、この明示的にって段階踏まないといやなわけでして。

205:デフォルトの名無しさん
04/06/18 23:59
boost::variant

206:192
04/06/19 00:10
>>205
そういや、それもあったなぁ。
いまだ使ったこと無いが。
なんに使うと効率てきなのかいまいちわからん。
ビジターパターンに使えるっていうが、ビジターパターン自体まだ使ったこと無いや。

207:デフォルトの名無しさん
04/06/19 00:15
C++が難しくないなんて言えるなんてすごいな。
今までVB,C,C++,Dehphi,Java,PHPなどで業務アプリを作って来たけど、
一番生産性が低いと感じたのはC++だった。
もちろん、それなりに習熟すれば生産性はあがるのだろが、
習熟するまでの時間がかかりすぎる感がある。
今の職場では多分俺が一番C++に詳しいけど、C++をマスターしたなんてとても言えないし、
積極的にC++を採用したいか？と聞かれれば可能な限り他言語を選択したい。
C++マンセーになる理由が俺には解らん。。。

208:デフォルトの名無しさん
04/06/19 00:27
>>207
WindowsのServiceアプリ組むときなんかはC系の言語が一番便利なわけで
人によってはCでそのまま組むよりもC++の方が開発時効率が上がる
少なくとも私はそう
CよりもC++の方が一度に考えなければいけない要素が少なくて済む

209:デフォルトの名無しさん
04/06/19 01:10
>>207
C++以前にCに十分習熟していないせいだと思うよ

210:デフォルトの名無しさん
04/06/19 01:26
生産性の低い言語＝習熟しにくいだからな
熟練者が生産性高いよって言ってもサンプルにはならへんのが実情
個人的にはDに一番期待している

211:デフォルトの名無しさん
04/06/19 01:31
つーか、業務系なんてどの言語で書いたって同じだろ。
C++のメリットが活きるのは寧ろ制御系だからな。

212:デフォルトの名無しさん
04/06/19 01:36
てか、俺的イメージだが、
ｃ++からｃを省いたようなもんがJAVAって感じだが・・・。
VBで生産性あがるっていっても、簡単なもんだけでしょ？めんどいことになるとできなそうだし。
デルファイはいじったことないなぁ、簡単らしいって話はきくが。
PHPもまだないなぁ。

俺はｃ++2年ほどやったが、
後は、
アセンブラ、
ロケール、
メモリアロケータ、
modern c++ design 読んで、
デザパタ極めて、
マルチスレッドも極めるくらいかねぇ。
って先なげぇ。
まぁ、一部ｃ++以外にもつかえるが・・・。

213:デフォルトの名無しさん
04/06/19 20:53
ISO C++の規格策定にかかわっている人にとっても、C++は難しいらしい。
現行の規格に内在するバグというか不都合な点がバラバラ出てきている。
URLﾘﾝｸ(www.open-std.org)
URLﾘﾝｸ(www.open-std.org)

214:デフォルトの名無しさん
04/06/20 11:10
C++もＪａｖａも使ってる俺からすればJavaの方が圧倒的に簡単。
両者比較してJavaのほうが難しいなんていってる奴はオブジェクト指向理解して無いだろ（ﾌﾟﾌﾟﾌﾟｯ
せっかくC++コンパイラ使ってるのにＣみたいな書き方ばっかりする宝の持ち腐れオオバカや郎なんだろうな（ｗｗｗ

215:デフォルトの名無しさん
04/06/20 12:00
>>214
誰も「Javaのほうが難しい」なんていってないと思うが。

216:デフォルトの名無しさん
04/06/20 12:07
Javaしか出来ないJava厨の思考回路は意味不明過ぎて難しい

217:デフォルトの名無しさん
04/06/20 17:25
Cしか出来ないJavaを使った事のないような時代遅れの無能親父の煽りはもう沢山

218:デフォルトの名無しさん
04/06/20 20:40
Javaしかできない連中はただいま大量生産中です。
正直言ってヤバいっすね。

219:デフォルトの名無しさん
04/06/20 21:02
ほとんどｃ++しかできないです。
まぁ他の覚えるのはそれほど苦労はしないけど。使わんからすぐ忘れる。

220:デフォルトの名無しさん
04/06/20 21:05
次の本命はD言語だな
メモリリークを起こさない上に任意のタイミングでGCできる優れもの
２ｃｈブラウザもDで作れば無駄にメモリ取らずに済むよ

221:デフォルトの名無しさん
04/06/20 21:23
>メモリリークを起こさない上に任意のタイミングでGCできる優れもの
大抵のGCはメモリリーク起こさないし、任意のタイミングでコレクトできると思うんだけど

>２ｃｈブラウザもDで作れば無駄にメモリ取らずに済むよ
なんで？

222:デフォルトの名無しさん
04/06/20 21:37
>>221
>>メモリリークを起こさない上に任意のタイミングでGCできる優れもの
>大抵のGCはメモリリーク起こさないし、任意のタイミングでコレクトできると思うんだけど
ランタイムなしでそれを実現できるのさ

>>２ｃｈブラウザもDで作れば無駄にメモリ取らずに済むよ
>なんで？
２ｃｈブラウザは起動初期の倍近くのメモリリークが起こってるからね

223:デフォルトの名無しさん
04/06/20 21:45
>>222
ランタイムなしでそれを実現出来るから何？

2chブラウザって沢山あるけど、そもそもどの2chブラウザなの？

224:デフォルトの名無しさん
04/06/20 22:03
>>223
ランタイムが無いって事は早いって事じゃん！
ちなみに俺にブラウザはLive2ch、最強だぜ

225:デフォルトの名無しさん
04/06/20 22:17
Live2ch って VB製じゃなかったか？
速さとか軽さとかを追求したものではないだろう……。

226:デフォルトの名無しさん
04/06/20 22:22
というかVBランタイムってGC無いんだと今知ったのは内緒ｗ

227:デフォルトの名無しさん
04/06/20 22:29
ネイティブでGC作る言語は強力だとは思うが
資産が無い上にMSがC#発表したばかりでのってくるとも思えないのが痛い

228:デフォルトの名無しさん
04/06/20 22:38
おまいら、自分のケツぐらい自分でふけよ。
その内、下の世話までM$におながいすることになるぞ。

229:デフォルトの名無しさん
04/06/20 23:09
てーか、GCいらない。
メモリ取得、解放するときの動作早くしろ。
自分でメモリアロケータをカスタマイズしなくても、
コンパイラオプションの設定で超高速で動くようにしてくれ。

230:デフォルトの名無しさん
04/06/20 23:20
GC使ったほうが長時間安定した速度で動くから、
非GC環境が速いとも言い切れないらしいよ

231:デフォルトの名無しさん
04/06/21 00:12
今ホットゾヌ２使っているけど、メモリリークひどすぎ。Delphiなんだけどなぁ。
スレをどんどん見ていくとあっという間に５００ＭＢほどに未使用メモリが膨れあがる。
正直一番気に入っているので、C#で書き直して(　ﾟдﾟ)ﾎｽｨ…。

232:デフォルトの名無しさん
04/06/21 00:21
>>230
できれば根拠が知りたい。

233:デフォルトの名無しさん
04/06/21 00:55
>>232
良く>>230の言っている意味がわからんが、非GC環境で「メモリリーク」が
どんどん起こったとして、メインメモリを食いつぶしてスワップ起きまくりに
なるから遅くなる、とかそういう次元の話なのだろうか。

234:デフォルトの名無しさん
04/06/21 01:07
メモリリークは非GC環境に限った話じゃないんだが。

235:デフォルトの名無しさん
04/06/21 01:25
>>232-233

URLﾘﾝｸ(www.kmonos.net)
より

C/C++ プログラマは明示的なメモリ確保と解放に慣れていて、
ガベージコレクタの効率や利点については懐疑的なようです。
私は、一からガベージコレクションを念頭に置いて書いたプロジェクトと、
既存のプロジェクトを GC を使うように方向転換した経験のどちらも持っていますが：

ガベージコレクトされたプログラムの方が高速です。これは直感に反するかもしれませんが、その理由は：

236:デフォルトの名無しさん
04/06/21 01:25
●明示的なメモリ管理の際によく使われる手法は、参照カウントです。
代入があるたびにカウントを増やしたり減らしたリソースを挿入するのは、速度低下の原因になっています。
スマートポインタクラスでラップしても、速度的な解決にはなりません。（
またいずれにせよ、循環参照を削除できない参照カウント方式は、一般的な解決策ではありません。）
●オブジェクトによって獲得されたリソースの解放には、デストラクタが使用されます。
多くのクラスでは、このリソースとは割り当てられたメモリのことです。
GCを使えば、ほとんどのデストラクタが空になり、完全に削除してしまえます。
●メモリ管理のためのデストラクタは、オブジェクトがスタックに置かれたときに影響が顕著になります。
例外が発生したときに、全てのスタックフレームでデストラクタが呼び出され、メモリを解放するような仕組みが必要となるのです。
もしデストラクタが関係しなければ、例外を処理する特別なスタックフレームを設定する必要がなくなり、コードは高速に実行されます。
●メモリ管理に必要なコードは全てを合わせるとちょっとした量になります。
大きなプログラムになるほど、キャッシュに入らない部分が増え、ページングが多く発生し、プログラムが遅くなります。
●GCは、メモリが残り少なくなってきたときのみ実行されます。
メモリに余裕があれば、プログラムは全速力で実行され、メモリ解放に一切時間を取られません。
●モダンなGCは、過去の遅いものより遙かに発展しています。世代型のコピーGCには、昔のマーク＆スイープアルゴリズムの非効率さはありません。
●モダンなGCはヒープの詰め直しを行います。これによってプログラムが活発に参照するページの数を減らし、キャッシュヒット率を高め、スワップ回数が減ります。
●GCを使うプログラムは、メモリリークの積み重ねで次第にパフォーマンスが悪化、という事態に縁がありません。

237:デフォルトの名無しさん
04/06/21 09:34
> ●GCを使うプログラムは、メモリリークの積み重ねで次第にパフォーマンスが悪化、
> という事態に縁がありません。

これはウソだな

238:初期不良
04/06/21 10:07
まあ、突っ込みたいのはわかるがメモリリークになる可能性は低くなっていると言う事でいいんじゃねーの？

239:232
04/06/21 10:57
>>235
提示してくれたページ、GC周りをさらっと目を通した。ありがとう。
●スマートポインタは使いたいケースに応じて選ぶことができるから、
　参照カウントだけと比べるのはどうかなぁと思う。
●デストラクタが空になるのはスマートポインタでも同様。
●例外に関しては同意。
●メモリが少なくなって来た時にごっそりメモリ解放するんだと
　むしろその一瞬非常に不安定になるのではないか。（これは欠点に書いてあったな）

自分は例外バンバン投げたいのでデストラクタが重くならないなら
それはありがたい。
ただ、Dって面白そうだね。autoを使ってscopedに解放もできちゃうようだし。
きめ細やかな言語だと感じた。GCの話題から外れてゴメン。

240:デフォルトの名無しさん
04/06/21 12:00
まあ、スタイルにも依るんでしょうけど。
●明示的なメモリ管理の際によく使われる手法は、参照カウント...
shared_ptrってそんなに頻繁にコピーってする？
俺は所有権のはっきりしないリソース（ファイル・ハンドル等）の管理に
使うことが多く、参照カウンタが変化するのってタスク相当の粒度の
オブジェクト間の構成を初期化するときぐらい。

●またいずれにせよ、循環参照...
上記のような使い方をする場合は、保持するオブジェクトと
保持されるオブジェクトの関係が階層的になり、参照がループすることは
無い。むしろGC導入によるdtor呼び出し遅延のほうが俺的には大問題。

●メモリ管理のためのデストラクタは、オブジェクトがスタックに...
俺の場合、Appレベルでは例外って殆ど使わないし。

つうか、GCスレってないのね。

241:デフォルトの名無しさん
04/06/21 18:54
>>240
「コンパイラ・スクリプトエンジン」相談室が失速気味なので
良かったら使ってやってください。

ｽﾚﾘﾝｸ(tech板)

242:デフォルトの名無しさん
04/06/21 20:27
>>239
>●デストラクタが空になるのはスマートポインタでも同様。

同様じゃないよ。C++だと書かなくてよくなるだけで、実際はコンパイラが生成してる。
GCがあると、「完全に」削除できる。

243:デフォルトの名無しさん
04/06/21 20:40
脳内コンパイラｷﾀ------

244:デフォルトの名無しさん
04/06/21 20:47
？

245:デフォルトの名無しさん
04/06/21 21:33
>>242
dtorに書いてなくても暗黙的にメンバ変数のdtorが呼ばれるつう
意味ならその通りだけど。
ていうか、236の2番目のはどういうメリットなんだろう。
記述忘れてメモリリークって意味ではauto_ptr/shared_ptrで書けば
ありえないし。まともなC++erならメンバにauto_ptr等を含んだ
オブジェクトを頻繁に（例えばsortの比較関数オブジェクト内で）
生成・破棄するようなコードはかかないだろうし。

サイズが減ってキャッシュが云々ってのもいまいち説得力に欠ける。

246:デフォルトの名無しさん
04/06/21 22:00
>>242
オブジェクトのデストラクタは空
スマートポインタのデストラクタは空でない
ということがいいたいのだろう

オブジェクト内にスマートポインタをもつなら
結局オブジェクトのデストラクタも空でなくなるが

247:232
04/06/21 22:06
>>242
デストラクタについては、
1. ソース上書かなくて良くなる
2. スコープが切れた瞬間に呼び出されるわけではなくなるから例外が効率良くなる
と言っているように見えた。だから1についてスマートポインタと同様と書いたんだが、
文意は違ったのかもな。でも、把握した事実は変わらないと思う。

完全に削除って表現が微妙だな。デストラクタが呼ばれなくなるわけじゃなくて
呼ばれるタイミングがスコープから抜けるタイミングではなくて、GCのタイミングになるよ
という意味だよね。

…C++から離れてる。そろそろやめたほうが良さそうだ。名無しに戻ります。

248:デフォルトの名無しさん
04/06/21 22:50
>>235
一般論としてGC付のが速いって言うなら
理屈はいいから実際のベンチ出せといいたい。

249:デフォルトの名無しさん
04/06/21 23:15
>>248
お前もGC無しの方が早いというならベンチ出せコラ

つか、どういうベンチプログラムならうまく計れるんだコレ

250:デフォルトの名無しさん
04/06/21 23:17
オブジェクトの生成と破棄（スコープアウト）をひたすら繰り返すベンチだな

251:デフォルトの名無しさん
04/06/21 23:20
計るんならゴミ回収遅延によるシステム全体の
ディスクキャッシュ効率の低下も考慮しとけって。

252:デフォルトの名無しさん
04/06/21 23:24
>●GCは、メモリが残り少なくなってきたときのみ実行されます。
>メモリに余裕があれば、プログラムは全速力で実行され、メモリ解放に一切時間を取られません。

これを素直に読むと
GC有りのプログラムを多数常駐させると互いにメモリ圧迫しあって
パフォーマンスががた落ちになりそうに聞こえるわけですが

253:デフォルトの名無しさん
04/06/21 23:27
言語とは関係ないとはいえ、現実的に
メモリが不足しがちだとOSまで不安定になるしねぇ。

254:デフォルトの名無しさん
04/06/21 23:30
あとDのコンパイラの最適化ってどの程度やってるの？
もともとコンパイラ屋だから能力的にはできるんだろうけど
言語仕様決めてライブラリガリガリ書いてその上最適化もやるって無理っぽくない？

255:デフォルトの名無しさん
04/06/22 01:47
・メモリが不足したらGCが走る
・メモリが不足するとOSが不安定になる
ということは、これに
・論理メモリよりも物理メモリの方が小さい
をプラスすると
・GCが走るときはOSが不安定なとき
・OSが不安定になるまでGCが走らない
ってなことになるんじゃないかしら？

256:デフォルトの名無しさん
04/06/22 01:59
コンパイラ屋だけど、実際GCの方が総合的には速いと思う、
コンパイラ側が全部管理できればオプティマイザに特別なアプローチが出来るからね。
ただC++には似合わないと思う、最小限の機能強化でGCはライブラリにして今流のtemplateでエレガントに実装すべきだ！
と主張してみたかったりもする。
C/C++は、組み込みから汎用までいかなる環境にも耐えられる言語であって欲しいです。
言語本体は最小限の機能のみをもつ機械語翻訳機がいい。

ところでDはGCを自作で置き換えるとかできるのかな？
日に日に強力になってきているDに興味が沸きつつある今日この頃。

257:デフォルトの名無しさん
04/06/22 05:44
Cは恥かしすぎ

258:デフォルトの名無しさん
04/06/22 10:13
>>256
>総合的には速いと思う
GCの最適化で？それともコードの実行時最適化？

もっともC++でもそういう総合的に早くするって考えは
あるよね。例えばvectorにpush_backする時にサイズを
２倍ずつ増やすとか。C++erでもそういうトレードオフを
理解しないでSTLとか使ってる奴っているだろうし。

259:デフォルトの名無しさん
04/06/24 17:21
vectorが完全に連続したメモリを確保するのに対して、
dequeがブロック単位でしか連続したメモリを確保しない事を知らない香具師が多すぎ

260:デフォルトの名無しさん
04/06/24 17:25
突然なんだ？

261:デフォルトの名無しさん
04/06/24 17:29
で、ベンチはまだか?

262:デフォルトの名無しさん
04/06/25 00:25
>>259
バッファ用のバイト配列をvectorで確保すると
知らない人間は面食らうよね

263:デフォルトの名無しさん
04/06/25 01:43
C++の難しさって殆んどtemplateが占めてんじゃねーの？

と思ったら>>144みたいなのも居るのね。。。

264:デフォルトの名無しさん
04/06/25 10:04
vector v(x);
read(&v[0]);
なんてやるなら、素直にscoped_arrayや、
それが許されないならコピペや自作で対応した方が
見た目にも易しいし。

265:デフォルトの名無しさん
04/06/25 10:27
>>264
同意しかねる。
その用法はvectorの設計コンセプトに合致するものであり、何の不満も無いよ。

266:デフォルトの名無しさん
04/06/26 12:49
同じく同意しかねる。ただ不満はある。
C++の言語が難しくて聖書のようにあげられる代表的な数冊の本を
読破理解しないと使いこなせないような言語になっちゃうのは
見た目に直感的じゃないからと思う。

267:デフォルトの名無しさん
04/06/26 13:02
でも全体としての言語仕様の大きさはともかく、
すぐ上で挙げられている「テンプレート」や「STL」といった個々の要素に関しては、
習うより慣れろを地で行ってると思うよ。本はリファレンス的に使えばそれで。

268:デフォルトの名無しさん
04/06/26 14:42
C++の難しさは言語仕様よりも使用方法のノウハウの難しさのような気がする
個々はたいした事はないのに組み合わさったときの威力は大きく、それを利用するためだと思う。
template <typename H,typename T> struct TypeList
{
typedef H head ;
typedef T tail ;
} ;
と書かれれば、これがどんな定義なのかはC++をちょっと知っていれば判るが
これをどう活用するのかとなると急に難しくなる。
分りやすい書籍を作るのに従来通りの言語仕様の本とライブラリの本だけでは補えない部分があるのに
その部分を上手く解説した本はあまり無い気がする。

269:デフォルトの名無しさん
04/06/26 15:16
>>268
それ、発想が Lisp 的なんよね。
Lisp 知ってる人からすると、そのコードも見ただけで何がしたいかすぐ分かる。
template を使ったメタプログラミングって関数型言語と似てるらしくて、
Lisp 的表現が良く使われる。

270:デフォルトの名無しさん
04/06/26 15:29
実際のコードは逐次処理的にかいてTypeList等で
それらのコードを組み合わせる構造を記述して
GenScatterHierarchy等で実際にコードを組み合わせて
実装を生成する。

関数型言語だと構造だけでなく実際に実行されるコードも
関数型っぽく記述しなきゃいけないってのが、慣れてない人間
にとっては厳しい。

そういう意味でC++でのMPっての有難いんだよな。

271:デフォルトの名無しさん
04/06/26 21:29
馬鹿は馬鹿なりの使い方すればいいし、
頭いい奴は頭いいなりの使い方すればいい
ってだけの話なんじゃないの？

272:デフォルトの名無しさん
04/06/26 21:40
>>271
両者が一緒にいるときはどうしたらいいのでしょう。

273:デフォルトの名無しさん
04/06/26 22:12
一番はバカにコードを書かせないで頭いいヤツに全部かかせることかな。

そっちの方が早く、優秀なモノが出来るだろう。

274:デフォルトの名無しさん
04/06/26 22:21
根幹にあたる部分を、頭いい奴にザッと作らせる。
頭悪い奴には、ただひたすらそれを使うか、応用する部分を作らせる。

プログラミングに限った話じゃないがナ。

275:デフォルトの名無しさん
04/06/27 02:40
>>272
ベアプログラミングで鍛えるべし。
勉強するきないやつなら、いじめるべし。

276:デフォルトの名無しさん
04/06/29 15:53
ネタふり
C++のグローバル変数初期化タイミングは難しすぎ。

dynamic initilizationなグローバル変数にいたっては
main前に呼ばれることすら保証されてない。
dynamic initilizationなグローバル変数の初期化の
スレッド安全性とか考えると頭痛くなる。

また、main前の初期化順序もある程度は制御したい。
翻訳単位のモジュール性を向上させる意味でも。

こればっかりはjavaが羨ましいよ...。

277:デフォルトの名無しさん
04/06/29 17:37
グローバル変数使うなよ

278:デフォルトの名無しさん
04/06/29 17:46
データメンバ　≒　グローバル変数

279:デフォルトの名無しさん
04/06/29 17:54
Cをやってきた人はC++が出来ないと嘆く人が多いですよね？
自分はC++から入ったんでCの理解はさほど困らなかったんですが、
教授でもそういう人が居ますよ。駄文失礼しました。

280:デフォルトの名無しさん
04/06/29 17:57
出来ないんじゃなくてやる気が無いだけだろ。
CとJavaがあればC++いらないし。

次ページ