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
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。