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

2021/05/16(日) 10:45:59.00

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

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

■前スレ
ふらっと C#,C♯,C＃（初心者用） Part150
https://mevius.5ch.net/test/read.cgi/tech/1616471904/
■関連スレ
C#, C♯, C＃相談室 Part94
https://mevius.5ch.net/test/read.cgi/tech/1553075856/
■コードを貼る場合は↓を使いましょう。
https://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
https://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

2021/07/24(土) 00:23:31.06

イベントが過去形か受動態かについては議論があるよ
全部過去形だというのは明らかに無理があるw
どっちの場合もあると思うしそれでいいでしょ。

受動態＞過去形＞完了形

一般的な使用頻度はこうじゃないかな。
しばらく前からイベントに普通の名詞形を使う命名の仕方もあるよね

2021/07/24(土) 00:26:07.51

>>687
https://docs.microsoft.com/ja-jp/dotnet/standard/design-guidelines/names-of-type-members#names-of-events

2021/07/24(土) 00:33:52.24

>>688
それはあくまでガイドライン。
実態の話をしてるんでしょ。

例えばそこのページに出ているDroppedDown、
dropは自動詞だと思うので過去形だという主張はちょと無理がある

2021/07/24(土) 00:36:42.84

長々と何やってんだこいつらは

2021/07/24(土) 00:55:30.71

>>689
droppedは過去形でよく使わんか？
an apple dropped down.とか
stock price dropped.とか。

2021/07/24(土) 01:44:28.78

よく勘違いしてる人いるけどwww

2021/07/24(土) 01:47:50.50

その労力でドキュメント書けよと

2021/07/24(土) 02:04:43.55

何したいのかよくわからんけど
getterしか必要ないってことはそもそも画面に表示する必要ないプロパティじゃないの

2021/07/24(土) 02:16:18.66

イミフ
値に単位でも付いてんじゃん？

2021/07/24(土) 02:31:41.54

>>691
何を言っているのか意味がわかんないけど、自動詞って言葉の意味は分かる？
dropしたのはDroppedDownイベントを発生させるオブジェクトではないよね？
イベントを発生させるオブジェクトはdropしたんじゃなくて「された」んだよw

もちろん「何かが落ちた」という現象を通知するイベントなんだと強弁することもできるが、
これ言ってて苦しいでしょ（笑）不自然で無理矢理すぎる。
受動態だって考える方が100倍自然だ。

Clickedイベントとかも同じ。
これが過去形ならButtonが自分で自分をクリックしたのかとw
お前はクリックしたんじゃなくてされたんだろうがとw

2021/07/24(土) 02:49:48.99

どうでもいいことをｗ

2021/07/24(土) 07:33:48.35

続きは議論スレでどうぞ。

ふらっと C#,C♯,C＃（議論用） [無断転載禁止]©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1469538912/

2021/07/24(土) 09:11:25.75

>>696
自動詞わかるよ？

なんで自制を使うかって理由が抜けてるんだと思う。
ネイティブにとってもそこはMSの方針いけてねえよなって思うところかもしれんのだと思うんだけど、MSはBeforeClickとAfterClickとかそういう接頭語を使ってイベント発火順を表して欲しくないんよ。
なので、Clickのあとに起こるイベントはClickedなんよ。
Click→Clicking→Clickedになる。

2021/07/24(土) 09:34:03.83

NCが無いぞ

2021/07/24(土) 10:12:44.82

>>694
ViewModelでの話に限って言うと
setterを持っているってことはViewから入力があるという含意がある
（もちろんケースバイケースでそうでない設計にすることもある）

で、例えばViewのラベルで現在時刻表示するためにViewModelにNowTimeプロパティを用意したとして
Viewからの入力はないんだからsetterを用意するのはおかしいよね、ということ

2021/07/24(土) 11:05:01.44

>>698
誘われてあっちを久し振りに読んでみたけど、ここよりも有意義なことが書いてある気がしてならない。

2021/07/24(土) 12:26:37.04

>>701
現在時刻は変化してくんだからprivateなセッターで値を更新して、プロパティ変更イベント発生させればいいんじゃないの？

2021/07/24(土) 12:40:41.42

>>701
>setterを持っているってことはViewから入力があるという含意がある

ないよ
外部から呼ばれたくなければprivate/protectedなsetterを使う

現在時刻のような呼び出しのたびに変化するような値は一般的にプロパティにすべきじゃないよ
(DateTime.Nowとかあるけど、あれはMSも間違いだと思ってるらしい)

2021/07/24(土) 12:42:42.49

別にそれでもいいんだけど
現在時刻そのものはDateTime.Nowでとるじゃん（これがModelに相当する）
わざわざViewModelにDateTimeのフィールド置いたりとかする必要がない
ViewModelは単にDateTime.Nowを返すgetterを持つだけで充分
setter書いても実際には何もsetしないとか違和感バリバリだし

2021/07/24(土) 12:46:48.97

>>704
> (DateTime.Nowとかあるけど、あれはMSも間違いだと思ってるらしい
ソースは?

2021/07/24(土) 13:18:24.45

もとの話は他のクラスのプロパティから導出されるプロパティって話だったんだが

2021/07/24(土) 13:23:10.38

>>705
それでもいいじゃなくて、どうクラスを設計するか
取得した時点でモデルプロパティ値が更新されたと見なす仕様なのか、リアルタイムで更新する仕様なのか
単に現在時刻をとれればいいのであれば、それはプロパティじゃなくてメソッドだし、プロパティ変更イベントを用意する必要もない

2021/07/24(土) 13:39:01.39

DateTime.Nowは設計失敗の産物って話、俺もどこかで読んだ記憶があったんだけど
おおもとのソースは書籍だったみたいだ
ググったら個人ブログの感想でこんなのが引っかかった
https://ufcpp.wordpress.com/2009/12/27/net-%e3%81%ae%e3%82%af%e3%83%a9%e3%82%b9%e3%83%a9%e3%82%a4%e3%83%96%e3%83%a9%e3%83%aa%e8%a8%ad%e8%a8%88/

2021/07/24(土) 13:48:21.00

海外のクソライブライブラリ使うとたまにそういうレベルでメソッドになったりプロパティになったり
非常に邪魔くさい

DateTime.NowがDateTime.Now()になったりDateTime.GetNow（）になったりDateTime.GetInstance.Nowになったり
コロコロコロコロ変えてくる

ドキュメントが整備されてないからインテリセンスで推測して変更するしかない

2021/07/24(土) 14:41:03.27

>>702
向こうでやると初心者用スレに書かない人が現れて論破されちゃうから行きたくないらしいよ
ここで議論してる人はその程度って事

2021/07/24(土) 19:53:22.67

>>701
その含意はない
XAMLのModeプロパティでOneWayとか指定するようになってるし

2021/07/24(土) 20:51:57.91

俺ならModelの方にINotifyPropertyChangedを実装して、VMでは
ReadOnlyReactivePropertyで変更通知を中継するな

2021/07/25(日) 17:48:33.79

アドバイスを頂きたいです。
簡単なCRUD機能を持ったコンソールアプリがあり、EntityFrameworkを使用してSQL Serverとのやり取りを行っています。
このSQL Serverのデータベースを年毎に個々に持ちたいという要件が出てきました。
テーブル構成等は全く同じで2020年のデータベース、2021年のデータベースをそれぞれ立てるという形です。

ただ、毎年この作業の対応は出来ないので、コマンドを叩くだけのような自動化をしたいと考えております。
理由として社内の事情によりvisual studioを使用する事が難しい点があります。
その為、アプリ側でDBとの接続情報を変更して発行しなおす事がハードルが高いため、可能であれば自動化したいです。

データベースの作成はSQL文を使用すれば良いと思うのですが、EntityFrameworkを使用しているアプリ側への対応として、「接続するデータベースが変更された場合」という部分はどのように対応してよいか分かりません…。

CodeFirst、ModelFirstどちらの場合でもデータベースの変更に対応するにはやはりプログラム側で変更するしかないでしょうか？
データベースを年毎に分けた場合、過去のデータを参照したい時に年毎のデータベースそれぞれのDbContextの情報を作成しないと行けないと考えるとやはり自動化は無理でしょうか…

当方素人レベルなので良い案も浮かばず、何か少しでもアドバイス頂きたいです…。
長文大変失礼しました。

2021/07/25(日) 17:54:33.09

sqlserverで1年に1回ジョブながせばいいのでは？
今年分のdbは常に'hoge'って名前にして、1/1　0:00にhogeをデタッチして名前変更。
でhogeを新規作成

2021/07/25(日) 18:11:58.13

>>715
ありがとうございます。
通常使用するのは「hoge」固定とし、年が変わるごとに「hoge2020」「hoge2021」のように名前を付けて別物として扱うということですよね。

私もこれなら行けるかもと考えていたのですが、例えば過去のデータを参照したい場合に「hoge2020」「hoge2021」の情報をアプリ側が所持していないので参照出来ないのでは…と思い悩んでいました…。(先程コンソールアプリと記述してしまいました、すみません。正しくはフォームアプリです)

2021/07/25(日) 18:27:49.79

変更した情報をhogeのテーブルに持ち、クライアントへ渡しては？

hogeのConnStrInfoテーブル

ID,　db_name, year
1,　hoge_2018,　2018
2,　hoge_2019,　2019
3,　hoge_2020,　2020

これをクライアント側で取得し、動的に接続先を切り替える。
efだとConnection Stringをこねくり回すのはめんどいかもしれないけど
他に方法が思い浮かばない。

2021/07/25(日) 18:42:30.26

>>714
DBが分かれていて、別のDBに接続するときに接続情報を切り替えるのは当然だと思うけどなんでそれがダメなの？

2021/07/25(日) 19:28:19.50

>>717
ありがとうございます。
こんな方法思いつきませんでした。
知識が乏しいので、私にはかなり難しそうですがプログラム側で変更出来ないならDB側で工夫するしかないですね。

>>718
アプリはEntityFrameworkを使用し、既存のデータベースからモデルを構築しています。
年毎にデータベースが増えたとしてもvisual studioの機能を使用し、データベースの構造をモデル化すれば良いのですが、諸事情によりvisual studioの利用が難しい環境ですのでプログラム側を変更しなくて済むような別の方法を探しています…。
回答になってなかったら申し訳ありません…。

2021/07/25(日) 20:53:07.93

それってテーブル設計に変更があったら過去のデータベースも変更するの？
そこ詰めといた方がいいよ

2021/07/26(月) 03:27:45.68

データベースが増えても構造が変わらない限りモデルは増えないけどどんなイメージをしてるのか気になる

2021/07/26(月) 03:31:43.27

新しいテーブルに既存のテーブルから正規化しつつ移行ってパターンで1回地獄見たな。
該当の既存のテーブルを、協力会社の古い基幹システムが使ってて、そっちが動かなくなった。

2021/07/26(月) 09:47:45.98

普通に作ってればＤＢの接続情報をプログラム内に固定でもってることなんてないと思うが

つか年度ごとに別ＤＢ作るとかそもそもの発想がもう普通じゃないかｗ

2021/07/26(月) 11:04:48.50

まあソースベタがきは確かにないやろな

色々冷静な判断が出来ない現場なんだろう、知らんけど

2021/07/26(月) 11:09:22.19

もしかしてパーティショニングの事を言ってる可能性。

2021/07/26(月) 11:11:01.52

年度毎にデータを残しておいていつでも出せるようにしてほしいみたいな客の言葉を
常識的なシステム設計を理解していないバカが鵜呑みにしちゃった結果だろ
ギョウムシステムにはよくあること

2021/07/26(月) 11:54:28.60

市販の会計ソフトだと年次ごとデータベースを分ける作りにしてるのはよくある

旧年度のDBはそのままにして新年度だけDB構造を変更できたり
確定処理後は読み取り専用にするのをアプリ層じゃなくDB層でできたりと
メリットもあるので一概に否定される考え方でもないと思う

2021/07/26(月) 12:38:50.17

イベントソーシングでいいじゃん

2021/07/26(月) 13:14:31.91

>>728
イベントソーシングはスキーマ変更の問題を解決しない
それどころか過去全期間に渡る全データのマイグレーションというとてつもなく面倒な作業となる

2021/07/26(月) 13:15:54.39

>>729
何言ってんだ？

2021/07/26(月) 13:18:18.35

>>730
知らんがな
イベントソーシングで何がどう解決するのかお前が説明しろ

2021/07/26(月) 13:31:24.51

イベントソーシングなら過去のデータを全てそのまま維持しつつ年度ごと、それどころかあらゆる変化に対応可能
アペンドオンリーなので過去データは最初から読み取り専用
年度ごとにデータベースを分けるなんて間抜けなことはしなくていい

2021/07/26(月) 14:32:10.50

スキーマ変更に対して取りうる戦略ってのはイベントソーシングでも基本的に同じ

読み取り専用にする話はイベントソーシングで言うと
確定処理後に過年度のイベントが入ってこないようにしたり
入ってきてもプロジェクション時に必ず除外するようなアプリを通す必要がある

アプリ層で処理するって意味では年度別にデータベースを分けずに各データに年度をもたせた場合と同じ

2021/07/26(月) 15:09:24.98

この業界わけのわからない横文字技術で解決することっていっつも皆無だよね
単に下駄履かせてイキってるだけ

2021/07/26(月) 15:51:35.56

>>733
>スキーマ変更に対して取りうる戦略ってのはイベントソーシングでも基本的に同じ
わからない
RDBではデータモデルの変更が発生すればスキーマを変更する
イベントソーシングはデータモデルの変更が発生してもアプリケーションを変更するだけ
つまりイベントの再生方法が変わるだけでデータレイヤは永遠に同じ

>読み取り専用にする話はイベントソーシングで言うと
>確定処理後に過年度のイベントが入ってこないようにしたり
>入ってきてもプロジェクション時に必ず除外するようなアプリを通す必要がある
イベントソーシングでは過去の状態を再生するにはタイムスタンプでフィルタするだけ
過年度の変更イベントが入っても過去の状態の再生には影響しない

>アプリ層で処理するって意味では年度別にデータベースを分けずに各データに年度をもたせた場合と同じ
単にタイムスタンプでフィルタするだけなのでアプリ層の仕事は存在しない

2021/07/26(月) 16:18:53.38

そんな夢みたいな仕組みがなんのしがらみもなく完璧に動作するならみんな使ってるよ…

2021/07/26(月) 16:34:40.70

完璧に動作するんだけど大きなパラダイムシフトだから精神的抵抗orマイグレーション抵抗があってみんな食わず嫌いしてるだけ

2021/07/26(月) 16:54:08.24

馬鹿なんだろうなあきっと

2021/07/26(月) 16:55:34.22

>データレイヤは永遠に同じ
イベントソーシングでは後からのスキーマ変更はすなわち意識高い系アーキテクトにとっては屈辱的な設計の破綻なので、
そうならないように属性を全部JSON型の列に突っ込むような緩いスキーマを採用する場合があるってだけだ
引き換えに失うものはC#プログラマならよく理解してるだろう
もちろんちゃんと型を付けて真面目にDBを使う選択もあって、その場合はよくある普通の取引記録テーブルと変わらん
スキーマvsスキーマレスの違いであり、イベントソーシングとは直接関係ないよ

2021/07/26(月) 17:00:20.93

>>738
自己紹介？

2021/07/26(月) 17:03:55.87

>>739
ビジネス要件は日々変化するのでスキーマ変更を屈辱と感じるのは古臭い考え方のおじさん達だけだよ
変化に柔軟に適応するために最適化した進化と考えればいい
なおデータレイヤがスキーマレスだからといってモデルがタイプレスになるわけではないことは知っておいたほうがいい
C#や類似の言語が持つ静的型の堅牢性はESでも依然として完全に発揮されるので安心していいよ

2021/07/26(月) 17:12:24.77

そうかなあ
スキーマレスだとせっかくのnull許容参照型もあまり役に立たなくなるし、
おかしなデータが混入しててデシリアライズ時に型違いで落ちるとか日常茶飯事だったよ
マイグレーションによる停止が許容できるなら断然スキーマがある方が楽よ

2021/07/26(月) 17:23:29.78

>>742
さっきも言ったようにESでモデルの静的な型安全性が損なわれることはない
notnull/nullableは依然として有効だよ
再生時に型違いで落ちるのが日常茶飯事というのは何を言ってるのかわからないね

2021/07/28(水) 15:11:51.63

初歩的な質問でごめん
EntityFrameworkで2つのテーブルをjoinするやり方を調べてると下のコードみたいに結合した結果を作るように書いてたのね

(book, category) => new{
Title = book.Title,
Category = category.Name,
PublishedYear = book.PublishedYear
}

もしbookテーブル、categoryテーブルが例えば100列ずつあって結合後に全要素取得したい場合はnew以降に全カラム分記述しなきゃいけない？

2021/07/28(水) 17:18:49.56

いけないことはない

2021/07/28(水) 17:28:01.17

var q = db.Books.Join( db.Categories, o => o.id, i => i.id, ( o, i ) =＞ new { Book = o, Category = i } );
foreach(var row in q)
{
　int bookId = row.Book.id;
　int categoryId = row.Category.id;
　：
　：
}

まぁ不要なカラムを含んでいる分、使用メモリも増えるが。
生産性優先なら上記のように書くことも多々あり

2021/07/28(水) 19:36:49.49

>>746
ありがとう
確認だけど、この部分で全要素をqに格納が出来て

var q = db.Books.Join( db.Categories, o => o.id, i => i.id, ( o, i ) =＞ new { Book = o, Category = i } );

欲しい要素がある場合は後から個別に参照するって感じだよね

foreach(var row in q)
{
　int bookId = row.Book.id;
　int categoryId = row.Category.id;
　：
　：
}

LINQ難しい…

2021/07/28(水) 20:04:32.82

テーブルの結合て、モデルの結合だよな
モデルの設計をミスってるとしか思えんのだが

ほんとにテーブルを結合したいなら生ＳＱＬ流せばいいんじゃね

2021/07/28(水) 20:37:20.88

>>747
そう。
Linq文は横に長くなりがちなので、一時変数は極力短くすることが多いのも難しく感じる要因かな。
やってるのはただのinner join

もうちょっと丁寧に書くと
using(var db = new HogeContext() )
{
　// 欲しい情報
　string bookName;
　int bookPrice;
　string categoryName;

　// クエリ生成
　var query = db.Books.Join( db.Categories, outer => outer.category_id, inner => inner.id, ( outer, inner ) => new { Book = outer, Category = inner } );

　// 実際のDB接続とクエリ実行はforeach文に到達したとき
　foreach(var row in query)
　{
　　bookName = row.Book.name;
　　bookPrice = row.Book.price;
　　categoryName = row.Category.name;
　　：
　　：
　}
}

情報取得だけならAsNoTracking()つけたりするから、さらに横に長くなる。

2021/07/28(水) 23:03:49.99

こんなトンチみたいなことするより
サクッとSQLでええわってならんの？

2021/07/28(水) 23:47:01.98

スマートに書けませんか？系のスマートは究極的には人それぞれなものでね…

2021/07/29(木) 11:05:49.23

EF使うようになってから明示的なJoinなんて滅多にやらないしな
今回のもdb.Books.Include(x =>x.Category)でいいし

2021/07/29(木) 12:18:33.25

>>749
分かりやすくて助かるありがとう

EFで取得した値がnullかどうかをチェックってどうしてるの？
生のSQL書くやり方だと取得した取得したDataReaderをループで回して

while(reader.Read() )
{
for(var i = 0; i <= 10; i++)
{
if(Convert.IsDBNull(reader[i])))
{
testList[i] = 0;
}
else testList[i] = reader[i]
}
}
↑みたいにチェックしてnullだったら0埋めとかやりたい処理を書くんだろうけど、EFで取得した値だと上で教えてくれたように

foreach(var row in query)
　{
　　bookName = row.Book.name;
　　bookPrice = row.Book.price;
　　categoryName = row.Category.name;
　}
ループで回してもrow.Book.nameみたいに個別にアクセスしないといけないからnullのチェックはそれぞれの要素に対してするの？
わかりにくくてごめん

2021/07/29(木) 12:47:21.43

WPFでcanvasに図形が追加されるたびにその状態を保存してUndoRedo機能を作りたいです
stack<t>にcanvasを入れれば実装できると考えていたのですが出来ませんでした
stackの中身を見てみるとcanvasが全て最新のものになっていました
理想
①図形追加
→stack1 canvas(図形一個だけ)
②図形追加
→stack1 canvas(図形一個だけ)
→stack2 canvas(図形2個)
③図形追加
→stack1 canvas(図形一個だけ)
→stack2 canvas(図形2個)
→stack3 canvas(図形3個)
実際
①図形追加
→stack1 canvas(図形一個だけ)
②図形追加
→stack1 canvas(図形2個)
→stack2 canvas(図形2個)
③図形追加
→stack1 canvas(図形3個)
→stack2 canvas(図形3個)
→stack3 canvas(図形3個)

this.canvasをstackにpopで格納しているのですが恐らく参照型になっている(？)のかと思います
どうすれば解消されるか教えてください

2021/07/29(木) 13:19:29.67

>>754
stack2を作る時に、
var stack2 = stack1;とすると同じインスタンスを参照するのでstack1の追加が反映される
var stack2 = new stack(stack1);とすると別のインスタンスを参照するので反映されなくなる

という話であってるよね

2021/07/29(木) 18:55:32.43

分からない事を相手に伝える能力って大切だよな。

2021/07/29(木) 19:16:32.82

それができる人って、5chで質問しなきゃならんような事態には陥らないんだよね。

**>>754です** (ﾜｯﾁｮｲ 1a36-SEfg) · 2021/07/30(金) 00:50:25.37

stackのインスタンスは1個だけです

Stack<Canvas> stack = new Stack<Canvas>();で宣言して
①canvasに図形追加後にstack.Pop(canvas)
→stackの中身1個目(図形一個だけ))
②canvasに図形追加後にstack.Pop(canvas)
→stackの中身1個目(図形一個だけ)
→stackの中身2個目(図形2個)
③canvasに図形追加後にstack.Pop(canvas)
→stackの中身1(図形一個だけ)
→stackの中身2(図形2個)
→stackの中身3(図形3個)

少し書き直しました
これが実現したことです

**>>754です** (ﾜｯﾁｮｲ 1a36-SEfg) · 2021/07/30(金) 00:52:16.98

連レス申し訳ないです
PopではなくPushでした

2021/07/30(金) 02:25:15.43

stackにcanvasをpushしたあと、
そのcanvasは再利用せず、newして作り直してる？

2021/07/30(金) 05:37:39.20

まず「値型参照型 C#」でググってみよう

**>>754です** (ﾌﾞｰｲﾓ MM9a-SEfg) · 2021/07/30(金) 10:43:57.97

>>760
Redo()｛
Canvas Newcanvas = this.canvas;
stack.Push(NewCanvas);
｝

してます

2021/07/30(金) 11:05:04.49

それは参照のコピーなので、stackに入ってる実体は全部一緒になる

stack.Push(this.canvas);
this.canvas=new Canvas();;

とやって新しい実体を作って、この上に図形を置いていく

2021/07/31(土) 22:58:59.84

添付図のような必ず始点Xが0からなる四角の座標List配列の重複部をチェックして配列を作り直したいんですけど、考え方がさっぱりなので教えて下さい。

＠原点XYは四角の左下を押さえ、加工はXは右。Yは上への数値とし、マイナス数字はなしです。

(原点X) / (原点Y) / (加工X) / (加工Y)
・変更前
[0] 0 / 15 / 30 / 10
[1] 0 / 40 / 10 / 120
[2] 0 / 60 / 30 / 30
[3] 0 / 110 / 30 / 30

・変更後
[0] 0 / 15 / 30 / 10
[1] 0 / 40 / 10 / 60
[2] 0 / 60 / 30 / 30
[3] 0 / 90 / 10 / 20
[4] 0 / 110 / 30 / 30

2021/07/31(土) 23:03:01.69

？

2021/07/31(土) 23:11:36.23

何回読み返しても何言ってるのかさっぱりわからんw

2021/07/31(土) 23:19:55.92

ZDDを独自実装しようとしているのかな

2021/07/31(土) 23:23:58.74

なんかいろいろかわいそうな奴が多いスレだな。

2021/08/01(日) 02:08:17.96

宿題か

2021/08/01(日) 03:45:12.85

添付図ってどれ

2021/08/01(日) 07:54:26.92

https://i.imgur.com/VDN8u8W.jpg
すみません。これです。

2021/08/01(日) 08:17:39.94

>>764
・加工XYって何？
・変更前、変更後って何？
・表の[番号]は何？
・表の一行は何を表してるの？
・作り直したいって具体的にどうするの？
・そもそも重複部をどうしたいの？

2021/08/01(日) 08:57:03.12

>>771
図だけ見るなら
Xの値が同じ領域のYの範囲を作成する
だけじゃね？

①重複なしのY範囲リストを作成する（矩形のor取ればできるはず）
②開始Y座標のXの最大値を求める
③元の矩形情報から②のY範囲を求める
④リストに追加
⑤②③④で次のY範囲を求める
以下ループ

みたいな

2021/08/01(日) 09:14:55.78

>>764
パズルみたいでなんとなく考えてみたんだけどこういうことか

https://i.imgur.com/HHY6VFU.png

これが　変更前の四角形[0]　の　「座標」とやらの考え方かな

んで[0]～[3]の矩形が重なり合う部分を消去
残る矩形の「座標」を求める

変更前[1]の横幅がもっと広かったりするときれいに四角形が作れないけど
そういう場合は存在しないのかな
それとも別のルールで　「変更後」　の四角形をつくるのかな

2021/08/01(日) 09:31:09.73

今気づいたんだけどimgurって閲覧数でるのな
20分で16Views
おれが2回ぐらいブラウザから開きなおしてるとしても
こんな時間からここ見てる人結構いるのな

2021/08/01(日) 09:53:24.09

>>771
X軸側を無視していいなら単純に
for i = 0 to 3
if [i+1].原点Y < [i].原点Y + [i].加工Y then
[i].加工Y = [i+1].原点Y - [i].原点Y
end if
next
でよくね？

2021/08/01(日) 09:54:45.41

>>776
領域分割できそうにないな

2021/08/01(日) 11:25:36.83

>>771
なるほど
ルール説明が不十分なんだけど、その細長い四角形の幅が10ではなくて50とかあったらどうなんの？

2021/08/01(日) 11:41:00.72

>>773
Xの開始点が0じゃない場合は対応できる？
例えば真ん中らへんにある正方形(?)がちょっぴり右にズレてる場合

2021/08/01(日) 11:56:08.78

>>779
Xの開始点はゼロ固定なんじゃないかと思ってる多分

2021/08/01(日) 11:59:33.18

Xの開始点がゼロ固定出ない場合は矩形を作成するための優先順位のルールが必要になると思われる

2021/08/01(日) 12:06:37.48

あっよく見たらxはゼロ始点って書いてあったわ

2021/08/01(日) 12:55:16.92

Y軸を底辺とみなしてX軸側に伸びる棒グラフのようなものと捉えて処理したら一応できた
Y軸で使う最大の値160を要素数とする配列を作る
棒グラフの高さ、つまり加工Xを要素として入れていく
んで、この配列を材料にしていろいろと・・・

ただ、変更前配列の、例えば　[0] 0 / 15 / 30 / 10　の　10を1に変えるとまだエラー出ちゃうわ
つまらんところでつまづく
時間ないのでやめたー

**デフォルトの名無しさん** (ｽﾌｯ Sd9a-kof4) · 2021/08/01(日) 12:57:59.16

atcoderとかでありそうな課題だなと思った
やった事ないけど

2021/08/01(日) 13:19:27.15

元の矩形リストから各頂点のx, yをリストアップし、重複を排除して格子を作る
格子中の各矩形を走査し、元の矩形リストと衝突するものだけを抽出する

2021/08/01(日) 13:35:56.90

>>764 のような質問の仕方を見ると、人に物事を伝える能力や単語の選び方って凄い重要だと実感する
回答者にナゾナゾ出してるんじゃないんだから、加工とか原点という意味不明な単語を使わずに
「左下の座標」「幅」「高さ」
で良いじゃない
あとアップしてある図は右端の縦線がないけど、左（変更前）と右（変更後）で違うというのは質問に関係あるの？

四角の重なりをどうにかしたいなら
System.Windows.Rect（またはSystem.Drawing.Rectangle）として全て総当たりで
IntersectWithで重なり検出したら何かする
Containsで完全に含まれることを検出なら更に何かする、で良いんでない

2021/08/01(日) 13:39:33.75

なるほどそういう質問だったのねw
これ数学的に厳密なアルゴリズムを考えるのはきつそうだね。

与えられる座標が整数であり上限が確定している（例えば200）なら、
ファミコン時代のテレビゲームのBG面みたいに200×200のタイルでできた盤面上で
考えるのが簡単そうかな知らんけど