>子スレッド放置というつもりで実装はしてないので、後で確認してみます。
えーと、CanBreakが使われる（join()しない方）と放置になります。
>子スレッドの終了に関してのコンセプトは、
> ～
>と、考えています。
なんとなく言わんとするところは理解できますが、問題は「放置する」選択肢がないこと
なんです。
コンセプトとして、絶対にデストラクタが終わった時にはスレッドは終了していることを
保証し、それに反するような使い方をするスレッドを作る場合は別の関数・クラスを使うなりする
ということであればそのままでも問題はありません（その場合以下は無視して下さい）。
もし、そうではなく汎用的なスレッドクラスを目指しているのであれば幾つか問題があります。
まず、前スレでも指摘したのでご存じだと思いますが、無限ループ"的"な子スレッドの場合、
Threadクラスがデストラクタで join()を行うと復帰が困難になります。
又、デストラクタで強制的に子スレッドを破壊することは、子スレッドの状況如何では
非常に危険を伴います。
従ってこの場合、放置する（勿論ハンドルは解放しますが）か、キャンセルポイントによるスレッドの
キャンセルをするのが最適なのではないでしょうか。
次に
> 必ず子スレッドの終了を待つ(安全側)か、子スレッドを強制的に終了させる(危険側)のか
ということは
Threadクラスのライフサイクル ＞ 子スレッドのライフサイクル
ということになります。
これが便利なケースもありますが、逆にいつ終わるか判らない子スレッドの為に、
Threadクラスが存在していなければならないことになり、スレッドの本来の目的である
非同期性が失われ、運用が不便になる可能性もあります。
例えばある関数の機能として、リクエストだけして戻っていき、
（一定時間で終わるだろう）処理そのものは子スレッドで行うような場合、
どうしたらいいでしょう。
[color=#d0d0ff" face="monospace]TK::ThreadOpe<int>* test()
{
return new TK::ThreadOpe<int>(bar2,0);
}
[/color]
とか、
[color=#d0d0ff" face="monospace]boost::shared_ptr< TK::ThreadOpe<int> > test()
{
return new TK::ThreadOpe<int>(bar2,0);
}
[/color]
なら、即座に関数を抜けていきますが、戻値を受け取って管理しないと
いけません。
[color=#d0d0ff" face="monospace]void test()
{
TK::ThreadOpe<int> thread1(bar2,0);
}
[/color]
というようなコードですと、現状の仕様ではbar2が終わるまで戻れませんし、
強制破棄するタイプだとしても、すぐに関数を抜けて戻っていきますが
それでは bar2()の処理が終わりません。
これがもし「放置」するタイプであれば、最後のコードで旨く動きます。
こういう、リクエスト系の使い方はしないのでしょうか？
>また子スレッドの放置は、メモリーリークの可能性や、子スレッドが悪さをする可能性があると
もちろん、放置は万能ではありません。
マズイのであれば、キャンセルポイントによるスレッドのキャンセルをするなり、
実行の終了を親スレッド側でまったり、或いは最悪スレッドの強制終了も視野にいれる必要はあります。
ちなみに前スレで話題にした C++0xの std::threadなど多くのスレッドクラスのデストラクタは
基本的に実行している子スレッドに何もすることなく終えるようです。