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/10/06(日) 12:41:06.92

>>128
逆になんで不可能だと思うの？

2024/10/06(日) 13:11:45.32

普通は穴あきバッファを使う
EZ/VZはlessに編集機能を付けるってユニークな設計をしている
設計自体を知りたいなら「The Craft of Text Editing: Emacs for the Modern World」が参考になるかと

FINALはdumpすると、MIFESとREDの悪口が書いてある:-p

2024/10/06(日) 14:14:27.86

「穴あきバッファ」なんて初見なんだけどもしかして誤訳じゃない？

2024/10/06(日) 14:18:43.02

エディタのバッファ管理用のデータ構造は効率的な編集をサポートするためで
文字数カウントや行の折り返しの話はどういうデータ構造を使うかとはほとんど関係ないよね

今はGap Bufferもあまり主流じゃなくてPiece TableかRopeが使われることが多くなってる

2024/10/06(日) 14:21:17.70

興味があれば↓この辺読んでみるといい
TypeScriptだしC++に比べるとわかりやすいはず
https://code.visualstudio.com/blogs/2018/03/23/text-buffer-reimplementation

この辺の話はエディタのコアな部分ではあるけど
>>123の知りたいこととはほぼ関係ない

2024/10/06(日) 15:19:51.19

なにかの文書を画面に表示したい
←　表示したい部分が何行目に当たるか計算する
←　一行に含まれる文字数を知りたい
←　プロポーショナルフォントのときはどうするん？
←　行の長さを測定する関数使え
←　一文字ずつ足したり引いたりしながら測定を繰り返す
←　全部の行についてこれやんなきゃかよ？
←　やってられない

2024/10/06(日) 18:49:45.21

azukiのソースコード見れば？

2024/10/06(日) 18:57:38.47

>>135
>←　表示したい部分が何行目に当たるか計算する
テキストファイルなら頭から読み込むしかなく改行でカウントアップするだけ

>←　一行に含まれる文字数を知りたい
>←　プロポーショナルフォントのときはどうするん？
文字数によって折り返し位置が決まるか
表示幅によって折り返し位置が決まるかのどちらか
両方のルールを同時に適用するというのは一般的ではない
プロポーショナルフォントが関係してくるのは後者の場合のみ

表示幅で折り返す場合は指定したRectangleにフィットするよう
よろしくやってくれる表OS提供のAPIがあるので基本的にはそれを使う
APIの内部的では各文字の表示幅を足し算してるが
とりあえずは画面表示部分だけを計算すればいいので
思ってるほど大した計算量ではない

>←　やってられない
んなことたぁない

2024/10/06(日) 20:12:16.90

そもそも公開されてるソースがC++多いからなんだというのか

2024/10/07(月) 02:48:29.36

>←
それより矢印の使い方おかしくね？と思った

2024/10/07(月) 06:41:02.52

→えっ

2024/10/07(月) 07:51:22.02

矢印 Unicode(ユニコード)一覧文字 0g0.org
https://0g0.org/topic/arrows/

2024/10/07(月) 08:50:05.33

↑↑↓↓→→←←

2024/10/07(月) 20:30:46.78

個人レベルで作るなら別にベストな方法じゃなくても良い
とりあえず作ってみたらいい
そして徐々にブラッシュアップしていけばいい

2024/10/08(火) 02:42:19.62

どうせTextBoxかRichTextBox使うから
いちいち行の文字数数えて改行とかという発想がでてこなかったわ
毒されてるんだろうか

2024/10/08(火) 09:46:02.12

質問者の作りたい物に行番号やカーソル位置座標とか要らなさそうだから
テキストボックスで十分だと思う

2024/10/09(水) 03:08:11.25

行列番号、文字数、ファイルサイズ、ドラッグ移動、カラー絵文字、正規表現検索＆置換、折り返し
これぐらい欲しい

2024/10/09(水) 05:37:10.40

こりゃ確かにいろいろと発想がズレてるな

2024/10/10(木) 01:43:13.48

カラー絵文字ってどうやるんだろう

2024/10/10(木) 01:45:48.53

どうとは？
もしかしてわざわざ白黒にしてるのか？

2024/10/10(木) 02:14:45.51

くるみぽんちおの刑だ！！

2024/10/10(木) 14:48:43.23

まじかテキストボックスがカラー絵文字に対応したのか
週末試してみるわありがと

2024/10/11(金) 00:26:48.51

win11で作ったformアプリがwin10で盛大にズレてて頭抱えてる

2024/10/11(金) 01:05:53.43

>>152
何をもってOSに起因する症状だと判断したの？

2024/10/11(金) 06:58:29.47

OSバージョン毎のフレームサイズの差異とか気にもせずに処理でも書いたか？

2024/10/11(金) 08:01:38.38

OS関係なく単にディスプレイのスケーリングの違いでは

2024/10/11(金) 09:18:43.20

それだな

2024/10/11(金) 09:50:54.30

フォントとか配置とかやり直しはMacOSのあるあるだと思ってた

2024/10/21(月) 02:25:35.38

ライブラリを使用するために下みたいなコード書いた
ライブラリ内でIHoge.Method();の機能を上書きしたいのとHogeで設定されるさまざまな機能を使いたいがためにIHogeを実装したHogeクラスを継承してMethod();を隠蔽、そのうえでライブラリから呼び出されるようにIHogeをさらに継承？実装させてる

ちょっと無理矢理感強いけどこれはアリですか？

ライブラリの中
～
IHOGE.Method();
～

public interface IHoge
{
public void Method();
}
public class Hoge : IHoge
{
public void Method()
{
元の処理
}
}

自前で作ったクラス
public class NewHage : Hoge,IHoge
{
public new void Method()
{
上書き処理←やりたいこと
}
}

2024/10/21(月) 02:45:34.93

>>121
亀レスだけどすごいのあったぞ
中身見てないけど多分お前が望んでるやつだと思う
https://sumiox.com/cs-windowsorm-mynote/

2024/10/21(月) 08:25:43.38

>>158
Hoge.Methodにvirtual
NewHage.Methodでoverride

2024/10/21(月) 12:38:44.14

>>158
それがやりたいことなら別にいいんじゃね？

Hogeの他のメソッドがMethod()を呼ぶとか
Method()がHogeの他のメソッドを呼ぶとかの関係が出てくると
newを使わない場合に比べるとバグるリスクが高くなるような気はする

インターフェース+コンポジションにしておけばバグるリスクは低くなる
その代わりに多少書く手間がかかる

2024/10/21(月) 12:53:33.54

>>160
Hogeはライブラリの中の実装だからvirtualにできないのつらみ
>>161
なるほどありがとう

2024/10/22(火) 12:35:56.21

newで上書きしたことないな

2024/10/22(火) 19:02:31.64

>>163
なんかchatGPTが教えてくれた

2024/10/22(火) 19:03:43.61

てかVisualStudioが教えてくれた
緑波線でnewしてくださいって
public new 戻り値の型メソッド名

2024/10/23(水) 20:43:06.26

ML.NETを試してみたら思いの外お手軽で面白いな
アプリにさくっと組み込めそうだ

2024/10/23(水) 21:09:39.51

>>166
薄い本があるので入手お勧め

2024/10/24(木) 06:52:54.39

.NET MAUIで試したことあるけどWindowsはいけたがAndroidではトレーニングでエラーはいた記憶

2024/10/27(日) 08:19:05.51

>>159
サンクスです、これはすごいな
解説がおおくてわかりやすい
これのソースコードがダウンロードできたらよかったのに

2024/11/01(金) 19:03:45.14

CookieってSystem.Text.Jsonでシリアライズ・デシリアラズするとDomainKey変わっちゃってSet-Cookieで同じ名前のクッキー来ても違う奴判定されてダブるんだな
正確に言うと先頭ドット有りだと変わらないのと、BinaryFormatterやNewtonsoft.Jsonで非パブリックフィールド含む全フィールドをそっくりそのままストア・ロードさせれば変わらないんだけど

2024/11/14(木) 09:50:27.66

ZipPlaってファイル管理ソフトのソース持ってる人いる？
居たらアップして欲しい

2024/11/14(木) 10:20:27.81

>>171
ぐぐったらGitHubにForkされたのがあるようだぞ
オリジナルからどの程度手が入ってるか知らんけど

2024/11/16(土) 02:07:13.59

>>172
自分もそれは見つけたんだけど、何を変えてるのかもハッキリしないんですよね
なのでオリジナル持ってる人が居たらと思いまして

2024/12/07(土) 11:39:26.82

WinFormsってWindowのクラスネーム決められないの？
Win32のFindWindowのClassNameで探させたいのだけど

2024/12/07(土) 17:24:39.89

protectedなCreateParamsプロパティをオーバーライドしてClassNameを書き換えることはできる
独自名ならとりあえずRegisterClassは必要だけどそれだけで済むかどうかは知らん

2024/12/08(日) 10:13:10.77

C#側のプロパティは書き換えられても実際の内部の値はそういうことしないと無理そうか

2024/12/08(日) 11:19:30.20

RegisterClassExしてやろうとしたことあるけど
CreateParamsでRegisterしたClassName指定してもエラーになって
それで良く分からんまま放棄したな昔

2024/12/08(日) 11:24:39.87

流行りのAIはその辺何か教えてくれんのか？

2024/12/08(日) 11:42:31.33

はい

2024/12/08(日) 12:16:51.06

人間が垂れ流した知識を混ぜるだけのAIが、人間が知らないことを教えられるわけないだろｗ

2024/12/08(日) 12:37:03.03

世界中のどこかで語られたかもしれない事実をそこらの人間がすべて知ってると思うのがおかしい気がする

2024/12/08(日) 17:47:34.90

つーかさWin32APIのCreateWindowで作ったウィンドウをC#にAttachする程度基本的な仕組みぐらいあるやろ
あるやろ…

2024/12/08(日) 21:09:31.34

CSharp初心者が学習始めるなら何からがおすすめ？
多分IIS?使ったウェブアプリになるんだけども
Javaでのアプリ開発経験はあり

2024/12/08(日) 21:38:41.73

Paint.netのソースを見たまえ

2024/12/08(日) 21:46:52.70

これかな、ありがとちょっと見てみるわ
h
ttps://github.com/paintdotnet

2024/12/09(月) 11:14:47.99

SetWindowLong
SetWindowLongEx

2024/12/09(月) 11:15:02.52

GWL_EX_STYLE

2024/12/09(月) 13:22:41.09

科学＋ 5ch

【AI】AIはわずか2時間の対話で人間の性格をコピーできる [すらいむ★]
https://egg.5ch.net/test/read.cgi/scienceplus/1733576027/

コメントに面白いことが書かれている

**185** (ﾜｯﾁｮｲ 5f62-oAsD) · 2024/12/09(月) 17:56:14.64

PaintDotNetをインストールした

2024/12/11(水) 06:17:57.42

varなんて使うな戦争ってもう終結したの？

2024/12/11(水) 07:27:33.98

言語によりけりだから

2024/12/11(水) 08:36:42.20

盲目的にvar使うなとは思うけど、一切使うなはないなぁ

2024/12/11(水) 08:50:12.41

まあマイクロソフトのサンプルにも使ってる例あるしな

2024/12/11(水) 10:05:12.70

jsのvarと違ってただの便利機能だしな

2024/12/11(水) 12:36:15.23

varで参照型を扱うとnullableになるのはどうにかしてほしい

2024/12/11(水) 13:56:36.44

推論型なんだし、必要に応じて使えばいいんじゃね？
objectならともかく

2024/12/11(水) 14:39:24.72

varが絶対必要なのって匿名型使うときだけだから、必要に応じて使う、だとvarはほとんど用無しになっちゃう
戦争に参加するつもりはないが仮にvar使うんなら必要に応じてじゃなく基本varにしないと

2024/12/11(水) 14:54:27.03

c#は基本varでいいよね
多分大体のc#er？はvarじゃないときにだけ理由を気にするんじゃないかな

2024/12/11(水) 18:36:49.06

初期に頭のいい人は一番先に varに飛び移った
その後みんな気が付いて移行した
今でも使わないのはご老人

2024/12/11(水) 19:15:48.68

varばかりやわ

2024/12/11(水) 20:38:24.59

VBのVariant最強

2024/12/11(水) 20:41:39.44

それはないかなw

2024/12/11(水) 23:21:13.31

インターフェース分離の原則が分からない
「必要のない振る舞いを実装しない」のは適切だと思うんだけど、ポリモーフィズムとの組み合わせが悪いように思う

interface IBird { string Name { get; } }
interface IFlyable { void Fly(); }

// ペンギンは飛べないので IFlyableを実装しない
class Pengin : IBird { ... }
class Eagle : IBird, IFlyable { ... }

のようにした場合に、プログラムが List<IBird> birds のような形でデータを持つと、「飛べる鳥がいる」という情報が型から消える

foreach (IBird bird in birds) {
　Console.write(bird.Name);
　if (bird is IFlyable flyable) {
　　flyable.Fly();
　}
}

「飛べる鳥なら飛ばす」ようにしたい場合、インターフェースを分離する場合だと上記のように is でキャストするしか無さそう？
IBirdで扱っているのに「インスタンスは IFlyable である可能性がある」という情報に依存してるのに少し違和感があって、より綺麗な解決策があれば知りたい

2024/12/12(木) 00:16:45.29

c#スレですよ

2024/12/12(木) 08:54:59.88

そこを別々のインターフェースとして分離するのが間違ってるだでは
飛べる飛べないも”鳥”の一要素でしょ

2024/12/12(木) 08:59:12.98

プロパティで持てば解決

2024/12/12(木) 09:20:56.04

>>206
Nullableな IFrayable? をプロパティとして持たせて、飛ぶ鳥の場合はthisを返すようにするということ？

2024/12/12(木) 09:43:51.10

そこだけのインターフェース化に拘るなって言ってんだよ

2024/12/12(木) 10:34:43.14

鳥とペンギンだと近すぎて例えとして微妙だった
例えば「動物のリスト」のようなデータを持ち、動物には鳥のように飛べるクラス (Flyメソッドを持つ) と、トラやライオンのように走るクラス (Runメソッドを持つ) があるといった場合

動物の一覧を持つには List<IAnimal> のような型を使うと思うけど、これは合ってるよね？
その上で動物によって違うアクションを行わせたいとする

IAnimal側に CanFly のようなメソッドを追加していくと、例えばサルのように「道具を使う動物」が後から追加された場合、IAnimalにメソッド追加が必要になり、それはBirdなどの各クラスにも影響する
Birdクラスは「道具を使う」なんてことは知らないのに、インターフェースのために CanUseTool のようなメソッドを後から追加するのは違う気がする

そうするとやっぱインターフェース分離の形になりそうで、そうなると利用側で is でキャストするのが落としどころなのかと

2024/12/12(木) 13:06:06.44

鳥以外にも飛ぶ（正確には滑空だが滞空することに変わりはない）動物は居るし
鳥だって地面をRunするヤツは居る
鳥にも、猿程でなくてもその辺に落ちてる物を道具的に使うヤツも居る

お前の例題がそもそもめちゃくちゃなんだよ

2024/12/12(木) 13:06:59.82

あといい加減余所でやれ
C#直接関係ない

2024/12/12(木) 17:51:32.06

ここの住人はC#を使っていてSOLID原則に悩まされたことなど無いのだろうか

2024/12/12(木) 18:08:37.64

>>203
ある動物が飛べることと、鳥であることは独立なんだから、
「飛べる鳥がいる」という情報はなくても仕方なくない？
統計的な相関関係はあるかもしれないが、包含関係でないなら仕方ない。
飛べる他の動物を無視するのなら、IBirdを継承したインタフェースでIFlyableBirdを作ればいいのでは？

2024/12/12(木) 18:40:52.28

ISP自体はC#でよく出てくる問題じゃないの？
これなんかまさにそう
https://dev.to/fabriziobagala/interface-segregation-principle-452m

だけどこういった解説はISP単体の説明になっていて、泳ぐ、走るといった能力の異なるものを Animal として抽象化する方法を教えてくれない
綺麗な方法でなくても「C#ではこうすることが多い」のようなプラクティスがあれば知りたかったんだけど、そういうのは無さそうなんですかね

2024/12/12(木) 19:18:32.74

実装を伴わない抽象化の話ってなんの身にもならないからやめなさい
それとインターネットサービスプロバイダの話は他所でやってくれ

2024/12/12(木) 19:18:50.89

求めてそうなプラクティスは見た事ないなぁ
個人的には、飛ぶにしても走るにしても動物という存在の態様のひとつだから
動物IFのプロパティに含めるでいいんじゃないかと思うけどね

2024/12/12(木) 19:36:28.62

var unko = new Unko()

より

Unko unko = new()

の方が良くね？

2024/12/12(木) 19:46:48.91

もっと地球規模の視野で考えろよ
うんこも地球の一部だろ？つまりうんこは地球とも言える
わかるか？

2024/12/12(木) 19:55:04.36

>>217
まぁ、後者ができるようになったの後になってからだから

2024/12/12(木) 22:38:48.07

>>214
それISP単体の説明にもなってない
class Penguin : IAnimalにNotImplementedExceptionでFly()を実装すれば即ISP違反だというのは間違い
まずは原典にあたってISPを理解してきたほうがいい
謳われてる原則をどう活用するかはその後

2024/12/12(木) 22:49:28.08

そもそも
そんな鳥のプログラムなんか一般的じゃねーし

2024/12/12(木) 22:59:54.30

>>220
「クライアントが『泳ぐ、飛ぶ、もしくは走る動物』として使うことを想定するのなら、そのインターフェースであるIAnimalにその情報を含めるのは適切」ということですかね
class Penguin としては Fly や Run などのメソッドの実装はノイズに思えるけど、IAnimalとして使われるなら、その契約に従えという感じかな
(それだと後から「道具を使う」がIAnimalに追加された際に Penguine もメソッド追加が必要で、そこがモヤモヤしてる)

こういう場合にアダプタ (ラッパー？) を使うのって適切？
純粋に Penguine としての機能を提供するクラスと、それを IAnimal として使うためのアダプタみたいなの
それだと更に複雑さを増すだけ？

OOP難しい……

2024/12/12(木) 23:02:07.06

適切とか
とりあえず作ればよくね？

適切かどうかなんてエグゼにしたら関係なくね？

それとも論点だけ考えて実際のプログラム作らないの？

それ何したいの

2024/12/12(木) 23:31:52.39

例が不適切だから混乱してるだけにしか見えないなぁ

2024/12/12(木) 23:50:28.74

SOLIDが現実のコードで使われなかったり、「オブジェクト指向は問題を複雑にするだけ」みたいなことを言われる原因

2024/12/13(金) 01:16:53.76

>>203
インターフェース分離の原則は「クラスが必要としないメソッドを実装しない」ってだけ
ペンギンのような飛べない鳥が IFlyable を実装しないのは正しい
あとは「飛べる鳥」をインターフェースで分かるようにしてやればいい
isを使う羽目になったのは飛べるかどうかわからない IBirdをListにしてるから
---
interface IBird { string Name { get; } }
interface IFlyable : IBird { void Fly(); }
// ペンギンは飛べない
class Penguin : IBird {
public string Name => "Penguin";
}
// ワシは飛べる
class Eagle : IFlyable {
public string Name => "Eagle";
public void Fly() => Console.WriteLine($"{Name} is flying!");
}
// 飛べる鳥だけを扱うリストを作る
List<IFlyable> flyableBirds = new List<IFlyable> { new Eagle() };
foreach (var bird in flyableBirds) {
bird.Fly(); // 明示的に飛べる鳥しか扱わない
}

2024/12/13(金) 01:54:21.75

こいつら病気なんか

2024/12/13(金) 01:55:37.37

だね

2024/12/13(金) 06:18:42.75

SOLIDにしても所詮理想論であって現場に即してるわけじゃないしなぁ