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

1 ：12/05/04 〜 最終レス ：12/05/29

前スレ
C#, C♯, C＃相談室 Part71
http://toro.2ch.net/test/read.cgi/tech/1332575004/
Visual Studio 2010 Express
http://www.microsoft.com/japan/msdn/vstudio/express/default.aspx

2 ：

関連スレ
ふらっとVisual C#,C♯,C＃（初心者用） Part92
http://toro.2ch.net/test/read.cgi/tech/1335703825/
ふらっとC#,C♯,C＃（初心者用） Part92
http://anago.2ch.net/test/read.cgi/software/1335443552/
WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part13
http://toro.2ch.net/test/read.cgi/tech/1334300003/
【VB.NET】LINQ友の会【C#, C♯, C#】
http://hibari.2ch.net/test/read.cgi/tech/1202568694/
C#,C＃の宿題片付けます。
http://hibari.2ch.net/test/read.cgi/tech/1197620454/
ASP.NET + Atlas or Ajax について
http://hibari.2ch.net/test/read.cgi/tech/1150036430/
Microsoft Silverlight その8
http://hibari.2ch.net/test/read.cgi/tech/1300831451/
Visual Studio 2010 Part16
http://hibari.2ch.net/test/read.cgi/tech/1312046969/
C# C＃ C♯でゲームを作ろう Part1
http://hibari.2ch.net/test/read.cgi/tech/1212972014/

3 ：

参考リンク
MSDNライブラリ
http://msdn.microsoft.com/ja-jp/library/
@IT Insider.NET
http://www.atmarkit.co.jp/fdotnet/
Insider.NET 会議室 ディレクトリ
http://www.atmarkit.co.jp/fdotnet/index/bbs/
MSDN フォーラム
http://social.msdn.microsoft.com/Forums/ja-JP/categories/
pinvoke.net: the interop wiki!
http://pinvoke.net/
宇宙仮面の C# プログラミング / C# Programming
http://uchukamen.com/
WisdomSoft C#入門
http://wisdom.sakura.ne.jp/programming/cs/
WisdomSoft Microsoft .NET入門
http://wisdom.sakura.ne.jp/system/msnet/
どっとねっとふぁん
http://dotnetfan.org/
緑のバイク　初めてのＣ＃ 〜 覚え書き 〜
http://homepage3.nifty.com/midori_no_bike/CS/
どぼん！の .NET Tips
http://dobon.net/vb/dotnet/

4 ：

質問する前に"必ず"WikiやFAQ集を参照し、同じような質問がないか確認してください。
初歩的な質問はPC初心者板で･･･
http://pc11.2ch.net/pcqa/
参考リンク(よく出てくる情報リンク)
Windows Vista Wiki
http://windowsvista.ms/index.php
Windows VistaFAQ
http://vistafaq.stdo.net/index.html
〜インストールから設定・活用まで〜 すべてが分かるWindows Vista大百科
http://journal.mycom.co.jp/special/2007/windowsvista/menu.html
コードの量が多い場合は下記サイトを使うなどしたほうがいいかも。
コードを貼り付けてRun codeのチェックを外し、submitボタンを押すと専用のアドレスが発行されます。
http://ideone.com/
直接貼る場合はhtmlエンコードした方がインデントも残って見やすいです。
http://kawama.jp/php/encode_html.php

5 ：

ネトウヨのニュースコピペ荒らしはこまめに通報しましょう。

6 ：

コピペとかどうでもいい。

7 ：

何だ立てたのか

8 ：

うめ

9 ：

客指定のフレームワークがない時って、S2Container.net,S2DAO.netあたり使ってる？

10 ：

ある

11 ：

拡張子の関連付けにおける ProgID の重複防止に関する質問です。
今、プログラムでレジストリをいじって拡張子の関連付けをしようと思っています。
HKEY_CLASSES_ROOT\(ProgID)\shell\open\command にコマンドを記述し、
HKEY_CLASSES_ROOT\(拡張子) に ProgID を登録すれば良いというのは分かりましたが、
ProgID を決め打ちすると他アプリとたまたま重複する可能性が捨てきれないと思いました。
重複しない事を保証するにはどのようにすれば良いのでしょうか？

12 ：

誰もつかわないような的な拡張子にする。

13 ：

ちなみにその話はC#関係あるんだろうか

14 ：

ProgIDの重複より拡張子文字列の重複の方がよっぽど深刻だぜ
というか他のプログラムは気にしてないので>>11だけ気にしても意味がない

15 ：

C# でやろうとしています
拡張子重複は重複時に警告出すので考慮はしてあります。
ProgID はたまに .1 がついてる重複回避なのか別用途なのかよく分からないものも見かけるので、
他のプログラムは気にしてるものかとも思ってましたが・・・そういうわけでもないんでしょうか。
HKEY_CLASSES_ROOT\CLSID 内に ProgID が記述されているようなので、
初回起動時に重複チェックしてユニークなものを CLSID 内に記述しておき、
以降はそこを参照する、という事も考えましたが、
COM を使ってるわけでもないのに CLSID に勝手にキーを追加しても良いものかと思っています。
あるいはエクスプローラからの登録時に使われる (拡張子)_auto_file を使えば
重複も気にしなくていいのかもと思いましたが、
勝手にこのキーを作って問題はないのかと気になりました。

16 ：

いい悪いの話はMSに聞かねえとわかんねえよ

17 ：

C#でやるにしても今話してるところはC#に関係ないよｗ

18 ：

c#でシステム系のコード書くとかなりの確率であとでライブラリに追加されんだよな。

19 ：

どう考えてもWindowsの仕様の話しだし、何でやろうとしてるかは問題ではない
C言語でも同じことはできるんだから

20 ：

.1とかついてるのはバージョン。重複防止とは違う。

21 ：

特に気にしなくていいと思うけどな
http://msdn.microsoft.com/en-us/library/dd542719%28VS.85%29.aspx
というか名付け方を知らないだろ
「たまに .1 がついてる」なんて言ってるあたり

22 ：

.NET 特有の流儀があるかもと思いここで質問しましたが
そんなものは特にないし、そもそもそこまで気にしてるアプリはないということですね
了解しました　ありがとうございます

23 ：

そう言うことは最初に書いてあげるといいと思うの。特に１行目とか。

24 ：

デモ確かに、名前空間がどうとかネーミングルールがどうとか言う割に、
拡張子（というか、関連づけ？）に関してはかなりいい加減だよな。
今から収拾つくもんでも無いだろうけど。

25 ：

コレクションのforeachをスレッドセーフで処理したいのですが、
lockする以外によい方法はないでしょうか？

26 ：

System.Collections.Concurrent名前空間下のコレクションを使う

27 ：

自分で作るファイルの拡張子ってまだ3文字以内にこだわっているの？

28 ：

>>25
スレッドセーフの意味は何がしたいかによって違う
foreach全体をlockする代わりというなら、いったんコレクションをコピーしてから(もちろんロックして)列挙するくらいしかないぞ

29 ：

拡張子ってさ、program.c#とかでも良かったんじゃない？なんでcsにしたんだろうな〜

30 ：

記号は極力使わない方がいいだろ

31 ：

fileスキームでもフラグメントって使えるんだったか

32 ：

program.csharp

33 ：

program.シーシャープ

34 ：

C++で
string glb; //グローバル変数
string __declspec(dllexport) foo(){
　string tmp=glb;
　return tmp;
}
call "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /x64
cl /LD /Tp "hoge.cpp" /link /DLL /DEF:"hoge.def"
という風にしてdllを作っています.
C#で
[DllImport("hoge.dll", CharSet=CharSet.Auto, ExactSpelling=true)]
public static extern string foo();
としてfoo()関数を使用してみたのですが,
「System.AccessViolationException: 保護されているメモリに読み取りまたは書き込み操作
を行おうとしました。他のメモリが壊れていることが考えられます。」
などと出てきてアクセスできません。
なんとかならないでしょうか?
環境はWindows 7 64bitです

35 ：

string返すのはダメだろう
文字列を受け取るならC#側でメモリを確保して引数にポインタを渡し、
C++側でそこに文字列を入れるのが普通だと思う

36 ：

っていうかC/C++のコードとしても間違ってると思う。
どんなお漏らしし放題のコードだよw

37 ：

C++から呼ぶんだったらstd::stringの値返しは問題ないだろ?
C#から呼んだらリークすると思うけど

38 ：

stringにマーシャリングできるのはchar*かw_char*

39 ：

/*C++*/ int __declspec(dllexport) foo(char* buf, int n) { strncpy(buf, glb.c_str(), n); return min(glb.size(), n); }
/*C#*/ [DllImport("hoge.dll", CharSet=CharSet.Auto, ExactSpelling=true)] public static extern int foo(StringBuilder buf, int n);
こうか?　合ってるかは知らん

40 ：

>>39
あなたが神か〜〜〜!
できますた

41 ：

CharSet=CharSet.Ansiにするか
wcharにしてUnicodeにしないとまずくない？しらんけど

42 ：

Autoだし問題ないんじゃね？

43 ：

Autoが有意なのはDLLがHogeWとHogeAの両方を公開してる場合だけ
大抵はWもAもないからAutoは却ってまずい

44 ：

Autoだとたいていの環境(Windows9x以外)だとUnicodeになっちゃうんじゃね？
今の時代、Autoって意味なくね？

45 ：

ないね

46 ：

質問です！
ファイル監視をするのにFileSystemWatcherを使用すべきか
Threading.Timerで監視をするのか迷っております。
仕様としては
１．指定の１ファイルの更新日時が変更されたときにイベントを発生させたい。
２．ファイルが更新されることは非常に稀（ほぼ初回起動してからは滅多に変わらない）
というものです、どちらも簡単に実現可能なのですがどちらがより負荷のかからない
処理なのか知りたいです。
具体的にはFileSystemWatcherが指定ファイルが変更されたときにOSからの通知で
つどイベント発生しているか・・・なのです＞＜

47 ：

FileSystemWatcherで十分。むしろスレッドタイマーとか無駄に使って
アクセスしてたら無駄な負担が掛かる。FileSystemWatcherのイベントで更新日時が変更されたかどうかは、
判定可能。

48 ：

スレッドタイマーで十分。むしろFileSystemWatcherとか無駄に使って
アクセスしてたら無駄な負担が掛かる。スレッドタイマーで更新日時が変更されたかどうかは、
判定可能。

49 ：

>>46
Windowsであるなら、FileSystemWatcherの実態はWiin32API。
http://d.hatena.ne.jp/s-kita/20100131/1264900167
NotifyFilter プロパティさえ設定していれば、
最低限必要なタイミングのみで処理できるので、
単純なプログラム内の負荷は最小化できると思う。
スレッドタイマーでグルグル回しても、更新されるタイミングが極端に少ないというのなら、
毎度チェックする処理の分、無駄な負荷が発生する。
ただ、FileSystemWatcherの使い方にはそれなりの考慮がいるので注意。

50 ：

>>49
ふむふむ、内部的にはWin32ApiのRegNotifyChangeKeyValueみたいな
処理が走っているのかなぁ？
実際にFileSystemWatcherを使用した実装も行ったのですが、少々くせが
ありましたね（汗)（ファイル変更イベントが２回来るとか）

51 ：

>>50
まあ、何のケースだったかは忘れたが、更新頻度の高い監視をしたら、
バッファーオーバーフローおこすケースもあったんで、過去には採用を見送ったこともあるくらいだ。
そういう「くせ」に気を付ける必要はあるが、「頻度が低い」という当該条件下なら、
スレッドタイマーによる判定の有用性はあまり思いつかないな。
多少のコーディング・設計的な手間を犠牲にしても、FileSystemWatcherで良いと思う。多分。

52 ：

FileSystemWatcherは更新を検知して監視しているファイルシステムを更新するとヤバイよね
予想外のタイミングでイベントが発生して大変だった

53 ：

真面目にやるなら、
FileSystemWatcherで監視
↓
バッファがあふれたらTimerに切り替え
↓
更新が無いまま一定時間が経過したらFileSystemWatcherに戻す
が妥当だな。

54 ：

・FileSystemWatcherのイベントハンドラ(のスレッド)内で処理を実行
なんてことしなければバッファが溢れることなどまず無い
仮にそれでも溢れるとしてもイベントをトリガーとして使うだけ
・どれかが変更されたことを検知したら監視対象の全てを自前の処理で確認

55 ：

>>54
MSDN読んで来い

56 ：

やなこった

57 ：

しょうがねーな、俺が読んでくる

58 ：

いやいや俺が

59 ：

よくわかんないんだけど、そのバッファーって勝手に解放されるの？
それとも各自が解放するの？？

60 ：

>>59
MSDN読んで来い

61 ：

FileSystemWatcherなんて使ったことなかったが、結局FileSystemWatcherを使っても
ファイルシステムへの変更を逐一漏らさず検出することは出来ない場合がある、ってことか。
まあよく考えれば当たり前かな。
>>46の用途がそうかどうかわからないけど、通常は
　- 必ずしも変更を逐一検出する必要はない。（短時間に複数回変更が行われても、
　　一回だけ通知してくれればOK）
　- でもイベントによる変更の通知より後にさらに変更が行われて、それが
　　通知されないケースが発生しうるのは困る。
こういう場合が多いと思うから、だとするとタイマーで自前でポーリングした方が安全な気がする。

62 ：

やなこった

63 ：

> ファイルシステムへの変更を逐一漏らさず検出することは出来ない場合がある、ってことか。
監視イベントが大量に発生するとバッファが溢れて通知漏れする場合がある
フィルタで監視イベントを減らすか、バッファの容量を増やして対応するって
　M　S　D　N　に　か　い　て　あ　る　じ　ゃ　な　い　で　す　か
なんで読まないの？
説明書読まないで始めていいのはゲームだけだから

64 ：

MSDNは説明書ではないんですけど

65 ：

俺は説明書読んでからゲーム始めるよ。むしろゲームやってるより楽しかったりする

66 ：

説明書読まないとできないゲームは糞ゲー（　･`ω･´）ｷﾘｯ

67 ：

C#もゲームみたいなもの

68 ：

つまり説明書嫁

69 ：

>>63
それで万事解決とも書いてない。
MSDN読んでないタワケはどっちだよ

70 ：

>>69
万事解決なんて言ってないだろ禿

71 ：

>>70
じゃあ>>61に書いたことのどこが間違ってるのか言ってみろ。
っていうか言わなくていいから馬鹿は黙ってろ。

72 ：

まるで子供の喧嘩ね

73 ：

>>71
どっちだよ禿、てめーが黙ってろ禿

74 ：

>>72
C#は、おこちゃま用のインタプリタ型の言語なんだから適当なのでは？

75 ：

インタプリタ？

76 ：

JITって何なんでしょうね

77 ：

インタプリタ方式との比較 [編集]
インタプリタ方式との違いは、インタプリタ方式がその都度コードを解釈しながら実行するのに対して、JIT方式は機械語に変換したものを実行することである。また、インタプリタ方式と同様に実行時にJava仮想マシンや共通言語ランタイムのようなランタイム環境を必要とする。
インタプリタ方式と比較すると性能面では以下のような差が出てくる
機械語に変換されるため、コンパイル後の実行速度はインタプリタ方式の数倍の性能となる
モジュールやクラス、関数のロード時にコンパイルが行われるため、プログラムの起動には時間がかかる
一度コンパイルしたコードを保持するために、より多くのメモリ容量を必要とする

78 ：

NGワード:インタプリタ

79 ：

FileSystemWatcherは、内部でReadDirectoryChangesW(WIN32API)をunsafeコードで呼び出す。
InternalBufferSizeは、バッファサイズ。初期値は、8192Bytes。

80 ：

>>61
ファイルごとにイベントハンドラが呼び出されるとは限らないけど、
ファイル変更後には1回以上イベントハンドラが呼び出される
つまり、FileSystemWatcherのイベントハンドラで
(タイマーでやろうとしている)変更確認を行えば良いだけ

81 ：

>>80
オーバーフローしない限りはね。
って、だから行空け馬鹿の>>63ですら言ってることだけど、MSDNをちゃんと読もうよ。

82 ：

最初からMSDNを読んでいれば、こんなことにはならなかった・・・・・

83 ：

class ウィンドウ
{
public int 幅 {get;set;}
}
って何がしたいんでしょうか？
public int 幅;
でよいのでは？

84 ：

なぜフィールドを公開してはいけないのかを調べなさい

85 ：

あなた自身はしらないのねｗ
yahooで検索します

86 ：

・virtualにしとくと派生クラスでoverrideできる
・プロパティとフィールドを区別するフレームワークも多い
・使わなくても警告が出ない

87 ：

>>83
試しにフィールドとプロパティをそれぞれ1つずつ持ったクラスをList<T>で簡易データソースにしてDataGridViewに喰わせてみるといい
つまりそういうことだ

88 ：

>>83
http://code.msdn.microsoft.com/windowsdesktop/13-4ee47d39
これが全てではないが、オブジェクト指向的には単なるメンバではなく、
プロパティとしておいた方が捗る可能性が高い、とする。

89 ：

>>86
とか
>>87
みたいな、オブジェクト指向を分かってなさそうな回答を見るとなんだかなあ、って思う。

90 ：

オブジェクト指向w
ちょっと前に誰か書いてたけど、いきなり大上段の話を始める奴は確かに馬鹿っぽい。
っていうか、なんでかなあと思うならまずお前が答えろって

91 ：

オブジェクト指向というより、ちょっとしたことでもとりあえず関数通しとけば
後で変更しやすくて便利っていうC言語の時代からある考え方だろ

92 ：

フィールドは、クラス内部で状態や値を持つものとして扱う。
プロパティは、クラス外部に何らかの形で状態や値を公開するものとして扱う。
プロパティは、一種のメソッド（関数）であり、入出力(set/get)時になんらかの特定の処理が可能。
例えば、Widthという横幅を表す状態があるとして、設定される値の範囲を抑制するなど。

93 ：

>>90
「DataGridViewで表示するとき便利だよ！」
→「じゃあ、このオブジェクトはDataGridViewで表示しないし、全部publicフィールドでいいや！」
みたいな。色んな前提が抜けてる。大上段、ってのがそういう意味じゃないかもしれないけど。

94 ：

DataGridViewとかは、オブジェクト指向云々ってよりは、.NETの仕様というか機能みたいなものかと。
データバインドは、リフレクション掛けて公開されたプロパティが対象という・・・

95 ：

>>94
だから、オブジェクト指向なんていう基礎中の基礎をすっ飛ばして、
ポトペタで満足している連中なんだろうな、と推察しているわけだ。

96 ：

何のこっちゃw

97 ：

無闇にフィールドがpublicで公開されてると、気持ち悪く感じるようになる。
constとかreadonlyとかで読み取り専用のフィールド(規定値等)であれば、良いけど。

98 ：

オブジェクト指向ってのは無意味なカプセル化をするって意味ではない
それにフィールドからプロパティへ変更しても再コンパイルしてもらえない状況なんて現実的に考えにくい

99 ：

public constは怖いだろ

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

Prologの宿題片付けます (243)
くだすれPython(超初心者用) その13 (590)
Google Maps API 質問箱 (314)
Borlandにはやられた... (357)
【C++】 DirectX初心者質問ｽﾚ Part36 【C】 (980)
C#,C＃の宿題片付けます。 (765)
--log9.info------------------
カンヅメモンスター　ジェムジェムモンスター (352)
【ナムコ】ポケットキング POCKETKING【namco】 (106)
【GB】X（エックス）総合スレ【3Dシューティング】 (183)
モンスタータクティクスは神ゲー (148)
【WSC】ワイルドカード　第8章【SC】 (232)
たまごっちのパチモンを語るスレ (207)
初代　白黒ゲームボーイの思い出を語ろう (906)
携帯電獣テレファングを語るスレ (130)
＝ Atari Lynx (アタリ・リンクス) 総合スレ ＝ (322)
コントラ＆魂斗羅スピリッツ(GB) (177)
GBのスーパーロボット大戦総合 (260)
【GB】パズルゲー総合スレ【GBC】 (380)
正直アドバンス出た時びっくらこいた香具師来い (446)
GB名作アクションゲームを挙げてけ (873)
デジタルモンスターの思い出 (419)
ゼロ・ツアーズ (145)
--log55.com------------------
【PS4】地球防衛軍4.1 Part98【EDF4.1】
絶体絶命都市シリーズ総合スレ Part30
ぷよテト 53 【ユーム荒らすな��】
【PS4/XB1】Fortnite　Part1【Save The World】
【XB1】 Battlefield 1 Part9 【BF1】
【PS4】FPSで足音を聴こうmixamp等の周辺機器を語るpart10【サラウンド】
【PS3/PS4】初音ミク -Project DIVA-24【F/X/FT】
【Switch】マリオ＋ラビッツ キングダムバトル