ふらっと C#,C♯,C＃（初心者用） Part129 [無断転載禁止]©2ch.net

2017/06/09(金) 18:36:01.72

「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。

他のスレッドでは書き込めないような低レベルな質問、
質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。

内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。

なお、テンプレが読めない回答者は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスはやめてください

>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。

■前スレ
ふらっと C#,C♯,C＃（初心者用） Part128
http://mevius.2ch.net/test/read.cgi/tech/1493730340/

■関連スレ
C#, C♯, C＃相談室 Part94 [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/tech/1492843013/

■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/

■情報源
https://msdn.microsoft.com/en-us/library/gg145045.aspx
http://referencesource.microsoft.com/
---

VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured

2017/07/02(日) 08:57:33.81

>>587
ネット上の参照はやったことはないけどunko1の同じ形式のパスを適用したらいいだけでは
「データ内の」がいまいちわからないがパスが相対パスならば補完して絶対パスにするとか
ローカルでの参照ならそうする

2017/07/02(日) 09:13:50.60

出来ました！
ありがとうございます！

2017/07/02(日) 10:04:30.01

出来てなかった
絶対パスだと別のパソコンに移したりしたときとかに画像が読み込まれん
http://i.imgur.com/A7kdZFD.png
これをこうすればできると思ったけどこれだとエラーを吐いてしまいます
なぜでしょうか？
当方Ｃ＃どころかパス云々についての知識もさっぱりの初心者なので・・・

2017/07/02(日) 10:29:02.34

>>590
まずはC#の入門書とVC#のチュートリアル本を一通り終えてきたら?
悪いけどそんなレベルでいちいち2chで質問してたら何年経っても勉強終わらんぞ

2017/07/02(日) 10:30:38.54

というか2ちゃんは勉強や議論には不向き
Markdownも使えないゴミシステムなんて今や罵り合いぐらいにしか使えん

2017/07/02(日) 10:44:40.55

C#を勉強し始めた初心者ですが質問させて下さい
LIST<T>に、あるクラスのインスタンスを追加していって、必要なくなったらRemoveしてるのですが、このRemoveしたインスタンスの破棄処理は明示的に行ったほうがいいのでしょうか
その場合どういう風にすればいいのか教えていただけないでしょうか

2017/07/02(日) 10:49:58.90

何を突っ込んでるかによる
PCのリソースを独占したり圧迫するようなものなら破棄作業したほうがいい
でもよくあるデータだけの小さなクラスのインスタンスはほっとけばいい

2017/07/02(日) 11:13:27.07

>>593
list

2017/07/02(日) 11:13:46.07

>>593
状況次第だよ
インスタンスの所有者(破棄の責任者)はそのリストなのか否か
要素のクラスがIDisposableを実装しているか否か

2017/07/02(日) 11:16:06.46

>>593
listにのみインスタンスをnewしてるならlistからRemoveしたらガベージコレクションされると思うけど(タイミングは知らん)

2017/07/02(日) 11:57:12.72

>>593
(1) リストから削除するアイテムの型がIDisposableを実装している
(2) リストから削除後はもう使うことはない

この2つを満たすならDispose呼んだ方がいいのかもね。

俺ならやらないけど、コード1行でも減らさないと死ぬ病気なら
拡張メソッド使ってIDisposable実装してたらRemoveと同時にDispose呼ぶメソッドでも追加するとか

2017/07/02(日) 12:25:36.45

っていうか、.NET のガベコレとか理解してないならまずそっちが先決だね
別に難しい話じゃないし

2017/07/02(日) 14:03:45.88

俺のアプリは10秒に一度強制ガベコレが動く
って実装にしといたら引き継いだやつが組んだコードが落ちまくる
強制ガベコレ動かすと落ちるプログラム組む奴って結構いるよ
オススメ

2017/07/02(日) 15:03:56.21

逆に疑問なんだけど、どうやったらガベコレで落ちるようなコードを書けるんだ？unsafe？

2017/07/02(日) 15:24:12.89

>>601
すでに死んでいるから
普段はガベコレが動くまで偶然生きていて
強制ガベコレを動かすとすぐ削除されるから死ぬ

2017/07/02(日) 15:34:00.52

rubyの拡張をC言語で書いてたりすると余裕でそんなことを起こせるが
c#でどうやったらそんなことになるのか全然わからん

2017/07/02(日) 15:39:04.23

知ったか臭しかしないしスルーでいいよ

2017/07/02(日) 15:40:01.17

p/invokeとかunsafeが絡めばよくある話だな。

2017/07/02(日) 15:47:41.79

>>603
Diposeしてるやつ使おうとしたりremoveatしてるやつをremoveatされてないかのように使ったりして死んでる
後中身の見えないクラスで実はしんでんすよその状態的な

後はマルチスレッド関係で削除してんのに別スレッドではそうでないつもりで動いてたり
強制ガベコレかけるとゾンビも速攻であの世行くし不具合発見にいい
こういうタイミングが微妙なコード書くやつのソースって落ちやすい

2017/07/02(日) 16:08:18.93

普通using使うだろ

2017/07/02(日) 16:41:39.44

そういえば、使い終わったオブジェクトは using 使うなりして破棄してね。
ってリクエストしたら、try - catch の finaly で .dispose するからいいんだって言った人がいたな。
結果は同じだけど、どうせ直すなら using の方が素直な気がしたんだけど。まあいいけど。

2017/07/02(日) 16:50:21.19

>>608
usingの複数定義が気持ち悪いと言って頑なにfinalyでdisposeする人居たわ

2017/07/02(日) 16:51:54.15

>>607
開放されるかどうかは作り手の努力次第だけどなｗ

2017/07/02(日) 16:57:16.82

なんかくせーなお前
技術的に風呂入ってる？

2017/07/02(日) 16:57:31.53

>>609
シコシコ

2017/07/02(日) 16:59:16.69

他人の作った関数が仕様通りに動作するかどうかはその作り手の努力次第、ってのと何か違うの？

2017/07/02(日) 17:19:56.91

>>611
ｳﾙｾｪｿﾞﾎﾗｧ!( ‘д‘⊂彡☆))Д´) ﾊﾟｰﾝ

2017/07/02(日) 17:26:36.02

>>610
そんなの using 関係ないだろ
自分のなけなしの知識全開かよ w

2017/07/02(日) 17:43:52.22

>>615
でもdisposeなら解放されるんでしょ?

2017/07/02(日) 18:49:49.73

>>616
はあ？
using って単なるシンタックスシュガーだぞ

2017/07/02(日) 19:18:19.40

>>617
(￣ー￣)ﾆﾔﾘ

2017/07/02(日) 20:12:27.11

>>593です
レス頂いた皆様ありがとうございます
listの追加はインスタンスの作成と同時に行いlistから削除した後は2度と使用しません
そのクラスは個別のデータを管理するだけのクラスです
とりあえずあまり何も考えずGCの対象になると思い明示的な解放は必要ないのかなと思ってたのですが作法的にどうなのかと思い確認しました
ですので現状IDisposableは実装しておらず言わばリストから削除してほったらしの状態です
GCについてはあまり勉強していないので調べてみたいと思います
その他アドバイスありましたらよろしくお願いします

2017/07/02(日) 21:55:59.98

>>606
そんなコード書き奴いるのが驚きだけど、居るところにゃ居るんだなぁ。。。

2017/07/03(月) 07:19:58.02

>>620
> Diposeしてるやつ使おうとしたりremoveatしてるやつをremoveatされてないかのように使ったりして死んでる
これGC関係ないし
> 後はマルチスレッド関係で削除してんのに別スレッドではそうでないつもりで動いてたり
別スレッドだろうが参照もってりゃ回収されないし
どう見てもおかしい人だから相手しなくていいと思うよ

2017/07/03(月) 09:45:56.42

数日前からいるガイジだな

2017/07/03(月) 10:16:25.45

>>621
強制ガベコレすると落ちるけどしないと落ちないときあるじゃん
ってまあヘンテコなコード書いてないとお目にかかれないけどさ
そんなことないと主張するなら別にそれでもいいよ
俺は困らないし

2017/07/03(月) 12:07:19.95

そうか困らないかよかったなおめでとさん

2017/07/03(月) 13:36:19.21

Visual StudioC#
同じ階層のフォルダをクリックしたら、設定を変更してメモ帳を起動でませんか？

構造
フォルダ0
ーーフォルダ1
ーーメモ.txt

フォルダ1をクリックしたら、同じファイルのメモ.txtを太字にして、
閉じる時に元に戻す。

2017/07/03(月) 13:37:07.82

>>625
太字にして起動でした。

2017/07/03(月) 13:50:01.76

すいません。
どうもテンパってる見たいです。

フォルダを開くと同時にメモ帳でフォルダ内のテキストファイルを全て起動
メモ帳を起動する前に　太字とファントにして文字サイズを変更したい。
メモ帳を閉じたら、設定を元に戻す

どうしたら良いでしょうか？

2017/07/03(月) 15:16:40.85

落ち着け
フォルダをクリックしたらってのはエクスプローラ上でってこと？

フォントはメモ帳開く前にレジストリ変更、開いたら戻すって感じでできると思う

2017/07/03(月) 15:23:47.15

>>628
エクスプローラーの右側に有る奴です。

2017/07/03(月) 15:58:34.40

やゃ落ち着きました。

アクティブフォルダ（操作中のファオルダ）内にtxtファイル存在するか調べる。
もしも、存在するなら、Windows10のメモ帳で全てのtxtファイルを開く。
存在しないなら、何もしない。

メモ帳を開く場合
　　　　規定フォントかを調べる。
windows10付属の規定フォントで無いなら、規定フォントにする。
＿規定フォントなら、文字を大きくする。
＿次に太字にする。

メモ帳の開く場所をディスプレイ中央に設定する。

やりたい事はこんな感じです。

2017/07/03(月) 16:05:48.40

>>601
Zombie

2017/07/03(月) 17:26:05.31

>>630
アクティブフォルダを検知する手段が見当つかないけど
それをドロップされたフォルダ（指定されたパス）で実行するに変更ならすぐできるんじゃない？
１．指定されたディレクトリに*.txtがあるか調べる
２．見つかればメモ帳の設定をバックアップして変更>>628
３．メモ帳に*.txtを順次渡して起動
４．メモ帳が全て終了したら設定を元に戻して終了

**625** (ﾜｯﾁｮｲ 2e96-naxa) · 2017/07/03(月) 17:40:07.28

>>632
アクティブフォルダを検知する方法はボクも知らないです。

タスクバーに存在するフォルダがアイドル常態かどうかを調べて、
アクティブなら実行させる　とか考えました。

一日、数百回ほど、
フォルダを開くのに対してドロップ＆ドラッグは流石に勘弁して下さい。

2017/07/03(月) 17:43:31.54

>>633
じゃあフォルダ群を最初に全部登録して選択したもので実行するとか
とりあえず>>632の部分は必要になるから答えを待ちながら作った方がいいんじゃないかな

2017/07/03(月) 17:52:47.65

俺にはウィルスにしか見えないわけだが
こいつの目的は何なの?

2017/07/03(月) 17:54:07.35

DOSじゃないんだからOS全体でアクティブなディレクトリなんて存在しないと思うよw

2017/07/03(月) 17:55:34.21

アプリケーションにドロップしたディレクトリじゃ駄目なのかよ

2017/07/03(月) 18:00:01.58

まず現行業務フローの洗い出しができてないよね
１日数百回フォルダ移動してる暇な奴ってすでに俺には聞き込み調査か粛清が必要なレベル
プログラムを組むんじゃなくて
ローキックの連打で解決できそうな臭いしてる

**625** (ﾜｯﾁｮｲ 2e96-naxa) · 2017/07/03(月) 18:14:18.18

皆さん、いろんな意見をありがとうございます。

（笑わないで聞いて下さい。）
毎回落としてくる、エロ画像がボクの宝物なので、
大事にパスワードを設定してます。

開く時にパスワードを書いたメモファイルを何時も開き忘れるので、
フォルダを開いたと同時に表示して欲しいんです。

>>638
画像によっては属性が夢の様に、いっぱい詰まってるので毎回、移動させてます。

2017/07/03(月) 18:16:39.30

エクスプローラーもメモ帳も自分で作ればいいだけに見えるんだが・・・
それらの部品ならCodeProject漁れば出てくるよ

**625** (ﾜｯﾁｮｲ 2e96-naxa) · 2017/07/03(月) 18:17:23.61

フォルダにパスをかけなければと言う人も居ますが、フォルダにパスワードは必要です。
メモファイルは隠しフォルダにしたら何とか隠せますが、パスがついてない画像は
閲覧されちゃいます。

2017/07/03(月) 18:24:04.65

>>640に賛成
ディレクトリの位置に紐つけたパスワードのデータベース作ればメモ帳起動する必要もなくなる

2017/07/03(月) 18:28:02.02

>>623
> 強制ガベコレすると落ちるけどしないと落ちないときあるじゃん
>>605みたいなケースだろ
そうじゃなくて普通に使っててそんなことになると言うならサンプルコードあげてみそ

**652** (ﾜｯﾁｮｲ 2e96-naxa) · 2017/07/03(月) 18:34:05.18

>>642
メモ帳が必要な理由としては、コメント書いてるんです。
「今日も可愛いね」「その猫耳が似合ってるよ。」とか書き込んで、
後から同じファイルを開いた時に追加してコメント入れてるんので、メモ帳を起動させたいのです。

**625** (ﾜｯﾁｮｲ 2e96-naxa) · 2017/07/03(月) 18:35:12.16

間違えました。
652では無く、
625でした。

**625** (ﾜｯﾁｮｲ 2e96-naxa) · 2017/07/03(月) 18:46:56.71

現状では634の方法で行きたいと思います。
一部を保留にしながら、632にを参考に進めて行きたいと思います。

**625** (ﾜｯﾁｮｲ 2e96-naxa) · 2017/07/03(月) 20:33:26.13

レジストリを触りたくないので、メモ帳を起動後にフォントと文字サイズを変更
しようと思ってますが、やり方が見つかりません。

ファイル内に.txtが有るか調べる
ファイルを指定してメモ帳で起動するまで行きましたが、
起動後、メモ帳の設定の仕方が分かりません。
どなたか教えてくれませんか？

（ファイルへの書き込みと読み込みは結構、でてくるんですけどねｗ）

2017/07/03(月) 21:08:48.55

DLL AとAが参照しているDLL Bがあって、BでAのPOCOクラス使いたいんだけど循環参照になっちゃうからPOCOクラスをDLL Cとか別で定義するしかないよね？
C#なら別DLLにしなくてもいけると言われたんだが、どうやるのか見当つかない・・・

2017/07/03(月) 21:10:48.36

メモ帳だから出来ないんよ。
最低限テキスト編集機能しか無いからね。
ワープロじゃ無いから、テキスト編集さえ出来れば良い(高機能でも快適な編集が出来ればいい)ってのがテキストエディタ。
フォントとかはワープロの領分だよ。

2017/07/03(月) 21:11:02.19

>>648
Bに実装してAから呼び出す

2017/07/03(月) 21:15:30.82

>>648
AとBを一つのDLLにまとめる
どうせ切り離せないなら分ける意味ないでしょ

2017/07/03(月) 21:19:23.58

>>649
メモ帳にフォントと文字サイズの指定はあるぞ。
表示される文章全体に対してだが。

2017/07/03(月) 21:21:13.75

あったっけ。
ま、どうでも良いけど。

2017/07/03(月) 21:29:33.51

指定じゃ誤解を招くな。
そういうアプリの設定ね。

2017/07/03(月) 21:31:35.49

>>648
そうするしかない、というよりそうすべきだね。
俺は共通のenum一つのために別のdllに分けたことがありますw

2017/07/03(月) 21:34:16.70

>>650>>651>>655
やっぱり今のままじゃどうやっても無理だよね、サンクス

2017/07/03(月) 21:37:08.97

循環参照が発生した時点で設計バグなので楽しいリファクタリングタイムだ

2017/07/03(月) 21:52:41.27

んでまた資料も書かずに突貫工事でプログラム組んで余計ややこしいことになっちゃうまでが準備体操

2017/07/03(月) 21:57:30.38

あらゆる管理業務の負荷はコードの品質で天地の差が出る
循環参照してるようなクソコードのドキュメンテーションは地獄だ
リファクタリングしてからやった方がいい

2017/07/03(月) 22:01:47.75

そのリファクタリングが正しく出来なさそうだからまず資料作れって言ってんだよハゲ
っていう不毛な会話はもうしない
突貫工事が好きなところといい
きっと彼は土属性に違いないのだから

**625** (ﾜｯﾁｮｲ 2e96-naxa) · 2017/07/03(月) 22:32:44.15

てっきり無視されるかと思ってました。ｗ

フォルダを開くのを認識させるのは、どうしたら良いのでしょうか？
指定したフォルダを開く事はできても、これから開くフォルダを認識する事なんてできるのでしょうか？

質問ばかりで申し訳ないです。

2017/07/03(月) 22:35:33.59

>>656
よろしくないってだけで、無理ではないと思うが。

2017/07/03(月) 22:40:33.08

>>660
正しいドキュメントを書くことはコードを書くことよりはるかに難しい
循環参照するような破滅的コードが相手だとまともなドキュメントを工数に見合う時間で作れる見込みは少ない

そもそもコンパイラや静的解析ツールを利用して体系だった機械的なプロセスでコードの品質を高めて可読性を上げることができる
それがリファクタリングの中でも大きなメリットの１つだろ
そこへ来てドキュメントを書いてからリファクタリングなどというのは全く見当違いの馬鹿馬鹿しい行為なんだよ

ドキュメントを作るのはリファクタリングで整理されてドキュメント化可能な状態になってから
あるいは探索的リファクタリングで得た知識を忘れないようにドキュメント化する
なんにせよコードを弄った後の話だ

こんなこと普段からコードを書いてリファクタリングしてれば知識がなくとも体感的にわかることなんだけどね
この業界はコードを書かない自称エンジニアさんばかりでため息が出るね

2017/07/03(月) 22:42:41.27

>>663
せめて問題点がわかる粒度の表にするべきだと思うわ

2017/07/03(月) 22:46:38.52

>>663
お前、ドキュメント書いてからソース書いたことないな

異なる文化を持ってる会社と仕事したらボコボコにぶっ叩かれるな
設計書を完璧にfixしないとソースコード触らせてもらえないとこあんぞ
でも一度はそういうところに行くべきだと思う
きっと違った世界が見えるはずだ

2017/07/03(月) 22:50:03.47

どうでもいいよw
それ以上はチラシの裏に書いてよw

2017/07/03(月) 22:51:34.84

スタンダードはv字開発の方なんだけどな

2017/07/03(月) 22:58:15.68

リバースエンジニアリングは小規模でのみ通用する方式

2017/07/03(月) 23:06:11.28

>>664
リファクタリング対象を選ぶために、という理由でなら資料を作る意義はあるかもしれない

例えば複雑度、更新頻度、バグ密度などリファクタリングをする価値を判断できる数字というのは結構、ある
殆どのデータは自動収集できるものでレポートを手作りすることはないだろうが
ざっと目を通した時の難易度などは手作業の方が早いかもしれないね

でもね、リファクタリングの方法を探るために先に資料を作るというのは、ない
制限時間付きのパズルを解こうとしているのにまずはドキュメント？冗談でしょう
やるとしても、パズルを弄りながらメモ書き、程度でしょ

2017/07/03(月) 23:24:27.65

>>669
もうそれ設計でもなんでもねーじゃんｗ

2017/07/03(月) 23:24:29.30

>>665
ガラパゴスの国だからね
文化の違いは認めるよ
修正は設計書のレビューを通してからコーディングという現場に居たこともある
しかし徹底的なドキュメンテーションが正解だとは思わない
ドキュメンテーションには時間がかかるし統一的な記法も機械的な検証方法も無い
実際の挙動を決定するコードと同期しているか定かでは無い
何よりこの手の現場ではコードを弄るという探索的プロセスを軽視する傾向が強いことが問題だ

コードを弄らずにドキュメントだけ正しい状態に持っていこうとするということは
まるでパズルを頭の中で組み立てて手順を資料化するような馬鹿馬鹿しい行為だ
パズルに挑戦する人は誰だって自分の手でパズルを弄りながら考える
それと同じでリファクタリングの方法を考える人は自分の手でリファクタリングをしながら方法を考えるんだ
手を動かす前に思いつくようなアイデアはいつだって陳腐で使い物にならないものばかりだ

2017/07/03(月) 23:28:02.84

完成するかどうか分からんパズルと仕事をおなじにされてもなぁ

2017/07/03(月) 23:32:35.22

肉体言語の使い手だよね
メラ!（右フック!）

2017/07/03(月) 23:39:08.40

>>670
そもそも設計ってなんだと思う？

俺はビルドを実行する前までのプロセスが設計だと思う
コーディングは設計フェーズでコードは設計書
製造はビルダーの仕事

俺らが作るものは最終的には動くプログラムなんだよね
それでコードはそのプログラムがどういう仕組みでどういう風に動きますっていう定義をずらずらと書いたものだよね
それってまさにプログラムの設計書じゃないか

じゃあ世間の言う設計書ってなんだって話だけど
俺からするとそういうのは設計概要とか設計方針の方がしっくりくるんだわ

2017/07/03(月) 23:41:12.61

どっちのいいぶんもまぁわからんでもないが結局プロジェクトの規模によるんじゃないの？
みんなだいたい一人どれくらいのプログラムの量かくの？

2017/07/03(月) 23:41:26.60

宣言型言語で書くならそうだが、普通コードは命令書であって設計書じゃない。

2017/07/03(月) 23:42:46.19

>>673
もう投了ですか？

2017/07/03(月) 23:49:00.34

>>674
いやぁさすがにそれは詭弁にしか聞こえない
だってお前のは材料数も期間もなんもでねーじゃん
ただ単にパズルが解けるまで遊んでるだけで最悪なんの成果もないわけじゃん

2017/07/03(月) 23:51:24.33

>>676
世の中の多くの設計書が手続き(命令)的な書き方をされてますよね
年配のCOBOLエンジニアさんが書く設計書などがまさにそうですが
あれは設計書ではなかったと

2017/07/03(月) 23:52:11.27

だいたいリファクタリングとか言ってるけど
ここまで来てそんな問題起きちゃうのはただの設計ミスだよね?
設計書から完成させる文化の仕事受けて１回軍法会議にかけられて死ねばいいよ

2017/07/03(月) 23:53:02.74

ひとつの型が唯一解とは思わないが設計書は必要だよ
コーディング以降は各テストレビュー完了毎にメンテナンスするくらいの頻度でいい

アルゴリズムの伝達にプログラム要素は含まれない

2017/07/03(月) 23:59:24.25

>>678
現実的な時間で終わるかどうかの見極めはコード弄ってればすぐにわかるよ
むしろコード弄らずにドキュメントベースで話を進めると簡単だと思ったら実は思ったより時間かかりました～なんてことになる
悲しいけど世の中そんなプロジェクトで溢れかえってるのが事実なんだ

2017/07/04(火) 00:00:45.70

>>679
COBOLの設計書ってコード設計という名のコーディングシートを除けばわりと宣言的だぞ
関数型に近い

2017/07/04(火) 00:00:55.20

>>680
断言するけどそんな設計書はありません
就職すればわかるからそのあと出直してきな

2017/07/04(火) 00:03:06.32

>>682
それを外したからリファクタリングなんて名前の設計ミスの修正をやってるように見えるんだが?

2017/07/04(火) 00:10:19.18

>>681
概要を素早く把握するには設計書はちょうどいい文書だと思う
しかし概要を超えた明細はコードで語るべきだ
コードを直す前に必ず設計書修正しろなんてパラノイア的なやり方は負担を増やすだけで利益は少ない
コスト意識のない完璧主義者に付き合わされるのは苦痛だ

2017/07/04(火) 00:14:55.81

>>683
そうなのか
うちのCOBOL経験者はJavaのようなOOP言語でもコテコテの手続き的な設計書を書くよ
まあ人によるってことだろうね