- 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/
- 610 名前：デフォルトの名無しさん mailto:sage [2006/01/17(火) 17:23:19 ]
- >>603
> 「で
まで読んだ。
- 611 名前：デフォルトの名無しさん mailto:sage [2006/01/17(火) 18:50:02 ]
- 普通に603より609のほうが深いのが悲惨だなｗ
- 612 名前：デフォルトの名無しさん mailto:sage [2006/01/26(木) 21:11:27 ]
- >>609
ではどうすれば正しいのか教えてくれ
- 613 名前：デフォルトの名無しさん mailto:sage [2006/01/26(木) 21:54:07 ]
- その使い方は正しい。>>608は変。
- 614 名前：デフォルトの名無しさん mailto:sage [2006/01/29(日) 20:48:13 ]
- >>613
どう変なのか説明よろ
- 615 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 07:10:13 ]
- 繋がりがまるでない。
- 616 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 12:01:29 ]
- >>614
批判に対して「じゃあお前がやってみろ」というのは
反論にも何にもなってないわけですが、
小学生くらいだと別におかしいとは思わないようですね。
- 617 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 22:33:06 ]
- お前らもっと生産的なことに労力を使うように汁。
- 618 名前：デフォルトの名無しさん mailto:sage [2006/04/21(金) 14:44:27 ]
- C++を使いはじめて10年以上になるが、
これまでC++をC++として使える奴って未だ見た事がない。
このスレでC++を絶賛している奴は本当にC++を使いこなしているのか疑問。
- 619 名前：デフォルトの名無しさん mailto:sage [2006/04/21(金) 19:12:33 ]
- 2chだし、ピンキリいると思うよ。
- 620 名前：デフォルトの名無しさん mailto:sage [2006/04/21(金) 21:41:08 ]
- そもそも何を持ってC++をC++として使っているというのかが曖昧。
- 621 名前：デフォルトの名無しさん mailto:sage [2006/04/22(土) 01:17:52 ]
- 2chでなくてもピンキリ
ttp://sourceforge.jp/softwaremap/trove_list.php?form_cat=165
- 622 名前：デフォルトの名無しさん mailto:sage [2006/04/22(土) 10:47:13 ]
- >>618
おまいの周囲の連中のレベルなんか知ったこっちゃないが
>このスレでC++を絶賛している奴は
「絶賛」する奴 (いたっけ？) は信用するな。
見た目だけで「あいついい女だよな」っつってる奴は
その女と付き合ってるわけではない。
- 623 名前：デフォルトの名無しさん mailto:sage [2006/04/29(土) 16:21:55 ]
- そもそもオブジェクト指向が難しすぎ
gotoを使って何が悪いんだ
- 624 名前：デフォルトの名無しさん mailto:sage [2006/04/29(土) 17:17:48 ]
- >>623
それはない。
- 625 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2006/05/24(水) 12:40:01 ]
- で、C++のどこが難しいんだ？
クラスが分からないのか？
- 629 名前：デフォルトの名無しさん mailto:sage [2006/05/24(水) 12:54:45 ]
- >>627
概ね頷けるところだが、
> koenig lookupなんかは、ライブラリの設計ミスを言語仕様側で
> 取り繕おうとして傷口を広げた例だね。
これだけ、聞いた事が無い話だった。
何のこと？
- 630 名前：デフォルトの名無しさん mailto:sage [2006/05/24(水) 13:05:06 ]
- >>627
>後方互換性にこだわらない
ここ同意
- 631 名前：デフォルトの名無しさん mailto:sage [2006/05/24(水) 13:12:19 ]
- 後方互換性は、言語使用の複雑さの原因であることは確かなんだが
普及の速度には大きく貢献してるだろうから、単純に否定できないと思うんだ。
- 632 名前：デフォルトの名無しさん mailto:sage [2006/05/24(水) 15:52:15 ]
- まぁ、実際に携わってみれば誰もが苦しむところだろうな。
- 633 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2006/05/24(水) 20:17:10 ]
- D&Eを読めば嫌と言うほど互換性確保に努めてきた様子がひしひしと伝わってくる。
- 636 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2006/05/24(水) 23:17:26 ]
- >>637
それだと operator+ を定義していないクラスに + を使おうとしたとき、
plus_trais についてのエラーメッセージが出るよね？それもなんかおかしくね？
- 639 名前：デフォルトの名無しさん mailto:sage [2006/05/24(水) 23:25:01 ]
- >>637
わざわざstd::huck::plus_traitsに持っていく意味がわからない。
- 640 名前：デフォルトの名無しさん mailto:sage [2006/05/25(木) 00:19:15 ]
- >>638-639
std::hooksに含まれているテンプレートを部分特殊化してくれって意味。
オーバーロード解決に相当する処理をテンプレートで実装する必要があるから、
現行C++の機能だけで完全に実現できるかは分からんけど、
必要ならコンパイラにいくつか機能を追加すればいい。
- 641 名前：デフォルトの名無しさん mailto:sage [2006/05/25(木) 00:41:39 ]
- >>640
コンパイラに koenig lookup を追加すればいいってことだな。
- 642 名前：639 mailto:sage [2006/05/25(木) 02:39:06 ]
- >>640
その意味はわかるけど意図が判らない。
直接operator +を特殊化すればよいのではないかと思った。
- 643 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2006/05/25(木) 02:47:08 ]
- >>637
より踏み込んだ議論として，そもそも hook の所有権・所在の
あり方に関する議論もあります．
特殊化に基づく hook の提供の場合，特定の名前空間に hook の所在が
固定されますが，それはそもそも正しいのか？
全く関係の無いサードパティが提供するヘッダとプライマリテンプレートに依存し，
その名前空間を開けて hook を提供しなければならなくなる状況も想定され，
それは本当に正しいのか？という疑問です．
そういう意味では ADL による hook があらゆる名前空間を
潜在的にぶち破る特性を逆手にとって，
「大域の ADL hook 用名前空間 （global ADL namespace） に hook をおく」と
考えることも， hook の所在の中立性という観点からは
あるいは悪くないともいえます．
少なくとも「ライブラリ設計の欠点とその補完としての ADL」という観点は
少し視野が狭すぎるような気がします．
- 645 名前：デフォルトの名無しさん mailto:sage [2006/05/25(木) 03:00:06 ]
- >>642
operator+ には特殊化するべきプライマリテンプレートがそもそもないです．
また，関数テンプレートの部分特殊化が現行規格に存在しないために，
一般にクラステンプレートに対して関数テンプレートを特殊化することができない，
という事情もあります．クラステンプレートの静的メンバ関数を
わざわざ持ち出すのは，関数テンプレートの部分特殊化の
エミュレーションのためだと思ってもらえれば良いかと思います．
- 646 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [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用名前空間を１ヶ所用意して、
特殊な動作は全部そこに書く/書かせるということと同じでしょう。
もちろん名前空間の内部が第三者によって手を加えられる（特殊化ではなく）という問題はありますが。
- 649 名前：デフォルトの名無しさん mailto:sage [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 mailto:sage [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 mailto:sage [2006/05/25(木) 14:55:55 ]
- よく考えてみたら、ADLがない場合には
two phase lookupの挙動が変わりそうな気がしてきましたが
そこまでは考えていませんでした。
- 652 名前：デフォルトの名無しさん mailto:sage [2006/05/25(木) 16:19:50 ]
- >>650
plusからはcomplexのoperator+は見えるけどvalarrayのoperator+は見えない。
646で書いたlazyoverloadというのはoperator+を全部見てくれという意味。
- 653 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2006/05/26(金) 01:10:18 ]
- >>655
>現在、boost.rangeなどで使われているものがあります。
>lazyoverloadによる結果と違うのは、
>fundamental type用のフックが定義できるかどうかということでしょうか。
あと、フック関数の定義される場所が
１ヶ所の名前空間になるか(lazyoverload)
複数の名前空間にまたがるか(boost.range)ということでも違いますね。
- 657 名前：デフォルトの名無しさん mailto:sage [2006/05/26(金) 01:38:15 ]
- >>655
> そのコードでは、nnn::good<char>()も0を返すはずです。
これですね。勉強になりました。
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 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 02:46:35 ]
- 個人的にはこれらの問題は C++ の言語規格あるいは
C++ のライブラリ設計を原因とする固有の問題だとは思っておらず，
（C++ の）汎用プログラミングにおいて非常に重要で魅力的な特性である
"non-intrusiveness" を成立させつつ，なおかつ hook をどう提供するか，
を考える上でかなり本質的な問題だと思っています．
将来的な言語機能の追加も視野に入れてよいならば，例えば
コンセプトに基づく特殊化・オーバーロードといった C++0x での
機能追加があるいは問題解決の1つの糸口になるのではないかと
個人的には思っています．
- 662 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 07:30:03 ]
- ドラゴンボールにたとえてもう一回プリーズ
- 663 名前：デフォルトの名無しさん [2006/05/27(土) 10:42:33 ]
- 神様、宇宙人、人造人間、とさらに強い敵を出すために世界観が滅茶苦茶。
技もどんどんインフレになっていき、何が強くて何がよわいのか、序列や使い方
が良くわからん。つまりドラゴンボール状態。
C++ is Dragon Ballというのは、アメリカのカンファレンスで良く聞くジョークでも
ある。
- 664 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 14:27:51 ]
- （拍手）
- 665 名前：デフォルトの名無しさん [2006/05/27(土) 17:59:55 ]
- よく聞くのかよ
- 666 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 21:39:59 ]
- 毎日な
- 667 名前：デフォルトの名無しさん [2006/05/28(日) 23:12:30 ]
- 『ゴクウが教えるC++』という書籍では、継承を説明するのに、サイヤ人←スーパーサイヤ人と
いう誰でも思いつきそうな例で説明されているらしい。
- 668 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 23:18:13 ]
- 例えで説明してもらわなくても、シンプルなソースと実行結果があれば概念なんて直ぐわかっちゃうのに。
例えての説明で一番分かってもらえるのは、既に知っている人なんだけどな。
しかもC++はあまり難しくないと言う罠。
- 669 名前：デフォルトの名無しさん mailto:sage [2006/06/02(金) 06:35:13 ]
- C++の難しさはbetterCとしても使えてしまうところじゃないか？
結局のところ、それでもかなりのことが行えるので、それで満足してしまって
C++の本域や可能性を見失ってしまう。
まぁ、STLにしてもほかのBoot（？）にしてもこれらを使いこなせるようになる前に
大概のことは楽にやってのけられるし、
これらを学んでも実践にどこまで投入していいか？の問題もある。
あと、Cの影響力が強すぎてC時代の財産とかが未だに尾を引いているのかもしれない。
（周りの人間との統合性とかを考えるとやっぱり Better Cぐらいが一番能率がいいのかもしれないし。）
- 670 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2006/06/09(金) 17:11:22 ]
- >>672
マルチ氏ね
- 674 名前：デフォルトの名無しさん mailto:sage [2006/08/15(火) 17:53:21 ]
- Javaは引数の参照渡しができない
とんでもない駄作
- 675 名前：デフォルトの名無しさん mailto:sage [2006/08/15(火) 19:52:10 ]
- >>674
そーゆーこはJava厨が沢山居そうなスレにageで書き込みなさい。
- 676 名前：デフォルトの名無しさん mailto:sage [2006/12/26(火) 18:42:28 ]
- C++のマニピュレータはどこもマネしないくらい最強
- 677 名前：デフォルトの名無しさん mailto:sage [2006/12/26(火) 18:57:45 ]
- あれ使ったことない
難しいというか・・・鬱陶しいというか・・・
- 678 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 02:07:53 ]
- アレはどっちかっていうと単にインターフェイス的にもパフォーマンス的にも
駄作(というか失敗作？)だから、みんなにそっぽ向かれただけ。printfマンセー！
- 679 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 18:56:34 ]
- まああれはあれで、使いようによっては有用で便利なんだが
vector<int> vec_int;
・・・中略
cout << vec_int / "," % 3 << endl;
たとえばこれで、vec_intの中身全部を
一行に３要素ずつ（ % 3）、カンマで区切って（ / "," ）
出力なんてことをやったりできる
- 680 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 18:58:18 ]
- ああ↑はあくまで、こういうマニュピュレータを自分で定義したら、という話ね。
- 681 名前：デフォルトの名無しさん mailto:sage [2006/12/30(土) 01:44:13 ]
- そもそもstd::endlもマニピュレータだということを知らない人がかなり多い
- 682 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 12:09:20 ]
- ライブラリに優劣があるのは仕方ない
iostreamは行き過ぎた抽象というやつかな
ファイルなんかランダムアクセスでいいんだよバカやろう
的なのが提案されてる
ともかくいまさらbindを取り込むDは不憫
- 683 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 12:31:17 ]
- streamの名前の通りに素直に考えた設計だと思うけどね。
iostreamの出力をiostreamで読み込む。これは簡単。
問題は既存のファイルや人が読みやすいファイルがstreamとして扱いやすいかということだろうよ。
- 684 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 14:45:01 ]
- iostreamは真似しちゃいけない設計の見本のような気がする。
- 685 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 18:07:40 ]
- 後のSTLともあまり噛み合ってないからな・・・。
- 686 名前：デフォルトの名無しさん mailto:sage [2007/01/09(火) 12:26:43 ]
- >>679
>カンマで区切って（ / "," ）
「<<」、「>>」で感性がマヒしてると、こういう
変態的な演算子を定義しちゃうようになるんでしょうか。
- 687 名前：デフォルトの名無しさん mailto:sage [2007/01/09(火) 22:39:57 ]
- templateとBoostで麻痺してるせいか
この程度は、きわめて直感的でわかりやすいと
自分では感じるんだが
まああれだ、素人はだまってろ
- 688 名前：デフォルトの名無しさん mailto:sage [2007/01/09(火) 23:30:20 ]
- まあでも他人と共同で書くときには控えようかなと思うよ、俺は。
- 689 名前：デフォルトの名無しさん mailto:sage [2007/01/09(火) 23:49:14 ]
- 俺も、なんか気づいてみたら趣味で書いてる時と、仕事で書いてる時のコードに
とても同じ人物が書いたとは思えないようなギャップが発生している。
・・・ゴメン、本当は仕事で書いてるコードも基礎部分が極端にトリッキーなコードになってる。
- 690 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 18:48:59 ]
- C++にclassって必要なの？
structで充分だろ
- 691 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 19:24:31 ]
- >>690
そう思うなら使わなければよろしいのでは?
- 692 名前：デフォルトの名無しさん [2007/02/28(水) 06:53:06 ]
- CとC++じゃ明らかに生産性が違うよ
- 693 名前：デフォルトの名無しさん [2007/02/28(水) 07:00:11 ]
- えっ、そうなんですか、つまり 生産性は C >> C++と
- 694 名前：デフォルトの名無しさん [2007/02/28(水) 21:44:20 ]
- C++は再利用性が高くてメンテナンスも容易
オブジェクトを組み合わせるだけでほとんど完成する
- 695 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 00:25:38 ]
- C++は１ヶ月も見てないととたんに忘れるな･･･
- 696 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 02:12:03 ]
- スクリプト言語からC++に戻ってくると、
通常型とポインタと参照があることに安心する。
- 697 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 17:27:52 ]
- あるあるｗｗｗｗ
- 698 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 23:55:34 ]
- >>694
ツリ?＿
- 699 名前：デフォルトの名無しさん mailto:sage [2007/03/04(日) 01:38:17 ]
- >>690
十分といえば十分ですね
まったく同じ子とできるわけだから
- 700 名前：デフォルトの名無しさん mailto:sage [2007/03/08(木) 22:08:43 ]
- コンテナクラスの継承ﾏﾝﾄﾞｸｾ
- 701 名前：デフォルトの名無しさん mailto:sage [2007/03/09(金) 00:00:58 ]
- std::vectorとかか？
あれは継承するような存在ではないから面倒で当然だ。
- 702 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 02:46:25 ]
- >>684
具体的には?
istreamとostreamがiosを仮想継承して
iostreamがistreamとostreamを多重継承しているところとか?
- 703 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 13:03:47 ]
- >> と << の気持ち悪いオーバーロードとかもかな。
- 704 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 13:52:26 ]
- マニピュレータを新しく作るにしても
istream, ostream, iosを修正しなくてもできるの?
- 705 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 14:23:27 ]
- >>704
できるよ。
やりかたよくわからないけど。
- 706 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 15:13:16 ]
- わからんのに言うなーー
- 707 名前：デフォルトの名無しさん [2007/03/24(土) 18:12:59 ]
- C++の印象：
一貫性より無節操さかな。その無節操なところが難解にさせてるね。
無節操だと思うところは、オブジェクト指向にしても、ジェネリック
プログラミングにしても同じ統一した法則の元で成り立ってないわけで
それが複雑怪奇にさせているという指摘。
オブジェクト指向にジェネリック系の考えを入れてプログラミングを
すればわかるけど、よほど注意深く作っていかないとスパゲティになっ
てしまう。それだけバグ取りが難解になり易い弱点を持ってるね。
バグ取りだけじゃなくて、コーディングに時間がかかるね。効率的な
作成はまず不可能だと考えていいよ。javaでも最近テンプレート的な
動きがあるようだけど、あれは自滅の方向かもしれませんよ。
要するに余計なところばかりに神経を使って作らないといけなくなる
事がC++の問題点だと思うね。慣れたから大丈夫というレベルを超え
ちゃってるんで。
- 708 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 18:38:17 ]
- >>707
直行してる概念を組み合わせても混乱は無いはずなんだが。
オマエのプログラムがスパゲッティになったのを誰かのせいに
したいだけに見えるぜ。
- 709 名前：デフォルトの名無しさん [2007/03/24(土) 18:47:09 ]
- >>708
???
- 710 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 19:03:22 ]
- インターフェイス実装目的以外での継承禁止
|
 |
