ふらっと C#,C♯,C＃（初心者用） Part134
■ このスレッドは過去ログ倉庫に格納されています
「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、
質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスはやめてください
>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。
■前スレ
ふらっと C#,C♯,C＃（初心者用） Part133
http://mevius.5ch.net/test/read.cgi/tech/1510056685/
■関連スレ
C#, C♯, C＃相談室 Part95
http://mevius.5ch.net/test/read.cgi/tech/1508180530/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/
■情報源https://msdn.microsoft.com/ja-jp/library/gg145045.aspx
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/index
https://msdn.microsoft.com/en-us/library/gg145045.aspx
http://referencesource.microsoft.com/
-
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured 調子にのって式形式の略記しまくったら=>まみれになったでござる using dispose は便利な機能だが実装の闇が深くて台無し。魔剣ダイナシ。 SQL鯖へのConnectionもUsingの中に入れちゃっていいのかな？
昔は最初にConnection開いて、ずっと開きっぱなしの中で処理して、最後にCloseすることが多かったけど
不安定な接続(スリープで回線断)やミラーリングサーバーを考慮すると、いちいちOpen/Closeしたほうがいい。
だけど、usingの中に入れることで、いちいちDisposeされたら
接続キャッシュが機能せずに体感速度が落ちる、って風になる？ 接続管理はコネクションプーリングに任せてプログラム上は最短でOpen-Close >>8
SQL鯖でusing多用はいかん
try/finally使ってopen/closeしとけ
速度はopenしっぱなしとほぼ変わらん >>10
それdisposeと一緒やん。
ってか、disposeじゃん。
なにいってんの？ >>13
disposeじゃねぇ。usingだわ。まちげーた >>13
disposeしてないよ
何言ってんの? >>15
やってることが、using使ったdisposeと等価なんだけど。
usingはtry/finalyの糖衣構文
(sql鯖のコネクションについては)closeとdisposeは等価
何か違いがあんの？ var SqlConn = new System.Data.SqlClient.SqlConnection(xxxx);
という感じの宣言は try/finaly の外でやっておいて
open/close は try/finaly の中でやる
って意味で書いたと思ってたけど、そうだよね？ >>16
msdnのSqlConnectionメソッドの
closeとdisposeの説明をちゃんと嫁 >>19
おじさん?
アフォな専門学校の生徒かと思ったわw
放置プレイしま～す SqlConnectionメソッドってのはちょっと分からなかったけど
SqlConnection.Closeにはこう書かれてるな
> SqlConnection は、適用範囲外では閉じられません。
> そのため、Close または Dispose を呼び出して、明示的に接続を閉じる必要があります。
> Close と Dispose は、機能的に同じです。
DisposeはComponent.Disposeに飛ばされたから
そもそもSqlConnection.Disposeのページが存在しない >>18
msdnに機能的に等価って書いてあるんだけど、なに読めば良いの？
>>17
try/finalyの外で宣言した変数を使い回すってこと？
usingを抜けなければ、disposeは走らないから、一度開いた同一の接続を使い回すのであればusingの中で、接続(open)を複数回するのであれば、個別の変数を切り直した方が良いと思うよ？
前提が違ってたらごめんね。 アプリは生きててDBだけリセットかけたらもう一回接続しないと駄目？
なんかアクセス毎に開いて閉じて入れておかないと面倒な感じじゃね？ 最近はMicrosoftDocsに飛ばされるね、MSDNもあるけど英語がメイン
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/keywords/using-statement
ついこないだIDisposable実装したけど、これまたクイックアクションで親切すぎるコメントつきテンプレが流し込まれる iPhoneのキーボードのこれhttps://i.imgur.com/PStMLdz.jpgはプログラム書くときのダブルクォーテーションとは違うんだな。ideoneでなぜかエラーが出たので気づいた。
https://i.imgur.com/wyCNyNM.jpgこれだと使える。
英字キーボードのやつ “””””””””””
ABCのほう """"""""""" >>25
C#と関係無いけど、この業界にはよくある事
U+301CとU+FF5Eの違いとかな ソフトウェアキーボードでコード書くとか苦行過ぎるw ideoneでちょっとした動作を試したりするときだけだな C#ってmalloc・calloc・realloc的なかんすえはありますか？
全部自動？ いやmalloc的なのは普通の配列のnewかMarshal.AllocHGlobalだろ ただいま勉強中なのですが、↓のようなコードの設計、ネーミングその他は適切でしょうか？
身近に現役プログラマーの方がいないためいろいろと聞けないのが現状です。
なんでも指摘してくださると助かります。
public static class DirectoryUtils{
public static string ErrorMessage { get; private set; } = null;
public static bool DeleteFiles(string directoryPath) {
if (!Directory.Exists(directoryPath)){
ErrorMessage = "ディレクトリが存在しません";
return false;
}
try {
foreach (var file in Directory.GetFiles(directoryPath)){
File.Delete(file);
}
}catch (Exception exc){
ErrorMessage = exc.Message;
return false;
}
return true;
}
}
使う側
var success = DirectoryUtils.DeleteFiles(directoryPath);
if (!success){
MessageBox.Show(DirectoryUtils.ErrorMessage);
return;
}
//総変換数を求める
var totalNumber = GetNumberOfTotalConverting()
//Converting,Conversion,All,Total,Number,Count等々、悩んでいます 自分だったら
public class DeleteFilesResult
{
public string ErrorMessage { get; set; }
public bool Success { get; set; }
}
みたいなクラス作ってそれを結果として返すかな >>36
エラーならエラー文字列返して、正常なら空文字かnull返すのが素直じゃないかな？ successならsucceededとかじゃないの
もしくは構造体なりで
if (result == RESULT.OK)
とか さっそくでたな
ｔｒｙ catchはDeleteFilesメソッドの中じゃなくて
外で使うべき >>36
静的メンバーにエラー情報を持たせるのは時代錯誤で論外。
エラー情報は普通に例外を投げようよ。
単に失敗成功が分かってエラーメッセージが取得できればよいだけなら、
エラーメッセージはoutな引数で戻せばいい
あと、一つのファイルの削除に失敗した時点で処理中断する仕様でいいの？
失敗しても継続する方が自然なような気もするけど...
DeleteFilesより明示的にDeleteAllFiilesの方がいいんじゃないか？
GetNumberOfTotalConvertingは長すぎ
それを含むクラスに適切な名前がついてればそんな冗長な名前にする必要ないでしょ >>41
以前暴れていた
CsvHelper例外で落ちるな糞野郎くんだろう DeleteFiles内部でtry catch受けていいのは
そのファイルをスキップして残りを消す場合など 例外が飛んでそれをもとに制御が変わるなら
適切なtry catchの場所を考えるべき あと、例外についてはとにかく何でもキャッチしたがる人と、
それに対するアンチテーゼで「例外は絶対キャッチするな」と主張する人がいるけど、
どっちも何か盛大に勘違いしてる極論だから眉唾で聞いた方がいいと思う そうだね
例外利用するならFile.Deleteのページを見て
どんな例外をスローするか調べたほうがいい
権限無くて削除できないとかあるから 頻繁な例外を想定するならロギングで出力した方がいいよ
エラーを毎回表示なんて非現実的だし無視してOK連打したら意味ないでしょ
それよりタイムスタンプつけてテキストファイルに保存した方が後から照会できる
問い合わせの多くは、何もしてないのに突然おかしくなった、というやつばかり
そういう時はログフォルダをzipで圧縮して添付してもらおうというわけ 状況が許すならDirectory.Delete (string path , bool recursive)を使いたい >>36
同じく静的メンバにエラー状態持たせるのは論外だけど
どうしてもやりたいなら成功時にそれをクリアしないとダメ
bool返すよりoptionalみたいなのを返すのがモダン そのフォルダが相手のミスでリードオンリーにされた場合は例外情報が全部死ぬけどな >>36です
こんなにレスがつくとは思いませんでした。みなさんありがとうございます。
①結果を格納するクラスを作成し、それを返し、参照する
②エラー文字列を返す
③例外を投げるかoutな引数で戻す
どれもそういった発想が無かったので勉強になります。
ちなみにoutを使う場合はtupleを使って2つ返すのもありですか？
>静的メンバーにエラー情報を持たせるのは時代錯誤で論外。
こういう風に指摘されるともっともっと勉強しようと励みになります。ありがとうございます。
＞あと、一つのファイルの削除に失敗した時点で処理中断する仕様でいいの？
＞失敗しても継続する方が自然なような気もするけど...
たしかに処理の中断をするまでもないですね
例外処理についてはメソッドを呼ぶたびにtry catchを書くのが冗長という理由だけで中にいれてました。
制御が変わるかなど考慮すべきでした
optionalや＞もしくは構造体なりでif (result == RESULT.OK)
などまだまだ理解できない部分が多いので調べてきます >>50
予期せぬ例外は
https://qiita.com/exliko/items/42715a0c9fd7519eb6d9
このような感じでログファイルに出力するようにしていたのですが、
たしかにエラー毎回表示も微妙なので、もっとログをとっていくようにしていきます >>47 >>48
例外が起きた際、個々の例外によって制御を変える場合は個別に書いて、
MessageやStackTraceをロギングして終了するだけの場合はExceptionですべて捕捉する感じですか？
当初はIOException,UnauthorizedAccessExceptionなど書いていたのですが、
結局Messageしか使っていなかったので全ての例外を捕捉するようにしていました。 Directory.GetFilesはファイルを全部探してから配列でそれを返すので色々と無駄
列挙するだけならDirectory.EnumerateFiles 教えてもらったことにお礼を言うのはいいとして変える必要があったのだろうか >>55
Tupleでいいけどちゃんと名前付けてね
もしvs使ってるならコード分析かけてみれば？
静的メンバーの公開とかは警告で教えてくれたはず >>57
基本的に例外を避けたい理由がなければ例外を使えば良い
ロギングしてアプリを終了するならExceptionでcatch
復帰可能のは個別に対処（ディレクトリが見つからない場合は再入力を求めるなど） >>55
outはもはや要らない子
名前付Tuple使っとけ bool ok,int unkor,int unkog,int unkob
var unkc = GetUnkoColor();
if(unkc.ok){
成功
}else{
失敗
}
みたいな？ また、Exceptionが不遇な扱いを受けている
哀れすぎて何も言えねえ また、大して考えず産廃を作った予感
言語開発者暇なのか？
Getしようとしたけど要素がないときもあるじゃん
全部例外で飛ばされるとかマジやめて 例外が邪魔とかoutイラナイわめいてるのは大抵Dictonaryでしょ
連想配列は銀の弾丸ではない、期待しすぎ 今はout引数で変数宣言できるようになったからかなりスマートになった
むしろタプルの必要性が疑問なくらい
TryGetXならnull問題もないし 何が返されるか分かりにくいじゃん
タプルで返して分割代入すればいい outでもクラスでも構造体でもタプルでも好きなもの使えばいいよ
>>78
いらんというお前のレスがいらん
チラシに書いとけ outって呼び出す時に一々変数を定義しなきゃいけないのが面倒
Tupleは戻り値が分かりづらいって欠点がある
どちらも一長一短だから好きな方を使えばいい
.NETライブラリが使ってないから使わないって思考停止すぎんだろ 公認じゃない感あるし.NETの関数とマッチしないからな c#が気に入らなきゃMatzみたいにオレオレ言語作れよ 時間帯によってgpuの色味をコントロールするソフトを作りたいです
具体的にはf.luxみたいなソフトを作りたいのですが、かんたんですか？C#でいいんです？
f.luxはガンマ？が高目に設定されるようで、余計眩しく感じたりします >>94
たまに似たような人がいるけど仕様段階で先が見えないくらいならあきらめた方がいい
このスレは設計のアドバイスをする役割ではないから 画面関係ってOSのAPIレベルで標準化されてるのかな。
Win10だとそれっぽい機能がついてるから存在するのかもしれんが、それ以前のOSには存在しない気が
そもそも、昔よくあったOOPの責務の仕分け問題じゃないけど、画面の調整機能って
本来はモニター側が担当すべき機能でPC側でやるのはいかにも筋悪だよねw ■ このスレッドは過去ログ倉庫に格納されています
