C++は難しすぎ 難易度:2 at TECH
[2ch|▼Menu]
1:前々スレ985
03/12/18 06:52
理解できないわけないだろ!
デザパタも知らずにC++使いの質を下げるC厨には げんあり

前スレ達
難易度:1 URLリンク(pc2.2ch.net)
難易度:2 1スレリンク(tech板)

2:デフォルトの名無しさん
03/12/18 07:37
24歳ですべて悟りました。
天才だから。

3:デフォルトの名無しさん
03/12/18 07:41
難易度が上がっていないという驚愕の事実。

4:デフォルトの名無しさん
03/12/18 09:12
スレ建ては難しすぎ

5:デフォルトの名無しさん
03/12/18 09:20
十数年前はチーズバーガーが1個230円だった。
それが、ついこの間まで1個88円で売っていた。
これはつまり、その気になれば1個88円で売れたモノを230円で売ってた訳だ。
その昔に1個230円で食ってたオレに言わせれば全く腹の立つ話だ。

6:デフォルトの名無しさん
03/12/18 09:26
>>5
MZ-5500 の拡張メモリボード (256KByte) を
\72,000 で買った俺にしては(ry

7:デフォルトの名無しさん
03/12/18 09:30
チーズバーガーもメモリも十年前は今とは段違いにコストがかかったんだよ。

8:デフォルトの名無しさん
03/12/18 10:24
>>7
メモリは間違いなくそうだが、チーズバーガーのコストはあまり変わってなさそう。

9:デフォルトの名無しさん
03/12/18 10:53
>>8
品種改良による大量生産、輸送コストの削減。
加工食品の調達コスト削減、等々。

10:デフォルトの名無しさん
03/12/18 11:08
>>9
中国産農産物の輸入拡大。多分これが一番大きい。

11:デフォルトの名無しさん
03/12/18 16:00
「げんあり」は継承したんだ…

12:デフォルトの名無しさん
03/12/18 18:10
吉牛が290で食えたときには(ry

13:1
03/12/18 22:02
>>3 >>4
出勤直前で焦っていた。
正直すまんかった。

14:デフォルトの名無しさん
03/12/18 22:07
  ∧_∧
 ( ´∀`)

15:デフォルトの名無しさん
03/12/18 22:21
>>8
10年前の牛肉100% > 牛から食える肉を切り出したものが100%
現在の牛肉100% > 牛は100%肉として使う

16:デフォルトの名無しさん
03/12/18 22:58
>>13
つかそれ以前に

  糞 ス レ 勃 て て ん じ ゃ ね え よ 脳 挫 傷 !

17:デフォルトの名無しさん
03/12/18 23:22
例えば、C++をオブジェクト指向の入門に使用すると、まず突き当たるのはその言語仕様の複雑さです。
C++は手続き指向の言語であるCとの互換性を保つことを強いられたので、オブジェクト指向の本質とは
あまり関係のない部分が多く言語仕様に入り込み、習得のし難い言語になってしまっています。
(このように手続き指向をオブジェクト指向に拡張し、両者の概念の混在する言語をハイブリッド系OO言語
といいます)。またC++のようなハイブリッド系言語は、手続き指向でのプログラム作成が全く問題なく行え
てしまうので、「C++を使用しているが、オブジェクト指向になっていない(ただのCプログラミングをしている)」
ということが起こってしまいます。

更に、なんとかC++を使いオブジェクト指向の考えでプログラミングできるようになったとしても、言語の性質上、
メモリ管理の問題が常につきまとうことになります。もともとオブジェクト指向は、システムにまつわる問題を抽
象的に捉えられるところに利点があり、メモリ管理といった低レベルの部分はなるべく気にせずに、アプリケー
ションドメインといった上位の概念に注目したいはずです。C++ではメモリ管理をみずから行わなければならな
いため、アプリケーションに本質的な処理と、単なるメモリ管理の処理が入り交じり、




18:デフォルトの名無しさん
03/12/18 23:23
コード自体を非常にわか
りにくくする側面があります。また人間の手によるメモリ管理は、必ずといっていいほどメモリリーク現象を引き
起こします。このために、「あまり多くのオブジェクトを用意しないようにしよう」という考えが働くようになり、設計
上は分離されていたはずのクラスが実装時に安易に合成され、奇麗なオブジェクト指向設計をくずしてしまうこ
ともあります。

一方Javaはどうでしょうか。Javaはかなり奇麗にオブジェクト指向の考えを実現しているといえますが、
数値や配列などの「基本データ型」はオブジェクトではありません。そのために「全てを統一的にオブジェ
クトとして扱えるはず」というオブジェクト指向の原則に合致せず、やはり不自然なコードを書かねばなら
ない場面がでてきます。
例としてJavaでは、「何でも入れてしまえる順番つきの入れ物」を表すのに、Vectorというクラスが用意
されています。このVectorに物をいれるときに、基本データ型が混ざっていると以下のようなコードを強
いられます。

19:デフォルトの名無しさん
03/12/19 00:12
いいこと言うね〜 禿同だよ

20:デフォルトの名無しさん
03/12/19 00:45
>>18
出たなデザインパターン。プロジェクトの中で3人知ってる人間がいたら良い方だよ。
残りの雑魚は家に帰っても酒呑むかTV見てるかくらいの奴だし。
勤勉な奴は一握りだぞ?20代でそういうやつは極小。30代で技術しか取り柄のない奴が
逃げ道としてデザインパターンなんかを習得してる。悪いってわけじゃないけど、
30代が技術にすがるって、見ていて悲しくなるよね。


21:デフォルトの名無しさん
03/12/19 00:46
>>18
そ こ で

C#

だ!


22:デフォルトの名無しさん
03/12/19 00:46
感じて デジャヴ

23:デフォルトの名無しさん
03/12/19 01:17
>17-18
いまどき Vector型 は使わないね。
なんかのコピペかな。

それに必ずしも「完全に」オブジェクト化してれば
いいもんっていうものでもないよ。
原始型はラップすればいいだけだし。

Integer int1 = new Integer(123);
Integer int2 = new Integer(456);
int1.add(int2.getValue());

なんてやるより

int i1 = 123;
int i2 = 456;
i1 += i2;

ってやった方が楽だし分かり易いでしょ?


24:デフォルトの名無しさん
03/12/19 01:28
>>22
だから、30歳過ぎて、社会の政治的な要因に太刀打ちできるような
立場になってからもデザインパターンみたいな一技術で重宝されるような
人物に対して「逃げ道だよな」って言ってるの。20代の奴がやりたくてもできないような
ところで自分をアピールする術を持ってないのかって。
中堅者のやることっていったら、20代の奴が仕事をしやすいように、いろいろと根回しすることだろ?
年齢重ねても、やることが20代の延長だったら会社に居る意味ねーよ。
スパゲティコードだとか、その辺は中堅社員が口出すことじゃねーって。
むしろ、20代の奴が気付いて、中堅社員に意見をUPして、それから中堅社員が根回しするのが理想。
要は、いい歳こいて低レベルな話してんじゃねーよって。もっと抽象的になれってことだ。


25:22
03/12/19 01:45
>>24
何で俺にw

26:23
03/12/19 02:07
>24
俺か?w
まだ27なんだけどな。

つーかデザインパターン云々いってる
話はどこからきたわけ??



27:デフォルトの名無しさん
03/12/19 02:16
>>25-26
前スレのコピペだよ。
単なるあげ荒氏だから反応するな。


28:デフォルトの名無しさん
03/12/19 09:48
>>21
プップップ
残念ながら>>17-18のコメントはSmalltalk解説サイトの前文なのだ(藁
VB厨のようなM$の奴隷の雑魚どもが使う言語C#ごときに出る幕は無い(藁



29:デフォルトの名無しさん
03/12/19 10:15
>>18
>また人間の手によるメモリ管理は、必ずといっていいほどメモリリーク現象を
                       ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
>引き起こします。

書いた奴が、自分の間抜けっぷりを隠す為に
一般化しようとしているとしか思えない。

30:デフォルトの名無しさん
03/12/19 13:26
メモリリークを強調するのって
新言語をC++と比較するときの常套手段だよね。
Cならいざ知らず、C++を然るべき使い方すれば
メモリリークなんて滅多に起こさないと思うが。


31:デフォルトの名無しさん
03/12/19 14:13
ポインタに相当するものがあるなら、必ずメモリリークするよ

メモリリークするようなコードを書いちゃう人は、
どんなに管理手法を凝らしてもリークさせちゃう。

たとえばGCなんてその注意をほんのちょっと減らすだけでしかない。
にもかかわらず大げさに取り上げたがるのは、
表面的なところにとらわれてるか、初心者かのどっちかだろうねえ。

32:デフォルトの名無しさん
03/12/19 14:35
>>29
> >>18
> >また人間の手によるメモリ管理は、必ずといっていいほどメモリリーク現象を
>                        ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
> >引き起こします。
>
> 書いた奴が、自分の間抜けっぷりを隠す為に
> 一般化しようとしているとしか思えない。
ではお前は間抜けなことをせずに間違いを一切犯さずに
超超!超!超!超!超!!大規模アプリ開発で
ポインタ演算をべらぼーに徹底的に使い切ってコーディングできるか?

お前には無理だ。それは、お前が人間だからだ。


33:デフォルトの名無しさん
03/12/19 14:37
>>30
それがしかるべき使い方をする香具師がほとんどいないんだからねえ。

速度を強調するにはどうしても避けられない問題につきあたるわけよ

34:デフォルトの名無しさん
03/12/19 14:54
> 超超!超!超!超!超!!大規模アプリ開発で
> ポインタ演算をべらぼーに徹底的に使い切ってコーディングできるか?

できるよ。

規模が大きかろうが小さかろうが、
しかるべきサイズのモジュールやコンポーネントに分割して開発するだろ。

この「しかるべきサイズ」の条件として、「ポインタが安全に使える」
というのがあるだけの話。さらに言うなら、条件の一つでしかないし、
それほど重要じゃない。

35:いちゆ
03/12/19 15:02
C#はいまだにポインタ型が使えるんだが、
あれはどぅだ?

36:デフォルトの名無しさん
03/12/19 17:17
っていうかおまえらC++じゃなくてCのポインタをイメージ
してないか?Cのポインタは怖い。キャストとか特に。
C++だとauto_ptrやクラスでラップできるしね。

で、普段C++な俺がCでWinドライバ作成してるわけだが、
緊張感が違うな(w


37:Kusakabe Youchien
03/12/19 17:49
>>36
こわがりすぎー

38:デフォルトの名無しさん
03/12/19 18:06
>>27
いや、分かってるがワロタ

39:デフォルトの名無しさん
03/12/19 21:05
メモリーリークってJavaだってたいしてかわらんだろ?
使えるだけ使いまくって足りなくなったらいらない
メモリを開放してるんだから。

まぁ、要するにJavaはメモリ食い杉。

40:sage
03/12/19 21:21
GCがあったってリークさせるやつはさせるさ。

リークを完全になくすには例外安全を貫く必要がある。
過剰な例外安全の保証を行うと、性能面でのC++のメリットがなくなる。
そのあたりのトレードオフの存在が、C++のいいところでもあり悪いところでもある。

41:デフォルトの名無しさん
03/12/20 11:31
>>36
緊張感が違えば十分だが
Cのソースのメンテの場合などは
あきらめでいっぱいになる事もある。

42:Java最強
03/12/29 20:19
C++は列挙型なんて時代遅れのものがついてる欠陥品

43:デフォルトの名無しさん
03/12/29 22:05
おまえらマジでC言語のポインタで挫折したの?

44:デフォルトの名無しさん
03/12/29 22:19
abc.exeという実行ファイルがあったとして
この実行ファイルの引数がどうなっているか調べる方法はありますでしょうか?
もしくはそれがわかるソフトでもかまいません。
よろしくお願いします。

45:デフォルトの名無しさん
03/12/29 22:29
リファレンス(T&)渡しを的確に使用している奴はいるのか。
ポインタ渡しを使った場合と効果は同じだけど、
引数で渡すデータを変更しない場合は、リファレンスを使い、
値を変更する場合はポインタを使うようにしているのだが、
それ以外で適切な使い方を知っている猛者はご教授願いたい。
(コピーコンストラクタやoperator関数の引数ってのはなしで。)

46:デフォルトの名無しさん
03/12/29 22:33
>>45
中学生。


47:デフォルトの名無しさん
03/12/30 01:29
>>45
たとえばあるオブジェクトを指すクラスを作るときで、
そのオブジェクトをコンストラクタ以外では指定できないようにしたいとき、
参照型のメンバ変数とすることがとても有効な場合がある。


48:sage
03/12/30 02:47
適切、かどうかは判断しがたいが
templateをぽちぽちいじるようになれば、リファレンスは避けて通れなくなる。
いちいちポインタを要求するtemplateってのは使いづらいからね。


49:デフォルトの名無しさん
03/12/30 03:56
>>45
More Effective C++でも嫁

50:デフォルトの名無しさん
03/12/30 06:42
>>45
>引数で渡すデータを変更しない場合は、リファレンスを使い、

変更するかしないかはconstの有無で判断するもんだと思う。
ポインタでもリファレンスでも。

51:デフォルトの名無しさん
04/01/03 22:52
てかこのスレの住民は(>>48以外?)モダーン本も読んでないのか?

TypeTraitsで適切な引数型を自動的に検索できるのは
参照型のシンタックスがコピー渡しと同じだからだろうが。


52:デフォルトの名無しさん
04/01/04 00:44
テンプレート関係の勉強をしようにも、
頭が悪いので理解できない。

初心者用の本だとスタッククラスに対して、
int型やchar型をテンプレート引数にとる簡単な例ばかりで、
応用例は、ほとんど載ってない。

標準ライブラリとテンプレートのからみを説明している本は、
中級者以上の本ばかりなので、難しくて理解できない。
(特にsetやlistテンプレートの実装部分とかの説明が理解不能)

この辺のからみについて、何かわかりやすい本or
最適な勉強法はあるのでしょうか。

53:デフォルトの名無しさん
04/01/04 01:07
>>52
URLリンク(www.amazon.co.jp)
試しにこれ読んでみれ。

54:デフォルトの名無しさん
04/01/04 01:09
俺はlistやhashtableを実装(再発明)したよ。
lokiやboostのコードを読み漁りながらだったんだけど、
type traitsやfunctionalなんかが中心だったかなあ。
カナーリ勉強になったよ。

55:デフォルトの名無しさん
04/01/04 02:46
「JavaプログラマーのためのC++」ってないかね。
JavaのStringやVectorと対比させてSTLを教えてほしい。
newとdeleteの管理をちゃんとやるための設計のしかたとか。


56:デフォルトの名無しさん
04/01/04 10:46
newとdeleteの管理すらできないうちからSTLに手を出したりするから
C++がわからなくなる。
テンプレート(機能)は鬼門なので他が十分に理解できるまでとっておく。
STL(ライブラリ)はもっと鬼門なのでテンプレートが十分に理解できるまでとっておく。

あとは車輪の再発明はC++の学習には欠かせない要素。
自分で作ってはじめて理解できる。それがC++。

57:デフォルトの名無しさん
04/01/04 21:51
読む→試す→作る→だから身につく

58:デフォルトの名無しさん
04/01/05 01:15
どこかで見たことあるモンクだと思ったら…


そんなにこわがることないのにー ;-p



59:デフォルトの名無しさん
04/01/06 11:58
>>56
STL(あるいはその再発明)を使わなけりゃ例外安全な
deleteの管理なんて出来ないだろうが。

60:sage
04/01/06 22:48
>>59
そんなことはないない


61:デフォルトの名無しさん
04/01/07 02:13
出来ないというか、やる気はせんな。

62:デフォルトの名無しさん
04/01/11 21:41
>>59
auto_ptrはSTLじゃありませんが何か?

63:デフォルトの名無しさん
04/01/11 21:46
やっぱり安全なdeleteの管理はできそうもないな。
なぜならauto_ptrはSTLだからね。

64:デフォルトの名無しさん
04/01/12 00:25
GNU関係のプログラム書いてたら99%はANSI Cだから素のポインタ操作も
最初は苦しむが慣れたら明確かつ究極的なインタフェースとして使えるよ。
サーバ系で一リクエストに何千回も処理する箇所があればオブジェクト指向系
の糞重い&メモリ食いな処理は命取りになる。
そういう時にポインタでデータをきちきちに詰める。
1バイト単位できっちり。
JAVAやC#みたいなインタプリタと違って最適化やVMも必要ないから
十分なパフォーマンスが得れる。
だが熟成には何年何ヶ月と要するよね。
適材適所があるわけだから一概にC++はダメって言い切るのはどうなのかな?


65:デフォルトの名無しさん
04/01/12 00:52
C# はインタープリタじゃないわけだが。
Java も最近 JIT 方式のものがあったりするし。

揚げ足取りスマソ。

66:デフォルトの名無しさん
04/01/12 01:12
やっぱし テンプレートは理解しておいた方がいいのかなぁ。
難しい..

67:デフォルトの名無しさん
04/01/12 01:16
>>66
最低限、STL のコンテナが使えれば OK だと思う。
それが出来たら Modern C++ Design でも読みつつ Loki の内容理解とか。

68:デフォルトの名無しさん
04/01/12 01:17
>67
了解。頑張ります。

69:デフォルトの名無しさん
04/01/12 01:21
.NET自体がおおざっぱに捉えてインタプリタだと思うんだが。

70:デフォルトの名無しさん
04/01/12 01:24
>>69
修行が足りん 出直してこい

71:デフォルトの名無しさん
04/01/12 01:25
>>70
C#とかJAVAって386コード吐けるんですか?

72:デフォルトの名無しさん
04/01/12 01:41
>>71
JIT コンパイルで検索しる。

73:デフォルトの名無しさん
04/01/12 04:25
>>67
テンプレートは
template< typename T >くらいなら分かるけど、
template< int n >とか見てボカーンでした。

あと、
template<class T> class shared_ptr
{
(略)
template<class Y>
explicit shared_ptr(Y * p): px(p), pn(p, checked_deleter<Y>()) // Y must be complete
{
detail::sp_enable_shared_from_this(p, p, pn);
}

も全然理解できません。
template<class Y>って・・・・
shared_ptrってTのポインタを抱えるクラスだと思うけど
どうしてYが出てくるのやら・・・

いい解説ページか本はないでしょうか。

74:デフォルトの名無しさん
04/01/12 04:29
それどころか、Modern C++ Designの表紙をめくったところで

template<int m1, int l1, int t1, int m2, int l2, int t2>
Physical<m1+m2, l1+l2, t1+t2> operator*(Physical<m1,l1,t1> lhs
                     Physical<m2,l2,t2> rhs )
{
  return Physical<m1+m2, l1+l2, t1+t2>::unit*lhs.value()*rhs.value();
}

がいったいなんのことやら、と。

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を処理するのに再帰を使用するとかが
関数型言語っぽいっていう理解はOK?
その他、あれば解説よろしく

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++厨の化けの皮をはがせ!


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

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

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

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
テムプレートってどういうときに使うんでつか?
難しすぎて頭がおかしくなります。
たとえば1から100まで足すプログラムに使いませんよね?

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
それは1から100まで足すプログラムというより、
1から100まで足してある数値を取り出すプログラムでは?


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
リフレクションいいよね。

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

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
а≧○иξ⊃XγΘ△Φ?

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
OL50人

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
>影でこそこそ処理されると気持ち悪い。
高級言語は、多かれ少なかれどこか影でこそこそやってます。
本当にそれが嫌なら、アセンブラで組めw


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
過労死すんなよw

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
てか、俺的イメージだが、
c++からcを省いたようなもんがJAVAって感じだが・・・。
VBで生産性あがるっていっても、簡単なもんだけでしょ?めんどいことになるとできなそうだし。
デルファイはいじったことないなぁ、簡単らしいって話はきくが。
PHPもまだないなぁ。

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


次ページ
最新レス表示
スレッドの検索
類似スレ一覧
話題のニュース
おまかせリスト
▼オプションを表示
暇つぶし2ch

5371日前に更新/241 KB
担当:undef