- 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/
- 577 名前：デフォルトの名無しさん mailto:sage [2005/08/02(火) 00:55:12 ]
- >576
その対処法によって、570のいう、
> コンストラクタ呼び出しで作った一時オブジェクトでローカル変数を直接初期化できる。
ことができない(実際にはできる)という、現行規格への不満が解消されるのだから関係ある。
まぁ570が、一時オブジェクトをローカル変数のコンストラクタに渡す文法を知らなかっただけのようだが。
- 578 名前：570 mailto:sage [2005/08/02(火) 01:51:48 ]
- 知ってたよ。
- 579 名前：デフォルトの名無しさん mailto:sage [2005/08/02(火) 03:51:30 ]
- 一見変数宣言に見えてしまうややこしさを問題としてるという論点に気付かない>>577を暖かく見守る俺が579ゲットですよ
- 580 名前：577 mailto:sage [2005/08/02(火) 10:28:59 ]
- 結局568の主張は、
とくに機能的な違いはないけど、今の文法は見た目がわかりにくいから、
ブロック内での関数宣言を廃止し、全て変数宣言と見なすという仕様にすれば良かったのに
ってことなのね。
ぱっと見のわかりやすさは重要だと思うけど、もう二重に括弧つける癖がついたんで、どうでもいいかなと思う。
>579 サンキュー。これからも暖かく見守ってください。
- 581 名前：デフォルトの名無しさん mailto:sage [2005/08/05(金) 01:15:34 ]
- このスレの人たちは英文をバリバリに読めるのか？
俺全然読めない。
- 582 名前：デフォルトの名無しさん mailto:sage [2005/08/05(金) 06:24:21 ]
- 英語しかなければ読むけど、ちょっと下手という程度なら日本語に喜んで飛びつきますが何か。
規格だってISOではなくJISの訳を読むし。
- 583 名前：デフォルトの名無しさん mailto:sage [2005/08/05(金) 10:31:42 ]
- キチガイ翻訳はお断りだが
- 584 名前：デフォルトの名無しさん mailto:sage [2005/08/08(月) 16:18:38 ]
- >>583
じゃお前が翻訳してくれ
- 585 名前：デフォルトの名無しさん mailto:sage [2005/08/08(月) 18:40:15 ]
- それが出来りゃ原書読むわい
- 586 名前：デフォルトの名無しさん mailto:sage [2005/08/15(月) 09:49:34 ]
- 糞 ス レ 勃 て て ん じ ゃ ね え よ 脳 挫 傷 ！
- 587 名前：デフォルトの名無しさん mailto:sage [2005/08/15(月) 12:19:58 ]
- >>586
今頃何言ってんの？m9(ry
- 588 名前：デフォルトの名無しさん mailto:sage [2005/08/15(月) 13:32:23 ]
- ﾌﾟｷﾞｬ（ｒｙ
- 589 名前：デフォルトの名無しさん [2005/09/03(土) 20:06:30 ]
- OSのベータ版を市販するやり方は
どこにもマネできないくらい最強
- 590 名前：デフォルトの名無しさん mailto:sage [2005/11/21(月) 20:30:09 ]
- JavaScriptは難しすぎ
pc8.2ch.net/test/read.cgi/hp/1132400636/
- 591 名前：デフォルトの名無しさん mailto:sage [2005/11/28(月) 14:52:04 ]
- ポインタと参照を混ぜるとややこしいから、ポインタで統一してるんだけど
参照しか使えない場合もあるしなんなんだよ！！
- 592 名前：デフォルトの名無しさん mailto:sage [2005/11/28(月) 15:29:17 ]
- 俺はなるべく参照を使って、仕方ない時だけポインタを使う
- 593 名前：591 mailto:sage [2005/11/29(火) 14:48:00 ]
- あっそうかスマートポインタ使えばいいんだって使ってるプロジェクト
見たことねえorz
- 594 名前：デフォルトの名無しさん [2006/01/04(水) 11:55:46 ]
- もっともっと難しくなって構わないから早く来いC++0x。
なんてこのスレで言うとぼこぼこにされそうだ。
- 595 名前：デフォルトの名無しさん mailto:sage [2006/01/06(金) 00:21:22 ]
- C#に慣れてきたらC++触るのﾃﾗダルくなってきた…
つーか、同じVisualStudioなのにエディタの出来があからさまにVC#＞＞＞＞＞＞VCなのは何の嫌がらせだよ
- 596 名前：デフォルトの名無しさん mailto:sage [2006/01/06(金) 00:35:56 ]
- >>595
(ﾟ∀ﾟ)人(ﾟ∀ﾟ)ﾅｶｰﾏ
- 597 名前：デフォルトの名無しさん [2006/01/08(日) 01:29:03 ]
- >>595
Ｃ＃はＭ＄が作った言語だからＪａｖａ、Ｄｅｌｐｈｉ潰しをしながら
普及のために本気にならんといかんのだよ
Ｃ＋＋についてはＭ＄の都合におかまいなく拡張されたりするから
ほんとはサポートすんのヤなの
だけどＣ＃がコケた時の保険のつもりで一応サポートしとくの
これが戦略。わかる？
ほんとはＣ＃、ＶＢで世界を支配したいの
あとはオマケ
- 598 名前：デフォルトの名無しさん mailto:sage [2006/01/08(日) 03:30:39 ]
- >>597
2バイト文字使うなら
せめて♯を使えよと。
- 599 名前：デフォルトの名無しさん mailto:sage [2006/01/08(日) 19:48:58 ]
- エディタはEmacs系を使えばいいのだ、勝手に補間するVSの親切エディタとは手を切れ、
あれは人を堕落させる。
- 600 名前：デフォルトの名無しさん mailto:sage [2006/01/09(月) 00:59:30 ]
- >>595
言語仕様が複雑でC#よりﾏﾝﾄﾞｸｾからじゃないかなあ。
- 601 名前：デフォルトの名無しさん mailto:sage [2006/01/09(月) 21:15:09 ]
- >>595
なんか、MSはC#を無理やり推し進めている感じだしね。
FXではWIN32 API呼ぶのにオーバーヘッドがあるようだし・・・
- 602 名前：デフォルトの名無しさん mailto:sage [2006/01/11(水) 23:05:13 ]
- つーかアプリのパフォーマンスにAPIのオーバーヘッドなんざ
ほとんど関係ないと思うが。処理の9割以上は自分のコード
の中だろ？
- 603 名前：デフォルトの名無しさん mailto:sage [2006/01/13(金) 12:29:12 ]
- だから、３０歳過ぎて、社会の政治的な要因に太刀打ちできるような
立場になってからもデザインパターンみたいな一技術で重宝されるような
人物に対して「逃げ道だよな」って言ってるの。２０代の奴がやりたくてもできないような
ところで自分をアピールする術を持ってないのかって。
中堅者のやることっていったら、２０代の奴が仕事をしやすいように、いろいろと根回しすることだろ？
年齢重ねても、やることが２０代の延長だったら会社に居る意味ねーよ。
スパゲティコードだとか、その辺は中堅社員が口出すことじゃねーって。
むしろ、２０代の奴が気付いて、中堅社員に意見をＵＰして、それから中堅社員が根回しするのが理想。
要は、いい歳こいて低レベルな話してんじゃねーよって。もっと抽象的になれってことだ。
- 604 名前：デフォルトの名無しさん mailto:sage [2006/01/13(金) 13:44:16 ]
- >>603
> だから
まで読んだ。
- 605 名前：デフォルトの名無しさん mailto:sage [2006/01/13(金) 18:34:11 ]
- >>603
日本語でおｋ
- 606 名前：デフォルトの名無しさん mailto:sage [2006/01/14(土) 03:46:11 ]
- 日頃誰にも吐き出せず溜め込んでいたモノを一気に吐き出したようだが、
そうやって長年熟成させてきた割には深みゼロなのが哀しいね。
まぁ、この程度の頭だから、誰にも認められずストレス溜めてるんだな。
- 607 名前：デフォルトの名無しさん [2006/01/14(土) 13:09:20 ]
- >>603
デジャブか。
どっかでみたレスだ。
- 608 名前：デフォルトの名無しさん mailto:sage [2006/01/16(月) 18:52:13 ]
- >>606
では君が深みのある話をしてくれ。ぜひ読みたい
- 609 名前：デフォルトの名無しさん mailto:sage [2006/01/17(火) 11:53:19 ]
- >>608
「では」の使い所が変ですね。
- 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 ]
- あれ使ったことない
難しいというか・・・鬱陶しいというか・・・
|
 |
