[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/10 01:13 / Filesize : 241 KB / Number-of Response : 948
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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



1 名前:前々スレ985 mailto:sage [03/12/18 06:52]
理解できないわけないだろ!
デザパタも知らずにC++使いの質を下げるC厨には げんあり

前スレ達
難易度:1 pc2.2ch.net/tech/kako/1058/10586/1058675178.html
難易度:2 1pc2.2ch.net/test/read.cgi/tech/1063323615/

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

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

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

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

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

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

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

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

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



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

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

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

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

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

16 名前:デフォルトの名無しさん mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [03/12/19 00:12]
いいこと言うね〜 禿同だよ

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




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

C#

だ!


22 名前:デフォルトの名無しさん mailto:sage [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 mailto:sage [03/12/19 01:45]
>>24
何で俺にw

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

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



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


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



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

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

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




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

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

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

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

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


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

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

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

できるよ。

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

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

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

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

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


37 名前:Kusakabe Youchien mailto:sage [03/12/19 17:49]
>>36
こわがりすぎー

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

39 名前:デフォルトの名無しさん mailto:釣れますか?('A`) sage [03/12/19 21:05]
メモリーリークってJavaだってたいしてかわらんだろ?
使えるだけ使いまくって足りなくなったらいらない
メモリを開放してるんだから。

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

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

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



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

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

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

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

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

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


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


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


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

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

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



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

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


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

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

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

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

53 名前:デフォルトの名無しさん mailto:sage [04/01/04 01:07]
>>52
ttp://www.amazon.co.jp/exec/obidos/ASIN/0201734842/
試しにこれ読んでみれ。

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

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


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

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

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

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


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



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

60 名前:sage mailto:sage [04/01/06 22:48]
>>59
そんなことはないない




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

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

63 名前:デフォルトの名無しさん mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [04/01/12 00:52]
C# はインタープリタじゃないわけだが。
Java も最近 JIT 方式のものがあったりするし。

揚げ足取りスマソ。

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

67 名前:デフォルトの名無しさん mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [04/01/12 01:41]
>>71
JIT コンパイルで検索しる。

73 名前:デフォルトの名無しさん mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [04/01/12 07:46]
>いい解説ページか本
Modern C++ design しかない!

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

76 名前:デフォルトの名無しさん mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [04/01/13 23:13]
templateをしっかり学習したければHaskellを
覚える事をお勧めする。

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

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

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

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

83 名前:デフォルトの名無しさん mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [04/01/20 04:48]
hp.vector.co.jp/authors/VA000092/jokes/strup.html

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

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

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

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

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



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


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

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

94 名前:デフォルトの名無しさん mailto:sage [04/01/22 17:45]
pc2.2ch.net/test/read.cgi/tech/1070089173/

続きはこちらでどうぞ。

95 名前:73 mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [04/02/09 11:08]
>>96
暴れるのはマ板だけにしとけ知的障害者。

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

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

100 名前:デフォルトの名無しさん mailto:sage [04/02/09 19:50]
>>98
(゚Д゚)

>>99
そうだ



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






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<241KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef