5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

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

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

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
ttp://www.amazon.co.jp/exec/obidos/ASIN/0201734842/
試しにこれ読んでみれ。

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
http://hp.vector.co.jp/authors/VA000092/jokes/strup.html

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
http://pc2.2ch.net/test/read.cgi/tech/1070089173/

続きはこちらでどうぞ。

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
http://page4.auctions.yahoo.co.jp/jp/auction/d47227135

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++以外にもつかえるが・・・。

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

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


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
ほとんどc++しかできないです。
まぁ他の覚えるのはそれほど苦労はしないけど。使わんからすぐ忘れる。


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

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

>2chブラウザもDで作れば無駄にメモリ取らずに済むよ
なんで?

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

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

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無いんだと今知ったのは内緒w

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
今ホットゾヌ2使っているけど、メモリリークひどすぎ。Delphiなんだけどなぁ。
スレをどんどん見ていくとあっという間に500MBほどに未使用メモリが膨れあがる。
正直一番気に入っているので、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

http://www.kmonos.net/alang/d/
より

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
「コンパイラ・スクリプトエンジン」相談室が失速気味なので
良かったら使ってやってください。

ttp://pc5.2ch.net/test/read.cgi/tech/1070089173/

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する時にサイズを
2倍ずつ増やすとか。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++いらないし。

281 :デフォルトの名無しさん:04/06/29 19:19
>>279
多い?そんなに聞かないけど。。
プログラムスタイルの違いに始め戸惑うだけじゃない?

282 :デフォルトの名無しさん:04/06/30 00:13
>>281
現場では意外に多いよ。テンプレートや継承を勉強せずにいきなりソース見るから理解できるわけもないんだけど。

283 :デフォルトの名無しさん:04/06/30 04:34
>>276
そういうのは処理系依存になる事も多いね
#pragma で明示的に指示できる処理系もあるよ
組み込み向けでは、コンパイラメーカーにリクエストだすと機能追加してくれる事もあるし
判り難い標準仕様よりも、そっちに頼っていたりする事が多いです。


284 :276:04/06/30 10:14
>>283
確かに、処理系依存では有るけど・・・。

言語内でそういうのを保証しようとするとstaticなlocal変数とか
利用する羽目になるけど、スレッド安全性とかコストとかの問題も
あるし。main先頭でいちいちリソース初期化等の処理を書くってのも
モジュール性の観点から考えるといまいちな気がするしなぁ。

285 :デフォルトの名無しさん:04/07/02 00:35
>>279
C++よりもCのほうが難しいだろう。
C++なら簡単にできたことがCだといくつかの要素に還元せねばならず、
しかも全部横並びの関数になるため凝集度が低くなってしまう。
あとからメンテするのが大変。
C++を極めた人間のC++ソースと
Cを極めた人間のCのソースなら
前者のほうが分かりすい。

286 :デフォルトの名無しさん:04/07/02 00:39
>>285
ソースの分かりやすさと言語の難しさは違うと思われ。

287 :デフォルトの名無しさん:04/07/02 22:26
>>282
ヴァカみたいにテンプレートや継承使いまくってるタコソースなんか見る気がしないということでは ?

288 :デフォルトの名無しさん:04/07/03 01:27
>>285
C++で本格的にプログラムを書いた事が一度もありませんね?

289 :デフォルトの名無しさん:04/07/03 09:06
>>288
煽っているつもりだろうが、それはむしろ逆だろ、本格的に書けばC++の方がやさしい
C++の言語仕様は厄介だから、ちょこっと書く分には難しい。
変な煽りはヤメレ

290 :デフォルトの名無しさん:04/07/03 23:43
>>289
別に、C++でも、C風に書くこともできる

291 :デフォルトの名無しさん:04/07/04 04:21
おじさんはextern "C" {}のトリコ

292 :デフォルトの名無しさん:04/07/05 02:14
C++の仕様準拠率がもっとも高いコンパイラって、
現時点では何になるのでしょうか?
もしかしたらスレ違いかもしれないけど、
これだけ「難しい言語」だと
仕様に準拠するのも大変そうだなぁということで…。

293 :デフォルトの名無しさん:04/07/05 14:53
準拠度そのものを比較したってのは知らないけど、
Boostのレギュレーションテストは参考になるね。
ttp://boost.sourceforge.net/regression-logs/

294 :デフォルトの名無しさん:04/07/05 18:25
本格論議はよくわかんないけど、std::map なんかがやっぱり便利だから、
よく初心者の勉強用に用いられる「単語の出現頻度を調べよ」みたいな
プログラムは、C の場合より著しく簡単になるよね・・・


295 :デフォルトの名無しさん:04/07/10 14:16
>>282
それはソース云々より設計がタコ
どんな言語で書いてもタコはタコ
まC++はタコさ加減が露呈しやすい言語ではあるが
VBなんかだとみんなタコだからカモフラージュになるしな
タコじゃないほうが浮いて目立って困る

296 :デフォルトの名無しさん:04/07/10 14:20
295=タコじゃないつもりのタコ

297 :デフォルトの名無しさん:04/07/10 16:32
いきなり設計云々が出てくる辺りがとっても蛸。

298 :295:04/07/10 18:48
>>287>>282を間違えたあたりがタコorz

299 :デフォルトの名無しさん:04/08/07 19:46
言語仕様がタコなC++の時代は終わった
これからはtemplateを使う必要がないJavaの時代です

300 :デフォルトの名無しさん:04/08/07 19:50
>>299
ウゼーあげんなボケ 程度の低い釣りは秋田

301 :デフォルトの名無しさん:04/08/08 01:33
>>293
やっぱりboostなんて使えないってことかな。

302 :デフォルトの名無しさん:04/08/08 01:34
>>301 意味がわかりません。

303 :デフォルトの名無しさん:04/08/08 01:45
>>302
移植性が低いってことでは

304 :デフォルトの名無しさん:04/08/08 09:08
boost が使えなくて泪目で boost なんて必要ないんだぁぁぁっ
て事ですな。

305 :デフォルトの名無しさん:04/08/11 03:38
>>299
>templateを使う必要がないJavaの時代です
1.4でがんばってね。

306 :デフォルトの名無しさん:04/08/12 06:24
現場だと継承、テンプレート一切使わないってこと多いな。
テンプレートなんてそんな難しいか?
boostはともかく、STLと簡単なテンプレートぐらいなら誰でも理解できるだろ?
テンプレートが難しいってのは、一部の天才が作った
ジェネリックプログラムとかのこと?

307 :デフォルトの名無しさん:04/08/12 06:55
サイズが10倍になるのでプロの現場では使われません。

308 :デフォルトの名無しさん:04/08/12 07:00
テンプレートが難しいんじゃなくて、テンプレートを使って書かれたコードに、
テンプレートパラメータの名前省略されたものが多かったり
traitsとかpolicyに分解されてコードが細切れの散り散りだったり
その上、#ifdef等で切り刻まれていて全体像を把握しづらいコードが多いというだけのこと。

309 :デフォルトの名無しさん:04/08/12 07:38
そりゃぁセンスのない奴が書けばテンプレートに限らずね。

>>307
仮令10倍であっても作業効率が上がるのであればプロだからこそ使いますが。
#サイズ云々する現場なんて寧ろ限られるって。

310 :デフォルトの名無しさん:04/08/12 17:09
DinkumwareのSTLはセンスの無い奴が書いたのか?

311 :デフォルトの名無しさん:04/08/13 05:03
C++の仕様はセンスの無い奴が書いた


312 :デフォルトの名無しさん:04/08/14 01:18
>>310
コンパイル時のリソース消費を少しでも軽減するためらしい。
あとは、真似防止か。

313 :デフォルトの名無しさん:04/09/03 12:27
Loki を理解するよりも、STL のソースを読むほうが難しいと思う。

314 :デフォルトの名無しさん:04/09/03 13:54
実装によるだろ(ry

315 :デフォルトの名無しさん:04/09/04 23:55
>>313
じゃあ、M$版の奴。

316 :デフォルトの名無しさん:04/09/06 13:52
C++使えると豪語する奴=本当はCしかできない低脳
http://pc5.2ch.net/test/read.cgi/prog/1094445966/

317 :デフォルトの名無しさん:04/09/06 22:56
漏れはC++よりもVBが難しい

318 :デフォルトの名無しさん:04/09/08 11:03
C#やっとけ。嫌ならDやっとけ。嫌なら(ry

319 :Ruby!!:04/09/08 17:09
Ruby!!!!!!!!!!!!!

320 :デフォルトの名無しさん:04/09/08 19:10
C++って使いどころがない。
for_eachとかいつ使うんだこんなの、forの劣化版でしかない。

321 :デフォルトの名無しさん:04/09/08 20:10
例の「ほげ言語のパラドックス」の意味がよくわかるねw

322 :デフォルトの名無しさん:04/09/08 22:51
>>302
inline

323 :デフォルトの名無しさん:04/09/08 23:25
>>320
お前、あれだろ。車を「こんなの地球温暖化の原因になるだろ」って難癖つけて
乗らないだろ。

324 :デフォルトの名無しさん:04/09/08 23:44
車と地球温暖化って?
なに言っての、このボンクラ
どこかで聞きかじったのかしらん?w

325 :デフォルトの名無しさん:04/09/09 00:47
車と地球温暖化の二つの単語から
「聞きかじった」とかいう発想が出てくるのが凄いw

「なに言っての」のあたりといい、かなり必死なようで。
理由はわからんが。げらげら

326 :デフォルトの名無しさん:04/09/09 01:29
↑またまた新手の厨が出現w


327 :デフォルトの名無しさん:04/09/09 01:30
>>325ってきっと、偉そうなこと言っときながら、GUIなPCしか触ったことないんでしょうね。
DOS時代を知らないんだな、こういう香具師。


328 :デフォルトの名無しさん:04/09/09 02:02
悔しいからって二つも書かなくていいぞ、324w

329 :デフォルトの名無しさん:04/09/09 03:01
C++は使いまくりだろ。俺はCの方がよく使うけど。
一番使うとこがないのはRubyとJava。

330 :デフォルトの名無しさん:04/09/09 03:35
言うまでも無いけど、仕事によって使用頻度が違ってくるからなあ。
普通は使わない言語の方が多いだろ。
逆に、まんべんなく使用するとなったら、それ部署たらいまわしにさ(ry

331 :デフォルトの名無しさん:04/09/10 22:07:23
Java言語仕様も包含してC+++ つーのはどう?

えーい、こうなったら、VBやDelphiも許してしまう
てんこもり言語「C+++++」のお出ましだ!



・・・もうマニアしか使えねぇな

332 :デフォルトの名無しさん:04/09/10 22:21:24
class C+++++: public C++, public Java, public VB, public Delphi, protected C#;

333 :デフォルトの名無しさん:04/09/10 22:26:06
最強言語Ruby!!!!!!!!!!!!!!!

334 :デフォルトの名無しさん:04/09/10 22:46:31
class 最強言語: public C+++++, private Ruby;

335 :デフォルトの名無しさん:04/09/11 13:34:55
>>332-334
  (゚Д゚ );;; <スゲェ・・・

336 :デフォルトの名無しさん:04/09/11 13:39:36
private Rubyという言葉に笑った。
言いえて妙

337 :デフォルトの名無しさん:04/09/11 14:07:08
C++って、何でもできるのがいいよね。
ビットフィールドとか共用体をCから引き継いでるから
エンベディッドのきつい環境でも、メモリを節約しつつ
ある程度見やすく書けるし。
メンバ関数ポインタを配列に突っ込んだりやりたい放題。

一人で組むんなら最高の言語だよ。

338 :デフォルトの名無しさん:04/09/11 15:32:40
>>337
>一人で組むんなら
人数が何か関係してるのか?

339 :デフォルトの名無しさん:04/09/11 19:22:16
>>338
多人数で組むなら、あんまりトリッキーなコードは書けないじゃん。
それならJavaでも大差ない。

340 :デフォルトの名無しさん:04/09/12 00:43:44
俺、最近<boost/preprocessor.hpp>の利用による繰り返し処理を勉強中何だけど
もしかして、これって、perlなどの言語でちょちょいと書いて、出力して、コピペ
したほが可読性の面からもいいんじゃないかと気づいてしまったんだけど
まだまだ理解が足りないというかとなのかな。

341 :デフォルトの名無しさん:04/09/12 01:32:06
C++ってそんなに難しいか?
STLが超便利でCなんてやってらんない体になってしまった

342 :デフォルトの名無しさん:04/09/12 02:08:55
>>341
幸せな時期だね。

343 :デフォルトの名無しさん:04/09/12 05:17:05
286上のQuick C、MASMの時代からC、C++一筋で趣味、仕事でやってきて
他の言語はいらないとまじめに思ってたんだが・・・最近、C#をCつながりで
やってみるかと覗いてみたら・・・もうC++の時代は終わりかもしれんな。
C++を身につけた人間があえて乗り換える必要はないが、新人にC++を教えたり
薦めたりする気はなくなったよ。これからやる人はC#やった方が良いな。
.NET→WinFXと進んでいこうとするならなおさらだな。

344 :デフォルトの名無しさん:04/09/12 05:55:31
http://www.square-enix.co.jp/shop/goods/images/series_cre4_06.gif
小さすぎて見えんがな('Д`)

112 名前:名前が無い@ただの名無しのようだ :04/09/09 21:07 ID:s4msPAUO
http://www.ffcompendium.com/EspMon/necron9-b.jpg
http://www.ffcompendium.com/EspMon/necron9-a.jpg

345 :デフォルトの名無しさん:04/09/12 17:33:17
>>343
C#は絶対にC++は超えらんないと思うよ
C#って実質Windowsでしかつかえねーじゃん
WindowsでもDLL内の関数なりクラスを使うとなると
面倒だし・・・
挙げだすと枚挙に暇がない
WindowsではVC++&MFCこれ最強
ま ち が い な い!

346 :デフォルトの名無しさん:04/09/12 18:51:02
オトトイ、キ・ヤ・ガ・レ!

347 :デフォルトの名無しさん:04/09/12 19:26:19
Windows + C言語のみでMFCも使わずWin32APIネイティブ。
自分でWinProcからMSGをディスパッチしる! <これ最強。

348 :デフォルトの名無しさん:04/09/12 20:10:59
>>345
> C#は絶対にC++は超えらんないと思うよ

それはそうなんだ、言語の汎用性という意味からするとあなたの言ってる事は
非常に正しいんだ。

> C#って実質Windowsでしかつかえねーじゃん

これもまさしくそうなんだ。

でも、仕事って、まぁ俺の場合はそうなんだけど、9割方Win絡みなんだよね。
でもって、次の世代のWindowsが06年に出るかどうかは別として何時か、近い
将来は必ず出るんだよね。で、そのWindowsからはWin32Apiはネイティブじゃなくて
WinFXでエミュレートされるんだよね。となると、これから始める人があえてwin32api
に精通する必要はなくなるんだよなぁ。むしろ、今は.NETのクラスライブラリの使い方
に精通した方が良いと言える。

> WindowsではVC++&MFCこれ最強
> ま ち が い な い!

現行ではね。Win32Apiがその存在意義を失うであろう、ここ2〜3年の間わって話し
だよな。OSのネイティブAPIがWinFXのクラスライブラリになれば話しはがらっと変わるよ。

まぁ、ハードに近い分野をMSがどうやってクラスライブラリにのっけてくるか、お手並み
拝見だけど、.NETの最適化も1.1→2.0βで大幅に進んでるからね。画像処理のコードを
1.1と2.0βで同じようにコンパイルしたら5倍ほど速度アップしてた。1.1上で約16秒
要してた処理がコンパイルし直すだけで3秒程で終わるようになってたからね。

ただ、間口を広げるという観点からは他のプラットフォームでも使えるC&C++を知っとく
ってのは悪くないとは思うけどね。

349 :デフォルトの名無しさん:04/09/12 21:27:02
じゃあ、その画像処理処理コードをC++で書き直してみたら?
C#がC++を凌げない答えがそこにあるから。

350 :デフォルトの名無しさん:04/09/12 21:27:08
>>348
> まぁ、ハードに近い分野をMSがどうやってクラスライブラリにのっけてくるか、お手並み
> 拝見だけど、.NETの最適化も1.1→2.0βで大幅に進んでるからね。画像処理のコードを
> 1.1と2.0βで同じようにコンパイルしたら5倍ほど速度アップしてた。1.1上で約16秒
> 要してた処理がコンパイルし直すだけで3秒程で終わるようになってたからね。

ま、まじっすかそれ?

351 :デフォルトの名無しさん:04/09/12 21:52:58
>>349
やりましたよ。C++だと.3秒で終わりました。テスト用に作ってる
画像処理用ライブラリなんですけどね。巨大なサイズのビットマップを
読み込んでフィルタ処理するって奴です。
現行だとC++の方が10倍程速いですね。しかしですね、ここが大きな問題
なんですが、C#でもbitmapクラスを使わずにそのままメモリに展開して
ポインタ使ってアクセスすると.4秒程度で終わってしまうんですね。ファイル
読み込みにはもちろん.NETのクラスライブラリを使用してます。
個人的にはC#でunsafeなコードを書くのは邪道だとは思うんですが、やろうと
思えば問題ないって話ですね。dll呼び出しするほど手間でもないですし。
インラインアセンブラ使うような感じですね。となると話しはややこしくなってきます。
C#に対するC++の現行での利点は、
・ポインタを駆使出来る。
・win32apiへのアクセスが容易である。
・ネイティブコードを吐ける。
とまぁ既存のライブラリ資産の問題を抜きにすればこんなところです。後ろの2つは
ここ2〜3年で利点でもなんでもなくなってしまう訳です。で、1つ目に関してもボトル
ネックとなるような肝い部分ではC#でも問題なく使用出来る、となればほとんど差は
なくなってしまうんですね。やはり考え込んでしまいますね。ただ、プロジェクトの規模
が非常に大きくなってきた時のGCの挙動というのがどの程度パフォーマンスに影響を
与えるのか現時点では読めません。コードでの工夫のしようはありますが、最終的には
VM任せですから。まぁこのあたりもMSが最適化していくような気はしますが。
一つはっきりしときたいのは私はC++を否定するつもりは毛頭ありません。ただ、スレタイ
にもあるとおり「C++は難しすぎ」と感じる人がいるのだとすれば無理して今から覚える
必要は、Win上での開発を念頭に置いているのなら、ないんじゃないかなと思っただけです。

>>350
ほんとです。ソースはそのままコンパイルやり直しただけでその程度のパフォーマンスの
向上が見られました。βがとれた時はそれなりに期待しても良いのかなという気にはなり
ましたね。

352 :デフォルトの名無しさん:04/09/12 22:14:50
俺はc#がVBSのような運命を辿るような気がして成らないんだけど・・・

353 :デフォルトの名無しさん:04/09/12 23:16:22
> C#に対するC++の現行での利点は、
> ・ポインタを駆使出来る。
> ・win32apiへのアクセスが容易である。
> ・ネイティブコードを吐ける。

C#はどれもできるぞう。
ところで、最初のはあんまりうれしくないなあ。

354 :デフォルトの名無しさん:04/09/12 23:23:24
Ruby最強言語
Ruby!!!!!
Ruby >>>>>>>>>>>>>>>>>>>>>>>>>>> Cω

355 :デフォルトの名無しさん:04/09/12 23:59:55
>>353
脊髄反射?

ポインタ使える事は >>351 も知ってるようだぞ?
ポインタは確かにアレなんだけど、本流になるには絶対必要だと思うね・・・残念ながら。

Native 呼び出しはモノによっては結構面倒。単にアクセスの容易さだけなら C++ のが当然上だよ。
確かに普通の Win32 API はそれほど面倒なのに突き当たった事はないけど、
COM だとラッパー作るのが大変なの多いね。TLB とか無い場合は。
もちろん JNI みたいなのよりは全然マシだけど。

それから、C# で直接ネイティブコードは吐けないんじゃない?
インストールしたマシン上で変換はできるけど。

356 :デフォルトの名無しさん:04/09/13 00:10:56
まぁ何にせよ楽なのはC#だわな。
別に両方使えれば問題ないさね。適材適所。

357 :デフォルトの名無しさん:04/09/13 01:36:37
>>355
本流ってよくわからんが、洗練されたC++コードにはポインタは登場しないよ。
ポインタが飛び交うなら、それはC++の顔をしたCだと思う。

358 :デフォルトの名無しさん:04/09/13 01:38:54
っつうか355みたいなのは若い(よね?)ならいいけど
年くってたらヤバいと思いなされ。

359 :デフォルトの名無しさん:04/09/13 01:47:40
>>358
何か言いたいならはっきり言えよ

360 :デフォルトの名無しさん:04/09/13 02:06:50
>>357
それはおまいがC++が書けないからだよ w

361 :デフォルトの名無しさん:04/09/13 02:13:48
>>357

すまん。自分はポインタつかいまくり。
スタックに積むオブジェクトとヒープに確保する
オブジェクトは明確に区別している。

それでヒープに確保するためのオブジェクトはどうしても
ポインタになる。スマートポインタはつかっているけど
生のポインタのほうが適切だと思う場所もあるので
それで生のポインタをつかっている。


362 :デフォルトの名無しさん:04/09/13 09:04:59
>>361
> 生のポインタのほうが適切だと思う場所もあるので

そういう場所がほとんどなくなるのが、最近のC++のやりかただと思うのよ。

特殊な例を特長なんかにしないほうがいいよ。

363 :デフォルトの名無しさん:04/09/13 14:18:22
>>362
どうやって?

364 :361:04/09/13 16:54:41
自分の場合、ヒープに確保するタイプのインスタンスは
以下のような管理の使い分けをしている。
(依存、関連、集約、コンポジションぐらいは理解しているよね)

[依存]

ケース1 :
あるメソッドローカルでつかわれるインスタンスで
メソッドをぬけるとインスタンスが不要になる場合。
auto_ptrかscoped_ptrをつかう。

ケース2 :
あるメソッドの引数として渡されるインスタンス。
渡されたインスタンスはそのメソッドの中でしかつかわれない。
この場合は生ポインタ。理由はインスタンスの寿命にメソッドは
関知しないためスマートポインタにする意味がない。

[単項関連]

ケース1 :
格納するクラスがインスタンスの寿命の管理をしないといけない場合。
この場合はauto_ptrかscoped_ptrかshared_ptr。

ケース2 :
格納するクラスがインスタンスの寿命に関知しない場合。
この場合は生ポインタかweak_ptr。


365 :361:04/09/13 16:55:34
[集約]
基本的な方針は単項関連と同じ。集約のコンテナにはSTLコンテナ
をつかい、スマートポインタをつかう場合にはshared_ptr
(これじゃないとコンテナに格納できないから)をつかう。

[コンポジション]
問答無用にSTLコンテナ+shared_ptr。

こんな感じ。依存のケース2のような場合はスマートポインタを
つかう意味がないし、別に特別なケースでもなくてよくあるんだけど。


366 :デフォルトの名無しさん:04/09/13 17:01:42
洗練されたC++の流儀とは、boostを使う事だったようです。
最近使えるようになったんでしょうね、うれしくてたまらないみたいです。

367 :デフォルトの名無しさん:04/09/13 17:08:53
↑Boost分かってない香具師の僻みキタ━━━━━(゚∀゚)━━━━━!!

368 :デフォルトの名無しさん:04/09/13 17:17:20
標準がしょぼいせいでいろんなもんが乱立する事態になってる

369 :デフォルトの名無しさん:04/09/13 17:23:25
なんたらptrとかほにゃららptrとか確かにウザィよね。
ライブラリレベルでやるもんじゃねえよ。

370 :デフォルトの名無しさん:04/09/13 17:29:55
>>367
と言う事にしたいのですね。

自分の場合とか言いながら、長々と何を言うかと期待すれば
boost入門ページの最初の方に書いてある事を書いてみただけ。
ヤレヤレ

そんな事はboostの名前を知ってるような人間は誰でも(活用しているかはともかく)承知している事で、
それでもあえて生ポインタを使っているケースは多々あるのに、それを否定するだけの説得力(代案)が
先の文章には無い。

371 :デフォルトの名無しさん:04/09/13 17:37:11
とりあえず否定だけしてみて自分の意見は無い香具師キタ━━━━━(゚∀゚)━━━━━!!

372 :361:04/09/13 17:44:29
だからスマートポインタ最大限に利用したとしても
生ポインタをつかうケースがあるって例をあげてみた
んだけど。

>そんな事はboostの名前を知ってるような人間は誰でも
>(活用しているかはともかく)承知している事で、
>それでもあえて生ポインタを使っているケースは多々あるのに、
>それを否定するだけの説得力(代案)が先の文章には無い。
361の発言みれって。自分も生ポインタつかいまくりだって。


373 :デフォルトの名無しさん:04/09/13 18:01:12
>>372
使いまくったらダメだろw

374 :デフォルトの名無しさん:04/09/14 00:56:19
>>364
依存のケース2で生ポインタ使ってるところは参照が適切だと思うが、いかがか?

375 :デフォルトの名無しさん:04/09/14 00:58:55
話の途中で悪いが、今の「ポインタを使いまくる」の意味は、
自力でnew/deleteしまくるって意味だよな?

376 :デフォルトの名無しさん:04/09/14 00:59:47
>>375 ちがうだろう。

377 :デフォルトの名無しさん:04/09/14 00:59:58
void******** (********a)(void******** (********)(void********));
なんて普通に使ってますが、何か?

378 :361:04/09/14 01:19:12
>>374
ヒープに確保するオブジェクト限定の話なので、生ポインタです。
個人的にヒープに確保したインスタンスの参照をとるのは
抵抗があるかな。

たしかにスタックに積むオブジェクトや構造体ならむしろ参照の
ほうが望ましいと思います。


379 :デフォルトの名無しさん:04/09/14 01:49:54
>>378
その抵抗には何か根拠がある?
まるで意味の無い区別だと思うが。

ヒープ上の(動的)オブジェクトを引数に取る関数と
スタック上の(自動)オブジェクトを引数に取る関数とで
オーバーロードでもするつもりか?

380 :デフォルトの名無しさん:04/09/14 02:44:40
いつのまにかスレタイに沿った話題になってる

381 :デフォルトの名無しさん:04/09/14 02:47:18
>>375
「生の」な。

生のポインタを渡したり、受け取ったり、コピーしたり、
インクリメントしたり、引き算したり、足し算したりすることかなあ。
そういうCみたいなコードはさすがにメンテするのも疲れる。

382 :デフォルトの名無しさん:04/09/14 02:48:46
それはおまいが`使えない'香具師だからだYo

383 :デフォルトの名無しさん:04/09/14 02:50:29
む、「Cみたいな」は禁句か?

384 :デフォルトの名無しさん:04/09/14 04:32:03
>>382
話についていけないお馬鹿さんが
無視して書き込まなくてもいいのでは? ;-)

385 :デフォルトの名無しさん:04/09/14 05:22:30
無視して書き込む? ;-)

386 :デフォルトの名無しさん:04/09/14 07:03:25
つーかね、
システムコールがiteratorに移行しない以上、
ポインタ(アドレス渡し)は永遠に不滅です。

387 :デフォルトの名無しさん:04/09/14 09:05:47
システムコールなんてwrapされる最たるもんだろ

主パスの処理にシステムコールが出てきたりするなら、C以前だなそりゃ

388 :361:04/09/14 09:53:58
>>379

設計の段階でヒープに確保するオブジェクトとスタックに積む
オブジェクトは「明確に区別している」ので、同じクラスの
インスタンスがヒープに確保されたりスタック積んだりとまちまちに
なることはないので、オーバーロードする必要はない。
クラスによってヒープに確保かスタックに積むかが決定している。

ヒープに確保するオブジェクトの例をあげればポリフォーリズムが
必要なクラス、スタックに積むクラスは通貨型やベクトル型、
複素数型、クォーターニオンなど。

C++ではオブジェクトをヒープで確保することを強制できないので
とりあえずコピーコンストラクタや代入演算子をprivate属性に
するぐらいはやっているが、最終的にはドキュメントに書いている。

Compositeパターンのように子ノードの削除の責任が親ノードにある
場合、delete演算子かスマートポインタで破棄するんですが、
これがスタックにつまれていると親ノードの都合で削除できない
ので問題になる。こういうのは仕様できっちりきめるしか
回避方法がないのはC++の欠点だと思っている。

...というか、こういうガイドラインって一般的ではないのかな。
とりあえずつかいわけとしてはC#の値型と参照型に近い
感じなんですが。


389 :デフォルトの名無しさん:04/09/14 10:15:27
>>388
> 設計の段階でヒープに確保するオブジェクトとスタックに積む
> オブジェクトは「明確に区別している」ので、同じクラスの

クラスを使う側のローカルな操作なら自分の決定を前提とできるだろうけど、
クラスや関連関数を提供する側では、どちらに確保されるかと言う前提は持てないだろう。

> ヒープに確保するオブジェクトの例をあげればポリフォーリズムが

"polymorphism" な。

> C++ではオブジェクトをヒープで確保することを強制できないので

コンストラクタを protected にして、ヒープに確保するstaticな
生成関数を用意すればできるよ。

> これがスタックにつまれていると親ノードの都合で削除できない
> ので問題になる。こういうのは仕様できっちりきめるしか
> 回避方法がないのはC++の欠点だと思っている。

他の言語なら仕様でキッチリ決めないで回避できるの?

> ...というか、こういうガイドラインって一般的ではないのかな。
> とりあえずつかいわけとしてはC#の値型と参照型に近い

C#は詳しくないけど、それを表したいなら、
 C#:値型 → C++:メンバを並べたクラス型
 C#:参照型 → C++:実装へのスマートポインタひとつをメンバに持つクラス型
こんな感じの対応付けにならないか?

390 :361:04/09/14 10:40:07
>"polymorphism" な。
すんまそん。typoです。マジで恥ずかしい。

>コンストラクタを protected にして、ヒープに確保するstaticな
>生成関数を用意すればできるよ。
そういえばそうだった。忘れていました。

C#だと構造体は必ずスタックにつまれる(ボキシングするとヒープに
移るけど)し、クラスはヒープに確保される。まあC#の場合はも
ともとGCがあるからインスタンスの破棄のことは考えなくていいんだけど。


391 :361:04/09/14 11:13:37
>C#:参照型 → C++:実装へのスマートポインタひとつをメンバに持つクラス型
これって俗にいうHandle-Bodyだよね。これも設計ポリシーによってはアリですね。
昔の(今は知らん)xerces-cもそうだったような覚えがある。


392 :デフォルトの名無しさん:04/09/14 14:17:40
横槍ですが...

>>388
>Compositeパターンのように子ノードの削除の責任が親ノードに
>ある場合
むしろ私の場合は、Compositeパターンによる関連性と寿命管理を
分離する設計が殆どです。Compositeパターンにより関連付けられた
オブジェクト群を利用するオブジェクトと同じ寿命を持った
オブジェクトを用意し、それに保持させるって感じです。

そういった意味では、ライブラリがクライアントの用意するオブジェクト
の寿命を管理する設計よりも、ライブラリはあくまでもそのオブジェクト間の
関連性だけを利用するようにし、その関連性の利用期間を外部に通知できる
ようなインターフェースを用意します。オブジェクトの寿命が本質的に
あいまいな場合のみshared_ptrを使いますが、稀なような気がします。


393 :361:04/09/14 14:48:48
>むしろ私の場合は、Compositeパターンによる関連性と寿命管理を
>分離する設計が殆どです。Compositeパターンにより関連付けられた
>オブジェクト群を利用するオブジェクトと同じ寿命を持った
>オブジェクトを用意し、それに保持させるって感じです
イメージとしてはFlyweightのようなオブジェクトプールを
つかうって感じでしょうか?ちがったらすみません。
一応、GoFの本を確認したところ「component を削除するのは誰か」
という段落で「通常は親ノードが子ノードを削除するのが最もよい」
とは書いてありますが、そうでなければいけないとは書いてないですし、
例外のケースもあげられています。

>あいまいな場合のみshared_ptrを使いますが、稀なような気がします。
個人的にもshared_ptrをガーベージコレクションのかわりに
つかうことは殆どないです。thisポインタ問題(shred_ptrの
thisポインタはスマートポインタで管理されていない。
一応回避策はありますが)や循環参照でメモリリークが
発生したりするので意外とつかいにくいです。むしろ
コンテナに入れることができる唯一のスマートポインタ
というつかいかたが多いです。

クライアントが生成したインスタンスをライブラリ側で
寿命を管理する必要があるかどうかは議論の余地がありますね。


394 :デフォルトの名無しさん:04/09/14 14:49:56
とりあえず、俺に責任は無い。

395 :デフォルトの名無しさん:04/09/14 23:50:16
C++でポリモーフィズムを使う時って、ヒープに実態確保して、ポインタ使うしかないの?

396 :デフォルトの名無しさん:04/09/14 23:56:41
スタックに確保して参照を使うのもアリです。

397 :デフォルトの名無しさん:04/09/15 01:24:57
で、361よ。
> 個人的にヒープに確保したインスタンスの参照をとるのは
> 抵抗があるかな。
これは具体的な根拠があるわけじゃない、ってこと?

398 :361:04/09/15 12:58:23
ヒープに確保したインスタンスを参照にすると削除するときに&演算子で
ポインタに戻してやらないといけないのと、スマートポインタをつかう
ことも多いので、参照をつかっているところとスマートポインタを
つかっているところで表記がまちまちになって好きじゃない。
一貫性のある表記が好きという個人的な好みの問題。でも本当に
わざわざヒープに確保したインスタンスを参照にする人って
いるの?

ポリモーフィズムは別にスタックに確保したオブジェクトでも
できるけど、スタックに確保しちゃうとインスタンスの寿命の
管理の自由度が下がる。それにスタックに確保しちゃうと
Factoryメソッドのようなメソッド内部で生成したインスタンス
をメソッドの外部に提供するときにコピーコンストラクタが
必要になるのでそういうときに困る。例えばオブジェクトが
ビットマップのような巨大なデータをもつ場合、コピーコン
ストラクトのコストは大きいし、コピーコンストラクタを
書くのが難しいオブジェクトもある。なので必要のない
コピーコンストラクタはprivateにして使用禁止にして
つかわないようにしている。巨大なデータを持つオブジェクトは
前にもいった人がいるようにHandle-Bodyなんかでもいい
(実際にHandle-Bodyをつかっていたり、文字列クラスなんかは
CopyOnWriteをつかっている実装も多い)が、自分はHandle-Bodyを
つかうスタイルではない。これもスタイルの問題。


399 :デフォルトの名無しさん:04/09/15 13:42:11
>>398
どこを縦読みすればいいのですか?

400 :デフォルトの名無しさん:04/09/15 14:16:46
ポリフォーリズムをポリホと略すスレはここです

401 :デフォルトの名無しさん:04/09/15 17:20:36
|  ポリフォーリズム の検索結果のうち 日本語のページ 約 7 件中 1 - 3 件目 (0.54 秒)

あるからびっくりだ。

402 :デフォルトの名無しさん:04/09/15 19:32:31
全部同一人物?

403 :初期不良:04/09/15 21:23:16
>>400
モーフィングとフォーミングを勘違いするなら分かるけど
フォーリングと勘違いするというのは飛んでるなと思う。
3カウント入れちゃうよ

404 :361=別名ポリホ:04/09/15 21:35:53
だからマジtypoだって...。まだいりじるのか...。
本気で恥ずかしいんだからいじめんなよ。



405 :361=別名ポリホ:04/09/15 21:36:44
>>いりじる
いじるの間違いだ。またtypo。もう嫌...。

406 :デフォルトの名無しさん:04/09/15 21:38:17
ていうか、ポリフォーリズムをモリモーフィズムと間違えるのって恥ずかしすぎ。

407 :デフォルトの名無しさん:04/09/15 22:06:55
イリジウムのことね

408 :デフォルトの名無しさん:04/09/15 22:12:54
はずかしすぎ。
アンテナでかすぎ。

409 :デフォルトの名無しさん:04/09/15 22:24:30
どうtypoったらそうなるのか分からん

410 :デフォルトの名無しさん:04/09/15 22:47:57
typoだけに突っ込んでいる人は、
そうやって話をはぐらかそうとしている
厨房なので無視するべし。

411 :374:04/09/16 00:56:53
>>394
なんか、どちらかに誤解があるようだな。
>>364の [依存]ケース2 で言っていることは、
たとえば「あるメソッド」foo について、
 foo(T*);
というふうに引数の型として生ポインタを使うということじゃないの?
それに対して、
 foo(T&);
のほうが適切ではないかと言う突っ込みを>>374で入れている。
これは引数の型の話で、確保したインスタンスを
保持するための型は関係ないと思うんだけど、
漏れが>>364を誤読しているの?

412 :374:04/09/16 00:58:09
レスアンカー間違えた。
>>411>>398 宛てね。

413 :361=別名ポリホ:04/09/16 08:34:22
>>414

何度も同じようなことを書いてすまんけど、
1.クラス設計時にヒープかスタックか決めている
2.ヒープに確保するオブジェクトは常に(スマートポインタを含めた)
ポインタとしてつかいたい
3.参照をつかわないのは参照とポインタが混ざって表記の揺れに
なるからという好みの問題
別に参照をつかっちゃまずいっていう決定的な理由はない。
設計ポリシーとしてメソッドの引数は一貫して参照をつかうの
であればそれはそれでいいんじゃないでしょうか?っていうか俺が
文句いうことじゃないけど。

逆にちょっと質問。setterのようなあるインスタンスを引数の値とって
それをインスタンス変数に保持するメソッドで、かつ削除の権限が
そのsetterを持つインスタンスにある場合、これも参照で渡すの?
そうだとするとどこかの段階で参照からポインタに変換しないと
削除できないような気がするんですが。それともこの場合は
特別にポインタで渡すんでしょうか?


414 :361=別名ポリホ:04/09/16 08:38:54
すまんレスの先が411だった。

質問の意図は指摘しているところで参照をつかうと、
setterうんぬんのケースと一貫性を保とうとすると
無理がある場所がでるんじゃないかってことです。



415 :374:04/09/17 09:34:20
>>413
最初に突っ込みいれた箇所(>>364の[依存]ケース2)では
「渡されたインスタンスはそのメソッドの中でしかつかわれない」状況となっている。
「インスタンス変数に保持するメソッド」なら状況が違うんじゃないの?
これらの異なる二つの状況の間で一貫性なんてあるはずがない。

生ポインタ使う場所の例として挙げられた箇所に
参照のほうが適切だと突っ込みいれたのに、
スマートポインタ使う場所を挙げて反論されても困る。

416 :デフォルトの名無しさん:04/09/17 12:25:53
> 削除の権限が そのsetterを持つインスタンスにある場合
どういう状況だかよく分からんが、std::auto_ptrみたいなものを
作ろうとしてるなら、素直にコピーを作成したオブジェクトが責任を持って
オブジェクトを破壊すべきだ。
参照渡しされたものを受け取った側で破壊するのは、分かりづらい。

とりあえずスマートポインタ勉強してから出直せ。


417 :デフォルトの名無しさん:04/09/17 12:56:51
漏れはリアルタイム画像処理をよくやるんだけど、
画像のピクセルデータにアクセスするときはなんとなく生ポインタ使っちゃうな。

あったり無かったりするものを引数にしたいとき、T* 型の引数にして 0 渡すと
「無し」みたいなこともたまにやるし。C# や Java のライブラリでも null 渡せる
メソッドは結構あるから、実装面ではポインタ型の使いどころはそこそこあるん
じゃねーの?

418 :デフォルトの名無しさん:04/09/17 15:26:19
まあ、あれだ

参照渡しでもポインタ渡しでもコピー渡しでもなんでもいいけど、
参照剥しをするのは控えた方がいいな。

あとでdeleteするオブジェクトはポインタで保持しとけ。


419 :ポリホ:04/09/17 17:46:25
>参照渡しされたものを受け取った側で破壊するのは、分かりづらい。
からポインタつかえっていってんだろ。

>「渡されたインスタンスはそのメソッドの中でしかつかわれない」状況となっている。
>「インスタンス変数に保持するメソッド」なら状況が違うんじゃないの?
>これらの異なる二つの状況の間で一貫性なんてあるはずがない。
状況が違うから一貫性がなくてもよいという判断なら別にいい。
自分はポインタにすると2つの状況で整合がとれるから好きなだけだ。

メソッドの引数はポインタうんぬんという話はヒープに確保した
インスタンスに限定の話だ。しかもコーディングスタイルの問題
だから人のことはとやかくいうつもりはない。

ヒープに確保したインスタンスの参照剥がしが好きじゃないといったら
根拠を求められるし、好きじゃない理由をいったらなぜか参照剥がしは
わかりずらいっていう謎のつっこみが入るし、わけがわかりません。

いったい自分にどうしてもらいたいんだろう。


420 :デフォルトの名無しさん:04/09/17 20:42:41
>>411
foo を書いていて引数にnull 値のようなものを許したいとき、
foo(T*) にするか、foo(T&) にして T::Null を提供するかっていうと、
漏れはメンドクサイから大抵前者だけど。


421 :デフォルトの名無しさん:04/09/17 21:28:32
>ポリホ
もうちっと日本語勉強しろよ

422 :デフォルトの名無しさん:04/09/18 11:32:18
>>419
>いったい自分にどうしてもらいたいんだろう。
いじられ役に徹してくだちい。

423 :デフォルトの名無しさん:04/09/23 02:34:10
とりあえずC++ではヒープではなく「フリーストア」って呼ぶんじゃなかったっけ?
まぁ、データメンバを「メンバ変数って呼んじゃダメなの?」くらいの勢いだけど。

424 :デフォルトの名無しさん:04/09/23 22:05:22
int* a,b; と int* a; int* b; って違うんだな・・・

425 :デフォルトの名無しさん:04/09/24 00:10:23
>>424

いや、それは違いすぎだから…。
両方ポインタにするなら

int* a, *b;

じゃないとね。
だけどこういう書き方になるから型の後にアスタを付けるスタイルは好きではない。

int *a, *b;

のほうが美しいじゃん。好みの問題かもしれないけど。

426 :デフォルトの名無しさん:04/09/24 00:14:44
>>424
所詮C++はC言語のころの呪縛から逃れられてないのよ。

>>425
int* a;
int* b;
と2行に分けることを推奨。

427 :デフォルトの名無しさん:04/09/24 04:48:24
>>426
>所詮C++はC言語のころの呪縛から逃れられてないのよ。

だがそれが(・∀・)イイ!!
というか、仕様変更するとコンパイルエラーが発生するレガシーコードが
混在してしまう可能性があるから仕方ないっしょ。








・・・レガシーという単語を使いたかっただけだ。気にしないでくれ。orz

428 :デフォルトの名無しさん:04/09/24 08:39:01
int* をtypedefして違う名前を与える
さらにはintを変えられるようにtemplate化

429 :デフォルトの名無しさん:04/09/24 09:23:41
C言語の型とは何か。

typedef int *iptr;
int *は ptr->int
iptrも ptr->int
int *[]はarray->ptr->int
int (*)();はptr->function as int
int *();はfunction as ptr->int
struct { int a,b;} *;はptr->struct{int a;int b;}


構造が同じなら互換性があると言う。

iptr a;
int *b;
a = b; // ok

しかし
struct { int x,y;} a;
struct { int x,y;} b;
b = a; // error '=' : 互換性のない型が含まれています。


これはいったい、どうしたことか。

430 :デフォルトの名無しさん:04/09/24 10:25:14
>>429
b=a;

b.x=a.x;
b.y=a.y;
と同義であるとはいえない。
直感的にはそうであるが。
同義であるなら同義であるとoperator=なりで
コンパイラに教えなきゃわからん。


431 :デフォルトの名無しさん:04/09/24 10:43:24
>>429
struct A { int x,y;} a;
struct B { int x,y;} b;

名前を省略しただけの扱いなんだろ。
別々の構造体で、たまたまメンバの並びが同じになっただけで代入ができたら困る。

432 :デフォルトの名無しさん:04/09/24 11:45:46
C++スレでC虫臭い話を続けるな

433 :デフォルトの名無しさん:04/09/24 17:58:58
>>424-425
こんな解決法もある。
typedef int *PINT;
PINT a, b;


434 :デフォルトの名無しさん:04/09/24 18:03:42
それ終わってる。
とっくに。

435 :デフォルトの名無しさん:04/10/07 00:13:22
>>429
基本的に別の型に代入はできない。当たり前だけど。Java だって C# だってそうでしょ。
typedef は単なる別名で、新しい型を作る訳では無いって、仕様で決まってますから。

436 :デフォルトの名無しさん:04/10/26 17:24:17
メンバの並びが同じな別々の構造体を作る必要性はあるのか?

437 :デフォルトの名無しさん:04/10/26 18:09:29
あたりまえ

438 :デフォルトの名無しさん:04/10/26 19:18:18
>>436
「今はたまたま同じメンバだけど、将来的には拡張されるかも知れない」
ってことはありそう泣きガス

439 :デフォルトの名無しさん:04/10/26 19:56:30
>>438
その場合、直接代入できる必然性はないよね。

440 :デフォルトの名無しさん:04/10/27 11:48:39
>>439
ふむ。そりゃそうだ。

441 :デフォルトの名無しさん:04/10/29 01:42:08
ふと思ったんだけど、構造体やクラスの(データ)メンバを
while文のようなループ文でくるくる回しながら順番に取れたら便利かも?
名前とか個数とかデータ型を意識せずにクルクル…。
そういうのってうまいこと出来ないかな?

442 :デフォルトの名無しさん:04/10/29 01:46:03
>>441
意味が判らない

443 :デフォルトの名無しさん:04/10/29 01:53:58
>>441
型の違うデータメンバのいったい何が取得したいのか? ってことだね。
たとえば各メンバの文字列表現が取得したいのなら
そのような関数を用意すればすむ。

444 :デフォルトの名無しさん:04/10/30 03:34:49
うっ、わかりにくかったか…。orz 例えば擬似的なコードを書いてしまうと…。

struct TEST_STRUCT
{
 int mInt;
 long mLong;
 char mChar[255 + 1];
};

void main()
{
 vector<VARIANTのような型> dstArray;
     ^^^^^^^^^^^^^^^^^^^^^
 TEST_STRUCT srcData; //適当に初期化済みの状態とする
 int i = 0;
 while( 1 )
 {
  dstArray.push_back( srcData.○[ i ] );
  i++;                ^^^^^^
 }
}

こんな感じで、データメンバを「名前ではない方法」でアクセスできれば、
結構便利な使い方ができそうだなぁと思ったのでつ。
「○[ i ]」の部分って必ずデータメンバの名前で指定しなければならないから…。

dstArray.push_back( srcData.mInt );
dstArray.push_back( srcData.mLong );

…のように一つ一つ全部指定しなきゃいけないし、型に「VARIANTのような型」が無い以上、
そういうやり方すら出来ないではないでつか…。
関数にしても結局はすべて名前で指定しなければならないし…。

445 :444:04/10/30 03:37:25
>>444

しまった、ループの脱出条件を書いてないから無限ループケテ〜イだ…。orz
まぁ、その辺は突っ込み入れないでちょ。

446 :r:04/10/30 08:20:36
>>444
offsetof

使った事無いけど。多分。

447 :r:04/10/30 08:25:36
>>444
つーか

TEST_STRUCT srcData[] = ...;

for( int i = 0; i < ...; i++ )
    dstArray.push_back( srcData[i] );

じゃなくて?



448 :デフォルトの名無しさん:04/10/30 09:57:07
>>444
実体でなくポインタを維持すればいいなら、
std::vector<void *>dstArray;
dstArray.push_back(reinterpret_cast<void *>(&srcData.mInt));
dstArray.push_back(reinterpret_cast<void *>(&srcData.mLong));
dstArray.push_back(reinterpret_cast<void *>(srcData.mChr));
構造体のメンバの列挙は誰かがやらないといけないからねぇ。
static const unsigned sOffsets[] = {
offsetof(TEST_STRUCT, mInt),
offsetof(TEST_STRUCT, mLong),
offsetof(TEST_STRUCT, mChr),
};
for (unsigned i = 0; i < sizeof(sOffsets) / sizeof(*sOffsets); ++i) {
dstArray.push_back(reinterpret_cast<void *>(reinterpret_cast<char *>(&srcData) + sOffsets[i]));
}
これでもなんとかなるかな。

449 :デフォルトの名無しさん:04/10/30 19:41:55
>>446
「offsetof」なんて初めて聞いた!
…と思ったらひょっとしてC++の言語仕様にはないものですよね?
ぐぐってみたらどうやら「.NET Framework」なのかな?

>>448
ふむふむ、ポインタを駆使すれば結構なことが出来そうですね。
しかしなんていうか難しいというかちょっぴり複雑に…。(^^;

基本的に私もメンバを一つ一つ指定することになんの抵抗も無かったんですが、
最近職場でBorlandC++Builderに慣れた同僚が、

「構造体のメンバって一つ一つ名前でアクセスしないといけないんですかねぇ?
 面倒くさいですねぇ」

…などと話していたので、興味を持った次第でつ。
これができるとどういうメリットがあるかという話ですが、
(C++Builderの話限定になってしまうのですが)
DBの不特定なテーブルから、フィールド名を指定せずに
不特定の構造体のメンバにデータを突っ込めるため、
プログラムの汎用性が高まるということらしいです。


450 :デフォルトの名無しさん:04/10/30 22:20:56
offsetofを知らないだけならともかく(それも問題だが)、C#って・・・
絞り込みも出来ない、googleのトップしか見ないで、2番目は無視する人かね

451 :448:04/10/31 01:07:37
>>449
offsetofなんて、Cでもマクロで簡単に書ける代物なんだけど。
標準ヘッダを探してみることもできないのかな?

452 :デフォルトの名無しさん:04/10/31 02:37:42
うわ〜ん、そんなにいじめるなぁ〜。ヽ(`Д´)ノ
簡単にできるというのがいいのだよ。
めんどっちいのはイヤ。

453 :デフォルトの名無しさん:04/10/31 02:45:31
しかし、とりあえずoffsetofというマクロが
標準的に用意されてることを教えていただき、
ありがとうございますた。m(_ _ )m

454 :r:04/10/31 17:05:43
クラスのメンバを、別々に、同じベクタに入れる意味がわからん

455 :デフォルトの名無しさん:04/11/25 02:44:24
最近書き込みがないね。

456 :デフォルトの名無しさん:04/11/25 04:01:13
重複スレだからな。

457 :デフォルトの名無しさん:04/11/26 03:07:57
C言語とJavaとRuby使って,そこそこ書きました.
次はC++にチャレンジするかと,プログラミング言語C++を買ってきました.
難しいです.何書いてるのかわかりません.
俺の頭が悪いのが原因でしょうが,C++の難しさに挫けそうです

458 :デフォルトの名無しさん:04/11/26 08:15:19
ヽ(冫、)ノズコーッ
何処が難しいか言ってみて。
十分習得出来る知識あるように見えるけど…

459 :デフォルトの名無しさん:04/11/26 10:26:54
>>458
>十分習得出来る知識あるように見えるけど…
んな事が >>457 読んで解るのか!ESPer でつか?

460 :デフォルトの名無しさん:04/11/26 10:52:23
>>459
Yep

461 :デフォルトの名無しさん:04/11/26 14:05:17
>>457
CからC++に移ったばかりの人
for (int i = 0; i < 10; i++) {
v[i] = 1;
}

C++を使い慣れてきた人
for (std::vector<int>::iterator it = v.begin(); it != v.end(); it++) {
*it = 1;
}

C++が「使える」と言えるレベルの人
std::fill(v.begin(), v.end(), 1);

これでやっと中級に入門です。先は長いです。くじけそうです。

462 :デフォルトの名無しさん:04/11/26 14:07:40
C++のことがある程度わかってくると、++、--は前置にするもんです。

463 :デフォルトの名無しさん:04/11/26 16:44:04
運置

464 :デフォルトの名無しさん:04/11/26 21:17:08
>>462 どうして?

465 :デフォルトの名無しさん:04/11/26 21:20:14
>>464
前置の方がコピーのコストがかからないから

466 :デフォルトの名無しさん:04/11/26 21:27:04
>>465 どうして?


467 :デフォルトの名無しさん:04/11/26 21:32:47
>>466
More Effective C++の項目6を嫁

468 :デフォルトの名無しさん:04/11/26 21:36:34
>>467
読んでみた。ありがとう。
インライン展開されるような場合は別に気にしなくていいね。

469 :デフォルトの名無しさん:04/11/26 22:23:28
>>461
それ見てC++の方がタイプ量多い割にたいしたこと出来ない。
Cの方が1000万倍マシと悟った。

470 :デフォルトの名無しさん:04/11/26 22:24:18
>>469
それはちょっと勘違いだ。
C++ は C より便利だよ。

471 :デフォルトの名無しさん:04/11/26 22:24:53
>>467
んじゃ、これから
Effective ++C
と書くことにしちくりマンボ

472 :デフォルトの名無しさん:04/11/26 22:28:36
>>471
山田君、座布団一枚持ってっちゃって

473 :デフォルトの名無しさん:04/11/26 22:32:14
>>468
テンプレートでの汎用プログラミングのために常に
前置にしておくと後々組み込み型をクラスにしたくなった
とき修正量が減る。

474 :デフォルトの名無しさん:04/11/26 23:07:05
>>473
組み込み型かクラスかは別に関係ないような?

475 :デフォルトの名無しさん:04/11/26 23:35:39
>>474
クラスだとテンポラリオブジェクトが生成されるよ。
インライン展開されてもね。

476 :457:04/11/27 02:51:11
思ったよりレスが…ありがとうございます.

>>458
最初は俺も楽勝だろーとか思っていたのですが,何故か頭が受け付けません.

>>461
今の俺の書き方だと,モロ最初の書き方ですね…

477 :デフォルトの名無しさん:04/11/27 03:07:44
>>461
C++を究めた人はアセンブリに戻る。

478 :デフォルトの名無しさん:04/11/27 03:10:04
>>477
そういう内容のメガデモ作品があったな

479 :デフォルトの名無しさん:04/11/27 06:47:22
>>461の二番目みたいに、全く抽象化されてもいないのに
無理やりイテレータ使う意義って、全くないように思えるんだが

480 :デフォルトの名無しさん:04/11/27 09:02:51
インポラリ

481 :デフォルトの名無しさん:04/11/27 09:22:04
>>457
> C++の難しさに挫けそうです
「プログラミング言語C++」の難しさに挫けそうなだけだろ。

482 :デフォルトの名無しさん:04/11/27 09:34:42
>>479
そんなことはない。
少なくともコンテナを差し替えられる。

483 :デフォルトの名無しさん:04/11/27 23:14:25
そんなこといったら、最初の書き方ならば
vectorを配列にさしかえれるという利点があるなw

484 :デフォルトの名無しさん:04/11/27 23:16:08
>>483
vectorを配列に差し替えても、あまり嬉しくはないだろう。

485 :デフォルトの名無しさん:04/11/27 23:37:44
速くなるやん

486 :デフォルトの名無しさん:04/11/28 04:04:31
>>485
そういう用途なら、boost::arrayがあるから利点とはならない。

487 :デフォルトの名無しさん:04/11/28 04:36:03
boost::rangeでcontainerとbuilt-in arrayが汎用に扱えるようにもなったしね

488 :デフォルトの名無しさん:04/11/28 11:09:50
後からコンテナを差し替えやすいってのが利点。

489 :デフォルトの名無しさん:04/11/28 17:27:41
コンテナの差し替えなんかするのか?ホントか?

テンプレート引数で型を受け取るときに、
どのコンテナでもOKなのは、確かに意義があるといえるが

前述の例はそういうわけでは全くないし、
正直、三つある例のどの書き方でも、優劣はないと思うが

490 :デフォルトの名無しさん:04/11/28 20:57:16
前述の例だけみればたしかにどれでもいいレベルの話だけど、
意識の持ち方のことを言ってるんじゃないの?
できるだけSTLコンテナやSTLアルゴリズムを使おうという。

491 :デフォルトの名無しさん:04/11/28 21:39:47
しっかし、組み込み型(intとかdoubleとか)のコンテナならSTLのアルゴリズムは
教科書通りに使えるんだが、クラスになると途端に使い物にならなくなるのは
どういうこと?
STLの範囲で済ます場合、メンバ関数ならアダプタでなんとかなるが、メンバ変数は
叙述関数・関数オブジェクトを用意しなければならない。
正直、boost::bindやboost::lambdaが無かったらやってられないよ。
でもこれも一長一短で、boost::lambdaは動かないコンパイラもあるし(bcc32)、
boost::bindは遅いし。

492 :デフォルトの名無しさん:04/11/28 22:55:18
> boost::bindは遅いし。
なんで?

493 :デフォルトの名無しさん:04/11/28 23:17:06
>>492
なんでだろう? 俺が聞きたいよ。
アセンブリコード見たけどよく分からん。あまり最適化されてない様子。
lambdaは早いんだけどな。
単純なlambda式なら、イテレータをループで回すより早かったりする。

494 :デフォルトの名無しさん:04/11/28 23:47:31
>>493
テストコード出せる?

495 :デフォルトの名無しさん:04/11/28 23:49:47
boostの一部のライブラリを見てると、素直にC++にクロージャを足した
新しい言語を作って使えよと言いたくなる。

496 :デフォルトの名無しさん:04/11/28 23:55:10
boost使ってる時点で負け組み

497 :デフォルトの名無しさん:04/11/28 23:57:22
>>496
何を使うと勝ち組みになれるの?
boost のめざそうとしているものを使わなくてもいいってこと?

498 :デフォルトの名無しさん:04/11/29 03:52:25
>>495
C++Builder言語

499 :デフォルトの名無しさん:04/11/29 08:41:38
C++が難しいのは、テンプレートのがポリモルフィズムより速いからだと思う。

500 :デフォルトの名無しさん:04/11/29 08:55:56
http://pc5.2ch.net/tech/kako/1058/10586/1058675178.html
http://pc5.2ch.net/test/read.cgi/tech/1063323615/

501 :デフォルトの名無しさん:04/11/29 09:53:18
>>495
templateの良し悪しはともかくとして、
言語のコアとしてそういった概念のシンタックスを
持つのではなく、メタプログラミングによって後から
追加できるのっていいなと思うけど。


502 :デフォルトの名無しさん:04/11/29 11:15:07
このスレ見てるとげんなりしてくるなw

503 :デフォルトの名無しさん:04/11/29 11:19:09
>>501
同感、クロージャーなどを突っ込むよりtemplate機能をもっと整理して
この種の機能はライブラリとして実装してもらいたい。
クロージャー以外にもデザパタ一式ガベコレ一式程度は自働ジェネレートできるくらいがいい。
言語のコアはあくまでシンプルで高速な物がいい。

504 :デフォルトの名無しさん:04/11/29 12:55:33
VC++で計算した数値を引数で表示したいんですが、printfで表示されません。だからMessageBoxを使って表示したいんですがエラーがでます。どうしたらいいんでしょうか?どなたか分かる人教えてください。


505 :デフォルトの名無しさん:04/11/29 13:10:08
( ゚Д゚)ポカーン

506 :デフォルトの名無しさん:04/11/29 15:55:09
505うぜーよ!!
知らないならくるな!!!
消えちまえーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

507 :モウモウ:04/11/29 21:13:40
>>504
とりあえず、現状のソース見せて。

508 :デフォルトの名無しさん:04/11/29 21:15:44
質問した本人はそのスレ全てを覚えてるとは思えないが…(笑)

509 :デフォルトの名無しさん:04/12/04 16:22:48
「ファイアーエムブレム」は難しすぎ
http://game.2ch.net/poke/kako/1020/10203/1020340325.html
Linuxは難しすぎ
http://pc.2ch.net/linux/kako/1025/10252/1025263879.html
三連複は難しすぎ
http://cocoa.2ch.net/keiba/kako/1025/10252/1025257025.html
メモ帳は難しすぎ
http://pc5.2ch.net/test/read.cgi/win/1101205340/

510 :デフォルトの名無しさん:04/12/13 13:46:51
C++はSTLと継承を使いこなし始めた辺りが
生産性・理解向上の分水嶺だった記憶がある。

511 :釣られたか(w:04/12/13 14:01:00
>504
ConsoleとWinアプリは違うから。
デバイスコンテキストをキーワードに勉強しる。

あとこの手の質問はVC++のスレ・・・って適当なの無いな今は MFC限定しか


512 :デフォルトの名無しさん:04/12/13 14:44:57
>>511
★初心者にVisual C++を教えるスレ★ Part16

513 :デフォルトの名無しさん:05/01/01 23:35:39
C++には、他に類を見ない自由と絶対的な○○が与えられている。

514 :デフォルトの名無しさん:05/02/15 18:08:52
C++の機能限定版とか無いの?

515 :デフォルトの名無しさん:05/02/15 18:32:19
>>514
例外、クラス、関数オーバーロードや
デフォルト引数などの機能を取り除いた
C というものがあります。

516 :デフォルトの名無しさん:05/02/16 18:00:21
>>514
EC++なんてものもある。
http://ja.wikipedia.org/wiki/Embedded_C_Plus_Plus

517 :デフォルトの名無しさん:05/02/17 00:39:05
>>516
だがしかし、はっきり言ってウンコだ。

518 :デフォルトの名無しさん:05/02/19 00:11:41
>>516
例外処理が省かれてるのが最大の問題だな。

519 :361=別名ポリホ:05/02/19 00:26:05
>>518

テンプレートも名前空間もない。
実際にEC++環境があったのでコーディングしてみたことがあるけど、
全然C++らしくない。


520 :デフォルトの名無しさん:05/02/19 06:54:53
まああくまでもembeddedだからねえ。

521 :デフォルトの名無しさん:05/02/22 15:21:43
時々、ECMAScript をバイナリに落とすことが出来ればと考えることがある。

obj = new Object;
obj["Method"] = function( a, b )
{
 echo("OK");
}

obj.Method(); // OK

441 がやりたいことも、プロトタイプ取得で簡単OK

522 :デフォルトの名無しさん:05/02/23 14:30:47
漏れの考えはこうだ!

>461 様の例で「CからC++に移ったばかりの人」の書き方は
いかにも効率が悪そうな印象を受けるけど、
漏れが「仕事で」プログラムを作るなら、
迷わずこのやり方を取る。
(かなり馬鹿にされるだろうけど…。)

そして趣味で(個人的な事情で)プログラムを作るなら、
「C++を使い慣れてきた人」や「C++が『使える』というレベルの人」のような
書き方ができるように努力するだろう。

なぜなら仕事でプログラムを作り、それを他の技術者に引き継ぐ場合、
単純な書き方がもっとも無駄な手間を省くからだ。

そして多くの場合、理解しにくいバグの発生を予め抑制することができる。
また、改修を加えるときや、
不幸にしてプラットフォームの異なる環境へ移植する場合にも、
少ないコストで作業を終えることができるであろう。

スレ違いで申し訳ないけど、
引継ぎ作業によるコストって、
プログラムの書き方で随分変わるんですよ。

「凄いC++技術者」の書いたプログラムを引き継いだ場合、
「凄くないC++技術者の私」が改修を加えるのは大変なんですよ。

523 :デフォルトの名無しさん:05/02/23 15:30:38
>>522
ごく普通なC++プログラマな私からすれば、他人のソースを引き継いだときに
ループが書いてあったらそれだけで要注意項目になります。
std::fillならそのまま読み飛ばせる分だけ、引き継ぎコストは抑えられるわけですな。
構造体も然り。初期化処理をその構造体を利用する側でやらなければいけないよりは
コンストラクタを書いておいてくれたほうがよっぽど確実。
まぁ、「凄くないC++技術者=C++をベターCとしてしか使えない技術者」というなら別ですが。

524 :デフォルトの名無しさん:05/02/23 18:11:34
ようするに522が凄いC++技術者になればいいだけ。

525 :デフォルトの名無しさん:05/03/12 16:40:27
なんで一時オブジェクトは非const参照に変換できないんだ
template<typename E, typename T, typename A, typename Value>
inline std::basic_string<E, T, A>& ToString(std::basic_string<E, T, A>& rstr, Value t) {
  return rstr = static_cast<std::basic_ostringstream<E, T, A>&>(std::basic_ostringstream<E, T, A>() << t).str();
} //static_castしないとエラーを吐く。これはコンパイラのせいだと思う。
#define ToStr0(t) ToString(std::string(), t)

template<typename E, typename T, typename A, typename Value>
inline std::basic_string<E, T, A>& ToString(std::basic_string<E, T, A>* pstr, Value t) {
  return *pstr = static_cast<std::basic_ostringstream<E, T, A>&>(std::basic_ostringstream<E, T, A>() << t).str();
}
#define ToStr1(t) ToString(&std::string(), t)

int main() {
  cout << ToStr0(5) << endl;  //エラー:一致するものが見つからない
  cout << ToStr1(.125) << endl; //OK
  return 0;
}
って書こうと思ったんだよ。
そしたらふと思いついてこうしたら動くんだよ。
#define ToStr0(t) ToString((std::string&)std::string(), t)
頼むからこんなのキャスト無しでも適当にやってくれよ。

そもそもオブジェクトを値渡しで返そうとするとインライン展開できない
ってのがなけりゃこんなことで悩む必要は無かったんだよ>Borland

526 :デフォルトの名無しさん:05/03/12 17:34:19
それはインライン展開しない方がいいと思うが。

つうか、boost::lexcal_castとか素直に使った方がええんじゃないの?

527 :デフォルトの名無しさん:05/03/12 19:06:53
>>526
lexcal_cast.hppをインクルードするとエラーになってしまうもんで。

528 :デフォルトの名無しさん:05/03/13 04:15:03
>>525
> //static_castしないとエラーを吐く。これはコンパイラのせいだと思う。

ostream に対する operator << の戻り値は ostream& だから、
コンパイラに依らずエラーになるはず。
一時オブジェクトで処理しようとしているのが間違い。

529 :デフォルトの名無しさん:05/03/13 11:35:07
>>523
for ( xxx i = foo.begin(); i != foo.end(); ++i.) {
 nannka(*i, arg1, arg2, arg3);
 kannka(*i, arg4, arg5);


こんなのは、NGで
一回しか使わんつまんねえファンクタわざわざ宣言して
for_eachなりつかわんとNGなんだよな?

アンタがそうゆう主義なのはかまわんが
それがごく普通かねえ?

つうか、実務経験なさそうなふいんき

530 :デフォルトの名無しさん:05/03/13 13:12:54
>525
形式的には、一時オブジェクトは右辺値なので非 const 参照に変換できない。

非 const 参照→呼び出された側で変更される

一時オブジェクト→もともと定数だった可能性がある / すぐに破棄される
=定数のものを変更しようとしている / 変更された値が破棄される
ということでデフォルト安全側に倒してるんじゃないでしょうか。

531 :523:05/03/13 15:09:14
>>529
んにゃ、一々ファンクタ書くまでもない処理ならループでもいいんでない?
ただ、ファンクタもいらんような単純な処理まで一々ループを書くなって話。
適切な比較オペレータを持っているクラスだというのに一々findループを書く神経は疑うってことね。
まぁ、>529の例ならファンクタ書かれるよりはループで書かれた方がよっぽどまし。
更に言えば、for (int i = 0; i < foo.size(); i++) なんて書かれるよりずっとまし。

532 :デフォルトの名無しさん:05/03/15 02:44:42
そこでlambdaですよワラ

533 :デフォルトの名無しさん:05/03/19 05:54:34
>>531
しょーもないことにこだわってるあたり覚えたての学生とみた(遠い目

534 :デフォルトの名無しさん:05/03/19 10:29:39
「まし」とか繰り返して、さも自分にはもっといい案があるかのように匂わせておいて
結局そのまま書かずに退散するのが「らしい」ですよね ;-)

535 :523:05/03/19 10:41:38
んー、ないよ〜
単にどっちがいいかって書いただけだし。
ファンクタを作らなくてもalgorithmのfind使えるケースで自分でループ書くのや
iterator使わずに制御変数でループを回すのが要注意だって話で。
>529の例ならそれでなんも問題ないんでない?
#そもそも私自身がファンクタ作るの苦手だw

536 :デフォルトの名無しさん:2005/03/21(月) 12:01:02
C++よりMLの方がいいよ。

537 :デフォルトの名無しさん:2005/03/24(木) 05:34:21
まあバランスが大事だよな

538 :デフォルトの名無しさん:2005/03/25(金) 07:52:46
C++はすさまじく肥大化した言語。しかし、慣れると機能が多くて便利なのも事実だったりする。
シンプルといわれていたJAVAもバージョンが新しくなるにつれて肥大化が進んでいる。
C#はC++から機能を削ったとはいえ、機能を付け加えているから最初から肥大化している。
機能が多い言語は必ず肥大化し、複雑になってしまう。

シンプルで初心者に優しいけど「不便な言語」よりは、複雑で便利な言語のほうが良いと思が、
複雑な言語は初心者には優しくない。

初心者にやさしい「複雑な言語」があれば望ましいけど、それは無理かもしれない。


539 :デフォルトの名無しさん:2005/03/25(金) 08:59:47
>>538
(行き着く先は)自然言語。
そして曖昧さと冗長性が増える罠。

540 :デフォルトの名無しさん:2005/04/25(月) 00:25:10
シーピーピー シーピーピー シーピーピー シーピーピー
シーピーピー シーピーピー シーピーピー シーピーピー
ろ く な も ん じ ゃ ね ー

541 :デフォルトの名無しさん:2005/04/25(月) 08:41:55
負け犬?

542 :デフォルトの名無しさん:2005/04/26(火) 23:11:19
int n;
n.~int();
これがコンパイルを通ってしまうのに驚いた。
こんな関数にint型の値を渡してもコンパイルが通ったからまさかと思ってやってみたら通った。
template <class T>
void Destroy(T& t)
{
  t.~T();
}


543 :デフォルトの名無しさん:2005/04/26(火) 23:52:59
>>542
VS.net2003だと下のテンプレ関数のみ通った。
n.~int();は error C2059: 構文エラー : ''<L_TYPE_ambig>'' って出る。


544 :デフォルトの名無しさん:2005/04/27(水) 00:21:50
テンプレートじゃなくても通るのが正しいような気がする。

545 :デフォルトの名無しさん:2005/04/27(水) 13:49:42
>>538
今ならまだD言語のライブラリは少ない…貧弱

546 :デフォルトの名無しさん:2005/04/27(水) 14:17:59
C++もなにかしようと思ったら機能が貧弱だよ
GCもないし、拡張工事をせざるを得ない
良くも悪くもCなんだな

547 :デフォルトの名無しさん:2005/04/28(木) 00:29:01
>>546
そうだね、あせんぶらにもGCつければべんりだね(わら

548 :デフォルトの名無しさん:2005/04/28(木) 05:10:40
>>546
そうじゃなくて、君の頭じゃC++は無理なんだよ。

549 :デフォルトの名無しさん:2005/04/28(木) 05:16:58
何見当違いの煽りをしてるんだか。

550 :デフォルトの名無しさん:2005/04/28(木) 07:44:37
javaは.closeを書かせておいてGCがあると
主張するのは無理がある。同期のコードなんてCそのものだ。
そういえばGenericsもプリプロセッサで実装しているし
assertの実装は失笑である。javaは新しいCなのだろう。
DはRAIIというのがあるようだ

551 :デフォルトの名無しさん:2005/04/28(木) 17:52:40
C++はむずかしいので、機械語で書いてます。

552 :デフォルトの名無しさん:2005/04/28(木) 18:04:09
>551
俺にはそっちの方がムズい…

553 :デフォルトの名無しさん:2005/04/29(金) 02:10:38
BCBのヘルプに
「alloca 関数の使用はあまりお勧めできません。」
って書いて有るんですけど、そうなんですか?

554 :デフォルトの名無しさん:2005/04/29(金) 09:14:17
>>553
スタックを食い潰すし、移植性に乏しいからでは?

555 :デフォルトの名無しさん:2005/04/29(金) 10:02:13
C99ならVariable Length Arraysを使ったほうが良いかと。

556 :デフォルトの名無しさん:2005/04/29(金) 17:30:06
C++ならstd::auto_ptrを使ったほうが良いかと。

557 :デフォルトの名無しさん:2005/06/02(木) 20:59:36
仮想関数を使えばswitch-caseの嵐から抜けられるわけで、個人的にはそれだけで大満足です。

558 :デフォルトの名無しさん:2005/06/02(木) 23:37:01
>557
だね。場合分けをすることなしに、異なる振る舞いを事前に記述して、コンパイラ任せにできる
有利性、というか。

でも、その有利性を理解できない層というのも確実にあって、それは何かっつーと、
仮想関数という概念、というか言語仕様を知らない層なんだよね。C++はもちろん、
Javaも知らないという層。switch-caseで、あり得る場合分けが全部ソース上に
明記してあった方が判りやすいしデバッグしやすいじゃん、と主張してきそうな、
えてしてそういう層が実装仕様を決めやがるんだよなあ。おっとこれはグチだな。すまん。
誰か強力に布教してくんねーかな。俺はもー疲れた。

559 :デフォルトの名無しさん:2005/06/03(金) 05:12:20
>>558
無理。そういう層は大抵「学習意欲」<「日々の仕事をこなすこと」だから。

560 :デフォルトの名無しさん:2005/06/03(金) 11:21:57
switch-case の代わりとしての仮想関数なら C でも出来るわけで。

561 :デフォルトの名無しさん:2005/06/03(金) 11:26:56
>>560
だからどうした?

562 :デフォルトの名無しさん:2005/06/04(土) 00:16:50
C++儲のおいらでも560には半分同意。
switchの代わりなら構造体+関数ポインタでも
それほど労力がふえるとも思えない。
勿論、仮想関数の方が楽なのは事実だけど。

むしろ、Cで困るのはコンストラク・デストラクタ・templateがない事。
auto_ptrを見ても分かるようにデストラクタが非仮想であっても、
templateと組み合わせればものすごく便利になる。
これが無い故に生成と破棄がセットになったリソースを複数作る
処理で、生成失敗時の破棄処理を書いてるとうんざりする。

563 :デフォルトの名無しさん:2005/06/04(土) 01:28:29
要するに、リソースリークを避けるための下らない労力、プログラムの本質
から大きく外れたロジックやコードがCでは多くを占めてしまうってこったよな。
文字列やリストなんて単純なものも、Cでは悩みの種だ。

まあメモリリーク回避だけならGC使う手もあるがなー。
GC使えるような環境なら今時Cなんて使うなよという話もあるが。

564 :デフォルトの名無しさん:2005/07/13(水) 23:42:53
この速度ならぬるぽ

565 :デフォルトの名無しさん:2005/07/13(水) 23:45:51
>564
ガッ!
ちゅーかまたお前かっ!

566 :デフォルトの名無しさん:2005/07/20(水) 22:15:59
sageてぬるぽもなかろうに
それよか、こんな過疎スレで
sageぬるぽに3分でガッした565の方が神

567 :デフォルトの名無しさん:2005/07/24(日) 23:15:44
int main()
{
  std::locale::global(std::locale("japanese"));
  _bstr_t bs(L"ほげ");
  std::wcout << bs << std::endl; //static_cast<const wchar_t *>(bs)とすれば無問題。
  return 0;
}

VC7.1だとbsはconst wchar_t *か悪くてwchar_t *へ変換されるかと思いきゃ、
なぜかこれに解決される。せめてconst wchar_t *とであいまいにしてくれよ。
template<class _Elem, class _Traits> inline
  basic_ostream<_Elem, _Traits>& __cdecl operator<<(
  basic_ostream<_Elem, _Traits>& _Ostr, const char *_Val)

568 :デフォルトの名無しさん:2005/07/30(土) 10:43:10
今更だけどブロック内での関数宣言を廃止し、全て変数宣言と見なすという仕様にすれば良かったのにと思う。

569 :デフォルトの名無しさん:2005/07/31(日) 00:36:05
>>568
そのメリットは?

570 :デフォルトの名無しさん:2005/07/31(日) 01:25:38
>>569
コンストラクタ呼び出しで作った一時オブジェクトでローカル変数を直接初期化できる。

struct S0 { S0(); };
struct S1 { S1(S0 zero); };

int main()
{
 S1 x(S0()); // 現行の規格では関数宣言
 ...
}

571 :デフォルトの名無しさん:2005/07/31(日) 04:20:58
>570
S1 x = S0(); で回避できると思うけど、いちいち気にするのがいやってこと?

572 :デフォルトの名無しさん:2005/07/31(日) 04:45:26
>>571
その書き方だと暗黙の変換とコピーコンストラクタが必要になる。
S1を↓のようにするとコンパイルできない。
struct S1 { explicit S1(S0 zero); };
struct S1 { S1(S0 zero); private: S1(S1 const&); };

573 :デフォルトの名無しさん:2005/07/31(日) 05:09:49
>>569
ブロック内で関数宣言する奴なんて見かけない。みんなヘッダをインクルードする。
570みたいなコードは誰もが最初変数宣言だと思ってはまる。
それだったら全部変数宣言にするほうが、わかりやすいんじゃないかと考えた。

たとえば「ブロック内では関数宣言をしたければexternを付ける必要がある。
externなしで関数・変数宣言どちらともとれるときは変数宣言」とでもすればよかったのにと思う。

574 :デフォルトの名無しさん:2005/07/31(日) 10:32:18
>>573
Cとの互換性を最優先した結果、なんだろうなあ。

575 :デフォルトの名無しさん:2005/08/01(月) 12:09:55
>>570
S1 x((S0()));

()の2バイト分も面倒か?

576 :デフォルトの名無しさん:2005/08/01(月) 14:22:05
対処法の有無はこの話題には関係無いだろう。

577 :デフォルトの名無しさん:2005/08/02(火) 00:55:12
>576
その対処法によって、570のいう、
> コンストラクタ呼び出しで作った一時オブジェクトでローカル変数を直接初期化できる。
ことができない(実際にはできる)という、現行規格への不満が解消されるのだから関係ある。

まぁ570が、一時オブジェクトをローカル変数のコンストラクタに渡す文法を知らなかっただけのようだが。


578 :570:2005/08/02(火) 01:51:48
知ってたよ。

579 :デフォルトの名無しさん:2005/08/02(火) 03:51:30
一見変数宣言に見えてしまうややこしさを問題としてるという論点に気付かない>>577を暖かく見守る俺が579ゲットですよ

580 :577:2005/08/02(火) 10:28:59
結局568の主張は、
とくに機能的な違いはないけど、今の文法は見た目がわかりにくいから、
ブロック内での関数宣言を廃止し、全て変数宣言と見なすという仕様にすれば良かったのに
ってことなのね。

ぱっと見のわかりやすさは重要だと思うけど、もう二重に括弧つける癖がついたんで、どうでもいいかなと思う。
>579 サンキュー。これからも暖かく見守ってください。

581 :デフォルトの名無しさん:2005/08/05(金) 01:15:34
このスレの人たちは英文をバリバリに読めるのか?
俺全然読めない。

582 :デフォルトの名無しさん:2005/08/05(金) 06:24:21
英語しかなければ読むけど、ちょっと下手という程度なら日本語に喜んで飛びつきますが何か。
規格だってISOではなくJISの訳を読むし。

583 :デフォルトの名無しさん:2005/08/05(金) 10:31:42
キチガイ翻訳はお断りだが

584 :デフォルトの名無しさん:2005/08/08(月) 16:18:38
>>583
じゃお前が翻訳してくれ

585 :デフォルトの名無しさん:2005/08/08(月) 18:40:15
それが出来りゃ原書読むわい

586 :デフォルトの名無しさん:2005/08/15(月) 09:49:34
糞 ス レ 勃 て て ん じ ゃ ね え よ 脳 挫 傷 !

587 :デフォルトの名無しさん:2005/08/15(月) 12:19:58
>>586
今頃何言ってんの?m9(ry

588 :デフォルトの名無しさん:2005/08/15(月) 13:32:23
プギャ(ry

589 :デフォルトの名無しさん:2005/09/03(土) 20:06:30
OSのベータ版を市販するやり方は
どこにもマネできないくらい最強

590 :デフォルトの名無しさん:2005/11/21(月) 20:30:09
JavaScriptは難しすぎ
http://pc8.2ch.net/test/read.cgi/hp/1132400636/

591 :デフォルトの名無しさん:2005/11/28(月) 14:52:04
ポインタと参照を混ぜるとややこしいから、ポインタで統一してるんだけど
参照しか使えない場合もあるしなんなんだよ!!

592 :デフォルトの名無しさん:2005/11/28(月) 15:29:17
俺はなるべく参照を使って、仕方ない時だけポインタを使う

593 :591:2005/11/29(火) 14:48:00
あっそうかスマートポインタ使えばいいんだって使ってるプロジェクト
見たことねえorz

594 :デフォルトの名無しさん:2006/01/04(水) 11:55:46
もっともっと難しくなって構わないから早く来いC++0x。
なんてこのスレで言うとぼこぼこにされそうだ。

595 :デフォルトの名無しさん:2006/01/06(金) 00:21:22
C#に慣れてきたらC++触るのテラダルくなってきた…
つーか、同じVisualStudioなのにエディタの出来があからさまにVC#>>>>>>VCなのは何の嫌がらせだよ

596 :デフォルトの名無しさん:2006/01/06(金) 00:35:56
>>595
(゚∀゚)人(゚∀゚)ナカーマ

597 :デフォルトの名無しさん:2006/01/08(日) 01:29:03
>>595
C#はM$が作った言語だからJava、Delphi潰しをしながら
普及のために本気にならんといかんのだよ
C++についてはM$の都合におかまいなく拡張されたりするから
ほんとはサポートすんのヤなの
だけどC#がコケた時の保険のつもりで一応サポートしとくの
これが戦略。わかる?
ほんとはC#、VBで世界を支配したいの
あとはオマケ

598 :デフォルトの名無しさん:2006/01/08(日) 03:30:39
>>597
2バイト文字使うなら
せめて♯を使えよと。

599 :デフォルトの名無しさん:2006/01/08(日) 19:48:58
エディタはEmacs系を使えばいいのだ、勝手に補間するVSの親切エディタとは手を切れ、
あれは人を堕落させる。

600 :デフォルトの名無しさん:2006/01/09(月) 00:59:30
>>595
言語仕様が複雑でC#よりマンドクセからじゃないかなあ。

601 :デフォルトの名無しさん:2006/01/09(月) 21:15:09
>>595
なんか、MSはC#を無理やり推し進めている感じだしね。
FXではWIN32 API呼ぶのにオーバーヘッドがあるようだし・・・

602 :デフォルトの名無しさん:2006/01/11(水) 23:05:13
つーかアプリのパフォーマンスにAPIのオーバーヘッドなんざ
ほとんど関係ないと思うが。処理の9割以上は自分のコード
の中だろ?

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

604 :デフォルトの名無しさん:2006/01/13(金) 13:44:16
>>603
> だから

まで読んだ。

605 :デフォルトの名無しさん:2006/01/13(金) 18:34:11
>>603
日本語でおk

606 :デフォルトの名無しさん:2006/01/14(土) 03:46:11
日頃誰にも吐き出せず溜め込んでいたモノを一気に吐き出したようだが、
そうやって長年熟成させてきた割には深みゼロなのが哀しいね。
まぁ、この程度の頭だから、誰にも認められずストレス溜めてるんだな。

607 :デフォルトの名無しさん:2006/01/14(土) 13:09:20
>>603
デジャブか。
どっかでみたレスだ。

608 :デフォルトの名無しさん:2006/01/16(月) 18:52:13
>>606
では君が深みのある話をしてくれ。ぜひ読みたい

609 :デフォルトの名無しさん:2006/01/17(火) 11:53:19
>>608
「では」の使い所が変ですね。

610 :デフォルトの名無しさん:2006/01/17(火) 17:23:19
>>603
> 「で

まで読んだ。

611 :デフォルトの名無しさん:2006/01/17(火) 18:50:02
普通に603より609のほうが深いのが悲惨だなw

612 :デフォルトの名無しさん:2006/01/26(木) 21:11:27
>>609
ではどうすれば正しいのか教えてくれ

613 :デフォルトの名無しさん:2006/01/26(木) 21:54:07
その使い方は正しい。>>608は変。

614 :デフォルトの名無しさん:2006/01/29(日) 20:48:13
>>613
どう変なのか説明よろ

615 :デフォルトの名無しさん:2006/01/30(月) 07:10:13
繋がりがまるでない。

616 :デフォルトの名無しさん:2006/01/30(月) 12:01:29
>>614
批判に対して「じゃあお前がやってみろ」というのは
反論にも何にもなってないわけですが、
小学生くらいだと別におかしいとは思わないようですね。

617 :デフォルトの名無しさん:2006/01/30(月) 22:33:06
お前らもっと生産的なことに労力を使うように汁。

618 :デフォルトの名無しさん:2006/04/21(金) 14:44:27
C++を使いはじめて10年以上になるが、
これまでC++をC++として使える奴って未だ見た事がない。
このスレでC++を絶賛している奴は本当にC++を使いこなしているのか疑問。

619 :デフォルトの名無しさん:2006/04/21(金) 19:12:33
2chだし、ピンキリいると思うよ。

620 :デフォルトの名無しさん:2006/04/21(金) 21:41:08
そもそも何を持ってC++をC++として使っているというのかが曖昧。

621 :デフォルトの名無しさん:2006/04/22(土) 01:17:52
2chでなくてもピンキリ
ttp://sourceforge.jp/softwaremap/trove_list.php?form_cat=165

622 :デフォルトの名無しさん:2006/04/22(土) 10:47:13
>>618
おまいの周囲の連中のレベルなんか知ったこっちゃないが
>このスレでC++を絶賛している奴は
「絶賛」する奴 (いたっけ?) は信用するな。
見た目だけで「あいついい女だよな」っつってる奴は
その女と付き合ってるわけではない。

623 :デフォルトの名無しさん:2006/04/29(土) 16:21:55
そもそもオブジェクト指向が難しすぎ
gotoを使って何が悪いんだ

624 :デフォルトの名無しさん:2006/04/29(土) 17:17:48
>>623
それはない。

625 :デフォルトの名無しさん:2006/05/01(月) 12:07:03
>623
オブジェクト指向とgoto不要論を同じレベルで論じるなよ

626 :デフォルトの名無しさん:2006/05/22(月) 14:29:18
>>595
>つーか、同じVisualStudioなのにエディタの出来があからさまにVC#>>>>>>VCなのは何の嫌がらせだよ
だよな

627 :デフォルトの名無しさん:2006/05/24(水) 11:55:09
C++の標準化委員会は冒険的に過ぎるところがある。
C++がこれだけ強力な言語になったのは彼らの力だけど、
いろいろと取り返しの付かない失敗をしている。
slice_arrayで大恥をかき、exportや<cNNN>ヘッダで実装者を悩ませ、
言語仕様の穴を利用してauto_ptrを実装してしまう。
koenig lookupなんかは、ライブラリの設計ミスを言語仕様側で
取り繕おうとして傷口を広げた例だね。
もう少しやる気の無い連中、あるいは後方互換性にこだわらない連中が
標準化をやっていればこんなに難しい言語にはならなかっただろうに。

628 :デフォルトの名無しさん:2006/05/24(水) 12:40:01
で、C++のどこが難しいんだ?
クラスが分からないのか?

629 :デフォルトの名無しさん:2006/05/24(水) 12:54:45
>>627
概ね頷けるところだが、
> koenig lookupなんかは、ライブラリの設計ミスを言語仕様側で
> 取り繕おうとして傷口を広げた例だね。
これだけ、聞いた事が無い話だった。
何のこと?

630 :デフォルトの名無しさん:2006/05/24(水) 13:05:06
>>627
>後方互換性にこだわらない
ここ同意

631 :デフォルトの名無しさん:2006/05/24(水) 13:12:19
後方互換性は、言語使用の複雑さの原因であることは確かなんだが
普及の速度には大きく貢献してるだろうから、単純に否定できないと思うんだ。

632 :デフォルトの名無しさん:2006/05/24(水) 15:52:15
まぁ、実際に携わってみれば誰もが苦しむところだろうな。

633 :デフォルトの名無しさん:2006/05/24(水) 17:05:09
>>631
まあそうなんだけど、予約語の使いまわしが
初学者を混乱させてんじゃないかな、と。

634 :デフォルトの名無しさん:2006/05/24(水) 18:51:51
ケーニヒがなかったら
a + 1 // OK a.operator+(1)
1 + a // NG
my_namespace::operator+(1,a) // OKだが書いてられるか

635 :デフォルトの名無しさん:2006/05/24(水) 20:17:10
D&Eを読めば嫌と言うほど互換性確保に努めてきた様子がひしひしと伝わってくる。

636 :デフォルトの名無しさん:2006/05/24(水) 21:43:18
初学者のためにOSのカーネルがコンパイルできなくなるなんて
許されないからな

637 :デフォルトの名無しさん:2006/05/24(水) 23:01:13
>>629 >>634
operatorやswapをこんな感じにしておけばKoenig lookupは要らなかった。
lessを提供すればless_equalも勝手に実装してくれるとか、
そういう仕組みを作ることもできる。

namespace std {
    ...
    namespace hooks {
        template <class T1, class T2>
        struct plus_traits;

        template <class T>
        struct plus_traits<std::complex<T>, std::complex<T> > {
            typedef std::complex<T> result_type;

            static std::complex<T>
            plus(const std::complex<T> &a1, const std::complex<T> &a2)
            { ... }
        }
    }
}

template <class T1, class T2>
std::hooks::plus_traits<T1, T2>::result_type
operator+(const T1 &a1, const T2 &a2)
{ return std::hooks::plus_traits<T1, T2>::plus(a1, a2); }

638 :デフォルトの名無しさん:2006/05/24(水) 23:17:26
>>637
それだと operator+ を定義していないクラスに + を使おうとしたとき、
plus_trais についてのエラーメッセージが出るよね?それもなんかおかしくね?

639 :デフォルトの名無しさん:2006/05/24(水) 23:25:01
>>637
わざわざstd::huck::plus_traitsに持っていく意味がわからない。

640 :デフォルトの名無しさん:2006/05/25(木) 00:19:15
>>638-639
std::hooksに含まれているテンプレートを部分特殊化してくれって意味。
オーバーロード解決に相当する処理をテンプレートで実装する必要があるから、
現行C++の機能だけで完全に実現できるかは分からんけど、
必要ならコンパイラにいくつか機能を追加すればいい。

641 :デフォルトの名無しさん:2006/05/25(木) 00:41:39
>>640
コンパイラに koenig lookup を追加すればいいってことだな。

642 :639:2006/05/25(木) 02:39:06
>>640
その意味はわかるけど意図が判らない。
直接operator +を特殊化すればよいのではないかと思った。

643 :デフォルトの名無しさん:2006/05/25(木) 02:46:28
>>637
これはこれで一時期は真剣に考察されていた案ですけれど,
結局「分かりにくい」ということで一度標準委員会で否決されているんですよね.
swap の場合ですけれど.

特にデフォルトがない hook の場合,特殊化に基づく hook の提供は
exact match を要求する,つまり特殊化したい型それぞれに
いちいち全部特殊化を用意しなければならない
(これは base-derived や cv-qualification まで含めて厳密にやらないといけない)
のに対して, ADL による hook は loose match で済む,
例えば base に対する特殊化が derived に自動的に適用されるような
直感的なあり方に一応適合します.
この議論は関数テンプレートの部分特殊化 (FTPS) が導入されても
基本的な議論の流れに大きな変化はないでしょう.
(というか,クラステンプレートの静的メンバ関数を用いるそもそもの動機は,
FTPS が現行規格で存在しないことの workaround だったはずです)

もちろん ADL による hook の提供の場合も,一般に挙動が非常に予測しにくい,
つまり,名前空間お構いなしでありとあらゆる名前空間を潜在的にぶち破る
凶悪な特性を持ちえることと,一般に汎用プログラミング特有の構文指向な面が
強く出る (hook がどう定義されているか (signature-oriented) ではなくて
hook をどう呼び出したか (syntax-oriented) に意味が左右されやすい)
という非常に大きな欠点を抱えるのも確かです.

644 :デフォルトの名無しさん:2006/05/25(木) 02:47:08
>>637
より踏み込んだ議論として,そもそも hook の所有権・所在の
あり方に関する議論もあります.

特殊化に基づく hook の提供の場合,特定の名前空間に hook の所在が
固定されますが,それはそもそも正しいのか?
全く関係の無いサードパティが提供するヘッダとプライマリテンプレートに依存し,
その名前空間を開けて hook を提供しなければならなくなる状況も想定され,
それは本当に正しいのか?という疑問です.
そういう意味では ADL による hook があらゆる名前空間を
潜在的にぶち破る特性を逆手にとって,
「大域の ADL hook 用名前空間 (global ADL namespace) に hook をおく」と
考えることも, hook の所在の中立性という観点からは
あるいは悪くないともいえます.

少なくとも「ライブラリ設計の欠点とその補完としての ADL」という観点は
少し視野が狭すぎるような気がします.

645 :デフォルトの名無しさん:2006/05/25(木) 03:00:06
>>642
operator+ には特殊化するべきプライマリテンプレートがそもそもないです.
また,関数テンプレートの部分特殊化が現行規格に存在しないために,
一般にクラステンプレートに対して関数テンプレートを特殊化することができない,
という事情もあります.クラステンプレートの静的メンバ関数を
わざわざ持ち出すのは,関数テンプレートの部分特殊化の
エミュレーションのためだと思ってもらえれば良いかと思います.

646 :デフォルトの名無しさん:2006/05/25(木) 05:56:24
>>643-644
> ADL による hook は loose match で済む,
こいつの解決策だけど、
案1: オーバーロードを追加するとき、新しい名前を導入したとみなさないで
部分特殊化と同様に扱えるような構文を導入する
lazyoverload operator+;
namespace std {
    ...
    namespace hooks {
        lazyoverload swap;

        template <class T, class Alloc> void
        swap(std::vector<T, Alloc> &a1, std::vector<T, Alloc> &a2)
        { a1.swap(a2); }
    }
}
template <class T> std::complex<T>
operator+(const std::complex<T> &a1, const std::complex<T> &a2)
{ ... }
コンパイラから見ればKoenig lookupとほとんど同じ機能だから、
実装は不可能ではないはず。

647 :デフォルトの名無しさん:2006/05/25(木) 06:09:37
案2: typeofなどの機能を導入してオーバーロード解決の機構を
テンプレートから活用できるようにする
template <class U>
struct plus_traits<std::complex<int>, U> {
    static std::complex<int>
    plus(const std::complex<int> &a1, int a2)
    { ... }
    static std::complex<double>
    plus(const std::complex<int> &a1, double a2)
    { ... }

    typedef typeof(plus(const std::complex<int> &, U)) result_type;
};
実現性がどの程度なのかは分からんけど、可能ならテンプレートの力はかなり増す。

648 :デフォルトの名無しさん:2006/05/25(木) 13:11:41
>>646
>>643さんが指摘されてる、クラステンプレートの部分特殊化による手法の問題は、
class Aに対してstd::hooks::???_traits<A>を実装したとして、
その後AのサブクラスであるB,C,...Zを作成した際に
全く同じstd::hooks::???_traits<B>, ... std::hooks::???_traits<Z>を
実装しなければならないということだと思うのですが。
この点、ADLの場合は基底クラスを引数にとる関数一つで用は足ります。

派生クラスと基底クラスの関係は、
オーバーロード解決では考慮されますが(部分)特殊化の解決では考慮されません。

>>643のコードを見る限り、operator+(T,T)の部分特殊化として
operator(const complex<T>&, const complex<T>&)を定義しているようですが、
これでは、>>643で言及された問題は解決できません。

ただし、ADLがない世界を仮定して、更にlazyoverload云々を無視して
普通のオーバーロードだと考えれば、>>643の問題はないように思います。
これは、hook用名前空間を1ヶ所用意して、
特殊な動作は全部そこに書く/書かせるということと同じでしょう。
もちろん名前空間の内部が第三者によって手を加えられる(特殊化ではなく)という問題はありますが。


649 :デフォルトの名無しさん:2006/05/25(木) 13:51:00
>>648
普通のオーバーロードだとこれが動かない。
template <class T>
std::complex<T> operator+(std::complex<T> a1, std::complex<T> a2);

namespace std {
    template <class T>
    struct plus : public std::binary_function<T, T, T> {
        T operator()(const T &a1, const T &a2) const
        { return a1 + a2; }
    };
}

template <class T>
std::valarray<T> operator+(std::valarray<T> a1, std::valarray<T> a2);

650 :648:2006/05/25(木) 14:43:27
>>649
std::plus::operator()内のa1+a2のことを言っていると思いますが、
いまいちよくわからないので、推測しながら答えます。

まず、complexのoperator+が、
plus内部から解決されないことを問題にしているのであれば、
>ADLがない世界を仮定して、
ということです。
もう少し補足すると、ADLがない結果として、
std名前空間内にoperator+がないことも仮定しています。

また、valarrayのoperator+が最後に定義されていることから、
two phase lookupを問題にしているとも推測できますが、
それでも特に問題がないのではないでしょうか?

どこを問題にしてるかを明らかにしてもらえれば、
より有意義に議論できると思います。

651 :648:2006/05/25(木) 14:55:55
よく考えてみたら、ADLがない場合には
two phase lookupの挙動が変わりそうな気がしてきましたが
そこまでは考えていませんでした。

652 :デフォルトの名無しさん:2006/05/25(木) 16:19:50
>>650
plusからはcomplexのoperator+は見えるけどvalarrayのoperator+は見えない。
646で書いたlazyoverloadというのはoperator+を全部見てくれという意味。

653 :デフォルトの名無しさん:2006/05/25(木) 17:56:54
>>652
一応確認しておきますが、通常のC++における>>649のコードの問題点は、
両方のoperator+がstd名前空間内にないことですよね?
>>649の"ような"コードでは、complexのoperator+もstd::plus::operator()からは呼ばれませんし、
>>649のコード単体ではcomplexのoperator+は呼ばれますが、
 std::basic_string等のoperator+がstd名前空間内に定義されてしまうと呼ばれなくなる)
逆に、両方のoperator+がstd名前空間内にあれば、両方ともplusから呼ばれます。

で、本題に戻りますが、>>643で指摘された問題点と
lazyoverloadには何の関連があるのでしょうか?
今の段階では、
> ADL による hook は loose match で済む,
という部分を勘違いされているように思えます。

あと、
>lazyoverloadlazyoverloadというのはoperator+を全部見てくれという意味。
の全部というのは、名前空間を無視して全部ということでしょうか?


654 :デフォルトの名無しさん:2006/05/25(木) 23:59:35
>>653
>>643の問題を普通のC++で解決するのが大変or不可能であることは認識している。
で、その解決策として部分特殊化でなくオーバーロードでhookを実現
できるようにする(>>646)か、メタプログラミング向けの機能を追加する(>>647)
ことを考えた。
> >lazyoverloadlazyoverloadというのはoperator+を全部見てくれという意味。
> の全部というのは、名前空間を無視して全部ということでしょうか?
lazyoverload宣言をした名前空間の中だけ。解決したいのは次の問題。
namespace nnn {
    int fff(int) { return 0; }
    template <class T> int good() { return fff(T()); }
    template <class T> int bad() { return nnn::fff(T()); }
    int fff(char) { return 1; }
}
と定義されているとき、nnn::good<char>()は1を返すけどnnn:bad<char>()は
0を返してしまう。テンプレートを定義した時点で見える関数だけでなく、
インスタンス化した時点で見える関数を全部候補にしてくれ、というのが
lazyoverloadの意味。

655 :デフォルトの名無しさん:2006/05/26(金) 00:55:41
>>654
標準準拠のコンパイラでは、
そのコードでは、nnn::good<char>()も0を返すはずです。
というのは、point of instantiationの文脈で名前解決を行うためには、
unqualifiedな関数呼び出しで(これはOK)、かつADLを介する必要があります。
しかし、charにはassociated namespaceがないため、ADLが行われません。
その結果、point of definitionの文脈で名前解決が行われます。

というのを昔、>>643の中の人(多分)にどこかのスレッドで教えてもらった記憶があります。

ちなみに、>>643に対する一つの解決法として
現在、boost.rangeなどで使われているものがあります。
lazyoverloadによる結果と違うのは、
fundamental type用のフックが定義できるかどうかということでしょうか。

656 :デフォルトの名無しさん:2006/05/26(金) 01:10:18
>>655
>現在、boost.rangeなどで使われているものがあります。
>lazyoverloadによる結果と違うのは、
>fundamental type用のフックが定義できるかどうかということでしょうか。

あと、フック関数の定義される場所が
1ヶ所の名前空間になるか(lazyoverload)
複数の名前空間にまたがるか(boost.range)ということでも違いますね。


657 :デフォルトの名無しさん:2006/05/26(金) 01:38:15
>>655
> そのコードでは、nnn::good<char>()も0を返すはずです。
これですね。勉強になりました。
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#197
> fundamental type用のフックが定義できるかどうかということでしょうか。
ADLが利用できて、operator以外であれば、フックにダミーの引数を入れて
無理矢理ADLをやらせる手がありますね。
namespace hooks {
    struct hack;
}
template <T> int really_good() { return fff(hooks::hack(), T()); }
struct hooks {
    int fff(hack, int) { return 0; }
    int fff(hack, char) { return 1; }
}
struct abc {
    struct A {};
    int fff(hooks::hack, A) { return 2; }
}

658 :デフォルトの名無しさん:2006/05/27(土) 02:44:49
lazyoverload を持ち出している方の動機は一応理解できているつもりです.
ですが, lazyoverload という提案はあくまで今手に入る
言語の仕様ではないので,これに関する議論は少し避けさせてもらいます.
提案自体に対しても,特に後方互換性の点で色々あら捜しはできるかとも
思いますけれど,それも指摘したところであまり実になるとは思わないので,
もうちょっと一般的なことをつらつら書かせてもらいたいと思います.

hook をある名前空間に集約するべきか,あるいは
あらゆる名前空間(associated namespace)に散在させるべきかは
一般に非常に難しい問題だと思います.
例えば swap という hook を考えたとき(これは現行規格の文言では
ADL 経由で発見される hook であるとは明示されていませんが),
swap という操作は問題ドメインをほとんど限らない非常に一般的な操作・概念で,
1つの名前空間に集約する方向性はそれほど正しいとは思えない.
どちらかというと各ユーザ定義型の associated namespace においておくほうが
おそらく正しい. std 名前空間に集約するという方策もある意味中立性が高いので,
std 名前空間に swap という hook を集約してしまう考え方もあるかとは思いますが,
そうした場合,今度はそれまで考慮されてこなかった新しい hook が登場してきた
場合に,その hook をどこに集約するべきなのかという問題が常についてまわります.

659 :デフォルトの名無しさん:2006/05/27(土) 02:45:30
もちろん ADL による hook でも問題はあります.
先の swap を ADL 経由の hook とする場合,あらゆる名前空間において
"swap" という名前の非メンバ関数の意味を潜在的に予約してしまいます,
これのため,あらゆるドメインで "swap" という名前に対する共通のコンセンサス
(つまり2つのオブジェクトの状態を交換するという操作の名前であるという共通認識)
が取れるという(楽観的な)前提が必要になります.
実際, swap に対する将来的な規格の方向性は現在のところこの立場のようですが,
一方でこの話を金融関連のドメインで仕事をしている方たちにしたところ,
「swap という言葉は金融関連のドメインではまったく違う意味で使われる
(ので swap という名前に共通のコンセンサスが取れるという認識は甘い)」
と異論がきてしまった,という話もあったようです.
swap という非常に一般的と思われる名前1つでこの状況ですから,
おそらくある名前を全ての名前空間で潜在的に予約してしまう ADL hook のあり方は
一般には非常に受け入れがたい.
現在, Boost.Range などで導入されている ADL hook の名前では,
この問題を避けるため,マクロの名前規則を髣髴とさせる
boost_ なんて prefix が付いています.
しかしこれでは ADL による hook の大きな利点であった
「hook の所在の中立性」をかなり殺してしまっています.
実際,この観点から名前を boost_begin じゃなくて range_begin にしたら?
という議論も見受けられます.

660 :デフォルトの名無しさん:2006/05/27(土) 02:46:12
ライブラリ設計を考える上でユーザの使い勝手は非常に重要で,
そして hook をユーザにどう提供させるかはまさにライブラリの
インタフェース設計そのもので,ユーザの使い勝手に直結する部分だと思います.
今ここで議論されている方々は造詣が深く,
hook の提供における問題点を把握され整理されておられるので,
>>646 >>647 >>657 といった手法も自然に受け入れられ,
各々の手法の長短も理解されておられますが,
世間一般の大多数から見れば非常に理解しづらい難解な問題であり,
ライブラリ利用者の立場でこれらの手法を利用して
hook を提供しようとする場合,大多数はいわゆるバッドノウハウ,要するに
「関心のある問題の解決に直結しない,不必要に難しい手法と知識」
としか評価してくれないかと思います.
そしてこれはそのままライブラリ全体の評価に直結すると思います.
こういった,特にライブラリを利用する上でのバッドノウハウは
うまく隠蔽できるならばそれに越したことはないかと思います.
ADL hook はもちろん色々な問題は抱えますが, 利用者の立場から見れば,
他の手法と比較しても,次善策としてはある程度妥協できるレベルに
あるんじゃないでしょうか?

Boost.Serialization では,アーカイブのバージョンを指定する引数に
>>657 で示されているような hack を巧妙に隠蔽することで,
two-phase lookup での問題を解決しつつ, hook のためのオーバーロードを
boost::serialization 名前空間に集約させることに成功していますが
(ライブラリ作者の名前から Ramey trick とか呼ばれることもあります),
あのレベルに到達して初めてライブラリのインタフェースとしては
成功と言えるのではないかと思っています.
もちろん,あの手法は非常に特殊な状況で偶発的に成功した例だと思いますので,
汎用性が全く欠けていて応用が利かないのですが…….

661 :デフォルトの名無しさん:2006/05/27(土) 02:46:35
個人的にはこれらの問題は C++ の言語規格あるいは
C++ のライブラリ設計を原因とする固有の問題だとは思っておらず,
(C++ の)汎用プログラミングにおいて非常に重要で魅力的な特性である
"non-intrusiveness" を成立させつつ,なおかつ hook をどう提供するか,
を考える上でかなり本質的な問題だと思っています.
将来的な言語機能の追加も視野に入れてよいならば,例えば
コンセプトに基づく特殊化・オーバーロードといった C++0x での
機能追加があるいは問題解決の1つの糸口になるのではないかと
個人的には思っています.

662 :デフォルトの名無しさん:2006/05/27(土) 07:30:03
ドラゴンボールにたとえてもう一回プリーズ

663 :デフォルトの名無しさん:2006/05/27(土) 10:42:33
神様、宇宙人、人造人間、とさらに強い敵を出すために世界観が滅茶苦茶。
技もどんどんインフレになっていき、何が強くて何がよわいのか、序列や使い方
が良くわからん。つまりドラゴンボール状態。
C++ is Dragon Ballというのは、アメリカのカンファレンスで良く聞くジョークでも
ある。


664 :デフォルトの名無しさん:2006/05/27(土) 14:27:51
(拍手)

665 :デフォルトの名無しさん:2006/05/27(土) 17:59:55
よく聞くのかよ

666 :デフォルトの名無しさん:2006/05/27(土) 21:39:59
毎日な

667 :デフォルトの名無しさん:2006/05/28(日) 23:12:30
『ゴクウが教えるC++』という書籍では、継承を説明するのに、サイヤ人←スーパーサイヤ人と
いう誰でも思いつきそうな例で説明されているらしい。

668 :デフォルトの名無しさん:2006/05/28(日) 23:18:13
例えで説明してもらわなくても、シンプルなソースと実行結果があれば概念なんて直ぐわかっちゃうのに。
例えての説明で一番分かってもらえるのは、既に知っている人なんだけどな。
しかもC++はあまり難しくないと言う罠。

669 :デフォルトの名無しさん:2006/06/02(金) 06:35:13
C++の難しさはbetterCとしても使えてしまうところじゃないか?
結局のところ、それでもかなりのことが行えるので、それで満足してしまって
C++の本域や可能性を見失ってしまう。
まぁ、STLにしてもほかのBoot(?)にしてもこれらを使いこなせるようになる前に
大概のことは楽にやってのけられるし、
これらを学んでも実践にどこまで投入していいか?の問題もある。

あと、Cの影響力が強すぎてC時代の財産とかが未だに尾を引いているのかもしれない。
(周りの人間との統合性とかを考えるとやっぱり Better Cぐらいが一番能率がいいのかもしれないし。)

670 :デフォルトの名無しさん:2006/06/02(金) 14:47:20
>>669
休刊直前くらいのCマガにそれと同じこと書かれてたな。

671 :デフォルトの名無しさん:2006/06/09(金) 03:28:13
C++がドラゴンボールというのは、なんとか仙人とか何とか王様とか変な権威ありそうな
奴がいろいろ御託を並べるが、実は何か奥が深い物があるわけではない、という点でも
似てるな。

672 :デフォルトの名無しさん:2006/06/09(金) 16:48:52
MFCで自作簡易レンダリングエンジンって出来ませんか。(IEに依存しない)
何方か方法おしえて>>>

673 :デフォルトの名無しさん:2006/06/09(金) 17:11:22
>>672
マルチ氏ね

674 :デフォルトの名無しさん:2006/08/15(火) 17:53:21
Javaは引数の参照渡しができない
とんでもない駄作

675 :デフォルトの名無しさん:2006/08/15(火) 19:52:10
>>674
そーゆーこはJava厨が沢山居そうなスレにageで書き込みなさい。

676 :デフォルトの名無しさん:2006/12/26(火) 18:42:28
C++のマニピュレータはどこもマネしないくらい最強

677 :デフォルトの名無しさん:2006/12/26(火) 18:57:45
あれ使ったことない
難しいというか・・・鬱陶しいというか・・・

678 :デフォルトの名無しさん:2006/12/29(金) 02:07:53
アレはどっちかっていうと単にインターフェイス的にもパフォーマンス的にも
駄作(というか失敗作?)だから、みんなにそっぽ向かれただけ。printfマンセー!

679 :デフォルトの名無しさん:2006/12/29(金) 18:56:34
まああれはあれで、使いようによっては有用で便利なんだが

vector<int> vec_int;
 ・・・中略
cout << vec_int / "," % 3 << endl;

たとえばこれで、vec_intの中身全部を
一行に3要素ずつ( % 3)、カンマで区切って( / "," )
出力なんてことをやったりできる

680 :デフォルトの名無しさん:2006/12/29(金) 18:58:18
ああ↑はあくまで、こういうマニュピュレータを自分で定義したら、という話ね。

681 :デフォルトの名無しさん:2006/12/30(土) 01:44:13
そもそもstd::endlもマニピュレータだということを知らない人がかなり多い

183 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)