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

2018/06/05(火) 19:32:42.28

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

>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。

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

■情報源
https://msdn.microsoft.com/ja-jp/library/gg145045.aspx
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/index
https://msdn.microsoft.com/en-us/library/gg145045.aspx
http://referencesource.microsoft.com/

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

2018/07/08(日) 00:27:29.44

>>501
linqの古いコードって、例えばどんなん？ラムダ使ってない奴のことかな？

2018/07/08(日) 00:45:39.18

>>503
日本語

2018/07/08(日) 02:13:34.73

性懲りもなくよう相手にするなあこのクサレ脳みそども

2018/07/08(日) 11:15:40.05

他のスレでデザパタと略す奴は例外なくクソって言う風潮があるから
その略称は使わないほうがいいｗ

2018/07/09(月) 15:36:56.63

LinqというかDBアクセス系のパターンの事ならリポジトリパターンやイベントソーシング・CQRSあたりかな
MSの黒本 C#実践開発手法はどうだろう

あとRxも押さえとけば

2018/07/09(月) 23:28:49.95

名前付きパイプでプロセス間通信するとき、できるだけ遅延を小さくするためにすべきこと、したほうがいいことがありますか？

2018/07/10(火) 03:23:37.00

ポータブルなASP.NET実行環境はありますか？
勝手にソフトインストール出来ない環境で使いたい為、Tomcatのように、設定ファイルで設定してexe起動するだけのタイプを探しています。

2018/07/10(火) 03:44:47.11

>>509
.NET CoreとASP.NET Core
SCDでデプロイして内蔵サーバーのKestelで動かす
CoreはMVC系なので509が知っているASP.NETとは別物かもしれないが

2018/07/10(火) 07:07:05.03

formが3つがあってそれぞれ仮にa,b,cとして、a,b,cの中にコンボボックスがいくつかあってaのコンボボックスの一つにエクセルをdbで読み取って？コンボボックスに値を入れました。
以降もコンボボックスに入れてくんですけど、違いがブック名とシート名でコードをまとめたい時はどこにどのように書けばいいですか？
今はform aのloadに一つ書いてます。

2018/07/10(火) 08:43:35.96

class Configurations { 各コンボボックスに入れるべき値をそれぞれプロパティとして定義 }
interface IConfigurationsSource { Configurations GetConfigurations(); }
class ExcelConfigurationsSource : IConfigurationsSource {
　private readonly string book;
　private readonly string sheet;
　public ConfigurationsSource(string book, string sheet) { this.book = book; this.sheet = sheet; }
　public Configurations GetConfigurations() { return Excelシートから読み取ってConfigurationsに詰めて返す(book, sheet); }
}
こういうのを作って使い回す

2018/07/10(火) 10:08:29.34

クラスを継承して機能を共通化するのとインターフェースで共通化するのと何が違いますか？

2018/07/10(火) 10:27:34.35

いろいろなレベルでの回答があるが
インターフェースはMIX可能
継承の濫用は保守困難になりがち
インターフェース意識した方が設計的にスマートな事が多い

c#8で事情は大きく変わるが

2018/07/10(火) 13:38:42.06

クラス継承は切り離せないが、インターフェースなら切り離せる。

2018/07/10(火) 15:17:35.18

>>493
即レス感謝です
勉強になります
ありがとうございました

2018/07/10(火) 15:18:53.33

え、8ってどうなるん・・・

2018/07/10(火) 15:59:38.63

そらもうアレよ

2018/07/10(火) 17:43:22.36

おジャ魔女どれみc#

2018/07/10(火) 19:00:19.81

>>512
レベルが高過ぎてさっぱりです。
これはクラス追加してクラスに書く感じですかね？
クラス=VBのモジュールって感じでいいんですかね？

2018/07/10(火) 19:04:58.17

>>514
> c#8で事情は大きく変わるが
C#8ではnull非許容が標準になるという噂は聞いたことがあるのですが、
この話は検索してみてもなんのことを仰っているのか分かりませんでした
とても興味があるので、ぜひ詳しく教えていただけないでしょうか

2018/07/10(火) 21:19:40.32

>>521
インターフェースのデフォルト実装が導入されることかな。
.NET ランタイムにも手が入るそうな。

2018/07/10(火) 21:45:00.39

>>522
レスありがとうございます！
ただこれだけを聞くとC#8でインターフェースの価値が更に上がるように思うのですが、
>>514さんはインターフェースの価値を説かれた上で
「c#8で事情は大きく変わる」と仰っていているので、他の機能に拡充が図られるなどで
インターフェースの価値が相対的に下がると仰っしゃりたいように感じました
実際にはそういうわけではないのでしょうか？

いずれにしても、インターフェースのデフォルト実装は便利そうで楽しみです
あと、それほどいろいろと手を入れるなら、
IList<T>が共変なIReadOnlyList<out T>と反変なIWriteOnlyList<in T>を
継承するようにするとか、そういう変更もあると嬉しいな～と素人ながら思ってみたりｗ

2018/07/10(火) 22:52:33.99

めっちゃ詳しいｗ

2018/07/10(火) 23:47:58.27

>>523
IWritableListとIReadableListみたいな名前ならともかく、
それじゃわざわざOnlyって強調した単語使ってる意味がなくなるから悪手だろ

2018/07/11(水) 00:12:23.28

>>525
既にList<>はIReadOnlyList<>を実装してるんだから今更だろ。
IList<>がIReadOnlyList<>を継承できない理由は、インターフェイスメンバの明示的実装を壊すから
IList<>に宣言されてたメンバのうちIReadOnlyList<>と被るものを全部削除したとしたら、IList<>のメンバを明示的実装している既存のクラスが全滅する

2018/07/11(水) 00:40:08.40

誤解を与えてすまん
c#8でインターフェースのデフォルト実装がサポートされるので価値は高まるという認識でok

null不許容も含めて大きく変わるねえ

2018/07/11(水) 00:50:36.62

null非許容を乱暴に説明すると

参照型の変数にnullが入らないのがデフォになる。よって多くのシナリオでnull落ちになるケースが激減する。基本的にプログラミングが楽になる。
変数にnull許可する場合には明示的に宣言が必要になる。

既存のソースに対しては破壊的変更になるからコンパイルオプションとかになるんじゃないかな。

2018/07/11(水) 01:02:22.00

OOP的にも綺麗でテーブルが正規化されてればnull非許容は受け入れられるかもね
業務システムではあまり役に立たなそうだ

2018/07/11(水) 01:04:51.55

＞よって多くのシナリオでnull落ちになるケースが激減する。基本的にプログラミングが楽になる。
岩永氏の例の記事にもそう書いてあるが、何度考えてもこれは逆だと思うなw
いわゆる「例外を握りつぶす」筋悪コードと同じ弊害をもたらすだけだろう

2018/07/11(水) 01:08:15.17

凄まじい列数でほとんどがnullのテーブル
あれをなんとかしないとアプリケーションからnullを排除することは難しい
インフラの問題だからホスト言語のちょっとした改善でどうにかなるものじゃない

2018/07/11(水) 01:22:37.10

最近の言語がそういう流れだからだろうね

DB絡みに外部結合やORM、既存ライブラリやサービスがある以上、null考慮は回避できないだろうから使い分けになるだろうね
nullまみれのテーブルもいまだにみかけるし

新規コードでサクサク組んでいくには便利やと思う

2018/07/11(水) 01:24:04.27

>>525
レスありがとうございます
確かに、ReadOnlyという言葉がIReadOnlyList<>を継承するものにかかっていると考えると
IList<>がIReadOnlyList<>を継承するのは妙な感じですね
ただ現実として、>>526でも指摘していただいているようにList<>はIReadOnlyList<>を
実装していますので、ReadOnlyという言葉はあくまでIReadOnlyList<>自身にかかっていると
とらえてしまってもいいのかなと考えています
その現状の言葉遣いが間違っているのだから直すべきだというご主張なら、
実現可能性は私には難しくて分かりませんが、とても興味深いご意見だと思います

>>526
レスありがとうございます
書いていただいた文章を読むと、インターフェースは継承元のインターフェースと
同じ名前のメソッドを持てない、もしくはインターフェースの明示的実装に悪影響があると
考えていらっしゃるように見受けられたのですが、この部分がよく理解できなかったので
申し訳ないのですが詳しくご説明していただけるとありがたいです

>>527-528
レスありがとうございます
私の方こそ、変な深読みをしてしまい失礼しました
私は初学者なので機能の増強は単純に楽しみなのですが、
既存のソースを多くお持ちの方にとっては大幅な変更はいいことばかりでもないのですね

>>528-531
興味深いお話をどうもありがとうございます
自分からnull非許容の話を出しておいて恥ずかしいのですが、
実はこれが具体的にどういうものなのかほとんど理解できていないのです

var a = new string[1]; は許されるのか？とか、許されるならそれは
var a = new string[1] { string.Empty }; と同じ意味なのか？とか、
もしそれが正しいなら、クラス毎に Empty 的なものを用意しないといけないのか？とか
疑問は膨らむばかりです

2018/07/11(水) 01:52:22.43

シンプルなコードで良い疑問やなあ
実際導入されたら混乱しそう…

右辺のArrayがnullを許さないからコンパイラに怒られそう
初期値入れたらいけそう
もし仮にstringの規定値がemptyになる仕様になれば初期化無しでもコンパイルとおるかも

c#7系以前と同じ挙動にするなら
var a = new string[1]?;
という記述になるはず

List系使うから配列を生で使う機会は減ったけどね

2018/07/11(水) 01:53:31.50

恐ろしい子！

2018/07/11(水) 04:05:50.95

C#の話じゃないかもしれませんが、
LAN上の他のPCと通信するにはTCPorUDPしかないですかね？
ポート開けようとすると管理者のパスワード要求されるので
そういうのに影響されない方法があれば教えてください
サーバー上にファイル作って共有しようかとも思ったのですが
ロックとか速度とかちょっと使いにくいので

2018/07/11(水) 07:45:57.48

インターネットに出れるんならAWSでSQSかKinesisでも使えば

2018/07/11(水) 08:15:13.05

>>536
RAWなら好きなもの送れるでしょ

2018/07/11(水) 08:54:54.59

ネットワークプログラミングの定石学びたいっす

2018/07/11(水) 09:14:18.75

レイヤー無視なら
Multi-object Multi-lingual Document Intermediary　の仕様書でも

2018/07/11(水) 09:42:14.12

>>536
TCPやUDPじゃないと関所を通れないからなぁ

2018/07/11(水) 10:03:35.37

ポート開けたくないな、名前付きパイプのRemotingは？
sambaのポートが開いてりゃ疎通できた気がする。

2018/07/11(水) 10:03:54.68

ないな→ないなら

2018/07/11(水) 12:51:43.31

>>536
> ポート開けようとすると管理者のパスワード要求されるので
要するになんか管理者に知られずき通信したいんだろ
悪事に加担する気はない

2018/07/11(水) 12:56:39.30

アホか
くだらないことを書き込む前に少しは推敲しろ

2018/07/11(水) 13:59:27.90

>>544
aho

2018/07/11(水) 16:51:29.67

ありがとうございます
まずは名前付きパイプを調べてみます

2018/07/11(水) 16:58:41.62

バイブにたかしとかりょうとか名前付けて愛用してんのかなぁ…

2018/07/11(水) 17:39:37.83

>>534
レスありがとうございます

>右辺のArrayがnullを許さないからコンパイラに怒られそう
>初期値入れたらいけそう
確かにそんな気がしますね
でもそうなると大きな配列とは相性が悪そう・・・

>もし仮にstringの規定値がemptyになる仕様になれば初期化無しでもコンパイルとおるかも
それが一番わかりやすそうですね
ただ、stringはともかくStringBuilderの規定値とかどうすればいいのかさっぱり見当がつきません

>c#7系以前と同じ挙動にするなら
>var a = new string[1]?;
>という記述になるはず
?の位置は[1]の前ですか？
まあ書き方はともかく、もしvar a = new StringBuilder[100];とすると
自動的に100個のStringBuilderのインスタンスが作られるなら、
そのような動作を望まなければ配列の要素の型はnull許容にしたほうが良さそうですね

そうすると、例えばジェネリック型を使うときにはstringのような型とStringBuilderのような型の
区別をつけたくなることもありそうですし、ジェネリック型制約に新しく
where T : immutable（intやstringは許すけどStringBuilderは許さない）が
追加されたり・・・とか妄想してみましたｗ

2018/07/11(水) 17:57:29.81

プログラム素人で恐縮ですが、for文のスコープの中に変数を宣言するとメモリの無駄使いになるでしょうか?

for(;;) int hoge =1;
のような書き方です

for文に入る前に宣言した方が作法的に良いのであればそうしたいと思い

2018/07/11(水) 18:16:12.97

コンパイラが最適化するのじゃないか？

初心者は、そんな事を考えずに、なるべく狭いスコープで宣言した方が良い。
処理に、10秒以上掛かるのなら、その時に考えても良いけど

「Effective 何々」などの本を読むと、書いてあるかも知れないけど

2018/07/11(水) 18:20:39.15

>>550
C系の言語では基本的に一箇所で宣言された変数はメソッド全体で一つしか作られない
C#の場合はクロージャが絡んだりすると変わってくるけど、基本的にはそういう思想で設計されてる
気にせず必要最小限のスコープで宣言せよ

2018/07/11(水) 18:31:22.94

>>545-546
そんなレスしかできないからお前は🙅なんだよ w

2018/07/11(水) 18:40:26.95

>>550
IL見ればあなたの悩みは全て解決しますよ

2018/07/11(水) 20:26:56.12

あーでも>>550みたいな書き方すると突っ返されるメーカーあるよな。
無駄な作業させてるって自覚無いんだろうかなぁ

2018/07/11(水) 20:31:34.49

>>550みたいな書き方してるコードってたいてい他の部分もクッソ汚いから、とりあえず突き返すのはわりと賢明なやり方

2018/07/11(水) 20:35:01.60

スコープ毎にスタック操作なんかしないし、汚くてもオプティマイズされたら面影も無いし、イジメでしか無い罠

2018/07/11(水) 20:39:44.95

>>549
このレスからにじみ出る頭のよさ

2018/07/12(木) 00:31:45.14

var すら毛嫌いされちゃうとこなのでコードレビューなんかやったらストレスで禿げるわ

2018/07/12(木) 01:31:48.84

それぞれのコーディング規約に従えばいいんじゃないですか

2018/07/12(木) 02:20:50.58

>>555
さすがに>>550のコードは例としてはあれだが
C#でforの中でしか使わん変数をforの外で定義しろと？
どんなメーカーだよ。つかメーカーってなんのメーカーだよ

2018/07/12(木) 05:53:25.42

C#8のデフォルトインターフェースメソッドって、
インターフェースでほぼコーディングを終わらせてしまうことも可能、
って解釈で良いのかな。

2018/07/12(木) 06:34:40.79

クエリとlinqとlinqToXmlの違いがなにかよくわからないです
これらはなんですか

クエリはfromやselectとか思ってたのですが
"from a ～ select a"も "XXXXXX.Select(～)" の両方ともクエリ？

linqの中にクエリがある感じですか？
用語の違いを知りたいです

2018/07/12(木) 06:53:16.73

>>561
C組込上がりが閑職で社内システムを任されるとありそう

関数の先頭で宣言しろ宣言

2018/07/12(木) 07:09:00.83

>>563
メソッド式とクエリ式でググれ

**デフォルトの名無しさん** (JP 0Hc9-+kVx) · 2018/07/12(木) 07:38:41.95

NumericUpDownで、ホイール下回転で値をUpさせる方法ないですか？

2018/07/12(木) 08:08:47.97

>>562
ライブラリ実装者が破壊的変更の影響を最小化
細かいパフォーマンスを最適化
するためのものなので乱用しないで
拡張やダイヤモンド継承による名前の重複など問題はまだ残ってる

2018/07/12(木) 09:04:57.23

>>553
管理者のパスワードって、単なるスーパーユーザーのパスワードのことだろきっと

2018/07/12(木) 12:49:07.46

だったらなんなんだよ

2018/07/12(木) 15:12:12.67

久しぶりにまたＣ＃勉強してみようかと思ってるんだけど
最近の動向ってどうなの？雑誌でもあまり見かけなくなったけど

2018/07/12(木) 15:52:53.09

さあ、プログラミングの雑誌読んでる奴は最近少ないでしょ
プログラミング情報は基本ネットだからな

2018/07/12(木) 16:16:23.83

>>570
マイクロソフトはAndroidのアプリC#で作る環境起こしたり結構力入れてる

2018/07/12(木) 16:37:53.91

>>572
へえ～そうなんだ
金のにおいプンプンするね

2018/07/12(木) 16:40:31.97

そういえばWindowsフォンとかいうのもあったね

2018/07/12(木) 16:45:06.48

>>572
iOSもな

2018/07/12(木) 17:23:36.80

雑誌とか書籍とか、本屋の棚を見てると勢力図が判るね。
Python強い。

2018/07/12(木) 17:25:15.60

MVC使ってるんですが、アルゴリズムをSQLに書くのは邪道でしょうか?

Modelを用意している時点でC♯でアルゴリズムを書くのが正攻法なのかなという気がして

でもクエリにある程度書いた方がパフォーマンスは良さそうで悩んでいます

2018/07/12(木) 19:07:16.04

>>566
NumericUpDownの派生コントロールを作ってOnMouseWheelを書き換える
方法 : 既存の Windows フォームコントロールから継承する
https://docs.microsoft.com/ja-jp/dotnet/framework/winforms/controls/how-to-inherit-from-existing-windows-forms-controls
コード例
public class NumericUpDownEX : NumericUpDown
{
protected override void OnMouseWheel(MouseEventArgs e)
{
　 if (null == e) return;
　 decimal m = this.Value;
　 int a = e.Delta > 0 ? -1 : 1;
　 m += a * this.Increment;
　 m = m > this.Maximum ? this.Maximum : m;
　 m = m < this.Minimum ? this.Minimum : m;
　 this.Value = m;
}
}

2018/07/12(木) 19:39:16.71

どうでもいいことだけどEventArgsがnullで渡ってくるケースってあるの？

2018/07/12(木) 20:09:54.21

>>577
邪道です
ビジネスロジックがSQLを侵食すると保守性が下がりスパゲティクエリが量産されます
結果的にパフォーマンスも劣悪なものとなるでしょう

2018/07/12(木) 21:06:22.46

そのSQLはどこに書かれているのだね

2018/07/13(金) 06:58:05.36

SQLはクエリ管理クラスでC♯で管理してます
ストアドで書かれてたらC♯がどうこういう話では無いですね

つかストアドは世間様の開発では一般的なのでしょうか

改修に弱そうなイメージがありシステム構成の検討任されたら自分なら選択しなさそうですけど

2018/07/13(金) 08:21:33.93

ビジネスロジックをストアドに集めるってのは
見たことあるなぁ。
既存言語はFEP構築だけに使う。

どちらかに徹底してりゃ良いんじゃね。鼻ホジ

2018/07/13(金) 12:34:59.94

>>583
システムのリプレイスとデータベースのリプレイスのどちらが多いかだよな

後者でストアド依存は死ねると思う

2018/07/13(金) 14:43:56.67

DBのバージョンアップじゃなくてリプレイスで
システムをリプレイスしない案件なんてほぼ考えられん

2018/07/13(金) 15:22:59.85

可能な限り全部SQLでいいよ
多くの場合SQLの方が圧倒的に簡潔だしテストも容易だし
ストアドは管理が面倒だし見通しも悪いからソースに書きたいが

2018/07/13(金) 16:31:35.87

SQLに書いてもいいけどシステムが死ぬまで面倒を見て、他のメンテナーに迷惑をかけないでくださいね

2018/07/14(土) 14:54:07.96

データベースにSQLite使ってるんだけど、データ量が増えたらSELECTがクッソ重くて無反応になる
無料でもっとまともなDBってないかな？

2018/07/14(土) 14:57:09.03

そもそもインデックスとか
ちゃんと使ってるのかね

2018/07/14(土) 15:00:44.83

もちろん

2018/07/14(土) 15:02:50.58

PostgreSQLだな

2018/07/14(土) 15:06:32.58

C#から使うならSQLServerでしょ

2018/07/14(土) 15:26:32.37

どちらも無料なの？

2018/07/14(土) 15:40:56.72

>>579
nullで渡すと

2018/07/14(土) 15:44:26.58

標準ライブラリのことでは？

2018/07/14(土) 16:03:24.84

プライベートの開発ではpostgresql一択

2018/07/14(土) 16:12:40.69

>>588
データ量がどのくらい増えたとかテーブルのスキーマ構成とかSELECT文みてみないとなんとも言えんな
DBMS変えたら劇的に変わるもんでもないし

2018/07/14(土) 16:56:06.37

>>596
売るアプリだから無料のがよい

>>597
すまんすまん
indexの順番変えたらかなり改善した
複合indexを先に設定して、その後単一index作ってた
これを入れ替えた感じ

2018/07/14(土) 16:57:19.10

無料ならSQLServerはかなり制限がある
PostgreSQLは完全に無料で、性能・機能とも圧倒的に上
SQL ServerはWin上でGUIでお手軽に運用できるしMS製品で完結するのでドカタには愛されてる

2018/07/14(土) 16:59:28.09

俺はデータをカテゴリに分けてそれぞれに専用のテーブルを用意して振り分けて高速化したことある

2018/07/14(土) 17:06:29.29

PostgreとMySQL比べるとどんな感じ？

2018/07/14(土) 17:06:52.80

>>599
かなりって例えば？
ストアドも使えるしDBサイズも10GBまで使えるし基本問題ないっしょ。サイズ超えそうになったらバックアップDBとしてアーカイブすりゃいいしね。C#ならSQLServerがいいよ

2018/07/14(土) 17:09:02.22

俺もSQLServer使ってたけど10GB制限がキツイし全てのレコードを読めないと不都合だから別のDB探してたけどMySQL使おうかと思ってたところだった