[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 03/27 07:18 / Filesize : 229 KB / Number-of Response : 925
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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



1 名前:デフォルトの名無しさん mailto:sage [2009/04/01(水) 10:15:52 ]
(#゚ー゚)つ < C#、.NETの話題はこちらでどうぞ。

前スレ
C#, C♯, C#相談室 Part51
pc12.2ch.net/test/read.cgi/tech/1233757615/

Visual C# 2008 Express Edition 日本語版
www.microsoft.com/japan/msdn/vstudio/express/vcsharp/

その他テンプレ>>2-5くらい

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

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

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

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

675 名前:デフォルトの名無しさん mailto:sage [2009/06/05(金) 02:10:54 ]
.NetFrameworkのJITってSIMDを使わないんですか?
使う事があるのはmonoだけですか?

676 名前:デフォルトの名無しさん mailto:sage [2009/06/05(金) 02:48:54 ]
せいぜいmovqくらいじゃね

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

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

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

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



681 名前:デフォルトの名無しさん mailto:sage [2009/06/05(金) 07:14:37 ]
>>680
VBにしてもJavaにしてもこんなもんじゃね?
デルファイとかさらに早いし

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

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

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

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

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

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

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

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

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

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



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

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

693 名前:デフォルトの名無しさん mailto:sage [2009/06/07(日) 10:08:20 ]
激しく計算するような分野じゃC#は使えないよ

694 名前:デフォルトの名無しさん mailto:sage [2009/06/07(日) 10:44:08 ]
GUIと通信部分をC#で書いて、計算はworkstationでやってるけど?

695 名前:デフォルトの名無しさん mailto:sage [2009/06/07(日) 10:47:45 ]
いいんじゃない

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

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

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

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

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

700 名前:デフォルトの名無しさん mailto:sage [2009/06/07(日) 13:35:43 ]
C++スレで存分に語れよ



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

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

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

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

705 名前:デフォルトの名無しさん mailto:sage [2009/06/07(日) 13:44:29 ]
だからC++スレで存分に語れよ


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

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

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

707 名前:デフォルトの名無しさん mailto:sage [2009/06/07(日) 14:24:58 ]
public DoubleList(int capacity) : base(capacity) {
}

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

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

710 名前:706 mailto:sage [2009/06/07(日) 14:31:20 ]
>>707,708さん

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

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

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



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

712 名前:デフォルトの名無しさん mailto:sage [2009/06/07(日) 14:41:54 ]
extention method もあるな

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

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

715 名前:デフォルトの名無しさん [2009/06/07(日) 20:13:25 ]
スレ違いかもしれませんが・・・

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

716 名前:デフォルトの名無しさん mailto:sage [2009/06/07(日) 20:31:32 ]
Ctrl+M, M

717 名前:デフォルトの名無しさん mailto:sage [2009/06/07(日) 20:48:09 ]
>716

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


718 名前:706 mailto:sage [2009/06/07(日) 22:30:26 ]
>>711,712さん

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

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

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

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

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



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

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

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

724 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 00:28:40 ]
>Collectionは中の実装に依存しないから。
中の実装ってどこを指してんの?

725 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 06:41:21 ]
言ってることが滅茶苦茶だな

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

727 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 09:09:07 ]
>>724
以下のような話はわかる?

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


728 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 09:27:33 ]
is-implemented-in-terms-of関係

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

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



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

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

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

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

735 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 18:04:24 ]
なにいってんだかわかんねw

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

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

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

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

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

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

危険だ


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

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



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

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

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

744 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 18:55:24 ]
>>743
一般的なスタックの概念から外れてるんじゃないかい?
>>727みたいな話になるけども

745 名前:デフォルトの名無しさん [2009/06/08(月) 19:02:05 ]
>>743
それならStackなんていらない
リストで代用できるしその方が速い

746 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 19:03:38 ]
>>736
あー、そうだった。

でもまぁ、この話って、インターフェースプログラミングのお作法以前の話として、
C#のコレクションの分類に一貫性がないというか滅茶苦茶なのが一番の癌なんじゃないかなぁ。

IListってのがあったら、普通Listはその直系の具象実装だと思うわなぁ。

747 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 19:04:26 ]
明示的にスタックとしているのにインデクサでアクセスされたらたまらんな。
おお怖い。

748 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 19:06:01 ]
まずいとおもったから作りなおしたんでしょ。1.2だかで

749 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 19:06:18 ]
>>746
まあね

750 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 19:08:38 ]
>>744
コールスタックって、スタックの第一級の応用例じゃないのかね。

>>745
適当だけど、

int sp = 0;
int[] stack = new int[100];
void push(int i) { stack[sp++]; }
int pop() { return stack[sp--]; }

みたいなノリの実装だったら、少なくともpush(), pop()はlistより高速なんでないかね。
ランダムアクセスのオーダーもListと等価になるし、特にListのが優位な点も見当たらないが。



751 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 19:09:08 ]
C#のコレクションはLINQと相まって、もういっぺん見直した方がいいとは思う
上のFindの話もそうなんだけど、ああいうメソッドがコレクションについているべきではないと思われるし。

752 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 19:11:37 ]
Find系は以前からあるから、新加入のLINQと役割的に競合してるわけね

753 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 19:13:10 ]
一発で決まる綺麗な実装は難しいね、LINQの汎用性ときたら半端じゃない。

754 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 19:13:11 ]
>>750
そのへんは相当シビアな速度求められるところだから
[]演算子で先頭アドレス基準にアドレス計算しなおすだけで
ふざけんなって言われるよ

755 名前:デフォルトの名無しさん [2009/06/08(月) 19:14:14 ]
SilverlightではLINQと被ってるのはごっそり削られました

756 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 19:15:35 ]
>>754
JavaやC#といった言語はオプティマイズ問題とインターフェイスの問題はきれいに切り分けられるように工夫された言語なんだから、ごっちゃにするなよ。

757 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 19:17:43 ]
>>756
コールスタックの話題だろ?
>>750が持ち出してるのは

758 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 19:19:01 ]
>>754
C/C++で組み込みのリアルタイムシステムを書いてるならともかく、
JavaとかC#で、そのレベルのチューニングを要求するのはナンセンスな気がするのだが。
そもそも、中間言語レベルでも整数のインクリメントなんて1opじゃないのかね。

759 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 19:20:56 ]
>>757
で、コールスタックになったら問題が何か変わるわけ?
スタックフレームの知識はあるよ、アセンブラやってたから、心配せずに言ってみな。

760 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 19:22:56 ]
>>757
ん?
Stackでランダムアクセスをしちゃいけない理由ってのがあるか否かって話じゃないの?

ちなみに、CPUレベルの話なら、pushとpopはほぼノーコストでしょ。
JavaやC#の話をしてるなら>>758



761 名前:デフォルトの名無しさん [2009/06/08(月) 19:25:50 ]
だからランダムアクセスできたら何のためにリストとは別にスタックがあるのかわからなくなるだろ

762 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 19:31:02 ]
>>761
push()とpop()とpeek()が使える、Listの特殊な場合がStack、って分類なだけでしょ。
実装的にもアルゴリズムのオーダー的にも差異はほぼ無いわけだし。

アセンブラレベルでpushとpopを特別扱いしてるのは、詳しくは知らないけど、
それこそコールスタックで使うとか歴史的理由とかその辺じゃないの?

763 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 19:32:06 ]
>>762
差異がないってw

764 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 19:37:16 ]
>>762
あんま関係ないけど、呼び出しスタックはダイクストラという偉い人がスタックはハードウェア化すべきだとのたまわったので、以後のCPUでは多く採用された。
構造化プログラミングの提唱者の人ね、その後RISCという方法が主流になって再び捨てられた。
歴史的にはそんな感じ

765 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 19:38:13 ]
>>763
実際、Javaではそのように扱っていて、特に問題は起きてないわけだが。

逆に、「ランダムアクセスができるものはスタックとは呼ばない」という定義が
一般的だと主張するなら、それを示してくれ。
「○○という計算機科学の教科書に書いてあった」とかそういうのでもいいよ。

766 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 19:39:15 ]
>>764
そーか、それは知らなかった。勉強になったよサンクス。

767 名前:デフォルトの名無しさん [2009/06/08(月) 19:40:24 ]
だから.NETのStackではあえて差異をつけてるんだろ
同じなら二つもいらない

768 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 19:41:44 ]
>>765
無意味なところに話を持っていくなぁ

769 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 19:53:06 ]
Stackでランダムアクセスができるのはおかしい
というのに異論がある人がいるとは思わなかったじぇ。

770 名前:デフォルトの名無しさん [2009/06/08(月) 19:57:24 ]
できたら意味がない
というだけのことなのに…



771 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 20:01:45 ]
>>769-770
じゃあ、コールスタックはおかしくないのか、というところに話が戻るわけだが。

772 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 20:08:31 ]
IListインターフェイス付きのコレクションと、そうでないコレクションは実装は同じでも設計レベルでは分けて考えろという事。
実装からインターフェイスを分離独立せよ、これがわからんやつはプログラマ廃業したほうがいい。






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<229KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef