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


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

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



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

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

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」という観点は
少し視野が狭すぎるような気がします.






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

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

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