C++の問題点について語るスレです
C++ってなんであんなに肥大化しちゃったの?
http://pc11.2ch.net/test/read.cgi/tech/1219902495/
探検
【信者】C++の問題点【アンチ】
■ このスレッドは過去ログ倉庫に格納されています
2008/10/10(金) 09:13:53
124デフォルトの名無しさん
2008/10/18(土) 00:55:05 C++のIDEに自動的にヘッダやnamespaceを宣言してくれる奴って何かあります?
Javaとかだと適当にクラス使ってもクラスパスから候補探してくれるのがメジャーなIDEの基本機能にある。
Javaとかだと適当にクラス使ってもクラスパスから候補探してくれるのがメジャーなIDEの基本機能にある。
125デフォルトの名無しさん
2008/10/18(土) 05:16:34126デフォルトの名無しさん
2008/10/18(土) 05:38:24 自動的にヘッダを追加するようなIDEは怖くて使えません
127デフォルトの名無しさん
2008/10/18(土) 13:39:49 さすが生産性の無さでユーザーがみるみる減っている言語だけはあるw
128デフォルトの名無しさん
2008/10/18(土) 13:56:13 >>124
C++のヘッダのincludeは単なるプリプロセッサ命令で、やってることは
原始的なコピペ
Javaは自己記述的なjarやclassからシンボルをインポートしてるわけだ
C++でそういうことをやるのは技術的に不可能ではないだろうが
向いているとは思えんな
現代的なIDEなどが出るよりはるか以前に作られた化石言語なのだから仕方が無い
C++のヘッダのincludeは単なるプリプロセッサ命令で、やってることは
原始的なコピペ
Javaは自己記述的なjarやclassからシンボルをインポートしてるわけだ
C++でそういうことをやるのは技術的に不可能ではないだろうが
向いているとは思えんな
現代的なIDEなどが出るよりはるか以前に作られた化石言語なのだから仕方が無い
129デフォルトの名無しさん
2008/10/18(土) 14:06:23 C++はIDEととことん相性悪いからな
まるでIDEを妨害しようとしているかのような仕様
VSやBuilderやCDTはマジ頑張ってると思うのですよ
頭が下がる
まるでIDEを妨害しようとしているかのような仕様
VSやBuilderやCDTはマジ頑張ってると思うのですよ
頭が下がる
130デフォルトの名無しさん
2008/10/18(土) 21:29:58 C++を有難がって使ってる奴なんているの?
居たとしたらちょっと馬鹿すぎる
居たとしたらちょっと馬鹿すぎる
131デフォルトの名無しさん
2008/10/18(土) 21:38:06 文句なしの代替が無いから使っているだけだよ。
132デフォルトの名無しさん
2008/10/18(土) 22:40:11 有難がって使うプログラミング言語なんてないだろ。
133デフォルトの名無しさん
2008/10/18(土) 22:51:52134デフォルトの名無しさん
2008/10/18(土) 22:53:30 C++が一番簡単だから使ってる
135デフォルトの名無しさん
2008/10/18(土) 22:59:07 結局、
136デフォルトの名無しさん
2008/10/18(土) 23:00:16 結局、このスレにC++信者なんて居なかったってオチか
137デフォルトの名無しさん
2008/10/19(日) 01:23:10 >>105
↑頭悪いねこれ。
↑頭悪いねこれ。
138デフォルトの名無しさん
2008/10/19(日) 14:06:06 C++が最高だと思って使ってる奴はいないだろ。
ただ分かってない上司やクライアントがいるからC++の仕事もあるってだけだ。
本当はCで十分だったり、C#やJavaの方が効率良かったりするんだが。
ただ分かってない上司やクライアントがいるからC++の仕事もあるってだけだ。
本当はCで十分だったり、C#やJavaの方が効率良かったりするんだが。
139デフォルトの名無しさん
2008/10/19(日) 14:12:04 C#やJavaをフロントエンドにして、
OS依存部分や、処理が思い部分を
C言語で書くスタイルがベストだな。
既にOracleがそうだし、CADもそういうのがある。
OS依存部分や、処理が思い部分を
C言語で書くスタイルがベストだな。
既にOracleがそうだし、CADもそういうのがある。
140デフォルトの名無しさん
2008/10/19(日) 14:23:15 C++はプログラム初級〜中級者向けのおもちゃとしてはそこそこ面白い
だが普通はすぐに暗黒面に気付いて使うのを辞めるor仕事で仕方なく使うだけだ
だが普通はすぐに暗黒面に気付いて使うのを辞めるor仕事で仕方なく使うだけだ
141デフォルトの名無しさん
2008/10/19(日) 14:41:12 その通り過ぎて何も言えねえ…
良い代替言語があれば良いんだけどね
良い代替言語があれば良いんだけどね
142デフォルトの名無しさん
2008/10/19(日) 14:53:48 D言語がふらふらしてなければなw
創始者が「仕様変えるぞー」を未だに自粛しないからこまったものだ。
創始者が「仕様変えるぞー」を未だに自粛しないからこまったものだ。
143デフォルトの名無しさん
2008/10/19(日) 16:11:15 まあ暗黒面に気付かないうちはまだまだ初心者ってことだ
それに気付いた時にはバッドノウハウばかりで他言語に応用が効かないのも悔しいところだ
それに気付いた時にはバッドノウハウばかりで他言語に応用が効かないのも悔しいところだ
144デフォルトの名無しさん
2008/10/19(日) 16:19:28 Plan9(笑)
D言語(笑)
D言語(笑)
145デフォルトの名無しさん
2008/10/19(日) 16:37:25 バッドノウハウを追求するのは楽しい
しかしチームでやる仕事ではゴメンだね
しかしチームでやる仕事ではゴメンだね
146デフォルトの名無しさん
2008/10/22(水) 11:30:38 クライアントから例外もテンプレートも(わからないから)使わないで欲しいって言われた
周辺環境もある意味では言語の問題点に含まれると思う
特にC++の場合、ひとによってスキルの差がありすぎ
せっかくのリソースが活かせないことが多い
まあ割の良い仕事だから我慢するけど、これならCの方が開発効率良いよorz
周辺環境もある意味では言語の問題点に含まれると思う
特にC++の場合、ひとによってスキルの差がありすぎ
せっかくのリソースが活かせないことが多い
まあ割の良い仕事だから我慢するけど、これならCの方が開発効率良いよorz
147デフォルトの名無しさん
2008/10/22(水) 17:05:15 Cの方が開発効率良い、に関しては、
だったらクラスも何も使わないでC同然に書けばいいじゃないと思う。
だったらクラスも何も使わないでC同然に書けばいいじゃないと思う。
148デフォルトの名無しさん
2008/10/22(水) 17:14:26149デフォルトの名無しさん
2008/10/22(水) 18:05:19150デフォルトの名無しさん
2008/10/22(水) 19:03:52 >>149
147でないけど
キャストは new の仕様を促すからそのほうがいいんじゃない。new の方が楽で型安全だし。
extern "C" はCとリンクする部分だけでいいよ。普通の C のライブラリだって extern "C" 使ってるし。
extern "C" を使わないほうが型安全だし。
147でないけど
キャストは new の仕様を促すからそのほうがいいんじゃない。new の方が楽で型安全だし。
extern "C" はCとリンクする部分だけでいいよ。普通の C のライブラリだって extern "C" 使ってるし。
extern "C" を使わないほうが型安全だし。
151デフォルトの名無しさん
2008/10/22(水) 19:18:08 >>150
newは例外まみれで鬱陶しい別の問題を引き起こすだろ
ただの関数形式のアロケータなら差し替えるのも簡単だ
C++をC++らしく使わないという仮定の話をしているようだから
それぐらいならCの方がいいと言ってるんだよ
クラスすら使わないC++で提供される付加価値よりは
グダグダなABIだの、さりげなく仕込まれる例外対策だののほうがずっと鬱陶しい
newは例外まみれで鬱陶しい別の問題を引き起こすだろ
ただの関数形式のアロケータなら差し替えるのも簡単だ
C++をC++らしく使わないという仮定の話をしているようだから
それぐらいならCの方がいいと言ってるんだよ
クラスすら使わないC++で提供される付加価値よりは
グダグダなABIだの、さりげなく仕込まれる例外対策だののほうがずっと鬱陶しい
152デフォルトの名無しさん
2008/10/22(水) 21:07:44 > ただの関数形式のアロケータなら差し替えるのも簡単だ
それと同じくらいnewの差し替えも簡単だ。
void* operator new(std::size_t n)
{
return my_alloc(n); //NULLを返せば例外はthrowされない
}
void operator delete(void* p)
{
my_free(p);
}
//以下コピペするだけ
void* operator new[](std::size_t n)
{
return operator new(n);
}
void operator delete(void* p)
{
operator delete(p);
}
いや、これもずっと鬱陶しい「さりげなく仕込まれる例外対策」の内というならそれまでだけど。
それと同じくらいnewの差し替えも簡単だ。
void* operator new(std::size_t n)
{
return my_alloc(n); //NULLを返せば例外はthrowされない
}
void operator delete(void* p)
{
my_free(p);
}
//以下コピペするだけ
void* operator new[](std::size_t n)
{
return operator new(n);
}
void operator delete(void* p)
{
operator delete(p);
}
いや、これもずっと鬱陶しい「さりげなく仕込まれる例外対策」の内というならそれまでだけど。
153デフォルトの名無しさん
2008/10/23(木) 00:24:04 bad_allocが嫌ならnothrowつきのnewを使えばいいじゃない
ただ、例外を使わないようにするとどうせNULLチェックをサボる奴が出てくるので
むしろ有害だと思うけどな
ただ、例外を使わないようにするとどうせNULLチェックをサボる奴が出てくるので
むしろ有害だと思うけどな
154デフォルトの名無しさん
2008/10/23(木) 02:02:52 NULLチェックをサボるために例外を使うってことは、newする部分をまとめてtryに入れるんだろうけど、
スマートポインタかGCでもない限り、メモリリークの危険性がある。
STLで用意されてるauto_ptrはSTLコンテナに食わせられない糞仕様。
スマートポインタかGCでもない限り、メモリリークの危険性がある。
STLで用意されてるauto_ptrはSTLコンテナに食わせられない糞仕様。
155デフォルトの名無しさん
2008/10/23(木) 08:09:11 CAutoPtr
156デフォルトの名無しさん
2008/10/23(木) 11:08:44157デフォルトの名無しさん
2008/10/23(木) 11:46:55 std::tr1::shared_ptrかboost::smart_ptrのどっちかと間違えてるんだと思うが
どっちにしろどうしても必要な所で最低限の使用にしないと重すぎて酷いことになるからなぁ
auto_ptrはそこそこ軽いから割と気軽に使える
まあ、本当は生ポインタが一番いいんだけどな
プログラマが楽をするためだけにスマポの莫大なオーバーヘッドを持ち込むのは感心できない
どっちにしろどうしても必要な所で最低限の使用にしないと重すぎて酷いことになるからなぁ
auto_ptrはそこそこ軽いから割と気軽に使える
まあ、本当は生ポインタが一番いいんだけどな
プログラマが楽をするためだけにスマポの莫大なオーバーヘッドを持ち込むのは感心できない
158デフォルトの名無しさん
2008/10/23(木) 12:17:44 プログラマに苦労を強いると、バグの発生率が跳ね上がるでしょ。
多くの状況ではオーバーヘッドよりバグの方が深刻な問題になるんだから、楽はすべきだと思うけど。
多くの状況ではオーバーヘッドよりバグの方が深刻な問題になるんだから、楽はすべきだと思うけど。
159デフォルトの名無しさん
2008/10/23(木) 13:12:15 C + Boehm GCでいいやん
スマポなんかより便利だし
スマポなんかより便利だし
160デフォルトの名無しさん
2008/10/23(木) 13:21:50 >>157
boost::smart_ptr なんて存在しない。
どっちも shared_ptr。
あとオーバーヘッドなんて大したことないぞ。
ポインタに参照カウントの分の整数がついて回るだけ。
ポインタアクセス時は通常のポインタとほぼ同等
(レジスタ割り付けが多少阻害されるかもしれんが)。
コピーやデストラクト時に参照カウントの増減でこれも一瞬。
boost::smart_ptr なんて存在しない。
どっちも shared_ptr。
あとオーバーヘッドなんて大したことないぞ。
ポインタに参照カウントの分の整数がついて回るだけ。
ポインタアクセス時は通常のポインタとほぼ同等
(レジスタ割り付けが多少阻害されるかもしれんが)。
コピーやデストラクト時に参照カウントの増減でこれも一瞬。
161デフォルトの名無しさん
2008/10/23(木) 19:05:25 boost::intrusive_ptr 方式のスマートポインタが好き。
162デフォルトの名無しさん
2008/10/23(木) 20:50:24 UN*X では Objective-C が使えるから無理して C++ を使う必要は無いよね
163デフォルトの名無しさん
2008/10/23(木) 21:02:12 >>162
極一部のUnix以外ではCが主流というオチ。
極一部のUnix以外ではCが主流というオチ。
164デフォルトの名無しさん
2008/10/23(木) 21:22:07 unixだとc++なんか有象無象とひとつ
165デフォルトの名無しさん
2008/10/23(木) 21:28:01166デフォルトの名無しさん
2008/10/27(月) 19:09:41 C++
↓
C++0x
↓
C++(笑)
↓
C++0x
↓
C++(笑)
167デフォルトの名無しさん
2008/10/29(水) 13:28:21 newの例外の問題がなんなのか良くわからんが
template<class T>class vAlloc{
public:
T *m_obj;
vAlloc() : m_obj(NULL){};
vAlloc(int size) : m_obj(NULL){
Alloc(size);
};
~vAlloc(){
delete []m_obj;
};
Alloc(int size){
delete []m_obj;
try {
m_obj = new T[size];
} catch(std::bad_alloc) {
cerr << "メモリを増設してください" << endl;
m_obj = NULL;
exit(0);
}
};
};
こういうクラスを作っといて
vAlloc<char> str1(100);
strcpy(str.m_obj, "Hello");
こうやって利用すればいいんでないの?
template<class T>class vAlloc{
public:
T *m_obj;
vAlloc() : m_obj(NULL){};
vAlloc(int size) : m_obj(NULL){
Alloc(size);
};
~vAlloc(){
delete []m_obj;
};
Alloc(int size){
delete []m_obj;
try {
m_obj = new T[size];
} catch(std::bad_alloc) {
cerr << "メモリを増設してください" << endl;
m_obj = NULL;
exit(0);
}
};
};
こういうクラスを作っといて
vAlloc<char> str1(100);
strcpy(str.m_obj, "Hello");
こうやって利用すればいいんでないの?
168デフォルトの名無しさん
2008/10/29(水) 13:34:53 >>167
言いたい事は分かるけど、コピーコンストラクター位はつけた方がいいと思うんだ
言いたい事は分かるけど、コピーコンストラクター位はつけた方がいいと思うんだ
169デフォルトの名無しさん
2008/10/29(水) 13:46:13 「解決できるけどデフォルトで放置されている問題」が多いんだな
170デフォルトの名無しさん
2008/10/29(水) 13:55:15 >>167
なんだそれ
vAlloc<char> str1(100);
なんてやるなら
char str1[100];
でいいだろ
そのクラスはそれ以上のものをそれは何も提供していないし
何の解決にもなっていない
なんだそれ
vAlloc<char> str1(100);
なんてやるなら
char str1[100];
でいいだろ
そのクラスはそれ以上のものをそれは何も提供していないし
何の解決にもなっていない
171デフォルトの名無しさん
2008/10/29(水) 14:02:26 STLとかはAllocator差し替えられるけど
alloc()が例外投げること前提に作られてて
NULLチェックなんてしてるわけねーし
C++でデフォのnew捨てるってのは
事実上、標準を含む大半のライブラリを捨てるってこと
alloc()が例外投げること前提に作られてて
NULLチェックなんてしてるわけねーし
C++でデフォのnew捨てるってのは
事実上、標準を含む大半のライブラリを捨てるってこと
172デフォルトの名無しさん
2008/10/29(水) 14:03:41173デフォルトの名無しさん
2008/10/29(水) 14:05:16174デフォルトの名無しさん
2008/10/29(水) 14:09:13 コンストラクタやデストラクタが動くんだからalloca()の代用は言いすぎか
まあ、そういうことが言いたいんじゃなくて、newが使われるシナリオの
ごくごく一部しかカバーできていないだろ、といいたいんだよ
まあ、そういうことが言いたいんじゃなくて、newが使われるシナリオの
ごくごく一部しかカバーできていないだろ、といいたいんだよ
175デフォルトの名無しさん
2008/10/29(水) 14:41:56176デフォルトの名無しさん
2008/10/29(水) 16:21:08 >>167
そんなことするならset_new_handlerとvector(もしくはboost::scoped_array)で十分だと思う。
そんなことするならset_new_handlerとvector(もしくはboost::scoped_array)で十分だと思う。
177デフォルトの名無しさん
2008/10/29(水) 16:50:22178デフォルトの名無しさん
2008/10/29(水) 17:37:38179デフォルトの名無しさん
2008/10/29(水) 18:06:25 そういうことか。よく見てなかった。
つうかabort()だのexit()だの呼んでる時点でダメだろ
つうかabort()だのexit()だの呼んでる時点でダメだろ
180デフォルトの名無しさん
2008/10/29(水) 19:09:35 俺の探し方が悪いのか、abort()だのexit()だの呼んでる以外のサンプルコードを見た事がない
181デフォルトの名無しさん
2008/10/29(水) 19:13:25 ま、new handlerでできることはそれぐらいだろ
つまり、new handlerは、「それでいい」プログラムにしか使えないってことだよ
つまり、new handlerは、「それでいい」プログラムにしか使えないってことだよ
182デフォルトの名無しさん
2008/10/29(水) 19:39:56 予めでっかいメモリを確保→newハンドラで解放すれば、
ヒープに空きができてnewを成功させられるぜっていう話を聞いたことがある。
実用性皆無にしか思えない。
ヒープに空きができてnewを成功させられるぜっていう話を聞いたことがある。
実用性皆無にしか思えない。
183デフォルトの名無しさん
2008/10/30(木) 01:39:17 new handler で必ずしも必要でないキャッシュをパージすることが考えられる。
Java の SoftReference がそんな感じ。
Java の SoftReference がそんな感じ。
184デフォルトの名無しさん
2008/10/30(木) 09:41:16 bad_allocが発生する様な環境下で、必要のないキャッシュを持つ設計が正しいのだろうか?
185デフォルトの名無しさん
2008/10/30(木) 10:01:22 あっちと内容がかぶってる
C++が糞言語なのはみんな知ってるから一箇所でやってくれないかな
C++が糞言語なのはみんな知ってるから一箇所でやってくれないかな
186デフォルトの名無しさん
2008/10/30(木) 13:05:43 どこ?
187デフォルトの名無しさん
2008/11/02(日) 04:11:41 >>172
C++ってそんな事も出来ないのかw
C++ってそんな事も出来ないのかw
188デフォルトの名無しさん
2008/11/02(日) 07:33:07 配列ごときをいちいち動的にヒープに取るような非効率言語とは違うんですっ!
189デフォルトの名無しさん
2008/11/02(日) 08:49:23190デフォルトの名無しさん
2008/11/02(日) 11:53:20 >>189
Cは低級言語だから別にいいんだよw
Cは低級言語だから別にいいんだよw
191デフォルトの名無しさん
2008/11/02(日) 12:23:05192デフォルトの名無しさん
2008/11/02(日) 12:37:38 C言語は高級言語だろ・・・
抽象化水準が低いから中級言語って言う奴はいたけど。
抽象化水準が低いから中級言語って言う奴はいたけど。
193デフォルトの名無しさん
2008/11/02(日) 12:54:55194デフォルトの名無しさん
2008/11/03(月) 19:11:25 演算子のオーバーロードはヤバイと
ム半年目の頃に既に俺は思ってたね
関数の引数が参照渡しなのもヤバイ
ム半年目の頃に既に俺は思ってたね
関数の引数が参照渡しなのもヤバイ
195デフォルトの名無しさん
2008/11/03(月) 21:30:24 演算子多重定義関数での引数と言えば、const参照が相場だろ。
2行目が値渡しでないからやばいと言っているのであればそれは違う。
2行目が値渡しでないからやばいと言っているのであればそれは違う。
196デフォルトの名無しさん
2008/11/03(月) 22:35:07 const参照渡しが安全だと思ってるアホ発見
197デフォルトの名無しさん
2008/11/04(火) 00:23:34 Cに++した程度の言語だ
やばくて当たり前だっての
オブジェクト指向アセンブラに何処まで求めてるんだ?
やばくて当たり前だっての
オブジェクト指向アセンブラに何処まで求めてるんだ?
198デフォルトの名無しさん
2008/11/04(火) 00:39:19 本当に C に ++ してくれたのなら、どんなに良かった事か…
本当の意味で C with Class だったら更に良かったんだがな
残念言語
本当の意味で C with Class だったら更に良かったんだがな
残念言語
199デフォルトの名無しさん
2008/11/04(火) 02:52:09 >>192
お前その発言がどんだけ化石か自覚してるのか?
お前その発言がどんだけ化石か自覚してるのか?
200デフォルトの名無しさん
2008/11/04(火) 09:33:16 C++の++は良く分からん物でオーバーロードされてるだろ
201デフォルトの名無しさん
2008/11/05(水) 18:03:54 もしかしたら実際の処理は--かもしれない
202デフォルトの名無しさん
2008/11/05(水) 18:33:56 そしてC++の仕様上、それを知る事は不可能に近い
203デフォルトの名無しさん
2008/11/06(木) 16:48:48 >194-196のやりとりがよくわかりません。
演算子定義をconst参照で受けて、さらに注意しなければいけないことって何?
演算子定義をconst参照で受けて、さらに注意しなければいけないことって何?
204デフォルトの名無しさん
2008/11/06(木) 18:08:29 多分、>>196 にしか解らない深い理由があるんだろう。
205デフォルトの名無しさん
2008/11/06(木) 19:33:21 const_cast
206デフォルトの名無しさん
2008/11/06(木) 20:24:16 それくらいでびくついているようではC++なんて使えないけどな。
全くもってそこらじゅう罠だらけだもん。
全くもってそこらじゅう罠だらけだもん。
207デフォルトの名無しさん
2008/11/06(木) 21:22:36 ・constなんてconst_castや普通のキャストで誰でも簡単に外せる
・constを外さなくたってmutableメンバがあれば変更し放題
・deleteに対してconstは全く無力
何かを安全にするつもりでconstを使ってるなら、それは時間の無駄です
constは何も守ってくれません
・constを外さなくたってmutableメンバがあれば変更し放題
・deleteに対してconstは全く無力
何かを安全にするつもりでconstを使ってるなら、それは時間の無駄です
constは何も守ってくれません
208デフォルトの名無しさん
2008/11/06(木) 21:45:34 const_cast は使うこと自体が有害だと思われ
209デフォルトの名無しさん
2008/11/06(木) 21:46:39 気休めにしかならないと分かっていても、すがりたくなる。
ほかに信じられるものなんて何もないから。
ほかに信じられるものなんて何もないから。
210デフォルトの名無しさん
2008/11/06(木) 21:51:57 setの要素を変更する時にconst_castは不可欠です
211デフォルトの名無しさん
2008/11/06(木) 21:58:17 あれってconst付いていたっけ?
212デフォルトの名無しさん
2008/11/06(木) 22:04:48 setの要素を直接変更したらまともに動作しないぞ
removeしてからinsertしないと
removeしてからinsertしないと
213デフォルトの名無しさん
2008/11/07(金) 02:46:00 EffectiveSTLの22番だな
214デフォルトの名無しさん
2008/11/07(金) 03:43:36 比較関数が見ないメンバであれば問題ない。
215デフォルトの名無しさん
2008/11/07(金) 09:35:55 const_castなんてC++の問題ではなく、C++を利用するプログラマの問題だろ
217デフォルトの名無しさん
2008/11/07(金) 16:23:46 で、外注先のプログラマに問題が無い事は誰が保障してくれるんだ?
言語側で保障してりゃ良いだけの事を、本当に非効率的な言語(笑)だわ。
言語側で保障してりゃ良いだけの事を、本当に非効率的な言語(笑)だわ。
218デフォルトの名無しさん
2008/11/07(金) 17:01:39 問題のあるプログラマを雇っている外注なんぞ切ってしまえ
219デフォルトの名無しさん
2008/11/07(金) 17:05:50 また始まった
ぼくはそんなつかいかたしないからC++はわるくないんだい!!
なんか本気で言ってそうでかわいそうになる
ぼくはそんなつかいかたしないからC++はわるくないんだい!!
なんか本気で言ってそうでかわいそうになる
220デフォルトの名無しさん
2008/11/07(金) 17:29:08 何のためにconst_castがあるのかも考えず、不用意に使うような奴を擁護する事の方が信じられん
きっと、大阪の轢き逃げみたいな事件を起こすような奴に違いない
きっと、大阪の轢き逃げみたいな事件を起こすような奴に違いない
221デフォルトの名無しさん
2008/11/07(金) 17:53:25 はいはい、今度は論点のすり替えですね
フルコースですか
次のメニューをお願いします
フルコースですか
次のメニューをお願いします
222デフォルトの名無しさん
2008/11/07(金) 17:54:41 レッテル張りも消化済みでしたね
引き続きどうぞ
引き続きどうぞ
223デフォルトの名無しさん
2008/11/07(金) 18:12:17 そもそも、言語側で保障する方が非効率だから、保障しなかったのにね
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 【速報】「女芸人No.1決定戦 THE W」9代目女王にニッチェ! 7年ぶり3度目で悲願の優勝 [牛丼★]
- 「おこめ券は米以外の食品も買える。効果的な活用を」 地元で農水相 [山形県] [少考さん★]
- 【芸能】『女芸人No.1決定戦THE W』 粗品が最後にバッサリ「優勝賞金1000万円にしてはレベル低い大会」 [冬月記者★]
- いじめ後遺症 15年前のトラウマに苦悩する当事者「夢の中に出てくる」「された側は一生ものの傷」 [♪♪♪★]
- 今年の流行語大賞 『働いて働いて働いてまいります』が受賞で不快感… 過労自殺の遺族らが会見「家族にむち打つような行為だ」 [冬月記者★]
- 東京の自販機そばに金塊4200万円分、何者かに持ち去られる…札幌の50代が8000万円振り込んだ後に上京して被害 [どどん★]
- お前「趣味……?ないですね。無趣味です」ぼく「ずっと2chしてるんだから2chが趣味でいいじゃん」前「?」
- 【正論】検察「山上よ、どんな事情があろうと暴力が許されない」 [442080748]
- 🏡パン🍞つー✌まる👌見え👊😅👊
- 実写映画「ストリートファイター」のキャラアートが公開。何か知らん人がいる…… [624898991]
- 【朗報】愚鈍な日本入ついに気ずく「高市より進次郎のほうがマシだったのでわ…」 [743999204]
- なんかさ100万くらい欲しいよな
