ふらっと C#,C♯,C＃（初心者用） Part145

2019/10/07(月) 20:16:17.93

!extend:checked:vvvvv:1000:512
次スレを立てる時は↑を2行冒頭に書くこと（1行分は消えて表示されない為）

「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスや酔っぱらいレスはやめてください
>>980を踏んだ人は新スレを建てて下さい。>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。

■前スレ
ふらっと C#,C♯,C＃（初心者用） Part144
https://mevius.5ch.net/test/read.cgi/tech/1563258983/
■関連スレ
C#, C♯, C＃相談室 Part95
https://mevius.5ch.net/test/read.cgi/tech/1508168482/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/

■情報源
https://docs.microsoft.com/ja-jp/dotnet/standard/class-libraries
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/index
https://docs.microsoft.com/en-us/dotnet/standard/class-libraries
http://referencesource.microsoft.com/
・Insider.NET > .NET TIPS - ＠IT
https://www.atmarkit.co.jp/ait/subtop/features/dotnet/dotnettips_index.html
・DOBON.NET　.NET Tips
https://dobon.net/vb/dotnet/index.html

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2019/11/11(月) 06:43:42.02

>>581
そりゃ欲しいのは最大値や最小値なのに複数の要素が返ってきても面倒なだけだし

2019/11/11(月) 08:24:51.18

>>584
ま、その通りなんだけど、581 が言いたかったのは、該当要素 T を返す拡張があってもいいよね、インデックス付き Select とかあるんだからさ、ってことでは？

>>583
有益な情報ありがとう。

2019/11/11(月) 09:41:13.10

>>585
そういう拡張があってもいいなと言うならわかるが
> Max、Min句が対象とした個別要素を返すってのは酷い気がするな
と言うのは思慮が浅すぎ

2019/11/11(月) 12:40:24.59

generics, trait だろ。
has-a, interface, duck typing など、継承じゃなくて包含

Ruby では、<=> 宇宙船演算子があれば比較できる。Comparable

2019/11/11(月) 12:41:25.30

どうかな
個人的にはどちらか一つだけしか選べないとしたら>>581の実装の方が合理的だと思うけど

単純にそっちの方が需要多いと思うし、二度手間にはなるが現状の実装は
>>581的実装で代替できる（変換結果の最大値は変換関数から求められる）のに対して
逆はどうやっても不可能だから

2019/11/11(月) 12:47:13.66

>>588
上位互換の方がいいっていうのはわかる。でもそれは LINQ to Object だけを考えた場合ね。

LINQ は LINQ to Entities という OR マッパーも強く意識しているから、標準 SQL 互換の機能も大事であり、どちらか一つという選択を強いるなら現状になる。

2019/11/11(月) 12:47:47.01

別に難しいもんじゃないんだし作りゃいいんだよ
どういうのがベストかが状況によってたやすく変化する処理だと思う
値が欲しいのか要素が欲しいのか、一つで良いのか全部列挙するのか
だから標準としては1回走査で済んでsum等の算術系と同じような入出力になる現仕様を選んだんじゃない？

2019/11/11(月) 18:08:06.42

なんかよくわからないけど、SQLとの互換性ならTが返ってきた方が遥かにSQLに近いでしょ

2019/11/11(月) 18:48:51.85

？？SQLで集計関数使ったら元のレコードはわからんめえ

2019/11/11(月) 18:53:21.43

>>591
わからないなら無理に噛み付かなくていいから。
LINQ to Entities の設計思想と実際の実装がどうなってるのかある程度理解できるようになってから出直して。

2019/11/11(月) 18:57:02.20

Tを返すと戻り値がIEnumerable<T>になる
流石にそれをMax関数と呼ぶのは抵抗がある

2019/11/11(月) 19:00:34.90

まず最大値を取る
その値を持つ要素の集合をselectする

確かに無駄だな
SQLはどこかで最適化してるのかな？

2019/11/11(月) 19:02:33.34

MAXはMAXだけどそういう用途の関数？があってもいいかもね
というかすでにあるんだろうか？

2019/11/11(月) 19:42:55.85

>>596
標準ではない
使ったこと無いけど583が紹介してるものか自作するか
自作しても数行だしググればコードは転がってるよ

個人的にはこういうやつは上げだすとキリがないんで現状で十分かなと思ってる
標準で山ほど用意されても何があって何を自作しなきゃならんかがわからなくなるんで本当に基本的なものだけあればいいかなと思う

2019/11/11(月) 19:55:30.29

LINQじゃなかったら作るのは簡単

2019/11/11(月) 20:48:49.06

SQLで書けるものはだいたい書けるようなってないと使いづらいよやっぱ

2019/11/11(月) 20:52:24.25

SQLだとストアドあるけど、LINQで書けるの？
インラインビューとかも

2019/11/11(月) 20:54:23.36

それは流石にLinqのせいじゃなく、例の変な人が言ってるフレームワーク等で吸収する部分じゃないか？

2019/11/11(月) 21:13:49.74

>>595
SQLの場合はインデックスがあるから一般的にO(log n)で最大値のキーが取得できる

LINQ標準でMaxByと同じことをやる場合はちょっと効率悪いけどOrderBy使う
O(n)にするためだけにAggregate使った拡張メソッド作るよりも
走査する件数を減らすことを考えたほうがよかったりする

2019/11/11(月) 21:39:19.76

LinqとSqlは根本的に別物なので使い分けろ
当たり前のことだな

2019/11/11(月) 21:40:04.42

>>600
DDLもLINQで書けるようにしろとか言いそうな勢いだなw

2019/11/11(月) 21:46:03.84

出来ればやってくる欲しいけどw

2019/11/11(月) 21:51:17.93

>>602
LINQ to Object vs LINQ to Entities でインデックスの有無は大きいよね。テーブルごとに特性とサイズを考えて、AsEnumerable でやるか AsQueryable でやるか機能配置の決め手になることがある。

OrderBy 使っていいなら、こんな感じかな？

public static IEnumerable<T> MaxBy<T>(this IEnumerable<T> src, Func<T, IComparable> selector) =>
src.GroupBy( selector ).OrderByDescending( x => x.Key ).Take(1).SelectMany( x => x );

>>600, 601
ストアドは DB の機能だから、フレームワークでは実現できないよ。
フレームワーク側でエミュレートできたとしても DB との間で通信が頻繁に発生することになるから、性能が出ないと思われる。

DB のストアドを呼ぶことはできるはず。

2019/11/11(月) 21:59:36.96

>>604,605
つEFのCodeFirst

2019/11/11(月) 22:10:23.25

>>607
LINQじゃねーしw

2019/11/11(月) 22:38:21.34

>>608
横からすまん。
Code First で DDL 相当のことが「かなり便利に」できるわけだが、DDL やるのに LINQ でなければならない理由を教えてほしい。

2019/11/11(月) 22:50:03.30

>>609
初めからLINQの話してて、何がベストかなんて話してない

2019/11/11(月) 23:03:24.65

LINQって便利なんだけど今一歩物足りないよな
何が足りないのかと言われても難しいが

**デフォルトの名無しさん** (ｽﾌｯ Sdbf-y5kd) · 2019/11/11(月) 23:09:21.20

十分もの足りるよ

**デフォルトの名無しさん** (JP 0Hcf-ApVS) · 2019/11/12(火) 01:07:27.57

前処理はストアドで定義してアプリはストアド叩くのが定石やろ

2019/11/12(火) 02:21:22.46

LANが10Mだったころの定石だな

**デフォルトの名無しさん** (JP 0Hcf-ApVS) · 2019/11/12(火) 03:26:22.31

今は前処理クライアントでやるもんなん？

2019/11/12(火) 06:42:14.04

>>610
LINQ にこだわるなら、こだわるだけの理由が必要。
スレに貢献している人を茶化すなら、茶化すだけの知識なり、思想なり、技術的裏付けが必要。

>>611,612
どちらの意見もわかる。

LINQ to Object に閉じるなら十分。足りない部分はライブラリ自作すればいいし、そのパズルが楽しかったりする。

でも、LINQ to Entities に踏み込むと足りないことだらけ。本質的ではないところで相当な工夫が必要だし、工夫しすぎると汎用性がなくなって使い物にならなくなる。

LINQ to Object で組み始めたロジックを LINQ to Entities 互換に拡張することを考えている時間が結局ムダになることも多い。

両者、似ているようでギャップがかなり大きいところに物足りなさを感じる。

2019/11/12(火) 06:51:40.24

最初から全くの別物なのに似ているというだけで変な期待をかけて勝手に裏切られた気持ちになる人が少なからず居る
別物と割り切って名前もインターフェースも変えれば初学者が迷わずに済んだだろうな

2019/11/12(火) 07:47:36.42

>>617
そうだね。裏切られたとは思わないけど、当初の期待はかなり高かった。

でも、LINQ to Entities の情報が少なすぎて別物だって理解するまでに相当な時間がかかってしまう。
誰も頼れる人がいない中、ネット情報のみの独学でみっちり3週間かかったよ、まともに使えるようになるまでに。

2019/11/12(火) 07:51:50.22

EntityFrameworkなのかEntityFramework Coreなのかはっきりさせとけよ…

2019/11/12(火) 08:11:27.68

>>619
わからなかったからどちらも試したよ。
Framework のバージョンによって作法が大きく異なるのに、ネットはバージョンを示さず情報が混在しているのも混乱する大きな要因だった。

2019/11/12(火) 08:13:15.74

あ、ID 変わっちゃった。
618=620

2019/11/12(火) 10:46:47.47

>>620
一次リソース見なよ

2019/11/12(火) 10:52:36.27

>>622
当然見てるよ。原文で。

2019/11/12(火) 11:56:05.18

まともに使えないものがまともに使えるようになったと言ってる時点でまともな人間でないのは明白

2019/11/12(火) 12:00:35.23

>>623
なら混乱しないはず

2019/11/12(火) 12:08:55.50

>>624
君は読解力ないのかな？
局面によっては使えるかもしれないけど、業務ロジックを完結させるには役者不足、LINQ to Entities はまだまだ発展途上だね、今後に期待、と一貫して言っているのだが。

一次ソースも二次ソースも充実してないのは発展途上でこれからもまだまだ移りゆくものだからだとも思ってる。それがわかるのにけっこうコストがかかったよ、そのあたりが個人的に物足りなさを感じるところかな。

2019/11/12(火) 12:15:05.01

あぁなるほど
データアクセスに業務ロジックをバリバリ書いてしまうタイプの人か

2019/11/12(火) 12:31:28.37

>>625
一次ソースはバージョンに関しては混乱しない。それは二次ソースの話。一次ソースが混乱させるのは、LINQ to Object から Entities へ移行するにあたって、重要かつ基礎的なコンセプトをまともに解説していないこと。

たとえば、IEnumerable の派生である IQueryable はアップキャストするだけで AsEnumerable で評価されてしまうとか、引数となるラムダ式が全く同じ記法なのに IEnumerable では Func で IQueryable では Expression だとか。

これらは分かってしまえば当たり前だし、うまく設計したものだなと感心するけれど、初学者にはトラップでしかない。

君はこれら暗黙の前提を一次ソースで知ったのか？
だとしたらどこにガイドがあるか教えてほしい。

一次ソースに当たれというのは一般的なお約束だけれども、LINQ to Entities に関しては、コンセプトや実装の難しさに比して一次ソースがかなり脆弱で不親切だと思うよ。

617 の言うとおり Object と Entities でインターフェースを変えて設計するか、あるいは、移行に十分な情報を一次ソースが用意するか、どちらかだと思う。そのどちらでもないことがアンチを生んでいる原因ではないかと。

2019/11/12(火) 12:34:30.29

>>627
もちろんレイヤー化はするし、機能配置はしっかり設計するよ。
ユーザーはコード見なくていいって時代じゃないんでね。

2019/11/12(火) 12:56:06.79

真っ赤なガイジ一歩手前

2019/11/12(火) 13:00:05.39

ごめんガイジに触っちゃっま

2019/11/12(火) 13:53:14.21

>>630,631
業務ユーザが LINQ to Entities に手を突っ込むの、ガイジだよなぁ、わかるぞ。
だがね、人のやらないことを先鞭をつけてやらねばならない場合もあるのだよ。

ひととおり技術評価した結果、本格的に導入するのは時期尚早という判断で別の技術つかうことにした。.NET 5 以降に期待してる。

2019/11/12(火) 17:44:24.07

え、業務アプリで普通にLINQ to Entities使ってるけどなんかマズい問題でもあるの？
単純に手軽で使いやすいと思ったから使ってるんだけど・・・・

2019/11/12(火) 17:50:33.05

>>633
問題ない。Dapper開発元のStackOverflowでさえEntityFramework Coreを併用してる。

2019/11/12(火) 18:29:22.62

LINQのmaxやminで最大最小が求められるけど
最大、最小の値を持つオブジェクトを取得する方法はないのかな？

2019/11/12(火) 18:44:22.60

MaxBy、MinByでググれ

2019/11/12(火) 18:46:28.43

散々上で話題に出てたやんｗ

2019/11/12(火) 19:49:03.77

>>635
new {
Max = src.Max(),
Min = src.Min()
}

2019/11/12(火) 20:14:31.68

>>628
それらを区別することがはたしてLINQの目指すべき理想なのかね

2019/11/12(火) 21:23:28.30

>>639
それらってどれのことだろう？
LINQ to Object と Entities のことかな？

両者の設計はよく考えられたシームレスで美しいデザインだと個人的には思うよ、違いをしっかり理解できた後ならね。違いが分かりにくいというのは言語設計の問題ではなく、MS Docs などガイドの問題だと思う。

何が理想的な設計かは人によって感じ方が違うのではないかな。

あ、EF4, 5, 6, Core と進化する間に名前空間や正規関数などがコロコロ変わっているあたりは、場当たり的で汚いと思う。何か制約があって実装をやり直した、その苦労の跡が垣間見える。Core から後方互換を捨てて綺麗に作り直そう感があるから、.NET 5 に期待している。

2019/11/12(火) 21:44:06.09

ごめんちょっと話が横に反れちゃうけど、このスレ見たり書き込んだりしてる人って
MicrosoftDocsって日本語/英語どっちを見てるの？
当たり前のように原文ですらすらと読んで理解してるものなの？
MSDNが廃止されてDocsになったはいいけど特にAPIリファレンスとか日本語訳の品質が酷すぎて辛い
自分は英語ほとんど読めないんで、Chromeで日本語版、FireFoxで英語版＋Google翻訳をそれぞれ表示して
３タブ切り替えながら読み進めてくなんて効率の悪いことをやってるんだけど、みんなはどうしてるのか気になった

MSの一次ソースに当たるのも↑の理由でしんどいんだよね・・・
もう潤沢な日本語訳が提供されるような時代じゃなくなったんで英語のできないPGは退場せざるをえないのか

2019/11/12(火) 21:45:38.20

docsは辞書的に使うことがほとんどだしそれぐらいなら英語で十分

2019/11/12(火) 21:46:46.04

>>641
もちろん英語

2019/11/12(火) 22:25:29.03

>>641
調べる目的によるかな。

引数の順番とかオーバーロードとかうろ覚えの確認程度なら、検索して最初に出てきた方。
初出のロジックを書くためにコンセプトや基礎設計からじっくり考えつつ API を調査するなら、まず日本語でざっくり理解、重要なポイントが和訳で怪しいなら英語で精緻化。
LINQ なんかは集合論や数学に近く、これらは概念が同じなら分野跨いで英単語が同一だったりして英語の方が理解が早いから英語のみ、とか。
LINQ to Entities の場合、一次二次併せてそもそもの情報量が少ないから、英語日本語関係なくとにかく漁る。(そして英語の Q&A でほのめかされているヒントに辿り着き、一次ソース原文を当たったりする。)

2019/11/12(火) 23:03:23.32

俺も英語は苦手だけどdocsは基本英語
どういうメソッドあったっけ？で見ることが多いから多少の単語がわかればほぼ理解できる
動作が知りたいときでよくわからん英語の言い回しがあったときは日本語にして読んでみる
けど、そういうときは日本語にしても大抵理解できない
デフォを英語にするようにしとけばプログラムで頻出する英単語が徐々に覚えられるようになるから英語をオススメする

2019/11/12(火) 23:37:52.61

>>641
日本語が読めたもんじゃないから英語に切り替えることが多い
機械翻訳かける時は、最近のグーグル翻訳は使い物にならないから、みらい翻訳のお試し翻訳使ってる

2019/11/12(火) 23:53:04.67

ありがと、自分もdocs英語派に転向するよう頑張ってみる
比較的翻訳が整ってる基礎説明みたいなページでもいちいち
「角度」⇒「Angular.js」、「反応」⇒「React.js」みたいな脳内逆翻訳をかますよりは
苦手でも最初っから英語版を読み解くほうがやっぱりマシなんだよな・・・

自分はFirefoxのアドオンで
・Simple Translate （右クリックでGoogle翻訳結果をポップアップ表示）
・MouseDictionary （マウスを乗せた英単語の日本語意味をリアルタイム表示）
を入れてる
みらい翻訳はいちいち英文をCopy&Pasteするのが面倒で常用断念

2019/11/13(水) 00:34:44.18

とりあえず日本語でぱっと見て意味が取れるならそれで良し
んん？ってなったときに原文に当たる
これが一番効率良いと思うよ

2019/11/13(水) 00:57:11.68

>>648
意味が取れたと思って試してみたら挙動がおかしくて、原文見たら真反対の意味でショック受けた記憶がある。

2019/11/13(水) 01:05:25.68

アホやなあ

2019/11/13(水) 01:08:43.01

まあジャパニーズITドカタの世界じゃ専門卒の英語アレルギーな連中に扱えないようなものが普及することは決してないから、
業界から脱出するつもりがないんなら英語はハナから捨てたほうが賢明だよ
だって業務では永遠に使えないんだから

2019/11/13(水) 01:13:25.17

どこの底辺業界の業務だよ

2019/11/13(水) 01:22:20.09

いや英語棄てるとか絶対無理。
日本語訳がアテにならないのが分かってから原文しか読んでない。

2019/11/13(水) 02:18:49.03

自分は英語が苦手
でもMSの自動翻訳はイマイチなのでgoogle翻訳の自動翻訳を使う
それでもよく分からない時はgoogle 翻訳のサイトにコピペして翻訳する

2019/11/13(水) 02:34:13.53

>>654
コピペする労力を惜しまないなら
みらい翻訳の方がましな日本語になるからお勧め

2019/11/13(水) 03:12:16.84

翻訳ソフトを多用するから英語読む力が身につかないんやで
まともな辞書を使って単語帳をつけて定期的に復習するのが大事
翻訳ソフトは最後の手段

マウスオーバーで引ける辞書も便利だけど
便利すぎて辞書ナシで文やパラグラフを読む努力をしなくなると英語力は向上しない

2019/11/13(水) 11:53:32.61

英語力向上が目的じゃないから。
あくまで目的は正しい情報を入手すること。
もう数年後にはかなりの精度の自動翻訳ができるようになってると予想する。

2019/11/13(水) 12:16:37.65

翻訳精度の向上ってもう10年以上言われ続けてるよねｗ
こないだgoogleだかどっかが文脈を考慮した翻訳どうのこうのってリリース出してたけどどこまで伸びるかねぇ

**デフォルトの名無しさん** (ｽﾌｯ Sdbf-y5kd) · 2019/11/13(水) 12:22:25.68

>>656
目的をはき違えてる

2019/11/13(水) 13:18:54.28

既に英語-日本語は十分な翻訳精度になってない？
MSDNのようなオフィシャルな場はもうほぼ完璧だし、そこら辺の外人フォーラムなんかでも一応意は汲める
中学英語程度の基礎があれば読みに関してはもう不自由しない

2019/11/13(水) 13:36:03.37

>>657
超短期的な目的でしょそれ
翻訳ソフト使わないと読めないままで良いと思ってるんなら別にいいんだけどさ

技術的な調査能力だったり新しい技術を身につける速度に顕著に差が出るよ

2019/11/13(水) 14:39:59.45

現状で完璧なんて口が裂けても言えないと思うけど…
msdnみたいな同じ言い回しが頻出するようなところは個別の対応もしやすいし、そもそも単調な事実だけを述べるだけの文章なんで誤訳は少ない
そんな環境でも真逆の意味に訳されてしまっているケースすら存在する
こないだdoとdo notが逆に翻訳されててちょっと燃えたよね
補助として使う分には十分なレベルではあると思うが翻訳能力自体はまだまだ伸びて欲しいと思うよ

2019/11/13(水) 14:49:33.50

>>661
俺たちは英語のマスターが目的じゃないの
しつこいよ

2019/11/13(水) 14:52:44.04

まともな大学出てるエンジニアなら英語さえ話せれば外資に転職して軽く一千万以上貰える
必死こいてEFCoreとか覚えるより本気で英語を勉強した方が遥かに効率的だぞ

2019/11/13(水) 17:03:16.58

時々機械翻訳が真逆の時あったけどどこをどう解釈したのか痕跡も判らない

2019/11/13(水) 18:13:13.40

質問です
ジェネリッククラスにおいて型Tがクラスのときとstructのときで全く挙動を変えたいのですが、
同名の2つのジェネリッククラスに異なる型制約をつけることは可能でしょうか

2019/11/13(水) 18:27:16.02

できないんじゃないかな
別のクラス名にして
インターフェースを被せてやるんじゃダメなの？

2019/11/13(水) 18:54:26.13

ん？where T classでの制約の話じゃないの？

2019/11/13(水) 18:54:57.26

>>667
ありがとうございます試してみます

2019/11/13(水) 18:55:58.02

>>664
EFCore使うのに必死になる必要なんてない

2019/11/13(水) 18:57:22.33

>>668
class A<T> where T class と
class A<T> where T struct とを同時に作れないか、という疑問でした

2019/11/13(水) 20:12:00.42

こんばんは
質問させてください

LINQのGroupByでデータテーブルの複数のカラムを指定しvar変数に格納後、
格納したデータをCopyToDataTableメソッドでデータテーブルに変換しようとしても、
CopyToメソッドしか候補に表示されないのですがVisual Studioのバグですか？

2019/11/13(水) 20:36:20.89

フォームアプリ作っていてデバッグ中です。

フォームのクラスから呼び出したクラスにブレークポイントを設定しているのですが、
止まってくれません。

フォームのクラス上に設定したブレークポイントでは止まってくれます。
これって仕様なのでしょうか？

2019/11/13(水) 20:54:49.74

なんかプロジェクト内でブレークポイントで止まるクラスと止まらないクラスがある。
前はどこに設定しても止まっていたのに・・・。
一体何が原因なんでしょうか？

2019/11/13(水) 20:55:42.59

ブレークポイントを通ってないから止まらないだけだろう

2019/11/13(水) 20:58:47.78

>>674
設定のチェックを外したらOKになりました。
自己解決しました。
おさがわせしてすいません。

2019/11/13(水) 22:19:14.93

>>672
変数名の上にマウス持ってったら型が表示される
その型は想定しているものになっていますか？

2019/11/13(水) 22:20:10.28

>>672
変数の型を確認すべし

2019/11/13(水) 22:20:40.60

やべ、超かぶった

2019/11/13(水) 22:24:28.57

>>672
IGroupingはキーを列挙するものだよ？
キーは通常DataRowじゃないからそりゃ出ないよ
グループごとにChildrenをDataTableにしたいのか、Childrenをキー順に並んだ１つのDataTableにしたいのかによって書き方は変わる

2019/11/13(水) 22:25:44.66

>>663
マスターww

辞書使う前にとにかく翻訳ソフト使うやつは
リファレンス見ずにQiita見てコピペしようとするやつと同じ思考回路なんだよね
いつまでもスキルが身につかない原因を自分が作り出してることに気が付かないとすぐに淘汰されるよ

2019/11/13(水) 22:33:54.95

>>677-678>>680
助言をいただきありがとうございます！
もう一度よく確認してみます

2019/11/13(水) 22:43:58.27

前にも居たけどなんですぐにVSのバグを疑うんだろうね？