【C++】STL（Standard ..
348:デフォルトの名無しさん
08/01/27 02:32:47
>>341
文字数ならサロゲートを割ってしまうことはないよ。
サロゲートペア一組で一文字だから。
349:デフォルトの名無しさん
08/01/27 02:33:58
wchar五個分でなくて、5「文字」分きちんと取れるコードを？
350:デフォルトの名無しさん
08/01/27 02:35:13
たとえば、
「か゛」は１文字という扱いでいいのか？
「か゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛゛(略」
みたいなどうしようもない連中はどうしよう？
351:デフォルトの名無しさん
08/01/27 02:38:26
>>348
std::string(wstring)の「文字数指定」は、1文字が固定長のコード体系が前提だから、サロゲがあると壊れるよ。
>>350
それペアになってなくない？
352:デフォルトの名無しさん
08/01/27 02:38:36
>>348
>サロゲートペア一組で一文字
一組で4バイト(結合文字は6バイトもある)
で、文字数(というより2バイト単位)指定はアウト。
s = サロゲート文字列
s2 = s.substring(0, 5)
とかやったらあぼーんでしょ
353:デフォルトの名無しさん
08/01/27 02:42:20
>>352
文字数というのは、キャラクタ数という意味で使った。
354:デフォルトの名無しさん
08/01/27 02:47:21
CString的にTCHAR使えてさらにクロスなものはないのかね？
355:デフォルトの名無しさん
08/01/27 02:48:52
>>350
合成文字は2キャラクタでしょ。
合成文字をぶった切ると、意味は通じなくなるかもしれないが違法ではない。
356:デフォルトの名無しさん
08/01/27 02:53:07
ああ、その「キャラクタ数」というのは、要するにUTF-32換算なわけか。
357:デフォルトの名無しさん
08/01/27 03:00:31
Winではstringは使うな。2バイト目が1バイト目とかぶってやがるからな。
wstringはサロゲートに注意して使え。途中で切るなよ。
Win98とかまだやってるカスはCStringでも使ってろ。
LinuxではstringでもEUCとUTF-8は2バイト目が1バイト目とかぶらないからまだ
なんとかなるはずだ。
クロスにしたいなら文字列クラスは当然自前だろ？
が俺の現状の認識
358:デフォルトの名無しさん
08/01/27 03:02:31
>>327
ハァ?
359:デフォルトの名無しさん
08/01/27 03:09:34
>>358
へ？
360:デフォルトの名無しさん
08/01/27 03:14:40
>>357
追加でMac OS XはCFString使っとけ。以上。
361:デフォルトの名無しさん
08/01/27 04:50:39
>>357
OS 関係なくてエンコーディングの話だろ？
Windows でも UTF-8 使えば問題ないし、 Linux でも Shift_JIS 使えば問題は出る。
クロスにしたければエンコーディングを OS 任せにしなければ良いだけの話。
たとえば UTF-8 を使うと決めれば std::string でもいけるでしょ。
362:デフォルトの名無しさん
08/01/27 05:05:46
>>361
だけの話・・って、実際にUTF-8でやったことないんだろ？試しにやってみなよ。
APIに渡すとき、コンソルに出すときすべてに変換をかます必要あるだろ？
文字リテラルはどうするんだ？ソース内のUTF-8はまだコンパイラのサポートが微妙だぞ。
現実的じゃないんだよ。OSが正式にサポートしてるSJISとかUTF-16以外を
内部エンコーディングにするのは。
363:デフォルトの名無しさん
08/01/27 05:33:05
１文字が何バイト使うかはどれ使っても一定ではない どれを使うか決まっていればどれ使ってもよい
364:デフォルトの名無しさん
08/01/27 05:48:20
UTF-32は4バイト固定。でも合成文字があるので結局同じ問題は残る。
365:デフォルトの名無しさん
08/01/27 06:53:55
一方ロシアはモールス符号を使った
366:デフォルトの名無しさん
08/01/27 06:59:29
合成文字なんて捨てろ
すべての文字を表現したいなんて無駄の極み
367:デフォルトの名無しさん
08/01/27 08:26:25
おいおい、放棄かよ
368:デフォルトの名無しさん
08/01/27 08:37:31
>>362
入出力と多言語以外の問題はなし 日本語使うんだったらどれでも同じ
入出力にコンバートするのに手間がかかるかどうかだけ
369:デフォルトの名無しさん
08/01/27 10:08:29
全部画像でおｋ
370:デフォルトの名無しさん
08/01/27 12:33:49
16x16ピクセル（256ビット）のパターンで全ての文字を表現するとかどっかで見たな。
371:デフォルトの名無しさん
08/01/27 13:24:31
文字コード総合スレだと思った
つーかPDFでおｋ
372:デフォルトの名無しさん
08/01/27 13:25:37
( д ) ﾟ ﾟ
373:デフォルトの名無しさん
08/01/27 15:15:28
>>365
一方ロシアは画像を使った
こっちの方がしっくりくるな。
374:デフォルトの名無しさん
08/01/27 15:52:02
>>370
宇宙の星にそれぞれ新しい文字で名前つけてもあまるだろｗ
375:デフォルトの名無しさん
08/01/27 16:26:01
一文字32バイトは流石に先取りしすぎだな
376:デフォルトの名無しさん
08/01/27 16:37:26
string path = "c:\\機能仕様書\\01.doc";
path.find("\\");
こんなであぼーんするstringは危険としか言いようがない
377:デフォルトの名無しさん
08/01/27 16:47:52
そんなアホなことをする方が悪い。
378:デフォルトの名無しさん
08/01/27 16:55:52
1文字に1GB
379:デフォルトの名無しさん
08/01/27 16:56:20
もう OCR でいいよ・・・
380:デフォルトの名無しさん
08/01/27 17:24:37
人間様の認識能力を利用する形が最強
381:デフォルトの名無しさん
08/01/27 17:28:05
人間なんてよく読み間違うじゃん
382:デフォルトの名無しさん
08/01/27 17:56:59
>371
CID(AJ15)のことか？ あのコードも印刷以外に使うのは
結構アレなんだけどなー。
383:デフォルトの名無しさん
08/01/27 18:00:16
Ｃ＋＋
メンバ関数内で
スコープ解決演算子で
classname::メンバ変数 の値変更するのと
this->メンバ変数 の値変更するのは何が違うの？
384:デフォルトの名無しさん
08/01/27 18:04:56
struct P{int m;};
struct C : public P{ int m;
void f(){ this->m = 0; this->P::m = 1; }
};
みたいな話。
385:デフォルトの名無しさん
08/01/27 18:07:20
>>377
findが使えないstringって・・・カスめ
386:デフォルトの名無しさん
08/01/27 18:09:21
path[path.find("\\")] == '\\'になるじゃん、ちゃんと。
387:デフォルトの名無しさん
08/01/27 18:12:41
返答ありがとう。
最初の
this->m は Ｃ のオブジェクトのメンバ変数ｍ
this->P::m は何でしょうか？
388:デフォルトの名無しさん
08/01/27 18:14:13
>>386
まじか？
389:デフォルトの名無しさん
08/01/27 18:16:16
>>386
そりゃなるだろwww
390:デフォルトの名無しさん
08/01/27 18:16:42
>>387
P の m にきまっちょるだろう
391:デフォルトの名無しさん
08/01/27 18:22:57
>>386
マジレスすると「能」の2バイト目の「\」がfindで見つかっちゃったんです。
string s = SJISの日本語;
はやっちゃだめなんです。初心者はみんなやってしまうんですが。
392:デフォルトの名無しさん
08/01/27 18:23:56
>>384
>>390
継承したときに変数名かぶった場合コウ書くんですね。
でも、多重に継承した場合、どう書くんだろう？
393:デフォルトの名無しさん
08/01/27 18:29:12
scope
394:デフォルトの名無しさん
08/01/27 18:35:01
>>392
間の型へ一旦 this をアップキャストすると良い。
395:デフォルトの名無しさん
08/01/27 18:35:31
>>391
だから、find とか使わない分には使っていいんだってばよ。
396:デフォルトの名無しさん
08/01/27 18:35:39
あー、ダイヤモンド継承か。
P1::P2::Pb::a = 100;
みたいに、継承順を追いかければ指定できたような・・・
397:デフォルトの名無しさん
08/01/27 18:37:14
char []hoge = SJIS文字列; とかやって、
strchr( hoge, '\\'); ってまずいじゃん。
でも、「char配列にSJIS文字列入れるの禁止」って言うのはどうよ、みたいな。
398:デフォルトの名無しさん
08/01/27 18:37:36
別の言語の癖が出てるぜ
399:デフォルトの名無しさん
08/01/27 18:37:59
>>397
そうそう。そんな感じ。
400:デフォルトの名無しさん
08/01/27 18:42:17
文字コードの話って、荒れる割に全然面白くないし、有用な知見も得られないんだよな。
401:デフォルトの名無しさん
08/01/27 18:44:35
結局毛唐が ASCII 以外どうでもいいと思ってるからな。
402:デフォルトの名無しさん
08/01/27 18:47:46
何も考えずに動いていたCStringがなつかすぃ。。
そういえばなんでがんばってfind禁止のダウングレードのstd::string使ってるん
だったっけ？
だれかどこでも動くCString作ってぇぇ
403:デフォルトの名無しさん
08/01/27 18:49:03
>>393
>>394
>>396
ありがと。
やっぱＣ＋＋はスゲーや。
Ｃのシンプルな文法に慣れきったオレには奥が深いぜ。
404:デフォルトの名無しさん
08/01/27 18:49:05
ドザは Windows のことしか考えないから困る。
405:デフォルトの名無しさん
08/01/27 18:52:20
どこでも動く？
どこでもSJIS使うの？
406:デフォルトの名無しさん
08/01/27 18:52:31
Linuxとかｶｽいらねーし
407:デフォルトの名無しさん
08/01/27 18:54:02
Mac では SJIS 使わん事も無い。
UTF-8 や EUC も使うが。
408:デフォルトの名無しさん
08/01/27 18:57:06
ASCII自体が腐ってるからな。誰だよ、あんなコードにしたのは。
409:デフォルトの名無しさん
08/01/27 18:58:30
>>405
いや、できればマクロとかでプラットフォームごととか文字コードとか
切り替えられてさ、当たり前だけどfindとかも問題なく動いちゃうやつ。
CStringみたいに楽に使えて、でもUTF-8とか16とかも平気な感じ。
std::ustringみたいに統一しちゃってさ。boostとかかな。
410:デフォルトの名無しさん
08/01/27 18:59:32
findだけの問題ならすぐ解決するけどな。
ただ、SJISのままだと単純サーチにするしかないので効率は悪い。
411:デフォルトの名無しさん
08/01/27 19:01:36
>>410
そりゃWinの場合は内部的には_mbsstr呼ぶとかして高速化しる
412:デフォルトの名無しさん
08/01/27 19:01:45
wstringに自動変換する const char *n_str();と
wstring(char*)を付ければ解決するような気になるけど？
413:デフォルトの名無しさん
08/01/27 19:01:47
>>406
普通sunだよな
414:デフォルトの名無しさん
08/01/27 19:05:17
Windows なら mbs 系でおkだが、
他の環境だとその手の関数あるんだろうか。
415:デフォルトの名無しさん
08/01/27 19:22:06
ついでに質問なのですが、TCHARみたいにstringとwstringを切り分けるにはどう
すればよいのでしょうか？以下のようにしておく必要があるのでしょうか？
他にもっといい方法があるのでしょうか？
#ifdef UNICODE
#define tstring string
else
#define tstring wstring
まだ98でもXPでも動かしたいので・・
416:デフォルトの名無しさん
08/01/27 19:23:31
組み込み型にしてもいい位のデータ構造なのに
クロスに作るのが難しいこんな世の中じゃ
417:デフォルトの名無しさん
08/01/27 19:25:51
>>415
とりあえず #define よりは typedef のほうがいいだろうな。
418:デフォルトの名無しさん
08/01/27 19:30:39
>>415
なにかわからないがよくないことが起こりそうな悪寒
419:デフォルトの名無しさん
08/01/27 19:41:43
charとwchar_tも切り替えないと。リテラル使ってるところがあったらそれもマクロで囲まないとね。
…めんどくさいでしょ。
420:デフォルトの名無しさん
08/01/27 19:45:37
つまり、C++0xのユーザ定義リテラルの登場を待てと
421:デフォルトの名無しさん
08/01/27 19:51:06
>>419
それは TCHAR と _T として既に用意されているだろう。
422:デフォルトの名無しさん
08/01/27 23:53:01
>>415
typedef std::basic_string<TCHAR> tstring;
>>362
361のようなことを現実にやれるソフトウェアでは、
多言語対応のため、文字列リテラルの大半はソースコードに含まれないとか、
APIはラッパー層があるから変換も余裕とかそういう次元にいると思う。
423:デフォルトの名無しさん
08/01/28 00:52:04
実際文字列リテラルをまったく含まないのはたいへんだぞ〜。
メッセージ的なものはともかくfind(":")的なパース類もすべてfind(COLON)とか
にして事前にUTF-8で用意しておかなくちゃいけなくなるし、全WinAPIをラップする
のはいよいよ無理だろうに。カレントディレクトリ一つ取るのも
GetCurDir(string& s){
TCHAR t[PATH_MAX];
::GetCurrentDirectory(PATH_MAX, t);
#ifdef UNICODE
Utf-16からUTF-8に変換
#else
SJISからUTF-8に変換
}
的にすべてのラップ関数を用意してあげなきゃいけなくなるし。。
424:デフォルトの名無しさん
08/01/28 00:57:46
> find(":")
他に理由がなければ、ASCII分はそのままソースに書いていいと思った。
425:デフォルトの名無しさん
08/01/28 00:59:56
そんなわけがないだろ。
426:デフォルトの名無しさん
08/01/28 01:02:52
A 系使えば大丈夫。
427:デフォルトの名無しさん
08/01/28 01:34:22
せっかくWinがUTF-16なのに内部エンコーディングをUTF-8にして、API呼ぶたびに
UTF-8からUTF-16に変換はちょっとやだなあ。
全てのAPIをラップする開発コストに加えて、実行時の変換コストまでかかるし。。
やっぱWinはUTF-16でいきたいね。
428:デフォルトの名無しさん
08/01/28 01:37:11
いい加減スレチガイだということに(ry
429:デフォルトの名無しさん
08/01/28 09:45:10
std::string/wstringは最重要のコンテナだしスレ違いとは思わんが・・
結局文字コード周りはいまいちなのがわかるだけなんだよなあ。。
430:デフォルトの名無しさん
08/01/28 14:04:09
話の流れぶった切って申し訳ないが言わせてくれ。
なんか良スレの悪寒。
431:デフォルトの名無しさん
08/01/28 15:13:29
日本語と中国語の区別ができない腐れた文字コードそれがUnicode
中国が大体元凶だけどな
432:デフォルトの名無しさん
08/01/28 15:26:40
> 内部エンコーディングをUTF-8にして、
> API呼ぶたびにUTF-8からUTF-16に変換
Dのことかー！
433:デフォルトの名無しさん
08/01/28 16:15:55
>>431 4.0からは区別できますよ
434:デフォルトの名無しさん
08/01/28 16:34:19
>>431
言語の区別ができない文字コードはUnicodeに限らないんだよ
435:デフォルトの名無しさん
08/01/28 17:12:12
ユニコードは本格的多国語環境や16ビット固定長を宣伝文句にしていたからねえ。
次々と撤回して期待外れだったよな。
436:デフォルトの名無しさん
08/01/28 17:37:19
だから、多国語ではなく多文字だったと。
437:デフォルトの名無しさん
08/01/28 17:44:51
見苦しい
438:デフォルトの名無しさん
08/01/28 18:07:33
ユニコードって、UNIXの文字コードだったから
ユニコードって言うんだよね。
439:デフォルトの名無しさん
08/01/28 18:27:51
おまいらいい加減スレ違いだぞコノヤロー。
440:デフォルトの名無しさん
08/01/28 19:13:14
>>438-439
しらんかった
441:デフォルトの名無しさん
08/01/28 19:15:54
ユニコード表みるとハングルが異様なほど文字数が多い
中国だけじゃないぞ
442:デフォルトの名無しさん
08/01/28 19:24:34
>>441
ハングルは現在全く使用されない組み合わせも全部作るように
韓国が強く要求したんだと
それでbatangが異常に膨れている。
韓国死ねよ。
443:デフォルトの名無しさん
08/01/28 19:30:25
>>442 にほんだって「あ゛」とかいれてるじゃん。
444:デフォルトの名無しさん
08/01/28 19:35:52
URLﾘﾝｸ(unicode.org)
ここをみるかぎり、「あ゛」は単一のコードとして存在しないようだが
445:デフォルトの名無しさん
08/01/28 19:57:49
ごめん、勘違いだったかも。でも日本人だって「あ゛」いれたいしぃ。
可変長で6バイトでもよくなったんだから、なんでもいれていいと思う。
446:デフォルトの名無しさん
08/01/28 19:59:46
>>443
やあチョーセンジン
447:デフォルトの名無しさん
08/01/28 20:06:35
>>442 欧米人にしたらCJK死ねよなわけだが。
なんでなかよくできんもんかね。
448:デフォルトの名無しさん
08/01/28 20:10:36
仲の良い隣国つーのは歴史上稀なわけだが。
稀つーかあるのか。
449:デフォルトの名無しさん
08/01/28 20:13:08
日本だって古代は中国と仲良かったじゃん。
あと、中国と韓国。
どちらも、主従関係だけどｗ
450:デフォルトの名無しさん
08/01/28 20:42:13
「仲良かった古代」、って遣唐使廃止まででそ。1000年も前の話だし。
451:デフォルトの名無しさん
08/01/28 21:41:37
当時は海ってのは命がけで渡るもの凄い大きな壁だったわけで、
隣国っつーよりは、日本とアメリカ・・・は言い過ぎかもしれんが、
そんな感じだったと思うぜ。
452:デフォルトの名無しさん
08/01/28 21:47:52
♪ ♪ ＼＼ ♪ 僕ら〜はみんな〜 生〜きている〜 ♪.／／ ♪ ♪
♪ ＼＼ ♪ 生き〜ているけど チョンは氏ね〜 ♪／／ ♪
♪ ∧ ∧ ∧ ∧ ∧ ∧ ∧ ∧ ∧ ∧ ∧∧ ♪
♪ ∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*) ♪
(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧
♪ ∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)♪
─♪─(ﾟ0 ﾟ*)｜ U(ﾟ0 ﾟ*)｜ U(ﾟ0 ﾟ*)｜ U(ﾟ0 ﾟ*)｜ U(ﾟ0 ﾟ*)｜ U(ﾟ0 ﾟ*)｜ U
| U.｜ | | U | ｜| Ｕ. | ｜| Ｕ. | ｜| Ｕ. | |｜ Ｕ. | |〜♪
♪ | | U U. | ｜ U U | | U U | | U U | | Ｕ Ｕ | | U U ♪
U Ｕ U U U U U U U U U U
453:デフォルトの名無しさん
08/01/28 22:06:43
URLﾘﾝｸ(www.open-std.org)
こんなのがあったのね。知らんかった
確かにゲームや組み込みではSTLそのまま使うのはキツイわな
454:デフォルトの名無しさん
08/01/28 22:11:55
>>447
電脳創世記っていう本にあったんだが、そもそも「CJKその他ヨーロッパの小国死ねよ」
ってやってる連中はアルファベットしかないコードしか使ってなくて、それを日本人が
「文字コード問題は俺たちが解決して業績上げますからメリケン共は口出ししなくても良いよ＾＾」
って挑発して今の流れになったんだと思う。
455:デフォルトの名無しさん
08/01/29 02:36:05
>>453
ゲームがメモリをキツキツに使うからって、数バイト〜数十〜数百バイト単位の
標準ライブラリのメモリ確保までキツキツにしても、あんまり関係ないと思うんだ。
どうせ画像やサウンドデータが１個増えればだけでそこらへんの努力は
吹っ飛ぶもんじゃないの？処理負荷にしてもさ。
456:デフォルトの名無しさん
08/01/29 02:42:20
>>442
漢字使用国がそれだけは言っちゃいかんだろ
「じゃお前ら文字数が多すぎるから統合ね」と言われても何も言い返せない
むしろ韓国みたいにもっと初期の段階で分離しろと言い張れば分離できたかも
しれないのに日本人おとなしすぎ
457:デフォルトの名無しさん
08/01/29 02:55:03
文字、文字コード関係はこっちいけよ
458:デフォルトの名無しさん
08/01/29 02:55:33
ｽﾚﾘﾝｸ(tech板)
459:デフォルトの名無しさん
08/01/29 02:58:15
英語・日本語・中国語間のソフトやマニュアルの翻訳をやってるけど
ほぼ同じ意味の文章なら中国語が一番少ないデータサイズで書ける
460:デフォルトの名無しさん
08/01/29 03:06:02
そんなの中国語知らん俺でも分かるっちゅーの
461:デフォルトの名無しさん
08/01/29 03:47:21
utf-8で？
アニメの中国語のfansubとか見るとかなが入った日本語と
漢字ばっかりの中国語で文字数そんなに変わらんように見えたけど。
だから画数で言えば中国語は不利。
462:デフォルトの名無しさん
08/01/29 04:43:57
一文字に線をたくさん詰め込むんだから、字数が少なくならないとおかしい。
ような気もする。
463:デフォルトの名無しさん
08/01/29 06:14:49
>>455
ゲーム機はメインメモリ領域が結構キツイんでないの
464:デフォルトの名無しさん
08/01/29 06:33:10
>>440
嘘過ぎる
465:デフォルトの名無しさん
08/01/29 06:40:30
さすがに>>440は釣りじゃないのか
466:デフォルトの名無しさん
08/01/29 06:41:36
>>462
ちょうどいいのがなかったけど、これとか
URLﾘﾝｸ(jp.youtube.com)
467:デフォルトの名無しさん
08/01/29 07:28:09
詩とか台詞の翻訳はちょっと特殊じゃないか？
ってどこへ行こうとしてるんだこのスレは
468:デフォルトの名無しさん
08/01/29 15:13:48
標準STLではunicodeをちゃんと扱えるんでしょうか？
処理系依存では（例えばVC++とか）扱えそうですけど。
469:デフォルトの名無しさん
08/01/29 16:35:57
ちゃんと扱う、の定義次第。
wstring, wchar_t を問題なく扱えればOKなのか？それなら問題ないよ。
ロカール処理やエンコーディング変換のための十分なサポートがあるか？それなりしかない。
470:デフォルトの名無しさん
08/01/29 21:06:41
>>455
コンテナ(というかアロケータ)のメモリ効率は重要だと思うが。
アラインメントやページ境界にかなり気をつかっているらしい。
演算効率についてはちょっと読みきれていないが...
inline展開とか命令キャッシュ効率とか、分岐予測の弱いプロセッサのこととか、
いろいろ書いてある。
でかいボトルネックは取り除いた上でさらにどうがんばるかって話では。
>>463
"Game platform memory metrics"ってところに主要なゲーム機のspecが書いてある。
471:デフォルトの名無しさん
08/01/29 21:17:44
EAがやたらマルチプラットフォームでゲームを作れるのは
この辺がしっかりしてるからかな
まぁ無理だろうけど、一部位公開してほしいな
472:デフォルトの名無しさん
08/01/29 23:48:57
VC9でライブラリを作ろうとするとえらーがでます。
使えないですか？
473:デフォルトの名無しさん
08/01/29 23:53:57
主語を書け。
474:デフォルトの名無しさん
08/01/30 00:12:34
むちゃぶりだな
475:デフォルトの名無しさん
08/01/30 00:50:00
バージョンは5.1.5です。
476:デフォルトの名無しさん
08/01/30 01:43:11
わたし にほんご わかりません
477:デフォルトの名無しさん
08/01/30 01:59:02
ベンチャーキャピタルが図書館の設立に失敗？
478:デフォルトの名無しさん
08/01/30 15:09:31
STLportじゃないの
479:デフォルトの名無しさん
08/01/31 12:03:42
マルチスレッドにてqueueを使いたいのですが、
STL等にセマフォを任せることは出来ないでしょうか？
480:デフォルトの名無しさん
08/01/31 12:06:11
基本的にSTLはスレッドセーフではない。
481:デフォルトの名無しさん
08/01/31 12:31:30
>>479
いまどきの実装であれば、たいていドキュメントにマルチスレッドについて書かれている。
そういう記述が無いとか、書かれた保証では不十分だとか、広い移植性が必要だとか、
ドキュメントを読むのがメンドイとか言うんなら自分でなんとかするしかない。
482:デフォルトの名無しさん
08/01/31 18:06:11
std::stringの配列の連続性は保障されてないそうですが、
実際配列が連続じゃない実装をしてる環境ってあるんですか？
483:デフォルトの名無しさん
08/01/31 18:10:37
配列じゃないよ
484:479
08/01/31 18:50:24
>>480-481
ありがとうございました。 無い事が分かって安心しました。
必死で作って、既に有ったらかなり凹むのでｗ（勉強にはなるけど）
WinAPIのCreateSemaphore()かmutexで検討したいと思います。
485:デフォルトの名無しさん
08/01/31 19:52:11
まあ実際はc_str()の動作を速くするために連続の場合が多いけどな。
しかもヌルターミネータ文字まで入ってたり。
486:デフォルトの名無しさん
08/01/31 19:54:51
>>482
ない。というか、次期の規格（C++0x）で連続性が保証されるようになる。
N2461) 21.3.1 basic_string general requirements [string.require]
3 The char-like objects in a basic_string object shall be stored contiguously.
That is, for any basic_string object s, the identity &*(s.begin() + n) == &*s.begin() + n
shall hold for all values of n such that 0 <= n < s.size().
487:デフォルトの名無しさん
08/01/31 19:58:43
std::ropeは標準じゃないけど、初めから切れ切れの文字列を
つなぎ合わせる事を想定してるな。
488:デフォルトの名無しさん
08/01/31 20:01:32
だからstd::ropeにはメンバ関数c_str()がない。
489:デフォルトの名無しさん
08/01/31 20:02:47
でもSTLportのstd::ropeにはc_str()があったりする。変なの。
490:デフォルトの名無しさん
08/01/31 20:04:03
標準じゃないのに std を使うのは違和感あるよな。
491:デフォルトの名無しさん
08/01/31 20:06:10
STLportはSGI-STLに妙なこだわりを持ってるよな。
何か言われてんのかな。
492:デフォルトの名無しさん
08/01/31 21:13:41
> 基本的にSTLはスレッドセーフではない
例えばどんな場合？
493:デフォルトの名無しさん
08/01/31 21:15:33
>>492
どんな場合って・・・何するにしてもスレッドセーフを要求する
仕様なんてないはずだけども。
494:デフォルトの名無しさん
08/01/31 21:17:02
STLportはスレッドセーフだったような
495:デフォルトの名無しさん
08/01/31 21:21:14
うーん、書いてないとスレッドセーフでないってのも・・
beginthread一回でも呼ぶプロセスではstlは一行も使えないってことに
なりそうな。
たぶん皆、同一インスタンスに複数スレッドでアクセスしなければ平気
くらいな解釈で使ってるんだよね
496:デフォルトの名無しさん
08/01/31 22:41:35
標準にスレッドセーフという概念がないから語っても意味ないだろ
497:デフォルトの名無しさん
08/01/31 23:19:44
スレッドの概念自体が無い
498:デフォルトの名無しさん
08/01/31 23:26:59
ちっ、また自己責任かよ。つかえねーな
499:デフォルトの名無しさん
08/01/31 23:30:23
効率のためにintの幅すら決めない言語に向かって何を言ってるのかね
500:デフォルトの名無しさん
08/01/31 23:39:35
int幅が実装依存なのはちゃんと作ってれば別に問題ないだろ。
501:デフォルトの名無しさん
08/01/31 23:41:25
原子力発電所も冷凍餃子もちゃんと作ってれば別に問題無いぞ。
502:デフォルトの名無しさん
08/01/31 23:41:37
AMD64は自然な長さが64ビットなのにintが32ビットだな
503:デフォルトの名無しさん
08/01/31 23:48:23
intが64bitな処理系は現存するのか？
その場合、32bitを示す型は何だろう？
504:デフォルトの名無しさん
08/01/31 23:52:06
C言語が設計された時期が古いので64ビットとか考えてなかったんだろ
505:デフォルトの名無しさん
08/01/31 23:52:21
>>503
ILP64 でググれ。
506:デフォルトの名無しさん
08/02/01 00:09:02
32bitといったらlongなんじゃないのか
507:デフォルトの名無しさん
08/02/01 00:16:41
>506
まさか、int 64bitでlong 32bitと言ってる？
508:デフォルトの名無しさん
08/02/01 00:17:56
ねたにまじ（ry
509:デフォルトの名無しさん
08/02/01 00:24:17
LP64のほうが素直だねやっぱり。
I16/LP32はDOSで経験があるし(w
510:デフォルトの名無しさん
08/02/01 00:25:16
もうビット数気にする処理には stdint.h 使えばいいということで。
511:デフォルトの名無しさん
08/02/01 00:29:14
_int64とかタイプしたくないよヽ(`Д´)ﾉｳﾜｧｧｧﾝ
4G超えのファイルなんかザラだろうが。
512:デフォルトの名無しさん
08/02/01 00:31:19
typedef すれば？
513:デフォルトの名無しさん
08/02/01 00:34:47
typedef _int64 long long ってできねーだろ
514:デフォルトの名無しさん
08/02/01 00:37:09
え？
515:デフォルトの名無しさん
08/02/01 00:37:34
long long とか名前長くしてどうするよ。
516:デフォルトの名無しさん
08/02/01 00:42:24
long long は既にあるべよ。long_long_long とかにしようべ。
517:デフォルトの名無しさん
08/02/01 00:44:20
>>515
C99にあるんですよlong long。
>>516
そうします。
518:デフォルトの名無しさん
08/02/01 00:47:19
long long ago むかーしむかし、あるところに長い長いアゴの男がおりましたとさ
519:デフォルトの名無しさん
08/02/01 00:50:58
_int64とはVC++くさいが、
VC++ .NET 2003からはlong longも使えるぞ。
520:デフォルトの名無しさん
08/02/01 00:51:20
中学の英語の授業中誰もが経験するであろうネタだな
521:デフォルトの名無しさん
08/02/01 00:53:43
>>516
別に知っとるが、_int64 の方が短くて分かりやすくていいじゃン
522:デフォルトの名無しさん
08/02/01 00:55:01
i8 u8 i16 u16 i32 u32 i64 u64
これでtypedefしとけば字数的にはint未満だ。何かとぶつかりそうだけどな。
523:デフォルトの名無しさん
08/02/01 00:55:52
そこで名前空間ですよ。
524:デフォルトの名無しさん
08/02/01 00:55:54
以下（8bitのみ未満）の間違い。
525:デフォルトの名無しさん
08/02/01 00:56:53
my_primitive_type::u64
なげーよ。
526:デフォルトの名無しさん
08/02/01 00:59:03
だから、自分のプログラム全体を特定の名前空間内に入れて、
そこで i8 とか定義しとけば何も付けなくて大丈夫。
527:デフォルトの名無しさん
08/02/01 02:14:27
stdintはC++の標準に入ったんだっけか
intN_tな連中。
528:デフォルトの名無しさん
08/02/01 02:18:41
_tてなんかの略？
529:デフォルトの名無しさん
08/02/01 02:30:24
type
530:デフォルトの名無しさん
08/02/01 02:47:05
>>527
最新のドラフトに cstdint と stdint.h が載ってた。次の改訂 (C++0x) で入るみたいだね。
531:デフォルトの名無しさん
08/02/01 06:38:05
C++0xはC99の(ほぼ)上位互換になるんですか
それともC99で使えてもC++0xではサポートされない機能もあり?
532:デフォルトの名無しさん
08/02/01 07:22:07
コンパウンドリテラルとか
配列個数に変数使うとか
そういうのは C++0x で無視
533:デフォルトの名無しさん
08/02/01 07:24:48
restricted ポインタとか色々無視されてる。
534:デフォルトの名無しさん
08/02/01 07:54:32
「配列の要素数に変数」はSTLと相性悪すぎだからな。
535:デフォルトの名無しさん
08/02/01 08:29:10
>>534
kwsk
536:デフォルトの名無しさん
08/02/01 09:01:10
コンパイル時に型が決まらない、だっけ？
537:デフォルトの名無しさん
08/02/01 13:51:10
type* v = new type[n]; ... delete[] v;
の糖衣構文にしてくれるだけでいいのに。
538:デフォルトの名無しさん
08/02/01 16:33:28
stlportsは2008には使えないの？
539:デフォルトの名無しさん
08/02/01 16:49:23
>>538
STLPort はインストーラ(make)が VS2008 にまだ対応していない。
手動でインストールするなら可能らしい。STLport VS2008 でググレ。俺はまだ試していないので、試したら結果を教えてくれ。
540:デフォルトの名無しさん
08/02/01 17:54:00
>>538
iostream使うとC2487がいっぱい出るよ
541:デフォルトの名無しさん
08/02/01 18:14:05
っ _STLP_STATIC_CONST_INIT_BUG
542:デフォルトの名無しさん
08/02/02 01:05:39
>>537
std::vector で何が不満なのさ？
543:デフォルトの名無しさん
08/02/02 01:06:58
見た目が汚い
544:デフォルトの名無しさん
08/02/02 01:09:31
はぁ？
545:デフォルトの名無しさん
08/02/02 01:21:27
std::vector<double> v(i);
と
double v[i];
なら下の方が綺麗だろう。
２次元配列とかなるともうキモいったらありゃしない。
546:デフォルトの名無しさん
08/02/02 03:43:09
エェー
547:デフォルトの名無しさん
08/02/02 04:00:52
valarray使えや
548:デフォルトの名無しさん
08/02/02 07:03:42
[i] はキモいだろ。どんだけ使い込んでるんだよ。
(i) これは正常。むしろ性情。
549:デフォルトの名無しさん
08/02/02 07:29:17
少し、頭冷やそうか
550:デフォルトの名無しさん
08/02/02 08:16:48
(O) ＜ くぱぁ
╋
/＼
551:デフォルトの名無しさん
08/02/02 11:50:57
>>548
FORTRAN か BASIC ばっかつかってるからそうなるんだ。
552:デフォルトの名無しさん
08/02/02 12:08:05
>>546 は
double v[i][j];
より
std::vector< std::vector<double> > v(i, std::vector<double>(j));
や
std::vector< std::vector<double> > v(i);
std::for_each(v.begin(), v.end(), std::bind2nd(std::mem_fun_ref(&std::vector<double>::resize), j));
の方が美しいと感じるようだ。
553:デフォルトの名無しさん
08/02/02 12:21:14
どうしても知識をひけらかしたい奴がいるようだ。
554:デフォルトの名無しさん
08/02/02 12:29:59
馬鹿か？
typedefしろよ
555:デフォルトの名無しさん
08/02/02 12:30:33
あんまりしょうもないtypedefたくさん作らないで欲しいお…
556:デフォルトの名無しさん
08/02/02 12:35:53
グローバルスコープでないならまだ許せる
557:デフォルトの名無しさん
08/02/02 12:50:03
typedef vector<int> vector_int;
typedef vector<double> vector_double;
…
こんなのがtypedefs.hに延々ならんでるソースを見せられたときは会社やめようかと思った。
結局1年しか勤めなかったけど･･
558:デフォルトの名無しさん
08/02/02 13:15:32
>>557
なにがあかんねん
559:デフォルトの名無しさん
08/02/02 13:17:39
>>558
いみないやん
560:デフォルトの名無しさん
08/02/02 13:18:26
まぁ普通意味を考えて命名するよな
#define VALUE_100 100
て定義する様なもの
561:デフォルトの名無しさん
08/02/02 14:29:30
>>557
そのレベルだと好みが分かれそうだなあ
vector<string> string_list
とかはありがちだけど。intとはな。。
562:デフォルトの名無しさん
08/02/02 14:32:11
vectorなのにlist?
563:デフォルトの名無しさん
08/02/02 14:36:40
>>561
そういう問題じゃない。
・typedef名に意味付けがない
↓のようなコメントと通じるものがある
a += 100; // aに100を足す
・字数がほとんど変わらず、打鍵数減少につながらない
…ところで、あなたは list<string>をどのようにtypedefするの？
564:デフォルトの名無しさん
08/02/02 14:39:41
んなマジレスされても。。名前考えんのめんどうだからしないねくらいだが
565:デフォルトの名無しさん
08/02/02 14:48:34
557に意味がないわけじゃないけどな。
typedefされた型しか使わないというのは、
互換性を重視するときは有利になる。
566:デフォルトの名無しさん
08/02/02 14:51:03
>>565
具体的にどんな移植性の問題が typedef によって解決されるんでしょうか？
567:デフォルトの名無しさん
08/02/02 14:54:21
>>565
typedefはそういう用途に使えることは否定しないけど、
vectorもintも標準の一部だから、互換性の点でもtypedef vector<int> vector_int;とする意味は無いんじゃないの。
568:デフォルトの名無しさん
08/02/02 14:55:54
>>566
typedefが移植性のためにあるようなものなのにな。
なぜなにの子供か？
569:デフォルトの名無しさん
08/02/02 14:56:04
もしかしてあれか？ int のサイズが違う環境では
typedef vector<long> vector_int;
に置き換えて「すっきり解決」とか、そういう話か？
570:デフォルトの名無しさん
08/02/02 15:01:04
intのサイズ違いをそのレベルで解決すべきじゃない。
571:デフォルトの名無しさん
08/02/02 15:03:50
つsize_t/off_t
572:デフォルトの名無しさん
08/02/02 15:05:24
だからやっぱり vector_int は意味無いだろ >565
573:デフォルトの名無しさん
08/02/02 15:31:24
std:: を省略できれば打鍵数が結構減る。
574:デフォルトの名無しさん
08/02/02 17:22:02
打鍵数とかでなく、会社からSTLは一律typedefせよ の命題が
課せられれば、vector_int みたいなものは生まれるし、それでもよいと思うぞ。
だから >>557 がどうこう言う程の問題ではないと思われるが。
こういうのは出たての若いのによくいる 自分は社内でも皆よりよく分かってる と
思いこんでる井の中の蛙ってこった。
575:デフォルトの名無しさん
08/02/02 17:31:06
std::foreachとかどうやってtypedefするの？
576:デフォルトの名無しさん
08/02/02 17:34:44
>>574
そんな命題を甘んじて受けるほど奴隷ではありません。
577:デフォルトの名無しさん
08/02/02 17:35:12
>>574
その通り、会社の方針なら勤めてる以上は従わざるを得ないのは言うまでもない。
そこで、無能だったり考え方の一致しなかったりする上司の下で働く羽目になった場合に取り得る行動は、
我慢して働きつづけるか、さっさと辞めるかの二者択一で、>>557は後者を選んだだけだろ。
別に非難されるようなことではない。
578:デフォルトの名無しさん
08/02/02 17:36:14
>>574
それは無能なプログラマが無能な会社に変わっただけで、>>557の判断には影響ないだろｗ
579:デフォルトの名無しさん
08/02/02 17:39:09
>>576
それで問題が発生したとき責任取って解決できるのなら
それでも良いんじゃね？ いざとなったら逃げるのはただの口だけ君。
580:デフォルトの名無しさん
08/02/02 17:43:00
vector<vector<vector<int> > >みたいなものを書かざるをえない状況なら
vector<T>をtypedefすることもあるんじゃないかな？
581:デフォルトの名無しさん
08/02/02 17:43:44
>>579
会社の命令に背いて問題を起こすなんて選択肢はもとからないよ
常識があれば、「従う」と「去る」の二択しか取れない
582:デフォルトの名無しさん
08/02/02 17:43:51
そんな当たり前の事言われましても。
583:デフォルトの名無しさん
08/02/02 17:48:52
>>566
このケースでvector<int>は必要なかったとしても、
list<string>はtypedefしたほうがいい。
とすれば、必要あるなしの境界はどこで切る？
こういう皆が使って判断の微妙な境界線は、
「一律typedef」が安全。
584:デフォルトの名無しさん
08/02/02 17:53:28
STLって型によらずアルゴリズムを記述できるような抽象化を
目指して作られてるはずなのに、ソースはtypedefだらけ。
それを異常と感じないほうがおかしい。
585:デフォルトの名無しさん
08/02/02 17:55:26
抽象的な書き方をしない箇所もある。適切にtypedefすることには何の問題もない。
586:デフォルトの名無しさん
08/02/02 18:03:04
そもそもどういう理由でtypedefしてるの？
587:デフォルトの名無しさん
08/02/02 18:04:36
>>584
抽象化するためにtypedefが必要だったりするし、STLなんかtypedefだらけだけど？
588:デフォルトの名無しさん
08/02/02 18:12:31
>>581
まぁね。 ドラマのまねっこで「僕はそんなことはできません」なんて
楯突いてその後その人間同士が上手く行くことなんてまぁないからね。
ドラマはご都合主義だから上手くいくけどさｗ
589:デフォルトの名無しさん
08/02/02 18:17:26
>>588
自分も会社の一員だけどね。そういうこだわりのない人間が集まってるから駄目な会社になったとも言える。
590:デフォルトの名無しさん
08/02/02 18:17:50
>>574
仕事ってオブジェクト(?)をもっと理解した方がいいよ。
逆に考えて、君がお客で 奴隷とかいうのが車屋の店員だったとする。
君は赤色の車を注文した。 しかし店員は「いやいまのトレンドは白です。
そこは譲れません」 と言ってるのと大して変わらん。
591:590
08/02/02 18:21:36
アンカー違い >>576 へ訂正
592:デフォルトの名無しさん
08/02/02 18:24:24
本日の課題
授業単元：コンピュータ理論
課題：本字の流れをvectorとlistを使って表しなさい。但しtypedefは使わないものとする。
593:デフォルトの名無しさん
08/02/02 18:27:27
販売拒否も車屋の勝手だろ
それで商売になるならそれでいいし、ならないなら別のことをするだけだ
意に反して赤い車を売らされることはない。もちろん妥協して赤い車を売ってもいい
594:デフォルトの名無しさん
08/02/02 18:33:44
>>590
それは違うだろ
595:デフォルトの名無しさん
08/02/02 18:43:17
>>593
おまえ尾崎豊の歌大好きだろ？ｗ
596:デフォルトの名無しさん
08/02/02 18:59:03
>>595
ほとんど聴いたことすらないｗｗ
597:デフォルトの名無しさん
08/02/02 19:31:33
typedef厨いる？
598:デフォルトの名無しさん
08/02/02 19:42:18
まあたいして責められてるわけでもないのに
いきなり奴隷なんて言葉を使い出す輩とは
あまり議論もしたくないな、おれは。
どこぞのウィルス流してつかまったヤツを想起してしまうよ。
599:デフォルトの名無しさん
08/02/02 19:49:14
>>587
それは抽象化とはいわん。単なる簡略化。
型の違いを意識の外に放り出してしまえるのが本来の抽象化。
現実はその逆。
600:デフォルトの名無しさん
08/02/02 19:49:59
個人でやってる分にはいいが、人が動かせない大きな岩(ﾌﾟﾛｼﾞｪｸﾄ)を
動かすには、全員が力合わせて同じ方向に綱引かないと成功なんか
ないよね。 俺は反対に引きたい とか関係ねーよ。
社会の歯車とかTVで憶えた訳分からん言葉に流されるべからず。
601:デフォルトの名無しさん
08/02/02 19:54:16
>>599
std::binary_functionの中とかでやってるtypedefはどう考えても抽象化のためだろ？
602:デフォルトの名無しさん
08/02/02 19:56:43
>>600
本心は別だろ？ｗ
マが鬱になる原因はそういうところが始まりなんだよ？
603:デフォルトの名無しさん
08/02/02 19:58:08
>593
本当は「会社として金を儲けるにはどうすりゃいい」というのに従うべきなんだけどな。
車売って利益上げるのが商売なんだから。
>586
色々。主に抽象化と手抜き。一例として
template<template<class>class trail_t>
struct Policy {
typedef trail_t<Policy<trail_t> > Trail;
// (snip)
};
template<class policy_t> // Policyの派生型を取り込むことを想定
class S {
typedef policy_t Policy;
typedef policy_t::Trail Trail;
// Trailをバンバン活用
};
といった感じで手が抜ける。
604:デフォルトの名無しさん
08/02/02 19:58:17
>>601
使ったこと無いから知らん
それにここまでの話の流れじゃはそういうとこじゃないだろ
605:デフォルトの名無しさん
08/02/02 19:59:30
俺は、木しか見ていない>>557より、森も見ている会社の
typedefs.hの方が賢いと思う。
606:デフォルトの名無しさん
08/02/02 19:59:50
ミス
それにここまでの話の流れじゃそういうとこじゃないだろ
↑typedef乱用のところな
607:デフォルトの名無しさん
08/02/02 20:00:42
>>604
使ったことないのね。了解。
608:603
08/02/02 20:01:43
ごめん。policy_tはPolicyの派生型じゃ無いわな。
609:デフォルトの名無しさん
08/02/02 20:19:10
>>602
本心は当然別よ。 本来人の考えが一致するなんて奇蹟ぐらいの考えで丁度いいよ。
映画あらしのよるに で上手く分かりやすく描かれてるよ。羊と狼が友情築くｱﾆﾒ風のやつ。
610:デフォルトの名無しさん
08/02/02 20:37:17
typedefs.h には元々プロジェクトの成功を見ていた２人の心を分かつ効果もありそうだ。
611:デフォルトの名無しさん
08/02/02 21:14:32
つうかコンテナをvectorからdequeに変えたくなった時や
intじゃなくて複素数入れたくなった時に
vector_int
じゃカコワルイだろ
612:デフォルトの名無しさん
08/02/02 21:18:35
おまいらソフトウェアプロジェクトマネジメントの本を読んでみ。「ピープルウェア」とか。
>600を実現するためにどれだけの苦労が必要かがわかる。
あくまでマネージャー視点だけど、プログラマ側からするとマネージャーの資質を
測るのに良いヒントになるよ。
ついでに「デスマーチ」もドゾー。現実は厳しいということを教えてくれる古典的名著。
613:デフォルトの名無しさん
08/02/02 21:19:56
そんな話はマ板でやれよ
614:デフォルトの名無しさん
08/02/02 21:20:00
>611 変えない……というのは冗談として。
そんときはリファクタリングじゃね？名前総取っ替えだろうね。
615:デフォルトの名無しさん
08/02/02 21:21:41
>613 だったら>603にコメント入れろよ。放置されてバカみたいだろ。
他のtypedefの使いかたでも良いよ。
616:デフォルトの名無しさん
08/02/02 21:27:10
だから vector_int には意味がなくて
typedef int Code;
typedef std::vector<Code> CodeList;
とか
typedef std::vector<Code> CodeSequence;
とかにしたほうが良いんじゃないのって言うのが良識のあるプログラマの意見じゃないかな
617:デフォルトの名無しさん
08/02/02 21:29:19
このスレでまともにSTLの話をしているのを見たことがない俺
618:デフォルトの名無しさん
08/02/02 21:35:25
文字コードの次はtypedefかお
619:デフォルトの名無しさん
08/02/02 21:40:05
で、赤い車は買えたの？
620:デフォルトの名無しさん
08/02/02 21:48:46
というか、おまいらTemplate使ってる？
Policyは非常に強力なコンセプトだと思うんだがね。
本当はもっと制約の少ないMix-in機能が欲しいけどね。
Policy同士で相互依存があると破綻しがちだから、けっこう設計が面倒。
621:デフォルトの名無しさん
08/02/02 21:49:24
>619
あぁ、早速それ乗って近くの本屋にEffectiveSTL買いに行く予定だよ
622:デフォルトの名無しさん
08/02/02 22:12:32
>>620
アレキサンドレスクの受け売りですか？
623:デフォルトの名無しさん
08/02/02 22:20:19
メイヤーズもヴァンデヴォーデも質問したら
ちゃんと返事くれるんだな。できる人は違うわ。
624:デフォルトの名無しさん
08/02/02 22:20:59
>>620
相互依存のあるPolicyなんて思い浮かばないんだけど
具体的にどんなの？
625:デフォルトの名無しさん
08/02/02 22:23:26
あれってヴァンデヴォーデって読むのか……
626:デフォルトの名無しさん
08/02/02 22:23:56
>622 基本的にはそんな感じなんだけど、Policyの組替えを想定してるんじゃなくて
単にデカいクラスのモジュール化をするときに使ったりしてる。
本当は包含とかでも何とかなるんだけどねぇ。
委譲関数書かなくて良いのが素敵なんで何となくポリシー使ってる。
627:デフォルトの名無しさん
08/02/02 22:26:16
>>625
いや適当
628:デフォルトの名無しさん
08/02/02 22:27:48
>624
もちろんきっちり設計してから組めば相互依存はほとんど無くすことができるんだけど、
トライ＆エラーで設計するときはそんなこと言ってられないからね。
ルーズに始めるときは、たいてい相互依存バリバリだったりする…………
リファクタリングするときも相互依存した状態を経由するから、そういうときも不便。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
4821日前に更新/208 KB
担当:undef