- 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/
- 552 名前：デフォルトの名無しさん mailto:sage [2005/04/28(木) 18:04:09 ]
- >551
俺にはそっちの方がムズい…
- 553 名前：デフォルトの名無しさん mailto:sage [2005/04/29(金) 02:10:38 ]
- BCBのヘルプに
「alloca 関数の使用はあまりお勧めできません。」
って書いて有るんですけど、そうなんですか？
- 554 名前：デフォルトの名無しさん mailto:sage [2005/04/29(金) 09:14:17 ]
- >>553
スタックを食い潰すし、移植性に乏しいからでは?
- 555 名前：デフォルトの名無しさん mailto:sage [2005/04/29(金) 10:02:13 ]
- C99ならVariable Length Arraysを使ったほうが良いかと。
- 556 名前：デフォルトの名無しさん mailto:sage [2005/04/29(金) 17:30:06 ]
- C++ならstd::auto_ptrを使ったほうが良いかと。
- 557 名前：デフォルトの名無しさん mailto:sage [2005/06/02(木) 20:59:36 ]
- 仮想関数を使えばswitch-caseの嵐から抜けられるわけで、個人的にはそれだけで大満足です。
- 558 名前：デフォルトの名無しさん mailto:sage [2005/06/02(木) 23:37:01 ]
- >557
だね。場合分けをすることなしに、異なる振る舞いを事前に記述して、コンパイラ任せにできる
有利性、というか。
でも、その有利性を理解できない層というのも確実にあって、それは何かっつーと、
仮想関数という概念、というか言語仕様を知らない層なんだよね。C++はもちろん、
Javaも知らないという層。switch-caseで、あり得る場合分けが全部ソース上に
明記してあった方が判りやすいしデバッグしやすいじゃん、と主張してきそうな、
えてしてそういう層が実装仕様を決めやがるんだよなあ。おっとこれはグチだな。すまん。
誰か強力に布教してくんねーかな。俺はもー疲れた。
- 559 名前：デフォルトの名無しさん mailto:sage [2005/06/03(金) 05:12:20 ]
- >>558
無理。そういう層は大抵「学習意欲」＜「日々の仕事をこなすこと」だから。
- 560 名前：デフォルトの名無しさん mailto:sage [2005/06/03(金) 11:21:57 ]
- switch-case の代わりとしての仮想関数なら C でも出来るわけで。
- 561 名前：デフォルトの名無しさん mailto:sage [2005/06/03(金) 11:26:56 ]
- >>560
だからどうした？
- 562 名前：デフォルトの名無しさん mailto:sage [2005/06/04(土) 00:16:50 ]
- C++儲のおいらでも560には半分同意。
switchの代わりなら構造体+関数ポインタでも
それほど労力がふえるとも思えない。
勿論、仮想関数の方が楽なのは事実だけど。
むしろ、Cで困るのはコンストラク・デストラクタ・templateがない事。
auto_ptrを見ても分かるようにデストラクタが非仮想であっても、
templateと組み合わせればものすごく便利になる。
これが無い故に生成と破棄がセットになったリソースを複数作る
処理で、生成失敗時の破棄処理を書いてるとうんざりする。
- 563 名前：デフォルトの名無しさん mailto:sage [2005/06/04(土) 01:28:29 ]
- 要するに、リソースリークを避けるための下らない労力、プログラムの本質
から大きく外れたロジックやコードがCでは多くを占めてしまうってこったよな。
文字列やリストなんて単純なものも、Cでは悩みの種だ。
まあメモリリーク回避だけならGC使う手もあるがなー。
GC使えるような環境なら今時Cなんて使うなよという話もあるが。
- 564 名前：デフォルトの名無しさん mailto:sage [2005/07/13(水) 23:42:53 ]
- この速度ならぬるぽ
- 565 名前：デフォルトの名無しさん mailto:sage [2005/07/13(水) 23:45:51 ]
- >564
ｶﾞｯ!
ちゅーかまたお前かっ！
- 566 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2005/07/31(日) 00:36:05 ]
- >>568
そのメリットは？
- 570 名前：デフォルトの名無しさん mailto:sage [2005/07/31(日) 01:25:38 ]
- >>569
コンストラクタ呼び出しで作った一時オブジェクトでローカル変数を直接初期化できる。
struct S0 { S0(); };
struct S1 { S1(S0 zero); };
int main()
{
S1 x(S0()); // 現行の規格では関数宣言
...
}
- 571 名前：デフォルトの名無しさん mailto:sage [2005/07/31(日) 04:20:58 ]
- >570
S1 x = S0(); で回避できると思うけど、いちいち気にするのがいやってこと？
- 572 名前：デフォルトの名無しさん mailto:sage [2005/07/31(日) 04:45:26 ]
- >>571
その書き方だと暗黙の変換とコピーコンストラクタが必要になる。
S1を↓のようにするとコンパイルできない。
struct S1 { explicit S1(S0 zero); };
struct S1 { S1(S0 zero); private: S1(S1 const&); };
- 573 名前：デフォルトの名無しさん mailto:sage [2005/07/31(日) 05:09:49 ]
- >>569
ブロック内で関数宣言する奴なんて見かけない。みんなヘッダをインクルードする。
570みたいなコードは誰もが最初変数宣言だと思ってはまる。
それだったら全部変数宣言にするほうが、わかりやすいんじゃないかと考えた。
たとえば「ブロック内では関数宣言をしたければexternを付ける必要がある。
externなしで関数・変数宣言どちらともとれるときは変数宣言」とでもすればよかったのにと思う。
- 574 名前：デフォルトの名無しさん mailto:sage [2005/07/31(日) 10:32:18 ]
- >>573
Cとの互換性を最優先した結果、なんだろうなあ。
- 575 名前：デフォルトの名無しさん mailto:sage [2005/08/01(月) 12:09:55 ]
- >>570
S1 x((S0()));
()の2バイト分も面倒か？
- 576 名前：デフォルトの名無しさん mailto:sage [2005/08/01(月) 14:22:05 ]
- 対処法の有無はこの話題には関係無いだろう。
- 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+を全部見てくれという意味。
|
 |
