C#, C♯, C＃相談室 Part98

2024/06/29(土) 19:18:41.95

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512

■Visual Studio 2022 Community(無償の統合開発環境)等はこちら
http://www.visualstudio.com/downloads/

■コードを貼る場合はこちら
http://ideone.com/

■前スレ
C#, C♯, C＃相談室 Part97
https://mevius.5ch.net/test/read.cgi/tech/1671585518/

■次スレは>>970が建てる事。
建てられない場合は他を指定する事。

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

2024/12/14(土) 12:52:03.62

C# 8 からはインターフェースのデフォルト実装が使える

2024/12/14(土) 14:27:07.29

Win10や11のOS付属のpowershell5.1でインラインで書けるC#ってバージョンちょっと古くね
できれば新しいRoslynのC#をpowershellから使いたいのだが
なんか昔の記事しか見つからん

2024/12/14(土) 15:05:36.28

どうせ別に入れる必要があるならPowerShell 7入れれば良くね

2024/12/14(土) 16:09:38.02

>>236
起動時に出て来るメッセージすら読めないのか

2024/12/15(日) 03:52:31.32

>>238
お前はこれでも読んどけ
https://learn.microsoft.com/ja-jp/powershell/scripting/whats-new/differences-from-windows-powershell?view=powershell-7.4
Roslyn単体で使うだけならビルドツール拾ってくるだけだが
Powershell上げるとなると仕様も大幅に変わってたりして無理だし俺が出した要件の解にもなってない

2024/12/15(日) 04:43:36.26

>>239
馬鹿が必死に調べただけの浅い知識で言い訳してる

2024/12/15(日) 09:22:53.93

今のところ互換性の為に残してあるんだろう
それを変えちゃうと問題が起こる可能性があるしMS側のメンテがめんどうなので
変えたい人は7とセットで入れろということなんだろう

2024/12/15(日) 13:32:12.27

>>239
バカの相手はしなくていいわ
その情報はありがたいが

2024/12/16(月) 00:02:44.03

PowerShellは完全に袋小路だからもう諦めた方がいい
6以降は事実上Azure専用

2024/12/16(月) 03:32:32.19

>>242
うわっ
自分の言い訳コメントに自作自演で恥ずかしい馬鹿発見

2024/12/16(月) 04:36:14.08

なんで作っては捨ててくスタイルなんかなMicrosoftは

2024/12/16(月) 06:57:26.47

作ってないやろ
買収してるだけ

2024/12/16(月) 08:17:45.85

PSはMSが作ってるが

2024/12/16(月) 09:42:40.38

Windowsに標準搭載されてる.NET Frameworkと今の.NETの時点で互換性ないのに
なんで.NETアプリであるPowerShellが叩かれるのか

2024/12/16(月) 12:31:10.08

標準搭載されてるPowerShellは.NETアプリじゃなくて.NET Frameworkアプリだからね

2024/12/16(月) 13:18:44.44

>>245
MSの社内政治に敗れたチームのプロダクトはそうなりがち
社内政治うまくやってると微妙なやつも長生きする

2024/12/16(月) 13:27:42.05

frameworkってなんでまだ存在するの？

2024/12/16(月) 15:54:22.92

.NETがFrameworkと互換性無くて捨てられないから

2024/12/16(月) 19:05:15.35

互換性ないってことは、.NETとframeworkの2つのアプリを動かしたら、GCもそれぞれで動き始めるの？

2024/12/16(月) 21:44:01.92

>>253
GCはアプリ(プロセス)毎じゃないの

2024/12/19(木) 20:41:55.41

PowerShellはWindowsにシステムワイドにインストールされた .NET Framework が存在するという前提で成立していたのに、
.NETでは.NET自体をアプリにバンドルするか、必要に応じて特定のバージョンを追加で入れるかになって完全に破綻しちゃったんだよね
一般的な.NETアプリならバンドルは可搬性が向上するから好ましいことだけど、
PowerShellの場合はシステムワイドにインストールされたいろんなモジュールと連携しなきゃいけないから.NETバンドルはありえない
完全に詰んでる

2024/12/20(金) 08:54:32.70

だからPowerShell Coreは標準装備じゃなくて追加装備

2024/12/20(金) 10:14:37.03

Windowsにそもそも入ってないなら追加インストールでいいんだけどね。問題は5が入っていること。
それによって「なぜ元々入っているのにわざわざ追加するのか」という当然の疑問を解消するコストが生じる。
開発者の好みだけでサポート期間も互換性も劣るゲテモノをゴリ押しするのは極めて困難だし、
そもそもPS書いて飯食ってるタイプのエンジニアでは最新に拘る人はそもそも少ないだろうね

2024/12/20(金) 13:01:10.12

はいそろそろC＃の話題でよろ

2024/12/20(金) 15:29:33.49

JAIST、「並行量子通信プロトコル」の完全な自動形式検証を実現
http://news.mynavi.jp/techplus/article/20241220-3090485/

2024/12/20(金) 17:50:29.82

>>258
なんかある？

2024/12/20(金) 20:02:54.65

またペンギンやら飛べない鳥だとかの話がしたいのかい？
それともPowshellの付属物の話がしたいのかい？
どっちなんだい？

2024/12/21(土) 10:56:38.14

>>257
>それによって「なぜ元々入っているのにわざわざ追加するのか」という当然の疑問を解消するコストが生じる。
>開発者の好みだけでサポート期間も互換性も劣るゲテモノをゴリ押しするのは極めて困難だし、

ほんそれ
5が全部入りにしておくのが正解だっただろうな

2024/12/21(土) 11:18:40.67

PS for sysetmみたいなのを最小セットで入れておけば良かった

2024/12/21(土) 11:42:21.51

終わらないPS談義

2024/12/21(土) 17:53:08.76

>>264
お前がC＃の話題振ってくれりゃ乗るよ
早くしろよ

2024/12/21(土) 18:15:03.35

いや知らんがｗ
俺がC#の話題にしろ言うたわけじゃないしｗ

2024/12/21(土) 21:57:55.88

今関わってるプロジェクトがスペース2つでインデントしててちょっと面食らってしまったんだけどこれ珍しくないもの？
今まで携わってきた中で一件も遭遇したことなかった

2024/12/21(土) 22:11:41.26

過去に深いネストを大量生産する人がエラくなっちゃって、そういうルールになってしまったんじゃないかと妄想しちゃうなｗ

2024/12/21(土) 23:25:41.77

今時スペース2個は珍しいな、C#とかではあんまりない気がする
昔々はどの言語でもタブを使っていいかとか、スペースで代用するなら2個か4個かで論争があったらしい
JSは2個が主流だった気がするけど今はどうだろ

2024/12/21(土) 23:39:03.76

jsonは2だったり4だったりまちまちだけどね

2024/12/22(日) 00:09:01.63

タブのが合理的
Goみたいな標準フォーマッタがあるのが理想だけどC#はそう言う文化はないね

2024/12/22(日) 02:26:26.71

俺はスペース2個のが視線移動減って楽だと感じてるからかなり昔から2個派だよ
>>268みたいな日本人特有の右倣えのお仕着せルールに甘んず昔から超効率化してるやつらは世の中に沢山いるんだよ
勉強になったな

2024/12/22(日) 03:54:49.07

TABに統一してるけど
表示上は半角スペース2から4個で用途で変えてる

2024/12/22(日) 05:02:43.67

{}は
if(){
}
の方が好き
普通は
if()
{
}
これ？

2024/12/22(日) 05:44:22.67

逆、最初の頃は上が大多数
ブログやら初心者講座やらで下の書き方が主流担ってきてる感じ

2024/12/22(日) 06:21:31.74

スペース2個インデントって言うと、XMLやHTMLを思い浮かべるな

2024/12/22(日) 07:48:19.66

>>275
違うぞ
上のはJavaやJavaScript界隈でのデファクト

下はMicrosoft系のC#とかのデファクト

公式が出してるコーディング規約がそうなってるだけ

2024/12/22(日) 07:50:46.11

>>276
例えばC#というかasp.net系だとrazor構文でhtmlと一緒にC#のコード埋め込む
そうするとインデントは2の方が見やすい

2024/12/22(日) 07:53:26.28

>>271
C#はチェーンメソッドのドットを縦に綺麗に並べる文化が有るんでタブだと都合が悪い
2でも4でも良いけどスペースがデファクト

2024/12/22(日) 08:13:40.94

>>277
いやだから
C＃が出る前というか出始めの頃で
Cプラプラ使い達が多かった時さ

2024/12/22(日) 08:20:56.74

当時、というか関数書くときって
hoge()｛
…｝

て書くのが一般的やったん

んでDelphiが出てきたらこの｛｝をBegin…Endで囲むから
hoge()
Begin
…
End

ここらへんはVBやVBAとかにも反映されて
その後C＃で出した際にって感じかな

2024/12/22(日) 09:15:42.08

>>279
タブをインデントで使ってスペースをアライメントで使えば理論上ズレないよ
Goのフォーマッタはこれに従ってるからタブ幅は任意に設定できる

prettierみたいな途中で強制的に折り返すフォーマッタとは相性が悪いけど

2024/12/22(日) 09:22:40.24

Indent with tabs, align with spaces

https://dmitryfrank.com/articles/indent_with_tabs_align_with_spaces

これね
これが理想だけどエンジニアのレベルが高くないとこのルールを守るのは難しいからスペースにしてるのが大半
ただしGoは強制フォーマッタでこれを解決してる

個人プロジェクトなら最初から好きなタブ幅にすればいいからタブにするメリットもあまりないし
気分でタブ幅変えれるのは結構メリットあるけどね

2024/12/22(日) 09:27:48.67

俺はずっと>>274の前者でインデントはタブだなぁ
なおタブの幅はスペース4個分

2024/12/22(日) 11:59:15.10

「自転車置き場の屋根の色」現象発生中

2024/12/22(日) 13:03:56.05

この手の話は職場のルールで決まるから個人がどうこうは関係ないよな
ただ自分のツールなんかは好きにしろだが
カッコ、演算子、型と変数の宣言の間の空白などもめる話題はいくらでもある

2024/12/22(日) 16:36:51.22

>>285
「原子力発電所の建設」について議論したいなら付き合うよ、それで議題は？

2024/12/22(日) 17:09:33.96

まあreshaperでテーム共有設定使うだけだしな

2024/12/22(日) 19:48:07.14

>>287
では失礼して
Unity製ゲームのMOD開発なんかでリフレクション使いまくるのもなんかスマートじゃないから、
aelij氏のIgnoresAccessChecksToGeneratorを魔改造させてもらってフィールド含めて全パブリック&readonly解除でゲームのコードに全アクセス出来るようになってめっちゃ捗るようになったのだけど、
欲が出て標準ライブラリにも手を出したくなってやってみたらmscorlibなんかはReferenceAssemblyだからプライベートフィールドはそもそもdll内に含まれてないから書き換えられないんだよね。
ランタイム時の実体dllを決め打って渡せばstring.m_firstCharとかList<T>._sizeとかも全てアクセスできるようにはなるんだけど決め打ち渡しもスマートじゃないからどうにか自動で解決をしたい。
ILSpyやmono.cecilにはランタイム時の実体dllを特定するコードあるんだけどbuildアクションから同じ事するのって可能だろうか？

2024/12/22(日) 19:55:36.15

はい

2024/12/22(日) 20:10:00.61

へー
なんだかもうゲームよりMOD開発、MOD開発より開発環境開発の方が長くなっちゃってますわ

2024/12/22(日) 20:35:36.44

だって、ここ
別にゲーム開発やないし

プログラムやで

2024/12/22(日) 20:50:51.80

いまだにmonoで簡単にいじられまくりゲームあるのか

2024/12/23(月) 00:10:04.98

>>289
日本語がややこしいけど
①標準ライブラリのPrivate含む全フィールドにリフレクションを使わずにアクセスして書き換えたりしたい
んで、
②実体DLLを決め打ちで渡せばアクセスできるってところまでできてる
あとは
③実体DLL取得を自動化したい
④なおかつビルドプロセスに組み込みたい
ってことか
MOD開発とか知らんけど面白そうじゃん

2024/12/23(月) 00:36:21.82

いまいち細かい要件がよくわからんけどAppDomain.CurrentDomain.GetAssemblies()で現在ロードされているすべてのアセンブリが取得できるらしいが、これ試した？
駄目だったならどういうところがダメだったのか教えてくれ

2024/12/23(月) 17:33:16.62

>>295
要するにIgnoresAccessChecksToGeneratorの話でMSBuild内のコードとして動くものだからそれやってもMSBuildがロードしてるものが返されるだけとなる
ILSpyなんかもtypeof(object)などから解決してるので上記の理屈でそのまま移植はできない

2024/12/23(月) 17:42:25.10

>>293
マルチメインじゃなくmodフレンドリーなゲームならil2cpp化せずそのまま出してるゲームも普通に多いよ
改変やチート防止のためなら難読化含めてやったところでそこまで難易度上がらないからそれ目的ならRustみたいにカーネルドライバ付けるしかない

2024/12/24(火) 18:58:01.04

個人開発の局所的な用途のマイナーツールの話が原発の建設並の重大事なのか
ちょっと難しすぎてわかんねえな

2024/12/24(火) 19:41:54.52

原発ってただの湯沸かし器じゃん
燃料がちょっとヤバイってだけで高尚なC#のプログラムと比較すんなよ

2024/12/25(水) 08:00:53.24

C#だってただの道具
しかもC#だけじゃお湯も沸かせない
高尚とかちゃんちゃらおかしい

2024/12/25(水) 08:26:32.01

ツールは手段であって目的はアクセシビリティバイパスだから言語レベルのスケールの話な
実際これ求めてる人は少なくないからUnsafeAccessorが実装された訳で
てかリフレクションの方が文字列で指定してる分よっぽど危険だと思うんだけどな

2024/12/25(水) 21:07:50.83

エロがビデオを進化させてきようにチートがソフトウェアを進化させるんだよ
湯沸かししかできない原発野郎は難しいなら黙ってろ

2024/12/25(水) 21:35:48.64

煽りたいだけのやつが居着いちゃってるのか、このスレ

2024/12/25(水) 21:39:40.34

いつものことだよあぼーんしときな

2024/12/25(水) 21:44:21.01

だぁ～から
ドーンおじはコテ付けろや

2025/01/01(水) 16:01:04.94

Enum.IsDefined(enumType, intValue)ってボックス化する？

AIに聞いたら最初は「ボックス化しない」とか言われたんだけど、第2引数がobject型として受け取ることを指摘したら「ボックス化するかもしれません」みたいな曖昧な返答されてよく分からなくなってきた

2025/01/01(水) 16:03:34.19

object型ならするよ
.NETのバージョンにもよるけどgeneric版の方が型がコンパイル時解決されるからパフォーマンスは良い

2025/01/01(水) 16:07:11.80

だよねありがとう

2025/01/01(水) 16:23:43.79

確かにジェネリクスでstruct制約付けたらボックス化回避できそう
ありがとう

public TEnum ConvertToEnum<TStruct, TEnum>(TStruct value)
where TStruct : struct
where TEnum : Enum
{
if (!Enum.IsDefined(typeof(TEnum), value))
throw new ArgumentException();

return Unsafe.As<TStruct, TEnum>(ref value);
}

2025/01/01(水) 22:57:38.89

JetbrainsやILSpyでIL見てboxあるかどうかみればいいんじゃね

2025/01/31(金) 11:32:40.83

ハック的なことなんだけどインスタンスのオブジェクトヘッダに埋め込まれるクラスハンドルへのポインタ？をインスタンス無しで得る方法って無いかな
typeof(MyClass)ってすると正にそのポインタが「mov rcx, 7FFB716DE758 -> call clrのtype取得関数」って感じのアセンブラが生成される訳だけど、その7FFB716DE758を得たいんだよね
インスタンスがあればUnsafeライブラリ用いて簡単に得られるのだけど

2025/01/31(金) 11:34:05.08

文章修正してたら日本語おかしくなったけどもし知ってる方いたらヒントでも何でも教えていただきたい

2025/01/31(金) 12:00:57.31

GetTypeで得られるものとは違うわけ？

2025/01/31(金) 12:51:25.22

>>313
GetTypeやtypeofで得られるものはあくまでもType型のマネージドインスタンスだから全く違う
だけど逆アセをするとtypeof()時には即値でハンドルへのポインタ?がアセンブラコードとして埋め込まれてるので内部的にはめちゃくちゃ簡単に得る方法があるはずなんだよね

2025/01/31(金) 14:52:24.28

一応自己解決だけどGetTypeやtypeofで得られたTypeインスタンスから「type.TypeHandle.Value」で希望のものは得られた
本来即値で得られるはずなのに冗長でもやもやはするが

2025/01/31(金) 15:09:15.71

ChatGPTに聞いたら同じ答えが返ってきたけどRuntimeTypeHandle.Valueは環境によってメソッドテーブルへのポインタじゃなくEETypeへのポインタや実装依存のメタデータへのポインタになる場合もあるから自分で確認しろよとのこと

2025/02/01(土) 06:49:44.36

そらJITなんだから･･･

2025/02/01(土) 10:13:37.11

いやJITは関係ないぞ

2025/02/01(土) 11:06:41.29

JITだろうが何だろうがconst intなんかは即値で埋め込まれるしね
だからクラス名.TypeHandleValueみたいなconst持っててくれたら嬉しいんだけど需要ほぼゼロすぎるか

2025/02/01(土) 12:12:47.05

ん？即値で得られない理由の話だったか
そっちならJIT関係あるわな

2025/02/01(土) 12:17:46.65

いや関係ないよ
なぜなら逆アセすれば分かるけど思いっきりレジスタ長以下のconst同様の挙動を見せてるからね
typeof時にね

2025/02/01(土) 12:48:59.04

逆アセｗ

2025/02/01(土) 12:53:04.51

アドレスとかプロセス起動のたびに変わることは無いんだっけ？

2025/02/01(土) 12:59:03.20

>>323
.NETの場合は当然変わるしネイティブでも設定次第では変わり得る
でもそもそもC#やJavaは実行時にその都度機械語を組み立てて行く訳だから、であればその都度埋め込めばいいだけの話

2025/02/01(土) 13:11:42.17

なら結局、ユーザークラスじゃ都度変わりうるってことじゃ？

2025/02/01(土) 15:14:32.83

>>321
それはJITやAOT後のものを見てるからでしょ
JIT/AOT時に異なる相対アドレスに配置できる余地を残すためにC#/ILの段階では固定しない

2025/02/02(日) 01:00:15.78

ILの段階で定数になるなら決め撃ちで問題ないだろ

2025/02/02(日) 06:57:31.12

ユーザークラスがILの段階で決め打ちになるわけないだろ

2025/02/02(日) 10:55:04.54

ユーザークラスだろうが何だろうが別に関係ないし
IL段階で定数になる必要もなくて事実として実行時に機械語になるタイミングで定数化されるんだよ
プログラマがその定数にアクセスする手段がないだけで

2025/02/02(日) 11:18:20.90

実行時にならんと決まらんものは定数じゃねぇ

2025/02/02(日) 12:43:09.18

定数ってか再三言ってるけど即値だな

2025/02/03(月) 22:15:38.62

インスタンスの型の厳密なチェック typeof (X) == x.GetType() やジェネリック型のチェック typeof (T) == typeof (X) はJITで最適化されるから、
質問者のケースがもしこれらに該当するなら変なハックは必要ない

2025/04/14(月) 17:39:25.74

Task<T>を返す非同期メソッドをUIスレッドで呼び出して結果を取得したいのですがどうすればいいのでしょうか?
ConfigureAwait(false)の後やTask.Runでスレッドプール上?で実行されてる
コード内からメソッドをUIスレッドで呼んで結果を取得したいのです

2025/04/16(水) 05:53:28.46

イマイチ質問が把握できないがこういうことか？
UIスレッドでTaskScheduler.FromCurrentSynchronizationContext();してTaskSchedulerを確保しておく
UIスレッドで実行したいメソッドは上記TaskSchedulerを使ってStartするTaskとして実行する

public Form1()
{
　　this.Button1.Click += ExecuteAsync;
}
async void ExecuteAsync(object? sender, EventArgs e)
{
　　var scheduler = TaskScheduler.FromCurrentSynchronizationContext();
　　await Task.Run(async () => {
　　　　using var logger = new Logger("Task");
　　　　var task = Task.Factory.StartNew<Task>(() => SetTextAsync(), CancellationToken.None, CreationOptions.None, scheduler);
　　　　await task;
　　　　await task.Result;
　　});
}
async Task SetTextAsync() {
　　await Task.Delay(1000);
　　this.Text = DateTime.Now.ToString("HH:mm:ss");
}

2025/04/16(水) 05:58:12.67

あ、TaskCreationOptionsのTaskが抜けてる…
async Task SetTextAsync()の代わりにasync Task<string> GetTextAsync()だったら
StartNew<Task<string>>にしてvar text = await task.Resultすればいい