ふらっと 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 いや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 まあ、でも、一人も試みるやついないってのも寂しい話だ >>100
アドベガンマが昔からあるのでアプリケーションで変えることはできる
スレ違いだし興味も無いのでこれ以上調べる気にもならない
>>103
やりたい人はやればいい
要件整理からはじめてガチ初心者にずっと教えるのが覚悟できれば >>85
c#7の新機能に出力変数宣言(out-var)がある。
これはこれで変数宣言を見落としそうだけど。 >>106
愚者は厚顔無恥あり正しい事を指摘するとキレる 値渡しと参照渡しの違いって、エクセルの貼り付けの「値のみ貼り付け」と「すべて貼り付け」みたいなもんですか？ 「図として貼り付け」と「リンクした図として貼り付け」の方が近いかな >>110
なるほど。そこまで外れてなかったようで安心しました。 >>109
変数：割り当てられたメモリー上の特定のアドレス範囲
値：変数の中身（変数に割り当てられたメモリーの範囲のバイト列）
参照：変数に割り当てられたメモリーの範囲の開始アドレス
まあ、値がwebページのコンテンツなら参照はそのURIみたいなもの >>112
値をコピーする際にアドレスをよりどころにしているのが参照渡しということですね。
なんとなくイメージはわかるのですがなかなか。 >>113
何も難しくないよw
2chで言えば参照渡しは人（メソッド）に対してレスのアンカーを示すだけで
中身は教えない。
値渡しはレスの内容のコピペ
参照渡し：
>>113
値渡し：
値をコピーする際にアドレスをよりどころにしているのが参照渡しということですね。
なんとなくイメージはわかるのですがなかなか。 C#の次期バージョンではin参照渡しとかreadonly ref structとか参照渡し周りが超絶複雑になるよ >>116
ライブラリってのが何を指してるのかしらんが、CLRはパフォーマンス向上のために採用するだろ なんの思想もなくただ思い付いた機能追加してんな
次世代の課題はどう考えてもコードの自動生成だからな
もうc#にそれを受け切るキャパはないと結論出してくだらん機能追加してんのかな？
この設計を実現するためのこの機能ってのがないよな >>119
ごもっともだがmsの言語拡張にいったい何パーセントのc#プログラマーがついて行けてるんだろ? >>120
基盤のためだから、馬鹿な一般プログラマーはついていけなくていい
パフォーマンス向上だ間接的な利益を受けるから 値型参照関連の新機能はパフォーマンス向上のために追加されるから
使わん奴は一生使わんだろうな >>122
>>102の法則が発動され中途半端な馬鹿がグダグダで複雑怪奇な(当然バグだらけ)の
コードを量産するから困るのです。 馬鹿と一緒に仕事しなければOK
馬鹿に仕事を発注しなければOK
そうもいかないって？馬鹿は大変だなｗ MicrosoftがVBを切り捨てたようにC#も底辺から切り捨てられていく
底辺プログラマの未来は暗い C#は他の言語で便利な機能があれば取り入れようとしてる時期
rubyみたいに何でも取り入れてごちゃごちゃにならなければいいけど
本当の意味で新しい機能はしばらく追加されないだろう >>128
それって簡単に言えばなんの思想もないから他言語パクって見ますって話でしょｗ >>129
全部入れてるわけじゃない
思想的にあってるものだけ入れてる
似たような感じだったjavaとも進化の仕方から違いが見て取れるはず
C#の下位がjavaと思ってたけど今は結構違いがある 技術力があれば不要なコミュニケーションを大幅ぬ削減できるという事実から目をそらさないで そりゃC#にはVisualStudioとRoslynという超強力な助っ人がいるからね
さらにReSharper買えばリファクタリングも楽々 ■ このスレッドは過去ログ倉庫に格納されています
