ふらっと C#,C♯,C＃（初心者用） Part150 YouTube動画>1本 ->画像>1枚

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

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

■前スレ
ふらっと C#,C♯,C＃（初心者用） Part149
http://2chb.net/r/tech/1608085775/
■関連スレ
C#, C♯, C＃相談室 Part94
http://2chb.net/r/tech/1553075856/
■コードを貼る場合は↓を使いましょう。
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/
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

---

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

List<乙>

コンソールでRPGみたいなゲーム作ろうとしてるけど
クラスの作り方がいまいち思い浮かばない
例えば
レベルアップした時にHPとかMPとかのクラスのフィールドをいじりたいけど、レベルクラスに入れるとステータス取るときに毎回status.level.hpみたいにレベルを通らないといけないのが厄介
かといってステータスクラスの中にレベルクラスとHPクラスを内包してしまうとレベルクラスのメソッドが呼び出された時にhpクラスのメソッドが呼び出せない…(staticはなしとして)

どうすれば良いのだ

レベルやHPをクラスにしたい理由は？
どういうメソッドを想定してるの？

>>3
単純に、ステータス、レベル、HP、MPをメンバ変数に持つクラスにすりゃええんちゃう？
レベルアップメソッドを呼ばれたら、それぞれを更新するだけ

最初は難しく考えないで、ありのまま設計して実装してみる
で、破綻しそうなら設計を変えて再実装
そういう試行錯誤も楽しいかもよ

ゲームはすべてのリアルタイムデータをエクセルに並べるつもりでプログラムを組め
物体同士の相互作用処理が一番多くてかつそれが7つも8つも同時に関わるので
オブジェクト指向言語の機能が役に立たないどころか悪影響すら及ぼす
絶対に使わないほうが楽に組めるぞ
まあ、まずやってみろ

偉そうなやつだな

でもまあ、とにかくやってみるってのには賛成。
根気よく続けて、それにちょっとした向上心があるなら、そのうちそれなりにはなる。

>>3 の人は、直接的なアドバイスを求めてるんだろうけど、ちょっとアドバイスしたくらいでどうにかなるようなもんでもないなぁって感じ。

>>3
オブジェクト指向言語だからクラスは物、オブジェクトであって、
RPGのキャラはそれぞれステータスを持つオブジェクト＝クラス。
キャラにはステータスがあるなら、それぞれのキャラクラスにはステータスクラスが保有されるべき。
・・・などと自分なりに整理して、設計してみてはどうか。
その設計で厄介なことがあっても、設計に納得出来るなら、それは通るしかない厄介事なのかもしれない。
それを回避したり厄介を軽減する手段はいろいろ有ると思う。
やってれば身についてくる。その過程がまた楽しい。
設計が正しいかどうか、それは自分が決めればいいが、想像が付かないなら書籍を漁る。

3だけど
一応4回くらい違う設計で同じ処理のコードを作ってみたんだが、やりたいことは
親クラスに子クラス1,2がいて
子クラス1のフィールドが更新されたとき、子クラス2のフィールドを更新したい

一応現状はref使ってインスタンスされてる子クラス2のアドレスを保存して子クラス1で間接的に更新してるけど
子クラス3,4,…って増えた時に毎回コンストラクタの引数変えて処理追加させるのは冗長的だなぁと思って違うやり方したいと考えてるけど思いつかない…

>>4
パラメータクラスに最大値、最小値、現在値をプロパティで持つようにして
HP、MP、LV、EXP、クラスをパラメータクラスを継承して作ろうとしてる
さいごにステータスクラスとしてHPからEXPをフィールドに持つようにしてコンストラクタでインスタンス化させるようにしてる

class Prameter{
private int _Max;
public int Max{
set MaxUpdate(value);
get return _Max;
}

protected virtual
void MaxUpdate(int val){
_Max=val;
}

最小値も上と同様
現在値も上と同様※
}

※少し実装とは違うけどざっくりとしたらこんな感じのクラスを現状HP,MP,Level,exp全クラスにそれぞれ継承してる
レベルアップとかは現在値の更新時処理のoverrideで処理変えたりして実装してるんだ

>>6
やっぱりそうか。Cのような関数での設計なら単純で作りやすいんだがオブジェクト指向の練習と思ってやってると意外と難しかった。
ちょうど7つも8つもパラメータが増えてきていちいち引数変えたりするの面倒やしクラスにするメリットがあまりないな…

>>13
7つ8つはパラだけじゃなくてオブジェクトもやぞ
アクセスを限定するオブジェクト指向言語の機能は絶対に役に立たん

>>11
ステータスクラスがHP, MP, LV, EXPの最大値、最小値、現在値をそれぞれ直接int等で持つ構成と
ステータスクラスがHP, MP, LV, EXPの各クラスのインスタンスを保持する構成とを比較して
後者にどういうメリットがあるのか、もしくはないのかを考えればいいんでないのかな？

>>10
>親クラスに子クラス1,2がいて
親クラス・子クラスという表現は一般的に継承関係を指すので
あるクラスが別のクラスのインスタンスを保持してる場合は親クラス・子クラスという表現は使わないほうがいい

>子クラス1のフィールドが更新されたとき、子クラス2のフィールドを更新したい
今回のケースで使うべきかどうかは微妙だけど
フィールドが更新されたときにそれをイベントとして通知するようなパターンを使えば
クラス1のコードでクラス2を参照する必要がなくなって通知先が増えてもクラス1を変更しなくてよい

https://paiza.io/projects/jSt0Q60s11SN8n8JJzO_7Q
これ、とあるゲームのキャラクターステータスだけどベタなキーバリューペアで管理してる
スキルや装備によってバトル中のHPや攻撃力/防御力とかが変化するから本来の値と底上げされた値は別項目で管理されてる

何か既存のRPGでやってるステータス計算の再現なのかな。
C#の仕組みを凝ると、デバッグが怖そう。

なるほど、
皆様、様々なアドバイスありがとうございます。
特に親、子クラスとかのニュアンスや使い方の指摘はありがたい。

ちなみにゲームの再現はしてないけど、イメージはCUIのドラクエのイメージ。それをオブジェクト指向の練習としてクラスで作ってみようとして一番最初で詰んだという経緯っす。

メリットデメリットは正直オブジェクト指向が初めてだからよくわからないってのが本音。ただ知識として幅は広がってる気がする。MVCモデルとかで実現するのかなーとか考えたりイベントをリストで管理するのかなーとか色々模索はしたけど結局いい感じにならず苦難中。

最初はあんまり沢山クラス作らない方がいいかと思う
段々とここは分離した方がいいとか継承した方がいいとか分かってくるので
とにかく動くものを作れるかどうかで勉強するにしても先に進めるかどうかの分岐点になるからな

オブジェクト指向の学習が目的なら、ポケモンで学ぶオブジェクト指向みたいなのがいくつかあるから
そういったPOSTを眺めるとなんとなく雰囲気がつかめるかもしれない

ゲーム自体があんまりOOP向きの題材じゃないかもしれないよ。

モデル化する必要があるのはゲームの世界を成立させている「舞台装置」
であってプレーヤーの目に見える表層的なキャラじゃなかったりすると思うんだけど
前者は得てして抽象的な存在になるし、どうしても後者に引きずられてしまう。

知らんけど。

大昔シューティングゲームとかボードゲームがいかにOOP向きじゃないかって
論争があったねw

そうか…
既にOOPに対して嫌悪感を抱き始めるこの始末。
とはいえ継承ができたりオーバーライドして変更したりできるのは良いね
〇〇/××って形の表示するのもは全部同じパラメータクラスで扱えるし、ちょこっと変えたいとなるとオーバーライドで消したりオーバーロードで処理増やしたりできるもんね。

うーん、やっぱC#はよーわからんw

ちなみに、C#(プログラミング)初心者が理解しやすそうな題材ってあります？
まだhelloworldから変数作って弄るよりかはゲームのほうが楽しめるんかなと思ってそれで始めたらドツボ入ったんだよね。
難易度も低めが良いけど…(マルチスレッドやGUIでないようなもの)

どういうものを最終的に作りたいかによるけどゲームが目標なら
最初からUnityで勉強するのもアリかなと思う

勉強ならコンソールアプリの方が文字だけの世界だから分かりやすいけど
最初からWinFormsのプロジェクト作ってボタンやテキストボックスなど配置して
GUIのアプリのつくり方を勉強するのも良いかも知れない
GUIだとButtonにはClickイベントが、TextBoxにはTextChangedイベントがあるとか
（デザイン画面のボタンなどをダブルクリックすれば、上記の説明した一番使うであろうイベントの
実装が追加されるようになっている）
そういうイベントにより処理を行うみたいな形になるので、リアルタイムのゲームとは違った感じになるかと

どっちにしてもプログラムしてみて動かしてを繰り返し出来る方が望ましいかな

なるほどなー
よく考えたら最終的にはGUIのアプリケーションプログラムが作りたいと思ってた。ゲームは特に好きじゃないけど好きな人が多そうだから説明する時にも役立つかなとは思ってゲームにしてた具合。
先にFormやるのもありかも

ライフゲーム

いろんな種類のキャラを動かす系のゲームはOOPに向いてると思うけどな
実際そういうゲームのほとんどがオブジェクト指向で作られてるわけで

プログラミングを学ぶ目的に適してるかと言われると微妙だが

>>27
向いてない
オブジェクト指向って
オブジェクト同士の処理を綺麗に書く
ように作られてない

全オブジェクトが存在するシーンにほぼすべての処理を記述することになる
マップ情報がないとキャラは移動すらできないことがすぐにわかる
ではマップとキャラのデータが混在した処理をどこに記述するべきか？
シーンに決まってる
なのでゲームシステムに関わるほぼすべての処理をシーンに記述することになる
もう仮にオブジェクト個別の処理が2〜3個見つかった程度で個別のクラスなんかに書くのはバカってぐらい
全部シーンに書くことになる

言語そのものよりライブラリに何があるのか把握しきれなくて辛い。
自分でクラスを作ったら、もう既に.Netにあったりするし。
辞書を熟読するような事前の勉強が必要なのかな。

>>29
必要なのは作る前にググる癖じゃね？

>>29
わかる。会社に入るとドキュメントの無いライブラリも加わる。

ゲームって普通にOOP学習にはもってこいじゃね？
一見全く種類の違う自キャラや敵やNPCなどを一つのベースクラスから派生させたりとかオブジェクト指向の有難みを享受しやすいジャンルだと思うけどな
まぁそういうことせずとも一度C言語を使ってみればC#を使ってる時点でデフォでめちゃくちゃオブジェクト指向の恩恵に授かってるというのを認識できるけど

ゲームだと単純に楽しいし、良く知ってる世界だし。
異世界小説が流行るのも、みんなリアルよりゲームのほうが詳しいからね。

ゲームはOOPより関数型のがやりやすい
OOPだとゲーム状態が大量のオブジェクトに分散してしまい管理が追いつかなくなる

パラメータ管理とレンダリングは別視点

unityやwpfで何か作ったらいいんじゃない？
嫌でもOOPを使うことになるし

Unityはやめといたほうがいいんじゃん？
ゲーム特有の定石が多い上にあまり公開されていないので、なかなかOOPを活かせるようなコードが書けるもんじゃない

なんか作るとき、ついつい無駄にインターフェース作ったり、クラスを継承させたりしたくなる。
後で使うかもって置いといても、結局、役立たずで無駄になったり。

YAGNI原則

質問です。
'string[][]'と'string[*,*]の違いは何ですか？

List<string[]> lists = new List<string[]>();
を
string[,] = lists.ToArray();
で二次元配列にしようとすると、

CS0029: Cannot implicitly convert type 'string[][]' to 'string[*,*]'

とエラーが出て困っています。

[][]は配列の配列
[,]は二次元配列

>>41
なるほど、理解出来ました。
ありがとうございました。

>>1
関連スレ
ふらっと C#,C♯,C＃（議論用） [無断転載禁止]©2ch.net
http://2chb.net/r/tech/1469538912/

>>38
「いつか使うだろう」という動機で作る機能の9割は結局使われないという法則があってだな

でも、ついでだし作っとくか、で作ったやつがその後のバグ対に効果大なこともあったな。結構。

「起こる可能性のあることはいつか必ず起こる」ってのはマーフィーの法則だっけ。
アタマの片隅にでも置いておくと、後で助かることがままある。

一人で作ってるならいいんだけど別の人が対応する時に混乱させるだけなことが多いからな
チーム開発では起こらないことを無駄に考えてしまうのはよくないって場面の方が多い

個人的には>>45に同意
要件レベルだと「いつか使うかも」で入れた機能はゴミでしかないが、
開発者が気を利かせて入れたものは役に立つことが多い

>>47
センス悪い奴って絶望的じゃん
ユースケースを脳内で構築できないっつーの？

必要になると思って書いておいたプロパティやメソッドが結局まったく使われなかった、
っていうのはないことはないと思う。

YAGNIって普通はこういう話じゃないの？

>>38が言ってるような要らんInterfaceや要らん継承関係を作ってしまうって
YAGNIとちょっと違う気がするし、そもそも普通はあんまりやらん気がするなあ。

コードレベルで呼び出されないのと運用上使用されないのは別問題だよ
前者はほぼ例外なく無駄無価値無意味なんで、俺がコードレビューするなら基本的には消させる

スレチ
議論は議論スレでどうぞ

>>44-50
横から便乗で質問ですけど、
「いつか使うだろう」とインターフェースや継承関係を作っておく自体は推奨されることですか？

例えば、インターフェースや継承関係が無くても、直付けで作れてしまう訳じゃないですか。
むしろ、そっちの方が楽（というか、直付けでしか作れない人もいますし）。
ただし、物事が複雑化してきたときに、インターフェースや継承関係があると拡張しやすい。

これって上級者なら、（どんなに小さいプログラムだろうが）常にインターフェースや継承関係を作った方がいいのか、
それとも、ケースバイケースで「このぐらい複雑ならインターフェースや継承関係が要る」という判断基準に則って作った方がいいんですか？

>>51
すれ違いになりました。
議論スレ、行きます。

>>52
推奨する人は確実にいないと思うよ。
「ついやっちまう」ことも普通はまずないんじゃないか。
IClonableみたいな実例があるから皆無とも言えないけど。

Seleniumで　closeとquitをセットで使ってましたが
quitさへ使えばプロセス残りも防げて万能という認識で良いでしょうか？

というのもなぜか、最近アップデートされたChromeドライバーのバグなのか
driver.close();を実行するとやたらと時間が掛かる様になり、ストレスを感じています。

演算子のオーバーロードを定義したクラスを継承してそのクラスのオブジェクト同士を足したりしたいんだけど、
継承した子クラス同士足し算してもオーバーロードしてるのが親クラス返してエラー出る…
なんとかなりませんか…

コーのせられる？

>>57
当たり前のことが起るべくして起こってるようにしか聞こえんよ
何か盛大に勘違いしてない？

>>59
その当たり前の事がわからないのですが…
子クラスのクラス変数に親クラスのインスタンスを入れれないのはわかりますが、それに対してどうすれば良いのですかと質問しています。

子クラスどうしの演算子を新しく定義する

いやいやゲームはメチャクチャOOPに向いてる。
ゲームエンジンがプロパティペインで物を制作管理していくのが中心になってるってことは
全体としてOOPと相性がいい。

そらそうよ、鋳型と各オブジェクト、その相互作用、隠蔽やインターフェース、
まさにオブジェクト指向言語の基礎サンプルやエクササイズが綺麗にヒットしやすいのがゲームよ。

>>62
エアプ乙
ゲームはオブジェクト同士の関連処理が一番多い
それを綺麗に書く処理はオブジェクト指向言語には無い
これを議論するといっつも言語機能に用意されてないもんだから色んなワンダーランドがご披露されるだけのクソ展開になる
いいか
そんなもんないんだ
お前がどう書くかなんて俺は興味ない
ただ言語の機能にない
それだけだ

たんに解がひとつではないだけの話じゃね？
そんなの普通のGUIアプリ一つ取ってもそうじゃん

文面見ればオブジェクト指向を理解して言ってるのかどうかわかるやろ

議論スレに行った方が良いのか判らないけど、
俺も初心者なんだけどC#の機能を試したくってさ。
基本キャラからキャラ種類別にクラス継承させたりして楽しんでたよ。

でもゴリゴリにスペックを切り詰めるようなゲームだと、そんな余裕はないのかもな。

ゴリゴリにスペック使うような案件にC#使うとは思えないけど

日本産のスマホゲーと大陸産のスマホゲーぐらいの速度差は出るだろうな

オブジェクト同士の関連処理を綺麗に書く機能、って具体的にどんな感じの物なのか興味はある。

ここ「初心者の質問スレ」で「初心者の雑談スレ」じゃないんだけどテンプレ読めないの？
マ板でやれ

>>68
中華の大手どころってマルチプラットフォーム対応なソシャゲもUnityとか使わずにそもそも自前エンジンで開発してね？

むしろUnityじゃないの見たことない

>>69
まあ言語機能云々は意味不明に聞こえるねw

前も書いたけど、ゲームの場合Mediator的な装置を用意すべき場面でも
目に見えるオブジェクトに引きずられて変な設計してしまいがちだと
いう意味なら分からんでもない。

バブルボブル（おっさんにしか分からんかも）で泡の相互作用を
Bubbleクラスに無理に実装したらたぶんハマるよね。

ちきしょー、分かっちまった

linq便利だなーって使いまくってたけど
最近自分が手続き型の思考をしなくなってきたことが怖くなってきた
これプログラミング能力が低下するのでは..

>>75
でもLinqって古くから有る技術の延長にある気がする。
SelectしてWhereで選んでSortしてっていうのは、コマンドプロンプトでパイプリダイレクションとかいう手法に似てる。
ラムダ式とかは新しいのかな。数学の世界とかそういう所では古いのか。

やっててよかったラムダ式。
やらなきゃよかった苦悶式。

>>76
君はLISPを何だと思っているのかね？

そうか、C#だとメソッドチェーンすらも一般的ではないのか…
いやそんな馬鹿な
Unity制御スクリプトとしての利用が多いから？
いいや雑談だし

>>75
そりゃ脳みそは使わないと衰えるだろうね
最適化重視で副作用を容認したコードを書こうとすると詰まることが増えた気がする

いきなりメソッドチェーンとか持ち出したのはLinqの話に絡めてか？
全然違うものだと思うが。

Linqのクエリ式自体はメソッドチェーンのシンタックスシュガーじゃん

メソッドチェーンの元々の意味はvoidのメソッドをthisを返すようにして....
ってことだったんだと思うよ。

個人的にはこういう重箱の隅を突く話は好きじゃないけど

>>73
純粋に、自分が知らない有用な書き方があるなら知りたいとは思うんだよな。
別スレの LINQ がらみの話題もやるかどうかは置いておいて勉強にはなったし。
もしくだんの人が出てきてくれて講釈してくれるなら専用のスレぐらいは立てる。

初歩的な事かもしれませんが教えて下さい。

以下のような独自クラス「Group」のリストがあります。
このリストをクラスのAgeListをキーにGroupByしたいのですが上手くグループ化できません。
どうすれば良いでしょうか。

public class Group{
/// グループID
public int Id {get; set;}
/// グループ名
public int GroupName {get; set;}
/// グループ所属の年齢一覧
public List<int> AgeList {get; set;}

public Member()
{
List = new List();
}
}

>>85
どうすればいいじゃなくてどうしたいのかをお前が決めろ
平均年齢なのか最大年齢なのかそれともまた別の基準なのか
グループ化に使うキーが一意に定まらないならグループ化のしようがない

>>85
最低限ビルドできるコードを例に挙げろよ

そもそもの設計ヤバない？AgeはMemberに持つのでは？

デフォルトで使われる比較関数じゃ欲しい結果が得られないからGroupByに独自の比較関数を渡すか、Groupクラスに比較方法を定義しておくかのどちらか

新卒研修の課題とかだろうから設計にツッコミいれてもしょうがないような

初心者以前の話だよな
何がしたいか位は分かるように書けよと思う

何がしたいかはなんとなくわかるだろ

>>92
動かないあれを見て分かるか？
そもそも構造すら間違ってるやろ

>>92
わかるんなら説明してくれよw
メンバーの年齢だけを保持してるグループってあまり見かけないし

俺はこういう場合、独自解釈して好きなように作る。
今回ならAgeListをソートしてカンマ区切りの文字列にして、をれをキーにする。
でGroupByだな。

過去この独自解釈が5割くらいそのまま仕様になってる

>>93
>独自クラス「Group」のリスト
>このリストをクラスのAgeListをキーにGroupByしたい

List<Group> list = new List<Group>();
// なんか処理
list.Groupby(x => x.AgeList)
ってしたいって理解したんだけど違うんかな

宣言でそもそも間違ってるのは知らん

Ruby なら、こういう感じ

members = [ {id: 1, age: 30}, {id: 2, age: 20}, {id: 3, age: 50} ]

p members.sort_by{ |member| member[ :age ] }

出力
[{:id=>2, :age=>20}, {:id=>1, :age=>30}, {:id=>3, :age=>50}]

>>97
C#なら？

>>97
APLなら？

そんな議論はさておき、俺様が>>100を掻っ攫う

Rubyガイジは無視して同じコードをちょっと書いてみた
https://paiza.io/projects/XRdHMEMPrv4_lIhlB8WYuw

ピザくいたい

この時間だからラーメンにしておきな

C++とJavaを業務でやっていてc#始めた初心者です。
Xamarin.Mac でmacOSのアプリを作りながら学んでるけど
恐ろしく情報が少ない…。Macでc#使う人って少ないんでしょうか？

そもそもXamarinで作る必要あるのかという感じがする
正直流行ってないからね
Java出来るならJavaでいいんじゃね？
もっと新しい技術ということならelectronをお勧めしておくわ
Windows限定アプリならVisualStudioでC#は楽でいいけどね

MacといえばSwiftじゃないの？

>>104
人脈作りから始めよう。

objective cとcocoaの方が需要あるやろ

>>105-107
回答ありがとうございます。
マジですか。。。C#以外をお勧めされて複雑ですが
その言語も調べておきます。
まだC#学習して1ヶ月程度ですが機能が盛り沢山で面白いので
Macでも普及して欲しいですね(´･ω･`)

機能は盛りだくさんでもPythonやJavaの方が人気なんだよね。
それぞれ良し悪しや向き不向きがあるだろうけど。

今、統計的な素養があってPytorch触れると
月単価150万からだもんなぁ。

>>108
どうしてもC#がいいなら採用出来るかどうかは別にしてもUnityという手はあるけどね

>>110
TensorFlowでもええん？ダメなん？

これってDLL importとかしなくなるってことですか？
https://www.atmarkit.co.jp/ait/articles/2101/29/news113.html

>>113
MSが共通Wrapper作りましたってことでDLL importは必要なくなるし、アンマネージ
部分についてもお約束を守ればよくなるみたいだけど、サンプル見ると色々手続きが
面倒臭そうで使い勝手は良くなさそう

void*とかobjectにするしかないだろうしアホみたいなオーバーロードの山になるだろうし
始まる前から破綻の予感しかしない

っていうか何で今更

そもそもガンガンWin32API使うなら素直にC/C++使うし、C#だとちょっとつまみ食いする程度にしか使わんから今のままでもいいや

apiで使う構造体とかの面倒くささが無くなるならいいんじゃない？

>>112
需要と供給で単価は決まるからなぁ

Cじゃない言語でOS作り直してくれよもう

アセンブラけ？

OSのようなハードに近いレベルの言語となると、Rustが流行ってるのかな。
C#でそういうのも出来ると良いのにね。

>>113
https://dot-sharp.com/net-getdetailsof/
Shell32.dllを使うとき、com参照を追加するだけでC#のライブラリと同じ程度の手軽さで使えました
これが増えるってならいいんじゃないかな

>>118
PyTorchはずっと不人気だったのに
今調べてみたら、ここ二年ぐらいでTensorFlowと拮抗してんな
ま、いいや、どっちか使えりゃ問題ないだろ

C#をネイティブコンパイルできうようにすればいいだけだと思うが。
なぜ回り道をするのか

>>123
無理せずPaddlePaddle使ってたんでえぇで

日本では需要ないけど

>>125
PaddlePaddleはダメダメだな
日本だけじゃなくて、世界でもダメな奴

AI関連は、何を使えるかよりどこの博士号を持ってるかの方が重要なんだろ？

CNTKの求人って見ないな
https://www.bigdata-navi.com/

以前画面解像度切り替えのツールを作った時にvanaraといwin32apiのラッパー使ったな
構造体も用意してあって簡単に使えた

win32って一々ラッパー挟まずとも実はC#側で結構調節してくれるんだよな
GetProcAddressみたいなANSI版しかないような関数でもstringそのまま放り込んでもちゃんと機能してびっくりした

人はそれをマーシャリングと呼ぶのである

a={1, 2, 3, 4}という配列が与えられて
更に10進数x=5が与えられた時、5を2進数にして101なので
(最下位ビットがa[0]になります)
配列の要素1と3の和を出力せよという課題が出ました

var r = 0;
for (int i = 0; i < a.Length; i++)
if ((x & i << 1) == 0)
r += a[i];
で求める答えが出そうだと思ったのですが
4ではなく3が出ます。どこが間違っているんでしょうか

>>133
その書き方だと通るんですよね..
下のように解説してるサイトがあったのでそう書いてみたのですが
なんかおかしいんです

ビット bit に i 番目のフラグが立っているかどうか if (bit & (1<<i))

え。
>if ((x & i << 1) == 0)
>if (bit & (1<<i))

あ、やっと気づきました
bit操作理解せずに、コピペで済ませてた弊害が出ました

ありがとうございました

>>134
それはたぶんC#ではなくてCのコード
「bit & (1<<i)」この式の型は何？
Cと違ってC#のifの()の中の式はboolでなければダメ

まあこれは初心者が知らずに混乱しても仕方ないかもしれない。
でも>>132のコードの何が間違ってるかは初心者でも自分で考えれば分かるでしょ。

とりあえず問題を小さい問題に分けて分割統治することから始めましょう。
>>133はそういう意味で書きました。

Typescriptじゃインターフェース名にＩ（アイ）をつけないのが推奨されてるけど、
C#もそうなったりするのかな。

破壊的変更を.NETユーザーが受け入れてくれるなら良いんじゃね

付けろと言ってる
https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/inside-a-program/identifier-names

C#でIが取れなかったのはCOMの影響があったからとかなんとか
今更C#の方針を変えることはないだろうね

エディタで色分けしてくれればいclass, struct, interface, abstract

プリフィクスのIは字面からインターフェイスだと分かるようにしたい、という強迫神経症的な動機というより、
単純に名前のバッティングを機械的に回避できる点が大きいんじゃないの？

どうせインターフェースにIを付けなくなっても、実装クラスのいい名前が思いつかずになんとかImplってサフィックスつけるんだろ？

Delphiだと、クラスにはTypeのT、パラメータにはFieldのFを付けるんだよね。
InterfaceのIはその名残なのかな、とか思ったんだよ。
そして、そういうのは無くしていく傾向なのかな、と。

>>144
付けないよ
そんなの付けるのJavaやってたやつくらいやろ

命名規則で一番上手くいってるのはC#と思う
インターフェースにプリフィックスIをつけるから命名で困った時にImplとかやらなくてすむし
プロパティ名は大文字で始めるから小文字で始めるローカル変数とぶつかりにくいし

で、最近は名前がさらぶつかりにくくなるようにメンバ変数はm_を付けるスタイルに個人的に変更した

キャメルケースｗｗｗ

まあVSの恩恵でかいよなあって

>>147
こういう適当な名前を付けるやつがいることにピキってるっぽいね
適切な名前にすりゃブッキングしねえから名前付けをサボるなってことらしい

なるほどなぁ
ちなみにIListはなんて名前にすればより適切だと思う？

おまえ馬鹿か
たいていぶつかるのはローカル変数や外部に公開しないクラス名だろ
JavaのImpl使うのだって、内部クラスや非公開や内部のエンジンクラスとか

そんなのに適切な名前なんかブッキングできねぇよカス

>>152
Microsoftの推奨する命名規則を参考にすれば良いんじゃない？
つまり、I付きPascal形式でスペル省略不可のフルネームで名詞を表せば良いのかな。
自由に付けても良いけど、.Net Frameworkと調子を合わせると違和感が無いと思う。

うちの会社、昔から変数名の1文字目にデータ型の略称（？）をつける文化みたいで、
intのListがiListだったり、longのListがlListだったり、ちょっと困惑した。

>>156
郷に入っては郷に従え！

君の使って良い変数はI150からI300までな！
そこはFortran出身者の支配する村であった

MSの.NETプログラムにおける命名ガイドラインな
https://docs.microsoft.com/ja-jp/dotnet/standard/design-guidelines/naming-guidelines

皆さんコメント入れる？　命名規約とか守ってたらコメント要らないような気がしてきた。

>>159
いわゆるドキュメンテーションコメント的なものは入れる。
あと、実例みたいなの。
//引数にXXとYYとZZを渡したら、戻り値はAAになる。

>>159
入れる

visualstudioだとクラスやメソッドの１行前に///入力で自動補完されるからそれは使ってるかな

日付、所属、名前、旧コードはコメントに残すのが常識でしょ

ギャグかな？

バージョン管理ツール使ってるのに旧コード残すやつにはイラッとする！
特に不具合のコードをコメントアウトして残されてると、当てつけなのかと思ってしまう

コメントって入れるものだったんだ。
書くものだと思ってた。

>>159
コメントには「なぜ」を書くんだよ

なぜこんなコード書いたんですか？と書いて旧コードを残すわけですね

168が仕様を理解せずおかしな実装を
したので辻褄合わせの辞書を実装しました by 167

>>159
コメントは基本的には必要悪なので必要がない限り書かないのが正しいけど、
少なくともパブリックメンバーについては単純に「必要」かもしれんね。

ないと書いた人の意図を変に誤解してないか不安になって
結局中のコードを覗きたくなるかもしれない。
そんなことしなくて済むためのカプセル化のはずなのに

1年後に自分の書いたコード読んで、何をやっているかちゃんと理解できるならば
書かなくてもよいんじゃないかなｗ

>>171
何をやってるかなんてコード読めば解るんだから、
そんなことのためにコメントは不要
「なぜ」そんなメソッドが必要か、
「なぜ」そのデータ構造やアルゴリズムを選択したか
なんていう、コードから見えない情報を記すのがコメント

MS含めアメリカ製の高品質なコードって「なぜ」のコメントが無茶苦茶充実してるよな
日本だとだいたい // 〇〇処理 みたいな無意味なコメントか、ほとんど無いかのどちらか
SaaSとか一般的にレベル高いと思われてるはずの現場では、だいたい後者のパターンでほぼコメントが無い
根本的に論理的な言語能力に差があるんだろうなと思わざるを得ないわ

コードレビューでコメントを書けって指摘されるじゃんw

コメントなんて要らないんだよ
コミットログを見ればいいんだから

private なプロパティってフィールドにするべきですか？

>>172
言いたいことは分かるけど「何をやってるかなんてコード読めば解る」というのは
あくまで理想であって常にそうできるわけじゃない。

何をやっているか書いてくれた方がありがたい場合もあるよ。

>>176
そんなことをルールで強制する理由はないと思うよ。

>>177
何をやってるかがコメントとコードで乖離してる事があるのが問題
英語でthirteen daysって言ってるのに、
字幕には2ヶ月って書かれる戸田奈津子の翻訳みたいな事が起きうる

>>178
逆に、コメントを書かせることでコメントを書きやすいコードになるという面はあると思うよ
クラスやメンバの責務が十分に明確ならコメントと実態の乖離なんてそう起きるものではない

>>178
コメントはバグる可能性があるからコメント書くな、
なんて言ったらバグる可能性があるのはコードも同じなんだから
コードも書くなってことになっちゃうよw

「不必要なコメントは有害無益」は正しいけど、それは
必要なコメントを否定する根拠にはなりえない。

>>180
コメントがバグるって話じゃなく、
書いた人の「つもり」がコメントとして残るのが危うい
実行時にどう動くかを決めるのは、コメントではなくコードなのだから、
コメントを読んでコードを読んだつもりになれるのも危うい

入門書の多くがコメントの書き方を蔑ろにしてるのが元凶だと思うんだよね
ほぼ単なるメモ機能としての記載しかされてない

続いちゃったので議論スレに移します
http://2chb.net/r/tech/1469538912/82

「コードを読めば何してるか分かる」のだから、メンテ忘れで誤ったコメントが残ったとしても問題ないとも言える。
・・・たまにブチ切れたくなることがあるけどな。

>>182
あれは解説を見ないとプログラムが理解できない人向けの本なんだからそれをコメントに書くのは当たり前じゃん

>>184
> 「コードを読めば何してるか分かる」
ならコメントなんていらんだろw

>>172
YOLOv5をC#に移植して内容を説明しては
くれまいか？

そんなに簡単な話なら誰も論文なんて読まないよ〜 :-p

ドキュメント代わりにしてるから入れる
///<summry>
の形式のやつ

doxygenで出力してモジュール設計書として納品して一丁上がり

クラス図もシーケンス図もねぇのになにいってんだこのバカ

>>186
だから要らないって話だろ
var hoge = items.First();
で最初の要素を取得するなんてコメントは要らん
記載するならwhy何故取得するのかだけ書けばいい

もし動作について記載したくなったなら、それはメソッド化するとかを検討した方がいい

>>190
だからと言って
> メンテ忘れで誤ったコメントが残ったとしても問題ないとも言える。
ってアホだろ、って言う指摘なんだが…w

それはアホだけどコメント入らないも的外れって指摘なんだが

>>192
>>184の全文読んでから出直してこいよw

宗教が合わないと作成者本人が綺麗に作ったつもりでも読みにくくてしょうがないからブロック毎に動作の概要ぐらいはコメントで書いといて欲しいわ

なんだよ、せっかく議論スレに移ったのについてきてねーじゃん
正直者が馬鹿を見る世界
もう移らん、絶対移らん（笑）

俺はコメント入れてほしい派

読めば判るっつってもさ、
コード書いてる本人ですら
何やってるか分かってない場合もあるからな（笑）
せめてコメントで
「ここではこんなことをしてる（つもり）」
って書いてくれら「全然そうなってないだろ！」と突っ込める

xxxInternal
xxxPublic
xxxOverride

パワーポイントやエクセル内の文字列を検索するクラスってありますか？
windowsの検索窓ではなく…

>>197
Windows Searchを使えば検索窓と同等の機能がプログラムから使える

>>198
素早い回答ありがとうございます！
そんなのあったのですね！検索力不足を痛感しました…
調べてみます。

議論スレに移れないってことは、
コメント付けたところで読めない無能だから無意味って証明になったな

>>200
何度も言うけど、真の無能はそれが自分を棚上げした物言いである、
という簡単な事実に気づく程度のこともできないお方だよ。

これ割とマジで大丈夫かと思うわ

ついでに、これも何度も言ってるが、そんなくだらない「交通整理」に誰も従わないのは
「交通整理」の欺瞞性とそれを主張している人間の卑しい動機に普通は気が付くから。

>>202
卑しい動機って何？

他人を見下し自分が主導権を握りたいという自分勝手な承認欲求が行動原理

>>202
暴れて飛行機から下ろされ
飲食店で入店拒否されて暴れて警察を呼ばれ
警察を殴った誰かはTwitterで同じこと言ってたなｗ

>>193
その 184 だけど。w
「コードを読めば何してるか分かる」な人は、そもそもコメントがなくてもいいんだから、書かれていても無視すればいい。
コメントが欲しい人は、コメントの弊害(メンテ忘れとか)の現状を承知の上でそう言ってるんだから、そもそも問題ない。

つまり、コメントがいる／いらないの論争は無意味だからやめとけってことなんだよ。
その上で「コードを読めば何してるか分かる」ように丁寧な書き方を目指せば済むことじゃん。

まあ自分はブロックと言うか処理単位でのコメントは出来るだけ書くけど。

だってコメント邪魔なんだもん

・コメントがあるとノイズになり視認性が落ちる
・コメントには嘘が混ざっていたり情報が欠落していることがあるので常にコードとコメントの整合性を確認しながら読まなくてはならない
・コメントに嘘を混ぜたり情報を欠落させないために細心の注意を払わないとコードを更新できなくなる

これは茶化しで書くけど。
コメントがなければストレスなく読める美しいコードなんて見たことないなあ。

>>206
> つまり、コメントがいる／いらないの論争は無意味だからやめとけってことなんだよ。
誰もそんな論争してませんよ…
もしかして>>186をコメント不要という主張だと思ったのか？w

そーなのか。
じゃあバカな私に分かるようにおまえ様の主張をきちんと述べてみてくれ。

>>211
>> メンテ忘れで誤ったコメントが残ったとしても問題ないとも言える。
> ってアホだろ、って言う指摘なんだが…w

改修履歴をコメントで残すとかいうのさえなけりゃ
他のコメントはコード読むのに邪魔になりはしない

>>211
>>183

必要だからどの言語もコメント機能が有るのでは？

言語ではないけどjsonってのが有ってだな

>>209
ほんこれ

>>216
あれなぜコメントの機能を持たせないのか不思議だわ
{
"$comment": "コメント"
}
みたいな形でコメント書くという方法もあるみたいだけど気持ち悪いし

最初に作った人が「コレはデータだからコメント不要」って取り付く島もないんだとか
VsCodeの設定ファイルみたく独自で拡張してjsonもどきになっているよな

jsonなんて人間の読めるもんじゃないと思う
ダブルコーテーションが目にキツイ

>>218
JSON自体は仕様がもう確定してるから。
jsoncとかJSON5とかRelaxed JSONとか拡張した別仕様ならある。

json便利だけど、protobufを使うようになってから使用頻度減ったなー

１つの一連の処理で一度に10回以上は失敗する可能性があるんだけど
例外って複数ストックできる？

できるよ
ValidationでエラーためてIsValidで確認するのと同じ

try{
...
}catch(Exception ex){
exceptions.Add(ex);
}finally{
continue;
}

こんな糞コード見たことないけどな。

デーモンコアと
マイナスドライバーを設定
try{
while(米が勝つまで回す){
�@測る
�Aマイナスドライバーを動かす
}
}
finally
{
�Bデーモンコアを離す
�Cif(青い光りが見えた){
�Dみんなを退避
�E逃げる
�F救急車を呼ぶ
�G遺書を書く
}
}

大体こんな処理なんだけど
�B〜�Gは途中で例外起きても
最後までやってほしいらしい
っていう一連の処理なんだ
どのエラーや例外も全部保存したい

>>224
なんかサンプルないですかね？

溜めておいた例外を最後にAggregateExceptionのInnnerExceptionsにセットして投げれば

>>227
なんかそういう処理の書き方の流れが知りたい感じです

年内に死にそう

NlogつかってファイルかDBに残すのが現実的じゃね？
https://nlog-project.org/
こんなやつ

>>223
失敗してても処理が継続される時点でそれを例外を呼ぶべきか、そもそも疑問に感じるね。

DirectoryInfo.GetDirectories は例外を送出するけど処理は継続する

まあ、結論としては
c#的にはこういう複数の処理が失敗するまたは終了処理も失敗するケースは言語的には完全に想定外ってことですかね

>>234
そもそも一体何をしたいのかさっぱりわからん
記録したいだけなのか失敗毎になにか処理したいのか

>>235
1メソッドでたくさん失敗するんです
でも例外って1つしか返せないじゃないですか？

>>234
地道に処理毎にtry{}catch(){}で囲めばいいだけ
言語のせいにするのはお門違い

>>237
そもそも例外で返すのが間違いということでしょうか？

>>238
<1>
var exceptions = new List<Exception>();

<2> (処理の数だけ作る)
try
{
　処理
}
catch( Exception e )
{
exceptions.Add( e );
}

<3>
throw new AggregateException( exceptions );

>>239
ありがとうございます
それって受け側ってどう書くんでしょうか？

>>240
受け側って何を指すのかわからないけどエラーをcatchしておいて投げなおしているだけじゃね
>>230の考え方でエラー起こるたびに「〜の処理中に〜のエラーが起きました」って全部記録する形から作っていけば？
エラー発生しても続行させる処理の方が大変になると思うしとりあえず一通り作ってみた方がいい

>>236
だから受け側で何をしたいんだよ…

>>241
普通に

try
{
}
catch(exception ex)
{
}

でaggregateexceptionってキャッチできますか？

簡単なサンプルで試してみればいいでしょ…

たぶん欲しいのはエラーのログなんだろうね。
あるいはPOSTでやるようなチェックリスト？

例外オブジェクトをエラーを表す目的で使ってもいいとは思うけど、
何がしたいのか目的をはっきりさせずに「例外をストックできるか？」とか質問するから
みんな混乱する。

なぜかこういう人は何をしたいのか書かないんだよな…
まあもういいや、相手もしてもしょうがなさそうだし

>>243
それで出来るけど、catch( AggregateException ex )で受けた方が
AggregateException.InnerExceptionsを参照しやすくていいんじゃない

>>246
正直
俺もよくわからない（笑）

>>247
ありがとうございます
受け側はなんの例外がくるかしらないんですよ多分

例外を見ればどの処理で発生した例外なのか確実に分かる場合はいいけど
そうじゃないならList<Exception>だとたぶん困るよね

>>250
どこで発生した例外かを知りたいなら例外にその情報を入れとけば良いだけだろ

>>251
>>239の例ではそれをやってないから困るんじゃねって話なんだけどさ

>>252
ExceptionでもSourceに入れるとかMessageの一部に入れるとかやりようはいくらでもあるだろ

エスパー回答すると、Disposeをしっかり作ってusingを使え、が顧客が本当に欲しかったもの

C#の話と関係無いかもしれませんが、パッケージの開発環境って今の時代何がありますか？
完全にオフラインで使える開発環境とかって無いんでしょうか？コマンドプロンプトしか無いんでしょうか？

落ち着け(´･ω･`)
パッケージ、開発環境、コマンドプロンプト
全然話が繋がっていない

開発環境と言われても困るな
聞きたいのはここら辺？
https://it-kyujin.jp/article/detail/1512/

なんとなくエスパーすると、開発ソフトをインストールさえすれば、その後はネット非接続で何でも開発出来る環境が理想ってこと？
なら、たぶん無い。

.net sdk使って、標準ライブラリだけ使うなら出来るんかな？
結局必要なライブラリやらランタイムをDLするか、他のPCでDLして開発PCに入れる事になりそうだけど。

>>258
待て待て、標準ライブラリだけでもオフラインで開発できるなら、回答しては「Ｙｅｓ」じゃないか？
特に、その「他のPCでDLして開発PCに入れる事になりそうだけど」が出来るんだしさ

>>255
目的を話せ
俺のエスパー能力をフル発揮すると、
セキュリティ上、スタンドアローンで動かさんといかんPCがあって、そこで開発したいだよな？

>>258
ありがとうございます！！！
環境を自分で作る以外ないんですかね。無謀すぎますね。
コンパイラ作るわけじゃないですからね統合環境は。
>>259
そうそう単にセキュリティの心配です。
オフラインだと全く外部に漏れる心配ないわけじゃないですか。
めちゃくちゃ安心するじゃないですか。

何でインターネットに繋いでないとプログラミング環境が整わないような
状況なんでしょうか？どう考えたってオフラインのほうがよくないですか？

今はネットワーク繋いでなんぼの時代だから

そういうセキュリティの気にし方をするのであれば、普段使いのPCとは別に
個人情報を一切入れないPCを１台用意して開発勉強専用にするのが一番安心できると思うよ
外に漏れて困るようなレベルのコードを書くならダメだけどさ

というかMicrosoftDocsやGitHubやStackOverflow/Qiitaとか一切閲覧できない環境で
NuGetやNPMに登録されてる出来合いのライブラリもまったく利用しない縛りを入れて
自分の能力だけで1から100までコードを書けるなんてすごいなあ
俺にはそんな縛りプレイしてたらとてもじゃないけど開発にならないや

インターネットにつながっていないが故に管理がおろそかになってパッチ適用がされない弊害の方がやっかい
日立のランサムウェアなんかはまさにそれ

構造体(値型)を関数の参照渡し以外で、参照する方法ってありますでしょうか？
配列の構造体にアクセスするコードを書いているのですが、
逐一配列の添字計算が入るのも嫌なので避けたいと思っています。
添字の数は関数の中では変わりません。
今は関数の参照渡しで使っていますが、他に方法は無いのかなと思いまして。

>>264
refローカル変数じゃあかんの？

>>264
理想形が見えねぇ

配列の構造体って何？

>>264
策士策に溺れてはいけない
愚直に一時変数を使いましょう

>>265
ref ってローカル変数に使えるんですね！
前に軽く試した時には右辺値にしかrefを記載してなかったので、
左辺の定義にもrefを記載すれば行けました。
有難うございました！

オフライン環境での開発だけど、
VS Community2019のオフラインインストーラをダウンロードして
オフライン環境に持ち込んで使ってる
c#でフォームのデスクトップアプリしか作らんので特に困ってない

>>264
var p = &array[5];

ゆう君みたいにCSCで開発するのだ

>>270
バグや脆弱性対応は？VS2019って頻繁に更新されてるけど

>>273
offlineインストーラーも知らないのは開発者としてどうかと思う

getsetプロパティをFuncで呼び出せるようにしたいのですが可能でしょうか？
メソッドで括って呼び出せば良いのだろうけど直接Funcに入れる方法があるならそうしたいです

よく分からん
Func<string> func = () => person.Name;
を
Func<string> func = person.Name;
みたいに書きたいってことか？　無理だけど
func = person.Name.Surname;
のときperson.Nameがいつ解決されるのか判断つかないし

>>276
返信ありがとうございます

イメージとしては複数のクラスで
public bool hoge {set => test = value; }
が複数あって
List<Func<bool, bool>> func;
に追加していってキャンセルとか何らかの処理後に一括して戻したい、と言うような処理です

やはりプロパティってメソッドみたくできないFuncに入れる事ができないんでしょうか
他の方法ですっきりする方法はないですかね？

やりたいことがさっぱりわからんな
ダイアログのキャンセル押したら画面ごと破棄でいいじゃん

>>277
List<Action<bool>> list;
list.Add(b => hoge = b);
こういうこと？

まあ気持ちはわかる
(Webでなく)GUIアプリで独学した初心者って、エンティティオブジェクトをアプリ全体で生存させるような設計をしちゃうんだよな
オブジェクト指向を普通に解釈すりゃそれが自然なんだけど、実際そういう設計はしないんだよ
ドメインモデルだろうとトランザクションスクリプトだろうと、エンティティはトランザクション毎に作る

>>274
知らないって決めつけてるのはどうかと思う
単にどうしてるのか聞いているだけ

>>278破棄と生成できれば良いのですがちょっと難しい。ユーザーコントロールでバインドしていて各コントロールは値を参照しあってます
今回は画面が切り替わったときに表示非表示を変える戻す、なので直接は関係ないのですが影響度を減らしたい
>>279
>>276見直してプロパティを直接でなくてもラムダ式でいけそうなことに気付き>>279さんの形を思い浮かびました、今出掛けてるので確認は後ですが多分解決できそうです

皆様ありがとうございます
解決しなければまた聞くかもです
ありがとうございます

>>281
知ってて聞くのはもっとどうかと思う

>>282
なんだかとってもおかしいよ

これあれじゃね？
開始日と終了日に期間制限があると値が設定できないやつ（笑）

何がしたいのかよく分からないね。

キャンセル要求が発生したら初期状態に戻したいなら
素直に初期状態をまるごとキャッシュしておく方が分かりやすいんじゃないかと思うけど

もっと素直なのはそもそもApplyするまでUIの値をモデルに反映しないことだよね。

まあたぶん要件を説明しきれてないんだろうけど

>>282
元に戻す処理を管理したほうがいいケースなのか
元の状態を管理したほうがいいケースなのかを考えたほうがいいよ

まあ、設定画面がモードレスでリアルタイムで値を変えたいときもあるかもしれんが
それやると
地獄の一丁目にご招待って感じ（笑）

Contract?

>>288
更にundo/redoの機能を付けてくれまいか？

で更なる深淵へw

>>290
影響する値でエラーが出てもそれとは関係ない表示はできる限り続けて欲しい（プレビューが見えないから）
エラーが出てるときは値の変更で表示は変わっても最後の反映はできないようにしてほしい
でも値を変更してる最中のundo,redoは効くようにして欲しい

って割とありがち要求だよね

モードレスやった時点で地獄を覚悟しろって感じ

そのためのMVVMですから！

>>283
めんどくさいのに本当にしてるのか気になったから聞いたんだけど何かおかしい？

うちにも本当にしてる端末はあるぞ。
むしろ自動で上げたくないしな。
既知の問題でワークアラウンドがあるならそれで良いというケースもあるし。
リリースノートめちゃくちゃ読む。

>>293
ネットに繋げないならそうするしかないし言うほど面倒でもないだろ
そもそもネットに繋いでる場合でもアップデートがある度に適用なんてしないよ
>>294が書いてるように修正内容見て影響ないとかワークアラウンドがあるなら適用しない

オフラインがめんどうとか何言ってんの？開発する時にはセキュリティ上当然やろ
オンラインとか最近の開発ではありえない

今のVSって最新メジャーバージョンは完全に人柱向けだからなあ
アップデートをすぐに入れられないような環境だと詰む可能性があるからむしろリスクが大きい
最新版を追えない環境なら2017使ったほうがいいよ

更新頻度はどちらも大して変わらん

https://docs.microsoft.com/ja-jp/visualstudio/releases/2019/release-notes#visual-studio-2019-version-169-releases

https://docs.microsoft.com/ja-jp/visualstudio/releasenotes/vs2017-relnotes#visual-studio-2017-version-159-releases

>>298
中身読めよ
2017の方は脆弱性修正と軽微なバグ修正しかやってない

docker「…」

C#を勉強中です
Delegateの機能はわかったのですが、これはどのような状況で使うのか思いつきません
こう使うと便利だという例を教えてください

それは繊細な問題ですね

delegateの機能が解説されていた箇所に書いてなかったの？書いてあったけどそれを理解できないってこと？

>>301
そのわかったというDelegateの機能を説明してみてもらってもいい？

>>301
真面目な話、無理に今理解しようとしなくていいと思うよ。
コード書き出ぜば自然に分かる。
後回しにして先に進んだ方が吉。

>>303
機能の解説だけでどのようなときに使うかは書いてなかったです

Delegate型の説明と作り方の後に例としてConsole.WriteLineでHelloと表示するメソッドを
新たに作ったDelegate型のaという変数に突っ込んでa()を実行して
ほら表示できたでしょという感じだったのだけれど
だからどうしたとしか思わなかったです

自分も変数のシャドーイングとか何が便利なのかわからないです
脳みそのメモリ圧迫されるのでは

>>306
こういうメソッドの引数がデリゲートで、まさに便利な使い方だと思ってる
https://docs.microsoft.com/ja-jp/dotnet/api/system.collections.generic.list-1.removeall?view=net-5.0

間違ってたら訂正よろしくです

>>308
これがdelegateだとしたら意識しないで使ってました
まさかこれが..

デリゲートは自分で使うもんじゃないと思ってた。
Buttonをクリックしたら、このメソッド実行してねってのを、IDEが作ってくれる奴だから。

だから、「こんなときどうしよう」って悩んだときに、
そうだ！デレゲートってのがあるんだよ！っていう、よっぽどの場合に、入門書を読めば良いと思う。
初めてのC#みたいな本がお薦めなんだけどね。

>>306
試しにhello2 からhello100まで突っ込んでみよう

デリゲート定期

デリケートに好きして

>>306
わからなかったらまず最初にリファレンスを読むといい
Delegateとは何かどういう目的で使われるのか普通に書いてる
https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/delegates/

まあこういうものが腹に落ちるようになるのが楽しいとこでもある

>>313
パジャマのままで

例えば、Ruby では、Forwardable でインスタンス変数に委譲できる

自分で配列クラスから、Stack を作って、その内のpush, pop だけを使いたい場合、
もし配列を継承・is-a すると、余計なメソッドまで継承してしまうので、それらを使いたくない。
そういう場合に、委譲・has-a で、インスタンス変数に委譲して、使うメソッドも限定できる

Go, Elixir も継承がない、委譲だけ。
継承は大掛かり。
使わないメソッドを呼ばれてしまう可能性があるから

また、誰でも使うような、String クラスなどを継承して、メソッドを追加されるのも嫌。
そういう継承は想定外だから

素人は、よくそういう事をする。
継承用のクラスじゃないのに継承したりする

require 'forwardable'

class Stack
extend Forwardable

def initialize( ) @ary = [ ] end
def_delegators( :@ary, :push, :pop )
end

stack = Stack.new
stack.push 1
stack.push 2
stack.pop

p stack #=> #<Stack: @ary=[1]>

>>307
shadowing とは、内外の変数は、別々の扱いで、
内側のスコープに入ると、内側が優先されて、
外側の同じ変数名が隠されること。
その際、外側の変数には影響を与えない。

Ruby では、外側のa は10で、内側のブロックスコープでは、
同名の変数aを使っても、外側の変数には影響を与えない。
ブロックスコープを抜けると、aは10のまま

a = 10
ary = [ 1, 2 ]

ary.each do |a|
puts "ブロック内: #{ a }"
end

p a

出力
ブロック内: 1
ブロック内: 2
10

このスレはRubyの宝石箱や！まで読んだ。

火入れするかあんたのはスピネルや
と言うべきか

なにかのネタというかエンジニアジョークなのかな？　わからないや

シャドーイングがどんな機能なのかは単純だからわかってるつもりだけど、一見同じ変数名を扱えることで何が嬉しいの？って話です
コード読んでて混乱しそうなので無い方が綺麗だと思うのだが、自分の脳みそが貧弱なだけかな？

c から来た人なんだけど、デリゲートって関数ポインターの認識

半角の＋＋が書き込めない。なんだこれ。

>>322
それがリストになっているので
複数の呼び出しを一気に行える。
という感じ

メモリリークの温床だがな。。

>>321
嬉しいでしょ。
まあぶっちゃけフィールドをローカル変数で隠蔽することはあまりないと思うけどね。

>>322
Cより機械語レベルで考えた方が分かりやすいね。
要はcall命令のオペランドだよね
厳密にはthisポインタの情報を含むから違うんだろうけど概念的には

初歩的な質問ですいません
オブジェクト初期化子とコンストラクタは何が違うんでしょうか？
やってることは同じのように感じるのですが…

>>324
デリケートって追加や削除されるたびに全リストコピーしてるんだっけ？
ぶっちゃけ効率考えたらデリケートよりインターフェースをリストで持たせた方が効率はいいよね

どいつもこいつもデリケートデリケートってよお！

♪シーズソーデリケート（デリケート、デリケート）

>>327
初期化子は参照側が任意に行う。代入しか出来ない。
コンストラクタはオブジェクト側が初期化のルールを決めて、ロジックが書ける。
ってことじゃないのかな。

>>327
コンストラクタにはそのオブェクトを生成するために必要なものを渡してる
初期化子は特に生成には関係ないない項目にも初期値を設定してるイメージ
使う側はあまり気にしなくていいけど用意する側は意識しといた方がいいよ

>>327
初期化子はフィールド単体に対しての初期化で、コンストラクタはクラス全体に対しての初期化って考えたらイメージしやすいかも
まあ、初期化子を指定しない場合でも、def aultで初期化されるんだけどね

>>327
そもそも問題設定が間違っていると思うよ。
正しい問題設定は「オブジェクト初期化子って何？」

オブジェクト初期化子とは、コンストラクタ呼び出しと、複数の任意のプロパティーやフィールドへの
値の設定をインラインで書けるようにした糖衣構文。

>>326
実を言うとnull safetyのせいで隠蔽したくなるんだな

もちろん、別の名前つければいいけど

C#に限らずnull safetyの言語で、特にビューモデルのクラスでnullableなフィールドを宣言する機会が多いいんだが、
フィールドはメソッド内でnullチェックしても非nullableに昇格しない(kotlinでいうスマートキャストが効かない)
から、
if (field == null)
　throw new IllegalState
var field = field!; // わざわざnon nullableなローカル変数に代入で、ローカル変数に適当な名前が思い付かないのでフィールド名と同じ名前で隠蔽

メソッド内で1,2回とか参照しないのであればわざわざnon nullableなローカル変数に代入しないが

特にkotlinとかスコープ演算子とかもあるがkotlinは｢!!｣と二重だからこれがいっぱい現れるとソースが見苦しい...

>>333
違うだろ。C#ならフィールドとプロパティをきちんと区別しないといかん。

x = a ?? b; ←null合体演算子

x.?method() ←これなんて言うんだっけ？

ピリオドとクエスチョンの位置逆だけどnull条件演算子

linuxとwindowsで動くguiソフト作りたいんですが、共通の開発環境と言語ってあるでしょうか？
openglを扱ってみたいのですが、c++とqtが多いんでしょうか？
c++を扱うと思うので、erectronやwxpythonなどは除外されるんでしょうかね。

>>341
C++の話をするのに何故C#のスレに来たの？

>>339
逆にnullだったらそのままにしたいってことが多いんだけどそういう演算子ないよね

int? x = null;
int? 2x = (x == null ) ? null : (2 * x);

みたいな

opengl関係無いアプリも作りたいので(´・ω・`)
ｃ＃は恐らくlinuxでは動かないものですよね

>>343
nullだったらメソッドやプロパティにアクセスせずnullを返すのがnull条件演算子(?.)
そのint?のケースは単に`2 * x`でnullが返されるようになってる

>>344
人脈があれば出来るぞ

>>344
Unityならwindowsでもlinuxでも動くはず

.NET MAUIがそういうの目指してるんだろうけれど…

>>347
unityをguiアプリ開発に使いませんよね　普通

>>349
mono 使えばいいんじゃないの？

>>345
条件演算子を使えないパターンの例をあげたつもりだったんだけどそういう動作すんのか
x.method()に対応するならmethod(x);にも対応してくれてもいいのにって思った

>>350
monoやxamarinはc#ですよね。
c#製アプリはlinuxで動かないと効かされていましたが。
あと、openglなので、c++ではないですか？

.net core も動くぞ

釣りだろ

なんでも釣りって言わないで

なんでguiにunity勧める奴いるのｗ

何にでもRuby勧める奴もいるだろ

まあC#スレでC++連呼してるのは釣りか底抜けのバカのどちらかだからいずれにせよスルーが基本かと

c#でPCがアイドル状態か否か判定したくて
マウスの動きが一定時間なしで判定するのは出来たんだけど
マウスを動かさずブラウザで動画再生しているときにもアイドル状態ではない判定にしたいんだけど
どうすれば判定取れるでしょうか

特定のキー押下でアイドル判定されない状態を追加して置いた方が今後楽じゃないかな？

メディアプレイヤーの類で動画再生は構わないの？
ブラウザのバックグランドタブで再生中の場合は？

一応各プロセス各スレッドがSetExecutionStateした結果のステートはこんな感じで取れるらしい
https://stackoverflow.com/questions/10970625/how-windows-decides-to-show-the-screensave

SetThreadExecutionStateだった

その他の案
スクリーンセーバーのプロセスをトリガに利用にする
例えば「ブランク」のスクリーンセーバーが起動してたら、
「scrnsave.scr」がプロセス一覧から取得できる(はず)
つまり*.scrが動いてたら確実にアイドル状態と判断できる
この方法はスクリーンセーバーを無効にしてたら意味ないけど、それはレジストリから判断できるはず
問題はアイドル+スクリーンセーバーの起動時間まで待つ必要がある事

つ WM _ enteridle

タスクスケジューラでアイドル状態を条件にプログラムを起動できる
コードから直接利用する方法があるかどうかは知らない

>>359
率直に言って無理がある気が。

結局システムで正式に定義されたステートじゃないと
今たまたま何か方法を見つけ出してもいつまでそれが使えるか
わかんないよね。

スリープを抑止するプログラムが起動しているかどうかで
判定できないかとも思ったけど、ブラウザの動画再生は
たぶんスリープ抑止しないよね知らんけど

SetThreadExecutionStateを試してみます

>>360
同じような機能入れてたけど設定し忘れ&解除し忘れで意味なかったです

GetLastInputInfo

>>361 でよさそう(未確認)
>>368 GetLastInputInfo は数ヶ月前10で試したけどうまくいかなかった

.NETで文字列の見た目の幅を求めるライブラリってある？
等幅フォント前提で半角英数なら1文字分、全角漢字なら2文字分、、、といったように計算したい

https://dobon.net/vb/dotnet/graphics/measurestring.html
これじゃだめなの？

>>370
シフトJISでエンコードした時のバイト数を数えればいいと思うけど
今時そんなの何に使うの？

>>371
ありがとう
でもできればプラットフォーム依存しないほうがいい

>>372
Markdownのテーブルをフォーマットしたり色々です

絵文字やサロゲートペアも考え出すとめちゃめちゃめんどくさいよね

>>370
雑にやるなら、StringInfo.ParseCombiningCharacters2倍して、半角文字の文字数引いたら良いんじゃないの？
アクセント付き文字も半角文字に入れればそれなりに並ぶんでは？

タイ語とかアラビア語まで考える？

MeasureStringの数字を見ながら、頭がウニになったGDI+の思い出
勝手に文字の大きさ計算してくれるwpfの有り難さよ

>>370
wcwidthとかeast asian widthで検索してみるといいと思う
https://www.nuget.org/packages/EastAsianWidthDotNet

>>375
情報ども
とりあえず日本語対応できればいいかなと

>>377
あざす
これたぶん正解っぽいすね

Markdownのテーブルっていうのが何かよく分からないけど、
細かいこと言えば等幅フォントであってもどの文字がどの幅で
描画されるかはフォントに依存するはずだと思うので、（一般的に半角の文字だと
されているものが半分の幅で描画される保証なんて実はないんじゃないか？）
グラフィック関係なら>>371みたいに実測するのが一番確実だよね

同じ文字で同じ等幅フォントで表示しても、アプリによって全角/半角相違することもあるよ
MS製品間でもVisualStudio/Officeで幅が一致しなくて以前困った記憶がある

httpclientでpostした時にレスポンスヘッダーのlocationが取れないんだけど取る方法なかんかな

HttpClientをnewするときに渡すHttpClientHandler(.NET Core/5ならSocketsHttpHandler)の
AllowAutoRedirectをfalseにすればいけるような

>>382
できたわ
サンクス

パネルに貼り付けているlabelの数を数えることってできませんか？

テキストファイルの1行目ならlabel1へ表示するってな感じにしたいのですが、
行数が少なければ↓でいいんですが、

label1.Text = File.ReadLines(FileName).Skip(0).Take(1).First();

数が多くなるとコードが長くなって修正等に時間がかかると思うんですよ。
そこでラベルの数が数えられるなら繰り返し文を使えばコードがスッキリするんじゃないかと思ったんです。
良い案のある方いらっしゃいましたらレスをお願いします。

>>384
controlsっているじゃん？

>>384
var count = this.panel1.Controls.Cast<Control>().Count( x => x is Label );

>>386
Controlにキャストする必要あるのか
つかOfTypeで良いんじゃねえのか

ちなみにControlsの列挙順って一定なのか？

>>387
思わずCastで書いちゃったけど、OfTypeの方がいいね

男だったらキャストして突っ張り続けろよ

>>387
designerの登録順に依存するけどイジるたびに変更を確認するの馬鹿馬鹿しいから
自分はコントロール名やタブ順で並び替えてる

>>390
(デザイナーでの)登録順ってのは「保障」されているのか？って話なんだが
ディクショナリとか一見登録順に見えても、それは条件が良いだけか実装依存な場合がほとんどだぞ

まあデザイナの定義もVSでいじるとどう変わるかわからんけどな

>>391
自分で調べもせずに何でそんなに偉そうなんだw
Control.ControlCollectionはIListインターフェースを実装してるとDocsに書いてある

>>388
いやCastの方がいいよ
失敗しない確信を持ってるんだから

>>384
なんかやりたいことと質問の内容が噛み合ってないような気がw

n番目のLabelにn行目の内容を表示したいんだったら
欲しいのはLabesの数じゃなくてIEnumerable<Label>とかじゃないの？

っていうかそういう目的ならLabelじゃなくてListViewとか使った方がいいんじゃないの？w

MVVMならもっと楽だったな

皆様回答ありがとうございます。
Controlsプロパティに関しましては↓に
https://www.atmarkit.co.jp/fdotnet/dotnettips/224controls/controls.html
＞PanelコントロールやGroupBoxコントロールなどを利用している場合には、フォームのControlsプロパティからすべてのコントロールにアクセスできるわけではない。

と書いていたのでスルーしていました。

>>394
まだ入門書を終わったばっかりでなにが正しいのかわかｒない状態なので、変な感じなってるっぽいです。
ご指摘ありがとうございます。


とりあえずやりたいことはできたので、皆様本当にありがとうございました。

>>396
一応釘を刺しておくけど、コントロール名を変えるだけで動かなくなるような実装にならないよう気をつけてね

>>397
横からすみません。
そういう事態を避けるにはどういう実装にすればいいでしょうか。

Nameプロパティを見ない処理にすればよくね？

>>399
現在、ToolStripのクリックされたボタンをNameで判別してます。
if(e.ClickedItem.Name == "") { }

この場合、Name以外のプロパティを使うようにするだけでいいでしょうか。

>>400
Nameじゃなきゃいいわけじゃないよ
じゃあTextで″削除″だった時にって分岐をすると、後にダイアログを出すから″削除...″に修正しなきゃってなって動かなくなる
派生してカスタムコントロールを作るとかTagを利用するとかが一般的かな

>>400
どのプロパティーを使おうが、そのコードを書いた時と違う値が設定されてしまったら
識別子として使えないのは同じじゃないの？w

素直に「クリックされたのは○○か？」を検査するコードを書けばいい。
if (e.ClickedItem == hogeButton) { ... }

そもそもボタン自身のイベントを使えば何がクリックされたか識別するコードを書く必要がない

ありがとうございます。

>>402
以前、その方式でやっていたのですが、理由あってToolStripと、そのコンテナになるFormを別にした結果、以下のコードになってしまいました。
結果、FormからMenuItemを直接参照出来なくなりました。
https://ideone.com/dlhYMG

対策的に、別途、MenuItemの一覧のenumと、クリックされたItemを伝播するイベントを作りました。
https://ideone.com/da5kPY

ただし、この場合はMenuItemを追加する時に、enumに要素を追加する必要がありますが、
enumは定数なので、アプリ使用中にItem追加した際、enumにそのボタンを登録出来ないのです。

それで結局Nameを参照するようになりました・・・

>>404
それで行きます！ありがとうございます！

動的にオブジェクト追加してるならそのオブジェクトの参照は持ってるはずだから
Nameプロパティとか見る必要ないはずだが

言語の機能でインスタンスを特定しようとするのはギルティ
だいたい作っていくと痛い目にあう

>>405
本来はToolStrip自身じゃなくて、ToolStripやMenuStripを持った
Formを継承した方がいいような気もするけどね。
まあそれじゃ満たせない要件なのかもしれないけど。

でもToolStripやMenuStripってFormの継承と相性悪いんだよな確か。
修正されずに放置されてるバグがてんこ盛りだった気がする

>>397-408
入門書がNameプロパティでの判別をしていたので、当たり前のようにやっていましたが、
あまりよくないやり方なんですね。
ありがとうございます。勉強になりました。

>>409
よくないかどうかは状況次第だと思う。
自分や他人がコントロールのNameを変更した時に、判定する側もきちんと変更すれば問題ないはず。
そもそも変更しないなら問題になることもないし。

>>410
「〇〇を変更した時には××も変更すべし」みたいな自明じゃないルールが存在すると、
そのルールをコードを保守する人が忘れているか知らない場合には
正常に動作しなくなるリスクが発生していることになる。

プログラミングの目的は要件を満たすことなので、他に手段がなければ
あえてそういうリスクのある方法を採用することはあってもいいけど、
今の話は明らかにそうじゃない

Windows,LInux,Macで動作するものを作る場合は.Net coreとmonoどっちがおすすめですか？

今からなら.NET 5 (.NET Coreの後継)
今年中には更に後継の.NET 6が登場予定
.NET Coreは既に終了済、monoはモバイル向け(.NET 6に統合される予定)

なんか次々思い付いてはゴミのように捨てていくよな

そうなんですね
.NET 5調べてみます！

.NET Core 3.1の次バージョンを.NET 5とリネームしただけだから.NET Coreが終わったわけじゃない

>>413
既に終了済み？？

インターフェースや抽象クラスのメリットとは？

つまりvirtualで処理をかかない純粋仮想関数を作る意味はあるのかということです。

そもそもvirtual指定するのであればデフォルト処理というものを書いておけば必要に応じてオーバーライドすればよいと思うのですが。

>>418
>インターフェイス
多重継承

>抽象クラス
デフォルト処理が決まらないメソッドを継承先でオーバーライドで強要する

>>419
ありがと、
めちゃわかりやすかった。

ちゃんとifやcase文で書いた方が実は後で楽だけどね
使うかどうかはかっちょええかどうかである場合が多い

将来的にスパゲティ化することを防ぐために多少手間でもインタフェースや抽象クラスを使って制約を設けるもんじゃないの？

そういうのは大抵、いざ要件が増えたときには、今の引数だけでは〇〇の情報が足りないとか、拡張を想定していなかった部分を拡張しなければならなくなったとかで破綻するんだよ
要件にないなら後で実際に拡張が必要になってからリファクタリングした方がよい

俺は>>422派だな。
要件が増えたときにパラメータが増えたとしても、ファクトリーに渡す拡張用の値増やすだけで元の処理に手を入れなくていいから

もしかして抽象クラスとインターフェースって使う必要ない？
メリットはスパゲティコードにしない制約を追加するだけで有れば設計ミスの方じゃないか？

>>425
まあでも知ってると他の誰かが使ったときに欠点がわかるよ
下地がそうやってできてるのにそれに逆らって作ってもしゃーないし
合わせるのは大事

ただメリットはよくわからん
List<object>やobject型の悪用とあんま変わらん気がする
落ちてもどこで落ちたかわからんのもいっしょ

>>425
同時平行開発するときは有用だな

interfaceはこのクラスにはこのメソッドがありますよと言う事を約束するだけで
実装が共通化しようもないようなものに使うものだし
（例としてforeachで回せるようにする為のIEnumerable）
抽象クラスは良くある例はFruitクラスの子クラスがAppleやら関連性のあるものに対して使うものだろうし
そもそも用途が違うような

>>425
アーキテクチャ綺麗だとあんまし使わないね
依存関係グチャグチャのスパゲティになってるとインターフェースで切ってDIしないとキツイ
けどそれは最初から設計ミスなんだよ

>>428
アルゴリズム書くときには便利かもね

クラスを他の人に使わせてまうとあとで変えれなくなってのっぴきならなくなることがあるからやがな。

interfaceにしておくことでサイズゼロにしておくことが出来る。
相手が不特定多数だと「変更したから変えてくれ」とはいえないわけですわ。

多態性を利用するために必須なんだから使わなきゃ不便じゃない？
純粋に楽になるついでに、構造に制約を設けて将来的に品質維持する保険にもなるっていう複数のメリットあるので、使わない理由が無いというか
一回つくって終わりの書き捨てならいらないけど

426の後半２行は意味がよくわからない

下手の考え休むに似たりって本当だよな

>>432
多様性を使う為に必須というのは初耳だった
別に普通のクラスでも継承してインスタンス化すれば多様性は使えると思ってたんだけど

同じ親クラスやvarの配列にしてfor回したり
そこでインターフェースや抽象クラスにしてしまうよりかは
少なくとも何も処理しないダミー関数でも書いて仮想メソッドで実装しておいた方が良いとおもてる

>>431
いやいやinterfaceから触るでしょうよｗ

ちゃんとcase文書いた方がいくつ分岐してるかわかっていいじゃん
これをメリットと思えないのってなんでなの？
ソース読むときいくつに処理が別れてるか知らずに済むことって皆無だと思うけど

今って多態性じゃなく多様性って言うのが主流なの？

>>436
いくつに分岐しているかを気にしなくてすむのがinterfaceによる抽象化のメリットの1つだろうに

いいえ多態性です

>>431
interfaceって実装しなくてもいいの？
詐欺にならない？

OOPの歴史も30年以上あるのでさすがに本質的に不要なものが
淘汰されずに生き残っているってことはないよ。

インターフェイス不要論とか抽象クラス不要論とか
staticおじさん級に幼稚で非生産的な書生論w

もっとマシなことに時間使った方がいいよ

>>440
実装しなくても良いのではなく、interfaceそのものには実装は書けない。必要なメソッドを定義するだけ
良くある例としてIDisposableがあるけど
using(var obj = new TestClass()) {
}
みたいな使い方したければ上記のTestClassにDispose()メソッドを用意してねって事で
class TestClass : IDisposable
{
public void Dispose() {何らかの終了処理}
}
みたいに実装を用意しないとそもそもエラーになる