10/06/13 23:21:55
.NETのboolは8ビットで0がfalseで0以外がtrueじゃなかったっけ
記事の間違いは別問題だが
475:デフォルトの名無しさん
10/06/13 23:22:23
記事ごと消すほどのコメントじゃないわな。
476:デフォルトの名無しさん
10/06/13 23:31:53
たまたま残ってたから一応書いておこう。
最初のコメント
----
> まとめると、
> BitVector32 BitArray
> true -1 を表す 1 を表す
> false 0 を表す 0 を表す
> となります。
これはいったいどういう意味でしょうか？
----
その返答
----
ビットフラグがONの場合がTrue、ビットフラグがOFFの場合はFalseです。
このON/OFFを数値で表した場合、BitArrayとBitVector32とではON/OFFの数値の意味が異なるという対比表になります。
そもそもビットの概念がわかっていないと、このBlogの説明に書いてある説明を理解しようとしても無理ですので、もし貴方がビットの考え方が良くわからないという場合は、
入門書籍やほかのWebサイトでその辺りを勉強してから、このBlogに書いてある意味を汲み取ってください。
----
477:デフォルトの名無しさん
10/06/13 23:36:23
いきなり攻撃的な返答だな。あの日だったりしたのか？ｗ
478:デフォルトの名無しさん
10/06/13 23:37:23
記事は消えても画像は残ってるんだな
URLﾘﾝｸ(techbank.jp)
479:デフォルトの名無しさん
10/06/14 01:01:27
マルチスレッドで教えてください。
ソケットプログラミングで、受信スレッドがキューにデータを溜めて、
メインスレッドは順次データを読み出して処理するというプログラムを書いています。
メインスレッドはキューにデータが無ければ受信するまで待機したいのですが、
一般的にどう実装するものでしょうか？
とりあえず作った受信スレッドは、
Monitor.Enter(obj);
受信ループ
キューに格納
Monitor.Exit(obj);
Monitor.Enter(obj);
ループEnd
Monitor.Exit(obj);
受信の都度Exitしてメインスレッドに所有権を明け渡しています。
動作には問題なさそう？なんですけど、なんかスマートじゃないというか。。。
480:デフォルトの名無しさん
10/06/14 01:05:17
AutoResetEventつかう
481:デフォルトの名無しさん
10/06/14 01:12:17
lock (q)
ループ開始
}
482:デフォルトの名無しさん
10/06/14 01:13:28
ミスって書きこんじまった、なしなしな
483:デフォルトの名無しさん
10/06/14 01:16:31
BlockingQueue系統を使うのが定石だが、
.NET 4より前にはなかったな確か。
BlockingQueueとか実装はそこらに転がってそうだが。
484:デフォルトの名無しさん
10/06/14 01:19:51
>>479
.Net4が使えるなら BlockingCollection<T> 一択。
つかえないなら、↓こういう同期機能付きコレクションを使う。
URLﾘﾝｸ(www.codeproject.com)
いずれにしても、そういうパターン（いわゆるProducer-Consumerパターン）では
同期機能はキューに持たせるのが一般的。で、Producer（この場合は受信スレッド）は
データをキューに入れるだけ、Consumer（この場合はメインスレッド）はキューから
取得するだけにする。
485:デフォルトの名無しさん
10/06/14 07:08:32
MVPって最初の頃(2003年とかその頃）はいいなと思ってたんだが、わんくま同盟とか言い出した頃から
馴れ合い色が強くなってきて、なんていうか、このブログの主はMVPになる条件を満たしていないにも
かかわらず、推薦制度を悪用してMVPになった感があるな。
こんなんがアドバイザとして高い金を取ってるかと思うとなんともいえない気持ちになる。
MVPを専属で引っ張ると100万/週ぐらい取らなかったか？
次回剥奪されると良いが。
486:デフォルトの名無しさん
10/06/14 07:29:51
>>485
> MVPを専属で引っ張ると100万/週ぐらい取らなかったか？
そんなに価値あるのか？
まあ、すごいのはいる。
487:デフォルトの名無しさん
10/06/14 07:47:51
nyaruruとかって本業何してんの？
488:デフォルトの名無しさん
10/06/14 07:52:15
そんなに取れません。ｎ氏はGoogleに・・・。
489:デフォルトの名無しさん
10/06/14 08:00:19
GoogleだとWindows使えなくなるじゃん
大丈夫かな
490:デフォルトの名無しさん
10/06/14 08:30:10
CodeProjectでじゃんじゃん記事書きまくってる奴とか、凄いのがいる。
日本語サイトでMVPを名乗ってる奴の中には、こういうしょうもないのが時々いるから
あんまり信用はしてないけど。
この人も結構メディアに露出しているけど、信用をなくすような行動取って大丈夫なのか？
「わかってませんでした。精進します」って言えば済んだことなのに。
491:デフォルトの名無しさん
10/06/14 09:32:56
>MVPを名乗ってる奴の中には
MVPは別に実力に関係ないしな
まぁ色々特典もらえるのは正直うらやましい
492:デフォルトの名無しさん
10/06/14 13:33:26
どこがじゃ
493:デフォルトの名無しさん
10/06/14 13:49:43
>>492
MVP乙
494:デフォルトの名無しさん
10/06/14 20:33:37
まあMVPに実力は関係ないな。
でも、一つのテーマでコミュニティ築く力は凄いと思わない。
495:デフォルトの名無しさん
10/06/14 21:05:26
うん。思わない。
496:デフォルトの名無しさん
10/06/14 21:47:57
思わないんかいw
MVPって数結構多いよね。
497:デフォルトの名無しさん
10/06/14 21:50:59
一時期、ものすごい増えて、今は多少減ったみたい。
498:デフォルトの名無しさん
10/06/14 22:26:37
高い金取るのってエバンジェリストとかそういうのじゃないっけ？
コンサル
499:デフォルトの名無しさん
10/06/14 22:36:01
>>480-484
レスサンクスです。
Producer-Consumerパターンでぐぐったらズバリ出てきました。
こんな一般的な話だったなんて・・・orz
500:デフォルトの名無しさん
10/06/14 22:43:43
シングルスレッドではproducerとconsumerの同期がとれないってのが、
プログラムをマルチスレッド化する大きな動機の一つだもんな。
501:デフォルトの名無しさん
10/06/14 23:32:24
うん。
502:デフォルトの名無しさん
10/06/15 06:54:05
マルチスレッドといえば.Net4使ってるのに生のthreadやらthreadpoolやらを使ってる奴は何がしたいのかわからん
どれだけ俺様ライブラリを量産したいのかと小一時間（ｒｙ
503:デフォルトの名無しさん
10/06/15 12:20:19
Producer-Consumerパターンなら生だろうとBackgroundWorkerだろうと大して変わらんだろ
504:デフォルトの名無しさん
10/06/15 21:08:21
そういうことじゃないだろ。
505:デフォルトの名無しさん
10/06/15 21:18:56
ほう
506:デフォルトの名無しさん
10/06/15 21:49:26
>>502はプロデューサーコンシューマーに限った話はしてないよね。
507:デフォルトの名無しさん
10/06/15 22:04:20
そんなMSの俺様クラス作られても、いつサポートされなくなるか分からないしな。
508:デフォルトの名無しさん
10/06/15 22:36:19
しかしまぁ大手のマルチスレッド関連の記事は古いものばかりだな
忙しくなけりゃ俺が寄稿してあげたいぐらいだわ
509:デフォルトの名無しさん
10/06/15 22:37:49
>>508
ブログにでも書け
キーワードさえうまく配置してればそのうち広まるよ
510:デフォルトの名無しさん
10/06/15 22:38:57
俺様ライブラリ（車輪の再発明）批判はいいとして、
それがどうして「生のthreadやらthreadpoolやらを使」うことがそれだって言うの？
そっちの方が意味がわからんよ。
511:デフォルトの名無しさん
10/06/15 22:46:06
>>458
んーこのblogなんとなく見てたら気になるとこいっぱいあるな…
でももうコメントもできんし。
っていうかだれかすでにコメントしてて消えちまったのかもしれんが。
512:デフォルトの名無しさん
10/06/15 23:52:40
>>504
.NET4触ってないからよくわからないんだが、Threading.threadは使わずにBackgroundWorker使えって事？
それとも.NET4はもっと便利なのがあるってこと？
513:デフォルトの名無しさん
10/06/16 00:06:43
あるよ
514:デフォルトの名無しさん
10/06/16 00:34:11
>>512
Task クラスとか、Parallel クラスとかが増えた。
515:デフォルトの名無しさん
10/06/16 06:25:10
目的が異なるものを比較する意味がわからん
516:デフォルトの名無しさん
10/06/16 06:41:52
え？ｗ
517:デフォルトの名無しさん
10/06/16 09:26:18
は？
518:デフォルトの名無しさん
10/06/16 10:08:53
あ？ｗ
519:デフォルトの名無しさん
10/06/16 10:10:59
お？
520:デフォルトの名無しさん
10/06/16 11:26:09
並列用のパラレルAPIやParallel Linqで、GUIの非ブロック化処理を書いちゃうわけか。
それはそれでやばげだな。
521:デフォルトの名無しさん
10/06/16 12:30:20
誰かいないのか？
それはそれでやばげだなって言ってんだろ！
522:デフォルトの名無しさん
10/06/16 14:07:14
ふざけんな！
俺がやばげだなつってるんだから反応しやがれ！
523:デフォルトの名無しさん
10/06/16 16:01:52
だあれもいない(´・ω・｀)ｼｮﾎﾞｰﾝ
524:デフォルトの名無しさん
10/06/16 17:36:48
それはそれでやばげだが、それもありなんじゃないかなって、今はそう思えます。
525:デフォルトの名無しさん
10/06/16 20:29:38
.net4はキャンセルフレームワークが追加されたのがいいな
これでマルチスレッドを使う人がちゃんとキャンセル実装をするようになればいいが…
526:デフォルトの名無しさん
10/06/16 20:34:27
耳毛、鼻毛を笑う。
527:デフォルトの名無しさん
10/06/16 21:27:25
しかし、そんなスレッドを酷使するような計算量のアプリって書いたことないなぁ。
あると欣喜雀躍する人がいるのは分かるがパンピーなプログラマでそんなもの要るの？
ちゃんとプロファイリングしてれば、キャンセルなんて考える必要なんて無いのが経験則。
それとも皆、もしかして物理シミュレーションとか暗号鍵解読とかでもやってるのか？
528:デフォルトの名無しさん
10/06/16 21:32:56
スレッドを酷使するかどうかとキャンセルを考えるかどうかがなんで同列に並んでんの？
俺の経験からいけばそれらは関係がないんだけど。
529:デフォルトの名無しさん
10/06/16 21:37:11
いや、長時間じゃなくてもGUIアプリで計算しようとしたら別スレッドにするだろ。
しない？なら言う事は何も無いな。
530:デフォルトの名無しさん
10/06/16 21:38:45
C#でGUIアプリをつくったらそれを別スレッドで行わないことが困難だろう。
531:デフォルトの名無しさん
10/06/16 21:40:50
パラレルを活用するのはそれなりに限られてるけど、
タスク系統は普通に使うでしょ。
532:デフォルトの名無しさん
10/06/16 21:45:24
>>527はどうしようもないバカ
スレッドのキャンセル書けないバカは一生マルチスレッドするな。
533:デフォルトの名無しさん
10/06/16 22:25:39
こうやってみるといかにマルチスレッドを使いこなしてないかわかるな
まぁちゃんとわかって仕事で使ってる人間なんてほんの一握りなわけだが
534:デフォルトの名無しさん
10/06/16 22:32:55
むしろよくわからないなら使わない方が良いとは思う。
大抵のビジネスアプリは使わんでも何の問題もない。
535:デフォルトの名無しさん
10/06/16 22:44:38
俺はビジネスアプリ作ってるけどかなり多用してるな
とはいえあまり見ないのもたしか
UIがフリーズしたり複数のタスクが同時に出来ないアプリが多い事多い事…
536:デフォルトの名無しさん
10/06/16 22:51:31
仕事だと危険すぎてやらせる気にならんのだよね。
自分だけで作る部分ならいいんだが。
537:デフォルトの名無しさん
10/06/16 22:51:45
ぶっちゃけスレッドって難しいじゃん
サンプル程度のものなら簡単に理解できるし実装も簡単だけど
いざちゃんとやろうと思ったら同期、同調、排他、例外処理、キャンセル、etc...と糞難しい
設計力も数段上の力が求められるしさー
業務系とかそれが出来ないからモーダルウィンドウに逃げてる人多いじゃんよ
538:デフォルトの名無しさん
10/06/16 23:00:14
中級者御用達のクック本。
その中でも最も難易度の高い非同期項目みて”超初心者向けだな”とか思える人が集まらないと実務じゃ無理。
539:デフォルトの名無しさん
10/06/16 23:03:48
マルチスレッドは怖いです
540:デフォルトの名無しさん
10/06/16 23:04:36
はいはい
541:デフォルトの名無しさん
10/06/16 23:06:39
実際のところ、UI止めたくないから裏でスレッド、くらいにしか使ってない。
542:デフォルトの名無しさん
10/06/16 23:11:53
GUIの裏で計算だとか通信だとかするならbackgroundworkerでよくね？
MSもこういう用途のために作ったんじゃないのかね
普通の受託開発屋なら通信部分って自前で書かない場合多いし
543:デフォルトの名無しさん
10/06/16 23:12:20
低能だからね。
544:デフォルトの名無しさん
10/06/16 23:30:05
>>542
だってそれ使うと同調しにくいじゃん…
スレッドも一本しか使わないし…
それ以上にUIにベッタリな仕様だからビジネスロジック部分には不向き
複数のスレッドで別々の処理をやってある時点で非同期に集計してその後にまた別の処理を…
なーんてことやると一気に難易度がググーーーンと上がっちゃいます！＞＜
545:デフォルトの名無しさん
10/06/17 00:05:35
出来るならやりゃいいと思うけど
適当に人あつめると出来ない人の方が多いからなあ。
低い方に合わせて作らんと死ぬよね
546:デフォルトの名無しさん
10/06/17 00:17:18
UI止めないのは操作感の改良だから、多重の並列処理はできないようにしてるが、
特に客から文句言われた事ないな。
計算が遅けりゃ十中八九はデータの持ち方とかに問題があって遅いから、遅いと
文句言われたら改良する。
文句言われなけい限り、保守とかが楽な方に意図的に流してる。
でもスレッドとか(あと信じられないことにコレクション)をヘルプのサンプル引き写し
レベルで使ってるだけで、マニアックだとか難しくて他の人が保守出来ないから
チーム作業ではやめてくれないかとか罵倒されて
(´・ω・｀)。。。(いくらなんでもあんたらが時代遅れだろ)
とか思うが相手が大多数なので言えない。
これは俺の勤め先がブラックなんだよな、な？一般的じゃないよな？（マ板行け自分）
547:デフォルトの名無しさん
10/06/17 00:19:42
>>544
勝手に上がればーーーーか(´・ω・｀)
548:デフォルトの名無しさん
10/06/17 00:23:53
>>544
そういう時はほかの方法でやるだろうよ。
549:デフォルトの名無しさん
10/06/17 00:40:39
外資の俺が言うのも何だが未だに国内で組んでるエンジニアはレベルが低いな…
スレッドぐらい使いこなせよ…
550:デフォルトの名無しさん
10/06/17 00:43:35
>>549
>スレッドぐらい使いこなせよ
レベルの低い会社に勤めてるのですねｗ
551:デフォルトの名無しさん
10/06/17 01:00:29
まあ自称分かってるやつが一番地雷なんだけどな。
552:デフォルトの名無しさん
10/06/17 01:08:08
使いこなせてる俺はいつの間にやら上級PGだったようだ
おまえ等、俺に挨拶は？
553:デフォルトの名無しさん
10/06/17 01:08:35
URLﾘﾝｸ(blogs.msdn.com)
なんでvolatileなのに問題が発生するのか説明してみて。
554:デフォルトの名無しさん
10/06/17 01:15:18
>>553
説明もなにも二つのスレッドが協調すべきなのにその操作をいれてないからだろ
そのブログじゃ同時に実行される云々いってるがスケジューラの指定が無い以上どっちが優先されるのかはプロセッサ任せ
つーかロックすらかけてない互いの状態弄って何がしたいのかわけわからん
volatileは全く関係ねぇよ
ふー、やっぱ俺って天才だわ
上級PGなめんなよ！
555:デフォルトの名無しさん
10/06/17 01:29:58
>>554
何を言ってるんだお前は…
556:デフォルトの名無しさん
10/06/17 01:35:27
volatileには順序保障の役割がある。
・volatile読み込みより前の書き込みは必ず先に実行される
・volatile書き込みより後の読み込みは必ず後に実行される
にも関わらず>>553ではすべての読み書きがvolatileなのに順序問題が起こる。
これはなぜか説明してみろという話。
557:デフォルトの名無しさん
10/06/17 01:42:14
いや、
・volatile書き込みより前の書き込みは必ず先に実行される
・volatile読み込みより後の読み込みは必ず後に実行される
かな
558:デフォルトの名無しさん
10/06/17 01:58:43
だからレジスタ依存＝プロセッサに依存するつってんだろー
それを阻止する為に～やりましょうとかずれてるわけで
ちゃんとやるならロックや適切なスケジューラを指定するのが常なんだよ！
上級PGなめんなよ！
559:デフォルトの名無しさん
10/06/17 02:06:04
上級な土方
560:デフォルトの名無しさん
10/06/17 02:09:16
まったく何でかが知りたいならO-o-Oでググれや
上級PGなめんな！
561:デフォルトの名無しさん
10/06/17 02:16:05
え、volatileに同期処理なんてあるの？初耳だわ。
562:デフォルトの名無しさん
10/06/17 02:22:54
同期じゃねぇよ
ただのコンパイラ最適化防止の為じゃ
そして>>553の記事は最適化は防げてもプロセッサの最適化(OoOのね)は防げないから任意でThread.MemoryBarrier()挟んでメモリバリアしろよタコ助共つーこと
上級PGなめんなよ！
つーかスレッド使う予備知識の基礎中の基礎だろ！
563:デフォルトの名無しさん
10/06/17 03:30:13
>>546
俺もいい言葉を言われたことがあるので伝えておくよ。
「ジェネリクスは信用してないから禁止」
564:デフォルトの名無しさん
10/06/17 03:57:44
>>561
C++のvolatileと混同してない？C#のにはあるよ。
ただOoOに対しては有効じゃないのかなぁ。
565:デフォルトの名無しさん
10/06/17 04:49:42
初鼻だわ。
566:デフォルトの名無しさん
10/06/17 05:59:33
あのな、スレッド関係で、順序保障の機能ってのはOoOの順序問題とかの解決に使う。
当然、C#のvolatileは順序を保証するために使える。
ではなんで>>553では全部volatileなのに順序問題が発生するのか。
567:デフォルトの名無しさん
10/06/17 06:14:20
参考
URLﾘﾝｸ(msdn.microsoft.com)
568:デフォルトの名無しさん
10/06/17 06:32:28
つまり>>551
569:デフォルトの名無しさん
10/06/17 06:42:49
参考
URLﾘﾝｸ(www.microsoft.com)
この辺が詳しいな。
570:デフォルトの名無しさん
10/06/17 06:56:55
>>563
デリゲート禁止ってのもあった・・・
571:デフォルトの名無しさん
10/06/17 08:55:56
いつからvolatileがOoOの順序保障が行われるようになったのやら
ほんとレベル低いな
572:デフォルトの名無しさん
10/06/17 10:30:22
>>563
医者が扱う薬の話かよ
573:デフォルトの名無しさん
10/06/17 10:51:05
/ufcpp.net/study/csharp/sp_thread.html
volatileって何だろうと思って凄腕の人の解釈見たらコンパイラの最適化防止ってかいてあるお
ゆとりPGをなめんなおっおっ（ ＾ω＾）
574:デフォルトの名無しさん
10/06/17 13:38:23
>>573
最適化でその変数がなかったことにされるのを防ぐだけ
575:デフォルトの名無しさん
10/06/17 13:41:28
何のために？
576:デフォルトの名無しさん
10/06/17 13:43:09
グローバル変数的に使うために用意した変数が、同ファイル中で手をくわえられてないから最適化で削除されちゃう
とかを防ぐためじゃなかったっけ。
577:デフォルトの名無しさん
10/06/17 13:43:56
コンパイラが不要だと思っても、実は他のスレッドが
必要としているかもしれないから。
578:デフォルトの名無しさん
10/06/17 13:44:31
volatileは順序保障するとか言ってた奴出てこいｗ
579:デフォルトの名無しさん
10/06/17 13:46:14
あぁ、スレッドであれこれするときに読むんだけど、おまえそのスレッドでその変数変更してねえのになんで読むんだよ
それいらねえだろってコンパイラが言ったら、それは別のスレッドが書き変えてるかもしれないの！って注意してやるんだったか
580:デフォルトの名無しさん
10/06/17 13:52:45
C言語のvolatileが想定してたのはSignalなどのCPU割り込み処理で、
スレッドのことは考えてなかった。
よくvolatileをスレッドで使うなというのはこのため。
C#やJavaのようなはじめからスレッドを想定してる言語では意味を拡張していて、
スレッドに対して使えるようになっている。
>>553の他の記事を見たが他のはエラーが起きたときのダイアログやメッセージを
イメージでアップしているが、この記事にはない。
おそらく手元の環境でエラーが起きなくて脳内で書いてるんじゃないのかな。
誰かこのプログラムでAssertが起きた人いる？
581:デフォルトの名無しさん
10/06/17 15:29:45
並列化で思い出したが、SIMD対応ってもうやる気無いのかね？
昔はJITの利点の一つとして喧伝してたもんだったが
582:デフォルトの名無しさん
10/06/17 16:05:48
環境に応じてスカラでXMMレジスタを使ってるらしい。
ベクトル化はMono.Simdのようなやり方しかないのだろうか。
583:デフォルトの名無しさん
10/06/17 17:01:13
Matrixとか折角あるのに対応してないのかね
つーかアレDirectX由来だっけ？
584:デフォルトの名無しさん
10/06/17 17:06:53
もともとMatrixはJpegやMpegの展開のために用意されたんじゃなかったっけ？
これからはマルチメディアの時代だとか言って。
今はビデオの展開はGPUの仕事になっちゃってるからCPUのMatrixはあんまり使ってないような。
585:デフォルトの名無しさん
10/06/17 17:27:28
Matrixの主な用途はTransformだと思ってた俺
586:デフォルトの名無しさん
10/06/17 17:53:49
>>585
君が正しい
587:デフォルトの名無しさん
10/06/17 19:44:11
var hoge = new hogehoge()
「新人がわかんないだろ、意地悪すんなよ」って言われた
588:デフォルトの名無しさん
10/06/17 19:56:13
新人いじめかよ
最低だな
589:デフォルトの名無しさん
10/06/17 20:02:15
volatileはメモリの読み書きを最適化して消さないだけ
それ以外は特に何も保証しない
590:デフォルトの名無しさん
10/06/17 20:07:59
>>578
ここはでたらめ言うだらけだな。
URLﾘﾝｸ(msdn.microsoft.com)
URLﾘﾝｸ(msdn.microsoft.com)
URLﾘﾝｸ(www.microsoft.com)
>>574
URLﾘﾝｸ(www.microsoft.com)
この辺読みゃ分かるが、よく誤解されてるように読み込みそのものが削除されるようなことは普通はない。
591:デフォルトの名無しさん
10/06/17 20:08:57
ぜんぜん前の書き込みを読まない奴だな。それはCの話だ。
592:デフォルトの名無しさん
10/06/17 20:11:32
>>589
そろそろ痛いから言語仕様でも読んでみな。
>>590の最初のリンクだけでも十分だ。
>>580
>>553のソースでしっかりAsser起こる。
一瞬なんで？って思ったが、まあよく考えてみれば確かに起こってもおかしくはないのかな…って感じ。
593:デフォルトの名無しさん
10/06/17 20:16:33
なんかごっちゃになっている奴がいるようだけど、volatile保証するが読み書きの順序と、
複数のスレッドが変数にアクセスする順序は別の問題だから。
594:デフォルトの名無しさん
10/06/17 20:19:05
>>593
未だに>>553の意味わかってないだろ。
595:デフォルトの名無しさん
10/06/17 20:20:35
いや、微妙だな、わかっていっているようにも読める。
596:デフォルトの名無しさん
10/06/17 20:22:20
C#の話だったのか
597:デフォルトの名無しさん
10/06/17 20:23:49
スレタイ読んでなかったのか
598:デフォルトの名無しさん
10/06/17 20:24:10
>>590
遠まわしな説明でよく解らんな。
メモリバリアの機能を含んでいるどうかだけ書けば１行ですむのに。
599:デフォルトの名無しさん
10/06/17 20:28:07
というか、>>553の例はコンパイラが無意味に見える命令を削除しているだけじゃないのか？
600:デフォルトの名無しさん
10/06/17 20:28:59
はい？
601:デフォルトの名無しさん
10/06/17 20:30:50
volatileは最適化をなくし削除しなくなるんじゃなかったのかよｗ
602:デフォルトの名無しさん
10/06/17 20:32:08
こんな風に分かってるつもりのやつがでたらめなことばっかり言うから、
危なくて使えないんだよ。
603:デフォルトの名無しさん
10/06/17 20:36:47
>>598
＞メモリバリアの機能を含んでいるどうかだけ書けば１行ですむのに。
メモリバリアの機能を含んでるならなんで>>553はAssert起こって、
明示的にメモリバリア命令入れたら起こらなくなるの？
って思うわな普通。
メモリバリアって言っても一言で言えるほど単純な話じゃない。
604:デフォルトの名無しさん
10/06/17 20:42:36
volatile は確かに最適化を抑止するんだが、それは一つのスレッド内で変数の参照順を
変更するようなものに限られるんだよ。
605:デフォルトの名無しさん
10/06/17 20:58:58
10.4.3 Volatile フィールド
他のスレッドによる volatile 書き込みは、それらが実行された順にすべてのスレッドで行われます。
606:デフォルトの名無しさん
10/06/17 21:38:57
趣味でしかプログラミングをしない俺にはサッパリだ。
607:デフォルトの名無しさん
10/06/17 21:54:02
まあ、そこの原文の
These restrictions ensure that all threads will observe volatile writes performed by any other thread in the order in which they were performed.
A conforming implementation is not required to provide a single total ordering of volatile writes as seen from all threads of execution.
2行目の全順序は要求されないってのが結局>>533の理由なのかな。
608:デフォルトの名無しさん
10/06/17 21:55:08
>>553だったorz
609:デフォルトの名無しさん
10/06/17 21:58:07
＞全順序は要求されない
「単一」の全順序は要求されない
が重要か。
610:デフォルトの名無しさん
10/06/17 22:00:41
特定のスレッドを特定のCPUコアで動かすのってどうやるんだっけ？
611:デフォルトの名無しさん
10/06/17 22:07:31
そんなこと考えてる前にlockしちゃうなぁ。
var obj = new Object();
としといて
lock (obj) { s_x = 1; s_ya = s_y; }
と
lock (obj) { s_y = 1; s_xa = s_x; }
で、俺的には万事解決。
色々深遠な問題もあるだろうけど、そんなこと知ったこっちゃねー♪
612:デフォルトの名無しさん
10/06/17 22:18:21
まあそもそもこんな処理は普通は出てこないからなー。
これはあくまで予想と異なる結果になることがあるのを示しているだけで。
ただ、こういうコードを、無意識のうちに、動作を無意識に期待して書いてしまう可能性はあるかもしれない。
まあ普通はマルチスレッドで何かを書く場合は常に同期のタイミングは考慮しながら書くから、
多分めったなことはないとは思うけどね。
613:デフォルトの名無しさん
10/06/17 22:24:25
でもいるんだよ。
既存の処理をなんにも考えずにマルチスレッドにしちゃうのが・・・
614:デフォルトの名無しさん
10/06/17 22:52:56
>>604
参照順は変更されるんじゃないの？
volatile読み込みは他の読み込みよりも早く行われるんでしょ？
615:デフォルトの名無しさん
10/06/17 22:56:00
>>614
まあね。orz
616:デフォルトの名無しさん
10/06/17 23:00:46
>>614
変更されないよ。
＞volatile読み込みは他の読み込みよりも早く行われるんでしょ？
そうじゃない。
volatile読み取りよりも後ろにある読み取りが、
volatile読み取りよりも前に移動されるような最適化は行われない
ってこと。
617:デフォルトの名無しさん
10/06/17 23:07:25
>>616
あぁー、そう読むのかぁ。
もっと精進します。
618:デフォルトの名無しさん
10/06/17 23:10:04
そもそもvolatileの順序保障をどういう風に使うかというと、
例えば
int data1;
int data2;
volatile bool completed;
みたいな変数定義を行って、
スレッドAで、
data1 = 1
data2 = 2
completed = true;
みたいなことをして、
スレッドBで、
if (completed)
{
//data1とdata2を読み取り
}
みたいにしたとき、data1とdata2の読み取りで、
確実にスレッドAで更新された結果にアクセスできる。
これは、
volatile書き込みより前の書き込みは必ずvolatile書き込みより前に行われ、
volatile読み取りより後の読み取りは、必ずvolatile読み取りより後に行われることが保証されてるから。
619:デフォルトの名無しさん
10/06/17 23:12:58
もしこの保証がないと、スレッドBでの読み取りで、
data1とdata2が、スレッドAが書き込んだ結果であることを保証できない。
620:デフォルトの名無しさん
10/06/17 23:14:24
>>618
> volatile書き込みより前の書き込みは必ずvolatile書き込みより前に行われ、
> volatile読み取りより後の読み取りは、必ずvolatile読み取りより後に行われる
リンク先にも確かにかいてあるけれど、これに当てはまらないものはすべて保障されていないと考えるべきなのかな。
volatile書き込みより後ろの書き込みが、volatile書き込みより前に行われる可能性とかそういうの。
621:デフォルトの名無しさん
10/06/17 23:24:01
C#の言語仕様では保証されてないはず。
ECMAのCLIのメモリモデルでも、
・読み取りと書き込みは、volatile の読み取り前に移動することができない。
・読み取りと書き込みは、volatile の書き込み後に移動することができない。
というルールしかないので保証されない。
ただし、CLR2.0のメモリモデルではもう少し保証が強い。
詳しくは
URLﾘﾝｸ(www.microsoft.com)
なんだけど、分かりにくいなｗ
少なくとも書き込み順序は変更されないはず。
なぜなら、CLR2.0では実質書き込みは全て「解放形式」になっているらしいので。
622:デフォルトの名無しさん
10/06/17 23:26:36
おっと、そこのリンクの
４．書き込みは、同一スレッドからの別の書き込みを超えて移動することができない。
があるので、書き込み順序はたとえvolatileでなくとも、変更されることはないな。
623:デフォルトの名無しさん
10/06/17 23:42:25
順序がどうとか、なんでそういう話になるのか意味がわからんよ。
volatileの意味は文字通りその変数を非同期的に変更されうるものとして
扱うという意味以上でも以下でもないはずだと思うんだけど....
624:デフォルトの名無しさん
10/06/17 23:48:23
>>623
俺もそれだけの意味だと思っていたんだけど、C#では違うということを恥ずかしながら今日知りました。
625:デフォルトの名無しさん
10/06/17 23:52:24
なんだよ、結局またわかってないヤツが暴れてただけかよｗ
626:デフォルトの名無しさん
10/06/18 00:02:39
俺は暴れてはいないつもりなので、他にも分かってない人がいたのでしょう。
627:デフォルトの名無しさん
10/06/18 00:04:30
>>626
お前だろ
628:デフォルトの名無しさん
10/06/18 00:08:54
俺のようなヘボプログラマにとっての結論は、
マルチスレッドではvolatileに頼るなということだな。
629:デフォルトの名無しさん
10/06/18 00:08:57
そんな、高速だけど分かってる奴でもとっちらかって間違いかねない仕掛けで書くより、
遅くても排他処理でガチガチ泥臭く書いたほうがメンテナンスとか考えると現実的じゃね？
忘れた頃に見直す度に一々頭の中で再検証すんのかよ、って話。
630:デフォルトの名無しさん
10/06/18 00:10:43
だね。メモリバリアメソッドも用がなさそうだし、当面lockステートメントでいいやって思った。
ちゃんと理解できたら正しく速く動作するライブラリを書きたいものです。
631:デフォルトの名無しさん
10/06/18 00:13:12
>>627
なんだ、暴れたのがいまさら恥ずかしくなったか？
632:デフォルトの名無しさん
10/06/18 01:05:25
>>623
こいつがどこまでもバカなだけ。
633:デフォルトの名無しさん
10/06/18 01:07:47
>>630
基本的には正しい判断だと思うよ。
lockだって別にそんなに重いわけじゃない（状況によるが）。
634:デフォルトの名無しさん
10/06/18 01:09:53
>>623
言語仕様からMSDNマガジンの詳細な記事から
何から何まで何度も示されてるのに意味が分からないなら
お前は本当に頭が悪いんだろう。
635:デフォルトの名無しさん
10/06/18 01:57:39
>>553のって
s_x = 1;
s_ya = s_y;
の部分について、s_yの読み取りが先に行われて、
s_xの書き込み、s_yaの書き込みが行われたってことになるの？
636:デフォルトの名無しさん
10/06/18 05:13:58
どうなの？
637:デフォルトの名無しさん
10/06/18 06:28:32
>>629
鉄板でしょう。
638:デフォルトの名無しさん
10/06/18 08:58:25
C#の言語仕様のダウンロードURI教えてください。
639:デフォルトの名無しさん
10/06/18 09:10:49
VS2010のフォルダ内にありましたorz
640:デフォルトの名無しさん
10/06/18 09:58:10
object[] a = string[]{"a"};
string[] b = a as string[];
この処理は純粋にaへの代入とbへのキャストが行われているだけで、
List<object>とList<string>を型変換するときのようなインスタンス
の新規作成はされないと考えてよいのでしょうか？
641:デフォルトの名無しさん
10/06/18 13:53:30
ちょっとした疑問
class A {
object lockobj = new object;
string _a;
public a {
get {
lock(lockobj){
return _a;
}
}
set {
lock(lockobj){
_a = value;
}
}
}
これって、ちゃんとロック掛かるんだろうか？
642:デフォルトの名無しさん
10/06/18 13:54:34
て
643:デフォルトの名無しさん
10/06/18 13:56:56
>>641
はい
644:デフォルトの名無しさん
10/06/18 15:16:12
>>641
いいえ、コンパイルすらできません
645:デフォルトの名無しさん
10/06/18 15:25:20
>>635ってどうなの？
なんで頭いい人たちみんなスルーなの
646:デフォルトの名無しさん
10/06/18 15:31:28
OoOについてggrks
647:デフォルトの名無しさん
10/06/18 16:28:23
>>644
型がないからってか？
質問の意図はそうじゃないだろ・・・
648:デフォルトの名無しさん
10/06/18 17:16:46
>>641
質問のポイントはLockのスコープからのreturnだろ？
ロックはreturnステートメントの実行直後にはずれるから普通に使える。
649:デフォルトの名無しさん
10/06/18 18:46:23
>>635
>>553の件少し判った気がする。
環境依存があるようだからここにいる人たちも確認してもらえると助かる。
Releaseモードでも確認できるように修正。コンソールに出力させるようにする。
＞Debug.Assert(s_xa == 1 || s_ya == 1);
if (!(s_xa == 1 || s_ya == 1)) Console.WriteLine("* {0}, {1}", s_xa, s_ya);
こちらの環境で確認できたこと。
マルチCPU、マルチコア、ハイパースレッディングでも起きる。
シングルCPU環境では起きない。
Relaseビルド、Debugビルドはどちらでも良い。
Debug実行時に起きる。Debugなしで実行では起きない。
結論
予想が当たってればOoOとか高尚な問題でなく、IDEのデバッガのバグの可能性がある。
650:デフォルトの名無しさん
10/06/18 19:06:46
>>646
すっこんでろ
651:デフォルトの名無しさん
10/06/18 20:41:20
>>649
俺の環境では、デバッグなし実行でも起こってる。
652:デフォルトの名無しさん
10/06/18 20:43:41
>>641
ちゃんとロックかかるってのはどういう意味で言ってる？
ロック自体はもちろん期待通り普通にかかるが、
objA.A =
objA.A + "hoge";
なんてのをアトミックに実行することは当然ながらできない。
653:デフォルトの名無しさん
10/06/18 20:44:30
改行入った…
objA.A = objA.A + "hoge";
な。
654:デフォルトの名無しさん
10/06/18 21:15:29
>>618
なんか違わないか？
その例だと、スレッドBでdata1,data2が「正しく」読める保証は何もないのでは？
でなきゃ、そもそもvolatileって何だって話になる。
655:デフォルトの名無しさん
10/06/18 21:26:12
>>654
＞でなきゃ、そもそもvolatileって何だって話になる。
どういう意味？？
何言ってるのかわからない。
そりゃまあ>>618には実際にはいろいろ前提があるのは確かだが、
文脈で言いたい事柄の意図は通じると思うが。
656:デフォルトの名無しさん
10/06/18 21:29:24
>>654の指摘が何を言おうとしてるのかわからないので、そうだな、
＞その例だと、スレッドBでdata1,data2が「正しく」読める保証は何もないのでは？
なぜ保証がないのかを具体的に書けばそちらの意図はわかるかもしれん。
657:デフォルトの名無しさん
10/06/18 21:33:09
無意味な実装検証してもしょうがないような
658:デフォルトの名無しさん
10/06/18 21:35:39
>>656
そもそもその保証がない（コンパイラの最適化によって変数そのものには
アクセスしない可能性がある）から、そういう可能性を排除するためのvolatileの
はずなんだけど....
どうもこのスレ、分かってるのか分かってないのかよく分からん人が多いよな
659:デフォルトの名無しさん
10/06/18 21:38:32
volatileの使い方？を勘違いしてる
660:デフォルトの名無しさん
10/06/18 21:42:04
ひょっとして>>590の後半に書いてるような、よくある誤解をしてるクチかな？
661:デフォルトの名無しさん
10/06/18 21:43:49
よくある誤解、ねえ....
662:デフォルトの名無しさん
10/06/18 21:44:48
>>658
それがよくある誤解。そんなことは起こらない。
何度も何度も何度も出してるけど
URLﾘﾝｸ(www.microsoft.com)
でも読んでみ。
※今はC#のvolatileの話だぜ
663:デフォルトの名無しさん
10/06/18 21:49:59
volatileの意味を誤読してるとか
664:デフォルトの名無しさん
10/06/18 21:51:18
>>658
メモリモデルの意味を全く理解してないな。
だったら、例えばもしlockで排他制御してた場合に、
他スレッドで更新した変数をlock内できちんと読めるのはなぜか考えてみな。
最適化で削除されるならそれすら保証されなくなる。
lock内では削除したらダメってコンパイラにはわかってるだろとか考えなしなこと言うなよ。
lock内から呼び出される普通のメソッドだってあるんだからな。
コンパイル時にそこがlock内かどうかなんて判断は無意味なこと。
665:デフォルトの名無しさん
10/06/18 21:53:01
>>662
だからvolatileの話じゃないし。
その参照先のどこにも「C#ではキャッシュを読む最適化は行われない」
とは書いてないように思うが。
666:デフォルトの名無しさん
10/06/18 21:58:40
メモリモデルのルールをよく読め。
------
読み取りが、同一スレッドから同一ロケーションに対する別の読み取りに隣接している場合、その読み取りは削除のみ可能。
書き込みが、同一スレッドから同一ロケーションに対する別の書き込みに隣接している場合、その書き込みは削除のみ可能。
規則 5 により、複数の読み取りまたは書き込みを隣接させてから、本規則を適用することが可能です。
------
667:デフォルトの名無しさん
10/06/18 22:01:01
＞その参照先のどこにも「C#ではキャッシュを読む最適化は行われない」
＞とは書いてないように思うが。
あのな、volatile読み取りより後の読み取りは必ずvolatile読み取りより後で実行されるってのは、
CPUのキャッシュ制御を含んだ話だよ。
>>618
ではvolatile読み取りの後に変数にアクセスしてるだろうが。
だから必ずキャッシュではなく（別スレッドで更新された）最新の値が読み取られる。
っていうかそのためのvolatileだって話。
668:デフォルトの名無しさん
10/06/18 22:02:41
どれとも
＞その参照先のどこにも「C#ではキャッシュを読む最適化は行われない」
＞とは書いてないように思うが。
これはCPUキャッシュじゃなくて、レジスタにキャッシュするとか、そういう意味で書いてるのか？
それなら、それこそ>>666の話だ。
隣接する同一ロケーションからの読み取り以外で、読み取りが最適化によって削除されることはない。
669:デフォルトの名無しさん
10/06/18 22:10:40
>>666
「ケースAの場合、readのみが削除可能」という文章は、
「readが削除されるのはケースAの場合のみである」という意味ではない。
大丈夫？
>>667
どう読んでも君が思ってるような意味には解釈できないと思うが...
「処理Aと処理Bはシーケンシャルに実行されます」の意味は、
処理Aに続いて行われる処理Bに対して最適化が行われない、などということを意味しない。
670:デフォルトの名無しさん
10/06/18 23:40:03
ふえ？
671:デフォルトの名無しさん
10/06/19 00:00:00
＞「ケースAの場合、readのみが削除可能」という文章は、
＞「readが削除されるのはケースAの場合のみである」という意味ではない。
＞大丈夫？
あほくさいこと言う前にそのページ全体をよく読んでみろよ。
メモリモデルをどのように定義してるか書いてあるから。
「メモリ モデルは、順次一貫性モデル (最も制限的かつ厳密なモデル) をベースとし、」ってとこらへんな。
だいたいそんなこと言ったら書いてないことだらけなんだから、そういう読み方じゃおかしいことくらいわかろうに。
＞「処理Aと処理Bはシーケンシャルに実行されます」の意味は、
＞処理Aに続いて行われる処理Bに対して最適化が行われない、などということを意味しない。
どこの記述のことを言ってるのかわからんがな、処理Bの最適かって具体的に何のことを言ってる？
読み取りの最適化なら、前に読んだ値をキャッシュしておくくらいしかないだろ。
メモリモデルでは、そういうのを読み取りを前に移動するという風に定義してるんだよ、上のページにちゃんと書いてある。
そして読み取りはvolatile読み取りより前に移動できない、
つまり、volatile読み取りより前に読み取りをキャッシュしておくという最適化は許されない。
全部書いてある。
672:デフォルトの名無しさん
10/06/19 00:04:49
もういちいち説明するのめんどくさい、勝手に自分流解釈しとけ。
メモリモデルのこととかある程度わかってる人間ならすぐに理解できる話だ。
volatile絡みのルールの話も、マルチスレッドでのメモリモデルの一般的な話を理解してるなら
はっきり言って常識レベルの話（ごくごく一般的なルール、javaのメモリモデルも同じようなルール）。
一回マルチスレッドのメモリモデルや順序について詳しく調べてみ。
673:デフォルトの名無しさん
10/06/19 00:17:33
>>658
お前が分かってないことははっきりしてる。
674:デフォルトの名無しさん
10/06/19 00:27:55
>>658
＞そもそもその保証がない（コンパイラの最適化によって変数そのものには
＞アクセスしない可能性がある）から、そういう可能性を排除するためのvolatileの
＞はずなんだけど....
URLﾘﾝｸ(msdn.microsoft.com)
Cとかの感覚で言ってるのかもしれないが、今どきのマルチスレッドを前提とした
havaやC#のような言語では、そう簡単にアクセスそのものが消されることはないよ。
マルチスレッドで正常な動作を保証するために（保証するようなコーディングができるようにするために）、
メモリモデルというものを定義して、そのルール内で最適化を行うようになってる。
だからlockやvolatileなどをルールに従って使用して、正常に動作することが保証できるコーディングを行える。
675:デフォルトの名無しさん
10/06/19 00:36:38
Wordドキュメントになってるc#言語仕様の、10.5.3 Volatile フィールドの説明でも、
>>618のような動作を正常に行えるようにvolatileを使う例が書いてあるな。
まあ日本語がおかしくて意味不明な感じに読めてしまうけどな。
言ってることはまさに>>618と同じ。
676:デフォルトの名無しさん
10/06/19 00:38:40
using System;
using System.Threading;
class Test
{
public static int result;
public static volatile bool finished;
static void Thread2() {
result = 143;
finished = true;
}
static void Main() {
finished = false;
// Run Thread2() in a new thread
new Thread(new ThreadStart(Thread2)).Start();
// Wait for Thread2 to signal that it has a result by setting
// finished to true.
for (;;) {
if (finished) {
Console.WriteLine("result = {0}", result);
return;
}
}
}
}
この例では、次のように出力されます。
result = 143
この例では、Main メソッドが Thread2 メソッドを実行する新しいスレッドを開始します。このメソッドは、値を result という非 volatile フィールドに格納し、
次に volatile フィールド finished に true を格納します。メイン スレッドは、フィールド finished が true に設定された時点で、フィールド result を読み込みます。
finished は volatile として宣言されているため、メイン スレッドはフィールド result から値 143 を読み込む必要があります。
フィールド finished が volatile として宣言されていない場合は、finished への格納後に result への格納がメイン スレッドから参照可能になります。
その結果、メイン スレッドがフィールド result から読み込む値は 0 になります。finished を volatile フィールドとして宣言すると、このような矛盾を回避できます。
677:デフォルトの名無しさん
10/06/19 00:46:04
あっそ
678:デフォルトの名無しさん
10/06/19 13:25:41
>>658
かたくなにそう信じてるやつがいるんだな…
元々意味のない参照ならそうなる場合はあるが、
普通ほとんどの場合は違うのに。
679:デフォルトの名無しさん
10/06/19 13:38:21
>>669
ｷﾘｯ
ついていけないならくだらんケチつけなきゃいいのに
680:デフォルトの名無しさん
10/06/19 16:08:49
また同じヤツが暴れてるのかｗ
お前はもうマルチスレッドとか無理だからあきらめろｗ
681:デフォルトの名無しさん
10/06/19 18:18:54
クラスアセンブリ(dll)を許可するプロジェクトだけに読み込ませるにはどうすればいいのん？
682:デフォルトの名無しさん
10/06/19 18:31:32
>>681
コールしているアセンブリの署名を調べる。
683:デフォルトの名無しさん
10/06/19 18:41:02
>>682
ｋｗｓｋ！
ちなみにクラスアセンブリは自前のソース月の物でありまする＞＜
684:デフォルトの名無しさん
10/06/19 19:09:18
署名は改ざん検知出来るだけ
DLLのアクセス制限云々の機能ではない
685:デフォルトの名無しさん
10/06/19 19:29:04
やっぱりそうなんですね
がっくし・・・・
ProjectA ---{OK}--- A.dll
第三者のProject ---{NG}--- A.dll
みたいな事をやりたい時はみんなどうしてるのん？
686:デフォルトの名無しさん
10/06/19 19:32:12
そんなことをやりたいと思ったことがない。
687:デフォルトの名無しさん
10/06/19 19:35:14
えー社内ライブラリとかどう管理してるのー？
不正リンクされて盗まれても「でへへっ！」とか言うだけ？
うそーん＞＜
688:デフォルトの名無しさん
10/06/19 19:38:50
>>685
ＤＬＬのファイルかフォルダにNTFSのアクセス権つければよくね？
689:デフォルトの名無しさん
10/06/19 19:47:26
制限出来れば
リフレクション使ってクラス調査→不正リンク→(ﾟ∀ﾟ )ｱﾋｬﾋｬ
という.net固有の糞みたいな問題が解決するけど
未だに対策は難読化しかない。
690:デフォルトの名無しさん
10/06/19 19:53:51
別になぁ。そもそもアセンブリじゃないDLLなら呼び放題だし。
売り物ならライセンス処理つけるだろうし。
お買い上げありがとうございました。だろ？
691:デフォルトの名無しさん
10/06/19 19:55:50
オープンソース時代だから別にいいじゃんｗ
盗まれたら裁判すればいいし(ｷﾘｯ
692:デフォルトの名無しさん
10/06/19 19:58:48
>>691
盗んだほうはC++で書きましたってオチだ
693:デフォルトの名無しさん
10/06/19 20:08:44
.NETでなくても、製品の実行ファイルや図版を勝手に使われたらどうするんだよ。
そういうときは法務部門や顧問弁護士の出番。
694:デフォルトの名無しさん
10/06/19 20:18:14
まっ、やり放題な業種だからどうしようもないってこった
裁判なんざ普通は起こせないしそもそも把握すること事態が不可能
695:デフォルトの名無しさん
10/06/19 20:47:43
ヤリ放題な業種だと自分に言い聞かせてるのか？こっちまで巻き込むなよ。
696:デフォルトの名無しさん
10/06/19 20:50:51
巻き込むも何も対策方法が何もない現状
自作パッカー作ったところで焼け石に水
理想は寝て言え
697:デフォルトの名無しさん
10/06/19 20:50:51
>>683
どのアセンブリからコールされているかはわかるだろ。
そして、そのアセンブリがどのような署名されているかを調べる。
逆コンパイル防止はそれ以前の問題。
698:デフォルトの名無しさん
10/06/19 21:05:35
毎回、毎回、クラス毎に調べるのか？
手間かかりすぎだろ
699:デフォルトの名無しさん
10/06/19 21:07:48
いたるところで StrongNameIdentityPermission でDemandでもしとけ。
まあ改ざんされたらもうだめだけどな。
700:デフォルトの名無しさん
10/06/19 21:45:18
単純に
public class MyLicence : License {
public override void Dispose() {}
public override string LicenseKey { get { return ""; } }
}
public class MyLicenceProvider : LicenseProvider {
public override License GetLicense(LicenseContext context, Type type, object instance, bool allowExceptions) {
if (allowExceptions) {
string exename = Path.GetFileName(Assembly.GetEntryAssembly().Location);
if (! exename.Equals("MyLicenceTest.exe")) {
throw new LicenseException(type, instance, "do't licenced");
}
}
return new MyLicence();
}
}
[LicenseProvider(typeof(MyLicenceProvider))]
public class TestClass {
License license;
public TestClass() {
license = LicenseManager.Validate(typeof(TestClass), this);
}
}
とかでもいいんじゃね？呼び出し元exe名縛り。
701:デフォルトの名無しさん
10/06/19 21:54:35
こんな抽象クラスあったのか。
中々面白いアプローチだと思う。
702:デフォルトの名無しさん
10/06/19 21:59:05
ほぉ、これはなかなか…
703:デフォルトの名無しさん
10/06/19 22:05:48
>>701-702
そりゃどうも。えっへん！
704:デフォルトの名無しさん
10/06/19 22:06:08
Licenseは破棄が必要だぜ…
705:デフォルトの名無しさん
10/06/19 22:07:59
と思ったけど必要なければ別に実害はないのか…
706:デフォルトの名無しさん
10/06/19 22:10:53
リソース持ってないし、いいかな？と省略したけど、実装する際は通常通り
Dispose()しといたほうがいいだろね。
707:デフォルトの名無しさん
10/06/19 22:14:16
リソースというか取得したライセンスを開放する処理を好きに定義するだけでしょ
同時利用数をデクリメントするとか
空でも全く問題ない
708:デフォルトの名無しさん
10/06/19 22:20:59
ってことみたいね。
709:デフォルトの名無しさん
10/06/19 22:48:04
というか、キモはexeのファイル名を確認するところなんだから、実装の仕方は人それぞれでしょう。
710:デフォルトの名無しさん
10/06/19 23:10:48
ってことみたいね。
711:デフォルトの名無しさん
10/06/19 23:30:09
>>700をoverrideとか使わずにもっと分かり易く書いてくれ
712:デフォルトの名無しさん
10/06/19 23:33:20
webアプリで
FileSecurity filesecurity = File.GetAccessControl(path);
(pathはstring型でファイルの絶対パスが代入されています）
としました。
このファイルを他のアカウントで作成して、
アクセス権限も拒否にしたら、デバッグ環境でですが、
'/'アプリケーションサーバーエラーが発生しました。
と出て、実行できませんでした。
とりあえず、try catchを使い、アクセス禁止として
処理すれば、実行エラーは回避できました。
DACLとかいまいちわかっていないのですが、
なにか他の回避方法はあるでしょうか？
よろしくお願いします。
713:デフォルトの名無しさん
10/06/19 23:33:38
そんなレベルだったら余計なこと気にするな
どうせその他の部分で穴だらけ
714:デフォルトの名無しさん
10/06/20 00:00:25
>>711
public class Hoge
{
private Hoge() {}
public static Hoge()
{
string exename = Path.GetFileName(Assembly.GetEntryAssembly().Location);
if (exename != "hoge.exe")
throw new Exception();
return new Hoge();
}
}
でも、リフレクションやLCGを使われたらどうなるの？
715:デフォルトの名無しさん
10/06/20 00:27:30
LicenseProviderって使ったことなかったからそのサンプルコードとしては
参考になったけど、正直実用的な意味があるとは思えんなあ…
アセンブリがロードされた時に何らかのスタティックメソッドの実行を強制できれば
いろいろ面白いことが出来そうな気がするんだけど
716:デフォルトの名無しさん
10/06/20 00:43:56
そうそう、今回の話とは別に、それ前からほしかったんだよね。
717:デフォルトの名無しさん
10/06/20 01:26:14
実用的には例えばSIDとかMACとかUSBメディアのPNPDeviceIDとか
※ SID : GetComputerName、LookupAccountName API参照
※ MAC : NetworkInterface.GetPhysicalAddress 参照
※ PNPDeviceID : WMI で Win32_DiskDrive, Win32_DiskDriveToDiskPartition, Win32_LogicalDiskToPartition, Win32_LogicalDisk 参照
そういった利用者を一意に特定出来る情報をプロダクトキーと一緒に公開鍵で
暗号化してライセンス認証サーバに送って、サーバで認証後に秘密鍵で
特定情報を暗号化して送り返してもらったものを記録。
その情報を公開鍵で復号して動作環境での取得値と一致していなかったら
ライセンス違反と判断・・・とかメンドクサい実装は必要に応じて。
718:デフォルトの名無しさん
10/06/20 01:53:37
うんまあ改ざんされたら意味ないんだけどね。
719:デフォルトの名無しさん
10/06/20 02:49:16
それを言ったらどんなアプリ、ExcelだろうとWindowsOSだろうと、リエンジニアリング
されてライセンス処理部を改ざんされたら無理。
それを言うことに意味はあるのかな？
720:デフォルトの名無しさん
10/06/20 03:02:30
簡単さが違うって話。
721:デフォルトの名無しさん
10/06/20 05:35:33
確かにDllMain的なのは欲しいよな。
722:デフォルトの名無しさん
10/06/20 11:42:56
static イニシャライザでチェックしちゃいかんの？
723:デフォルトの名無しさん
10/06/20 11:47:55
staticコンストラクタはいつ呼ばれるかわからない
724:デフォルトの名無しさん
10/06/20 12:00:08
アセンブリに属性をつけておいて
その属性にstaticコンストラクタを仕込んでおけば
dllを読みこんだタイミングで実行されたりしないかなあ
725:デフォルトの名無しさん
10/06/20 12:00:32
ふーん
726:デフォルトの名無しさん
10/06/20 12:08:28
>>724
されない
カスタム属性っていうのはあくまでメターデータのラッパークラスなので
インスタンスが作られるのはその属性を参照しようとしたとき
727:デフォルトの名無しさん
10/06/20 12:26:53
お前ら釣り耐性低すぎだろ
728:デフォルトの名無しさん
10/06/20 12:32:24
>>726
(ﾟ∀ﾟ)
729:デフォルトの名無しさん
10/06/20 18:55:14
>>700みて何じゃこりゃとおもったけど>>714見たら恐ろしく単純ｗ
730:デフォルトの名無しさん
10/06/20 19:30:28
何十個もクラスをライセンス管理しないなら >>714 で充分だね。
731:デフォルトの名無しさん
10/06/20 19:53:32
>>729
遅い
732:デフォルトの名無しさん
10/06/20 21:27:20
>>700でも充分簡単じゃねぇか。
あんなのすら分からなかったらそもそもコードかけねぇだろ。
733:デフォルトの名無しさん
10/06/20 21:46:45
>>732
インデントの差だろ
734:デフォルトの名無しさん
10/06/20 22:42:20
まあ確実に言えることは、>>700 程度のコードが複雑に見えるんじゃライセンス保護
なんて当分は無縁だということ。
735:デフォルトの名無しさん
10/06/20 22:50:21
>>733
専ブラで>>700をポップアップさせて見ればいい
736:デフォルトの名無しさん
10/06/21 00:53:37
うほ
737:デフォルトの名無しさん
10/06/21 10:19:51
先生！
thread.spinwaitとthread.sleepってどう違うんですかっ？
MSDN読んでも引数の違いぐらいしかわからないです！
高度な技術を持ってる人、おすえて！
738:デフォルトの名無しさん
10/06/21 10:31:49
解説読めよ。
739:デフォルトの名無しさん
10/06/21 11:41:25
>>738
わかりません！
740:デフォルトの名無しさん
10/06/21 18:04:49
Windowsフォームアプリを作るとメインウィンドウのクラスがめっちゃ大きくなっちゃうんですが、仕方ないんでしょうか？
それともpartialで分割するべきですか？（あまり意味ないと思いますが）
741:デフォルトの名無しさん
10/06/21 18:11:42
partialの分割は意味ない。
ユーザーコントロールにするとか、ビジネスロジックを別クラスにするとか、
そんな感じ。
742:デフォルトの名無しさん
10/06/21 18:49:35
ApplicationContext使って、MainFormにはインタフェースレベルのプログラムしか書かないとかかな。
743:デフォルトの名無しさん
10/06/21 20:37:11
それでもコントロールの量が多いとイベントメソッドだけでもめっちゃ多くなっちゃうんですよね。
そこそこ普通のフリーツールくらいの規模でもメインウィンドウのクラスだけで何千行にもなっちゃう。
744:デフォルトの名無しさん
10/06/21 20:40:43
だから、そーゆーのはユーザーコントロールにまとめるんだってば。
745:デフォルトの名無しさん
10/06/21 20:43:21
で、デザイナがバグって正常に表示されない、とw
あれたぶん2010でも放置なんだろうな
746:デフォルトの名無しさん
10/06/21 21:11:27
>>743 >>745
へったくそだなぁ
747:デフォルトの名無しさん
10/06/21 21:12:31
ユーザーコントロールが正常に動かないのは作り方が悪い
748:デフォルトの名無しさん
10/06/21 21:29:20
>>746
具体的に教えてよ
749:デフォルトの名無しさん
10/06/21 22:12:54
なんでそんなでかくなるんだろ。
イベントが盛りだくさんなの？
750:デフォルトの名無しさん
10/06/21 22:17:36
ボタンが百個あるので、イベントハンドラが百個なんでしょ。
751:デフォルトの名無しさん
10/06/21 22:28:16
ボタン１個にいくつのイベントがあると思ってんだ
752:デフォルトの名無しさん
10/06/21 23:05:11
はなし が かみあって ない
753:デフォルトの名無しさん
10/06/21 23:35:24
やっぱへったくそだな
754:デフォルトの名無しさん
10/06/21 23:50:20
>>746-747
素人臭い意見だな。
そんなわけないでしょw
実際ある程度やってみれば俺の言ってる意味がわかるよ。
755:デフォルトの名無しさん
10/06/21 23:54:22
自称玄人△
756:デフォルトの名無しさん
10/06/22 00:07:04
>>754
ユーザーコントロール使ったこともない自称玄人乙
757:デフォルトの名無しさん
10/06/22 00:12:58
IDEに表示されないという理由だけでユーザコントロールを避けるってどうなの？
#define BEGIN {
と同じくらいひどいと思うんだけど、素人だからですかね
758:デフォルトの名無しさん
10/06/22 00:15:09
それは言いすぎ。
IDEのコード生成は信用できないので禁止、くらいだろ。
759:デフォルトの名無しさん
10/06/22 00:24:31
・・・IDEに出ない？ツールボックスに出てきているコレはなんだろう？
760:デフォルトの名無しさん
10/06/22 00:29:02
>>757
「だから」避けろとか使うべきでない、などとは一言も言ってない。
761:デフォルトの名無しさん
10/06/22 00:31:03
揚げ足取り玄人ですね。かっこいいです！
762:デフォルトの名無しさん
10/06/22 00:34:15
>>760
デザイナがバグって正常に表示されないというのは素人がよくハマる部分だから
気をつけろって言う意味？
763:デフォルトの名無しさん
10/06/22 00:36:18
ガキ臭い揚げ足取りしてるのはどっちだよ。
ネトウヨみたいなよくわからん被害妄想だなおい。
こっちは単にVSのデザイナはユーザーコントロールを使うとバグって
正常に表示されなくなる場合がある、という事実を言ってるだけ。
っていうか、この程度の経験もない奴が偉そうに「ユーザーコントロール使え」
とか人に講釈垂れてるっていい根性してるよな。
764:デフォルトの名無しさん
10/06/22 00:40:46
>>762
VS自体のバグだから使う側が玄人か素人か関係ないし、
気をつけようもないんだけどさだから。
765:デフォルトの名無しさん
10/06/22 01:53:37
該当バグのURL晒したらすぐ済むことなのに
766:デフォルトの名無しさん
10/06/22 02:11:16
VS2008でデザイナがしょっちゅう腐ることがあるやつを
VS2010に持ってきたが、いまのとこ一度も腐ってない
767:デフォルトの名無しさん
10/06/22 02:36:55
2002や2003に比べたら2008の安定ぷりったらないんだけど、2010はさらに調子良いのか
これは楽しみ
768:デフォルトの名無しさん
10/06/22 03:24:29
コントロール多くてもほとんどユーザーコントロールだから、フォーム側に実装する事ほとんど無いなぁ。
そんなにフォーム固有の処理って多いもん？
769:デフォルトの名無しさん
10/06/22 03:50:48
>>768
ユーザコントロール作ったらバグるって言われるよ
770:デフォルトの名無しさん
10/06/22 04:23:34
ボタンにクリックイベント一個付けるだけでもわざわざ一個のユーザーコントロール作るの？
771:デフォルトの名無しさん
10/06/22 04:25:56
そうすべきだと思ったらそうするな
772:デフォルトの名無しさん
10/06/22 04:29:59
>>770
ボタンコントロールにだけ関連する処理ならユーザーコントロールか
継承したクラス作ってそこへ入れてしまえばいいんじゃね？
Formにだらだら書くよりすっきりするよ
773:デフォルトの名無しさん
10/06/22 04:35:29
継承したらそりゃコードは分割出来るけど
デザイナの意味を成さなくなってくるな
774:デフォルトの名無しさん
10/06/22 04:40:23
Visual Studioの登場で、内部はどんどん複雑に、表面は簡単になったおかげで
基本や構造を理解せずに何となくソフトを作るプログラマーが増えた
マシンパワーが有り余ってるから、いいかげんな作りのソフトでもそれなりに動いてしまうのも善し悪し
775:デフォルトの名無しさん
10/06/22 05:00:27
>>773
もう少し詳しく。
適当に予想してレスすると怒られる流れっぽいので。
776:デフォルトの名無しさん
10/06/22 05:11:51
>>773
成すよ
まあこのあたりみてくれ
URLﾘﾝｸ(cs2ch.blog123.fc2.com)
777:デフォルトの名無しさん
10/06/22 05:33:54
>>775
イベント追加する時に+=を書かなくちゃいけなくなるとか
778:デフォルトの名無しさん
10/06/22 05:35:24
>>777
hoge.Click +=
とか書いてTAB2回押せば勝手につくってくれるじゃん
779:デフォルトの名無しさん
10/06/22 05:47:02
>>778
プロパティのイベントを選べないじゃん
780:デフォルトの名無しさん
10/06/22 05:54:13
>>779
だからその辺は>>776読めって
一旦デバックすれば継承したクラスも同じように操作できるから
それができないとFormを継承したForm1の設定はどうやって実現するんだよ
普段コードをごりごり書いてるのはFormを継承したクラスだぞ
781:デフォルトの名無しさん
10/06/22 06:01:54
>>780
MainFormのデザイナから継承させたコントロールのイベントを
プロパティウィンドウからメソッド生成させると
結局MainFormのクラス内にメソッドが追加されないか？
これじゃ分割出来てないんだが
782:デフォルトの名無しさん
10/06/22 10:25:36
ボタン100個あって、100個クリックイベントを書くのは愚の骨頂だろ。
インタフェースの仕事としては、どのボタンがクリックされたかを伝えるだけで良いんだからさ。
それ以上に、動かす用途によって書き方は変わると思うんだが。
783:デフォルトの名無しさん
10/06/22 11:17:47
100個あるボタンそれぞれが全く別の処理を行うというのは考えづらい
ツールボタン的なものや、データ行それぞれに対するコマンドあたりだろうけど
そういうのは共通の入り口から振り分けられる
784:デフォルトの名無しさん
10/06/22 12:30:02
だね
785:デフォルトの名無しさん
10/06/22 13:01:54
private void button1_clickClick(object sender, EventArgs e)
{
MessageBox.Show("1");
}
private void button2_clickClick(object sender, EventArgs e)
{
MessageBox.Show("2");
}
...
private void button100_clickClick(object sender, EventArgs e)
{
MessageBox.Show("100");
}
なんてコードがあったら継承して、一つに纏めろと言いたくなるわな。
786:デフォルトの名無しさん
10/06/22 13:34:52
さすがにそれは・・・ｗ
使う方も大変だな、ボタン100個
787:デフォルトの名無しさん
10/06/22 14:01:28
ソフトウェア和文タイプキーボードとか
788:デフォルトの名無しさん
10/06/22 14:03:54
>>787
TagでもNameでもいいので識別に使う情報も足せておけば
イベントハンドラで余裕で処理できるよ
789:デフォルトの名無しさん
10/06/22 14:10:08
>TagでもNameでもいいので識別に使う情報も足せておけば
>イベントハンドラで余裕で処理できるよ
TagでもNameでもいいので識別に使う情報持たせておけば
一つのイベントハンドラで余裕で処理できるよ
790:デフォルトの名無しさん
10/06/22 14:40:49
>>785
継承も何も、一つだけ作って後は全部同じの指定しろって感じ？w
IDEからもできるしな！
791:デフォルトの名無しさん
10/06/22 14:46:51
>>777
部品化したにもかかわらず、何処かのフォームの勝手な理由で部品を変更しようとするの？
>>790
MessageTextみたいなプロパティをつくり、IDEからも操作できるようにしておき、
クリックされた時にMessageBox.Show(MessageText)を行うようなボタンを作成すれば
IDEで配置→MessageTextを設定
という作業になるよ
792:デフォルトの名無しさん
10/06/22 14:49:52
わざわざつくるのめんどくさくてこうしてしそう。
private void Form1_Load(object sender, eventargs e)
{
Foreach (Control c in Panel1.Controls)
{
if(typeof(c)==typeof(Button)) ((Button)c).Click += new EventHandler(softkeys_button_click);
}
}
private void softkeys_button_click(object sender, eventargs e)
{
Textbox1.Text = String.concat(Textbox1.Text, ((Button)sender).Text);
}
793:デフォルトの名無しさん
10/06/22 15:05:21
デザイナで出来ない云々
794:デフォルトの名無しさん
10/06/22 18:05:57
>>785
この例だと継承なんていらないでしょ。
button_clickに全てまとめて自分自身を判別すればいいんじゃまいか。
795:デフォルトの名無しさん
10/06/22 18:09:31
>>794
自分自身を判断する際に適当なプロパティがあるかどうかってところだな。
796:デフォルトの名無しさん
10/06/22 18:15:47
>>795
Tagになんでも設定できるので識別情報を入れるか
Nameにbuttonxxxと言った感じでxxxの部分に識別情報を入れておけばＯＫ
797:デフォルトの名無しさん
10/06/22 18:24:57
>>795
Tagってそういうのに使っちゃダメなの？
798:デフォルトの名無しさん
10/06/22 18:28:35
ボタン10個あってそれぞれに10個のイベントがあったら100イベント。
その他のコントロールもあったら数百個のイベントがあってもおかしくない。
そしてそれらが共通しない機能なのも普通にあり得る。
そういう状況の時にユーザコントロールを使えって話じゃないの？
でもそれだとイベントを関連付けるときにプロパティウィンドウは使えませんよーって話。
799:デフォルトの名無しさん
10/06/22 18:37:59
>>798
>イベントを関連付けるときにプロパティウィンドウは使えませんよ
・・・お前は何を言ってるんだ・・・？
継承したのもカスタムのも、普通にプロパティ窓からイベント付けられるぞ？
800:デフォルトの名無しさん
10/06/22 18:46:41
流れ仏多義理でちょい質問
Firefoxみたいにタブに閉じるしいたけ付けたいんだけど
オーナードローするしかない？
801:デフォルトの名無しさん
10/06/22 18:47:35
>>798
ユーザーコントロールにするのなら、
メソッドやプロパティ同様に、イベントもコントロール内で定義したらプロパティウィンドウで使えるっしょ。
802:デフォルトの名無しさん
10/06/22 18:49:40
>>800
タブ部分に閉じるボタンってこと？
labelなんかだと配下にbuttonとか置けるんだけど
タブコントロールのタブ部分にできたっけかな？
803:デフォルトの名無しさん
10/06/22 18:59:31
>>800
うん、オーナードロー。
804:デフォルトの名無しさん
10/06/22 19:11:17
>>799
>>801
あれ？
プロパティウィンドウからイベントを自動生成+関連付けしたら、結局メインクラスに生成されない？
メインクラスに生成されたらわざわざユーザコントロール作った意味がない気が…。
805:デフォルトの名無しさん
10/06/22 19:16:44
ああごめん。何いってんだ。
ユーザコントロールの方のプロパティウィンドウ使えばいいんだよね。
806:デフォルトの名無しさん
10/06/22 19:20:21
>>802
どうもタブそのものを取得するのが難しいみたい
だから結局>>803って結論しかないか
WPFなら簡単なのかねー？
807:デフォルトの名無しさん
10/06/22 19:21:55
>>806
あとはタブぽい動きをするユーザーコントロールを自分で作るかだねえ
808:デフォルトの名無しさん
10/06/22 19:22:12
質問です。
RichTextBoxで行間をピクセル単位で指定する方法はありますか?
809:デフォルトの名無しさん
10/06/22 19:34:11
コントロールを継承した時のデザイナってなんで表示されないんだっけ？
810:デフォルトの名無しさん
10/06/22 19:38:29
>>806
WPFなら簡単だね、タブに何でも入れられる。TabControl in タブなんて意味不明なUIさえ可能だ。
>>808
WinFormのRichTextBoxだと、EM_SETPARAFORMATで設定できないこともない
811:デフォルトの名無しさん
10/06/22 21:10:05
WPFなんて使ってるアホまだいるのか
812:デフォルトの名無しさん
10/06/22 21:18:58
WPFはこれから
813:デフォルトの名無しさん
10/06/22 21:30:19
>>811
VS2010をdisってるの？
814:デフォルトの名無しさん
10/06/22 22:20:06
WPFとかXNAとかしょっぱいもん使って作るくらいなら
DirectXをちゃんと使えるようにしろと
815:デフォルトの名無しさん
10/06/22 22:21:31
軽さが本分のIDEを、良いグラボ必須にした戦犯と聞き及んでおりますが、反論は？
816:デフォルトの名無しさん
10/06/22 22:24:19
IDEの本分が軽さであった時などない。はいろんぱー
817:デフォルトの名無しさん
10/06/22 22:34:17
つまりは作るアプリ皆高性能グラボ高性能CPU必須にする素晴らしい技術ですな。
いやはや、NVIDIAにAMD、インテルから感謝状が期待できますのう。
818:デフォルトの名無しさん
10/06/22 22:39:17
じゃあいつまでもWin9x基準で作ってろよ
Win7がちゃんと動く環境ならWPFは普通に動く
819:デフォルトの名無しさん
10/06/22 22:42:48
糞ボロいPCで開発、糞ボロいPCで使用っていうなら.netの使用自体を考え直した方がいいんじゃ
煽りじゃなく
C#(.net)が出た当時なんてもっとボロカスに叩かれて「誰が使うんだよw」とか言われてたが
ハードの進化で今は軽い方だと思うけどなー
820:デフォルトの名無しさん
10/06/22 22:43:47
WindowマネージャがGPU使ってる時代に中身のツールキットだけレガシーに拘ってもねぇ
821:デフォルトの名無しさん
10/06/22 22:47:15
Windows7ったら、未だにVista以下のシェアだぜwwwww
ちなみに、XP 62.55%、Vista 15.25%、7 12.68% (NetApplications May, 2010)。
いつになったらメジャーになるんだろうかな？
822:デフォルトの名無しさん
10/06/22 22:48:39
新しいハードの性能を活かさないともったいないから見た目をちょっと豪華にしようっていうだけだろ
見た目がどうでもいいんだったらWindows95時代の格好悪いUIで作ってればいい
今のWinFormsの見た目だって数年後には古臭くて格好悪いと認識されるようになってるよ
823:デフォルトの名無しさん
10/06/22 22:51:13
64bitつかうで無い限りやっぱりXPだよな。
ワクチンソフトの対応さえあればXP64bit使いたいんだが。
824:デフォルトの名無しさん
10/06/22 22:51:25
まだサポート期間残ってるし、しばらくはXPが優勢でしょ。
まーでも、ここ1～2年で大分変わると思うけど。
825:デフォルトの名無しさん
10/06/22 22:52:49
あの７のGUIの出来は拷問だよマジで。
826:デフォルトの名無しさん
10/06/22 22:52:50
でも、自分も 12.68% の一員なんだけど・・・やっぱ使いづらいわコレ。
一年近く使っててもイライラする。
827:デフォルトの名無しさん
10/06/22 22:53:32
>>823
よくわからんが64bit7でワクチンソフト？ウィルス対策ソフト？なら使ってるよ
828:デフォルトの名無しさん
10/06/22 22:55:39
>>821
歴史に学べ
どのOSもメジャーになるのに数年かかってる
SPが2になる頃にはシェア一位になってる
829:デフォルトの名無しさん
10/06/22 22:57:08
>>828
では、Vistaもそろそろメジャーに！
830:デフォルトの名無しさん
10/06/22 22:57:42
長年XPを使っていたので7で慣れが必要なのは確かに煩わしい
が、ある程度のスペックならばXPより快適だぞ
XP厨だったのに素直に降参した
831:デフォルトの名無しさん
10/06/22 22:57:45
どの辺が使いづらいの？ 普通に便利に使ってるけどなぁ。
832:デフォルトの名無しさん
10/06/22 22:57:58
初心者ならともかくプログラマでしょ? 一般人から見たらPCウィザードでしょ?w
カスタマイズしたりショートカットキー使ったり補助ツール使ったりしてたら使い勝手なんか全然変わらないよ
833:デフォルトの名無しさん
10/06/22 22:58:16
>>827
７の64bit版はワクチンソフトの対応有るけど、XPの64bit版の対応が無いんだよ。
で、泣く泣く７の64bit版使ってる。
834:デフォルトの名無しさん
10/06/22 22:59:46
ここはドザ板かｗ
835:デフォルトの名無しさん
10/06/22 23:01:49
いくらでもあるだろよ・・・。
836:デフォルトの名無しさん
10/06/22 23:02:05
これが情弱ってやつか・・・。
837:デフォルトの名無しさん
10/06/22 23:20:47
ツールバーにスタートメニュー作ってるが元々のスタートが邪魔。
ライブラリが幅きかせすぎ。
おまけにクリックすると「アクセスが拒否されました」なフォルダ大杉。
エクスプローラでフォルダ開くとフォルダのツリーで現在のフォルダがなぜか一番下にスクロール。投げ飛ばしたくなる。
時々、デスクトップにdesktop.iniが居座って削除出来ない。
ホームグループアイコン、レジストリ弄ってデスクトップから消しても消してもいつのまにか復活。
USBメディア抜き差ししてるとUSBアイコンが消える。まだもう一本刺さってるだろがぁ！
これは相性の問題かもしれないが休止から戻るとNICがだんまりする確率高し。
セキュリティの問題なのか知らないが、旧型のTeraStationと繋ぐときにはグループポリシーでNTLM応答のみ送信にしないとならない。
はぁはぁ・・・他にも色々ありすぎて・・・思い返すと段々腹が立ってきた。
838:デフォルトの名無しさん
10/06/22 23:25:25
お前は死ぬまでXP使っとけよｗ
839:デフォルトの名無しさん
10/06/22 23:26:28
ふあ…ふ
840:デフォルトの名無しさん
10/06/22 23:32:40
７上のものならいいけど、XPEとかEmbedded用XPの開発も結構あるのよね。
まだ5年以上MSのサポートもあるわけだし。
ここら辺はうまく使い分けないとな。
841:デフォルトの名無しさん
10/06/22 23:38:03
VPCって微妙にめんどくさいから結局は隣に古いPCを置いてXP入れてテスト専用にしてるわ
842:デフォルトの名無しさん
10/06/22 23:39:03
VPCって微妙にめんどくさいから結局は隣に古いPCを置いてXP入れてテスト専用にしてるわ！！！！！
843:デフォルトの名無しさん
10/06/22 23:39:31
>>832
エクスプローラのAlt>F>WがAlt>F>Xに変更されてたりしててだな。
すぐ慣れるんだけどさ。
844:デフォルトの名無しさん
10/06/22 23:40:53
>>837
まあ、UIの操作性は確かに難が多い。
単なる慣れの問題と言い切れない改悪点がいろいろあるとは俺も思う。
最悪なのがファイル検索の改悪。
だが、
＞おまけにクリックすると「アクセスが拒否されました」なフォルダ大杉。
こんな文句垂れる人はシステムフォルダを隠さない設定にしちゃダメだろw
845:デフォルトの名無しさん
10/06/22 23:42:57
7はXPよりも安定してるからいれてるな
ファイラー使うから7特有のUIとか関係なし
OSは安定さえしてればいいよ
846:デフォルトの名無しさん
10/06/22 23:44:05
なら2000でいいじゃん。
847:デフォルトの名無しさん
10/06/22 23:47:02
ファイラーなんて死語だと思ってたw
っていうか、使えるファイラある？
Avestaとか使いにくいし、UltraExplorerは期待してたが結局放置状態のようだし
848:デフォルトの名無しさん
10/06/22 23:47:58
>>846
マルチCPUに対応してない
サポート切れてセキュリティ死んでる
.Net4が入らない
スリープが終わってる
パフォーマンス悪い
安定云々以前に論外です
>>847
UltraExplorer風のものをdelphiで作ったからそれ使ってる
849:デフォルトの名無しさん
10/06/22 23:50:17
ここドザ板かと思ったw
>>847
x-finder使ってる。極稀に落ちるけど気にならないレベル。Win7pro64bit
850:デフォルトの名無しさん
10/06/22 23:53:20
>>849
ありがと後で試してみる。
851:デフォルトの名無しさん
10/06/23 00:25:55
>>844
例えば SendTo。
実際は SendTo は C:\Users\{ユーザ}\AppData\Roaming\Microsoft\Windows\SendTo
なんだけど、何故か C:\Users\{ユーザ}\SendTo が意味もなく存在してアクセス不能。
こんな変なものがあっても、隠れていたら良いとか言えるのか？
852:デフォルトの名無しさん
10/06/23 00:40:29
>>851
>何故か C:\Users\{ユーザ}\SendTo が意味もなく存在してアクセス不能。
うちのセブンちゃんにはありません
853:デフォルトの名無しさん
10/06/23 00:48:22
>>851
実際は（管理者権限なら）アクセス権をちゃんと設定すればアクセスできるんだけどさ。
まあ、アクセスを制限されるのに「管理者」って名ばかりなのは何なの、
って突っ込みたい気持ちは俺も分かるけどw
854:デフォルトの名無しさん
10/06/23 01:17:31
信用できる管理者に対する制限は少ないんだよ。ｗ
855:デフォルトの名無しさん
10/06/23 02:14:51
7で嬉しかったのは存在しないネットワークのパスのファイルにアクセスしようとして固まってもプロセスは殺せるようになった。
Vistaまではタイムアウトするまでプロセスを殺すことすらできなかった。
VistaからAPI追加されて対応したと思ってたのにVistaでも追加したAPIを使ってないのか殺せなかったなぁ…
856:デフォルトの名無しさん
10/06/23 02:34:23
数百個のファイルやフォルダを選択しただけでエクスプローラが落ちる仕様はvista以降解消されたの？
この仕様のせいで数百個のファイルの入ってるフォルダを別フォルダに移動する時に手動で50個くらいずつ移動しなくちゃいけなくて不便。
857:デフォルトの名無しさん
10/06/23 03:01:31
>>856
落ちるとなるとむしろ変なシェル拡張とかが入ってる環境じゃないかと疑いたくなるなぁ。
XPでも数百くらいのファイル数というかただファイルが多いという状況で落ちたことなんて全然ない。
それでもVista以降のエクスプローラの安定感はXPとは比べものにならないと思うよ。
でも、Vistaのエクスプローラは7を触ったあとでは操作性がいろいろクソすぎてもう触る気が起きないので7がお勧めだなぁ。
858:デフォルトの名無しさん
10/06/23 03:36:59
Vista以降で解消されたのか？ってことは、Vistaよりも前のOSでおちるってことだよね。
Meは知らんが、2000、XPでは当たり前のように1000ファイルぐらい選択していたよ。
ファイルの種類にもよるんだろか。
859:デフォルトの名無しさん
10/06/23 03:57:21
XPだとファイルを1000個コピーしようとしてプチフリして「残り 192839分」とかしょっちゅう見るけどなあ
860:デフォルトの名無しさん
10/06/23 04:06:59
それは
> ファイルやフォルダを選択しただけでエクスプローラが落ちる
と何か関係が？
861:デフォルトの名無しさん
10/06/23 04:22:50
結局ユーザーコントロールに文句言ってる奴は使い方知らないだけなんじゃねぇか、と疑いたくなるなー。
普通にFormを継承したMyFormとかTextBoxを継承したMyTextBoxみたいなの使うよな？
デザイナ上で普通に動くし・・・
862:デフォルトの名無しさん
10/06/23 04:52:33
まあなｗ