【C++】template 統合スレ -- Part6

【C++】template 統合 ..

607:デフォルトの名無しさん
05/05/21 10:35:12
>>606
代償としてイテレータのサイズが大きくなるから、使い道は微妙だけどな。

608:デフォルトの名無しさん
05/05/21 10:43:01
>>606
ふーん。
std::list の実装に使われてるのは見たこと無いんだけど、
標準コンテナの実装としては何か問題があるのかな？

と考えたら、イテレータを取得した後に要素の削除・追加をするとマズイような気がした。

609:デフォルトの名無しさん
05/05/21 10:44:00
>>604
リストを変更しないときのコストはたいしてかからないんじゃないか。
簡単なループの場合、movl (%eax),%eax が xorl (%eax),%eax になるだけだろう。

>>607
イテレータのサイズなんて問題になることがそうそうあるとは思えんが。

前後に追加削除があるとイテレータが無効になってしまうから
std::listとはコンパチにならなくなることの方がまだ問題になりそうだ。

610:604
05/05/21 10:50:55
>>607
イテレータのサイズとリンクリストに保持される各要素のデータサイズを同列で比較するのもどうかと思うが。

イテレータにポインタを2つほど追加したところで、8バイトしかサイズは増えない。
（処理が複雑化する分、イテレータオブジェクトのサイズはもう少し増えると思うが。）
しかし、双方向ポインタにしてしまうと、各要素毎に4バイトの投資が必要となる。

611:604
05/05/21 10:58:43
>>608 >>609
確かにイテレータの取得後に前後の要素が追加削除されると痛い。
排他制御の問題を抱え込むから、std::list との互換性は考えない方が吉かと。

612:デフォルトの名無しさん
05/05/21 11:12:46
>>609
> 簡単なループの場合、movl (%eax),%eax が xorl (%eax),%eax になるだけだろう。

訂正。これ間違い。xor+mov*2(or xchg)になるな。

613:デフォルトの名無しさん
05/05/22 00:18:22
> サイズは可変で大きい、挿入削除が定数時間(->list)、省メモリ(->vector)
データの格納にset使うのってやっぱダメなのか？
setの中身はconst扱いだけど、外してswapして取り出して消して使ってるけど。
挿入時もヌルデータ入れて跡で要素をswapしてるんで無駄なコピーも出ない用に工夫して、、、
、、、、

vectorはサイズ増えると勝手に自分のコピー作るんで、reserveしなきゃならんので嫌だ。
lispは探索が遅いし。mapはそんなものに使うのもったいないし。

結論　：　set使え！

614:デフォルトの名無しさん
05/05/22 00:31:16
setが泣いてるぞ

615:デフォルトの名無しさん
05/05/22 00:31:37
listのメモリ効率が気になるような状況でsetなんか使えるかよ
つーか、dequeって要素へのアクセスもそこそこ速くサイズ変更のコストも最小限なのになんで使われんのか。

616:デフォルトの名無しさん
05/05/22 03:41:02
>>615
dequeって要素へのアクセスもそこそこ速く
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
環境によってはlist並みに遅いわけですが何か？
OSやCPUは敢えて書かないが、STLportとかSTLportとかSTLportとか。

617:デフォルトの名無しさん
05/05/22 06:50:59
>>606
C++ でポインタにビット毎の論理演算なんて
吉外じみた真似、よく平気で出来ますね。

618:604
05/05/22 08:36:41
>>617
坊やだな、、、
ポインタと言えど所詮はビット列なのだよ。

619:デフォルトの名無しさん
05/05/22 08:39:59
>>618
reinterpret_castとか使わないといけないんだろ？
環境依存イクナイ(・A ・)！

620:デフォルトの名無しさん
05/05/22 08:55:43
>>606
面白いなぁ

621:604
05/05/22 08:55:52
>>619
reinterpret_castが即、環境依存につながるとは新鮮な考え方だな。
同じ環境内でキャストして、同じ環境内で元に戻すのであれば、環境依存も何もないだろうに（それを環境依存というのなら、コンパイラが吐くコードはすべて環境依存になるぞ）。
それとも、そういうことすら期待できない処理系が現存するというのか？
（そんなのが出てきた時点で reinterpret_cast は言語仕様から外されるだろうて。）

622:デフォルトの名無しさん
05/05/22 09:07:29
>>621
愉快な香具師だなお前。
C++の実装と進化の§14.3.3(P420)読んでみろ。

623:デフォルトの名無しさん
05/05/22 09:09:30
>>622
○C++の設計と進化
×C++の実装と進化

それから、規格票を優先しろ。

624:604
05/05/22 09:17:26
その本は持ってない。
引用の範囲内だろうから、出典を明記して引用してくれ。
内容を咀嚼して説明してくれてもよいぞ。

625:620
05/05/22 09:35:20
俺の面白いは純粋な意味であって、622と同じ意じゃないですよ

626:デフォルトの名無しさん
05/05/22 09:38:55
5.2.10 Reinterpret cast

4 A pointer can be explicitly converted to any integral type large enough to hold it.
The mapping function is implementation-defined [Note: it is intended to be unsurprising
to those who know the addressing structure of the underlying machine. ]

5 A value of integral type or enumeration type can be explicitly converted to a pointer.
A pointer converted to an integer of sufficient size (if any such exists on the implementation)
and back to the same pointer type will have its original value; mappings between
pointers and integers are otherwise implementation-defined.

要するに規格としてはポインタ型を整数型にreinterpret_castして
その値をそのままポインタ型に戻す操作以外は完全に実装依存

627:604
05/05/22 09:57:53
「5.2.10 Reinterpret cast」の真意は、整数型にキャストし、演算後の《変更された値》をポインタにキャストし戻したとしても、それはポインタとして無効であるということだけだと思うぞ。
一例を挙げると、配列の特定要素を指すポインタを整数型に変換した後、インスタンスオブジェクトのサイズ分だけ値を加算し、ポインタ型に戻したとしても、次の要素へのポインタにはならないぞ、、、という。

Magic listにおける A-B-C という例において、Bに保存されている値はAのアドレスとCのアドレスを特定のルールで「エンコード」しただけの整数値であり、デコードすることにより元々のポインタ値を復元することが可能なはず（てーか復元できなければ意味はない）。
このため、上記の§5.2.10の規則には抵触しないと思うが？
むしろ「A pointer *can be* explicitly converted to any integral type」と書かれている以上、そのことが保証されているとも取れる。

integral typeにして何の演算も許さず、元のポインタに戻すことしかできないのであれば、そもそもキャストする意味ないし。　まさかシリアライズするのか？、、、ってそれはあまりにも危険だしな。

628:デフォルトの名無しさん
05/05/22 10:18:14
>>626
ん?問題ないんじゃない?

同じポインタからは同じ整数になり、
同じ整数からは同じポインタになるっていう射影だよね。
この規格表のいいたいところは要するに、
アドレスが16違っている2つのポインタを、
整数に直した時も16違っているかどうかはわからないよ、
というだけの話じゃん。

629:626
05/05/22 10:20:55
>>627
＞Magic listにおける A-B-C という例において、Bに保存されている値はAのアドレスとCのアドレスを特定のルールで「エンコード」しただけの整数値であり、デコードすることにより元々のポインタ値を復元することが可能なはず（てーか復元できなければ意味はない）。
＞このため、上記の§5.2.10の規則には抵触しないと思うが？
＞むしろ「A pointer *can be* explicitly converted to any integral type」と書かれている以上、そのことが保証されているとも取れる。

5.2.10/5はポインタを整数にreinterpret_castした後，その整数値を「そのまま何の演算も行わずに」
元のポインタ型に再度reinterpret_castした場合，元のポインタ値に復元されることを保証するものです．
604さんのmagic_listでは排他的論理和演算を取るため「そのまま」ではないものの
5.2.10/5は明らかにreinterpret_castによるpointer <-> integerの1対1写像を保証しているものと
読めるため確かにそのとおりですね．626は621に対する指摘のつもりでしたが，
いやはや指摘がまったく見当違いどころかむしろ621が正当である根拠になりえますね．
これまた大変失礼しました．

>>628
上に同じです．失礼しました．

630:デフォルトの名無しさん
05/05/22 12:18:47
magic list はネタとしては面白いが、現実には滅多に使われない
データ構造だな。この手のネタは Hakcer's Delight とか Knuth
センセの本を読むとイロイロ転がってるよ。

あと、現実のプログラミングだと、list に int 一個だけ入れるのも
珍しい気がする。手元のコードをいくつか見直してみたが、わりと
大きめの構造体を繋ぐか、スマートポインタを入れることが多い。
いずれにしてもポインタ二個分のメモリなんて誤差って感じ。

631:デフォルトの名無しさん
05/05/22 13:39:00
珍しいかどうかは、ともかく
メモリ云々行ってた奴は、たぶん初心者だから
初心者の戯言を、あまり真に受けないほうが

632:デフォルトの名無しさん
05/05/23 09:43:55
結論はvector使え、でいいのか？

633:デフォルトの名無しさん
05/05/23 09:54:29
>>632
いい

634:デフォルトの名無しさん
05/05/23 12:40:40
magic list は所詮オナニー

635:デフォルトの名無しさん
05/05/23 18:35:46
ここはジェネリックプログラミングの話題じゃないのか？

636:デフォルトの名無しさん
05/05/24 00:13:26
>>635
テンプレートの話題ですよ。尤も、ｽﾚﾀｲも読めないなら
このﾚｽも読めない可能性、大。

637:デフォルトの名無しさん
05/05/24 03:37:35
暇つぶしに作ってた、ヘボコンパイラは出来上がったから
今度は、マジックリストクラステンプレートでも作ってみようかな
作ったらほしい人いる？

638:デフォルトの名無しさん
05/05/24 08:09:05
>>637 興味はある

639:デフォルトの名無しさん
05/05/24 09:47:05
学術的な興味なら。
ソースより測定結果をみたい。listやvectorとの比較つきで。

640:デフォルトの名無しさん
05/05/24 15:44:00
というか作りかけてる・・・

641:デフォルトの名無しさん
05/05/24 22:41:55
できたら
>>639もぜひ。

642:デフォルトの名無しさん
05/05/24 23:45:11
>>640
637だけど、あなたに任せます

643:デフォルトの名無しさん
05/05/25 01:39:21
小規模だけど多次元配列のポインタがどうしても必要で、newも使いたくないから
std::vector<std::vector< ...> >
とかで書いてみたんだけど、4次元ぐらいからコンパイル時間が凄くかかる。
ま、コンパイル時に何がおきてるか想像すりゃ当たり前といえば当たり前だし、
コンパイル時だけの問題なので気にしなきゃいいんだけど、
環境になるべく依存しないで(boostとかは使えないし、VC,gcc両方通す必要あり)、
効率の良い方法がありまつかね。std::deque使ってもかわらなさそうだし。

644:デフォルトの名無しさん
05/05/25 01:49:02
>>643
その「多次元配列」のインターフェースを必要最小限に絞って、
pimpl なり抽象インターフェースなりでコンパイル単位を分ける。
基本だな。

645:デフォルトの名無しさん
05/05/25 02:06:06
>>644
㌧クス。
pimplイディオムは詳しくないので、Exceptional C++でも読んでみまつ。

646:640
05/05/25 02:46:33
URLﾘﾝｸ(kansai2channeler.hp.infoseek.co.jp)
面倒だったのでBoost使いました．1.32.0が必要です．すいません．
VC++7.1とGCC3.4.2(mingw)でコンパイル確認しています．
勢いだけで突っ走ったので激しく読みにくいコードで申し訳ないです．
イテレータが安定じゃないのでsplice系がイテレータ返さないと
使い物にならないので，イテレータ返すようにしてます．
std::listのインターフェースであと実装していないのはsortと演算子だけです．
でも今日はもう気力残ってません．パフォーマンス測定もしかりです．おやすみなさい．

647:デフォルトの名無しさん
05/05/25 04:02:34
void reverse() // throw()
{
head_ = decode(sentry_.code, head_);
}

感動してしまった。

648:デフォルトの名無しさん
05/05/26 03:43:21
URLﾘﾝｸ(kansai2channeler.hp.infoseek.co.jp)
微妙なバカチョンと例外飛んだときのバグを直しました．多分これで完璧なつもりです．
ただ，相変わらずsortだけ面倒なので実装してないです．
指摘されていたこととは言え，このデータ構造イマイチ利点がぼやけてますね．
特にアラインメントの関係でノードのサイズが普通のリストのそれと
同じになってしまう（32-bitマシンでmagic_list<double>とか）場合もあったりで散々かも．
唯一，647さんが指摘されているように要素順の反転を定数時間でできるのが
大きな特色ですけれど，それがうれしい状況ってあるんでしょうか・・・．

649:デフォルトの名無しさん
05/06/06 11:28:39
質問です。
「具現化によって生成された実体」＝「ユーザー定義ではないスペシャライゼーション」
という理解でいいの？

650:デフォルトの名無しさん
05/06/07 22:08:43
"template テンプレートパラメータ"の意味が理解できないッス。
"Modern C++ Design" P11 の以下のコードなんですけど、

template <template <class> class CreationPolicy>
class WidgetManager : public CreationPolicy<Widget>
{
...
}

ここで template <class> に対して私の頭の中で
シンタックスエラーが発生します
。
template<class T> // ノーマル
template<> // 特殊化
template<class T=int> // デフォルト引数
template<class T, int=10> // 特殊化とデフォルト引数

というシンタックスは理解できています。
template <class> って何者？誰か教えてください。

651:デフォルトの名無しさん
05/06/07 22:12:38
省略されてるだけ。
template <class /*T*/>
class foo;

652:デフォルトの名無しさん
05/06/07 22:27:41
>>651
サンクスです。とすると何らかの型を受け取るけど、
その型の情報は無視するよ、っていうことなんですね。
これをもとにもう一回読んでみます。

653:デフォルトの名無しさん
05/06/07 22:32:56
>>650
int f(int i);
int g(int); // これも脳内エラーが出るか？

654:デフォルトの名無しさん
05/06/08 00:28:08
>>650

例えば､

template< template<class T, class A> class Vector>
struct hoge
{
typedef T value_t;
};

typedef hoge<std::vector> hv_t;

としても、この時点では”T"はまだ決まってないわけだから
名前付けても使えないのです。
無論、”Vector"もこのままでは使えません。

実際の使用には

template< tempalte<class,class> class V>
struct hoge
{
template<class T,class A>
struct bind
{
typedef V<T,A> type;
};
};

typedef hoge<std::vector> hv;
typedef typename hv::template bind<int,std::allo..>::type
のように使うことになりますね。

655:デフォルトの名無しさん
05/06/08 00:31:15
補足ですが､

使えない　== typedefできないということです。

656:デフォルトの名無しさん
05/06/08 00:41:11
>>654-655 とても650の理解を助けるとは思えない。

657:デフォルトの名無しさん
05/06/08 01:10:19
間違ったことは言ってないが、質問の答えとしては完全にズレてるな。

658:654
05/06/08 01:22:29
>>656-657

この場合
>"template テンプレートパラメータ"の意味が理解できないッス。
と書いてあるところから、名前云々は関係ないと思うのですが･･

659:デフォルトの名無しさん
05/06/08 10:35:01
>>658 会話になってないな。もういいから喋るな。

660:デフォルトの名無しさん
05/06/08 21:38:27
>>650です。
皆さんありがとうございます。
>>654さんのご意見もとても理解の助けになりました。

661:デフォルトの名無しさん
05/06/09 08:01:15
typedf templateってどうなったの？

662:デフォルトの名無しさん
05/06/09 08:13:16
template< template<class T, class A> class Vector>
struct hoge
{
typedef T value_t;
};
template<class B> typedef hoge<std::vector<B> > hv_t;
typeof(hv_t<int>::value_t) i;

みたいにtypedefの一文をテンプレート化できるんだっけ。

663:デフォルトの名無しさん
05/06/09 08:32:30
>>662
それはだめだろ。
template-templateパラメタのtemplateパラメタ（この場合T）
に言及するのは意味的におかしい。

664:デフォルトの名無しさん
05/06/09 08:43:39
こうじゃないか？

template <typename> struct hoge;
template <template <typename, typename> class V, typename T, typename A>
struct hoge<V<T, A> >
{
typedef T value_t;
};
template <typename T> typedef hoge<std::vector<T> > hv_t;
hv_t<int>::value_t i;

665:デフォルトの名無しさん
05/06/09 08:49:01
typedef templateを導入するなら変数templateや名前空間templateも欲しい。

と無責任に言ってみるテスト。

666:デフォルトの名無しさん
05/06/09 08:56:13
>>664
あーなるほど。C++よく分らないから適当に書いてみたんだけどそれなら理解できるｗ

>template <template <typename, typename> class V, typename T, typename A>
> struct hoge<V<T, A> >
こうやって部分的特殊化で各パラメータ間の関係を表現できるのね。

>>663
>template <typename T> typedef hoge<std::vector<T> > hv_t;

問題はこの部分で、パラメータvector<T>の高階性(?!)を維持してくれるのかどうかってところかねえ。

>>665
変数templateとはどんなもんでしょ？

667:デフォルトの名無しさん
05/06/09 11:34:08
もしも変数テンプレートがあったとしたらこんな感じ?
template <typename T> const T *NULL = 0;

int *pi = NULL;
char *pc = NULL;

#include <cstdio>
int main() {
　 std::printf("%p", NULL<void *>);
}

668:デフォルトの名無しさん
05/06/09 11:59:30
>>667
>int *pi = NULL;
>char *pc = NULL;
これを許すとまた規則が複雑になるな。

669:デフォルトの名無しさん
05/06/09 12:14:33
class null {
public: template<typename T> operator T*() const { return 0; }
};

const null NULL;

int *ip = NULL;
char *cp = NULL;

printf("%p", (void*)NULL);

でいいような気がす

670:デフォルトの名無しさん
05/06/09 12:16:52
誰もそんな話ししてないわけだが

671:デフォルトの名無しさん
05/06/09 13:24:53
>>667
引数とるコンストラクターはどうなるんだ。

672:デフォルトの名無しさん
05/06/09 13:52:48
typedef template ムチャ欲しいな。

673:デフォルトの名無しさん
05/06/09 14:26:04
>>667
今のC++の型の取り扱いにあわせると

template<typename T> const T *NULL = 0;

は，右辺がリテラルの0でこれは型がintだからポインタ型に変換できず，
Tをどの型でinstantiationすれば良いのか判断できずコンパイルエラーになる，
っていう扱いが妥当だと思いますよ．
もうちょい厳密に変数テンプレートを定義しようとすると，
結局，型推論のためのautoキーワードの拡張

auto a = b; // typename(b) a = b; の構文糖

と同じになると思います．Andrew Koenigあたりがこのautoキーワードの代わりに
>>667の構文を提案してたはず．

674:デフォルトの名無しさん
05/06/09 14:35:13
>>673
>>667の代わりに、
template <typename T> struct wrap{static const T *null;};
template <typename T> const T *wrap<T>::null = 0;
と書けることを考えると、今の扱いなら、

・template <typename T> const T *NULL = 0;
の時点では何も起こらない。
・printf("%p" NULL<void *>);
の点でインスタンス化が引き起こされ、void *const *を0で初期設定しようとし、成功。

が妥当じゃないのか？

675:デフォルトの名無しさん
05/06/09 14:50:45
>>670
そうでなくて、必要性が全く感じられないと言っている
まともな利用例ぐらい出さないと

676:デフォルトの名無しさん
05/06/09 14:56:07
>>674
その使い方だと常に明示的にインスタンス化しないといけない
（NULLを利用するたびに型パラメータを与えないといけない）わけですよね？
それは利用範囲が著しく限られませんか？

677:667
05/06/09 15:03:10
ところで俺は変数テンプレートは全く要らないと思うんだけどな。
俺も669と同じようなのを考えたことはあるけど。

678:デフォルトの名無しさん
05/06/09 15:10:28
>>676
使い道がないのは同意。
ただ、仮に現在のテンプレートの延長で「変数テンプレート」なるものを定義するなら、
>>674で言ったようになるはずだと思った。
>>673のような機能を導入するなら別の名前・構文を考えるべきだと思う。

679:デフォルトの名無しさん
05/06/09 15:26:38
型推論はされるとして、
NULLみたいに初期化子に使うとちょっと面白そうな…

クラス階層のあるところでPTHREAD_MUTEX_INITIALIZERみたいなやつ。

680:デフォルトの名無しさん
05/06/09 15:29:21
>>678
確かに「変数テンプレート」という名前は非常にまずいですね．
ただ構文については既存のキーワード使うとするとこれぐらいしかないような気がします．

681:デフォルトの名無しさん
05/06/12 15:01:48
アドビのオープンソースってど？流行ると思う？
STL、boostを基に、ウィンドウをスクリプトから生成する画期的システム
仮想マシンを実現とか、内容は理解を超えていた (つД｀)

いわゆるチョット修正のときに威力を発揮すると思う
SEはどんな些細なこともPGに要望しなけりゃならない
PGは思いつきの修正のために仕事が増えるばかり
だれか人柱になってください、やっぱアドビ待ちなのかな

682:デフォルトの名無しさん
05/06/12 17:16:13
>>681
AdamとEve( URLﾘﾝｸ(opensource.adobe.com) )のことか？なかなか
普及は難しいんじゃないかなぁ…

683:デフォルトの名無しさん
05/06/13 00:40:41
質問です。
BCC 5.5上のテンプレートのバグはどのようなものが
あるのでしょうか。

・・・特に大きいタイプリストを渡すと、他の特殊化に指定
したクラスが別のクラスに化けるとか、そんなのないですか？

684:デフォルトの名無しさん
05/06/13 10:45:49
>>683
質問するときはやりたいこと、実際にやったことを書いた方が良い。

685:デフォルトの名無しさん
05/06/13 14:20:43
>>683
どういうバグかは知らんがboostが満足に使えない。

686:683
05/06/13 21:39:52
自己解決しちゃいました。

経緯だけ説明しますと、Modern C++ Designのマルチメソッドを
自分の使いやすい形に改良して使っていたんです。で特殊化の
際タイプリストを
template<..,class Head,class Tail>struct
Dispatcher<...,Typelist<Head,Tail>,...>{
...省略
};
と展開していて、6ほどの長さのタイプリストをわたしたところエラー吐かれました。
（5つまでは普通にコンパイル＆動作しました）

これを
template<..,class TList>struct
Dispatcher<...,TList,...>{
...省略
};
としHeadにアクセスするときTList::Head,Tailにアクセスするときは
TList::Tailとするようにしたら今度は何十の長さでもコンパイルできました。

前者のコンパイルの仕方にバグがあるんでしょうかね・・・

687:デフォルトの名無しさん
05/06/13 23:51:10
BCCなんか使うなよ

688:デフォルトの名無しさん
05/06/14 17:45:57
もしかして、クラステンプレートのメンバ仮想関数って勝手に実体化される？

689:デフォルトの名無しさん
05/06/14 17:58:42
>>688
どんなコードでそう思った？

690:688
05/06/14 18:10:23
ものすごく単純化すると、
class base
{
public:
virtual void foo() = 0;
};
template <class> class derived : public base
{
public:
virtual void foo() { std::cout << "呼ばれた\n"; }
};
int main()
{
derived<int> d;
static_cast<base&>(d).foo();
}
こんな感じ。

691:デフォルトの名無しさん
05/06/14 18:24:16
>>690
それってderived<int>型の変数dを宣言したからderived<int>が実体化されているだけのように見えるが。

692:688
05/06/14 18:28:53
derived<int> が実体化されるのと
derived<int>::foo が実体化されるのは別じゃないですか？
クラステンプレートのメンバって呼ばれるまで実体化されませんよね？

693:デフォルトの名無しさん
05/06/14 18:31:57
>>688
規格では詳しくは規定されていないっぽい。
実際は
・derived<int>のインスタンスが宣言された
・derived<int>*からbase*の変換が行われた
のいずれかをトリガとして、仮想関数をすべて実体化することになると思う。

694:688
05/06/14 18:40:33
>>693
サンクス。未定義ってことですか。
一応、明示的に実体化しておいたほうがよさそうですね。

695:デフォルトの名無しさん
05/06/14 18:47:45
>一応、明示的に実体化しておいたほうがよさそうですね。
なんでそうなる？

ついでに、「未定義」と「未規定」は違う。

696:688
05/06/14 18:50:17
ん？
規定はされていなくても、正常に動くことは保証されているってことですか？

697:693
05/06/14 18:57:55
言い方が不正確だったな。
規格には、「メンバ関数は、その定義が必要とされるとき実体化される（意訳）」とある。
で、virtual関数については、いつ「定義が必要とされる」か正確に規定している部分が（俺の見た限りでは）なかった。
従って、virtual関数の正確な実体化のタイミングは規定されていないことになる。
それでも、「必要」になり次第実体化されることは保障される。

698:688
05/06/14 19:22:06
あー、なるほど。
規定されていないのは実体化されるタイミングだということですね。
どうもありがとうございました。

699:デフォルトの名無しさん
05/06/26 18:25:16
int k = 0;
for (vector< set<int> >::iterator it = v.begin(); it != v.end(); ++it)
it->insert(k++);

を boost::lambda か何かを使って for_each でシンプルに書けませんか？
メンバー関数に bind する仕方がよく分からないんですが・・・

700:デフォルトの名無しさん
05/06/26 19:33:36
>>699
typedef std::set< int > set_type;
typedef std::vector< set_type > vector_type;
void f( vector_type& v )
{
　using namespace boost::lambda;
　int k = 0;
　std::for_each(v.begin(), v.end(), (protect(bind((std::pair<set_type::iterator,bool> (set_type::*)(int const&))(&set_type::insert), _1, var(k)++)))(*_1));
}

○ boost::lambda か何かを使って
○ for_each で
× シンプルに

701:700
05/06/26 19:49:39
メンバ関数に限らず、オーバーロードが絡むと lambda は使いにくいな。

702:デフォルトの名無しさん
05/06/27 06:52:07
protect要るか?

>>701
C++は名前が重なった場合の簡潔な指名定方法がないしね。
lambdaに限らず面倒。
typeofがBoostに入るそうだから、そのうち頑張って改善されるといいな。

703:700
05/06/27 07:50:29
>>702
こんな感じで変形していったが、途中のやつの
エラーメッセージがひどくて（数１００行ぐらい出る）、
何がまずかったのかよくわかってない。
× ((*_1)->*insert)(var(k)++)
× bind(insert, *_1, var(k)++)
○ (protect(bind(insert, _1, var(k)++)))(*_1)

704:702
05/06/27 22:11:02
>>703
その3つの最初から間違ってるよ。
for_eachなんだから_1にはイテレータではなく参照が入る。よって
_1をdereferenceする必要はない。

まあ同じなんだけど、俺ならオーバーロードが絡む場合は
メンバ関数の特定を追い出すかな。
void hoge(vector<set<int> >& v) {
　　　　typedef set<int> set_type;
　　　　pair<set_type::iterator,bool>(set_type::*insert)(const int&)
　　　　　　　　= &set_type::insert;

　　　　int k = 0;
　　　　for_each(v.begin(), v.end(), bind(insert, _1, var(k)++));
}

705:700
05/06/28 00:20:42
>>704
うわ、とんでもない勘違いをしていたよ。
ありがとう。

706:デフォルトの名無しさん
05/07/05 14:15:55
URLﾘﾝｸ(d.hatena.ne.jp)
ここに書いてあった
struct Mean
ってどう使うの？　例がないと分からない
functorなのは分かったけど

707:デフォルトの名無しさん
05/07/05 14:27:54
int array[] = {1, 3, 5};
std::vector<double> v = ...;

int ma = Mean<int *>()(array, array + 3);
double mv = Mean<std::vector<double>::iterator>()(v.begin(), v.end());

こんな感じじゃないか？

708:デフォルトの名無しさん
05/07/05 16:19:10
for_eachにかけるものではないのね
でも便利そうｔｈｘ

709:デフォルトの名無しさん
05/07/05 16:25:40
>>707
のとおりにやってみたけど
コンパイル通らなかったよ

710:デフォルトの名無しさん
05/07/05 17:04:14
>>706
> 算術平均を求める Mean を書き直すと以下のようになる
> （もちろん Sum も反復子を使うように変更してあることが前提）

ちゃんとSumもコード書いた？

んで、漏れなら、合計値（累積値）を求めるアルゴリズムaccumulateを使い
平均値は：

void f(vector<double>& m) {
double avg = accumulate(m.begin(), m.end(), 0.0) / m.size();
}

のようにして求めるな。分散・標準偏差、RMSあたりも似たような実装ができる。

711:デフォルトの名無しさん
05/07/06 04:42:18
>>710
わざわざ関数にするのか？
コードの大きさを抑えるのにはいいけど。

712:デフォルトの名無しさん
05/07/06 07:22:20
>>711
しない。入力が何で出力が何か明確にしたかったので、関数形式で書いただけ。
実際に関数にするなら、template、inline、引数にはconst、戻値の型を明記、あたりが必要です。

蛇足で糞コード晒す。
template <typename T>
struct square : public binary_function<T, T, T> {
T operator()(const T& lhs, const T& rhs) { return lhs + rhs*rhs; };
};

double ms = accumulate(m.begin(), m.end(), 0.0, square<double>()) / m.size();
double rms = sqrt(ms);
double stdev = sqrt(ms - avg*avg);

713:デフォルトの名無しさん
05/07/06 08:07:25
STLは連続した、同じような事の繰り返し処理には滅法強いな。

714:デフォルトの名無しさん
05/07/06 20:49:48
>>713
あなたの人生もSTLで簡単になりますよ。

void silly_life(life& your_life)
{
　　struct
　　{
　　　　static int daily(day& d)
　　　　{
　　　　　　d.nebou();
　　　　　　d.nichan();
　　　　　　d.onanu();
　　　　　　d.shigoto();
　　　　　　d.nichan();
　　　　　　d.onanu();
　　　　　　d.neru();
　　　　　　return 0;
　　　　}
　　};

　　std::for_each(your_life.begin(), your_life.end(), daily);
}

久しぶりにtemplate見たよ。。。C#使いづれ～。。。orz

715:デフォルトの名無しさん
05/07/07 00:00:05
それがSTLクオリティ。

語呂悪いな。

716:デフォルトの名無しさん
05/07/07 07:31:19
速度が重要になるコードを書かなければなのですが、
やはりSTL経由の連続処理は、速度的に不利なんでしょうか？

一応自分なりに、次レスに書いたような実験をしてみたのですが、
プロファイル結果はSTL版hoge()が平均301msに対し、
シンプルなリストhage()の方が平均12msと、圧倒的な差に…。

今更自前リストなんて使うのは、考えただけで頭が痛くて。
なにかテストに落ちがないか、
或いはSTL版速度向上のための抜け道が無いか、教えて頂けないでしょうか。

717:714 行制限のため、見づらくてすいません
05/07/07 07:35:09
#include <list>
struct simple_list{
int val;
simple_list* next;
};
template <typename T>
void hoge( T first, T last ){
int sum = 0;
while( first != last ) sum += *(first++);
};
void hage( simple_list* sl_first ){
int sum = 0;
while( sl_first ){ sum += sl_first->val; sl_first = sl_first->next;}
};
int main(){
std::list<int> listInt;
for( unsigned long i=0; i < 100000; ++i ) listInt.push_back(i);

simple_list* sl_first = new simple_list;
simple_list* sl = sl_first;
for( unsigned long c=0; c < 100000; ++c ){
sl->val = c;
sl->next = new simple_list;
sl = sl->next;
}
sl->next = NULL;

hoge( listInt.begin(), listInt.end() );
hage( sl_first );
while( sl_first ){ sl = sl_first->next;delete sl_first; sl_first = sl; }
return 0;
}

718:デフォルトの名無しさん
05/07/07 07:51:04
>>716
プロファイルでは最適化は有効にしてる？
最適化しないと比較にならないし、最適化すると hoge(), hage() が
sum を返してないので、最適化で処理自体が消えてダメかもしれない。

hoge の sum += *(first++); を { sum += *first; ++first } にすると、少し違うかもしれない。

719:デフォルトの名無しさん
05/07/07 07:51:41
>>716
最適化した?
うちじゃ
hoge(): 8.46567 ms
hage(): 7.92051 ms
くらいなんだけど
環境はg++ (3.3.5)

720:716
05/07/07 08:08:12
我ながら非道い
sl->next = NULL;を削って
sl->next = new simple_list; を
sl->next = (c != 100000-1) ? new simple_list : NULL; とでも

>>718-719
最適化をすっかり忘れていました。
なぜだかsumを返すようにしてもhogeの方が消えてしまうのですが
もう少し試行錯誤してみます。

いずれにせよ力づけられました。ホッとしています。
レスありがとうございました。

721:デフォルトの名無しさん
05/07/07 08:20:05
>>720
返すだけで戻り値を使ってないんじゃ、と消えるかもしれないな。
チェックもかねて、画面に値を出すようにすれば大丈夫じゃない？
（そこまでやっても、ただの定数に置き換えてしまうコンパイラとかあるかもしれない。）

最終的にはアセンブリを吐かせて確認するといい。

722:716
05/07/07 08:25:49
最適化無しで719さんの方法で15%ほど速く
>>721
もしかしたらtemplateだったせいかも知れないです。インライン化されていたのかな。
templateを外したらhogeも出ました

hoge: 5.579 ms
hage: 5.313 ms
(vc++6)

朝からお騒がせしました、お二人(三人？)に再度感謝です

723:デフォルトの名無しさん
05/07/07 08:31:10
その程度の処理だとlistは兎も角、vectorは普通の配列と全く同じ速度出るよ。
#つーか、gccでもVC++でもstlの有無で全く同じ(質の)コード吐くんだけどね。

724:デフォルトの名無しさん
05/07/07 18:13:33
>>723
VCだと
vector>=配列
になるときもない？(誤差範囲内だけど)
GCCは
vector使うと少し遅くなる気がした。

725:デフォルトの名無しさん
05/07/07 18:23:22
その辺は具体的なコードを提示して比較でもしない限りなんとも言えないなぁ。
そもそも最適化で消えないコードでって条件になっちゃうし。

726:デフォルトの名無しさん
05/07/07 18:30:29
vectorのiteratorは大抵の処理系/STL実装で非デバッグ時には単なるポインタだろ。

727:デフォルトの名無しさん
05/07/07 18:34:16
>>722
ちなみに std::list が double-linked list だということは知ってるよな

728:デフォルトの名無しさん
05/07/07 23:52:14
doubleじゃないSTLのlistを提示しない限りそのレスは無意味

729:デフォルトの名無しさん
05/07/08 00:55:24
>>728
おれは>727じゃないけど、なんで？

730:デフォルトの名無しさん
05/07/08 01:02:35
そういえばslistは標準じゃないんだな。 STLPortにはあるけど。

731:デフォルトの名無しさん
05/07/08 20:43:04
次のようなコードがあるとします:
　struct base1 { base1(int x) {}; };
　struct base2 { base2(int x, int y) {}; };

　// IF<P,T,F>クラステンプレートは、Pが非0のときT、0のときFをIF::typeにtypedefする
　template <int N> struct derived : public IF<N,base1,base2>::type {};

このとき引数の数が異なるコンストラクタを持つ基底クラスをテンプレートで切り替え、
派生クラスのコンストラクタから、基底クラスのコンストラクタを呼び出したいのです:
　derived<1> d(0); // base1から継承し、コンストラクタは引数1
　derived<0> d(0, 1); // base2から継承し、コンストラクタは引数2

基底クラスのコンストラクタを呼び出すときには、派生クラスの初期化リストを使います。
ところが、派生クラスのコンストラクタ初期化リストでは、基底クラスのコンストラクタ
以外呼べませんから、次のように多重定義できません:
　// Nが非0だとすると
　derived(int x) : base1(x) {};
　derived(int x, int y) : base2(x, y) {}; // error! 基底クラスはbase1

このように基底クラスをテンプレートで替える場合に、うまく派生クラスのコンストラクタの
引数の数を調整するようなテクニックがあれば、ご教示いただけると幸いです。
また、異なるアプローチもあればコメントください。

732:デフォルトの名無しさん
05/07/08 20:50:10
俺にはderivedをNの値によって特殊化する方法しか思いつかない。

733:デフォルトの名無しさん
05/07/08 22:22:17
試しにこう書いてみたら g++ 3.4.4 cygming special では通ったんだが。

derived(int x) : IF<N,base1,base2>::type(x) {}
derived(int x, int y) : IF<N,base1,base2>::type(x,y) {}

734:731
05/07/09 02:41:09
>>732-733
レスありがとうございました。
>733の方法で、パパ、うまくできそうです。
続きがんばります！

735:デフォルトの名無しさん
05/07/09 08:17:21
どうもネットの世界の「ご教示」とか「ご教授」って浮いた言葉だなぁ。

736:デフォルトの名無しさん
05/07/10 00:59:18
実は初めてこの構文を知ったんだけどさ

>URLﾘﾝｸ(www.comeaucomputing.com)
>
>template <class T>
>T foo(T blah)
>{
>　　　　xyz object;
>　　　　T someInt;
>
>// (略)
>
>　　　　someInt = object.mt<int>(99.99); // AA: ill-formed
>　　　　someInt = object.template mt<int>(99.99); // BB: well-formed
>
>　　　　return someInt;
>}

ってなってて AA は ill-formed になってるんだけど、 object はテンプレートパラメータに依存してないんだから
template をつけなくても問題ないと思うんだけど。実際 g++ 3.4.4 だと通るし、. の前をテンプレートパラメータに
依存するように書き換えるとエラーが出る。

規格参照箇所 14.2-4
> When the name of a member template specialization appears after . or -> in a postfix-expression, or after
> nested-name-specifier in a qualified-id, and the postfix-expression or qualified-id explicitly depends on a
> template-parameter (14.6.2), the member template name must be prefixed by the keyword template.
> Otherwise the name is assumed to name a non-template.

737:デフォルトの名無しさん
05/07/10 02:07:52
template <typename T>
class Hoge {
public:
typedef std::vector<T> Container;
typedef Container::iterator Iterator;

private:
Container v;
};

と書いて、Hoge<int> hoge; とか呼ぶと、implicitなtypenameだと警告を言われます。
iteratorを表現するにはどのように記述すべきなのでしょうか。

738:デフォルトの名無しさん
05/07/10 02:09:19
>>737 gcc version 3.2 20020927 (prerelease) です。

739:737
05/07/10 02:11:47
URLﾘﾝｸ(www.tietew.jp) によると、

typename Container::iterator Iterator;

と書くみたいですね。これって常識なのかしら。

740:デフォルトの名無しさん
05/07/10 02:27:11
>>739
その場合、typenameは必須。

741:デフォルトの名無しさん
05/07/10 02:36:16
常識

742:デフォルトの名無しさん
05/07/10 04:36:52
当然

743:デフォルトの名無しさん
05/07/11 10:24:40
>>739
特殊化があるC++では、Tが確定しないと型推論が困っちゃうんで、
typedef typename Container::iterator Iterator;
って感じで。
typename Container::iterator Iterator;
も可能。
Container<int> v;
なら何とかなるはずだけど、explicitにtypenameしましょうという仕様。

744:デフォルトの名無しさん
05/07/16 20:53:42
＞型推論が困っちゃう

そうなのか？
Tが確定しないと、特殊化のあるC++ではstd::vector<T>::iteratorが
typedefされた型名か、メンバ（メンバ変数・関数）かが分からないから
コンパイラへのヒントとして型名であることを明示するのを義務付けてるんでは？

745:デフォルトの名無しさん
05/07/19 22:11:08

全然わかってないけど質問します。

テンプレートクラスの実装って全てヘッダーでやらないといけないんですか？
.cppの方でやるとリンカーエラーが出てリンクできないのですが！？
（全部ヘッダーにコピペしたら通った）

746:デフォルトの名無しさん
05/07/19 22:14:53

追加

だが、しかしそれをやると２重定義になる…
どうすればいいんじゃーーーー

747:デフォルトの名無しさん
05/07/19 22:20:05
>>745
テンプレートの定義をcppファイルに書きたければ、宣言と定義の両方にexportを付けるだけ。
しかしほとんどのコンパイラで使えない。（使えるコンパイラが全くないわけではない）

というわけで普通はヘッダにインラインで全て書く。
ごく稀に明示的実体化が使われることはあるが。

748:デフォルトの名無しさん
05/07/19 22:48:35
>>747
明示的実体化ってまさか、

template class c<bool>;
template class c<char>;
template class c<unsigned char>;

みたいに延々と cpp ファイルに書いていくわけ？

749:デフォルトの名無しさん
05/07/19 23:06:05
g++にはextern templateってのがあるね。

750:デフォルトの名無しさん
05/07/19 23:11:50
>748
そゆこと。

751:745
05/07/19 23:17:21
やってみた>>747

make -k all
g++ -Wall main.cpp Class.cpp -c
g++ -Wall main.o Class.o -o a.exe
main.o(.text+0x25):main.cpp: undefined reference to `Class<int>::Class[in-charge]()'
collect2: ld returned 1 exit status
make: *** [all] Error 1

ﾑﾘﾎﾟ

>>749を含めて出直してくる。これはイマの私の頭ではいくら考えても答えが出ない。
本を読むかg++のマニュアルを漁るか…

752:デフォルトの名無しさん
05/07/19 23:44:58
>>751
g++のinclude/bits/istream.tccより

// Inhibit implicit instantiations for required instantiations,
// which are defined via explicit instantiations elsewhere.
// NB: This syntax is a GNU extension.
#if _GLIBCPP_EXTERN_TEMPLATE
extern template class basic_istream<char>;
extern template istream& ws(istream&);
extern template istream& operator>>(istream&, char&);
extern template istream& operator>>(istream&, char*)

753:デフォルトの名無しさん
05/07/23 19:33:12
template <class T> class foo;

template <class T> class baa{
　friend foo;
　int n;
public:
　baa() : n(777){}
};

template <class T> class foo : public baa<T>{
　int hoge;
public:
　void set_val( baa<T>& arg ){ hoge = arg.n; }
};

int main(){
　baa<int> b;
　foo<int> f;
　f.set_val( b );
　return 0;
}

インデントが全角スペースですいません
これだとarg.nにアクセス出来ないのですが、間違っている場所を教えて頂けないでしょうか
friend foo; が、やっぱり
template <class T> friend foo; なんでしょうか

754:デフォルトの名無しさん
05/07/23 19:45:24
>>753
g++ でコンパイルすると、
:4: error: ISO C++ forbids declaration of `foo' with no type
:4: error: `foo' is neither function nor member function; cannot be declared friend

まぁそれは置いとくとして、
　friend class foo<T>;
で通ったよ。

755:753
05/07/23 19:59:42
>>754
やっぱりclass指定しますよね
書き込む前にチェックしたサイトで、指定が無かったので、自分が間違っていたのかと

そうか、再度template <class T>付けるのは馬鹿でした。
VC6なので、Tが同じじゃなかったらアウトだったかも・・・良かった。

本当に助かりました。コンパイルまでして頂いてすいません。ありがとうございました。

756:デフォルトの名無しさん
05/07/23 20:13:13
baaっての…なんかプログラムがアホっぽくなるな。

757:デフォルトの名無しさん
05/07/23 22:22:39
>>755
friend かどうかっていう問題なのか？
baa<T>::n が private か protected/public かどうかっていう問題では？

758:デフォルトの名無しさん
05/07/23 22:47:57
>>757
vtableを避けるための小細工なんです
眉をしかめる人が多いと思いますが、自分しか使わないのでお見逃しを

759:デフォルトの名無しさん
05/07/23 23:36:56
>>758
よくわからないな。>>753 のを
template <class T> class baa{
protected:
　int n;
public:
　baa() : n(777){}
};
とすると VC6 だと vtable に関して状況が変わるの？

760:デフォルトの名無しさん
05/07/23 23:51:14
753がprotectedを知らなかったというオチ？

761:デフォルトの名無しさん
05/07/24 00:21:24
>>759
失礼、深読みしすぎてました。

しかしすいません、そうなると>>757で頂いたレスの意図が分からないです。
protectedすると、引数で他のbaaを受け取ったとき、nにアクセス出来るのでしょうか。

762:760
05/07/24 00:40:00
753のコードでは、bar<T>::nがprotectedならfoo<T>::set_valの中でarg.nにアクセスできると思っていたがそうではなかったようだ。
ｽﾏｿ

763:デフォルトの名無しさん
05/07/24 01:03:17
>>761
アクセスできると思ってた。けど間違ってたのなら失礼。
・基本 class から派生 class を public 継承したとき、
・基本 class の protected member である n について、
・派生 class から this の n にアクセスできる。
・派生 class から this 以外の n にアクセスできない。
ということかな？も一回勉強しなおそ。

・ある class の private member である n について、
・その class から this の n にアクセスできる。
・その class から this 以外の n にアクセスできる。
というのは間違いないと思うんだけど。

あと自分の VC7 は、これに関して template class かそうでないかによって
コンパイル結果が違うのもよくわからない。

764:デフォルトの名無しさん
05/07/24 02:17:54
勉強しなおした。>>763は間違い多数につきスルーよろしく。失礼しますた。

次ページ