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

■ このスレッドは過去ログ倉庫に格納されています
2020/05/27(水) 10:14:39.92ID:wHIUQvvs
■前スレ
ふらっと C#,C♯,C＃（初心者用） Part147
http://mevius.5ch.net/test/read.cgi/tech/1582100741/
■関連スレ
C#, C♯, C＃相談室 Part94
http://mevius.5ch.net/test/read.cgi/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/index
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
2020/06/08(月) 07:36:06.86ID:SQAF69LT
>>133
なんか基準があるはずよ
落ちるのだけはやめてって言われてるなら
GUIの操作するメソッド全部でcatchしてメッセージでも出さんといかんじゃん
それとも「ああ、死んじゃっていいよ」って言われるかもしれんし
この場合は何もしないし
「ログにだけ出して」
ってのもあるし

そもそも各クラス例外を出す方針に一貫性がない
開こうと思ったファイルが開けないときの動作は普通は例外にしたくないけど例外が飛んでしまうときはcatchしないといけないわけで
まあ、個別に対処が必要？
2020/06/08(月) 07:41:47.96ID:CwjbcTvy
Rubyの話をする奴は、ちょっと話が違うとか理解することはできんのかな。
2020/06/08(月) 07:45:18.91ID:CwjbcTvy
>>133
例外は、Catchしたとて復帰不可能なものはアプリケーションエラーにして落とすのに使ってるかな。
そのメソッド内で完結できるならばCatchするというか。
後始末してから結局throwするケースもあるけど。

上っ面がアプリケーションからバッチ処理に変わっても同じように使える事、ぐらいを想定して例外処理書くと統一感出ると思うよ。
2020/06/08(月) 09:12:40.55ID:yGStluWB
>>134
自作だからその辺りの基準はないなあ
とはいえ世間でも基準は割とバラバラなのか
今回作ってるのはネットワーク関連のクラスなんだけど、初めて手を出す分野だからどれが個別に対処できるかは正直よくわかってないんだよね
参考にしてる資料に忠実に作ったら、ちゃんと動くんだけど例外処理だらけなのが見ててすごく気持ち悪くて、これで本当に正しいのかわからなくなったというか

>>136
使い分け方参考になります
あまり考えたくなったけどちゃんとしたものを組むなら例外の内容毎にきちんと仕分けしなきゃだめなのか・・・なんか逆にどんどん複雑になりそうで胸が熱くなるな
こう考えると寧ろサンプルはシンプルに纏まってて良いものに感じてきたわ

例外は普段最低限しか使用しないものだからイメージできなかったけど二人のお陰でなんとなく輪郭が見えてきた気がする、ありがとう
2020/06/08(月) 11:34:14.50ID:dXkaUtDt
例外は１つ残らず握りつぶせ
2020/06/08(月) 12:23:59.18ID:CwjbcTvy
>>137
例外って究極のgotoだからね。
その場でやっつけないなら慎重に受ける場所とその後の動きを検討しないといかんよ。
毎回その場でやっつけて、エラーとして呼び出し元に帰すって方針ならそれはそれでいいかも知れんけど、
誰かキャッチするだろって方針で、続行不能だからと適当に例外吐いて落とさせてると、あとで困る。特にバッチ処理。
2020/06/08(月) 13:24:22.92ID:MRA6597x
https://ufcpp.net/study/csharp/misc_exception.html
2020/06/08(月) 14:31:54.71ID:T+olwkzM
>>135
そいつはこの板のあちこちに出没する有名な荒しだからスルー推奨。
いくら指摘しても自分に都合のいい話しか目に入らないから相手するだけ無駄で、スレを汚すことになる。
2020/06/08(月) 14:45:08.81ID:XmX+evHg
>>133
エラーハンドリングの基本的な考え方はこのシリーズ読むと良いと思う
https://docs.microsoft.com/en-us/archive/blogs/nakama/293
2020/06/08(月) 21:31:29.92ID:g8QOms8D
>>138
これはネタで書いたんだろうけど、例外は適切な場所で握りつぶすのが大事だよな。
「知ってる例外はcatchするけどあとはスルー」ってのが最悪。
2020/06/09(火) 05:12:12.64ID:qGXJUMNV
色々資料をご紹介いただきありがとうございます
つまり、例外が大好きな.NETを呪いながら潰せる例外はメソッド内で潰し、潰せなければどのような例外があったかをきちんと調べられるようにすれば良いわけかな
今回は例外が発生してもクラッシュせず、かと言ってメソッド内で処理する事はできないようにする予定なので、例外が発生する可能性があるメソッド全てに例外の種類を特定できるような戻り値を与える方向で進めていく予定でやってみます
2020/06/09(火) 05:30:56.43ID:pfkm8l8b
例外が出る処理はすべてcatch書いて適切な処理を書けばいいだけ。簡単。
2020/06/09(火) 07:53:14.85ID:JJE9ezaH
>>145
どこでどんな例外が発生するかを全部把握して漏れなくやるのはそれなりに大変だなあ
2020/06/09(火) 08:08:09.91ID:iKljlpbe
>>146
かといって、Javaの検査例外の仕組みはちょっとフットワークが重たくなるんだよな。
あれ自体は悪い仕組みじゃないどころか、発想としては初期の割に進んでたんだけど。
2020/06/09(火) 08:50:30.25ID:1J1p6pRh
全ての例外をcatchすればいいんじゃね？
2020/06/09(火) 09:04:01.05ID:khWV6688
後にも先にもJavaしか採用していない悪い仕組みだよ
呼び出し階層の途中をすっ飛ばして高層階と低層階の間で例外の関心が繋がるという、
高階関数やフレームワーク等において普通に存在する極めて重要な例外のユースケースを検査例外は無視している
2020/06/09(火) 09:29:05.21ID:iKljlpbe
うーん、むしろ、例外が漏れるケース、throwsを書かざるを得ないケースってのを減らすべきだと俺は思ってたけどなぁ。
低層階で発生したものを高層階でハンドリングする事が正しいとはあんまり思わんな。
IOのExceptionみたいな、高層階側ではどうしようもない事を上げられても困ると思う。
2020/06/09(火) 09:44:56.94ID:xkuk2TPr
検査例外ほんと楽
2020/06/09(火) 10:19:25.97ID:LXNCuYlO
けんされいがいって何だろうと思って調べたんだが、素人目には良い仕組みに見えてしまった
ただ例外を前提にするなら、もはや例「内」のような気が
2020/06/09(火) 10:21:47.06ID:0Ox9n+fW
Anders Hejlsbirgの検査例外に対する批判
https://www.artima.com/intv/handcuffs.html
検査例外は失敗、とっくの昔に結論出てる
2020/06/09(火) 11:04:45.35ID:V/up5vUs
高層側でどうしようもない例外が上がってきてるならそれは下層側が間違ってるだけでは
2020/06/09(火) 11:27:54.89ID:/rzxY16Z
>>149
>後にも先にもJavaしか採用していない悪い仕組みだよ
Swiftで採用されてるよ
シグニチャによって呼び出し側にエラーハンドリングを強制する方法自体は悪い仕組みではない
例外ではないがRustも考え方としては同じだし>>142の赤間さんの考え方もベースは同じ
2020/06/09(火) 11:29:03.56ID:iKljlpbe
チェック例外の発想は悪くないしいい機能だと思うけど、Javaのやりかただとバージョニング諸々で破滅的な事になりがちだから、静的解析なりなんなりのツールで確認すべきかなーっていう主張に読めたんだけど？
2020/06/09(火) 12:02:30.29ID:GiCu1zyF
何の例外がくるのか意識してかけ派なのか
何の例外も気にするな派なのか
そのどちらであっても書き手の例外テロに強制的に付き合わなければならない
そのごった煮であることを受け入れた上でプロジェクトのスタンスを決めなければならない
2020/06/09(火) 12:06:21.98ID:0Ox9n+fW
>>155
Swiftの例外宣言は「例外を投げる」という指定ができるだけで、型の指定はないよ
>>153の話で言えば、あらゆるメソッドにthrows Exceptionが付けられて破綻した状態を正しいものとして受け容れてるわけ
2020/06/09(火) 12:32:13.75ID:+J3ztXKO
>>150
呼び出し階層が関心事の包含関係を反映しないケースは普通にある
ラムダなんかいい例で、君は x.Select(y => y.Hoge) でSelectがHogeの投げる例外を知っていなければならないと言ってるんだよ
160デフォルトの名無しさん
垢版 |
2020/06/09(火) 12:43:43.58ID:XPvdX8TV
>>144
例外をエラーコードに変換して何の意味があるのw
例外の発生個所でそれを適切に処理できないなら何もしなくていいでしょw
後々のメンテナンスを考えて、あえてcatchして再スローするコードを書いておくのはありだとは思うけど。
2020/06/09(火) 12:50:07.05ID:LXNCuYlO
>>149
関心が繋がるって意味が分からないんだが、要するに因果関係があるってこと？
2020/06/09(火) 13:18:10.16ID:iKljlpbe
>>159
俺の主張は違うよ。
Hogeは例外を投げてはいけないと言ってるつもり。
2020/06/09(火) 17:30:22.31ID:aSDBpvhy
>>162
例外を投げることを主張するばかりか、それを上位で処理することを強要する仕組みに賛同してなかったか？
2020/06/09(火) 17:38:45.69ID:SzX0azwe
>>163
してないよ。
上位で拾うならアプリケーションを落とすぐらいしかやりようがないって言ってるんだけど。
throwsを書かざるを得ないケースの逆の、書かないケースってどう言う事かわかる？
そのメソッドでは例外が発生しないって事になってるって事だよ。
2020/06/09(火) 17:59:59.91ID:8zzTjSiL
ホント役に立たない議論好きだな
ここから出ないでずっとやっててくれ
2020/06/09(火) 18:18:44.12ID:hAic2KbQ
> IOのExceptionみたいな、高層階側ではどうしようもない事を上げられても困ると思う。
どんなに対処してもFileNotFoundExcpetionって防ぎよう無いけど例外受けてUIでエラー表示とかもしないってこと？
低層でexceptionを捕まえて実装者定義の情報に変えてそれでエラーハンドリングしろってこと？
2020/06/09(火) 19:00:49.38ID:ZQ97UuIm
会社の共有フォルダに配置されており、パソコン起動時に実行されて、特定の時刻になったらトースト出すプログラムを作りたいのですが、どのようなプロジェクトが向いていると思われますか？

WPFのプログラムを起動して5分おきに時刻をチェックし時間になったらトースト通知という仕組を考えたのですが、タスクバーに常駐してるのもなぁと思いまして

スマートな方法がありましたらご教示下さい
2020/06/09(火) 19:03:38.70ID:GiCu1zyF
誰がトリガーなのかイマイチわからなかった
2020/06/09(火) 19:11:59.72ID:TTuCfF7e
>>167
タスクスケジューラとpowershell
2020/06/09(火) 19:13:58.26ID:ZQ97UuIm
>>169
100台近くあるクライアントにタスクスケジューラは辛いです
2020/06/09(火) 19:16:14.88ID:GiCu1zyF
>>169
ワラタ
全部そいつでいーじゃん
172167
垢版 |
2020/06/09(火) 19:26:51.59ID:ZQ97UuIm
クライアントパソコンは起動時に実行ファイルを実行出来る配布済みのものです
実行時に実行ファイルを常駐させる他ないかなと思いつつも適材適所のプロジェクトがあればお伺いしたいなと思っております
2020/06/09(火) 19:30:24.74ID:5mqVZkdG
>>160
.NETがcatchを強要するようなオブジェクトなんかを用意するから悩んでる
結局その場で何もできないなら多くのサンプルコードのように、catchした例外内容をコンソール上に表示する(または再スローする)だけの形が正解でいいのかな？
呼び出し元にも例外処理させるのはあまりやりたくないけどこういうのは仕方ないのか
174デフォルトの名無しさん
垢版 |
2020/06/09(火) 19:43:10.68ID:XPvdX8TV
>>172
別にWindowsのスタートアップに登録して常に起動させておく方法でも問題ないと思うけど、
どうしても嫌なら既に指摘されてる通りWindowsのタスクスケジューラーのタスクに登録すりゃいいでしょ。

ユーザーにそれを手動でやらせろ、と言ってるわけじゃなく、
あなたが作るプログラムがそれをやればいいってことね。
2020/06/09(火) 19:43:33.99ID:5mqVZkdG
.Net介してタスクスケジューラにアクセスできるみたいだし無理ではないんじゃね知らんけど
2020/06/09(火) 19:47:14.39ID:DD0S+2l+
むしろ呼び出し元にも例外処理させるために例外があるんだろ

ファイル書き込みをオブジェクトに任せて書き込もうとしたら書き込めなかった
その後の処理を呼び出し側に書かんでどうすんの？
2020/06/09(火) 19:57:00.94ID:1J1p6pRh
例外をcatchしたらログに吐き出して上位にthrowすればいいじゃん
2020/06/09(火) 20:20:05.71ID:5mqVZkdG
Oh...深く考える必要はなかったってことね
まあ例外に関しては立ち止まって考える機会を得れて十分に学習できたからこれはこれで良かったわ
2020/06/09(火) 20:47:35.88ID:JJE9ezaH
>>149
>呼び出し階層の途中をすっ飛ばして高層階と低層階の間で例外の関心が繋がるという、

それは例外機構そのものの問題だと思うがな。
検査例外はそれを静的にチェックするからすぐ目に付くけど、それ以外の言語は
その関係が動的暗黙的で表に見えないだけ。ある意味よけい悪い。
2020/06/09(火) 21:17:50.01ID:/rzxY16Z
>>173
何もしないならその場でcatchしちゃだめだって
ログ出力のような共通処理は集約例外ハンドラに任せる
2020/06/09(火) 21:23:32.42ID:/rzxY16Z
まず、大原則を覚えてください。

よほどのことがない限り、アプリケーションで try-catch を書いてはいけません。

もう一度繰り返します。

よほどのことがない限り、アプリケーションで try-catch を書いてはいけません。

もう一度(ry、すみませんしつこいですね^^。でもこれ、めちゃめちゃ重要なのです。
https://docs.microsoft.com/en-us/archive/blogs/nakama/net-part-1


賛同するかどうかは別だけど
これがMS推奨の定跡
2020/06/09(火) 21:33:11.86ID:/5vAUGTr
かこいー
2020/06/09(火) 21:34:51.57ID:GiCu1zyF
>>181
嘘だよ
まず、アプリケーションをストップさせたくないときはcatchしないと駄目だよ

そもそもファイルがない程度で例外出しやがるお前（Microsoft）みたいなのがいるから足並みが揃わないんだろうが
そもそもみんな例外の扱いに困ってんのはお前（Microsoft）のせいだお前（Microsoft）の

それと例外自体が造り手の思想依存であって
飛んできた例外に例外であることの正当性の保証はない
みんながみんな好き勝手飛ばすし
正当な処理結果なのに例外としてcatchさせるような作り方もできる
こんな状況なので方針というのは作れなくて1つ1つのメソッドでどういう動作にするか考えなくてはならない
2020/06/09(火) 21:45:54.45ID:5mqVZkdG
>>180
キャッチしないとその場でクラッシュするから・・・
例えば、通信先の接続に失敗しただけで例外になるからこれでクラッシュするのは避けたいって時とか
そうすると色々教えてもらった結論としてはcatchしてから何もせず再スローするしかないと思ったんだよね

でもやっぱり気持ち良いものではないから代替案があればそっちにしたいけどいかんせん俺の知識が足りない
2020/06/09(火) 21:54:22.43ID:/rzxY16Z
>>183, 184
なんなんだよもう
脊髄反射でレスする前に一通り読めよ

リンク見つけられないのかもしれないからシリーズのURL貼っとくわ
https://docs.microsoft.com/en-us/archive/blogs/nakama/293
https://docs.microsoft.com/en-us/archive/blogs/nakama/net-part-1
https://docs.microsoft.com/en-us/archive/blogs/nakama/net-part-2
https://docs.microsoft.com/en-us/archive/blogs/nakama/net-part-3
https://docs.microsoft.com/en-us/archive/blogs/nakama/net-part-4
https://docs.microsoft.com/en-us/archive/blogs/nakama/netjava

>>153がリンク貼ってるAnders Hejlsbergも同じ考え方やで
2020/06/09(火) 22:22:59.33ID:5mqVZkdG
>>185
すまん、集約例外ハンドラが全然理解できてなかったから頓珍漢なこと言った
ちょっとちゃんと読ませてもらうわ
2020/06/09(火) 22:33:12.16ID:DuX3svuW
>>183
FileNotFoundExceptionが出て欲しくないなら
きちんと事前にファイルの存在を確認すれば良いだけだろ
2020/06/09(火) 23:22:54.12ID:hAic2KbQ
ファイルの存在確認してからファイルオープンの間までにファイルが消えることがあるんですが…
2020/06/09(火) 23:30:26.73ID:SzX0azwe
ライブラリ内、関数内でcatchして、ファイルが無かった旨の結果を返すか、
(必然的に、成功、失敗のいずれかと付随する結果を持つ結果オブジェクトを返すことになる)
もしくは誰もキャッチせずアプリケーションエラーにしてアプリごと落としてしまうのが良いんじゃないの？
要は、ファイルが無い場合ってのは、それをもってなにか処理したい場合、正常系の1パターンであって、無理に救う異常系ではないと思う。
2020/06/09(火) 23:46:24.77ID:JzXG4Km2
結局どの階層でもファイルが見つからない状況に興味がなければ
そのアプリは落ちるしかあるめえなあ
2020/06/10(水) 01:16:04.50ID:uuofLs7B
>>189
落とした方がいいかどうかなんて
そんなのお前が決める問題じゃないじゃん
2020/06/10(水) 01:30:48.32ID:uuofLs7B
作るメソッドが例外を飛ばしまくるくせに
ドキュメントを書かないなんて奴は最悪で完全に制御するためには
メソッドの中のソース読んで例外が今回の仕様にマッチするかどうかまで調べないといけない現実
ファイルがなかったから飛んだ例外なのかファイルを開いて編集できなかったから飛んだ例外なのか
造り手はそれに気を使う義理はないが
2020/06/10(水) 04:06:10.84ID:YByuqf7A
全部catchしてそのままthrowが基本。
2020/06/10(水) 08:41:52.94ID:5C8ycaaS
そのまま投げるならキャッチする必要ないけど？
2020/06/10(水) 09:04:43.18ID:K14nATts
>>194
catchしないとそこで止まる
2020/06/10(水) 12:25:52.43ID:5C8ycaaS
キャッチされなかった例外はそのまま上位へ伝播したとおもったが
2020/06/10(水) 12:43:33.19ID:Zx+vJVNc
>>196
それであっているしそうしないとthrowの意味が半減する
catchして何か処理したうえで再スローするのならともかくそのままthrowって言っている>>193とそこで止まるって言っている>>195は例外処理の基本すらわかっていない
2020/06/10(水) 12:44:04.48ID:QxZHo/84
いっぱいとらいきゃっち書いてそう
2020/06/10(水) 12:46:06.23ID:ZZdZ0hPp
多分Java屋崩れ
2020/06/10(水) 13:03:07.18ID:5C8ycaaS
>>199
検査例外の対応がそうするのが主流ってことか？
201デフォルトの名無しさん
垢版 |
2020/06/10(水) 13:08:48.62ID:YjHyIyr2
catchしてそのまま何もせず再スローはメンテを意識して書く場合はあっていいよw

// ここで○○が××の場合HogeExceptionが発生
とかコメントで書くよりよっぽどいい。
記憶力抜群の人はどうだか知らないけど、だいたい忘れちゃうんだよ。
どこでどんな例外が起こる可能性があるかなんて
202デフォルトの名無しさん
垢版 |
2020/06/10(水) 13:38:18.89ID:VsaDrFv7
何もしないで再throwにしても
イベントログに描き込んだり
ログファイルに出力したり
黙ってても出来ることはある
2020/06/10(水) 14:23:24.58ID:y/XlP2+v
>>201
再スローする時にthrow exp;とかやってるあほなJava屋上がりを見たことがある
2020/06/10(水) 14:26:03.03ID:PhLjERI1
try{
....
}
catch{
throw;
}
205デフォルトの名無しさん
垢版 |
2020/06/10(水) 15:06:38.37ID:5C8ycaaS
>>202
ログ出力してるのになにもしてないとか言うと話がかわるんだが
206デフォルトの名無しさん
垢版 |
2020/06/10(水) 15:08:51.68ID:5C8ycaaS
>>201
たしか標準のドキュメントコメントに例外あったはずだか、それより良いと？
2020/06/10(水) 15:10:25.22ID:ZZdZ0hPp
設定ファイルを触っておいて
何もしてないのに起動しなくなりました
って言う奴と同じだなぁ
2020/06/10(水) 15:16:17.31ID:uuofLs7B
iniファイルがよく壊れるソフトの開発者に限ってユーザのせいにするんだぜ
2020/06/10(水) 15:17:25.83ID:yPI+9HIl
例外処理のものっそい便利なライブラリとかないん？
2020/06/10(水) 20:56:55.10ID:FCXoWDTQ
- エラーは戻り値じゃなく例外を投げるべき
- 検査例外は糞
- 想定しない例外が発生したら潔くプロセスを落とすべき

声が大きい例外君はこんなのが多いよな
2020/06/10(水) 22:02:29.82ID:uuofLs7B
>>210
ファイルが無い程度でふっ飛ばされんのかよ

だから夢みんなよ
例外なんて書くやつの匙加減一つでとんでもない仕様になりうるっていい加減理解しろ
誰でも好きに書けるんだからそらそうなるだろ
2020/06/10(水) 23:17:52.99ID:khHcCKsN
業務要件次第って思うんだが。。
要件詰めてないからブレるだけで
213デフォルトの名無しさん
垢版 |
2020/06/11(木) 02:07:01.03ID:IsdTc1b2
例外ガーって吠えてる人が何を勘違いしてるのか少し分かった気がする。
彼は結果に過ぎないものを原因だと錯覚してるんだな多分w

問題領域が複雑だから（原因）煩雑な例外処理が要求される（結果）のに、
彼は例外処理が問題を複雑にしているという逆立ちした認識に陥っている。

もっと根本的にそもそも安全側に倒す意義が分かってないような気もするけどw
214デフォルトの名無しさん
垢版 |
2020/06/11(木) 03:19:29.26ID:RDVRKDbg
x 例外ガーって吠えてる・・・
o 例外が、って吠えてる・・・

正しい日本語を使いたまえ。
2020/06/11(木) 03:32:04.56ID:lk03undl
頭悪そう
216デフォルトの名無しさん
垢版 |
2020/06/11(木) 06:28:00.20ID:m7gaY4Qp
過学習くん
2020/06/11(木) 07:23:56.49ID:kcRACwfn
トーストとかポップアップヒントとかネットに転がってるサンプルプログラムを動かしても無反応です
ひょっとしてOS側で機能制限されてるのでしょうか？
一年前は普通に出てた気がするので

なお、コードはここ様とか参考にしました
https://www.ipentec.com/document/csharp-show-popup-message-on-tasktray
2020/06/11(木) 08:12:57.48ID:jgipLoEz
これはひどい、>>214が
2020/06/11(木) 08:41:31.97ID:ZV+1UqXa
>>217
イベント設定した？
public FormMain()
{
InitializeComponent();
button1.Click +=button1_Click;
}
それでも出ないのなら自分でなにかOS設定でやらかしている
220デフォルトの名無しさん
垢版 |
2020/06/11(木) 10:51:47.05ID:lkbUBWj2
http://pineplanter.moo.jp/non-it-salaryman/2017/06/01/c-sharp-tasktray/
https://dobon.net/vb/dotnet/control/showtasktrayicon.html
2020/06/11(木) 11:30:26.55ID:hXL34I3w
>>217
NotifyIcon にアイコン設定した？
2020/06/11(木) 13:55:52.32ID:0fl6GOfP
StreamReader から文字列サーチして先頭の Position 得るライブラリとかありますか？
改行ないので ReadLine() は効かず ReadToEnd() はメモリが足らん状況です
223デフォルトの名無しさん
垢版 |
2020/06/11(木) 14:26:32.33ID:JpYLw7MR
改行無いならバイナリでバイト数指定して読め
2020/06/11(木) 18:23:47.52ID:YkN74GSh
そういうのを作ること自体が面白いと思えないとつらいねｗ
2020/06/11(木) 18:30:31.40ID:9OB4DptL
>>222
バイト位置を更新しながら、バイト列を繰り返し読む。
読み込んだバイト列の中からターゲットのバイト列の最初のバイトを探す。
最初のバイトにマッチしたらそこの位置からターゲットのバイト列の長さだけ読み込んで、
バイト列がターゲット文字列に一致するかを確認する。
一致すればそこの位置を返す。
2020/06/11(木) 18:31:15.90ID:EKtCO5aX
そういうのは自動テストやってるなら楽しいが手動でテストしなきゃいけないなら作りたくない
2020/06/11(木) 18:34:01.46ID:YkN74GSh
>>225
初心者相手だとそれだね
手ぬるいと感じてしまう自分はおかしいんだ
2020/06/11(木) 18:44:13.26ID:YkN74GSh
>>226
プログラムというのはそういうものじゃないかな
アルゴリズムを自分で考えるのが面白いと思えないならつまらないコーディング生活になる

自分の頭で考えるのが嫌だったり忍耐力が皆無ならまあ正直向いていない！

どーしても自分の頭でアルゴリズムを考えたくないならググるしかない
2020/06/11(木) 19:28:20.95ID:kcRACwfn
>>221
アイコンをブランクにしておりました
設定したら動作しました
ご指摘ありがとうございます
2020/06/11(木) 20:08:26.73ID:g/lvOsiL
アイコン表示されてないなら無反応は仕方ないなｗ
2020/06/11(木) 21:17:42.03ID:4cF8OH1R
>>213
例外は「安全側に倒す」とは真逆だと思うんだがなぁ。
緊急停止ボタンみたいなもんだけどそれは機器にとって安全な停止方法じゃないように。
2020/06/12(金) 00:23:47.90ID:UGclBUpq
アルゴリズムなんか正直ネットでいくらでも手軽に使えるのが落ちてるからなあ
俺にとってプログラミングなんて手段でしかないから結局作りたいものを好きなように作ってる時が一番楽しいわ
2020/06/12(金) 00:30:09.23ID:379Cwn2v
N=13ぐらいのおねえさん問題をC#で解いてくれ

https://youtu.be/Q4gTV4r0zRs
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況