ふらっと C#,C♯,C＃（初心者用） Part137
■ このスレッドは過去ログ倉庫に格納されています
「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、
質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスはやめてください
>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。
■関連スレ
C#, C♯, C＃相談室 Part95
http://mevius.5ch.net/test/read.cgi/tech/1508180530/
C#, C♯, C＃相談室 Part93
https://mevius.5ch.net/test/read.cgi/tech/1492818720/
■前スレ
ふらっと C#,C♯,C＃（初心者用） Part136
http://mevius.5ch.net/test/read.cgi/tech/1520057345/
■コードを貼る場合は↓を使いましょう。
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 >>208
それなら納得
existsの宣言の位置を移動するとif(!exists)がスコープから外れちゃうもんね
>>209
>>204の方法で解決したんなら>>204の指摘が正しかったんでしょうよ
で、それに気づかなかったんならやっぱり例外が握りつぶされてたんでしょ
なら今後のためにも原因は分からずで片付けず例外の名前くらい確認しといたほうが良いと思うよ オブジェクト指向のプログラミングでは
変数じゃなくてプロパティにアクセスさせるべき
みたいな事をよく聞くんだけど
・プログラムの開始時にあるフラグ(true/false)を決めて、その後一切変更されることがない
・そのフラグには、コード中の様々な所からアクセスがある
って場合は、プロパティじゃなくてpublicな変数でフラグを定義してもいいんですか？
オブジェクト指向がよくわかってないせいか
プロパティを経由するのがどうしても遠回りというか
一つ余分な作業を挟んでるように感じてしまう・・・ 変数は、公開しちゃダメ
その変数に、誰かが代入するかも知れないと考えると、
その変数に代入しているか、すべての場所を確かめないといけなくなるから、
プログラミングできなくなる
だから、プロパティで代入禁止に設定する
ただし、絶対に代入できない定数なら、公開してもよい >>212
後から書き換えられるのを確実に防止するために
プロパティを使うってことか なるほど
1人でコード書いてるからそういう発想が無かったけど
自分も後から絶対変な値を代入しない保証ないもんな
てことは、>>211の例だと
・引数付きのコンストラクタを使って、フラグの状態をインスタンス化
・そのフラグのプロパティはgetのみ設定
ってすればいいのか？
でもこれだと、そういうフラグを立てるタイミングがたくさんあったら
その分だけクラスを準備しとくことになると思うんだけど
そういうもんなの？ あ、いや
クラスを複数準備する必要はないな
>>213の後半の話は無しで >>211
212は読まなくていい
フィールドだってreadonly修飾子で代入禁止できるが、212はそんなことも分かってないから
プロパティがフィールドと違う点は大ざっぱに
* 派生クラスでオーバーライドできる
* プロパティから構造体を返すとコピーされる
の2点
この2つの特性が必要ない(または避けたい)場合にフィールドを選択してよい
判断できないならプロパティを選択する >>215
>* プロパティから構造体を返すとコピーされる
これが、全然分からんのだけど
classの代わりにstructを使った場合の話であってる？
今の自分が考えたところで、どうせちゃんと理解出来ない気もするけど >>212は別に全く問題ないだろ。
>>211の要はカプセル化の質問に対して、>>212はカプセル化の話として一般論として答えただけじゃん。
それに対して>>215と>>217はここはC#のスレだからC#特有のreadonlyなフィールドあるよとか言語依存の情報
つけ足してるだけじゃん。 オブジェクト指向では、変数は公開しない。
公開できるのは、処理(関数)だけ
クラス内を開発する人と、そのクラスを使う人は、別の会社・人を想定しているから、
変数にアクセスさせたら、絶対にダメ
クラス内を作っている開発者は、後で付け加えられる処理を予想できないから。
クラス内を開発した後に、別人が変数にアクセスして、動きを変えたらバグる
異なる会社間での開発を可能にする、
オブジェクト指向の大原則・カプセル化 プロパティから構造体を返すとコピーってのは意味わかんないね
コピーされるのは右辺がプロパティだろうがフィルドだろうが同じだよw
>>211
少なくともパブリックなメンバーに関しては、あえてフィールドを使う理由はないって
理解でいいと思うよ。例外はアンマネージドコードの呼び出しで使う型を定義する場合ぐらい。
フォールドのプロパティーに対して優位な点は
(1) 軽量である
(2) 簡潔に書ける
このぐらいしかない。
(1)が重要なケースなんかまずない。
(2)については、古いC#はともかく今のC#は儒分簡潔に書けるようになって来てる。 >>220
カプセル化っていのは、触る必要がないもの、触られては困るものを隠すこと。
この質問にはほとんど関係ない話w
フィールドをプロパティにしようが、触る必要がない文脈で触られることを防げるわけじゃないw
せいぜいセッターで値が適切かどうかチェックできる程度 まぁ、むしろ>>211のカプセル化などの話に対して、考え方説明せずに
初心者にいきなり言語仕様の詳細を羅列する>>215の方が教え方としてははぁーー??だわww >>222
質問者は
>オブジェクト指向のプログラミングでは
>変数じゃなくてプロパティにアクセスさせるべき
>みたいな事をよく聞くんだけど
で書いて始めてんじゃん。だから、カプセル化の説明した方がまずいいんじゃねぇか？？ >>224
何が「だから」なのかよくわかりませんw
質問は外部に見せるデータをプロパティとして実装すべきかフィールドでもよいのか。
カプセル化（余分なものを外に見せるな）は何も関係ないってw >>224
>オブジェクト指向のプログラミングでは
>変数じゃなくてプロパティにアクセスさせるべき
>みたいな事をよく聞くんだけど
を質問者が引き合いに出した以上、質問者はここからはしっかりわかってなくて、色々ごちゃ混ぜになってると
思われる。だから、そっから説明しなきゃ、おそらく習得できない。 自分はオブジェクト指向じゃない言語をちょっとだけやってたんだけど
そういう言語では、コードの最初の方に
public bool JudgFlag = true
って1行書いて、それにどこからでもアクセスするみたいな感じだと思うんだ
（全部独学だからこれも正解なのか知らんけど）
でも、オブジェクト指向ではこれやったらダメなんだよね？
ってのが知りたい
後、俺マジで初心者だから
質問文で聞きたいことが正確に表現できてる保証ないｗすまん >>227
別にダメじゃないよw
何度も言うけど、あえてフィールドを使う理由があんまりないだけw
フィールドをプロパティにしたらバグが減らせるとか可読性が上がるとか、
ほとんどの場合そんなことはない >変数じゃなくてプロパティにアクセスさせるべき
これが異なる会社間での開発を可能にする、
オブジェクト指向の大原則・カプセル化
どの教科書にも書いてある
その理由は、クラス内を開発している会社・人と、
そのクラスを使う会社・人は、異なっているから
オブジェクト指向では、これらの2つの立場からの見方が大切。
君はどちらの開発者ですか？
クラスを作る方・使う方？
クラス内を開発しているのは、過去だから、
そこから未来の、クラスを使う人の動きを予測できない
だから、変数に直接触らせたらダメ。
そこまで予測して、クラス内を作れないから >>229
そうなのか・・・
でも、解説サイト見てると
「ダメ」的な雰囲気で書いてあるとこばっかりじゃない？
俺の理解が間違ってるのかもしれないが
俺的には現状>>229に書いてある事が正解に思えちゃうんだよな
俺が1人で小規模な開発してるだけだから
いまいちオブジェクト指向のメリットを感じる場面が少ないのかな >>227
>public bool JudgFlag = true
変数を公開したら、ダメ。
カプセル化にならない
理由は、
>>212
に書いてある >俺が1人で小規模な開発してるだけだから
>いまいちオブジェクト指向のメリットを感じる場面が少ないのかな
まあこれだな
>>212の言ってる事は、OOPの「思想」としては間違いなく正しい
但し、単独での小規模開発という状況を前提にするなら「現実的なメリット」は無いに等しい >>227
うん。君のケースだとダメだね。それだと、クラスの内部状態JudgFlagが誰でも自由に書き換えられちゃう。
だから、まずは君は基本、>>220のようなC#とか言語関係ない一般的なカプセル化について勉強しよう。
で、君のケースだと自分で書いてるが
>・引数付きのコンストラクタを使って、フラグの状態をインスタンス化
>・そのフラグのプロパティはgetのみ設定
ってやるか、
getプロパティ書くの嫌なら>>215が書いたようにC#にはreadonlyフィールドというのがあるのでそれで代用できる。 おまえら変数は公開しちゃだめだけど、プロパティやgetter/setterなら公開してもいいって思っとるやろw >>231
どこの世界でも教条的（思い込みが激しいともいう）人はいるからねw
外部から取得/設定してもらう必要がある値をフィールドではなくプロパティにしたからって
ヒューマンエラーを減らす効果なんかないのは事実
ただ機能がより少ないフィールドをあえて使うことないでしょってだけの話
オブジェクトの公開するデータは必ずしもいつも変数に入っているわけではなく、
何らかの処理の結果を返す場合もあって、その場合はプロパティになるから、
だったら全部プロパティの方が統一感があるという考え方はあるかもしれない まとめると
「1人で小規模なコード書いてるだけなら
public bool JudgFlag = true
を書き換えたらダメなことぐらい自明だから、フィールドに1行書いて終わりでいい
若干雑だけど楽」
って考え方と
「いや、自分で決めたルールを自分で忘れることもあるから
ちゃんとプロパティにして触れない様にすべき
多少面倒でもコストを払うメリットがある」
って考えの対立なのかな
get;set;とか全く意味がわからなかった頃の嫌なイメージのせいで
プロパティを書く事が、「面倒・難しい」って体が拒否反応しちゃうんだよね
自動プロパティとか実装されてる今の時代に
何言ってんだって笑われそうだけど
まあ、でも色々モヤモヤしてた所がスッキリしました
ありがとう フォーム間のデータ受け渡しのやり方について教えてください
プログラムを起動して、最初にForm1でパラメータなどを設定、次にForm2で設定した
パラメータを元にデータを編集したいとします
（Form1で編集済みのデータをForm2に表示する、でもいいです）
このときにデータを受け渡すのは、program.cs で Application.Run(new Form1()); と
呼び出す前に
1. Form2 のインスタンスを作っておいて、それを Form1 の引数として与えてやる
2. 必要なデータのインスタンスを Main() 内に用意しておいて、そのインスタンスを
Form1 と Form2 のそれぞれに送る
3. どっちもダメで他の方法がある
のどれが良いのでしょうか。
Form1 の中で Form2 のインスタンスを作成して、Form2 に送るという方法も考えましたが、
そうすると Form1 が不要になったときに Dispose() すると Form2 も落ちてしまいます。 >>240
それは右座標を計算して返しただけであって処理を実行するのとは違う
面倒だからここ読んで
https://msdn.microsoft.com/ja-jp/library/ms229054(v=vs.100).aspx >>241
Form2にプロパティを追加
Form1の該当メソッド内でForm2を宣言＆インスタンス化してプロパティにパラメータをセット
Show(Dialog)メソッドで呼び出し メッセージキューを勉強中なんですが、
MSMQとMessageQueueクラスって何が違うんでしょうか？ >>244
ありがとうございます
この場合、もう二度と Form1 を使わないという状況であれば、Form2 の ShowDialog を
呼び出す前に this.Hide(); で隠しておいて、戻ってきたら this.Dispose(); でしょうか
Hide() だけで処理を抜けるコードを書き忘れて、いつまでもプログラムが残り続けるバグを
やったので、二度と戻ってこないフォームは Dispose() したいのです 今思ったのですが、そういう使い方だとむしろ Form2 を非表示で実行しておいて、
その中で Form1 を呼び出すべき？
で、Form1 を抜けたら this.Show(); とか >>243
頭悪そうだけど、単にバッキングフィールドの値をそのまま返すのではないケースを
「何らかの処理の結果を返す」と言っている。
処理 = 高価な処理ではない。
重かろうが単なる足し算だろうが処理は処理だ Applicationに共通のパラメータ持って、Form1とForm2で共有しちゃダメなんか 使い方次第じゃないかなとは思う
双方で同時に書き換えたりするならやめたほうがいい
それ以前にタダクソダサイと思う 自作ツールをソースコード付きで公開したいのですが、
パブリックドメインソフトにするのが最善ですか？ .netで簡単に実現できる機能（メールや圧縮、画像処理等）をネイティブCのアプリで利用したいです。VC++6.0の（C++ではなく）C言語で作るコンソールアプリでです。
C#で作っでdllを作って、C++のdllでそれをコールする関数を公開すれば実現可能ですが、もっといいやり方ないでしょうか？ >>254
今のOSSはMITライセンスでGithubに晒すのが主流 >>255
別プロセスにする
Win10のアプリなら WinRT のコンポーネントにすれば言語をまたがって普通に使える >>255
標準入出力のリダイレクト。
古典的でダサいけどね 皆様ありがとうございました
決まりきった定番の書き方はない、と理解すれば良さそうですね
自分で色々試してみます 今度はインデクサについて教えてください
https://ideone.com/TlRwJS
例として上記のようなコードを書いてみました
これで、インデクサを使って例えば anml["whale"] とすれば1が返ってくるような、
そういうものを作りたいと思います
（classified, lifeの各プロパティはユニークではなく、specificのみユニークとします）
本を紐解きながら書こうとしたのですが、animalsクラスの中ではリストになっていないので
書く場所はなさそうです。でもMainメソッドでは利用したい側なので、ここに実装することも
できない気がします。
多分インデクサの考え方そのものがわかっていません。どなたか教えていただけると
嬉しいです。 ListじゃなくてDictionaryを使えばOK anml.FindIndex(_ => _.specific == "whale")でよくね？ インデクサてのは自作のクラスにつけるプロパティみたいなものだから、List<animals>を内蔵するクラス作って
public int this[string p]{
get{ /* ここに検索して結果を返すコード書く */ }
}
でおkなんじゃねか？知らんけど。 >>262
すいません、理解のレベルが低いので、具体的にどう実装すればよいのかわかりませんでした
var anml = new Dictionary<animals, string>;
としてディクショナリは実装できたとして、要素追加の際 Add メソッドをどう書くのか、理解が
追いついていないようです
>>263
この書き方で、求めている操作は実現できそうです
ラムダ式の理解が怪しいのは勉強するとして、毎回これを書くと面倒＆間違えそうなのですが、
これは「十分に簡潔な書き方」なのか、それとも「メソッド等でさらに簡潔に書ける」のか、どちら
でしょうか。
>>264
この場合、各プロパティにアクセスする際は anml[i].specific とかではなくて anml(i, specific)等
メソッドを介してアクセスすることになるのでしょうか？ >>264は良くないよ
インデクサはループ内で使用されることを想定しておかないといけない
毎回線形検索が走るのは非効率すぎる 番号が欲しいのかanimalsオブジェクトが欲しいのか >>266
今回の用途では速度は重要でなく、またそもそも実現方法がわからなかったので、アルゴリズムはまだまだ先の話ですね
>>267
今回欲しいのは数字です Index番号が欲しいなら>>263で十分じゃないか？
見つからなかったとき例外吐くらしいから気をつけろい まちがえた。例外じゃなくて-1だ。すんまそ。回線で首吊ってくる XAMLファイルからボタンを削除した場合、CSコードの方に呼び出されることのないコールバック関数の宣言が残ってしまます
こういうのを効率よく削除する方法ってないのでしょうか？ >>273
Xamarin.Formsで使っています ここでいいのかわかりませんが、質問させてください。
C#でフレームワーク ASP.Net MVCで作っています。
テーブルのフォームをPOSTしたいのですが、
動的に作成した行をどのようにサーバー側で受け取ればよいのかわかりません。
<td>
<input class="form-control" id="no1" name="no2" type="text" value="" />
</td>
<td>
<input class="form-control" id="no2" name="no2" type="text" value="" />
</td>
このように、複数行があって、noの後ろの数値は、行を追加したら増えるように
javascriptで制御しています。
サーバー側の処理として、引数を
(string no1, string no2, ･･･)と列挙してすべて書けば、
POSTデータを受け取れることは確認済みです。
ただ、ユーザーの操作で行を何行追加するかもわからず、あらかじめ想定する
最大数の引数を列挙するのも現実的ではありません。
すべてのフォームデータを一挙に受け取って、
サーバー内部のロジックで処理する方法はないでしょうか。 どうせJavaScript書いてるんならJavaScript側でJSONの配列に纏めてからAJAXでポストするのもアリ [[[ ][ ]]]\[[]] [[[]]]],[[[ [][] ] Entity FrameworkでDBへのselectとかのリトライしたい場合ってどのようにすべきでしょうか
一時的なエラーだったりしたらもう一回トライとかしたいのです
例外全キャッチするのも無駄なのかなぁと思いまして 普通のRDBなら一時的なエラーなんか滅多にないだろ
400でいいよそんなもん >>280
DbExecutionStrategy [[[ []]]]*[[ [][] ][] } } {} [[[ 人間はILコードを覚えてハンドアセンブル出きるようになるべき winformの左辺や上辺をドラッグするとフォームのサイズが変わらずにフォームが移動してしまいますが
サイズを変更するように設定するプロパティなどはありますでしょうか
コードを書く必要がありますか？ >>288
古い脳の感覚でいえば、IL なんてハードウェアの裏づけのない、空想上の約束にしか過ぎないので、覚える気が起きない
x86-64 でおなかいっぱい >>291
CASL くらいはやったよ、8080、z80/6809/80x86/ｚ8000/r3000、まだ若かったからどんどん覚えることができたんだ…
でも、もうおなかいっぱいだ… 次元が違うだろ
ILは高級なオブジェクト指向言語
そもそも機械語に似せることを意図されていない >>293
ハードウェアマシン語とプログラム言語との間に、なぜ仮想マシンと仮想的な言語(IL/JVM)が採用されるようになったのか？そこが今でも判然としないのです… >>294
ドライバは何故存在するの？つってる様なもんだぞそれ >>295
いえいえ、階層性を全否定するわけではありません
「仮想マシンと中間コード」の必要性を問うているのです… 仮想マシンに焦点を絞るなら、ハードウェアの差異を吸収する為では
（.netはJavaVMほどあちこちに移植されてないというだけで）
ILに関して言えば、複数の言語（C#、VB.net、F#、他）を共通のフレームワーク上で動かせる様にする為 >>297
それならハードウェアや言語の統一を目指したほうが建設的なのでは？ >>298
不可能だろう
収斂進化により表面上似た様な機能を搭載する事はあっても、内部構造は特許なり権利なり絡んで来るから同じに出来ないし
JavaScript+CSS3ですらブラウザベンダ間で足並み揃えられないのに、言語の統一なんて出来る訳が無い 現状、中間言語側でも少なくとも JVM/.net framework にわかれちゃっているからねえ… >>301
LLVM はコンパイラの中で完結しているのではないかな？ >>302
コンパイラ開発者はとりあえずLLVM-IRに変換すればいいし最終段で機械語に変換するか直接実行するか他の言語のコードに変換するかは自由
というか最初と最後だけ作ればいいわけだから寧ろLLVM-IRが中心 >>304
うん、それはよくわかる
すべての「構造化」を全否定するわけではないんだよ ■ このスレッドは過去ログ倉庫に格納されています
