06/01/29 06:02:25
>>668
を読んでいくら禿でも、そんなことないだろうとプログラミング言語C++を読んでみたら
------------------------------------------------------
残念なことに、copy_ifはどうしたわけか標準ライブラリが
提供するアルゴリズムセットから抜け落ちてしまった(私の過失である)
---------------------------------------------------------
by 禿
プログラミング言語C++第三版 P610より
やっぱ禿のせいか
ｳﾜｧｧｧｧｧｧヽ(`Д´)ﾉｧｧｧｧｧｧﾝ!
670:デフォルトの名無しさん
06/01/29 09:41:20
まあ、logical_not使えばいいし。
671:デフォルトの名無しさん
06/01/29 10:24:19
_ifなんてついてる時点で設計ミスだから禿は正しい
filter_iterator使え
672:デフォルトの名無しさん
06/01/29 10:31:49
今禿って言う香具師ちょっと来い( ﾟДﾟ)
673:デフォルトの名無しさん
06/01/29 10:55:35
はげって誰のこと？
画像はってよ。
674:デフォルトの名無しさん
06/01/29 11:53:09
URLﾘﾝｸ(public.research.att.com)
remove_copyも名前がおかしい。
675:デフォルトの名無しさん
06/01/29 11:54:21
あれえ？前は椅子に座って机に足かけてる画像だったような気がするけど。
ハゲのくせに足なげえとしか思ってたけど。
676:デフォルトの名無しさん
06/01/29 12:05:45
名前はAdaでMusser&Stepanovが書いた頃の流儀だな。
removeじゃなくてDeleteだが。Copy_Ifはこの頃からない。
677:デフォルトの名無しさん
06/01/29 12:15:54
ホントだ。写真変わってるね。
ﾊｹﾞのくせに生意気
678:デフォルトの名無しさん
06/01/29 12:25:27
このおっさんの名前見るたびに、
インリンの顔が浮かぶ。
なんかＭ字ビターンに似てねぇ？
679:デフォルトの名無しさん
06/01/29 13:30:48
ｵﾏｲﾗ本人がいないからって言いたい放題だなｗ
680:デフォルトの名無しさん
06/01/29 13:38:47
禿より♥
template <typename InputIterator, typename OutputIterator, typename Predicate>
inline
OutputIterator
copy_if(InputIterator begin, InputIterator end, OutputIterator destBegin, Predicate p)
{
while (begin != end)
{
if (p(*begin)) *destBegin = *begin;
++destBegin;
++begin;
}
return destBegin;
}
681:デフォルトの名無しさん
06/01/29 14:01:16
>>679
俺は本人の前でも言えるよ。日本語でなら。
682:デフォルトの名無しさん
06/01/29 14:03:11
>>679
俺も本人の前でも言えるよ。エスペラント語なら。
683:デフォルトの名無しさん
06/01/29 14:06:06
ﾋﾞﾔｰｿって言語学者だしエスペラント知ってそうだな
684:デフォルトの名無しさん
06/01/29 14:23:36
だったら禿がこのスレ見たら泣くな
日本語も分かりそうだしｗ
685:デフォルトの名無しさん
06/01/29 16:08:10
は・・い、いえビョ～～ン先生ごめんなさい。
私たちが間違ってました。
686:デフォルトの名無しさん
06/01/29 16:13:40
copy_ifがあるとき ヽ（´ー`）ノ
//全てのアルファベットを抽出
std::copy_if(hoge.begin(),hoge.end(),back_inserter(x),std::isalpha)
copy_ifがないとき（´д｀）
//全てのアルファベットを抽出
std::remove_copy_if(hoge.begin(),hoge.end(),back_inserter(x),std::not1(std::ptr_fun(std::isalpha)))
687:デフォルトの名無しさん
06/01/29 20:49:19
何この平和なスレ。
688:デフォルトの名無しさん
06/01/29 23:30:00
>>686
copy_ifはないけれどBoostがある。
namespace bll = boost::lambda;
std::remove_copy_if(hoge.begin(), hoge.end(), back_inserter(x), !bll::bind(std::isalpha, bll::_1))
689:デフォルトの名無しさん
06/01/30 23:46:56
あ～るはげた～ひる～さがり～♪
690:デフォルトの名無しさん
06/01/31 00:06:11
か～つら～につづ～くみち～♪
691:デフォルトの名無しさん
06/01/31 01:37:40
めーがーねーがーごーとーごーとー♪
692:デフォルトの名無しさん
06/01/31 12:11:59
func(float a[])
という関数に
vector<float> x;
を引数に渡したくて、
func(&(x[0]))
とやっているんだけど、うまくキャストができません。
どうすればいいでしょうか？ご教授よろしくお願いいたしますm(__)m
693:デフォルトの名無しさん
06/01/31 12:24:00
>>692
すまん、普通にそれで通るんだがコンパイラ何よ？
#include<vector>
void func(float a[]){}
int main(){
std::vector<float>x;
func(&(x[0]));
}
694:デフォルトの名無しさん
06/01/31 12:35:35
>>693
すまん、おれのミスだった。まちがって、
int main(){
std::vector<float>x;
func(x);
}
とやっていた。
いずれにしろバグが取れて助かりました。
どうもありがとう！
695:デフォルトの名無しさん
06/01/31 13:18:55
それバグじゃない
696:デフォルトの名無しさん
06/01/31 21:45:01
694の頭にバグがあったということだろう。
697:デフォルトの名無しさん
06/01/31 23:30:35
スキンヘッド推奨
698:デフォルトの名無しさん
06/02/01 05:53:56
サイドは残さなきゃダメだろ
699:デフォルトの名無しさん
06/02/06 16:43:38
std::vector<T> にて、T はデフォルトコンストラクタ
T::T() を持たなければダメなんでしょうか？？？？
たしかに T::T() を必要とするメソッドは有るよな。
初期化されないブツが投入されるのがイヤな時には、
とりあえず T::T() の中で何か throw するようにしておく？
でもそれだと実行時にしか検出されない･･･
って、書いてて気づいたんだけど、もしかして
T::T() を宣言だけしておいて定義しなければ
リンク時に気づくかも。
700:デフォルトの名無しさん
06/02/06 16:50:32
そんなに気になるならデフォルトコンストラクタをprivateにすればいいやん（;´Д｀）
701:デフォルトの名無しさん
06/02/06 17:05:05
>>700 ΣΣ（ﾟдﾟlll）ｶﾞｶﾞｰﾝ
そ、そうだった・・・・
702:デフォルトの名無しさん
06/02/06 17:11:54
>>699
>初期化されないブツが投入されるのがイヤな時には、
ってことはそのTは自前のコンストラクタを持ってるわけでしょ
ってことはT::T()が勝手に定義されることはないので
何もしなくてもコンパイルエラーになるよ
703:デフォルトの名無しさん
06/02/06 17:19:35
>>702 うん、で、そういうクラスを std::vector<T> に
格納しようとしたら、std::vector<T> のコンストラクタの
一つが T のデフォルトコンストラクタを要求するので
エラーになります。 private にしても同じく。
でも実際にはそのコンストラクタは呼ばれないので、
宣言だけして定義はしなくてもリンク可能です。
実際に使われてるか否か（コードが生成されているか否か）
に関わり無く、テンプレートの関数はとりあえず
実体が生成されるものとして構文と識別子のチェックが行われるようです。
704:デフォルトの名無しさん
06/02/06 17:20:12
って、それは C++99 が要求している事なのか、
たまたま VC++ 2005 の実装がそうなのか分かりません。
705:デフォルトの名無しさん
06/02/06 17:27:22
JIS X3014ではコンテナの要素の要件に定められていることは、
コピーコンストラクト可能であることと代入可能であることだけだった。
（デフォルトコンストラクト可能である必要はないと）
706:デフォルトの名無しさん
06/02/06 17:30:26
>>703
VCで試そうとしたけどエラーが出ない......
エラーの出る最小のソース希望
707:ごめん
06/02/06 17:50:27
俺の勘違い。
class Kurasu {
private:
int i;
public:
Kurasu(const int given_i) { i=given_i;}
};
void KurasuVector() {
std::vector<Kurasu> k(100);
}
そりゃエラーになるわ。
俺が明示的にデフォルトコンストラクタを必要とする
コンストラクタを呼び出してるんだからな。
void KurasuVector() {
std::vector<Kurasu> k;
}
なら問題 nothing 。
正直、スマンカッタ
708:デフォルトの名無しさん
06/02/06 21:59:19
>>704
C++は98。
709:デフォルトの名無しさん
06/02/06 22:00:44
>>708
つ2003
710:デフォルトの名無しさん
06/02/06 22:04:28
禿共のがんばり次第によっては06
711:デフォルトの名無しさん
06/02/06 22:13:51
>>710
禿曰く09
712:デフォルトの名無しさん
06/02/06 22:17:47
おのれ禿・・・
そんなに待てぬ
713:デフォルトの名無しさん
06/02/06 22:29:30
禿禿いうな禿
714:デフォルトの名無しさん
06/02/06 22:31:23
禿せめて08年中ぐらいにはお願いします。
そうすれば00年代にはそこそこ対応したコンパイラが出るかもしれません。
715:デフォルトの名無しさん
06/02/07 06:18:41
禿さんの禿って今も進行してるんですか？
716:デフォルトの名無しさん
06/02/07 07:14:10
>>715
まだ完全には実装されていない。
というか、写真によってちょっとずつちがうから、
そこはベンダー依存ではないか。
717:デフォルトの名無しさん
06/02/07 07:48:57
10年に出すと言うのも男の勇気ですぜ，禿の兄貴。
718:デフォルトの名無しさん
06/02/07 11:12:23
確か最速で x=9 ってヒゲが言ってた。
標準化のプロセスに時間がかかるらしいから、
禿やヒゲががんばっても多分早くはならない。
719:デフォルトの名無しさん
06/02/07 11:19:31
まあ無理に急いで糞言語になるか、標準化遅れて処理系がNEEEEEEになるかはトレードオフだしなぁ
720:デフォルトの名無しさん
06/02/07 11:29:31
どこがC++0xなんだよ
C++1xじゃねえか
禿だか髭だかフサフサだかしらねーけどとっととしやがれ
721:デフォルトの名無しさん
06/02/07 11:45:21
C++0x0a
722:デフォルトの名無しさん
06/02/07 20:19:28
クラスのポインタ配列のvectorを作成し、
foo.push_back(new CFoo()); とやると無論コンストラクタが呼ばれますが
foo.erase(foo.begin()); 等とした際に
CFooのデストラクタが呼ばれないのは、こういう物だと思うしか無いのでしょうか？
foo[0].~CFoo(); みたいな事をeraseする度にやるのは何かおかしい感じがします
723:デフォルトの名無しさん
06/02/07 20:26:15
>>722
スマートポインタ
724:デフォルトの名無しさん
06/02/07 20:32:37
>>722
eraseする前にデストラクタではなくdeleteを呼べ。
それでは面倒だから>>723。
或いはboost::ptr_vector。
725:デフォルトの名無しさん
06/02/07 20:33:52
deleteされるわけじゃないからね、リークするだけ
boost::shared_ptrとかptr_vectorとかあるけど
726:デフォルトの名無しさん
06/02/07 20:36:09
>>723-725
一応、こういうモノなんですね…、ありがとうございます
ptr_vector ていうのがぱっと見便利そうなので試してみます。
とても参考になります。
727:デフォルトの名無しさん
06/02/08 00:27:35
>>722,726
もう納得したみたいだが
CFoo* p = new CFoo();
foo.push_back(p);
foo.erase(foo.begin());
で、勝手にdeleteされた方が
おかしい感じがするだろ
728:デフォルトの名無しさん
06/02/08 09:39:50
boost::ptr_vector と
std::vector<boost::shared_ptr> と
どっちがおすすめ？
っていうか本質的な違いある？
729:デフォルトの名無しさん
06/02/08 10:53:13
>>728
>どっちがおすすめ？
ケースバイケース
>っていうか本質的な違いある？
要素が生ポインタかスマートポインタか。
730:デフォルトの名無しさん
06/02/08 10:58:31
>>729 そうか、 boost::ptr_vector は中身が生ポインタか。
だったら std::vector< std::auto_ptr > とおなじようなもんか？
と思ったけど、後者はやっちゃだめなんだよな。
とりあえず boost::ptr_vector のヘッダファイルでも読んでみます。
731:デフォルトの名無しさん
06/02/08 21:55:40
>>730
ptr_vectorは、ただ単にデストラクタで全要素をdeleteするだけだろ。
auto_ptrとは何の関係もない。
732:デフォルトの名無しさん
06/02/08 23:20:20
要素が削除されたときにdeleteされるから、概念的に各要素がauto_ptrと言えなくも無い。
所有権の移動が無いからboost::scoped_ptrの方が適当だが。
733:デフォルトの名無しさん
06/02/09 08:17:21
(ﾟДﾟ)ﾊｧ?
734:デフォルトの名無しさん
06/02/09 09:28:44
ゆとり世代か
735:デフォルトの名無しさん
06/02/09 10:47:39
732はきわめて妥当なこと書いてると思うが……
736:デフォルトの名無しさん
06/02/09 19:14:45
>735
同意。
737:デフォルトの名無しさん
06/02/09 20:00:25
概念的という言葉を使えば、その記述が妥当であるかのように錯覚する。
しかし、プログラマの目の前にあるものは、
あいまいな「概念」などではなく、具体的で厳密なものだ。
プラットホーム、コンパイラ、ライブラリへの依存を無視した「概念」という言葉は、
プログラマに何の解決ももたらさない。時に誤解さえ与えかねない。
738:デフォルトの名無しさん
06/02/09 22:09:49
概念は心の拠り所。
739:デフォルトの名無しさん
06/02/10 00:22:32
>>737
お空に消えてなくなるタバコの煙みたいなレスですね。
740:デフォルトの名無しさん
06/02/11 14:39:46
先月末にApacheの(元はRogue Waveの)STLが出てるけど、これ既出？
URLﾘﾝｸ(incubator.apache.org) の一番下
741:デフォルトの名無しさん
06/02/12 14:20:46
>>740
DL してみたんですけど、 VC6 へのインストール方法がわかりませんでした。。。
742:デフォルトの名無しさん
06/02/20 06:46:37
vectorを配列のように使った場合、配列と比較してパフォーマンスは落ちますか？
743:デフォルトの名無しさん
06/02/20 06:47:16
自分で計れカス
744:デフォルトの名無しさん
06/02/20 07:15:19
実装にもよるが素人が書いた場合、むしろ速くなる場合が多いのでvectorが利用できるなら利用することをすすめる
745:デフォルトの名無しさん
06/02/20 10:08:16
>>742 パフォーマンスに一番影響が出そうなところは
at() と operator[] のどちらを使うかってところかなぁ。
俺はもんげ～速度に厳しいときだけ operator[] 使ってる。
746:デフォルトの名無しさん
06/02/20 11:06:31
未だにat()を使ったことがない。
747:デフォルトの名無しさん
06/02/20 11:18:38
>>746 とりあえず安全のために
速度にうるさくないところでは
at() を使ってる。冷害出してくれるし。
748:デフォルトの名無しさん
06/02/20 11:20:28
あー漏れも同じだ
とりあえずat使って例外が飛んでこなかったらホットしてる
749:デフォルトの名無しさん
06/02/20 11:54:43
ホットで藤井隆を思い出した
750:デフォルトの名無しさん
06/02/20 13:04:53
漏れはfor_eachを使うからat()もoperator[]も使わんがな。
751:デフォルトの名無しさん
06/02/20 21:13:31
STL
ST
S
ST
SLL
752:デフォルトの名無しさん
06/02/20 22:08:02
at は安全だっつって使っておきながら catch してない人が居たなあ……。
753:デフォルトの名無しさん
06/02/20 22:49:12
>>752
投げられる例外すべてを catch する必要は無い。
754:デフォルトの名無しさん
06/02/21 12:42:04
>>752
コケてくれるという事は、検出出来ている、という事です。
安全ですね
755:デフォルトの名無しさん
06/02/21 12:59:15
「こけてくれる=安全」といえばこんな思い出が。
学生時代、あるプロジェクトにバイトで火消し投入された。
バイトを投入するあたり、相当DQNな会社だったわけだが、
まぁ投入される方としては時給もよかったしラッキーって感じ。
で、いつまで経っても原因不明のバグが出たりでなかったりで
リリースできん、って言う物だったんだけど、社内で共通に
使ってるライブラリみて唖然とした。すげぇ臭い物に蓋な
プログラム。例えば年齢を引数に取るコードで、負の値が
与えられたら勝手に0と見なす、みたいなことやってる。
で、漏れが assert 入れたら、お前のせいでバグが増えたってしばかれた。
756:デフォルトの名無しさん
06/02/21 14:58:19
以下のようなプログラムでa::bを使用すると
public: static class std::map<int,int,struct std::less<int>,class std::allocator<int> > a::b
というリンクエラーが発生します。
これはなぜなのでしょうか？
#include <map>
class a {
public:
static std::map<int,int> b;
};
757:デフォルトの名無しさん
06/02/21 15:03:53
class a{
...
};
static std::map<int,int> a::b; ← static メンバは外部定義しないとダメポ
758:デフォルトの名無しさん
06/02/21 15:09:38
>>757 宣言もしてないのにそんなこと出来るの？
759:デフォルトの名無しさん
06/02/21 15:34:47
その質問はよくわからんな
760:デフォルトの名無しさん
06/02/21 15:36:11
僕がSTLより高速なコードを書ける日来ますか？
761:デフォルトの名無しさん
06/02/21 15:36:34
来ません。
762:デフォルトの名無しさん
06/02/21 15:49:21
>>756
何その糞コンパイラ。
763:760
06/02/21 16:03:57
>>761
ありがとうございました。
それが分かっただけでも大満足です＾＾
764:デフォルトの名無しさん
06/02/21 16:54:05
>>757
以下のようにしたらエラーが出なくなりました。
ありがとうございます。
#include <MAP>
class a {
public:
static std::map<int,int> b;
};
std::map<int,int> a::b;
765:デフォルトの名無しさん
06/02/21 17:19:24
>>762
そのレスは意味が分からん
766:デフォルトの名無しさん
06/02/21 17:53:27
>>755
続きは？
767:デフォルトの名無しさん
06/02/21 18:36:01
>>766
確かにちょっと気になるな
ワッフルワッフル
768:デフォルトの名無しさん
06/02/21 18:52:03
それはつまり、どういうイヤらしいしばかれ方をしたか
詳細を書けということだな
ワッフルワッフル
769:デフォルトの名無しさん
06/02/21 22:58:38
キャッチしなくていいってのは、例外安全無視ってこと？
770:デフォルトの名無しさん
06/02/21 23:02:21
>>769
関係ない。「例外安全」の意味わかってんのか？
771:デフォルトの名無しさん
06/02/22 07:02:16
>>769
キャッチ漏れがあっても最後に確実に検出できるのがいいとこでそ。
772:デフォルトの名無しさん
06/02/22 07:10:09
関数内でエラーを拾った場合に、メンバ変数なり引数変数なりを
関数呼び出し前の状態に戻しておいて、処理が呼ばれなかったことにしつつ
例外を投げるのが例外安全だっけ？
773:デフォルトの名無しさん
06/02/22 07:32:38
>>772
それは例外安全性のレベルが与える保証のうち、強い保証というもの。
774:デフォルトの名無しさん
06/02/22 08:42:51
>>772
URLﾘﾝｸ(www.research.att.com)
URLﾘﾝｸ(public.research.att.com)
URLﾘﾝｸ(public.research.att.com)
URLﾘﾝｸ(public.research.att.com)
用語を知るってのは、単なる記憶力の問題じゃなくて、
基礎概念を整理して理解するってことにつながるから、
URLﾘﾝｸ(www.research.att.com)にあることくらいは理解した方がいい。
英語苦手でも、簡単な英語で書かれているから、翻訳ソフト併用で問題なく読めるはず。
775:デフォルトの名無しさん
06/02/22 08:44:20
Deep C++にも例外の記事があったような気がしたがどうだっけ？
776:デフォルトの名無しさん
06/02/22 08:47:35
手元に 「Exceptional C++ (訳本)」 があるので、
例外中立と例外安全のところ読み返しときます。
777:デフォルトの名無しさん
06/02/22 08:47:42
>>775
あれは連載の途中で間違いの訂正が入っていたりするんで
途中だけ読むようなことは危険。
通して読めば、例外への誤解～理解を追えるので有益。
778:デフォルトの名無しさん
06/02/22 09:03:16
例外中立も例外安全も知らずに
例外を使っていたオレ。
779:デフォルトの名無しさん
06/02/22 09:35:50
Schmidtってちょっととぼけたところあるからな。
筆量はすごいんだが。
780:デフォルトの名無しさん
06/02/22 09:39:44
>>752はやっぱり変な気がする。
最終的に例外キャッチしない場所だったら、at使うよりも、
デバッグ版のSTL使うとか、assert入れるとか、デバッグ版とリリース版で[]とatを切り替えるとか
するのが筋でなかろうか。
まぁ速度気にしないならどうでもいいけど。
781:デフォルトの名無しさん
06/02/22 09:56:15
>>780
最終的に例外をキャッチしない場合でも範囲オーバー時の動作が違うわけで。
operator[]() で範囲オーバーしたら未定義動作。
at() で範囲オーバーしたら terminate() 。
環境によってはこれだけで十分な理由になり得る。
782:デフォルトの名無しさん
06/02/22 14:49:38
あー確かに。「誤動作即再起動」なプログラムには充分意味があるよ。
U/I持ってたらそうはいかないんだろうけど。
783:デフォルトの名無しさん
06/02/22 17:40:41
vector<double> a(n),b(n)
の２つの vector があって、
sort(a.begin(),a.end()) とsort をしています。
このとき、a の並び替えと全く同じ順番になるように
b も並び替えたいのですが、どうすればいいでしょうか？
class x{
double a
double b
firend operator<(const x&, const x&)
};
のような構造にして vector<x> c を作り sort(c.begin(),c.end());
とやればいいのは分かるのですが、a と b はメモリ上に
連続して配置する必要があるので、この方法は使えません。
いいアイデアがございましたら、ぜひよろしくお願いいたしますm(__)m
784:デフォルトの名無しさん
06/02/22 18:11:01
aのsortに合わせてbの要素も入れ替える様、sortを修正しろ。
a,bが小さいなら、class x { double a; int seq; } でseqに順番入れてソート、
bをseqみながら入れ替え。
785:デフォルトの名無しさん
06/02/22 18:19:03
>>783
boost::zip_iterator + a だけを見る比較
でいけるんじゃね？
786:783
06/02/22 18:25:56
レスどうもありがとうございます。
STL の sort をどこかに copy して修正すればいいのでしょうか？
STLの改造は今までやった事がないので、よく分からないのですが、
sort 命令に相当する source をSTLの中から探し出して、
それを改造し、自前で修正し、新たなソースファイルに
するということでしょうか？それともsort 文だけ
再定義する方法があるのでしょうか？
787:783
06/02/22 18:28:37
786は784へのレスです。
>>785
そんなのがあるのですか！boost::zip_iterator というのは
使ったことがなかったのですが、ぜひ勉強してみます。
やはりSTL だけでスマートにやるのは難しいでしょうか？
788:デフォルトの名無しさん
06/02/22 18:36:48
>>786
sortを修正すると言うより、sortに渡す関数オブジェクトを作れと言うことだろう。
789:デフォルトの名無しさん
06/02/22 19:32:27
関数オブジェクトによるソートといえば、
VC6のstd::list::sort()は欠陥で有名だよな。
std::sort()は大丈夫だけど。
790:デフォルトの名無しさん
06/02/22 19:47:39
xをsortしてから、a,bに全要素コピーし直す…
空間的にも時間的にも無駄が多いが
sortを自分で書くしかないか？
std::sortをコピペしてきて
swapの部分だけ二重にするとか
この2通りしか思いつかない
791:デフォルトの名無しさん
06/02/22 19:55:17
aのソート結果を使ってコピーする関数オブジェクトを作ってbからbNewにコピーしたら?
792:783
06/02/22 19:55:36
>>788
レスありがとうございます。
790さんが言われるように swap 自体を書き換えないといけない
ような気もするのですが、いかがでしょうか？
793:783
06/02/22 20:25:16
>>791
すみません、関数オブジェクトを使い慣れていない初心者でして、
考えてみたのですがよく分かりませんでした。具体的に
どのようにすればよろしいでしょうか？
794:デフォルトの名無しさん
06/02/22 20:31:27
>>790
> xをsortしてから、a,bに全要素コピーし直す…
> 空間的にも時間的にも無駄が多いが
これが一番簡単だよ
vector<x> tmp(n);
として、tmp[i].aとtmp[i].bに、a[i]とb[i]をすべてコピー
つぎにtmp[i].aでtmpをソート
a[i]とb[i]にtmp[i].aとtmp[i].bをすべてコピーする
795:デフォルトの名無しさん
06/02/22 20:55:42
>>789
VC6はそういうの苦手なの有名じゃん
796:デフォルトの名無しさん
06/02/22 21:01:24
std::sort(pair_iterator(a.begin(), b.begin()), pair_iterator(a.end(), b.end()));
で、両方のイテレータを操作してくれるような
イテレータアダプタ pair_iterator を作ればいいんじゃね？
797:デフォルトの名無しさん
06/02/22 21:18:41
>>796
それはsort側で両方の要素を同時にswapできるのか？
iteratorの指す先は単一の要素の気がするが
798:797
06/02/22 21:26:45
std::swapを特殊化すればできるかもしれないが、
前スレ
ｽﾚﾘﾝｸ(tech板)
の議論によれば、
std::sortがstd::swapを使用する保証はないらしい
799:デフォルトの名無しさん
06/02/22 21:36:20
>>795
苦手て(w
800:デフォルトの名無しさん
06/02/22 22:08:43
>>799
んじゃ正確に
ダメぽ
801:783
06/02/22 22:50:23
>>798
なるほど、そうですか。。。
>>794 の方法や、>>784 の class x { double a; int seq; } の方法で
地道にやる事にします。sizeof(double) > sizeof(int)なので、転送する
バイト数が少ない int seq の方法が有利かも。
いろいろとどうもありがとうございましたm(__)m ＞ 皆様
802:デフォルトの名無しさん
06/02/22 23:10:09
配列インデックスの配列 vector<size_t> c を作って、
比較関数に a[c[i]] < a[c[j]] のようなものを渡して sort() 。
あとは出来上がった c に従って a, b を並べればいい。
ダメかな？
803:デフォルトの名無しさん
06/02/22 23:13:40
index table (permutation) から実際の配列をソートしなおす
アルゴリズムって結構面倒だったような
804:デフォルトの名無しさん
06/02/22 23:15:46
最適化は後からやればいいんだよ
805:デフォルトの名無しさん
06/02/22 23:24:38
>>803
テンポラリ使えば簡単。
806:783
06/02/22 23:34:43
>>802 >>805 そうですね。この方法がベターな気がします。
どうもありがとうございました。
>>803 あくまでも tmp を使わない方針で、index table から配列を
ソートしなおすアリゴリズムを実装する位なら、最初から自前で
直接 sort する関数を作ってしまう方がよさそう(w
807:デフォルトの名無しさん
06/02/23 02:01:07
車輪の再発明をして、STLとのパフォーマンス差に愕然としないと、
一流のプログラマにはなれませんよね？
808:デフォルトの名無しさん
06/02/23 02:09:05
>>807 先にソースを読んで悟ることができる人もいるだろう。
809:デフォルトの名無しさん
06/02/23 02:12:13
プログラムを書くのも大事だけど、人のソースを読むのもかなり大事なんだよな
能力を高める秘訣については俺も知りたいもんだけど
810:デフォルトの名無しさん
06/02/23 08:09:54
人は、「vectorなんて初心者向けだろｗ」とタカをくくって、後で間違いに気づく。
811:デフォルトの名無しさん
06/02/23 09:56:52
真の初心者にはstd::map<long, T>を使わせるべき。
812:デフォルトの名無しさん
06/02/23 10:45:02
再発明した車輪の改良をして、STLとのパフォーマンス差に優越感を抱いた後で
例外安全とか柔軟性の差に愕然としないと一流のプログラマにはなれません
813:デフォルトの名無しさん
06/02/23 10:48:28
初めて出会った時からSTLにどっぷり依存してるから、
STL使わないという人を本気で不思議に思う。
814:デフォルトの名無しさん
06/02/23 11:03:33
初期の漏れ
どうでも良いところをstl任せにできるから、
重要な部分のチューニングに時間取れてｳﾏｰ!
今の漏れ
パフォーマンスはどうでも良いのでstlで出来ることは非効率でも全てstl任せ。
その分上位構造として複雑なアルゴリズムで難しい処理が実装できてｳﾏｰ!
特定の処理の実行速度だけ見ると昔の漏れの方が優秀・・・
815:デフォルトの名無しさん
06/02/23 11:09:10
STLは、フレームワークでもあるから、
自前特定領域チューニングコンテナを作る時にも設計の手間が大幅に省ける。
ステファノフ万歳
816:デフォルトの名無しさん
06/02/23 11:29:14
>>814
STL使用コードを低レベルなバッファアクセス並みに高速化できないのは、単に君が努力不足だから。
実体コンテナを使うだけでなく、その各要素へのアドレスvectorを利用すれば、
いくらでも低レベルなバッファアクセス並みの速度にできる。
817:デフォルトの名無しさん
06/02/23 11:38:55
sort()がswap()所以で遅いというなら、ポインタ配列に入れてCライブラリのqsort()すればいいだけ。
STLだと遅くなるとか言ってる奴は馬鹿丸出し。
818:デフォルトの名無しさん
06/02/23 11:42:52
>>816
なるほど。んではちょっと教えて欲しいんだけど、
「高々N個程度の物を納める可変長配列
（ただしNは小さくて、全体をスタックにも取れる）」
ってのはどう効率的に書けますか？
vector< int > hoge(); hoge.reserve(N); だと効率悪いし・・・
やっぱり↓こういうのをちゃんと作るのかな。
一度作れば汎用的に使えそうだし。
URLﾘﾝｸ(www.open-std.org)
819:デフォルトの名無しさん
06/02/23 11:44:47
boost 使えばいいのか・・・
820:デフォルトの名無しさん
06/02/23 11:54:29
>>818
＞vector< int > hoge(); hoge.reserve(N); だと効率悪いし・・・
は？vectorのせいじゃなくて、動的メモリを確保するタイミングが悪いだけだろ。
STLコンテナ使用をやめてallocやnewで記述したとしても同じことだ。
設計の段階から見直すことが先だろう。
同じバッファが再利用できないか、つまりは、スコープの見直し。
821:デフォルトの名無しさん
06/02/23 11:57:33
boost::ptr_container ?
早くこれにもシリアライザを用意して欲しいな。
まぁシリアライザだけ自分で書いてもいいけど。
822:デフォルトの名無しさん
06/02/23 11:57:38
>>818
Nが固定ならvector(size_type n)を使おうよ…
823:デフォルトの名無しさん
06/02/23 12:03:27
>>820
再利用できないとき、
あるいはしたくないときにはどうすればよいのか教えてください。
特にマルチスレッドのプログラム（やスレッドセーフなライブラリ）の場合
なかなかそう都合よくは行かないことも多くて。
824:デフォルトの名無しさん
06/02/23 12:05:41
>>822
それだと最初からサイズNじゃない？
>vector< int > hoge(); hoge.reserve(N);
と意味が違うような・・・
というか(スレ違いだけど) boost::array<int, N> hoge; で解決。
825:デフォルトの名無しさん
06/02/23 12:08:14
>>824
あ、やっぱりboost::array は完全固定サイズだから、
「高々Nの可変長」ってのとは違うような・・・
寝ます。
826:デフォルトの名無しさん
06/02/23 12:09:01
>>824
何言っているか理解不能。
お題をちゃんと示せよ。
827:デフォルトの名無しさん
06/02/23 12:12:29
＞なかなかそう都合よくは行かないことも多くて
多いか？
不可能であると頑なに決め付ける根拠が希薄なわけだが。
828:デフォルトの名無しさん
06/02/23 12:22:23
「高々N」は「上限がN」ということなので、上限固定として扱って問題ないと思うが、
「高々N」とはどういう意味で使っているのか?
829:デフォルトの名無しさん
06/02/23 13:28:16
もう面倒だからvalarray使えや
830:デフォルトの名無しさん
06/02/23 13:34:15
多分capacityが不変でsizeが可変なvector風コンテナのことを言ってるんだと思う。
831:デフォルトの名無しさん
06/02/23 13:57:40
だったらvectorでいいような。
832:デフォルトの名無しさん
06/02/23 13:59:10
いや、vectorだとスタックに取れない。
833:デフォルトの名無しさん
06/02/23 14:01:50
上限はそうだけど、なるべくメモリ消費したくないのでは？
834:デフォルトの名無しさん
06/02/23 18:56:02
自分でスタックに確保するアロケータを作ってそいつをstd::vectorに渡せばいけるのでは？
と思ったが、標準のコンテナに渡せるアロケータの要件を守れなさそうな気がする。
835:デフォルトの名無しさん
06/02/23 19:20:58
そこで、std::basic_string<Hoge>。
VC8だと。16バイトまではstackに確保してくれる実装になってた。
836:デフォルトの名無しさん
06/02/23 19:48:35
>>835
basic_stringは制約が・・・
837:デフォルトの名無しさん
06/02/23 23:58:27
>>834
allocate()でalloca()使ったからといって問題になることはないよ。
838:デフォルトの名無しさん
06/02/24 11:28:44
URLﾘﾝｸ(msdn.microsoft.com)
>セキュリティに関するメモ Windows XP では、try/catch ブロック内で _alloca を呼び出した場合は、catch ブロックで _resetstkoflw を呼び出す必要があります。
VC限定だけど、こんなへんてこ仕様の非標準関数はあまり使いたくない
839:デフォルトの名無しさん
06/02/24 11:45:02
べつにallocaなんて使わなくても、内部に配列を抱え込めば済む話じゃ。
840:デフォルトの名無しさん
06/02/24 11:52:01
まあ「高々N」だからな。
841:デフォルトの名無しさん
06/02/24 11:54:41
>>838
変な仕様というか、allocaの引数が可変だから、
スタックチェックに引っ掛からないように調整し直す必要があるんだろ?
通常終了時は関数出口辺りで調整するコードを実行するんだろうけど。
842:デフォルトの名無しさん
06/03/08 19:40:47
STLで環状リストってありますか？
++iteratorでぐるぐる回るやつが理想です。
843:デフォルトの名無しさん
06/03/08 20:41:51
ないです。
844:デフォルトの名無しさん
06/03/08 20:45:42
++iteratorの代わりに、
++iterator; if (iterator == ringList.end()) iterator = ringList.begin();するだけだろ。
845:デフォルトの名無しさん
06/03/08 21:12:04
>>843-844
レスありがとうございます。やはり無いですか。
>>844で示されたようにすればいいんですが、環状リストとして扱っているということを
コード上にも(アルゴリズム的に)反映させたいと思ってたので残念です。
846:デフォルトの名無しさん
06/03/08 21:20:33
>>845
844の動きをするイテレータを自作すればいいと思うのだが。
847:デフォルトの名無しさん
06/03/08 21:43:24
>>844みたいなことを内部的にしたいが為だけにiteratorのクラステンプレートを
自作するのは、まぁ、億劫な話だわな。
848:デフォルトの名無しさん
06/03/08 21:58:09
そこでboost iteratorsですよ。
849:デフォルトの名無しさん
06/03/08 21:58:51
そんなあなたにBoost.Iterator
850:デフォルトの名無しさん
06/03/08 22:01:06
つboost::iterator_adaptor
851:デフォルトの名無しさん
06/03/08 22:04:09
>>848-850
おまえら、合体しる。
852:デフォルトの名無しさん
06/03/09 01:20:26
>848-850をbindしようと思います
853:デフォルトの名無しさん
06/03/09 08:18:30
>>845
添字を循環させるってのはどう?
index = (index + 1) % array.size();
854:デフォルトの名無しさん
06/03/09 08:37:59
>>853
そういうことをするoperator []を持つコンテナを作るってのはどう?
855:デフォルトの名無しさん
06/03/09 08:41:18
>>854
まあ、言いたいのはそういうことです。
fetch_first, fetch_next, fetch_last で実装してもいいかも。
856:デフォルトの名無しさん
06/03/09 14:47:51
boost::iterator_adaptor で実装しようと思ったら思いの他難しいな…。
857:デフォルトの名無しさん
06/03/09 15:51:30
RandomAccessIteratorの要件を満たさないから
そこだけmpl::if_で分岐を入れる必要があるな。
858:デフォルトの名無しさん
06/03/09 15:59:35
ブーストってなんですか＞＜？
859:デフォルトの名無しさん
06/03/09 16:22:14
そろそろ "＞＜" を NG ワードに入れてもいい季節かな？
860:デフォルトの名無しさん
06/03/09 16:25:20
やめてください！＞＜
861:デフォルトの名無しさん
06/03/09 22:36:15
>>857
いや，ベースとなるイテレータが RandomAccess なら満たすんじゃないですか？
862:デフォルトの名無しさん
06/03/09 23:12:35
>>834あたり
遅くなりましたが、
URLﾘﾝｸ(www.tantalon.com)
にある StaticAlloc ってのがそういう感じに使えそうですね。
vector::swap時のアロケータとの整合性とか考えると、
自前でコンテナ書いた方が良いという気もしてきますた。
863:デフォルトの名無しさん
06/03/09 23:23:23
>>861
うまく順序を定められない。
pとqが異なるとき、[p,q)も[q,p)も空でない区間だから、
p < q かつ q < p である必要がある。
864:861
06/03/10 00:30:39
>>863
う～ん，これ設計として大別して2つあるんですね．
今，対象とする範囲の大きさを仮に10としたときに，
it と it + 10 が同値である （it == it + 10 が常に true） というあり方と，
it と it + 10 が同値でない (it == it + 10 が常に false) というあり方の2つです．
自分としては後者の設計を想定していて， it と it+10 はイテレータとしては同値ではなく
単に dereference の結果「たまたま」同じ値が返ってくるだけという考え方です．
この立場ではイテレータアダプタは readable だが writable ではない，となります．
こちらの設計ではイテレータアダプタオブジェクトが，現在の場所を指す
ベースイテレータオブジェクトと何らかのオフセット値を同時に保持する必要があります．
（ただし，ベースが RandomAccess なら保持するのはオフセット値だけで良いです）
多分 863 さん的には前者の立場かと思うんですが，前者の場合
全順序性のような RandomAccess 固有の問題に限らず，
一般に std::distance の意味が一意に定まらず，混乱すると思うので
（最小の正の値を返す，といったような何らかの一貫した立場を取ることはできますが）
個人的にはちょっと設計的に微妙な感じはします．
865:デフォルトの名無しさん
06/03/10 00:54:52
>>864
なるほど、後者の設計を思い付かなかった。
こっちの方がずっと扱いやすそうだ。
866:デフォルトの名無しさん
06/03/10 08:49:14
基本的なことで質問です
STLって便利？ではなくて使ったほうが良いですか？
867:デフォルトの名無しさん
06/03/10 09:11:47
C++でSTL使うのはWindowsをマウスで操作するぐらいに自然なことだ。
868:デフォルトの名無しさん
06/03/10 09:39:06
C++でSTLを使わないのは、裸の女を見てオナニーをするようなものだ。
STLを使うのは、オナニーではなくセックスをするようなものだ。
869:デフォルトの名無しさん
06/03/10 09:44:14
初心者の君が天才でもないかぎり、どんなに頑張ってもSTLより高速なコードは書けないだろう。
870:デフォルトの名無しさん
06/03/10 10:16:35
C++はSTLを使ってこそ本領を発揮できる。
871:デフォルトの名無しさん
06/03/10 10:19:02
>>870
そこまでヨイショするほどのもんでもないと思うが。
でも、STLは使え。>>866
872:デフォルトの名無しさん
06/03/10 10:26:54
>>867
Windowsをマウスを使わずにキーボードショートカットだけで操作するのは別に非効率とは限らないが、
C++でSTLを使わないのは非効率だ。
>>868
裸の女を見てオナニーをしても不毛ではあるがセックスに伴う責任は回避できる。
しかし、C++でSTLを使うことにセックスに伴うような責任は発生しない。
>>866
まぁ、使ってみろ。いいもんだ。
873:デフォルトの名無しさん
06/03/10 10:40:29
そうなんですか・・・これから勉強か～～
874:デフォルトの名無しさん
06/03/10 11:09:03
というか、STLの知識は他の言語でも役立つだろう。
これからどの言語もSTL風のコレクションクラスを持つことになるだろうから。
実際JavaやC#でも…
875:デフォルトの名無しさん
06/03/10 11:28:25
>>874
javaのあの脳味噌が腐ったようなGenerics実装みてよくそんな希望的観測が抱けるな。
876:デフォルトの名無しさん
06/03/10 11:37:25
実装? 仕様じゃなく?
877:デフォルトの名無しさん
06/03/10 11:40:53
>>876
漏れは「仕様」より一つメタな概念としての"Generics"ってのがあって、
C++ の template やら "Java の Generics" ってのはそれの実装だ、
という（脳内で）考えてるので自然に読めますた。
878:デフォルトの名無しさん
06/03/10 11:46:05
まあ仕様の間違いでしょ。
JavaのGenericsは、特殊化なしの制約付きとしてはそれほど悪くないんじゃない？
コアなC++使いにとっては貧弱に思えるけれども。
879:デフォルトの名無しさん
06/03/10 12:21:20
JavaのGenericsは切な過ぎる。
特殊化なしの制約なんてもう耐えられない。
880:デフォルトの名無しさん
06/03/10 12:31:52
特殊化しなくちゃ
881:デフォルトの名無しさん
06/03/10 12:36:26
JavaのCollectionの内部イタレータというのも切ないな。
実装の隠蔽という面からは、あれも正しいんだろうけども。
STL.NETは公開延期だけど、やっぱりJavaよりになるんだろうな。
特殊化はC++とCLOSくらいしかないし。
882:デフォルトの名無しさん
06/03/10 13:40:43
え、特殊化ねーの？(;ﾟДﾟ)
883:デフォルトの名無しさん
06/03/10 15:07:49
C++/CLIはgenericでなく、templateなら特殊化可能だったよ。
genericはnew制約とか余計な思想強制されるんでいらね
884:デフォルトの名無しさん
06/03/12 04:45:43
STLPortの5.0.2を使ってみたりしてるんだけど、
hash_setがなんか遅いような気がする
気のせい？
885:デフォルトの名無しさん
06/03/12 11:44:32
VC7のよりは速い
886:デフォルトの名無しさん
06/03/13 13:54:59
vectorから不連続な複数要素をインデックス指定で一度に効率よく削除するにはどうするのが一番いいんだぜ？
#include <stdio.h>
#include <vector>
#include <algorithm>
template<class T>
bool VectorErase(std::vector<T>& vt, std::vector<unsigned int>& ve)
{
std::vector<T>::iterator p1, p1Src, p1Dst, p1End;
std::vector<unsigned int>::iterator p2, p2End;
unsigned int i, nMaxElement;
// 削除するインデックスが配列サイズより大きいかチェック
nMaxElement = *std::max_element(ve.begin(), ve.end());
if (vt.size() <= nMaxElement){
return false;
}
if (ve.size() > 0){
p2 = ve.begin();
p2End = ve.end() - 1;
for (i = 0; p2 != p2End; ++p2, ++i){
// 次の削除要素までコピー
p1 = vt.begin() + *p2;
p1Src = p1 + 1;
p1Dst = p1 - i;
p1End = vt.begin() + *(p2 + 1) - 1;
for (; p1 != p1End; ++p1){
*p1Dst++ = *p1Src++;
}
}
887:デフォルトの名無しさん
06/03/13 13:55:33
// 次の削除要素がなければ、残りはコピーだけ
p1 = vt.begin() + *p2;
p1Src = p1 + 1;
p1Dst = p1 - i;
p1End = vt.end() - 1;
for (; p1 != p1End; ++p1){
*p1Dst++ = *p1Src++;
}
// リサイズ
vt.resize(vt.size() - ve.size());
}
return true;
}
void main()
{
std::vector<unsigned int> vecData; // 対象データ
std::vector<unsigned int> vecErase; // 削除インデックス (要昇順ソート、ユニーク)
unsigned int i, nMaxData;
nMaxData = 10;
vecErase.push_back(0); vecErase.push_back(4); vecErase.push_back(7); // 削除インデックス作成
for (i = 0; i < nMaxData; ++i) vecData.push_back(i); // データ作成
VectorErase(vecData, vecErase); // 削除実行
for (i = 0; i < vecData.size(); ++i) printf("vecData[%u]: %u\n", i, vecData[i]); // 結果表示
}
888:デフォルトの名無しさん
06/03/13 14:17:13
どうするのが一番いいんだぜ？って何語だぜ？
889:デフォルトの名無しさん
06/03/13 14:41:45
>>887
面倒なことせずに、簡単に行こうよ。それでパフォーマンステストしてから効率を考えよう。
#つーか、>886は効率悪そうでw
テンプレート化はしてないけどするにしても簡単でしょ。
static void VectorErase(vector<unsigned> & vecData, unsigned idx)
{
vecData.erase(vecData.begin() + idx);
}
static void VectorErase(vector<unsigned> & vecData, vector<unsigned> const & vecErase)
{
for (vector<unsigned>::const_reverse_iterator it = vecErase.rbegin(); it != vecErase.rend(); ++it) {
VectorErase(vecData, * it);
}
}
890:デフォルトの名無しさん
06/03/13 15:02:56
なぜvectorから要素を効率よく削除できるのはどうしてだぜ？
891:デフォルトの名無しさん
06/03/13 15:12:13
>面倒なことせずに、簡単に行こうよ。それでパフォーマンステストしてから効率を考えよう。
汎用の部品は最低限の最適化をしておいても損はないと思う。
とりあえず、>>889はO(n^2)なので問題外じゃないだろうか。
892:デフォルトの名無しさん
06/03/13 15:25:50
std::remove_ifは？
893:デフォルトの名無しさん
06/03/13 15:51:35
>>892
std::remove_if()はiteratorが渡されないからインデックス配列を扱う用途には向いてない希ガス。
>>891
同意。しかし、vectorの要素をインデックスで削除する用途はそれほどない希ガス。
>>887
インデックスを作る段階で、std::remove_if()をいきなり実行できないのかな?
894:886@Athlon64 3000+
06/03/13 20:33:38
nicegay達、レスありがとうだぜ？
簡単に試したところ、条件次第でremove_ifと速度が入れ替わる（500～1000万件
で±数十ミリ秒程度）のですが、平均的に速そうでかつムラがなさそうなので、
データクラスに削除フラグを持たせてremove_ifを使う方向で考えてみます。
895:デフォルトの名無しさん
06/03/13 20:52:14
>データクラスに削除フラグを持たせて
ほんとにそんな侵入的な方法が必要なのか？
すごく気持ち悪いんだが。
もちろん、おまえが良いというならそれで良いんだけど。
896:デフォルトの名無しさん
06/03/13 21:37:34
要素がスマートポインタ的な実装の場合、テンポラリvectorに生き残りを
コピーしてvectorごとswapするのが速い悪寒だぜ。
897:デフォルトの名無しさん
06/03/14 00:35:14
日本語でおｋ
898:デフォルトの名無しさん
06/03/14 01:18:36
・削除するインデックスのリストはソート済
・削除する要素が存在しないときの最適化はしていない
という条件だとこんな感じ？
まだまだ汎化＆最適化できそうだけど、もういいや。
void VectorEraser( std::vector<int>& target, std::vector<int>& erase)
{
std::vector<int> result;
std::vector<int>::iterator tb(target.begin());
std::vector<int>::iterator ti(target.begin());
std::vector<int>::iterator te(target.end());
std::vector<int>::iterator ei(erase.begin());
std::vector<int>::iterator ee(erase.end());
while((ti != te)&&(ei != ee)) {
if (*ei == std::distance(tb, ti)) {
++ei; ++ti;
} else {
result.push_back(*ti);
++ti;
}
}
result.swap(target);
}
899:デフォルトの名無しさん
06/03/14 01:23:20
>>894
niceなguyとniceなgayは微妙に違うんだぜ。
両方兼ねている人もいるだろうけど。
900:デフォルトの名無しさん
06/03/14 06:54:23
>>898
それだとtargetとeraseのサイズに比例した一時領域を食うからアンマリ良くないと思う。
コピーを作るより破壊的にコンテナに直書きしていったほうがコストが抑えれる。
void VectorEraser( std::vector<int>& target,const std::vector<int>& erase)
{
std::vector<int>::const_iterator ei(erase.begin());
std::vector<int>::const_iterator ee(erase.end());
std::vector<int>::iterator di(target.begin());
std::vector<int>::iterator tb(target.begin());
std::vector<int>::iterator ti(target.begin());
std::vector<int>::iterator te(target.end());
for(;ei != ee;++ei) {
std::vector<int>::iterator x(tb);std::advance(x,*ei);
di = std::copy(ti,x,di);
ti = ++x;
}
di = std::copy(ti,te,di);
target.resize(std::distance(target.begin(),di));
}
901:デフォルトの名無しさん
06/03/14 11:31:03
>>900
ループの最初の一回を外に出してコピーしないようにすると
より高速になりますね。
最初にif (ei != ee)が要りますが。
902:デフォルトの名無しさん
06/03/16 18:36:16
質問失礼します。
現在構造体にSTL stringのメンバを複数おいて利用しているのですが、
どうもメモリリークが起きてしまいます。
起きているのはそのメンバに有効な文字列（１バイト以上）が入ったときのみのようです。
入るのはoperater =によってです。
Debug実行の後の出力では
c:\program files\microsoft visual studio .net 2003\vc7\include\crtdbg.h(689) : {68} normal block at 0x00CD2568, 32 bytes long.
と、出力されています。構造体にstringは使用出来ないのでしょうか？
ご教授お願いします。
903:デフォルトの名無しさん
06/03/16 18:38:55
>>902
レガシーな構造体のつもりで安直なメモリ転送したりメモリコピーをしていなければ大丈夫。
904:902
06/03/16 18:44:46
memcpy Zeromemory等の関数は使用してないです。
もちろんstring内データ直アクセスも。
構造体内に構造体が３つあってそこにもstringやらintやら混ざってるのが悪いのでしょうか。
･･･そんなわけないですよねぇ･･･。
ちなみにSTLは.NET2003標準のやつです。
905:902
06/03/16 18:56:06
度々すみません。情報追加です。
構造体を使用しているのはクラスのpublicメンバで、
m_typData.strA = "aaaaaaaaaaaaaaaa";
等としたところでリークしていました。また、上記例から文字が一文字減るとおきませんでした。
その直前までsrAは未初期化の状態です。
906:デフォルトの名無しさん
06/03/16 19:06:34
>>904
その構造体を free で解放してたりしませんか？
907:902
06/03/16 19:11:14
>>906
していません。したら落ちます、構造体自体はそのまま
TYPE_DATA typData; の様な使い方をしているので。
string以外のメンバはint DWORD SIZE RECT POINT さらに構造体などですが、
いずれもメモリ操作系の関数は使用しておらず、すべてoperater =や+=等ばかり使用しています。
908:デフォルトの名無しさん
06/03/16 19:27:56
とりあえず再現性のある最小のコードを貼れ。
話はそれからだ。
909:902
06/03/16 19:34:37
最小ソースです Win32 Console VC++.NET 2003で作成
// CRTデバッグ
#define _CRTDBG_MAP_ALLOC
// CRTデバッグ
#include "stdlib.h"
#include "crtdbg.h"
#include <string>
using namespace std;
struct TYPE_A
{
string a;
};
void main(void)
{
TYPE_A typData;
typData.a = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
// CRT メモリリーク確認
_CrtDumpMemoryLeaks();
return;
}
910:デフォルトの名無しさん
06/03/16 19:39:07
>>909
typDataがスコープから抜ける前にリークチェックしてるよ
911:デフォルトの名無しさん
06/03/16 19:41:20
あと
・mainの戻り値にvoidはやめなさい。
・stdlib.hやcrtdbg.hがなぜ""で囲まれてるのか？
912:デフォルトの名無しさん
06/03/16 19:41:56
正しくはこうやるみたいですよ。試してませんが。
void main()
{
TYPE_A typeData;
typData.a = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
_CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
return;
}
913:902
06/03/16 19:57:38
解決しました。
実際の方ではWinMainの中でクラス変数を宣言し（そのクラスが構造体を持ってるのです）クラスの関数を走らせ終了する
ようなものになっていたのですが、クラスをポインタにしてnew 及び deleteを行えば解決しました。
STLの問題では無く申し訳ありません。同じスコープ内で有効な物に対してはチェックがうまく働かないと知りませんでした。
ご教授ありがとうございました。
914:902
06/03/16 20:03:39
>>911
前に勤めていた会社の先輩にSTLは<>、その他は""と習ったからです。
違うのでしょうか。
void main(void)に関しても高校時代のポケコンCが･･･
いろいろと間違った知識を使ってきたみたいで恥ずかしいです
>>912
調べて下さってありがとうございます。
試してみたところ_CrtDumpMemoryLeaks無しで終了時にチェックが働く様になりました。
915:デフォルトの名無しさん
06/03/16 20:16:43
>>913
new, deleteしなくても
int main()
{
{
TYPE_A typeData;
typData.a = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
}
_CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
return 0;
}
ってすればいいんだけどな。
916:デフォルトの名無しさん
06/03/16 20:22:39
>>914
> 前に勤めていた会社の先輩にSTLは<>、その他は""と習ったからです。
（´Д｀）
917:デフォルトの名無しさん
06/03/16 20:24:02
>>914
前の会社なら問題ないだろうから、その会社名と先輩とやらの名前を晒せ。
ローカルなインクルード以外は全て<>にするのが常識だ。
#プロジェクトローカルをどっちにするかは悩ましいところだが。
918:デフォルトの名無しさん
06/03/16 21:41:43
>>914
その先輩はSTLを標準ライブラリ全てを指す言葉として使っているに違いない。
919:デフォルトの名無しさん
06/03/16 22:20:00
きっとSTLがSTandard Libraryの略だと思ってるんだよ
920:デフォルトの名無しさん
06/03/16 22:27:15
まぁSTLという区分の曖昧さ・中途半端さにも若干の業はあると思うけれど、
その先輩はそれを言い訳にしちゃいけない領域に居るお馬鹿さんだな。
921:デフォルトの名無しさん
06/03/17 10:05:08
STL作った人は余程の自信があるんだろうな。
俺のソースは恥ずかしくて見せられない。＞＜
922:デフォルトの名無しさん
06/03/17 10:35:31
>>921
自信が無くても見せなければならない。
……、それがテンプレートの定め。
923:デフォルトの名無しさん
06/03/17 10:46:39
ｲﾔﾝ
924:デフォルトの名無しさん
06/03/17 13:00:47
ベクトルのリザーブってするとどんな利点があるの？
925:デフォルトの名無しさん
06/03/17 13:09:32
性能的に有利な場合がある
一個ずつpush_backしていくと何度も内部でrealloc©しちゃうけど
reserveしとけばそのサイズを越えるまで無駄なrealloc©をしないことが保証される
reallocによるメモリの断片化の防止とかもあるけど
いちいちメモリ確保&コピーコンストラクタ呼び出しするコストは馬鹿に出来ない
926:デフォルトの名無しさん
06/03/17 13:10:10
＆copyが©になっちゃう件について
927:デフォルトの名無しさん
06/03/17 13:35:17
>>925
あり＾＾
928:デフォルトの名無しさん
06/03/17 13:52:34
>>926
&copyって書けばいいだけのこと。(©)
929:デフォルトの名無しさん
06/03/17 13:53:39
ま、それだけのこと
930:デフォルトの名無しさん
06/03/17 14:00:34
♥
931:デフォルトの名無しさん
06/03/17 14:05:42
ああリザーブってキャパシティを保証するだけですか。
もともとキャパシティが必要個数分以上になってれば、リザーブなんか考えずに
ぼんぼこ必要分までプッシュバックしていっておｋ？
932:デフォルトの名無しさん
06/03/17 14:52:32
＞ああ給油ってのはガソリン入れるだけですか。
＞もともとガソリンが必要な量だけ入っていれば、給油なんか考えずに
＞ぼんぼこ目的地まで走っていっておｋ？
OK。
933:デフォルトの名無しさん
06/03/17 15:55:03
リザーブしただけでアプリのメモリ使用量は増えますか？
934:デフォルトの名無しさん
06/03/17 16:06:59
増えるかもしれないし増えないかもしれない。
そもそもreserve()で何もしない処理系もある。
935:デフォルトの名無しさん
06/03/17 16:09:41
>そもそもreserve()で何もしない処理系もある。
それは規格違反な気がするが。
どの処理系？
936:デフォルトの名無しさん
06/03/17 16:37:10
934じゃないけど。
Windowsのことかなー
あいつはallocしても、仮想メモリ空間のアドレスに空きがあればOKのフリするし。
実際にメモリをアクセスしに行ってPageエラーをキャッチして本物の仮想メモリを割り当てる
ってことやってるから、そのタイミングでswapファイルが作れなくなってあぼーんとか、ある。
937:デフォルトの名無しさん
06/03/17 17:40:42
>>936
それは「何もしない」とは大分違うような気がする。
938:デフォルトの名無しさん
06/03/17 23:26:13
resize()で今より大きい個数指定したら再確保すると思うんですが、
その時ってちゃんとリザーブして確保とか、考えられる限り高速に設計されてますか？
939:デフォルトの名無しさん
06/03/17 23:28:43
もちろん
940:デフォルトの名無しさん
06/03/17 23:30:38
じゃあ僕は安心してリサイズすればいいのですね＾＾
ありがとうございました
941:デフォルトの名無しさん
06/03/17 23:31:51
>>938
複雑度が線形以下で実装されていることが保証されている。
「高速に設計」されているかどうかは知らない。
942:デフォルトの名無しさん
06/03/17 23:33:51
そもそもreserve()なんて使いません＞＜
943:デフォルトの名無しさん
06/03/17 23:43:34
>>942
使えよ（必要ならば）。
944:デフォルトの名無しさん
06/03/18 01:58:19
C++の人達は呑気でイイですね
945:デフォルトの名無しさん
06/03/18 02:08:55
>>944
そんなわけあるか！
禿げが禿げてんのだってきっとストレスが原因だ！
946:デフォルトの名無しさん
06/03/18 02:16:58
しかしあれだけC++使える香具師にどんなストレスがあるって言うんだ
947:デフォルトの名無しさん
06/03/18 02:27:49
禿げが気になって気になってストレスたまるんだと・・・
948:デフォルトの名無しさん
06/03/18 02:59:51
おまいらが禿禿言うからだろ
言ったやつ謝れよ
949:デフォルトの名無しさん
06/03/18 04:44:02
ごめ…
950:禿
06/03/18 05:01:04
ちゃんと謝れ(`_ゝ´)
951:デフォルトの名無しさん
06/03/18 05:03:37
ごめんなさい＞＜
952:デフォルトの名無しさん
06/03/18 07:35:58
子曰く、放屁也。
953:デフォルトの名無しさん
06/03/18 11:47:14
禿げはビオチン不足が原因の可能性がある
サプリで摂れって
ビオチンは、糖尿病や肥満の対策にも有効だぞ
英語の綴りはbiotinだ
954:デフォルトの名無しさん
06/03/18 12:18:12
>>953 禿はセックスのやり過ぎだと思う。
だれか訊いてきて来んない？本人に。
955:デフォルトの名無しさん
06/03/18 13:59:12
禿げは
L-システイン
L-メチオニン
亜鉛
が不足している。
956:http://www.vector.co.jp/soft/win95/util/se072729.html
06/03/18 18:28:18
TextSS の64bit化おながいします
もしくは64bitにネイティブ対応した置換ソフトないですか？
957:デフォルトの名無しさん
06/03/18 19:21:36
>>956
スレ違い。マルチ乙。
あと氏ね。
958:デフォルトの名無しさん
06/03/19 21:02:01
大体マルチする程の内容ですらないしな
959:デフォルトの名無しさん
06/03/22 09:09:37
VC8でSTLport5.0.2をビルドすると、最後に「パブリックシンボルが
見つかりません」というリンカの警告が一つ出るな。
ま、ライブラリはビルド出来て使えたが、気になる。
960:デフォルトの名無しさん
06/03/22 09:15:40
ま、気にするな。
961:デフォルトの名無しさん
06/03/22 09:19:00
>>960
レス㌧クス。ま、5.0.2そのものがVC8 Beta用みたいだから、
VC8の正式版が出てる今日、STLportもVerUPすると期待してる。
962:デフォルトの名無しさん
06/03/22 10:17:19
ま、少なからず、近いうちに問題解決されるんじゃねぇかな。
963:デフォルトの名無しさん
06/03/22 17:06:28
おまいら週に何回オナニーしますか？
僕は最近めっきり減りました。
964:デフォルトの名無しさん
06/03/22 21:25:22
だいたい７回くらいかな。
曜日は火曜と金曜と決めている。
965:デフォルトの名無しさん
06/03/22 22:39:29
曜日決めてまとめてやるんですか。。。
966:デフォルトの名無しさん
06/03/22 22:59:37
STLは制限の多い組み込みとかの開発でも使い物になります？
967:デフォルトの名無しさん
06/03/22 23:01:34
最悪アロケータとか自分でどうにかできるなら
968:デフォルトの名無しさん
06/03/22 23:04:40
ﾄﾝｸｽ
969:デフォルトの名無しさん
06/03/22 23:10:13
STLがしっかり実装できるほど、
まともにテンプレートが使える、
組み込み向けのC++コンパイラなんてあるのかな。
970:デフォルトの名無しさん
06/03/22 23:17:45
組み込み向けってもピンキリだけどな。
URLﾘﾝｸ(www.toppers.jp)
こんなもんまであるご時世だし。
971:デフォルトの名無しさん
06/03/22 23:34:09
コンパイラに組み込み向けも糞もないんじゃないの?
ライブラリならともかく。
972:デフォルトの名無しさん
06/03/22 23:47:21
EC++とかはもうどうでもいいにせよ、世の中gccとか対応してないどマイナーなアーキテクチャなどいくらでもある
973:デフォルトの名無しさん
06/03/23 00:34:20
>>966
コンテナはともかく、アルゴリズムとファンクタはとても役に立つ！
974:デフォルトの名無しさん
06/03/23 02:31:39
>>973
例えば？
975:デフォルトの名無しさん
06/03/23 02:33:19
>>974
fill とか copy とか transform とか、いくらでもあるだろ。
976:デフォルトの名無しさん
06/03/23 10:11:49
>>974
equal_range でも sort でも remove_copy_if でも配列に対して使える。
一緒に bind などもどうぞ。
977:デフォルトの名無しさん
06/03/27 14:01:59
Apache C++ Standard Library
URLﾘﾝｸ(incubator.apache.org)
ってどんなもん？みんな使ってる？便利？
978:デフォルトの名無しさん
06/03/27 15:16:06
まず何でここで訊くのかが解らん
979:デフォルトの名無しさん
06/03/27 15:19:05
ここが一番適切なような気が駿
980:デフォルトの名無しさん
06/03/27 16:32:29
>>977
中身はほとんどRogueWaveのままだから、STLportよりは落ちる。
それにslistやhash_mapなど、SGI STL特有の便利なコンテナが無い。
Dinkumwareでさえ採用しているというのに。
981:デフォルトの名無しさん
06/03/27 16:56:51
ソースの読みやすさは、Apache C++ Standard Library が一番だと思うよ
982:デフォルトの名無しさん
06/03/27 18:55:16
ああ、それは俺もそう思う。使っちゃいないが。
983:デフォルトの名無しさん
06/03/28 16:57:58
次ぎスレは
C++相談室に合流ってことで
なしということでよろしく
984:デフォルトの名無しさん
06/03/28 17:16:10
合流かぁ・・・・C++相談室は時々荒れるからなぁ
985:デフォルトの名無しさん
06/03/28 18:46:40
え～このままでいいんじゃないの？
無くていいならそのうち落ちるって。
986:デフォルトの名無しさん
06/03/28 18:49:53
C++ｽﾚの人口から見て、次ｽﾚを建てる必要性はないと思う
987:デフォルトの名無しさん
06/03/28 19:49:04
毎度要らないという結論になるのに誰かが立ててしまう。
そんなこんなで4スレ目まで来てしまった。
いい加減このスレは終わらせようよ。
988:デフォルトの名無しさん
06/03/28 19:50:48
まだだ・・・
まだ終わらんよ・・・
989:デフォルトの名無しさん
06/03/28 20:24:30
>987
一部の人間が勝手に結論してるだけに見えるんだが気のせいかね
990:デフォルトの名無しさん
06/03/28 20:52:09
[合流するべき理由]
STLは規格により明確にC++である
>>988,989
理由は
991:デフォルトの名無しさん
06/03/28 21:34:22
またはじまったんかｗ
992:デフォルトの名無しさん
06/03/28 22:02:52
次ぎスレ
ｽﾚﾘﾝｸ(tech板)
993:デフォルトの名無しさん
06/03/28 22:18:00
バーロ、まだはじまっちゃいねーよ
994:デフォルトの名無しさん
06/03/29 00:32:51
>>992
GJ!
でも一瞬あせったよ、また立てたのかとね。
995:デフォルトの名無しさん
06/03/29 05:46:34
後で次スレ立てておくよ。
996:デフォルトの名無しさん
06/03/29 05:55:55
次スレ
【注意】STLの落とし穴【危険】
ｽﾚﾘﾝｸ(tech板)
997:デフォルトの名無しさん
06/03/29 08:53:54
>>998-100
もし立てたいと思うのなら、
その前に必ず>>992か>>996のスレで提案すること。
>>983-を見れば少なからず次スレを要らないと思っている奴が居るのがわかるはず。
998:デフォルトの名無しさん
06/03/29 08:57:34
>>996を再利用で、それを使い切ってから次スレでいいだろ。
999:デフォルトの名無しさん
06/03/29 10:59:22
ああ、それがこのスレの総意だな。
1000:デフォルトの名無しさん
06/03/29 12:15:07
1000なら、STLの呼称廃止
1001:１００１
Over 1000 Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。