C#, C♯, C＃相談室 Part52

C#, C♯, C＃相談室 P ..

511:デフォルトの名無しさん
09/05/21 02:04:35
>>510
書き忘れましたが、それも試して効果はありませんでした。

public Form1()
{
InitializeComponent();
webBrowser1.Navigate("about:blank");
webBrowser1.Navigate("URLﾘﾝｸ(www.google.co.jp)");
}

512:デフォルトの名無しさん
09/05/21 02:06:14
じゃあ、無理じゃね？素直にリロードしてもらえよ。

513:デフォルトの名無しさん
09/05/21 02:13:33
わかりました。
自分でもかなり調べてダメだったので、諦めることにします。
ありがとうございました。

514:デフォルトの名無しさん
09/05/21 02:51:04
前にAxWebBrowser使ってた時に俺もそんなことあったな。Navigateするタイミングだと思うんだけど。
起動時にNavigateするようにした時に稀にあった。
とりあえず、起動時にいきなりNavigate使う時はコンストラクタじゃなくてLoadイベントなり登録してそこでやった方がいいと思う。
それでこの症状が直るわけではないと思うけど。

515:デフォルトの名無しさん
09/05/21 12:03:16
>>506

webBrowserだけじゃなくて
IE6のそのものが、ずっと真っ白のままで表示されないことがあるんだが・・・

AVGのリンクスキャナを停止してからは少しマシになったかも？
普段はChromeを使っているから見なかったことにしてるけど。

516:デフォルトの名無しさん
09/05/21 14:18:15
>>506とおんなじコードで試してみたけど、
何度やっても問題なく表示されるな。

環境はXPProSP2、IE6、VS2008Pro

517:デフォルトの名無しさん
09/05/21 14:49:26
webBrowser1.BusyがTrueのときそうなるんじゃないか？

518:デフォルトの名無しさん
09/05/21 15:58:51
>>515
ウィルス対策ソフトは切ってます。

>>516
ほんの2日ほど前まで私もその環境でしたが、なぜか動きません。
XPProSP3、IE8、VS2008Exにしましたが、改善はありません。

>>517
ちょっと見てきます。

519:デフォルトの名無しさん
09/05/21 16:02:12
取り敢えず514な
System.Windows.Forms.WebBrowserはコントロール上に乗って無くても大丈夫なように作られてるけど一応

520:デフォルトの名無しさん
09/05/21 16:23:25
>>517
■PG
public Form1()
{
InitializeComponent();
Console.WriteLine("IsBusy:" + webBrowser1.IsBusy);
webBrowser1.Navigate("about:blank");
webBrowser1.Navigate("URLﾘﾝｸ(www.yahoo.co.jp)");
Console.WriteLine("IsBusy:" + webBrowser1.IsBusy);

}

■出力
IsBusy:False
'Test.vshost.exe' (マネージ型): 'C:\WINDOWS\assembly\GAC\Microsoft.mshtml\7.0.3300.0__b03f5f7f11d50a3a\Microsoft.mshtml.dll' が読み込まれました
IsBusy:False

■結果
画面まっ白

>>514
LoadイベントでやってもThread.sleep(5000)をnavigateの前後に入れてもまっ白になることが多々ありました。

521:デフォルトの名無しさん
09/05/21 18:07:17
Shownを使え

522:デフォルトの名無しさん
09/05/21 22:09:23
IE でダメなら、WebBrowser でもダメだろよ。

523:デフォルトの名無しさん
09/05/21 22:32:09
ReadStateがcompleteになるまで待ったほうがいいんじゃないかな？

524:デフォルトの名無しさん
09/05/21 22:49:46
ContextMenuStripに追加したToolStripMenuItemの
DropDownItemsに追加したToolStripMenuItemのイメージ余白の消し方を教えてください。

1階層目はShowImageMarginをFlaseにすれば消せるのですが
2階層目以降のToolStripMenuItemは余白が出たままになってしまいます…。

525:デフォルトの名無しさん
09/05/22 01:41:24
>>313さんのMecabの返り血をAnisで受けると文字化けするんですけど、
文字化けしない方法をどなたか教えてください orz

526:デフォルトの名無しさん
09/05/22 01:44:57
キャー！

527:デフォルトの名無しさん
09/05/22 01:46:46
PtrToStringAuto だとどうなる？

528:デフォルトの名無しさん
09/05/22 02:00:25
>>527
こんななりました。。
?慣???麩????????????弊(ry

529:デフォルトの名無しさん
09/05/22 02:26:54
Shift_JIS（CP932）をUTF-8と誤認識してるんじゃね。

530:デフォルトの名無しさん
09/05/22 03:09:18
俺はこれでできた

[DllImport("libmecab.dll")]
extern static int mecab_new2(string arg);
[DllImport("libmecab.dll")]
extern static IntPtr mecab_sparse_tostr(int m, byte[] str);
[DllImport("libmecab.dll")]
extern static void mecab_destroy(int m);

int mecab = mecab_new2("");
this.textBox2.Text = Encoding.Default.GetString(Encoding.Convert(Encoding.UTF8, Encoding.Default, Encoding.Unicode.GetBytes(
Marshal.PtrToStringUni(mecab_sparse_tostr(mecab, Encoding.Convert(Encoding.Default, Encoding.UTF8, Encoding.Default.GetBytes(
this.textBox1.Text))))))).Replace("\n", "\r\n").Replace("\r\r\n", "\r\n");
mecab_destroy(mecab);

531:デフォルトの名無しさん
09/05/22 06:06:52
これはひどいコード・・・

532:デフォルトの名無しさん
09/05/22 06:24:15
なんのためのマーシャリングなのかって感じだな

533:デフォルトの名無しさん
09/05/22 14:52:19
printPreviewDialog1.Bounds = this.Bounds;
printPreviewDialog1.ShowDialog();

こう書いても何故かthisと重なって表示してくれない
大きさは反映されるのに位置が自動的に決定されてしまう
解決方法知ってる方いたら教えてください

534:デフォルトの名無しさん
09/05/22 15:08:59
ウィンドウの初期位置を指定するプロパティがあるからそれをManualだったかなんかにする

535:デフォルトの名無しさん
09/05/22 15:32:25
PrintPreviewDialogにStartPositionプロパティは無いみたいです

536:デフォルトの名無しさん
09/05/22 15:40:11
.NET Framework クラスライブラリ
PrintPreviewDialog..::.StartPosition プロパティ

537:デフォルトの名無しさん
09/05/22 15:49:14
インテリセンスに出ないので無いと思ってましたが頑張って手打ちしたら出来ました
ありがとうございました

538:デフォルトの名無しさん
09/05/22 15:55:42
＞頑張って手打ち
ﾜﾛﾀ
気持はわかる

539:デフォルトの名無しさん
09/05/23 18:31:31
>>424 ｸｿﾜﾛﾀ

540:デフォルトの名無しさん
09/05/24 01:39:48
笑い事じゃねえよ！

541:デフォルトの名無しさん
09/05/24 11:01:56
いや、声出して笑っちゃったよｗ
ユニークな仕事だなｗ

542:デフォルトの名無しさん
09/05/24 12:58:03
たぶん日本で唯一だy。食いっぱぐれなくていいな。

543:デフォルトの名無しさん
09/05/24 14:30:22
＼拍手を打つ仕事があるときいてやってきました／

544:デフォルトの名無しさん
09/05/24 16:14:58
ListBoxの、選択されたアイテムを囲っている破線を消したいのですが可能でしょうか？
なぜか一瞬だけ、選択していないアイテムに破線が出るので消したいと思っています

545:デフォルトの名無しさん
09/05/24 16:45:38
>>544
独自描画にすれば消せるんじゃないかな。

546:デフォルトの名無しさん
09/05/26 10:30:51
その破線はキーボードフォーカスの存在を見せるためにある。
勝手に消されると状況によってはユーザーが混乱すると思うが
それでもいいなら>>545の言うようにオーナードローしては。

547:デフォルトの名無しさん
09/05/29 20:30:10
label.Text = "Value: ";
このようなValueを表示するラベルを貼りました。
スペースの後に増減する数字を代入していくのですが、どうやるのがいいのですか？
"Value: "が無い場合は単純で、
labal.Text += i.ToString();
でよかったのですが、、

548:デフォルトの名無しさん
09/05/29 20:45:57
>>547
labal.Text　+=　i.ToString();　＝　labal.Text　=　labal.Text　+　i.ToString();

549:デフォルトの名無しさん
09/05/29 20:49:05
>>547
string.Format

550:デフォルトの名無しさん
09/05/29 22:01:44
if(i==0)
　　label.Text = "Value: 0"
else if
....

551:デフォルトの名無しさん
09/05/30 17:38:53
コンストラクタ名のとこにクラス名書かなきゃならないという無様な仕様は
未来永劫そのままなの？

552:デフォルトの名無しさん
09/05/30 17:59:09
そりゃ、そんな根幹にかかわるところ変更はできないだろ。
嫌なら新しい言語作るしか。

553:デフォルトの名無しさん
09/05/30 18:11:25
不自然かもしれないけどC++やJavaで十分に受け入れられてるからな
はじめの頃のC#ではキーワードを少なくすることが重視されてたみたいだし

554:デフォルトの名無しさん
09/05/30 18:23:57
Javaの、ソースファイル名とpublicクラス名を同じにしとかないとエラーだよーん。
の舐めた仕様よりはマシになってるとは思う。

555:デフォルトの名無しさん
09/05/30 18:34:15
>>551
同感。同じことを2度書くのは無駄だよな
もう.ctorでいいのに

556:デフォルトの名無しさん
09/05/30 18:39:31
まあ、元々がC++プログラマーを逃がさないようにする目的があったから、
あの構文は変えようがないでしょ。

C# 開発者的に、C++ との互換性重視しすぎて失敗したなぁと思う部分もちらほらあるみたいなんで、
今よりさらにもうちょっと .NET が普及したら、その辺りなおした新言語を作るのもありかもしれないけど。

557:デフォルトの名無しさん
09/05/30 18:43:24
Font Font = new Font

558:デフォルトの名無しさん
09/05/30 18:44:46
>>557
var Font = new Font();

559:デフォルトの名無しさん
09/05/30 18:45:32
newはインテリセンスがなきゃ発狂する構文だが、あるから我慢できるレベル。
var使う事自体が冗長

560:デフォルトの名無しさん
09/05/30 18:50:41
>>559
いやー、var は要るよ。
宣言と代入は分けたい。

new なくすとすると、例えばどういう構文？
C++ のスタック割り当て時みたいに、クラス名() だけとか？

561:デフォルトの名無しさん
09/05/30 18:53:18
Python みたいに font = Font() とか書けたら嬉しさのあまり自決する

562:デフォルトの名無しさん
09/05/30 18:55:01
>>561
それはなぁ、型名と同じ名前のプロパティ定義できる C# だと文法的にあいまいになりそう。

563:デフォルトの名無しさん
09/05/30 18:57:39
後からの拡張とか考えると、new とか var とかの構文解析の起点になる部分は削らない方がいい。
font = Font() なんて認めたら、多分、後から機能足せなくて泣く。

564:デフォルトの名無しさん
09/05/30 19:13:55
結局コンストラクタの構文は無駄？必要？

565:デフォルトの名無しさん
09/05/30 19:16:03
>>561
それ出来るとIntelliSenseの暴発を招くから、今の型推論によるvarでの定義がバランス的にちょうどいい。

566:デフォルトの名無しさん
09/05/30 19:16:07
今のC#の方向性考えると必要。
C#の原型とどめないような改変が許されるんなら別にどっちでも。

567:デフォルトの名無しさん
09/05/30 19:19:12
キーワードconsを導入すれば万事解決

568:デフォルトの名無しさん
09/05/30 19:31:22
ぶっちゃけなれればどうでもいい

569:デフォルトの名無しさん
09/05/30 19:50:07
>>565
同感、C#は強く強くインテリセンスを意識した文法であって欲しい。
でないと、今のライブラリでさえ全体を憶えきれないのにこういうサポート外されたら気絶する。

570:デフォルトの名無しさん
09/05/30 21:19:51
何でPythonがはやってるんだ？
前に来た時はDが話題だったような…

571:デフォルトの名無しさん
09/05/30 22:39:22
個人的にはもう少し型を意識したJavaScriptのような言語がはやって欲しいな。

572:デフォルトの名無しさん
09/05/30 22:43:12
>>571
JavaScriptは十分はやってるだろ

573:デフォルトの名無しさん
09/05/30 22:47:18
PowerShellいいぞ。PowerGUIのコード補完との相性もかなり良好。

$a = [xml]"<data>foo</data>"

$a.

で候補にdataが出てくるんだぜ。
ソースコードじゃなくプロンプトで実行しながらじゃないと駄目だけど。

574:デフォルトの名無しさん
09/05/30 23:02:46
「C# .NETアプリケーション開発徹底攻略 C# 3.0/.NET Framework 3.5対応」
という本で、FormのLoadイベントはコンストラクタ完了よりも先に実行される（ことがある？）
とか書かれてるんだけどほんとにあるの？

どうもこの本思い込みで書いてるような部分も見られてちと怪しんだが…

575:デフォルトの名無しさん
09/05/30 23:31:51
InitializeComponents で子コントロールにプロパティを設定する際に、子から
親フォームが呼ばれてLoadされることが危惧されている。

576:デフォルトの名無しさん
09/05/30 23:38:37
そのフレームワークいいのかな
設計が甘いのでは？

577:デフォルトの名無しさん
09/05/30 23:44:14
甘いねぇ。

578:デフォルトの名無しさん
09/05/30 23:47:51
＞子から親フォームが呼ばれてLoadされる
ってどういう状態かわからん…

579:デフォルトの名無しさん
09/05/30 23:49:48
んーマルチスレッドと例外絡みのこと書いてあるとこもでたらめだしなー

580:デフォルトの名無しさん
09/05/30 23:51:20
ちゃんと引用したらいいと思うよ

581:デフォルトの名無しさん
09/05/31 00:11:54
>>574
うろ覚えだけど、
Win32だと、CreateWindow()内で、WM_CREATEを直接呼び出してたような気がする
(CreateWindow()の復帰値はWM_CREATEの復帰値に依存する)

なので、
- C#のFormのコンストラクタ内で内部的にCreateWindowの呼び出しを行う
- FormのLoadはWM_CREATEに相当する
の2つの条件が成り立てば
＞FormのLoadイベントはコンストラクタ完了よりも先に実行される
は、成り立つかもしれない

582:デフォルトの名無しさん
09/05/31 00:19:12
子が初期化待たないで親を Visible = true したら起きた。
でも、普通しねえよなぁ、こんなことwww

583:デフォルトの名無しさん
09/05/31 00:19:31
>>581
そんなこと考えるまでもなくマネージドだけで成立するよ、意味があるかどうかは別として
public class Form1 : Form {
　　 public FFFF() {
　　　　 Ctrl ctrl = new Ctrl();
　　　　 this.Controls.Add(ctrl);
　　　　 ctrl.Do();
　　　　 Debug.WriteLine("Ctor");
　　 }
　　 protected override void OnLoad(EventArgs e) {
　　　　 Debug.WriteLine("OnLoad");
　　　　 base.OnLoad(e);
　　 }
}
public class Ctrl : Control {
　　 public void Do() {
　　　　 Form form = this.FindForm();
　　　　 if (form != null) form.Show();
　　 }
}
相互参照はやっかいだね

584:デフォルトの名無しさん
09/05/31 00:22:05
namespace WindowsApplication1 {
public partial class Form1 : Form {
public Form1() {
InitializeComponent();
MessageBox.Show("end of init");
}

private void timer1_Tick(object sender, EventArgs e) {
Visible = true;
}

private void Form1_Load(object sender, EventArgs e) {
MessageBox.Show("Form.Load");
}
}
}
でタイマのintervalは1。

585:デフォルトの名無しさん
09/05/31 00:31:27
その前に

コンストラクタでこんなことしていいんか

586:デフォルトの名無しさん
09/05/31 00:38:47
そもそもそんなこする方がやばいんだから
しないように修正するべきだろう。

587:デフォルトの名無しさん
09/05/31 00:39:33
フォームをNewしたらいきなり表示されるとか、冗談ではないわ。

588:デフォルトの名無しさん
09/05/31 00:46:51
しないように済む方法を指導しないテキストがクズだな。

589:デフォルトの名無しさん
09/05/31 00:46:50
引用した方がいいんだが、何せ立ち読みで読んだだけなんで、すまんね。

しかし、デリゲートの非同期実行でEndInvokeせずに、なんと例外が無視されてしまうのだ！！
みたいなこといって、非同期実行するメソッド内で即座にコントロールにInvokeして、これで例外をとれる
っておまえそれ非同期実行の意味全然ないだろうがよとか、こんなの見るとなんか書いてあることが信用できない。

590:デフォルトの名無しさん
09/05/31 01:04:13
あー、エスパーすると、非同期実行すると例外取れないから同期しましょう、
と書いてあるのか？

591:デフォルトの名無しさん
09/05/31 01:11:44
そういうこと

592:デフォルトの名無しさん
09/05/31 01:17:58
その本でスレッド周りに何書いてあるのか、ちょっと気になってきたww

593:デフォルトの名無しさん
09/05/31 01:39:23
意外と好評な書評も。
URLﾘﾝｸ(mag.autumn.org)

594:デフォルトの名無しさん
09/05/31 02:11:24
んー今はどうかわからんけど、
Formは2回以上ShowDialogすると動作保証されない
だった気がするけどな。
ナレッジに出てなかったっけな…

595:デフォルトの名無しさん
09/05/31 07:20:32
C#で複数接続ができるサーバーを作成しているのですが、多くの接続を受け付けると、
「転送接続からデータを読み取れません: ブロック不可のソケット操作をすぐに完了できませんでした。」
というエラーが出て、例外が発生してしまいます。

誰かこのエラーの解決方法をご存じないでしょうか？
よろしくお願いします。

596:デフォルトの名無しさん
09/05/31 07:30:32
XPのコネクション制限に引っ掛かってるとか。

597:デフォルトの名無しさん
09/05/31 07:48:28
>>596
XPのコネクション制限には引っかからない程度でも発生するんですよね…
# 10本くらいConnectが発生すると5本目くらいからエラーが発生→例外→…という感じで

598:デフォルトの名無しさん
09/05/31 09:22:23
サーバOSやTCP/IP Pacherとかで制限ない状態で試してみれば？

599:デフォルトの名無しさん
09/05/31 09:51:46
その前にプログラムを

600:デフォルトの名無しさん
09/05/31 13:22:18
自分以外のコネクションが５～６個あるんでしょ？

601:デフォルトの名無しさん
09/05/31 14:13:55
VistaSP2と2008サーバでは撤廃されたっていうからXPでもパッチこないかな・・・
いやがらせとして残されたりして。

602:デフォルトの名無しさん
09/05/31 14:15:20
>>593
これWM_CREATE代わりなんだ、確かにShowDialogするごとに呼び出されるね、名前が悪いよな。

603:デフォルトの名無しさん
09/06/01 12:05:26
C#というか.netで使える
rubyでいうところの,Narray
pythonでいうところのNumPy
のような配列の形で演算してくれるクラスライブラリはありますか？

604:デフォルトの名無しさん
09/06/01 12:21:34
>>603
コンセプトがまるで違うけれども、あえて言えばLINQがそのような処理を担当するライブラリと言えるかと思われます。
だけれども、そういう操作そのものを求めるとちょっと、というかまったく違うものかも
やりかたとしては二つのシーケンスを一つのシーケンスにまとめる、そこに select なりで全体に演算を施す、といった具合。

605:デフォルトの名無しさん
09/06/01 12:46:05
数値演算ライブラリが欲しいと言ってるのに、linq挙げるってのはないだろｗ

でも、.NET向けってのは商業ものしか知らんわ。
BLAS系の.NETバインディングは探せばありそうだけど。

606:デフォルトの名無しさん
09/06/01 12:53:14
>>603
詳細はまだ調べてないけど、.NET で線形代数を助けてくれるライブラリなら
Math.NET があるみたい。
URLﾘﾝｸ(mathnet.opensourcedotnet.info)

607:デフォルトの名無しさん
09/06/01 13:01:57
>>605
そうですか？むしろ汎用度の高いライブラリだと思うんですけどね。
自分は今は線形代数周りは全部LINQで構築してしまいましたけど

608:デフォルトの名無しさん
09/06/01 13:04:41
そもそもLINQってのはテクノロジー（）笑の名前であって、ライブラリの名前ではないと思うんだが。

609:デフォルトの名無しさん
09/06/01 13:04:55
LINQのコンセプト、モナドと抽象線形空間の相性がいいというか……
実数上の線形空間はもちろん、複素数でも有限体でもいけるし、いっそ関数を基底とかも。
まぁなんかそんな感じてす

610:デフォルトの名無しさん
09/06/01 13:15:52
LINQは集合演算
mapもあるしリスト演算(コンベア的な)もつかえるし
そういういみじゃん

611:デフォルトの名無しさん
09/06/01 13:26:56
LINQtoObjectによる各種演算処理からLINQtoSQL or LINQtoXMLと次々と同一コンセプトでつながっていくのも気持ちいいしね。

612:デフォルトの名無しさん
09/06/01 18:04:30
列挙型を含んだクラスをシリアライズしようとすると
例外が発生してしまいます。

↓こんな列挙型です。
　　public enum ActionType
　　{
　　　　[XmlEnum(Name = "Single")]
　　　　One,
　　　　[XmlEnum(Name = "Double")]
　　　　Two,
　　　　[XmlEnum(Name = "Triple")]
　　　　Three
　　}

なにか方法などありますでしょうか？

613:デフォルトの名無しさん
09/06/01 18:10:14
例外の詳細ぐらい書けよ

614:デフォルトの名無しさん
09/06/01 18:15:12
IXmlSerializableを実装しろ

615:デフォルトの名無しさん
09/06/01 22:20:33
アンマネージコードからコールバックされるマネージコードで例外をアンマネージ側に
漏らしたくない場合は以下のMyCallBackのような処理であってる？

public delegate bool CallBack();

[DllImport("hoge.dll")]
private static extern int Hoge(CallBack callback);

static void MyCallBack()
{
　// このメソッド内で発生した例外を hoge.dll に漏らしたくない
　RuntimeHelpers.PrepareConstrainedRegions();
　try {
　　// hoge
　} catch (Exception e)
　　Console.WriteLine(e);
　}
}

static void Main()
{
　Hoge(new CallBack(MyCallBack));
}

616:デフォルトの名無しさん
09/06/01 22:25:23
それはいいけど渡し方がダメ
アンマネージコードに渡したデリゲートはstaticフィールドに入れとかないとGCされて死亡

617:デフォルトの名無しさん
09/06/01 22:25:31
エラー時コールバック（イベント）でも登録できるようにするべきじゃないかな。
常にコンソール出力だけでOKなら別にいいかもだけど。

618:デフォルトの名無しさん
09/06/01 22:29:47
＞エラー時コールバック（イベント）でも登録できるようにするべきじゃないかな。
＞常にコンソール出力だけでOKなら別にいいかもだけど。

おっと、CERじゃこんなのは無理か。
ってその前にコンソール出力も無理なんじゃないか？

619:デフォルトの名無しさん
09/06/01 22:37:08
なんかイマイチやりたいことが伝わってこない
例外握りつぶしてしまっていいのか

620:デフォルトの名無しさん
09/06/01 22:45:50
＞public delegate bool CallBack();

＞static void MyCallBack()

＞Hoge(new CallBack(MyCallBack));

返り値違うぞ

621:デフォルトの名無しさん
09/06/01 23:07:24
>>616
GCHandleいじるのが作法上正しいのでは

622:デフォルトの名無しさん
09/06/01 23:22:17
＞アンマネージコードに渡したデリゲートはstaticフィールドに入れとかないとGCされて死亡

このコードだと問題ないけどね。
もちろんこういう構造じゃない場合は問題あるので考慮は必要。

623:デフォルトの名無しさん
09/06/01 23:29:05
問題ないかどうかはHogeの中身による
非同期にコールバックされたり戻ったあとも向こうで関数ポインタ保持されたりしたら死ぬ

624:デフォルトの名無しさん
09/06/01 23:59:45
非同期にコールバックする頃にはプログラム終了してるんじゃないかな、この場合

625:デフォルトの名無しさん
09/06/02 00:11:12
この場合ってhogeの中身が何も書いてないんだから
何も判断できない

626:デフォルトの名無しさん
09/06/02 00:31:25
static void Main()
{
　Hoge(new CallBack(MyCallBack));
}

だから後でコールバックされるような使い方じゃないと「想定したら」、だよ。＞このコードだと問題ない

627:デフォルトの名無しさん
09/06/02 07:29:09
ホゲが何者かわからん状態で
てめー勝手に都合の良い想定をするのは愚の骨頂じゃないか

628:デフォルトの名無しさん
09/06/02 09:57:11
未来永劫大丈夫。
PCのメモリも640KBで十分だし。

629:デフォルトの名無しさん
09/06/02 11:05:07
別に普通の想定だろ。
まあ別に軽く突っ込んでみただけで、ホントにそれでいいとは思ってないよ。

630:デフォルトの名無しさん
09/06/02 11:28:47
>>628
いつまでそんなネタひっぱってんだよ化石

631:デフォルトの名無しさん
09/06/02 19:10:23
登録しといて後で呼び出してもらう形の方が想定としては一般的だと思うんだが
P/Invokeでは特に

632:デフォルトの名無しさん
09/06/02 19:10:47
未来永劫ひっぱるぜ

633:デフォルトの名無しさん
09/06/02 19:27:06
だから、このコードだと、なんだろ？

634:デフォルトの名無しさん
09/06/02 19:33:36
Hogeが非同期ならこのコードでも死ぬよ

635:デフォルトの名無しさん
09/06/02 19:44:12
CallBackが引数無い、返り値はbool、例外は関数の外に出したくない
工夫のしようがないよね

hogeのインターフェイスを変更可なら色々出来るが

636:デフォルトの名無しさん
09/06/02 22:18:06
>>634
いやまずあり得ないね。
まあ意味ないしどうでもいいけど。

637:デフォルトの名無しさん
09/06/03 17:19:43
ちょっと相談させて下さい。

ネットワーク経由で送られてくるバイトストリームがあるとして、あるバイト位置まで読み進めないと
どんなフォーマットのパケットが来てるか分からないという形態のプロトコルを処理する場合、C#的には
どう書くとするとスマートなんでしょうか?
結果的には、パケットの種類に応じた構造体として後の処理で使えるようになればいいです。

C言語だと共用体を使うとスッキリ書けますが、C#でFieldOffsetを使うのは何となく邪道な気がします。

638:デフォルトの名無しさん
09/06/03 17:46:28
自分なら迷わずFieldOffsetを使うけど、なぜそれが邪道なのかはわからん。

639:デフォルトの名無しさん
09/06/03 18:08:37
>>637
何で邪道なんだろ
どうしても嫌ならビットシフトやらこねくり回せば？

640:デフォルトの名無しさん
09/06/03 18:15:36
指定位置までMemoryStreamに入れといて
データの種類が判明してから適宜変換して使うとか？

641:デフォルトの名無しさん
09/06/03 19:44:55
>>637
バッファと実インスタンスを分けて書くしかないんじゃないかなぁ

642:デフォルトの名無しさん
09/06/03 19:45:46
>>637
ある時点でpush　backできるストリームを使うか作る

643:デフォルトの名無しさん
09/06/03 20:48:33
経験者に聞きたいのですが、C#はC++やCに比べて使いやすいでしょうか？
普及度とか今後を見たときに覚えておくと便利ですか？

644:デフォルトの名無しさん
09/06/03 20:51:46
段違いで使いやすい。
今後は、まあ、CやC++は上級者のための代物になりつつあるから
今からC,C++を一からやるよりは良いんじゃないかね。

645:デフォルトの名無しさん
09/06/03 21:12:48
C/C++で書く経験自体はしておいた方がいいと思うけど、実用的にはC#のが楽。
まぁ、C#じゃなくてもJavaでもRubyでもErlangでも好きなものを使えばいいと思うが。

646:デフォルトの名無しさん
09/06/03 21:17:40
レスありがとうございます。
C#は確かに使いやすくなっているようなイメージがあるのですが
CやC++でしかできなくて、C#じゃできない事ってあるんですか？

647:デフォルトの名無しさん
09/06/03 21:22:53
大きく見ればデバイスドライバとかシステムフックとかぐらいか

648:デフォルトの名無しさん
09/06/03 21:39:34
>>646
.NET言語だから移植性に難

649:デフォルトの名無しさん
09/06/03 22:03:33
ｃしらないとdllimportかけないじゃん

650:デフォルトの名無しさん
09/06/03 22:08:27
全部やっといた方がいい

651:デフォルトの名無しさん
09/06/03 23:02:14
>>646
OS関係の高度な操作とかは、C#では茨の道かも。
特定のCPUに特化したプログラムの作成とかも難しい感じ。

652:デフォルトの名無しさん
09/06/03 23:42:57
そういう、プリミティブなことをするか、組み込みなどで選択肢が少ないこと、よほどの高速性（これもものによっては関数型のほうが速い場合もあるが)でなければ生産性などなど考えたらC++というのは選択肢にはあがらんなぁ・・・
昔C++で今はC#メインだが、コンパイル速度が激速な点が一番うれしい。

653:デフォルトの名無しさん
09/06/03 23:53:16
Windows上で動く普通のアプリを作るだけなら
C#だけで充分だね。

654:デフォルトの名無しさん
09/06/04 06:39:10
C#がここまで評価される言語になると誰が予想しただろう

655:デフォルトの名無しさん
09/06/04 08:06:22
そりゃ、C# でググって出てくる上位サイトは
たいてい1.0とかそれのCTPの頃からC#の記事書いてるし、
その人らは予想してただろ。

656:デフォルトの名無しさん
09/06/04 08:08:06
.NET 1.0の頃は見向きもせずC++使ってた。
.NET 2.0とVS2005が出た時に、熱心に布教してたMS見て試しに使ってみたら意外と良くて、そこから徐々に乗り換えた。

>>654
VistaがまだLonghornと呼ばれていた頃
Win32を置き換える！とか言って浮き足立ってたなぁ

>Longhorn登場時期と予想されている2006年、PCは4～6GHz／2コアのCPUを搭載し、メモリ2Gバイト超、HDD1Tバイト超
2003年の記事眺めてて噴いたｗ　今だからこそ言える。ねーよｗｗｗ

657:デフォルトの名無しさん
09/06/04 11:41:06
>>652
>昔C++で今はC#メインだが、コンパイル速度が激速な点が一番うれしい。
C#が速いというよりもC++が致命的に遅いというのが実態な気がする。
いずれにしても、ある程度の規模を超えたらC++のコンパイル時間・リンク時間は実用的でないです
特にリンクが遅いのが余りに致命的

658:デフォルトの名無しさん
09/06/04 11:47:56
>>656
Core2辺りで一応達成といえるんじゃないかな、Pen4と同クロック比較で2倍程度(当時のCPUの想定はPen4クラスだと思われる)
メモリは一応2Gにはなった、HDD1Tバイト超だけが実現されていないかと
しかし、必要ない人には今の時点でもHDDは余っているだろうね

659:デフォルトの名無しさん
09/06/04 14:18:04
>>657
ヘッダ書き換えた時のコストがあまりにもひどいと思うよ。

660:デフォルトの名無しさん
09/06/04 14:20:34
>>659
それに関しては、分散コンパイルを使えば……、あんまり解決してないけど一応解決する
けれどもリンクはもう完全にお手上げ

661:デフォルトの名無しさん
09/06/04 14:27:54
今や、マネージコードで書かれたFPSなんかが出てきても、驚くほどのことじゃないな。

662:デフォルトの名無しさん
09/06/04 15:06:12
FPSって何？

663:デフォルトの名無しさん
09/06/04 15:08:35
ファーストパーソンシューティング
ゲームの一ジャンル。欧米で今一番はやってる形態

664:デフォルトの名無しさん
09/06/04 15:12:38
ファーストパーソンズシュータアァー！

665:デフォルトの名無しさん
09/06/04 17:06:53
空気よまずに、、、

フレーム・パー・セコンド

666:デフォルトの名無しさん
09/06/04 17:52:15
そういや、Silverlight3で書かれたFPSのデモがあったな
普通に3Dの画面がサクサク動いてて驚いた

667:デフォルトの名無しさん
09/06/04 18:33:59
>>666
これ？
URLﾘﾝｸ(www.innoveware.com)

668:デフォルトの名無しさん
09/06/04 18:55:11
>>659
そういうコストを減らすために
ヘッダの依存を分散させる設計が必要
そのコストが高いってことは設計が悪いってことだ
ヘッダのあるプログラミング言語的には

669:デフォルトの名無しさん
09/06/04 19:14:07
template…

670:デフォルトの名無しさん
09/06/04 21:22:45
>>668
それが最近の統計情報によると、ヘッダの重複コンパイルがコンパイル時間の8割がたを占めていて
ぶっちゃけヘッダ別けファイル別けするよりも、全ヘッダ・ソースを一つに結合してコンパイルしたほうがマシって状況にあるらしい。
さらに、リンクファイルに無闇に外部参照ラベルが出現している上、それがCからの名残でツリー構造ではなく名前空間にヘッダやらフッタやら特殊規則の名前やらが無節操にぶちまけられてまともに検索もできない有様。
古すぎるんだ、技術的に……

昔はこれでよかったんだよ、むしろこうする事により高速なコンパイルが期待できたんだ、だけどこの方法は数が増えるとコンパイル時間が爆発的に増えるんだ。
ちょっともうスレとは関係なさすぎますね、自粛します。

671:デフォルトの名無しさん
09/06/04 21:55:00
倍々ゲームでコンパイル時間が増えていたが、それでもコンピュータのパフォーマンスも倍々ゲームで増えていたので
しばらくは問題にならなかったんだな、しかしDiskIOその他は倍々ゲームパフォーマンスアップはしなかったので次第に問題が表面化してきたと。

672:デフォルトの名無しさん
09/06/04 23:53:55
>>670
ヘッダに全部コードを書いて、ソースはそいつをインクルードしてるだけってソフトがあったんだが、
それが理由なのか。

673:デフォルトの名無しさん
09/06/05 00:56:58
それはアレやないすかね、テンプレートの扱いがややこしいので
割り切って全部ヘッダにしただけやないですかね。

C++ は重複の多さもあるけど、コンパイル時に色々やりすぎって
話もあるんではなかろうか。

674:デフォルトの名無しさん
09/06/05 01:45:06
ひとまとめにしたほうがコンパイラも最適化を聞かせやすい品。
SQLiteがやってる。

675:デフォルトの名無しさん
09/06/05 02:10:54
.NetFrameworkのJITってSIMDを使わないんですか？
使う事があるのはmonoだけですか？

676:デフォルトの名無しさん
09/06/05 02:48:54
せいぜいmovqくらいじゃね

677:デフォルトの名無しさん
09/06/05 02:58:36
>>673
C++のコンパイル速度の遅さは文法の複雑さが主な原因。

678:デフォルトの名無しさん
09/06/05 03:10:57
>>674
VC++はリンク時の最適化というのがあって、
それ使えば全部ひとまとめにしたのと同じような効果が得られる。
まあこれ使うとさらにリンク時間が長くなるんだが。

679:デフォルトの名無しさん
09/06/05 03:47:29
>>675
SIMDが使える環境では使うようにJITコンパイルされる。
Mono.SIMDはSIMDによる"手動の最適化"を"マネージコードだけ"で行えるのが武器。
.NETでやるには部分的にC++/CLIを用いてネイティブで実装する必要がある。

680:デフォルトの名無しさん
09/06/05 03:53:06
むしろC#のコンパイル速度が速すぎる。
入力中にバックグラウンドでコンパイルしてるんじゃないかと疑ってしまったぞ。

681:デフォルトの名無しさん
09/06/05 07:14:37
>>680
VBにしてもJavaにしてもこんなもんじゃね？
デルファイとかさらに早いし

>>677
無意味なコンパイルだと思われる、一度コンパイルし結果が得られるはずであっても、直前のヘッダファイルが変更されると
全部コンパイルし直さない限り、そのままでいいか確定しないからな。
コンパイルの流れがちゃんとすれば、C++よりはるかに複雑な構造は取り扱えるし、C#だって今となってはC++と比較して遜色ないくらい複雑な内容をもっているし。

682:デフォルトの名無しさん
09/06/05 07:21:48
>全部コンパイルし直さない限り、そのままでいいか確定しないからな
この原因を作り出しているのがプリプロセッサで、C系のプリプロセッサの仕組みは今となっては非常にマズイという事になっている。
それとincludeされるファイルがincludeし始めると、対象が指数関数的に増えるのも問題。
C#の場合はどんなに複雑でも、各ファイルが独立しているので、コンパイル時間は線形的にしか増えない。今の言語はほとんどこのスタイル。

683:デフォルトの名無しさん
09/06/05 09:43:48
構文解析やコード生成自体はそんなに大したコストじゃないよ

684:デフォルトの名無しさん
09/06/05 11:11:08
>>683
十分デカイって、特に何か処理のする事がない、ただラベルの付け合わせだけのリンクでさえボロボロのC++においては

685:デフォルトの名無しさん
09/06/05 11:25:48
C言語とオブジェクトファイルをリンクするldの方式は1960年代の技術だからな、C++も基本的にはこの考え方を踏襲しているわけで
かれこれ40年越し、そろそろ半世紀前から使われてきた技術だ、さすがに熟成通り越して酢になってますよ。
今でも実用的に使われているというのはそれだけでも凄い事なんですけどね。

686:デフォルトの名無しさん
09/06/05 12:04:10
>>680
実際にバックグラウンドコンパイルを研究する価値はあるんじゃないか？ｗ
というか、きっと誰かしてる。

687:デフォルトの名無しさん
09/06/05 13:55:37
たしかにコーディング中の入力待ちアイドルタイムって長いもんな

688:デフォルトの名無しさん
09/06/05 15:35:15
これからのC++ではC#やVBがIntelliSenseを使うための情報収集をする時間でコンパイルか……
追い詰まっていると思われ

689:デフォルトの名無しさん
09/06/05 19:08:53
>>686
ていうか書いた奴が
インテリセンスで即反映、コードチェックも即掛かる
なんだからバックグラウンドってーか入力がある度にやってるんじゃないか

690:デフォルトの名無しさん
09/06/05 20:20:30
C++も使うが、Visual Studio 2010はびっくりするほどIntelliSenseが効くようになったのが凄い。
ブログでも今までのを捨てて新しくしたと言っていたし。
まあそれでもC#には敵わないが。

691:デフォルトの名無しさん
09/06/05 21:33:22
個人的にはできる限り早い段階でC++よりC#へ移行させてほしいと願うばかり
さすがにもうC++ではやりきれない

692:デフォルトの名無しさん
09/06/07 09:41:03
C#で十分にできることを、C++でやってるんだとしたら、
それは悲しいことだな

693:デフォルトの名無しさん
09/06/07 10:08:20
激しく計算するような分野じゃC#は使えないよ

694:デフォルトの名無しさん
09/06/07 10:44:08
GUIと通信部分をC#で書いて、計算はworkstationでやってるけど？

695:デフォルトの名無しさん
09/06/07 10:47:45
いいんじゃない

696:デフォルトの名無しさん
09/06/07 11:18:04
だから向き不向きあるゆーとろーが
向いてるところに生産性の悪いC++使うことないともゆーとろーが

697:デフォルトの名無しさん
09/06/07 13:28:22
激しく計算するような分野だが、C#に変えちまったけどな
C++でスレッド管理めんどくさすぎ、やってられない
結局やりきれずにシングルスレッドで書いてC#より遅くて使い物にならん事多々あり

698:デフォルトの名無しさん
09/06/07 13:29:49
いまならC++を使う状況はメモリを直接参照して変更するような処理かな？
いまならC++/CLIつかってその部分だけ書くのが便利かもと思ってる。

C#でちょっとした画像処理をポインタを使用して書いた時は、
unsafeがいちいちめんどくさくてストレスがたまったよ。

699:デフォルトの名無しさん
09/06/07 13:34:34
C#のunsafeでだるいならC++でもだるいだろう。
ちょっとコード書き足すだけだし

700:デフォルトの名無しさん
09/06/07 13:35:43
C++スレで存分に語れよ

701:デフォルトの名無しさん
09/06/07 13:36:11
C++のほうもOpenMPはだいぶ楽だと思う。
C#にもあれくらい簡単に使えるのが欲しい。
というわけで、.NET 4.0の並列化関係のライブラリに期待している。

702:デフォルトの名無しさん
09/06/07 13:37:34
OpenMPは総合力に掛ける、使いどころが限定的すぎる。

703:デフォルトの名無しさん
09/06/07 13:43:00
そんな最強言語決定戦みたいなのは厨二に任せて、
寛容なC#ユーザーはC++を使う人を一々否定しないって顔しとけよ

704:デフォルトの名無しさん
09/06/07 13:43:16
>>699
いや、アンセーフじゃないC++は普通に業務でつかってるかよ。
書くのは全くだるくはないが、ヘッダの依存関係を解決する方が面どくさい。

705:デフォルトの名無しさん
09/06/07 13:44:29
だからC++スレで存分に語れよ

706:デフォルトの名無しさん
09/06/07 14:15:56
public class DoubleList : List<double>
ってクラスがあって、
コンストラクタが
public DoubleList () { }
こうなってる場合は

みたいなクラスを作った場合には、 new DoubleList()
が呼ばれた時点でList<double>が作られますよね？

ここで Listのコンストラクタのうち、引数としてcapacityをとるものを
DoubleListのコンストラクタとしても用意したいのですが、どうしたらいいでしょうか？

707:デフォルトの名無しさん
09/06/07 14:24:58
public DoubleList(int capacity) : base(capacity) {
}

708:デフォルトの名無しさん
09/06/07 14:25:23
public クラス名() : base(スーパークラスの引数) {}

709:デフォルトの名無しさん
09/06/07 14:29:44
少しエスパーしてみた、本当に欲しいのはこっちか？、ちがってたらまぁ適当にやってくれ。
using DoubleList = List<double>;

710:706
09/06/07 14:31:20
>>707,708さん

それです！ありがとうございました。

>>709さん
doubleの可変長配列に各種メソッドの追加、演算子のオーバーロード等がしたくて
DoubleListなんて作ってました。

皆様ありがとうございました。

711:デフォルトの名無しさん
09/06/07 14:39:09
>>710
ならば、定石としてはコンポジションをとるべきである、多態性を目的としない機能追加を伴う導出は悪だ。

712:デフォルトの名無しさん
09/06/07 14:41:54
extention method もあるな

713:デフォルトの名無しさん
09/06/07 15:27:51
>>703
C++使う人を否定してるってよりは、
仕事でいやいやC++使ってる自分を否定したいんでは。

714:デフォルトの名無しさん
09/06/07 16:17:41
DoubleListだが、こいつはIList<T> に対するアダプターパターンで解決するのが基本かと。
演算子のオーバーロードというのだから、線形代数系の何かだと思われるが。
相手がList<double>限定では汎用度が低すぎるしな、double [] にも適用したいだろう。
特にIList系より抽象度が低くてよいのなら、IEnumerable<T>ベースで作ってやればLINQの恩恵にもあずかれるだろうし。

715:デフォルトの名無しさん
09/06/07 20:13:25
スレ違いかもしれませんが・・・

VS2008で、#regionで閉じられたソースを一気に全部開きたいのですが、
何かショートカットキーはあるのでしょうか？

716:デフォルトの名無しさん
09/06/07 20:31:32
Ctrl+M, M

717:デフォルトの名無しさん
09/06/07 20:48:09
>716

ありがとうございます。
CTRL+M系で色々できるんですね。

718:706
09/06/07 22:30:26
>>711,712さん

コンポジションって
public class DoubleList{
private List<double> list;
}
ってメンバ変数にしちゃうってことですよね？

その場合ってインデクサとかList<double>のうちすべてを自分でDoubleListに実装するってことですか？

手間ばかりであまりご利益が感じられないのですが。

719:デフォルトの名無しさん
09/06/07 22:56:24
>>718
コンポジションが嫌なら、Collection<double>からの派生にすればいい。
こいつの派生なら許せる。

720:デフォルトの名無しさん
09/06/07 23:10:14
>>718
継承は、依存関係が強くなりすぎるのが嫌われる。
手間はかかるけど、我慢してコンポジションにする人多い。
自分も、手間掛ける時間あるならそうする。

721:デフォルトの名無しさん
09/06/07 23:12:28
コンポジションを作るプログラム書けばいいじゃん、すぐ終わるよ

722:デフォルトの名無しさん
09/06/07 23:47:39
設計屋のオナニーって感じだな
List<double>がダメでCollection<double>は許せるとか
意味不明

723:デフォルトの名無しさん
09/06/08 00:19:20
Collectionは中の実装に依存しないから。
実装変えるたびに継承関係が変わったら話にならない。

724:デフォルトの名無しさん
09/06/08 00:28:40
>Collectionは中の実装に依存しないから。
中の実装ってどこを指してんの？

725:デフォルトの名無しさん
09/06/08 06:41:21
言ってることが滅茶苦茶だな

726:デフォルトの名無しさん
09/06/08 07:41:27
>>724
CollectionはList実装であることに依存しない、つー話じゃないの

727:デフォルトの名無しさん
09/06/08 09:09:07
>>724
以下のような話はわかる？

・.NET においては List って時点で配列リストの事を指してる
・List を継承するってのは「配列リストで実装します」と宣言するようなもの
・後からアルゴリズム変えたい（連結リストにしたり両端キューにしたり）場合があると困る
・コンポジションで作ってれば後から変えるのも自由

728:デフォルトの名無しさん
09/06/08 09:27:33
is-implemented-in-terms-of関係

729:デフォルトの名無しさん
09/06/08 13:32:30
グダグタ言わずにインターフェイスは多重継承可、クラスの継承はまずしなくても十分に汎用性が取れないか検討してから
クラスの継承は多態性が必要になった時に使う、しかし可能な限りインターフェイス継承。
100の屁理屈より100の実践、守ってやっていれば、なぜそうすることが良いか自然に分かる。

730:デフォルトの名無しさん
09/06/08 13:46:19
>>718
public class DoubleList : IList<double> {
private List<double> list;
}
こうすべきだな、他に必要なインターフェイスがあるならそれも加えておく。
最新のVS2008ならIList<double>と書けば、此処をクリックしろとマークがでるので、それをクリックして必要なスタブを全部生成すると便利だ。
こうやってList<double>の『実装に依存』させるのではなく、List<double>の『インターフェイスに依存』させるのだ。

731:デフォルトの名無しさん
09/06/08 14:00:53
「インターフェースの明示的な実装」
すげー、こんなのあったのか

732:デフォルトの名無しさん
09/06/08 14:08:45
結局のところ継承ってのは既に完成しているクラスを改造する行為で、コンポジションとインターフェイスにすると言う事は、
既に完成しているクラスをそのまま利用しつつ、共通項目を共通した方法で取り扱えるようにするという事。
改造する行為はバグを誘発しやすいんだな、なにしろ作った本人どういう手順で改造して欲しいまではあまりドキュメンテーションしないししきれないからね。
ブラックボックスをこじ開けるような行為はしない方が良いのです。

733:デフォルトの名無しさん
09/06/08 16:04:05
>>730
(スコア:5, 参考になる)

734:デフォルトの名無しさん
09/06/08 17:49:24
こういう初歩的なのはMSDNで3分でわかる○○等でやっているから見ておくといい
設計方法としてもオブジェクト指向の初歩なので、こういうのを知らなかったなら、一度一からオブジェクト指向を勉強するのがいい。
導出が分かればオブジェクト指向などというメチャクチャなのが時折いるが、あなんのは絶対に駄目だからな。

735:デフォルトの名無しさん
09/06/08 18:04:24
なにいってんだかわかんねｗ

736:デフォルトの名無しさん
09/06/08 18:24:45
>>726-727
少なくとも
System.Collections.ObjectModel.Collection<T>
はIListを実装した配列リストなんだが
Collectionも配列リストだ

クラスとインターフェイスと一般的な概念をぐちゃぐちゃにして話してないか？
インターフェイスはIをつける
一般的な概念はそれとわかるような文脈で書いてくれ
頼むから

737:デフォルトの名無しさん
09/06/08 18:28:10
とりあえず大元の質問者がList<double>から継承するっていうんなら、
Listにしかないメソッドを使いたいとかいうのもあるんじゃないか
Find系とか。doubleだしな
なんで>>730みたいにIListで十分と思えるのかがわからん
もしかしてIListはListの公開メソッド/プロパティ全部カバーしてると思ってる？

>>734
まったくだな
MSDNも見ずに一般論だけで偉そうに講釈垂れるのは
ハタ迷惑なアホだな

738:デフォルトの名無しさん
09/06/08 18:31:49
>>737
>Listにしかないメソッドを使いたいとかいうのもあるんじゃないか
それは完全に間違っているような気が……

>もしかしてIListはListの公開メソッド/プロパティ全部カバーしてると思ってる？
そういう問題ではないだろうという気が……

危険だ

739:デフォルトの名無しさん
09/06/08 18:33:27
>>737
「List<T>にしか無いメソッド」も実装すればいいじゃない

740:デフォルトの名無しさん
09/06/08 18:33:47
深いオブジェクト指向の知識など要らないとは思うけれど、必要最低限の知識はもっていてもらいたいものです……

741:デフォルトの名無しさん
09/06/08 18:38:42
MSDNは短い割にはポイント絞った良いセミナーやるからな、見ておいて損は無いよ。
特にビデオ物、流してみておくだけでも思わぬ拾い物が多い。

742:デフォルトの名無しさん
09/06/08 18:43:21
そういやjavaとか
StackがVectorから派生してるとかいうバカ設計なんだよなｗ
Stackなのにランダムアクセスできるｗｗｗ

743:デフォルトの名無しさん
09/06/08 18:51:36
>>742
処理系によるけど、コールスタックに積んだ引数とか、
普通にSP使ってランダムアクセスする場合の方が多い気がするのだが。
べつに、スタックだからって必ずいちいちpopしなきゃダメってこたないよ。

次ページ