C#, C♯, C#相談室 Part93©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
■Visual Studio 2017 Community(無償の統合開発環境)等はこちら http://www.visualstudio.com/downloads/ ■コードを貼る場合はこちら http://ideone.com/ ■前スレ C#, C♯, C#相談室 Part92 http://echo.2ch.net/test/read.cgi/tech/1485589613/ ■次スレは>>970 が建てる事。 建てられない場合は他を指定する事。 VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured そのC++ライブラリはそんな複雑なことしてんの? 数千行あるなら心折れるかもしれんが、自分で移植するほうが早い気がするけど C#かけるなら余裕でしょ byte[]からstructにマーシャリングするのが簡単かな あ、でも最近のC#はマルチプラットフォームだからバイトオーダーも気にしないとダメなのかな 地味にめんどくせえな 内容しっかり見てなかったけど100行なかったははず C#もどこかあるだろで探してたけどC#だけまったく見当たらなかったので、結果的には自分で移植のほうが早かったかな どなたか助けてください PaSoRiでFelicaのReadをしたいのです。 winscard.dllを利用し ScardTransmitにてADPUを送信することで 非暗号化領域のREAD/WRITEをすることはできました 追加で、暗号化領域のREADをしてほしいと言われ、 Group Service KeyとUser Service Keyという2つの鍵を渡されました。 どうやらこの2つの鍵を使って暗号化領域のREADを行うようなのですが それに該当する情報が見つかりません。 この2つの鍵と縮退鍵の関連もわかりません。 2つの鍵を使って縮退鍵を合成する??? 合成したとしてどういうAPDUコマンドを送る??? ご存知の方がいらっしゃいましたらご教授ください。 >>545 ごめんなさい。C#で書いてるのでC#で質問しました。 他に適当なスレが見つからなかったもので。。。 ライセンス契約の無い奴にそこから先は教えられねーわ。 バイナリファイルをバイト配列に一気に読み込んでLINQでゴリゴリするなんてC#って言うか.netの醍醐味だね。 C、C++と歩んできて正直C#なめてたが、プログラムの書き方変わったよ。 バイナリファイルのバイト配列はストリーム(BinaryReader/Writer)経由でしか扱ったことないな 浅学ですまないが非常に興味があるので、何をする処理にLINQを使っているのか教えてほしい >>549 横レスだけど「読み込んでLINQ」だからパーサーの部分だろ スキップ.テイク.リバースでバイトオーダー反転してデータ取り込むとかだ。 テキストファイルを一行ずつ読み込むとか、バイナリファイルを1フレームずつ読み込むなんてのは時代遅れなんじゃねかと。 最近は一括読み込みしかしないな。 パフォーマンスはライブラリやOSが担保してくれる。 時代遅れかどうかは知らんけど(そういうネトウヨチックな「俺スゲー」という間抜けな自己陶酔、俺は大嫌いだがw) 富豪的であってもそれが一時的(たとえばメソッドの中だけ)なら何も問題ないね。 その方がより簡潔だったり可読的に書けるなら否定する理由は何もない 時系列データのリアルタイム処理とかどうやって一括で読み込むんだ?? 時系列的に増えていくファイルだとか、ソケット通信のバイトストリートだとかは順次読み込みするしかないよ。 だけどドライブにあるファイルは一括読み込みの方が簡単だよ。1ステップだからね。それをソートするなりデータ抽出するなりLINQ使えば簡単だよ。 それを知ってから逐次読み出しなんか面倒くさくアホらしくなったよ。 >>556 プログラム上に巨大な配列生成しても、それだけRAMに割り付けられると思うのは大間違いだよ。 メモリの階層化とかで勉強してね。 >>556 には「高速RAMストレージ」って書いてあるけどw >>558 ストレージと書いてるだろw 外部記憶装置のアクセスの高速化しか考えてねーよw LINQのメリットの一つに IEnumerable<T>があるのになんで一括読み込みに拘るんや 一括読み込みしたものがアイエニュメラブルになるから。 >>560 最近のパソコンは速いぞ。 試しにやってみなよ。 まったく関係ないが、そういや、この手のデバイスって結局実用化せずに消えたのかね まったく聞かないな http://blog.livedoor.jp/dankogai/archives/50560934.html 読んだのずいぶん前とは思ったがもう12年前か... >>564 高速flash memoryでraid組んでもRAMの速度には負けるだろ。 >>565 PRAMのSSD版ならもう出てる DIMMは今年度中にサンプル出荷のはず STTやRe、Mは頑張ってるがまだ先だろうね Debug.Failのサンプルコードがこんなのなんですが プログラムのバグでもない限りは絶対に訪れないような場所には 片っ端からDebug.Failを撒いておいたほうがいいんですか? それともそれ専用のthrowすべき例外なりがあるんでしょうか? Assert.Fail? 何も書かないのは気持ち悪いので指針を教えてください switch (option) { case Option.First: result = 1.0; break; // Insert additional cases. default: Debug.Fail("Unknown Option " + option); result = 1.0; break; } >>568 そういうのはフロー解析による不要なコンパイルエラーを回避するために throw する 例外の種類は状況やポリシーに応じて InvalidOperationException, NotSupportedException, ArgumentException, NotImplementedException あたりを使うのが普通 これは標準で例外欲しくなるよなぁ いつも何を投げるか迷う そうかな >>569 が挙げてくれてるので十分でしょ。 少なくともメッセージは自由に設定できるし、本当に必要なら派生もできる。 そもそも例外をそんなに細かく分類する必要が本当にあるのかちょっと疑問 常識的にキャッチされない種類の例外なら何でもいいわな InvalidOperationExceptionだけはキャッチされる場合があるから微妙だけど、慣習的にはわりと多数派な気がする 個人的には常に NotImplementedException にしたい NotImplementedException は↓の人の意見だと本当は実装すべきなのに何かの都合でまだ 未実装の場合に使うらしいね。正しいかどうかは知らない http://yfakariya.blogspot.com/2011/07/blog-post.html 同じNotでもNotImplementedは「未」実装、NotSupportedは「非」サポートってのは分かりづらいっす 細かいけどコンパイルエラー回避のためにthrowする、ってのは違くない? 現実問題そんな感じになってしまうことはあるけど理想はコンパイラの都合に合わせたコードなんて無いほうがいいんだから >>569 >InvalidOperationException, NotSupportedException, ArgumentException, NotImplementedException これらの例外は自クラスには非はなく、呼んだ側の使い方が間違っているといった感じの例外に見えますが そんなにこだわらなくていいんでしょうか public class MyClass { public class BugException: System.SystemException{} public void buggedmethod() { ... throw new BugException(); } } これで良ければ1行で定義できて1番明快に思えますが 検索してもこんなことをやってる人は誰もいないっぽい… >>574 >>568 のケースに限れば、defaultに来るのはenumにメンバを追加したのにcaseを追加していない「変更漏れ」であると考えることもできるから、 NotImplementedException でも意味的におかしくはない NotSupportedExceptionは(継承の都合で)メンバ自体が使えないことを意味するからちょっと違う MissingCaseException を自作でいいのでは? >>577 なるほどそうかも 関係ないけど、いつも思うけどあるインターフェイスを継承してるのに そのインターフェイスのメソッド使ったらNotSupportedExceptionが飛んでくるって設計は なんか不条理を感じるのは俺だけかなあw インターフェイスって契約じゃなかったのかよw InvalidEnumArgumentExceptionは? >>569 が挙げてる例外は各々意味あるから>>568 のとはちょっと違う気がする AssertExceptionとかLogicErrorExceptionとかが欲しい Debugクラスのメソッドはリリース版のとき消えます、素通りします Debug.Fail() は起こりえない状況であり、かつ、素通りしても問題ない箇所、 またはリカバリ処理を行っている箇所にしか使用できません 基本は例外か Trace.Fail() を使用するべきです Debug.Fail() を使用して問題ないのは具体的には下記の条件に当てはまるときぐらいだと思います ・『絶対』に起こらないことを目視や単体テストで確認した上で、後続のコードでリカバリ処理を行っている箇所で、 開発によってコードが壊れてないかチェックするためにコードに挿入する (絶対に発生しないので単体テストを行う場合は #if で慎重にコードを切り替えてエラー状態を再現することになります) つまり、リカバリ処理してるなら Debug.Fail() は入れなくても問題ないはずです 遅くなりましたが例外とログの使い方大変参考になりました。 ありがとうございます。 超初心者ですが RectangleとかPointとかって、値型? 値型ってコンストラクタに引数渡せないって、さっき、読んだけど >>587 初心者ですが そいつらは値型でつ 値型は無引数のコンストラクタにコードを書くことができないんでなかったかいな? 構造体は初期化が0フィルだから フィールドが非null値の場合はどうなるのかはしらない Visual Studio 2017 合計 90 日間が過ぎました。 無料で使いたいんですが、どうすれば良いでしょうか? 90日ってことは有償版だろ 大人しく買えよ もしくはCommunity版を検討する >>592 どうしても有償版を使い続けたいのなら期限が切れるたびにWindowsを再インストールすればOK Community版に移行する事にしました。 ありがとうございます Communityって登録しないと期限とかなかったっけ サブスクリプションで全シリーズ揃えてる俺に死角無し。 Entity Framework Coreについて質問です。 以下のように1対多の入れ子(left join)になったデータを取ってくる場合で、一番最下層のテーブルに取得条件を追加したいです。 どのようにしてwhereメソッドを書けばよいでしょうか。 .Include(x => x.Departments) .ThenInclude(x => x.Groups) .ThenInclude(x => x.SubGroups) .ThenInclude(x => x.Employees) .ThenInclude(x => x.Skills) 例えば以下のような感じです。 Skill.ExpireDate >= DateTime.Today それぞれのプロパティはコレクションのため以下のようには書くことができません Where(x => x.Departments.Groups.SubGroups.Employees.Skills.ExpireDate >= DateTime.Today) ThenIncludeで指定しているプロパティがすべて列挙でなければ以下のように書けると思うのですが・・・ Where(x => x.Department.Group.SubGroup.Employee.Skill.ExpireDate >= DateTime.Today) それぞれの階層のクラスは全プロパティ取得することを想定しています。 Entity Framework Coreで実現可能でしょうか。 その条件ならテーブルを上からたどる必要はないのかと >>602 辿らない場合、スキルクラス単位で条件絞り込みができるのでしょうか? これができればとても楽なのですが、、、 どうしても上からたどりたいなら WhereとAnyで掘り下げていくとか SelectManyで平坦化するとかか いえ、辿りたいわけではなくて、辿らないとできないと勝手に思ってただけです 辿らなくて良いなら辿らないでやれればベストです。 ですがその方法がわからないので教えてもらえませんでしょうか。 var q = _context.Hoges.FromSql($@" select H.* from Hoges H where exists ( select null from Departments D where H.DeptId = D.DeptId and exists ( select null from Groups G where D.DeptId = G.DeptId and exists ( select null from SubGroups SG where G.GrpId = SG.GrpId and exists ( select null from Employees E where SG.SGrpId = E.SGrpId and exists ( select null from Skills SK where E.EmpId = SK.EmpId and SK.ExpireDate >= {DateTime.Today} ))))) "); var hoges = q.Include(x => x.Departments) .ThenInclude(x => x.Groups) .ThenInclude(x => x.SubGroups) .ThenInclude(x => x.Employees) .ThenInclude(x => x.Skills) .ToList(); 以下のコードはどういう内容なのでしょうか? public IList<float> Plus214_Output_0 { get; set; } 特に <float>、 { get; set; } が分かりませんでした 以下の一部になります https://github.com/Microsoft/Windows-Machine-Learning/blob/master/Samples/UWP/MNIST/src/MNIST.cs >>607 前者は「ジェネリック」、後者は「自動実装プロパティ」でググれ >>608 ありがとうございます!めっちゃ助かりました! Linqでの書き方で質問なのですが 同じサイズのdataAとdataBのデータがあるとして データが違う箇所のIndexを取り出すとしたらどう書けば良いでしょうか? 今は↓のようなコードになっています。 List<int> dataA = new List<int>() { 1, 2, 3, 4, 5, 6 }; List<int> dataB = new List<int>() { 1, 2, 4, 3, 5, 6 }; bool resultAB = dataA.SequenceEqual( dataB); if(resultAB = false) { foreach(var A in dataA) { 比較処理 } } 結果 2 3 >>610 ない頭絞って考えてみた。 Enumerable.Range(0, dataA.Count()).Where(p => dataA[p] != dataB[p]); やら dataA.Select((v, i) => new { value = v, index = i }).Where(p => p.value != dataB[p.index]).Select(p => p.index); どっちも汚い。もっと賢いのおしえろください こういうのってforで一つずつ比較するのが一番読みやすくて楽じゃね? >>613 俺もそう思う。他の処理が入ってもすぐに組み込めるし Linqは可読性がメリットなんだから、わかりにくくなったら本末転倒だし あくまで個人の感想です dataAとdataBが1000件以上あるので、まず単純に変更してるのがあるか?で SequenceEqualを使ってみた流れでLINQを調べていた流れで知りたかったです。 forで書くのがわかりやすいとは思うけど、LINQでもっとうまく書けるかなと思って >>611 参考になりました。ありがとうございます! for では、比較されるレコードが送られてくるけど、 LINQ では、答えしか送られてこないから、効率的 Linqのほうがわかりやすいし、ソースがランダムアクセスできるとも限らんだろ シーケンスを束ねてインデックス振って比較して違うやつだけ取り出してインデックスを取り出す Linqなら思ったことをそのまま書けばいい IEnumerable<int> Hoge<T>(IEnumerable<T> a, IEnumerable<T> b) { var comp = Comparer<T>.Default; return a.Zip(b, (x, y) => (x, y)) // シーケンスを束ねて .Select((e, i) => (i, e.x, e.y)) // インデックス振って .Where(e => comp.Compare(e.x, e.y) != 0) // 比較して違うやつだけ取り出して .Select(e => e.i); // インデックスを取り出す } ループじゃぱっとみ何やってるかわかんねえよ あくまで個人の感想だけど。 自分も >>619 みたいなのの方が分かりやすいなあ。 てか、そういう書き方をよくするというか。 LINQってEntityFrameworkでしか用途なくねえ? >>619 うーん、普通にこっちのほうが分かりやすいと思うけどw 別にLINQ否定派じゃないよ IEnumerable<int> GetIndices() { List<int> dataA = new List<int>() { 1, 2, 3, 4, 5, 6 }; List<int> dataB = new List<int>() { 1, 2, 4, 3, 5, 6 }; for (int i = 0; i < dataA.Count; i++) if (dataA[i] != dataB[i]) yield return i; } Zipしたものをforeachで回すのが一番自然 IEnumerable<int> Hoge(IEnumerable<int> A, IEnumerable<int> B) { var i = 0; foreach (var eq in A.Zip(B, (a, b) => a == b)) { if (!eq) yield return i; i++; } } 自分はやらんけどLinqならこう dataA.Zip(dataB, (a, b) => a == b).Select((eq, i) => eq ? -1 : i).Where(i => i >= 0); インデックスが必要な時、わざわざselect挟んでインデックス貼るの馬鹿らしい感じがして好きになれないんだけど仕方ないよね? そんなにインデックスを参照することが多いなら生成時に一緒に貼っとけって話かもしれんが… そもそもlinqマスターはインデックスを必要としない設計にいつもなるの? 自分もインデックスが無くて済むように考えるけど結果的に必要になる箇所が細部で出てくるんだよね どうしても必要な時はselect((value, index) => new {V = value, I = index})でインデックス引っ張ってるわ それでもインデックス欲しい条件1行で書けるのが楽だからLinq便利派だけども >>628 俺もそれ、ちょくちょくするんだけどforで回したほうがよくね?って思っちゃうことがあるんだよね もちろん処理によりけりと言ってしまえばそれまでなんだけど 比較するようなもんじゃないかもしれんがjavascriptなんかだと大抵インデックス取れるから、そっち触ったあとにC#に戻ると処理考えるときにインデックスありきで考えがちになっちゃう気がしてる 先に出てた課題でもzipしたあと、そのままlinqで処理を完結させるか、zip後にforで回すか 個人的にはzipがどちらにせよ入るなら最後までlinqの方が1つの処理を1つの手法で解決してる感じがして好き だけどインデックスが処理に必要だからfor使いたいって気持ちもわかる >>629 まぁforのがいいと感じるならそれでもいいんじゃないかな 複雑な処理しない限りは大体Linqのがスッキリするからそうしてるだけだし こういう拡張メソッド作っておくのはたまにやる public static IEnumerable<int> WhereIndex<T>(this IEnumerable<T> self, Func<T, bool> predicate) { var i = 0; foreach(var s in self) { if(predicate(s)) yield return i; i++; } } dataA.Zip(dataB, (a, b) => a == b).WhereIndex(eq => !eq); 拡張メソッド嫌いな人もいるだろうけど一番読みやすい わざわざSelectでインデックスつけてる冗長さもないし、添字アクセスもないし、使う時はすっきり意味がわかりやすい >>632 正直クソ分かりにくい 俺がレビューしたらリジェクトするわ WhereIndexというメソッド名を見たら大抵の人はインデックスをフィルタ条件にして要素の値を返すメソッドと誤解する そもそもメソッド名以前に、LINQって普通はキーやインデックスではなく要素の値を操作していくものっていう暗黙的了解があるから、 キーやインデックスの方を返すような操作については特に念入りにそれがわかるような明示的な表記になるように工夫したほうがいい SelectIndexWhere()ならどうか。英国紳士にも通じると思う SelectIndexFilteredByValue これでもパッと見 ? となる人は多そう >>634 IndicesWhereで十分でしょ Selectはいらんと思うw メソッドなのに動詞じゃないのはおかしいって言ったって、組み込みのWhereだってそうだ まあスレ違いだね。 >>633 >WhereIndexというメソッド名を見たら大抵の人はインデックスをフィルタ条件にして要素の値を返すメソッドと誤解する そんなのはWhereでできるし >LINQって普通はキーやインデックスではなく要素の値を操作していくものっていう暗黙的了解があるから、 >キーやインデックスの方を返すような操作については それもSelectでできるし だいたい要素の値を操作していくものっていう暗黙的了解があるならWhereIndexも要素の値が対象と思うんじゃない? なんか矛盾してね? ほぼ同じ拡張メソッドでIndexWhereのが引っかかったわ 多分こっちの方が自然なんだろうな 一応候補だったんだが自分的にしっくりこなかったけど ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる