トップページ⇒tech
1001コメント316KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2009/04/01(水) 10:15:52
(#ﾟーﾟ)つ ＜ C#、.NETの話題はこちらでどうぞ。

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

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

その他テンプレ>>2-5くらい
0655デフォルトの名無しさん2009/06/04(木) 08:06:22
そりゃ、C# でググって出てくる上位サイトは
たいてい1.0とかそれのCTPの頃からC#の記事書いてるし、
その人らは予想してただろ。
0656デフォルトの名無しさん2009/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年の記事眺めてて噴いたｗ　今だからこそ言える。ねーよｗｗｗ
0657デフォルトの名無しさん2009/06/04(木) 11:41:06
>>652
>昔C++で今はC#メインだが、コンパイル速度が激速な点が一番うれしい。
C#が速いというよりもC++が致命的に遅いというのが実態な気がする。
いずれにしても、ある程度の規模を超えたらC++のコンパイル時間・リンク時間は実用的でないです
特にリンクが遅いのが余りに致命的
0658デフォルトの名無しさん2009/06/04(木) 11:47:56
>>656
Core2辺りで一応達成といえるんじゃないかな、Pen4と同クロック比較で2倍程度(当時のCPUの想定はPen4クラスだと思われる)
メモリは一応2Gにはなった、HDD1Tバイト超だけが実現されていないかと
しかし、必要ない人には今の時点でもHDDは余っているだろうね
0659デフォルトの名無しさん2009/06/04(木) 14:18:04
>>657
ヘッダ書き換えた時のコストがあまりにもひどいと思うよ。
0660デフォルトの名無しさん2009/06/04(木) 14:20:34
>>659
それに関しては、分散コンパイルを使えば……、あんまり解決してないけど一応解決する
けれどもリンクはもう完全にお手上げ
0661デフォルトの名無しさん2009/06/04(木) 14:27:54
今や、マネージコードで書かれたFPSなんかが出てきても、驚くほどのことじゃないな。
0662デフォルトの名無しさん2009/06/04(木) 15:06:12
FPSって何？
0663デフォルトの名無しさん2009/06/04(木) 15:08:35
ファーストパーソンシューティング
ゲームの一ジャンル。欧米で今一番はやってる形態
0664デフォルトの名無しさん2009/06/04(木) 15:12:38
ファーストパーソンズシュータアァー！
0665デフォルトの名無しさん2009/06/04(木) 17:06:53
空気よまずに、、、

フレーム・パー・セコンド
0666デフォルトの名無しさん2009/06/04(木) 17:52:15
そういや、Silverlight3で書かれたFPSのデモがあったな
普通に3Dの画面がサクサク動いてて驚いた
0667デフォルトの名無しさん2009/06/04(木) 18:33:59
>>666
これ？
http://www.innoveware.com/quakelight.html
0668デフォルトの名無しさん2009/06/04(木) 18:55:11
>>659
そういうコストを減らすために
ヘッダの依存を分散させる設計が必要
そのコストが高いってことは設計が悪いってことだ
ヘッダのあるプログラミング言語的には
0669デフォルトの名無しさん2009/06/04(木) 19:14:07
template…
0670デフォルトの名無しさん2009/06/04(木) 21:22:45
>>668
それが最近の統計情報によると、ヘッダの重複コンパイルがコンパイル時間の8割がたを占めていて
ぶっちゃけヘッダ別けファイル別けするよりも、全ヘッダ・ソースを一つに結合してコンパイルしたほうがマシって状況にあるらしい。
さらに、リンクファイルに無闇に外部参照ラベルが出現している上、それがCからの名残でツリー構造ではなく名前空間にヘッダやらフッタやら特殊規則の名前やらが無節操にぶちまけられてまともに検索もできない有様。
古すぎるんだ、技術的に……

昔はこれでよかったんだよ、むしろこうする事により高速なコンパイルが期待できたんだ、だけどこの方法は数が増えるとコンパイル時間が爆発的に増えるんだ。
ちょっともうスレとは関係なさすぎますね、自粛します。
0671デフォルトの名無しさん2009/06/04(木) 21:55:00
倍々ゲームでコンパイル時間が増えていたが、それでもコンピュータのパフォーマンスも倍々ゲームで増えていたので
しばらくは問題にならなかったんだな、しかしDiskIOその他は倍々ゲームパフォーマンスアップはしなかったので次第に問題が表面化してきたと。
0672デフォルトの名無しさん2009/06/04(木) 23:53:55
>>670
ヘッダに全部コードを書いて、ソースはそいつをインクルードしてるだけってソフトがあったんだが、
それが理由なのか。
0673デフォルトの名無しさん2009/06/05(金) 00:56:58
それはアレやないすかね、テンプレートの扱いがややこしいので
割り切って全部ヘッダにしただけやないですかね。

C++ は重複の多さもあるけど、コンパイル時に色々やりすぎって
話もあるんではなかろうか。
0674デフォルトの名無しさん2009/06/05(金) 01:45:06
ひとまとめにしたほうがコンパイラも最適化を聞かせやすい品。
SQLiteがやってる。
0675デフォルトの名無しさん2009/06/05(金) 02:10:54
.NetFrameworkのJITってSIMDを使わないんですか？
使う事があるのはmonoだけですか？
0676デフォルトの名無しさん2009/06/05(金) 02:48:54
せいぜいmovqくらいじゃね
0677デフォルトの名無しさん2009/06/05(金) 02:58:36
>>673
C++のコンパイル速度の遅さは文法の複雑さが主な原因。
0678デフォルトの名無しさん2009/06/05(金) 03:10:57
>>674
VC++はリンク時の最適化というのがあって、
それ使えば全部ひとまとめにしたのと同じような効果が得られる。
まあこれ使うとさらにリンク時間が長くなるんだが。
0679デフォルトの名無しさん2009/06/05(金) 03:47:29
>>675
SIMDが使える環境では使うようにJITコンパイルされる。
Mono.SIMDはSIMDによる"手動の最適化"を"マネージコードだけ"で行えるのが武器。
.NETでやるには部分的にC++/CLIを用いてネイティブで実装する必要がある。
0680デフォルトの名無しさん2009/06/05(金) 03:53:06
むしろC#のコンパイル速度が速すぎる。
入力中にバックグラウンドでコンパイルしてるんじゃないかと疑ってしまったぞ。
0681デフォルトの名無しさん2009/06/05(金) 07:14:37
>>680
VBにしてもJavaにしてもこんなもんじゃね？
デルファイとかさらに早いし

>>677
無意味なコンパイルだと思われる、一度コンパイルし結果が得られるはずであっても、直前のヘッダファイルが変更されると
全部コンパイルし直さない限り、そのままでいいか確定しないからな。
コンパイルの流れがちゃんとすれば、C++よりはるかに複雑な構造は取り扱えるし、C#だって今となってはC++と比較して遜色ないくらい複雑な内容をもっているし。
0682デフォルトの名無しさん2009/06/05(金) 07:21:48
>全部コンパイルし直さない限り、そのままでいいか確定しないからな
この原因を作り出しているのがプリプロセッサで、C系のプリプロセッサの仕組みは今となっては非常にマズイという事になっている。
それとincludeされるファイルがincludeし始めると、対象が指数関数的に増えるのも問題。
C#の場合はどんなに複雑でも、各ファイルが独立しているので、コンパイル時間は線形的にしか増えない。今の言語はほとんどこのスタイル。
0683デフォルトの名無しさん2009/06/05(金) 09:43:48
構文解析やコード生成自体はそんなに大したコストじゃないよ
0684デフォルトの名無しさん2009/06/05(金) 11:11:08
>>683
十分デカイって、特に何か処理のする事がない、ただラベルの付け合わせだけのリンクでさえボロボロのC++においては
0685デフォルトの名無しさん2009/06/05(金) 11:25:48
C言語とオブジェクトファイルをリンクするldの方式は1960年代の技術だからな、C++も基本的にはこの考え方を踏襲しているわけで
かれこれ40年越し、そろそろ半世紀前から使われてきた技術だ、さすがに熟成通り越して酢になってますよ。
今でも実用的に使われているというのはそれだけでも凄い事なんですけどね。
0686デフォルトの名無しさん2009/06/05(金) 12:04:10
>>680
実際にバックグラウンドコンパイルを研究する価値はあるんじゃないか？ｗ
というか、きっと誰かしてる。
0687デフォルトの名無しさん2009/06/05(金) 13:55:37
たしかにコーディング中の入力待ちアイドルタイムって長いもんな
0688デフォルトの名無しさん2009/06/05(金) 15:35:15
これからのC++ではC#やVBがIntelliSenseを使うための情報収集をする時間でコンパイルか……
追い詰まっていると思われ
0689デフォルトの名無しさん2009/06/05(金) 19:08:53
>>686
ていうか書いた奴が
インテリセンスで即反映、コードチェックも即掛かる
なんだからバックグラウンドってーか入力がある度にやってるんじゃないか
0690デフォルトの名無しさん2009/06/05(金) 20:20:30
C++も使うが、Visual Studio 2010はびっくりするほどIntelliSenseが効くようになったのが凄い。
ブログでも今までのを捨てて新しくしたと言っていたし。
まあそれでもC#には敵わないが。
0691デフォルトの名無しさん2009/06/05(金) 21:33:22
個人的にはできる限り早い段階でC++よりC#へ移行させてほしいと願うばかり
さすがにもうC++ではやりきれない
0692デフォルトの名無しさん2009/06/07(日) 09:41:03
C#で十分にできることを、C++でやってるんだとしたら、
それは悲しいことだな
0693デフォルトの名無しさん2009/06/07(日) 10:08:20
激しく計算するような分野じゃC#は使えないよ
0694デフォルトの名無しさん2009/06/07(日) 10:44:08
GUIと通信部分をC#で書いて、計算はworkstationでやってるけど？
0695デフォルトの名無しさん2009/06/07(日) 10:47:45
いいんじゃない
0696デフォルトの名無しさん2009/06/07(日) 11:18:04
だから向き不向きあるゆーとろーが
向いてるところに生産性の悪いC++使うことないともゆーとろーが
0697デフォルトの名無しさん2009/06/07(日) 13:28:22
激しく計算するような分野だが、C#に変えちまったけどな
C++でスレッド管理めんどくさすぎ、やってられない
結局やりきれずにシングルスレッドで書いてC#より遅くて使い物にならん事多々あり
0698デフォルトの名無しさん2009/06/07(日) 13:29:49
いまならC++を使う状況はメモリを直接参照して変更するような処理かな？
いまならC++/CLIつかってその部分だけ書くのが便利かもと思ってる。

C#でちょっとした画像処理をポインタを使用して書いた時は、
unsafeがいちいちめんどくさくてストレスがたまったよ。
0699デフォルトの名無しさん2009/06/07(日) 13:34:34
C#のunsafeでだるいならC++でもだるいだろう。
ちょっとコード書き足すだけだし
0700デフォルトの名無しさん2009/06/07(日) 13:35:43
C++スレで存分に語れよ
0701デフォルトの名無しさん2009/06/07(日) 13:36:11
C++のほうもOpenMPはだいぶ楽だと思う。
C#にもあれくらい簡単に使えるのが欲しい。
というわけで、.NET 4.0の並列化関係のライブラリに期待している。
0702デフォルトの名無しさん2009/06/07(日) 13:37:34
OpenMPは総合力に掛ける、使いどころが限定的すぎる。
0703デフォルトの名無しさん2009/06/07(日) 13:43:00
そんな最強言語決定戦みたいなのは厨二に任せて、
寛容なC#ユーザーはC++を使う人を一々否定しないって顔しとけよ
0704デフォルトの名無しさん2009/06/07(日) 13:43:16
>>699
いや、アンセーフじゃないC++は普通に業務でつかってるかよ。
書くのは全くだるくはないが、ヘッダの依存関係を解決する方が面どくさい。
0705デフォルトの名無しさん2009/06/07(日) 13:44:29
だからC++スレで存分に語れよ
0706デフォルトの名無しさん2009/06/07(日) 14:15:56
public class DoubleList : List<double>
ってクラスがあって、
コンストラクタが
public DoubleList () { }
こうなってる場合は

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

ここで Listのコンストラクタのうち、引数としてcapacityをとるものを
DoubleListのコンストラクタとしても用意したいのですが、どうしたらいいでしょうか？
0707デフォルトの名無しさん2009/06/07(日) 14:24:58
public DoubleList(int capacity) : base(capacity) {
}
0708デフォルトの名無しさん2009/06/07(日) 14:25:23
public クラス名() : base(スーパークラスの引数) {}
0709デフォルトの名無しさん2009/06/07(日) 14:29:44
少しエスパーしてみた、本当に欲しいのはこっちか？、ちがってたらまぁ適当にやってくれ。
using DoubleList = List<double>;
07107062009/06/07(日) 14:31:20
>>707,708さん

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

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

皆様ありがとうございました。
0711デフォルトの名無しさん2009/06/07(日) 14:39:09
>>710
ならば、定石としてはコンポジションをとるべきである、多態性を目的としない機能追加を伴う導出は悪だ。
0712デフォルトの名無しさん2009/06/07(日) 14:41:54
extention method もあるな
0713デフォルトの名無しさん2009/06/07(日) 15:27:51
>>703
C++使う人を否定してるってよりは、
仕事でいやいやC++使ってる自分を否定したいんでは。
0714デフォルトの名無しさん2009/06/07(日) 16:17:41
DoubleListだが、こいつはIList<T> に対するアダプターパターンで解決するのが基本かと。
演算子のオーバーロードというのだから、線形代数系の何かだと思われるが。
相手がList<double>限定では汎用度が低すぎるしな、double [] にも適用したいだろう。
特にIList系より抽象度が低くてよいのなら、IEnumerable<T>ベースで作ってやればLINQの恩恵にもあずかれるだろうし。
0715デフォルトの名無しさん2009/06/07(日) 20:13:25
スレ違いかもしれませんが・・・

VS2008で、#regionで閉じられたソースを一気に全部開きたいのですが、
何かショートカットキーはあるのでしょうか？
0716デフォルトの名無しさん2009/06/07(日) 20:31:32
Ctrl+M, M
0717デフォルトの名無しさん2009/06/07(日) 20:48:09
>716

ありがとうございます。
CTRL+M系で色々できるんですね。
07187062009/06/07(日) 22:30:26
>>711,712さん

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

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

手間ばかりであまりご利益が感じられないのですが。
0719デフォルトの名無しさん2009/06/07(日) 22:56:24
>>718
コンポジションが嫌なら、Collection<double>からの派生にすればいい。
こいつの派生なら許せる。
0720デフォルトの名無しさん2009/06/07(日) 23:10:14
>>718
継承は、依存関係が強くなりすぎるのが嫌われる。
手間はかかるけど、我慢してコンポジションにする人多い。
自分も、手間掛ける時間あるならそうする。
0721デフォルトの名無しさん2009/06/07(日) 23:12:28
コンポジションを作るプログラム書けばいいじゃん、すぐ終わるよ
0722デフォルトの名無しさん2009/06/07(日) 23:47:39
設計屋のオナニーって感じだな
List<double>がダメでCollection<double>は許せるとか
意味不明
0723デフォルトの名無しさん2009/06/08(月) 00:19:20
Collectionは中の実装に依存しないから。
実装変えるたびに継承関係が変わったら話にならない。
0724デフォルトの名無しさん2009/06/08(月) 00:28:40
>Collectionは中の実装に依存しないから。
中の実装ってどこを指してんの？
0725デフォルトの名無しさん2009/06/08(月) 06:41:21
言ってることが滅茶苦茶だな
0726デフォルトの名無しさん2009/06/08(月) 07:41:27
>>724
CollectionはList実装であることに依存しない、つー話じゃないの
0727デフォルトの名無しさん2009/06/08(月) 09:09:07
>>724
以下のような話はわかる？

・.NET においては List って時点で配列リストの事を指してる
・List を継承するってのは「配列リストで実装します」と宣言するようなもの
・後からアルゴリズム変えたい（連結リストにしたり両端キューにしたり）場合があると困る
・コンポジションで作ってれば後から変えるのも自由
0728デフォルトの名無しさん2009/06/08(月) 09:27:33
is-implemented-in-terms-of関係
0729デフォルトの名無しさん2009/06/08(月) 13:32:30
グダグタ言わずにインターフェイスは多重継承可、クラスの継承はまずしなくても十分に汎用性が取れないか検討してから
クラスの継承は多態性が必要になった時に使う、しかし可能な限りインターフェイス継承。
100の屁理屈より100の実践、守ってやっていれば、なぜそうすることが良いか自然に分かる。
0730デフォルトの名無しさん2009/06/08(月) 13:46:19
>>718
public class DoubleList : IList<double> {
private List<double> list;
}
こうすべきだな、他に必要なインターフェイスがあるならそれも加えておく。
最新のVS2008ならIList<double>と書けば、此処をクリックしろとマークがでるので、それをクリックして必要なスタブを全部生成すると便利だ。
こうやってList<double>の『実装に依存』させるのではなく、List<double>の『インターフェイスに依存』させるのだ。
0731デフォルトの名無しさん2009/06/08(月) 14:00:53
「インターフェースの明示的な実装」
すげー、こんなのあったのか
0732デフォルトの名無しさん2009/06/08(月) 14:08:45
結局のところ継承ってのは既に完成しているクラスを改造する行為で、コンポジションとインターフェイスにすると言う事は、
既に完成しているクラスをそのまま利用しつつ、共通項目を共通した方法で取り扱えるようにするという事。
改造する行為はバグを誘発しやすいんだな、なにしろ作った本人どういう手順で改造して欲しいまではあまりドキュメンテーションしないししきれないからね。
ブラックボックスをこじ開けるような行為はしない方が良いのです。
0733デフォルトの名無しさん2009/06/08(月) 16:04:05
>>730
(スコア:5, 参考になる)
0734デフォルトの名無しさん2009/06/08(月) 17:49:24
こういう初歩的なのはMSDNで3分でわかる○○等でやっているから見ておくといい
設計方法としてもオブジェクト指向の初歩なので、こういうのを知らなかったなら、一度一からオブジェクト指向を勉強するのがいい。
導出が分かればオブジェクト指向などというメチャクチャなのが時折いるが、あなんのは絶対に駄目だからな。
0735デフォルトの名無しさん2009/06/08(月) 18:04:24
なにいってんだかわかんねｗ
0736デフォルトの名無しさん2009/06/08(月) 18:24:45
>>726-727
少なくとも
System.Collections.ObjectModel.Collection<T>
はIListを実装した配列リストなんだが
Collectionも配列リストだ

クラスとインターフェイスと一般的な概念をぐちゃぐちゃにして話してないか？
インターフェイスはIをつける
一般的な概念はそれとわかるような文脈で書いてくれ
頼むから
0737デフォルトの名無しさん2009/06/08(月) 18:28:10
とりあえず大元の質問者がList<double>から継承するっていうんなら、
Listにしかないメソッドを使いたいとかいうのもあるんじゃないか
Find系とか。doubleだしな
なんで>>730みたいにIListで十分と思えるのかがわからん
もしかしてIListはListの公開メソッド/プロパティ全部カバーしてると思ってる？

>>734
まったくだな
MSDNも見ずに一般論だけで偉そうに講釈垂れるのは
ハタ迷惑なアホだな
0738デフォルトの名無しさん2009/06/08(月) 18:31:49
>>737
>Listにしかないメソッドを使いたいとかいうのもあるんじゃないか
それは完全に間違っているような気が……

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

危険だ
0739デフォルトの名無しさん2009/06/08(月) 18:33:27
>>737
「List<T>にしか無いメソッド」も実装すればいいじゃない
0740デフォルトの名無しさん2009/06/08(月) 18:33:47
深いオブジェクト指向の知識など要らないとは思うけれど、必要最低限の知識はもっていてもらいたいものです……
0741デフォルトの名無しさん2009/06/08(月) 18:38:42
MSDNは短い割にはポイント絞った良いセミナーやるからな、見ておいて損は無いよ。
特にビデオ物、流してみておくだけでも思わぬ拾い物が多い。
0742デフォルトの名無しさん2009/06/08(月) 18:43:21
そういやjavaとか
StackがVectorから派生してるとかいうバカ設計なんだよなｗ
Stackなのにランダムアクセスできるｗｗｗ
0743デフォルトの名無しさん2009/06/08(月) 18:51:36
>>742
処理系によるけど、コールスタックに積んだ引数とか、
普通にSP使ってランダムアクセスする場合の方が多い気がするのだが。
べつに、スタックだからって必ずいちいちpopしなきゃダメってこたないよ。
0744デフォルトの名無しさん2009/06/08(月) 18:55:24
>>743
一般的なスタックの概念から外れてるんじゃないかい？
>>727みたいな話になるけども
0745デフォルトの名無しさん2009/06/08(月) 19:02:05
>>743
それならStackなんていらない
リストで代用できるしその方が速い
0746デフォルトの名無しさん2009/06/08(月) 19:03:38
>>736
あー、そうだった。

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

IListってのがあったら、普通Listはその直系の具象実装だと思うわなぁ。
0747デフォルトの名無しさん2009/06/08(月) 19:04:26
明示的にスタックとしているのにインデクサでアクセスされたらたまらんな。
おお怖い。
0748デフォルトの名無しさん2009/06/08(月) 19:06:01
まずいとおもったから作りなおしたんでしょ。1.2だかで
0749デフォルトの名無しさん2009/06/08(月) 19:06:18
>>746
まあね
0750デフォルトの名無しさん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のが優位な点も見当たらないが。
0751デフォルトの名無しさん2009/06/08(月) 19:09:08
C#のコレクションはLINQと相まって、もういっぺん見直した方がいいとは思う
上のFindの話もそうなんだけど、ああいうメソッドがコレクションについているべきではないと思われるし。
0752デフォルトの名無しさん2009/06/08(月) 19:11:37
Find系は以前からあるから、新加入のLINQと役割的に競合してるわけね
0753デフォルトの名無しさん2009/06/08(月) 19:13:10
一発で決まる綺麗な実装は難しいね、LINQの汎用性ときたら半端じゃない。
0754デフォルトの名無しさん2009/06/08(月) 19:13:11
>>750
そのへんは相当シビアな速度求められるところだから
[]演算子で先頭アドレス基準にアドレス計算しなおすだけで
ふざけんなって言われるよ
■ このスレッドは過去ログ倉庫に格納されています