失礼しました
Ban さんの
># でも簡単に動かしてみたら(doubleとか関係なく)、
># boost::keep_empty_tokensにしてるとtokenizerで余分な要素が取れちゃうっぽい。
># 何だろ。(XPpro,VC2008,boost1.45.0)
終わってませんでした、継続しませう。
[7] 0.10000000000000001 double
多分、この0.00000000000000001 このゴミの事ですよね、私も気になっていました。

επιστημηさん、ありがとうございます。
> Working draft N3090
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3090.pdf
1357ページですか、それも英語。orz

> > ってのしか見つからない。本当の所はどうなんでしょうね。
> 「本当の所」が知りたいなら規格にあたればいいやん。
# こう書けば、誰かさん（επιστημηさんやtetrapodさん辺り）が解説してくれるんじゃ
# ないかと思ったのも事実。

Banさん、ありがとうございます。
> JIS版(日本語)でいいなら、以下からX3014が閲覧のみ可能。
> http://www.jisc.go.jp/
JISは閲覧のみできるんですね。

休み明けに見てみたら、すっごい増えててびっくりしました

つっこみを募集すると、皆様色々つっこんで頂けて、とても参考になります
どうもありがとうございます

たしかに気になっていたんですけど
>> Container& operator+(const Container& line) const
>> {
>> static Container temp;
>> ...
>> return temp;
>> }
の部分って、どう書くべきなんでしょうねぇ
さらっとできるかなって思って書いたんですけど、ここが嫌だったんですけど、まぁい
いやで static にしちゃいました
この構造自体がよくないのかもなんですけど、実体だとデストラクタ呼ばれちゃって、
結局エイヤっだったんですよ

ちょっと、お手数ですけど参考にさせてください

> 多分、この0.00000000000000001 このゴミの事ですよね、私も気になっていました。

いえ、別件です。

私の方は単純に、用意したダミーデータの最後に , が余分についてただけでした。
　10, 20, 30,
だと、30の後ろにも空の要素があると判断されていて、
　10, 20, 30
なら30が最後で終わるところをdropしてないから30の次に"の要素が取れてたという…orz

ちなみに、初心者++ になりたい さんが書かれている「ゴミ」というのは
ただの誤差であって、浮動小数というのはそういうものです。

# 浮動少数の0.1ってのは典型例なので、「浮動小数」「0.1」とかで
# ちょっと検索するだけでも解説ページがごろごろ出てくるかと思います。

>>tmpの結果が使われていないようですが…。

これ自体は、ただのバグ？の指摘です。ローカル変数tmpの値を変更するのに、
そのtmpを使わずに*thisを返すのは意図通りですか、と。

> うまく説明できないのですが、私がtemplate クラスにこだわるのは、
> template の柔軟さと、クラスの強力なコンストラクタの力を合わせて、
> 取得するデータの型を判別して、実装者が欲する型のインスタンスを、
> 多態的に生成できないのだろうか？という発想からです。

ちなみに、std::vector<std::string>でもstd::vectorもstd::stringも立派に
templateクラスだと思いますが、それでご不満そうな理由が私にはよく分かってません。
# 多分、ここに何か「隠れた要求」があるのかなぁとは思いますが。

例えば10, 20, 30の各要素をある型として扱いたいとして、
10が数字なのか文字なのかなどが判断できるのは結局実装者だけのはず。
つまり、「実装者が欲する型」を「実装者が予めルール付けするのは必須」なわけですが
(「1番目は数字という静的な仕様」とか「[0-9]+なら数字という動的な判断」とか含む)
templateクラスならをその設定方法を楽にできるはず、ということでしょうか。

例えば以下を例でいうと、どれがイメージに近いでしょうか。
・データに型情報を持たせる　(boost::serializationのような読み出し？)
・データの判断条件を実装する (boost::spirit(もしくはtokenizer+regex等)のような読
み出し？)
・何も指定しなくても実装者の意図を推測して良しなに動作する何か。

>>> Container& operator+(const Container& line) const
>>> {
>>> static Container temp;
>>> ...
>>> return temp;
>>> }
> の部分って、どう書くべきなんでしょうねぇ

フツーに Container temp; でよくね?
コピーや解体のコストがシャレならんなら、
handle-bodyイディオムで参照を保持すれば。

憶測ですが、新しいオブジェクトを生成するはずなのに、
それを参照で返そうとしているのがそもそもの問題で。
Container& operator+(const Container& line) const
　　↓
Container operator+(const Container& line) const

無理矢理に参照で返そうとするから問題が出て、
その結果として無理矢理staticになったのではないかなぁと。
なので、こっちも要修正じゃないでしょうか。

ですね。

Container& operator+(const Container& line) const
{
Container temp;
...
return temp;
}

あーもー、肝心なとこで&抜き忘れてっし orz

Container operator+(const Container& line) const
{
Container temp;
...
return temp;
}

てか、僕ならメンバ関数にはせんです。

Container operator+(const Container& c1, const Container& c2)
{
Container temp;
...
return temp;
}

επιστημηさん、Banさん、参考意見ありがとうございます
でも、Banさんに指摘してもらって、気づきました

>Container& operator+(const Container& line) const
>　　↓
>Container operator+(const Container& line) const
ですねぇ

operator+= をコピーして operator+を書いたら参照残ってました
言われるまで、まったく気づかなかったです
気づかないまま、仕方なくstaticという道を選んでました。。。

επιστημηさんの言うとおり
>フツーに Container temp; でよくね?
と思って、最初はフツーに Container temp;にしてたんですけど、エイヤーで作ったこ
のクラス、デストラクタで解放処理しちゃってて、メソッドの出口でデストラクタが呼
ばれちゃってるのに、内部のメンバ領域が解放されちゃってるのに、参照で返そうとし
てたから、まずかったみたいです
解釈あってますか？

>handle-bodyイディオムで参照を保持すれば
そうですね、この戻り値が 間違えではなく参照型で返すものとして設計した場合は、ス
マートポインタも視野に入れていいかもしれませんね

でも、結論戻り値の間違えでした

>>handle-bodyイディオムで参照を保持すれば
> そうですね、この戻り値が 間違えではなく参照型で返すものとして設計した場合は、
> スマートポインタも視野に入れていいかもしれませんね

いや、そうでなくても:

class Container {
shared_ptr<vector<string>> body_ref;
...
};

どーのこーのしておけばコピーその他のコストは小さくなるし。

>> そうですね、この戻り値が 間違えではなく参照型で返すものとして設計した場合
は、
>> スマートポインタも視野に入れていいかもしれませんね
あ、参照型なら戻すのは *thisですね…

επιστημη さん、ありがとう
handle-bodyイディオムをちょっと勉強してみますね
本とか K&R のみで、後は仕事覚えた感じで気がついたら、ずいぶん偏った知識になって
ますので、時間を作って勉強してみますね

ちなみに επιστημη さんって、C++とかの本出してる、επιστημη さん
ですか？
年末年始はいろいろ本読んでみます

初心者++ になりたいさんは、この流れからいいアイディア思いついたかしら、
お邪魔してごめんなさいねｗｗｗ

> ですか？

ですよ！

>ですよ！
そうなんですか

えっと、私は組み込みの設計も多く、メモリの制限の都合上か、組み込み系の専用OSを
使わず、標準ライブラリも極力使わず、標準のmalloc/free、new/deleteを使用しない
で、自ら定義したヒープ領域に確保するできるだけ必要最小限で軽く動く自作関数とし
て再定義/オーバーロードしちゃっていて(もちろんテンプレートなどは未実装)、それを
多用してます、更にそれを制御するドライバをその延長上で作って、さらに更にそれを
使用したアプリケーション開発にいたるので、標準的なC++からかけ離れた環境での中 C
言語の枠を滅多に超えていませんというのが現状です(あ、alloc/free、new/deleteの自
作は組み込みだけですよ)
でも、組み込み系の専用OSの基盤も整いつつあるので、ちゃんとC++のお勉強もしてみよ
うかと思っていました
ただ、マネージド(CLI的な)のも広がりつつあり、かつ、MFCもCMFC～とかのクラスもド
シドシ増えてきちゃって、ちゃんとしたお勉強はなかなか後回しになってしますのが現
実ですね

C++の本はストラウストラップ氏の本(高かった…)くらいしか持ってないんですけど、重
すぎて全ては読めてないんですよｗｗｗ
επιστημηさんの名前が書かれていた-「Ｃ＋＋テンプレートテクニック」という
本(だったかな？)が最近本屋さんで目立つように置いてましたが、その本はちゃんとC++
のお勉強(というか主にSTL関係)にはどうでしょうか？

>「Ｃ＋＋テンプレートテクニック」

うーん、書き手が何を言うても宣伝にしかならんので^^;