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 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
初心者ですが
そいつらは値型でつ
値型は無引数のコンストラクタにコードを書くことができないんでなかったかいな？ 構造体は初期化が０フィルだから
フィールドが非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のが引っかかったわ
多分こっちの方が自然なんだろうな
一応候補だったんだが自分的にしっくりこなかったけど >>629
ランダムアクセスできるとは限らんしっていうかLinqだとほとんど出来ない >>641
ランダムアクセスできないコレクション扱うときにインデックスが欲しくなるケースってなかなか無いと思うけど >>643
それってインデックスつけることが一つの目的じゃない？
インデックスってかソートかな？
いろんなところでいろんな処理されるコレクションがあって、その処理の殆どにインデックスが不要だけどごく一部にインデックスがほしいとき、わざわざ1行追加するのスッキリしないなぁって感じ
たった1行なんだから書きゃいいんすよ？
それはわかってるけどなんか気持ち悪いなぁって気がするだけ ほとんど必要が無いインデックスだけど
ごく稀に必要になるから必要になるところでだけインデックスを追加するんだろ
ほとんど使わないインデックスのためにずっとランダムアクセス性を維持するとか無駄じゃん 何を言ってるのか意味が分からんけど、indexって言葉の意味を知ってて言ってるのかなそれw >>645
いや、linqでインデックスを付与しないけどランダムアクセスすることはあるよ？
前提変えたらそら意味通らんよ
コレクションをlinq以外で処理しちゃ駄目ルールでもあるの？ >>647
なにいってんだ?
IEnumerable<T>にインデックスなんてない
ないからSelectで付与するんでしょ
そんなルールはないけどほとんどほとんどLinqで済むでしょ?
Linqでサクサク処理してるのに中に突然ループが紛れ込んできたらキモいって話をしてる
var tmp = list.Where(...).OrderBy(...).ToArray();
for (int i = 0; ...) {
...
}
var result = tmp.Where(...).Select(...); >>648
え？ずっとそういう話をしてたのになんで突然
>ほとんど使わないインデックスのためにずっとランダムアクセス性を維持するとか無駄じゃん
って書いたの？
インデックスのないlinq処理でそれが必要になったときわざわざselectで付与するのなんか気持ち悪いねーって話よ？ >>649
気持ち悪いのはお前の感覚ではという話だろ
俺からすればToArrayやToListをかましてメモリとCPUを無駄にしたり余計なメソッドを追加するほうが嫌
メソッド化に関しては再利用性が高いかうまく抽象化されていて可読性が高まるというなら別だが
真にランダムアクセス性が必要なアルゴリズムならば変換せざるを得ないがそもそも今回の問題には必要がない >>650
うん、そうだよ
個人的に気持ち悪いなーってだけ
はじめからそういうふうにしか話ししてないつもりだけど
ランダムアクセスが不要だからあえてランダムアクセスできないコレクションを選択するの？
ランダムアクセスは不要だけどあったって使わないだけだからどっちでもいい、ってなるのが普通じゃないの？
パフォーマンス要求がシビアでランダムアクセスできるコレクションを選択することで、その要求から外れてしまう、とかいうならわかるけど >>651
ランダムアクセスが不要なアルゴリズムなら「当然」IEnumerable<T>(ランダムアクセスできないコレクション)を選択するだろう
まったくもって「あえて」と言う理由が分からん
もしもSelectやWhereの引数が配列だったら普通のプログラマなら「あえて配列にしたのはなぜか」と疑問を持つだろう
なんか逆なんだよね思考パターンが >>652
そういうもんかー
んじゃあ使うコレクションがランダムアクセスを提供しているか否かを把握しとかないと選択できないな… コレクションって言葉がダメだと思うぞ？
そもそもIEnumerableはシーケンシャルな列挙の機能しか提供しない
根本的に理解が間違ってる コレクションという表現はおかしいね
無限に乱数を返すものをソースにできるし マジレスするとメッセージ捕まえて
自力で描画すれば可能なんだけど
労力に見会わないのでお勧めしない
webやWPF, UWPならグラ弄るの簡単 のへこののけとこけﾉﾊｹｹﾉﾉﾈﾈサマを通り越しておりましたとが気になると７人 doxygenみたいなドキュメント生成ツールを使うとxaml部分がまともに解析出来ません。
bindingしているviewとviewmodelの関係なんかが分かるドキュメントにしたいんですが何か良い方法ないでしょうか？ Func<string> func = () => { return "text"; };
var res = func();
これを一文で書くことはできますか。
ふと気になっただけではあるけれど、自分で解決できなくて気になって仕方がない。
基本的なことが分かってないような気がする。 本当はなにをしたかったんだろう
例題が悪い気がする ああ、そうか。w
パラメータに対してちょっと複雑な変換を掛けるのだけど、汎用性がないから専用関数作るのもなんだし、
だったらラムダ式で書けばいいんじゃね？→ ラムダ式は Func 型？だから戻り値とれねーじゃん ってところから進めなった。
他にやり方はあるので出来なくてもいいのだけど、気にはなって。 専用関数でいいんじゃない？
複雑な処理ならそれこそ括りだしておいてわかりやすくしたほうがバグ出にくいし簡単でしょ ■ このスレッドは過去ログ倉庫に格納されています
