ふらっと C#,C♯,C＃（初心者用） Part150
レス数が1000を超えています。これ以上書き込みはできません。
!extend:checked:vvvvv:1000:512
次スレを立てる時は↑を2行冒頭に書くこと（1行分は消えて表示されない為）
「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスや酔っぱらいレスはやめてください
>>980を踏んだ人は新スレを建てて下さい。>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。
■前スレ
ふらっと C#,C♯,C＃（初心者用） Part149
http://mevius.5ch.net/test/read.cgi/tech/1608085775/
■関連スレ
C#, C♯, C＃相談室 Part94
https://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/
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
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured コンソールでRPGみたいなゲーム作ろうとしてるけど
クラスの作り方がいまいち思い浮かばない
例えば
レベルアップした時にHPとかMPとかのクラスのフィールドをいじりたいけど、レベルクラスに入れるとステータス取るときに毎回status.level.hpみたいにレベルを通らないといけないのが厄介
かといってステータスクラスの中にレベルクラスとHPクラスを内包してしまうとレベルクラスのメソッドが呼び出された時にhpクラスのメソッドが呼び出せない…(staticはなしとして)
どうすれば良いのだ レベルやHPをクラスにしたい理由は？
どういうメソッドを想定してるの？ >>3
単純に、ステータス、レベル、HP、MPをメンバ変数に持つクラスにすりゃええんちゃう？
レベルアップメソッドを呼ばれたら、それぞれを更新するだけ
最初は難しく考えないで、ありのまま設計して実装してみる
で、破綻しそうなら設計を変えて再実装
そういう試行錯誤も楽しいかもよ ゲームはすべてのリアルタイムデータをエクセルに並べるつもりでプログラムを組め
物体同士の相互作用処理が一番多くてかつそれが7つも8つも同時に関わるので
オブジェクト指向言語の機能が役に立たないどころか悪影響すら及ぼす
絶対に使わないほうが楽に組めるぞ
まあ、まずやってみろ でもまあ、とにかくやってみるってのには賛成。
根気よく続けて、それにちょっとした向上心があるなら、そのうちそれなりにはなる。
>>3 の人は、直接的なアドバイスを求めてるんだろうけど、ちょっとアドバイスしたくらいでどうにかなるようなもんでもないなぁって感じ。 >>3
オブジェクト指向言語だからクラスは物、オブジェクトであって、
RPGのキャラはそれぞれステータスを持つオブジェクト＝クラス。
キャラにはステータスがあるなら、それぞれのキャラクラスにはステータスクラスが保有されるべき。
・・・などと自分なりに整理して、設計してみてはどうか。
その設計で厄介なことがあっても、設計に納得出来るなら、それは通るしかない厄介事なのかもしれない。
それを回避したり厄介を軽減する手段はいろいろ有ると思う。
やってれば身についてくる。その過程がまた楽しい。
設計が正しいかどうか、それは自分が決めればいいが、想像が付かないなら書籍を漁る。 3だけど
一応4回くらい違う設計で同じ処理のコードを作ってみたんだが、やりたいことは
親クラスに子クラス1,2がいて
子クラス1のフィールドが更新されたとき、子クラス2のフィールドを更新したい
一応現状はref使ってインスタンスされてる子クラス2のアドレスを保存して子クラス1で間接的に更新してるけど
子クラス3,4,…って増えた時に毎回コンストラクタの引数変えて処理追加させるのは冗長的だなぁと思って違うやり方したいと考えてるけど思いつかない… >>4
パラメータクラスに最大値、最小値、現在値をプロパティで持つようにして
HP、MP、LV、EXP、クラスをパラメータクラスを継承して作ろうとしてる
さいごにステータスクラスとしてHPからEXPをフィールドに持つようにしてコンストラクタでインスタンス化させるようにしてる class Prameter{
private int _Max;
public int Max{
set MaxUpdate(value);
get return _Max;
}
protected virtual
void MaxUpdate(int val){
_Max=val;
}
最小値も上と同様
現在値も上と同様※
}
※少し実装とは違うけどざっくりとしたらこんな感じのクラスを現状HP,MP,Level,exp全クラスにそれぞれ継承してる
レベルアップとかは現在値の更新時処理のoverrideで処理変えたりして実装してるんだ >>6
やっぱりそうか。Cのような関数での設計なら単純で作りやすいんだがオブジェクト指向の練習と思ってやってると意外と難しかった。
ちょうど7つも8つもパラメータが増えてきていちいち引数変えたりするの面倒やしクラスにするメリットがあまりないな… >>13
7つ8つはパラだけじゃなくてオブジェクトもやぞ
アクセスを限定するオブジェクト指向言語の機能は絶対に役に立たん >>11
ステータスクラスがHP, MP, LV, EXPの最大値、最小値、現在値をそれぞれ直接int等で持つ構成と
ステータスクラスがHP, MP, LV, EXPの各クラスのインスタンスを保持する構成とを比較して
後者にどういうメリットがあるのか、もしくはないのかを考えればいいんでないのかな？
>>10
>親クラスに子クラス1,2がいて
親クラス・子クラスという表現は一般的に継承関係を指すので
あるクラスが別のクラスのインスタンスを保持してる場合は親クラス・子クラスという表現は使わないほうがいい
>子クラス1のフィールドが更新されたとき、子クラス2のフィールドを更新したい
今回のケースで使うべきかどうかは微妙だけど
フィールドが更新されたときにそれをイベントとして通知するようなパターンを使えば
クラス1のコードでクラス2を参照する必要がなくなって通知先が増えてもクラス1を変更しなくてよい https://paiza.io/projects/jSt0Q60s11SN8n8JJzO_7Q
これ、とあるゲームのキャラクターステータスだけどベタなキーバリューペアで管理してる
スキルや装備によってバトル中のHPや攻撃力/防御力とかが変化するから本来の値と底上げされた値は別項目で管理されてる 何か既存のRPGでやってるステータス計算の再現なのかな。
C#の仕組みを凝ると、デバッグが怖そう。 なるほど、
皆様、様々なアドバイスありがとうございます。
特に親、子クラスとかのニュアンスや使い方の指摘はありがたい。
ちなみにゲームの再現はしてないけど、イメージはCUIのドラクエのイメージ。それをオブジェクト指向の練習としてクラスで作ってみようとして一番最初で詰んだという経緯っす。
メリットデメリットは正直オブジェクト指向が初めてだからよくわからないってのが本音。ただ知識として幅は広がってる気がする。MVCモデルとかで実現するのかなーとか考えたりイベントをリストで管理するのかなーとか色々模索はしたけど結局いい感じにならず苦難中。 最初はあんまり沢山クラス作らない方がいいかと思う
段々とここは分離した方がいいとか継承した方がいいとか分かってくるので
とにかく動くものを作れるかどうかで勉強するにしても先に進めるかどうかの分岐点になるからな オブジェクト指向の学習が目的なら、ポケモンで学ぶオブジェクト指向みたいなのがいくつかあるから
そういったPOSTを眺めるとなんとなく雰囲気がつかめるかもしれない ゲーム自体があんまりOOP向きの題材じゃないかもしれないよ。
モデル化する必要があるのはゲームの世界を成立させている「舞台装置」
であってプレーヤーの目に見える表層的なキャラじゃなかったりすると思うんだけど
前者は得てして抽象的な存在になるし、どうしても後者に引きずられてしまう。
知らんけど。
大昔シューティングゲームとかボードゲームがいかにOOP向きじゃないかって
論争があったねw そうか…
既にOOPに対して嫌悪感を抱き始めるこの始末。
とはいえ継承ができたりオーバーライドして変更したりできるのは良いね
〇〇/××って形の表示するのもは全部同じパラメータクラスで扱えるし、ちょこっと変えたいとなるとオーバーライドで消したりオーバーロードで処理増やしたりできるもんね。
うーん、やっぱC#はよーわからんw ちなみに、C#(プログラミング)初心者が理解しやすそうな題材ってあります？
まだhelloworldから変数作って弄るよりかはゲームのほうが楽しめるんかなと思ってそれで始めたらドツボ入ったんだよね。
難易度も低めが良いけど…(マルチスレッドやGUIでないようなもの) どういうものを最終的に作りたいかによるけどゲームが目標なら
最初からUnityで勉強するのもアリかなと思う
勉強ならコンソールアプリの方が文字だけの世界だから分かりやすいけど
最初からWinFormsのプロジェクト作ってボタンやテキストボックスなど配置して
GUIのアプリのつくり方を勉強するのも良いかも知れない
GUIだとButtonにはClickイベントが、TextBoxにはTextChangedイベントがあるとか
（デザイン画面のボタンなどをダブルクリックすれば、上記の説明した一番使うであろうイベントの
実装が追加されるようになっている）
そういうイベントにより処理を行うみたいな形になるので、リアルタイムのゲームとは違った感じになるかと
どっちにしてもプログラムしてみて動かしてを繰り返し出来る方が望ましいかな なるほどなー
よく考えたら最終的にはGUIのアプリケーションプログラムが作りたいと思ってた。ゲームは特に好きじゃないけど好きな人が多そうだから説明する時にも役立つかなとは思ってゲームにしてた具合。
先にFormやるのもありかも いろんな種類のキャラを動かす系のゲームはOOPに向いてると思うけどな
実際そういうゲームのほとんどがオブジェクト指向で作られてるわけで
プログラミングを学ぶ目的に適してるかと言われると微妙だが >>27
向いてない
オブジェクト指向って
オブジェクト同士の処理を綺麗に書く
ように作られてない
全オブジェクトが存在するシーンにほぼすべての処理を記述することになる
マップ情報がないとキャラは移動すらできないことがすぐにわかる
ではマップとキャラのデータが混在した処理をどこに記述するべきか？
シーンに決まってる
なのでゲームシステムに関わるほぼすべての処理をシーンに記述することになる
もう仮にオブジェクト個別の処理が2～3個見つかった程度で個別のクラスなんかに書くのはバカってぐらい
全部シーンに書くことになる 言語そのものよりライブラリに何があるのか把握しきれなくて辛い。
自分でクラスを作ったら、もう既に.Netにあったりするし。
辞書を熟読するような事前の勉強が必要なのかな。 >>29
わかる。会社に入るとドキュメントの無いライブラリも加わる。 ゲームって普通にOOP学習にはもってこいじゃね？
一見全く種類の違う自キャラや敵やNPCなどを一つのベースクラスから派生させたりとかオブジェクト指向の有難みを享受しやすいジャンルだと思うけどな
まぁそういうことせずとも一度C言語を使ってみればC#を使ってる時点でデフォでめちゃくちゃオブジェクト指向の恩恵に授かってるというのを認識できるけど ゲームだと単純に楽しいし、良く知ってる世界だし。
異世界小説が流行るのも、みんなリアルよりゲームのほうが詳しいからね。 ゲームはOOPより関数型のがやりやすい
OOPだとゲーム状態が大量のオブジェクトに分散してしまい管理が追いつかなくなる unityやwpfで何か作ったらいいんじゃない？
嫌でもOOPを使うことになるし Unityはやめといたほうがいいんじゃん？
ゲーム特有の定石が多い上にあまり公開されていないので、なかなかOOPを活かせるようなコードが書けるもんじゃない なんか作るとき、ついつい無駄にインターフェース作ったり、クラスを継承させたりしたくなる。
後で使うかもって置いといても、結局、役立たずで無駄になったり。 質問です。
'string[][]'と'string[*,*]の違いは何ですか？
List<string[]> lists = new List<string[]>();
を
string[,] = lists.ToArray();
で二次元配列にしようとすると、
CS0029: Cannot implicitly convert type 'string[][]' to 'string[*,*]'
とエラーが出て困っています。 >>41
なるほど、理解出来ました。
ありがとうございました。 >>38
「いつか使うだろう」という動機で作る機能の9割は結局使われないという法則があってだな でも、ついでだし作っとくか、で作ったやつがその後のバグ対に効果大なこともあったな。結構。
「起こる可能性のあることはいつか必ず起こる」ってのはマーフィーの法則だっけ。
アタマの片隅にでも置いておくと、後で助かることがままある。 一人で作ってるならいいんだけど別の人が対応する時に混乱させるだけなことが多いからな
チーム開発では起こらないことを無駄に考えてしまうのはよくないって場面の方が多い 個人的には>>45に同意
要件レベルだと「いつか使うかも」で入れた機能はゴミでしかないが、
開発者が気を利かせて入れたものは役に立つことが多い >>47
センス悪い奴って絶望的じゃん
ユースケースを脳内で構築できないっつーの？ 必要になると思って書いておいたプロパティやメソッドが結局まったく使われなかった、
っていうのはないことはないと思う。
YAGNIって普通はこういう話じゃないの？
>>38が言ってるような要らんInterfaceや要らん継承関係を作ってしまうって
YAGNIとちょっと違う気がするし、そもそも普通はあんまりやらん気がするなあ。 コードレベルで呼び出されないのと運用上使用されないのは別問題だよ
前者はほぼ例外なく無駄無価値無意味なんで、俺がコードレビューするなら基本的には消させる >>44-50
横から便乗で質問ですけど、
「いつか使うだろう」とインターフェースや継承関係を作っておく自体は推奨されることですか？
例えば、インターフェースや継承関係が無くても、直付けで作れてしまう訳じゃないですか。
むしろ、そっちの方が楽（というか、直付けでしか作れない人もいますし）。
ただし、物事が複雑化してきたときに、インターフェースや継承関係があると拡張しやすい。
これって上級者なら、（どんなに小さいプログラムだろうが）常にインターフェースや継承関係を作った方がいいのか、
それとも、ケースバイケースで「このぐらい複雑ならインターフェースや継承関係が要る」という判断基準に則って作った方がいいんですか？ >>51
すれ違いになりました。
議論スレ、行きます。 >>52
推奨する人は確実にいないと思うよ。
「ついやっちまう」ことも普通はまずないんじゃないか。
IClonableみたいな実例があるから皆無とも言えないけど。 Seleniumで closeとquitをセットで使ってましたが
quitさへ使えばプロセス残りも防げて万能という認識で良いでしょうか？ というのもなぜか、最近アップデートされたChromeドライバーのバグなのか
driver.close();を実行するとやたらと時間が掛かる様になり、ストレスを感じています。 演算子のオーバーロードを定義したクラスを継承してそのクラスのオブジェクト同士を足したりしたいんだけど、
継承した子クラス同士足し算してもオーバーロードしてるのが親クラス返してエラー出る…
なんとかなりませんか… >>57
当たり前のことが起るべくして起こってるようにしか聞こえんよ
何か盛大に勘違いしてない？ >>59
その当たり前の事がわからないのですが…
子クラスのクラス変数に親クラスのインスタンスを入れれないのはわかりますが、それに対してどうすれば良いのですかと質問しています。 いやいやゲームはメチャクチャOOPに向いてる。
ゲームエンジンがプロパティペインで物を制作管理していくのが中心になってるってことは
全体としてOOPと相性がいい。
そらそうよ、鋳型と各オブジェクト、その相互作用、隠蔽やインターフェース、
まさにオブジェクト指向言語の基礎サンプルやエクササイズが綺麗にヒットしやすいのがゲームよ。 >>62
エアプ乙
ゲームはオブジェクト同士の関連処理が一番多い
それを綺麗に書く処理はオブジェクト指向言語には無い
これを議論するといっつも言語機能に用意されてないもんだから色んなワンダーランドがご披露されるだけのクソ展開になる
いいか
そんなもんないんだ
お前がどう書くかなんて俺は興味ない
ただ言語の機能にない
それだけだ たんに解がひとつではないだけの話じゃね？
そんなの普通のGUIアプリ一つ取ってもそうじゃん 文面見ればオブジェクト指向を理解して言ってるのかどうかわかるやろ 議論スレに行った方が良いのか判らないけど、
俺も初心者なんだけどC#の機能を試したくってさ。
基本キャラからキャラ種類別にクラス継承させたりして楽しんでたよ。
でもゴリゴリにスペックを切り詰めるようなゲームだと、そんな余裕はないのかもな。 ゴリゴリにスペック使うような案件にC#使うとは思えないけど 日本産のスマホゲーと大陸産のスマホゲーぐらいの速度差は出るだろうな オブジェクト同士の関連処理を綺麗に書く機能、って具体的にどんな感じの物なのか興味はある。 ここ「初心者の質問スレ」で「初心者の雑談スレ」じゃないんだけどテンプレ読めないの？
マ板でやれ >>68
中華の大手どころってマルチプラットフォーム対応なソシャゲもUnityとか使わずにそもそも自前エンジンで開発してね？ >>69
まあ言語機能云々は意味不明に聞こえるねw
前も書いたけど、ゲームの場合Mediator的な装置を用意すべき場面でも
目に見えるオブジェクトに引きずられて変な設計してしまいがちだと
いう意味なら分からんでもない。
バブルボブル（おっさんにしか分からんかも）で泡の相互作用を
Bubbleクラスに無理に実装したらたぶんハマるよね。 linq便利だなーって使いまくってたけど
最近自分が手続き型の思考をしなくなってきたことが怖くなってきた
これプログラミング能力が低下するのでは.. >>75
でもLinqって古くから有る技術の延長にある気がする。
SelectしてWhereで選んでSortしてっていうのは、コマンドプロンプトでパイプリダイレクションとかいう手法に似てる。
ラムダ式とかは新しいのかな。数学の世界とかそういう所では古いのか。 やっててよかったラムダ式。
やらなきゃよかった苦悶式。 そうか、C#だとメソッドチェーンすらも一般的ではないのか…
いやそんな馬鹿な
Unity制御スクリプトとしての利用が多いから？
いいや雑談だし >>75
そりゃ脳みそは使わないと衰えるだろうね
最適化重視で副作用を容認したコードを書こうとすると詰まることが増えた気がする いきなりメソッドチェーンとか持ち出したのはLinqの話に絡めてか？
全然違うものだと思うが。 Linqのクエリ式自体はメソッドチェーンのシンタックスシュガーじゃん メソッドチェーンの元々の意味はvoidのメソッドをthisを返すようにして....
ってことだったんだと思うよ。
個人的にはこういう重箱の隅を突く話は好きじゃないけど >>73
純粋に、自分が知らない有用な書き方があるなら知りたいとは思うんだよな。
別スレの LINQ がらみの話題もやるかどうかは置いておいて勉強にはなったし。
もしくだんの人が出てきてくれて講釈してくれるなら専用のスレぐらいは立てる。 初歩的な事かもしれませんが教えて下さい。
以下のような独自クラス「Group」のリストがあります。
このリストをクラスのAgeListをキーにGroupByしたいのですが上手くグループ化できません。
どうすれば良いでしょうか。
public class Group{
/// グループID
public int Id {get; set;}
/// グループ名
public int GroupName {get; set;}
/// グループ所属の年齢一覧
public List<int> AgeList {get; set;}
public Member()
{
List = new List();
}
} >>85
どうすればいいじゃなくてどうしたいのかをお前が決めろ
平均年齢なのか最大年齢なのかそれともまた別の基準なのか
グループ化に使うキーが一意に定まらないならグループ化のしようがない そもそもの設計ヤバない？AgeはMemberに持つのでは？ デフォルトで使われる比較関数じゃ欲しい結果が得られないからGroupByに独自の比較関数を渡すか、Groupクラスに比較方法を定義しておくかのどちらか 新卒研修の課題とかだろうから設計にツッコミいれてもしょうがないような 初心者以前の話だよな
何がしたいか位は分かるように書けよと思う >>92
動かないあれを見て分かるか？
そもそも構造すら間違ってるやろ >>92
わかるんなら説明してくれよw
メンバーの年齢だけを保持してるグループってあまり見かけないし 俺はこういう場合、独自解釈して好きなように作る。
今回ならAgeListをソートしてカンマ区切りの文字列にして、をれをキーにする。
でGroupByだな。
過去この独自解釈が5割くらいそのまま仕様になってる >>93
>独自クラス「Group」のリスト
>このリストをクラスのAgeListをキーにGroupByしたい
List<Group> list = new List<Group>();
// なんか処理
list.Groupby(x => x.AgeList)
ってしたいって理解したんだけど違うんかな
宣言でそもそも間違ってるのは知らん Ruby なら、こういう感じ
members = [ {id: 1, age: 30}, {id: 2, age: 20}, {id: 3, age: 50} ]
p members.sort_by{ |member| member[ :age ] }
出力
[{:id=>2, :age=>20}, {:id=>1, :age=>30}, {:id=>3, :age=>50}] C++とJavaを業務でやっていてc#始めた初心者です。
Xamarin.Mac でmacOSのアプリを作りながら学んでるけど
恐ろしく情報が少ない…。Macでc#使う人って少ないんでしょうか？ そもそもXamarinで作る必要あるのかという感じがする
正直流行ってないからね
Java出来るならJavaでいいんじゃね？
もっと新しい技術ということならelectronをお勧めしておくわ
Windows限定アプリならVisualStudioでC#は楽でいいけどね >>104
人脈作りから始めよう。
objective cとcocoaの方が需要あるやろ >>105-107
回答ありがとうございます。
マジですか。。。C#以外をお勧めされて複雑ですが
その言語も調べておきます。
まだC#学習して1ヶ月程度ですが機能が盛り沢山で面白いので
Macでも普及して欲しいですね(´･ω･`) 機能は盛りだくさんでもPythonやJavaの方が人気なんだよね。
それぞれ良し悪しや向き不向きがあるだろうけど。 今、統計的な素養があってPytorch触れると
月単価150万からだもんなぁ。 >>108
どうしてもC#がいいなら採用出来るかどうかは別にしてもUnityという手はあるけどね >>110
TensorFlowでもええん？ダメなん？ >>113
MSが共通Wrapper作りましたってことでDLL importは必要なくなるし、アンマネージ
部分についてもお約束を守ればよくなるみたいだけど、サンプル見ると色々手続きが
面倒臭そうで使い勝手は良くなさそう void*とかobjectにするしかないだろうしアホみたいなオーバーロードの山になるだろうし
始まる前から破綻の予感しかしない
っていうか何で今更 そもそもガンガンWin32API使うなら素直にC/C++使うし、C#だとちょっとつまみ食いする程度にしか使わんから今のままでもいいや apiで使う構造体とかの面倒くささが無くなるならいいんじゃない？ OSのようなハードに近いレベルの言語となると、Rustが流行ってるのかな。
C#でそういうのも出来ると良いのにね。 >>113
https://dot-sharp.com/net-getdetailsof/
Shell32.dllを使うとき、com参照を追加するだけでC#のライブラリと同じ程度の手軽さで使えました
これが増えるってならいいんじゃないかな >>118
PyTorchはずっと不人気だったのに
今調べてみたら、ここ二年ぐらいでTensorFlowと拮抗してんな
ま、いいや、どっちか使えりゃ問題ないだろ C#をネイティブコンパイルできうようにすればいいだけだと思うが。
なぜ回り道をするのか >>123
無理せずPaddlePaddle使ってたんでえぇで
日本では需要ないけど >>125
PaddlePaddleはダメダメだな
日本だけじゃなくて、世界でもダメな奴 AI関連は、何を使えるかよりどこの博士号を持ってるかの方が重要なんだろ？ CNTKの求人って見ないな
ttps://www.bigdata-navi.com/ 以前画面解像度切り替えのツールを作った時にvanaraといwin32apiのラッパー使ったな
構造体も用意してあって簡単に使えた win32って一々ラッパー挟まずとも実はC#側で結構調節してくれるんだよな
GetProcAddressみたいなANSI版しかないような関数でもstringそのまま放り込んでもちゃんと機能してびっくりした a={1, 2, 3, 4}という配列が与えられて
更に10進数x=5が与えられた時、5を2進数にして101なので
(最下位ビットがa[0]になります)
配列の要素1と3の和を出力せよという課題が出ました
var r = 0;
for (int i = 0; i < a.Length; i++)
if ((x & i << 1) == 0)
r += a[i];
で求める答えが出そうだと思ったのですが
4ではなく3が出ます。どこが間違っているんでしょうか >>132
わざと間違えてない？w
static int GetBit(uint x, int position)
{
return (int)((x >> position) & 1);
} >>133
その書き方だと通るんですよね..
下のように解説してるサイトがあったのでそう書いてみたのですが
なんかおかしいんです
ビット bit に i 番目のフラグが立っているかどうか if (bit & (1<<i)) え。
>if ((x & i << 1) == 0)
>if (bit & (1<<i)) あ、やっと気づきました
bit操作理解せずに、コピペで済ませてた弊害が出ました
ありがとうございました >>134
それはたぶんC#ではなくてCのコード
「bit & (1<<i)」この式の型は何？
Cと違ってC#のifの()の中の式はboolでなければダメ
まあこれは初心者が知らずに混乱しても仕方ないかもしれない。
でも>>132のコードの何が間違ってるかは初心者でも自分で考えれば分かるでしょ。
とりあえず問題を小さい問題に分けて分割統治することから始めましょう。
>>133はそういう意味で書きました。 Typescriptじゃインターフェース名にＩ（アイ）をつけないのが推奨されてるけど、
C#もそうなったりするのかな。 破壊的変更を.NETユーザーが受け入れてくれるなら良いんじゃね C#でIが取れなかったのはCOMの影響があったからとかなんとか
今更C#の方針を変えることはないだろうね エディタで色分けしてくれればいclass, struct, interface, abstract プリフィクスのIは字面からインターフェイスだと分かるようにしたい、という強迫神経症的な動機というより、
単純に名前のバッティングを機械的に回避できる点が大きいんじゃないの？ どうせインターフェースにIを付けなくなっても、実装クラスのいい名前が思いつかずになんとかImplってサフィックスつけるんだろ？ Delphiだと、クラスにはTypeのT、パラメータにはFieldのFを付けるんだよね。
InterfaceのIはその名残なのかな、とか思ったんだよ。
そして、そういうのは無くしていく傾向なのかな、と。 >>144
付けないよ
そんなの付けるのJavaやってたやつくらいやろ 命名規則で一番上手くいってるのはC#と思う
インターフェースにプリフィックスIをつけるから命名で困った時にImplとかやらなくてすむし
プロパティ名は大文字で始めるから小文字で始めるローカル変数とぶつかりにくいし で、最近は名前がさらぶつかりにくくなるようにメンバ変数はm_を付けるスタイルに個人的に変更した >>147
こういう適当な名前を付けるやつがいることにピキってるっぽいね
適切な名前にすりゃブッキングしねえから名前付けをサボるなってことらしい なるほどなぁ
ちなみにIListはなんて名前にすればより適切だと思う？ おまえ馬鹿か
たいていぶつかるのはローカル変数や外部に公開しないクラス名だろ
JavaのImpl使うのだって、内部クラスや非公開や内部のエンジンクラスとか そんなのに適切な名前なんかブッキングできねぇよカス >>152
Microsoftの推奨する命名規則を参考にすれば良いんじゃない？
つまり、I付きPascal形式でスペル省略不可のフルネームで名詞を表せば良いのかな。
自由に付けても良いけど、.Net Frameworkと調子を合わせると違和感が無いと思う。 うちの会社、昔から変数名の1文字目にデータ型の略称（？）をつける文化みたいで、
intのListがiListだったり、longのListがlListだったり、ちょっと困惑した。 >>156
郷に入っては郷に従え！
君の使って良い変数はI150からI300までな！
そこはFortran出身者の支配する村であった MSの.NETプログラムにおける命名ガイドラインな
ttps://docs.microsoft.com/ja-jp/dotnet/standard/design-guidelines/naming-guidelines 皆さんコメント入れる？ 命名規約とか守ってたらコメント要らないような気がしてきた。 >>159
いわゆるドキュメンテーションコメント的なものは入れる。
あと、実例みたいなの。
//引数にXXとYYとZZを渡したら、戻り値はAAになる。 visualstudioだとクラスやメソッドの１行前に///入力で自動補完されるからそれは使ってるかな 日付、所属、名前、旧コードはコメントに残すのが常識でしょ バージョン管理ツール使ってるのに旧コード残すやつにはイラッとする！
特に不具合のコードをコメントアウトして残されてると、当てつけなのかと思ってしまう コメントって入れるものだったんだ。
書くものだと思ってた。 なぜこんなコード書いたんですか？と書いて旧コードを残すわけですね 168が仕様を理解せずおかしな実装を
したので辻褄合わせの辞書を実装しました by 167 >>159
コメントは基本的には必要悪なので必要がない限り書かないのが正しいけど、
少なくともパブリックメンバーについては単純に「必要」かもしれんね。
ないと書いた人の意図を変に誤解してないか不安になって
結局中のコードを覗きたくなるかもしれない。
そんなことしなくて済むためのカプセル化のはずなのに 1年後に自分の書いたコード読んで、何をやっているかちゃんと理解できるならば
書かなくてもよいんじゃないかなｗ >>171
何をやってるかなんてコード読めば解るんだから、
そんなことのためにコメントは不要
「なぜ」そんなメソッドが必要か、
「なぜ」そのデータ構造やアルゴリズムを選択したか
なんていう、コードから見えない情報を記すのがコメント MS含めアメリカ製の高品質なコードって「なぜ」のコメントが無茶苦茶充実してるよな
日本だとだいたい // 〇〇処理 みたいな無意味なコメントか、ほとんど無いかのどちらか
SaaSとか一般的にレベル高いと思われてるはずの現場では、だいたい後者のパターンでほぼコメントが無い
根本的に論理的な言語能力に差があるんだろうなと思わざるを得ないわ コードレビューでコメントを書けって指摘されるじゃんw コメントなんて要らないんだよ
コミットログを見ればいいんだから private なプロパティってフィールドにするべきですか？ >>172
言いたいことは分かるけど「何をやってるかなんてコード読めば解る」というのは
あくまで理想であって常にそうできるわけじゃない。
何をやっているか書いてくれた方がありがたい場合もあるよ。
>>176
そんなことをルールで強制する理由はないと思うよ。 >>177
何をやってるかがコメントとコードで乖離してる事があるのが問題
英語でthirteen daysって言ってるのに、
字幕には2ヶ月って書かれる戸田奈津子の翻訳みたいな事が起きうる >>178
逆に、コメントを書かせることでコメントを書きやすいコードになるという面はあると思うよ
クラスやメンバの責務が十分に明確ならコメントと実態の乖離なんてそう起きるものではない >>178
コメントはバグる可能性があるからコメント書くな、
なんて言ったらバグる可能性があるのはコードも同じなんだから
コードも書くなってことになっちゃうよw
「不必要なコメントは有害無益」は正しいけど、それは
必要なコメントを否定する根拠にはなりえない。 >>180
コメントがバグるって話じゃなく、
書いた人の「つもり」がコメントとして残るのが危うい
実行時にどう動くかを決めるのは、コメントではなくコードなのだから、
コメントを読んでコードを読んだつもりになれるのも危うい 入門書の多くがコメントの書き方を蔑ろにしてるのが元凶だと思うんだよね
ほぼ単なるメモ機能としての記載しかされてない 「コードを読めば何してるか分かる」のだから、メンテ忘れで誤ったコメントが残ったとしても問題ないとも言える。
・・・たまにブチ切れたくなることがあるけどな。 >>182
あれは解説を見ないとプログラムが理解できない人向けの本なんだからそれをコメントに書くのは当たり前じゃん >>184
> 「コードを読めば何してるか分かる」
ならコメントなんていらんだろw >>172
YOLOv5をC#に移植して内容を説明しては
くれまいか？
そんなに簡単な話なら誰も論文なんて読まないよ～ :-p ドキュメント代わりにしてるから入れる
///<summry>
の形式のやつ
doxygenで出力してモジュール設計書として納品して一丁上がり クラス図もシーケンス図もねぇのになにいってんだこのバカ >>186
だから要らないって話だろ
var hoge = items.First();
で最初の要素を取得するなんてコメントは要らん
記載するならwhy何故取得するのかだけ書けばいい
もし動作について記載したくなったなら、それはメソッド化するとかを検討した方がいい >>190
だからと言って
> メンテ忘れで誤ったコメントが残ったとしても問題ないとも言える。
ってアホだろ、って言う指摘なんだが…w それはアホだけどコメント入らないも的外れって指摘なんだが >>192
>>184の全文読んでから出直してこいよw 宗教が合わないと作成者本人が綺麗に作ったつもりでも読みにくくてしょうがないからブロック毎に動作の概要ぐらいはコメントで書いといて欲しいわ なんだよ、せっかく議論スレに移ったのについてきてねーじゃん
正直者が馬鹿を見る世界
もう移らん、絶対移らん（笑）
俺はコメント入れてほしい派
読めば判るっつってもさ、
コード書いてる本人ですら
何やってるか分かってない場合もあるからな（笑）
せめてコメントで
「ここではこんなことをしてる（つもり）」
って書いてくれら「全然そうなってないだろ！」と突っ込める xxxInternal
xxxPublic
xxxOverride パワーポイントやエクセル内の文字列を検索するクラスってありますか？
windowsの検索窓ではなく… >>197
Windows Searchを使えば検索窓と同等の機能がプログラムから使える >>198
素早い回答ありがとうございます！
そんなのあったのですね！検索力不足を痛感しました…
調べてみます。 議論スレに移れないってことは、
コメント付けたところで読めない無能だから無意味って証明になったな >>200
何度も言うけど、真の無能はそれが自分を棚上げした物言いである、
という簡単な事実に気づく程度のこともできないお方だよ。
これ割とマジで大丈夫かと思うわ ついでに、これも何度も言ってるが、そんなくだらない「交通整理」に誰も従わないのは
「交通整理」の欺瞞性とそれを主張している人間の卑しい動機に普通は気が付くから。 他人を見下し自分が主導権を握りたいという自分勝手な承認欲求が行動原理 >>202
暴れて飛行機から下ろされ
飲食店で入店拒否されて暴れて警察を呼ばれ
警察を殴った誰かはTwitterで同じこと言ってたなｗ >>193
その 184 だけど。w
「コードを読めば何してるか分かる」な人は、そもそもコメントがなくてもいいんだから、書かれていても無視すればいい。
コメントが欲しい人は、コメントの弊害(メンテ忘れとか)の現状を承知の上でそう言ってるんだから、そもそも問題ない。
つまり、コメントがいる／いらないの論争は無意味だからやめとけってことなんだよ。
その上で「コードを読めば何してるか分かる」ように丁寧な書き方を目指せば済むことじゃん。
まあ自分はブロックと言うか処理単位でのコメントは出来るだけ書くけど。 ・コメントがあるとノイズになり視認性が落ちる
・コメントには嘘が混ざっていたり情報が欠落していることがあるので常にコードとコメントの整合性を確認しながら読まなくてはならない
・コメントに嘘を混ぜたり情報を欠落させないために細心の注意を払わないとコードを更新できなくなる これは茶化しで書くけど。
コメントがなければストレスなく読める美しいコードなんて見たことないなあ。 >>206
> つまり、コメントがいる／いらないの論争は無意味だからやめとけってことなんだよ。
誰もそんな論争してませんよ…
もしかして>>186をコメント不要という主張だと思ったのか？w そーなのか。
じゃあバカな私に分かるようにおまえ様の主張をきちんと述べてみてくれ。 >>211
>> メンテ忘れで誤ったコメントが残ったとしても問題ないとも言える。
> ってアホだろ、って言う指摘なんだが…w 改修履歴をコメントで残すとかいうのさえなけりゃ
他のコメントはコード読むのに邪魔になりはしない >>216
あれなぜコメントの機能を持たせないのか不思議だわ
{
"$comment": "コメント"
}
みたいな形でコメント書くという方法もあるみたいだけど気持ち悪いし 最初に作った人が「コレはデータだからコメント不要」って取り付く島もないんだとか
VsCodeの設定ファイルみたく独自で拡張してjsonもどきになっているよな jsonなんて人間の読めるもんじゃないと思う
ダブルコーテーションが目にキツイ >>218
JSON自体は仕様がもう確定してるから。
jsoncとかJSON5とかRelaxed JSONとか拡張した別仕様ならある。 json便利だけど、protobufを使うようになってから使用頻度減ったなー １つの一連の処理で一度に10回以上は失敗する可能性があるんだけど
例外って複数ストックできる？ できるよ
ValidationでエラーためてIsValidで確認するのと同じ try{
...
}catch(Exception ex){
exceptions.Add(ex);
}finally{
continue;
}
こんな糞コード見たことないけどな。 デーモンコアと
マイナスドライバーを設定
try{
while(米が勝つまで回す){
①測る
②マイナスドライバーを動かす
}
}
finally
{
③デーモンコアを離す
④if(青い光りが見えた){
⑤みんなを退避
⑥逃げる
⑦救急車を呼ぶ
⑧遺書を書く
}
}
大体こんな処理なんだけど
③～⑧は途中で例外起きても
最後までやってほしいらしい
っていう一連の処理なんだ
どのエラーや例外も全部保存したい
>>224
なんかサンプルないですかね？ 溜めておいた例外を最後にAggregateExceptionのInnnerExceptionsにセットして投げれば >>227
なんかそういう処理の書き方の流れが知りたい感じです NlogつかってファイルかDBに残すのが現実的じゃね？
https://nlog-project.org/
こんなやつ >>223
失敗してても処理が継続される時点でそれを例外を呼ぶべきか、そもそも疑問に感じるね。 class DaemonSequenceException:Exception
{
public Exception FooResult { get; set; }
public Exception BarResult { get; set; }
....
}
とかみたいに他の部分の成否と無関係に実行できる各部分に名前をつけて、
その部分の例外をプロパティーで持つとかするのかね知らんけど DirectoryInfo.GetDirectories は例外を送出するけど処理は継続する まあ、結論としては
c#的にはこういう複数の処理が失敗するまたは終了処理も失敗するケースは言語的には完全に想定外ってことですかね >>234
そもそも一体何をしたいのかさっぱりわからん
記録したいだけなのか失敗毎になにか処理したいのか >>235
1メソッドでたくさん失敗するんです
でも例外って1つしか返せないじゃないですか？ >>234
地道に処理毎にtry{}catch(){}で囲めばいいだけ
言語のせいにするのはお門違い >>237
そもそも例外で返すのが間違いということでしょうか？ >>238
<1>
var exceptions = new List<Exception>();
<2> (処理の数だけ作る)
try
{
処理
}
catch( Exception e )
{
exceptions.Add( e );
}
<3>
throw new AggregateException( exceptions ); >>239
ありがとうございます
それって受け側ってどう書くんでしょうか？ >>240
受け側って何を指すのかわからないけどエラーをcatchしておいて投げなおしているだけじゃね
>>230の考え方でエラー起こるたびに「～の処理中に～のエラーが起きました」って全部記録する形から作っていけば？
エラー発生しても続行させる処理の方が大変になると思うしとりあえず一通り作ってみた方がいい >>241
普通に
try
{
}
catch(exception ex)
{
}
でaggregateexceptionってキャッチできますか？ たぶん欲しいのはエラーのログなんだろうね。
あるいはPOSTでやるようなチェックリスト？
例外オブジェクトをエラーを表す目的で使ってもいいとは思うけど、
何がしたいのか目的をはっきりさせずに「例外をストックできるか？」とか質問するから
みんな混乱する。 なぜかこういう人は何をしたいのか書かないんだよな…
まあもういいや、相手もしてもしょうがなさそうだし >>243
それで出来るけど、catch( AggregateException ex )で受けた方が
AggregateException.InnerExceptionsを参照しやすくていいんじゃない >>247
ありがとうございます
受け側はなんの例外がくるかしらないんですよ多分 例外を見ればどの処理で発生した例外なのか確実に分かる場合はいいけど
そうじゃないならList<Exception>だとたぶん困るよね >>250
どこで発生した例外かを知りたいなら例外にその情報を入れとけば良いだけだろ >>251
>>239の例ではそれをやってないから困るんじゃねって話なんだけどさ >>252
ExceptionでもSourceに入れるとかMessageの一部に入れるとかやりようはいくらでもあるだろ エスパー回答すると、Disposeをしっかり作ってusingを使え、が顧客が本当に欲しかったもの C#の話と関係無いかもしれませんが、パッケージの開発環境って今の時代何がありますか？
完全にオフラインで使える開発環境とかって無いんでしょうか？コマンドプロンプトしか無いんでしょうか？ 落ち着け(´･ω･`)
パッケージ、開発環境、コマンドプロンプト
全然話が繋がっていない なんとなくエスパーすると、開発ソフトをインストールさえすれば、その後はネット非接続で何でも開発出来る環境が理想ってこと？
なら、たぶん無い。
.net sdk使って、標準ライブラリだけ使うなら出来るんかな？
結局必要なライブラリやらランタイムをDLするか、他のPCでDLして開発PCに入れる事になりそうだけど。 >>258
待て待て、標準ライブラリだけでもオフラインで開発できるなら、回答しては「Ｙｅｓ」じゃないか？
特に、その「他のPCでDLして開発PCに入れる事になりそうだけど」が出来るんだしさ
>>255
目的を話せ
俺のエスパー能力をフル発揮すると、
セキュリティ上、スタンドアローンで動かさんといかんPCがあって、そこで開発したいだよな？ >>258
ありがとうございます！！！
環境を自分で作る以外ないんですかね。無謀すぎますね。
コンパイラ作るわけじゃないですからね統合環境は。
>>259
そうそう単にセキュリティの心配です。
オフラインだと全く外部に漏れる心配ないわけじゃないですか。
めちゃくちゃ安心するじゃないですか。
何でインターネットに繋いでないとプログラミング環境が整わないような
状況なんでしょうか？どう考えたってオフラインのほうがよくないですか？ そういうセキュリティの気にし方をするのであれば、普段使いのPCとは別に
個人情報を一切入れないPCを１台用意して開発勉強専用にするのが一番安心できると思うよ
外に漏れて困るようなレベルのコードを書くならダメだけどさ
というかMicrosoftDocsやGitHubやStackOverflow/Qiitaとか一切閲覧できない環境で
NuGetやNPMに登録されてる出来合いのライブラリもまったく利用しない縛りを入れて
自分の能力だけで1から100までコードを書けるなんてすごいなあ
俺にはそんな縛りプレイしてたらとてもじゃないけど開発にならないや インターネットにつながっていないが故に管理がおろそかになってパッチ適用がされない弊害の方がやっかい
日立のランサムウェアなんかはまさにそれ 構造体(値型)を関数の参照渡し以外で、参照する方法ってありますでしょうか？
配列の構造体にアクセスするコードを書いているのですが、
逐一配列の添字計算が入るのも嫌なので避けたいと思っています。
添字の数は関数の中では変わりません。
今は関数の参照渡しで使っていますが、他に方法は無いのかなと思いまして。 >>264
策士策に溺れてはいけない
愚直に一時変数を使いましょう >>265
ref ってローカル変数に使えるんですね！
前に軽く試した時には右辺値にしかrefを記載してなかったので、
左辺の定義にもrefを記載すれば行けました。
有難うございました！ オフライン環境での開発だけど、
VS Community2019のオフラインインストーラをダウンロードして
オフライン環境に持ち込んで使ってる
c#でフォームのデスクトップアプリしか作らんので特に困ってない >>270
バグや脆弱性対応は？VS2019って頻繁に更新されてるけど >>273
offlineインストーラーも知らないのは開発者としてどうかと思う getsetプロパティをFuncで呼び出せるようにしたいのですが可能でしょうか？
メソッドで括って呼び出せば良いのだろうけど直接Funcに入れる方法があるならそうしたいです よく分からん
Func<string> func = () => person.Name;
を
Func<string> func = person.Name;
みたいに書きたいってことか？ 無理だけど
func = person.Name.Surname;
のときperson.Nameがいつ解決されるのか判断つかないし >>276
返信ありがとうございます
イメージとしては複数のクラスで
public bool hoge {set => test = value; }
が複数あって
List<Func<bool, bool>> func;
に追加していってキャンセルとか何らかの処理後に一括して戻したい、と言うような処理です
やはりプロパティってメソッドみたくできないFuncに入れる事ができないんでしょうか
他の方法ですっきりする方法はないですかね？ やりたいことがさっぱりわからんな
ダイアログのキャンセル押したら画面ごと破棄でいいじゃん >>277
List<Action<bool>> list;
list.Add(b => hoge = b);
こういうこと？ まあ気持ちはわかる
(Webでなく)GUIアプリで独学した初心者って、エンティティオブジェクトをアプリ全体で生存させるような設計をしちゃうんだよな
オブジェクト指向を普通に解釈すりゃそれが自然なんだけど、実際そういう設計はしないんだよ
ドメインモデルだろうとトランザクションスクリプトだろうと、エンティティはトランザクション毎に作る >>274
知らないって決めつけてるのはどうかと思う
単にどうしてるのか聞いているだけ >>278破棄と生成できれば良いのですがちょっと難しい。ユーザーコントロールでバインドしていて各コントロールは値を参照しあってます
今回は画面が切り替わったときに表示非表示を変える戻す、なので直接は関係ないのですが影響度を減らしたい
>>279
>>276見直してプロパティを直接でなくてもラムダ式でいけそうなことに気付き>>279さんの形を思い浮かびました、今出掛けてるので確認は後ですが多分解決できそうです
皆様ありがとうございます
解決しなければまた聞くかもです
ありがとうございます これあれじゃね？
開始日と終了日に期間制限があると値が設定できないやつ（笑） 何がしたいのかよく分からないね。
キャンセル要求が発生したら初期状態に戻したいなら
素直に初期状態をまるごとキャッシュしておく方が分かりやすいんじゃないかと思うけど
もっと素直なのはそもそもApplyするまでUIの値をモデルに反映しないことだよね。
まあたぶん要件を説明しきれてないんだろうけど >>282
元に戻す処理を管理したほうがいいケースなのか
元の状態を管理したほうがいいケースなのかを考えたほうがいいよ まあ、設定画面がモードレスでリアルタイムで値を変えたいときもあるかもしれんが
それやると
地獄の一丁目にご招待って感じ（笑） >>288
更にundo/redoの機能を付けてくれまいか？
で更なる深淵へw >>290
影響する値でエラーが出てもそれとは関係ない表示はできる限り続けて欲しい（プレビューが見えないから）
エラーが出てるときは値の変更で表示は変わっても最後の反映はできないようにしてほしい
でも値を変更してる最中のundo,redoは効くようにして欲しい
って割とありがち要求だよね
モードレスやった時点で地獄を覚悟しろって感じ >>283
めんどくさいのに本当にしてるのか気になったから聞いたんだけど何かおかしい？ うちにも本当にしてる端末はあるぞ。
むしろ自動で上げたくないしな。
既知の問題でワークアラウンドがあるならそれで良いというケースもあるし。
リリースノートめちゃくちゃ読む。 >>293
ネットに繋げないならそうするしかないし言うほど面倒でもないだろ
そもそもネットに繋いでる場合でもアップデートがある度に適用なんてしないよ
>>294が書いてるように修正内容見て影響ないとかワークアラウンドがあるなら適用しない オフラインがめんどうとか何言ってんの？開発する時にはセキュリティ上当然やろ
オンラインとか最近の開発ではありえない 今のVSって最新メジャーバージョンは完全に人柱向けだからなあ
アップデートをすぐに入れられないような環境だと詰む可能性があるからむしろリスクが大きい
最新版を追えない環境なら2017使ったほうがいいよ >>298
中身読めよ
2017の方は脆弱性修正と軽微なバグ修正しかやってない C#を勉強中です
Delegateの機能はわかったのですが、これはどのような状況で使うのか思いつきません
こう使うと便利だという例を教えてください delegateの機能が解説されていた箇所に書いてなかったの？書いてあったけどそれを理解できないってこと？ >>301
そのわかったというDelegateの機能を説明してみてもらってもいい？ >>301
真面目な話、無理に今理解しようとしなくていいと思うよ。
コード書き出ぜば自然に分かる。
後回しにして先に進んだ方が吉。 >>303
機能の解説だけでどのようなときに使うかは書いてなかったです
Delegate型の説明と作り方の後に例としてConsole.WriteLineでHelloと表示するメソッドを
新たに作ったDelegate型のaという変数に突っ込んでa()を実行して
ほら表示できたでしょという感じだったのだけれど
だからどうしたとしか思わなかったです 自分も変数のシャドーイングとか何が便利なのかわからないです
脳みそのメモリ圧迫されるのでは >>308
これがdelegateだとしたら意識しないで使ってました
まさかこれが.. デリゲートは自分で使うもんじゃないと思ってた。
Buttonをクリックしたら、このメソッド実行してねってのを、IDEが作ってくれる奴だから。
だから、「こんなときどうしよう」って悩んだときに、
そうだ！デレゲートってのがあるんだよ！っていう、よっぽどの場合に、入門書を読めば良いと思う。
初めてのC#みたいな本がお薦めなんだけどね。 >>306
試しにhello2 からhello100まで突っ込んでみよう まあこういうものが腹に落ちるようになるのが楽しいとこでもある 例えば、Ruby では、Forwardable でインスタンス変数に委譲できる
自分で配列クラスから、Stack を作って、その内のpush, pop だけを使いたい場合、
もし配列を継承・is-a すると、余計なメソッドまで継承してしまうので、それらを使いたくない。
そういう場合に、委譲・has-a で、インスタンス変数に委譲して、使うメソッドも限定できる
Go, Elixir も継承がない、委譲だけ。
継承は大掛かり。
使わないメソッドを呼ばれてしまう可能性があるから
また、誰でも使うような、String クラスなどを継承して、メソッドを追加されるのも嫌。
そういう継承は想定外だから
素人は、よくそういう事をする。
継承用のクラスじゃないのに継承したりする
require 'forwardable'
class Stack
extend Forwardable
def initialize( ) @ary = [ ] end
def_delegators( :@ary, :push, :pop )
end
stack = Stack.new
stack.push 1
stack.push 2
stack.pop
p stack #=> #<Stack: @ary=[1]> >>307
shadowing とは、内外の変数は、別々の扱いで、
内側のスコープに入ると、内側が優先されて、
外側の同じ変数名が隠されること。
その際、外側の変数には影響を与えない。
Ruby では、外側のa は10で、内側のブロックスコープでは、
同名の変数aを使っても、外側の変数には影響を与えない。
ブロックスコープを抜けると、aは10のまま
a = 10
ary = [ 1, 2 ]
ary.each do |a|
puts "ブロック内: #{ a }"
end
p a
出力
ブロック内: 1
ブロック内: 2
10 なにかのネタというかエンジニアジョークなのかな？ わからないや
シャドーイングがどんな機能なのかは単純だからわかってるつもりだけど、一見同じ変数名を扱えることで何が嬉しいの？って話です
コード読んでて混乱しそうなので無い方が綺麗だと思うのだが、自分の脳みそが貧弱なだけかな？ c から来た人なんだけど、デリゲートって関数ポインターの認識 >>322
それがリストになっているので
複数の呼び出しを一気に行える。
という感じ >>321
嬉しいでしょ。
まあぶっちゃけフィールドをローカル変数で隠蔽することはあまりないと思うけどね。
>>322
Cより機械語レベルで考えた方が分かりやすいね。
要はcall命令のオペランドだよね
厳密にはthisポインタの情報を含むから違うんだろうけど概念的には 初歩的な質問ですいません
オブジェクト初期化子とコンストラクタは何が違うんでしょうか？
やってることは同じのように感じるのですが… >>324
デリケートって追加や削除されるたびに全リストコピーしてるんだっけ？
ぶっちゃけ効率考えたらデリケートよりインターフェースをリストで持たせた方が効率はいいよね >>327
初期化子は参照側が任意に行う。代入しか出来ない。
コンストラクタはオブジェクト側が初期化のルールを決めて、ロジックが書ける。
ってことじゃないのかな。 >>327
コンストラクタにはそのオブェクトを生成するために必要なものを渡してる
初期化子は特に生成には関係ないない項目にも初期値を設定してるイメージ
使う側はあまり気にしなくていいけど用意する側は意識しといた方がいいよ >>327
初期化子はフィールド単体に対しての初期化で、コンストラクタはクラス全体に対しての初期化って考えたらイメージしやすいかも
まあ、初期化子を指定しない場合でも、def aultで初期化されるんだけどね >>327
そもそも問題設定が間違っていると思うよ。
正しい問題設定は「オブジェクト初期化子って何？」
オブジェクト初期化子とは、コンストラクタ呼び出しと、複数の任意のプロパティーやフィールドへの
値の設定をインラインで書けるようにした糖衣構文。 >>326
実を言うとnull safetyのせいで隠蔽したくなるんだな
もちろん、別の名前つければいいけど C#に限らずnull safetyの言語で、特にビューモデルのクラスでnullableなフィールドを宣言する機会が多いいんだが、
フィールドはメソッド内でnullチェックしても非nullableに昇格しない(kotlinでいうスマートキャストが効かない)
から、
if (field == null)
throw new IllegalState
var field = field!; // わざわざnon nullableなローカル変数に代入で、ローカル変数に適当な名前が思い付かないのでフィールド名と同じ名前で隠蔽 メソッド内で1,2回とか参照しないのであればわざわざnon nullableなローカル変数に代入しないが
特にkotlinとかスコープ演算子とかもあるがkotlinは｢!!｣と二重だからこれがいっぱい現れるとソースが見苦しい... >>333
違うだろ。C#ならフィールドとプロパティをきちんと区別しないといかん。 x = a ?? b; ←null合体演算子
x.?method() ←これなんて言うんだっけ？ ピリオドとクエスチョンの位置逆だけどnull条件演算子 linuxとwindowsで動くguiソフト作りたいんですが、共通の開発環境と言語ってあるでしょうか？
openglを扱ってみたいのですが、c++とqtが多いんでしょうか？
c++を扱うと思うので、erectronやwxpythonなどは除外されるんでしょうかね。 >>341
C++の話をするのに何故C#のスレに来たの？ >>339
逆にnullだったらそのままにしたいってことが多いんだけどそういう演算子ないよね
int? x = null;
int? 2x = (x == null ) ? null : (2 * x);
みたいな opengl関係無いアプリも作りたいので(´・ω・`)
ｃ＃は恐らくlinuxでは動かないものですよね >>343
nullだったらメソッドやプロパティにアクセスせずnullを返すのがnull条件演算子(?.)
そのint?のケースは単に`2 * x`でnullが返されるようになってる >>344
Unityならwindowsでもlinuxでも動くはず .NET MAUIがそういうの目指してるんだろうけれど… >>347
unityをguiアプリ開発に使いませんよね 普通 >>345
条件演算子を使えないパターンの例をあげたつもりだったんだけどそういう動作すんのか
x.method()に対応するならmethod(x);にも対応してくれてもいいのにって思った >>350
monoやxamarinはc#ですよね。
c#製アプリはlinuxで動かないと効かされていましたが。
あと、openglなので、c++ではないですか？ まあC#スレでC++連呼してるのは釣りか底抜けのバカのどちらかだからいずれにせよスルーが基本かと c#でPCがアイドル状態か否か判定したくて
マウスの動きが一定時間なしで判定するのは出来たんだけど
マウスを動かさずブラウザで動画再生しているときにもアイドル状態ではない判定にしたいんだけど
どうすれば判定取れるでしょうか 特定のキー押下でアイドル判定されない状態を追加して置いた方が今後楽じゃないかな？ メディアプレイヤーの類で動画再生は構わないの？
ブラウザのバックグランドタブで再生中の場合は？
一応各プロセス各スレッドがSetExecutionStateした結果のステートはこんな感じで取れるらしい
https://stackoverflow.com/questions/10970625/how-windows-decides-to-show-the-screensave SetThreadExecutionStateだった その他の案
スクリーンセーバーのプロセスをトリガに利用にする
例えば「ブランク」のスクリーンセーバーが起動してたら、
「scrnsave.scr」がプロセス一覧から取得できる(はず)
つまり*.scrが動いてたら確実にアイドル状態と判断できる
この方法はスクリーンセーバーを無効にしてたら意味ないけど、それはレジストリから判断できるはず
問題はアイドル+スクリーンセーバーの起動時間まで待つ必要がある事 タスクスケジューラでアイドル状態を条件にプログラムを起動できる
コードから直接利用する方法があるかどうかは知らない >>359
率直に言って無理がある気が。
結局システムで正式に定義されたステートじゃないと
今たまたま何か方法を見つけ出してもいつまでそれが使えるか
わかんないよね。
スリープを抑止するプログラムが起動しているかどうかで
判定できないかとも思ったけど、ブラウザの動画再生は
たぶんスリープ抑止しないよね知らんけど SetThreadExecutionStateを試してみます
>>360
同じような機能入れてたけど設定し忘れ&解除し忘れで意味なかったです >>361 でよさそう(未確認)
>>368 GetLastInputInfo は数ヶ月前10で試したけどうまくいかなかった .NETで文字列の見た目の幅を求めるライブラリってある？
等幅フォント前提で半角英数なら1文字分、全角漢字なら2文字分、、、といったように計算したい >>370
シフトJISでエンコードした時のバイト数を数えればいいと思うけど
今時そんなの何に使うの？ >>371
ありがとう
でもできればプラットフォーム依存しないほうがいい
>>372
Markdownのテーブルをフォーマットしたり色々です 絵文字やサロゲートペアも考え出すとめちゃめちゃめんどくさいよね >>370
雑にやるなら、StringInfo.ParseCombiningCharacters2倍して、半角文字の文字数引いたら良いんじゃないの？
アクセント付き文字も半角文字に入れればそれなりに並ぶんでは？
タイ語とかアラビア語まで考える？ MeasureStringの数字を見ながら、頭がウニになったGDI+の思い出
勝手に文字の大きさ計算してくれるwpfの有り難さよ >>375
情報ども
とりあえず日本語対応できればいいかなと
>>377
あざす
これたぶん正解っぽいすね Markdownのテーブルっていうのが何かよく分からないけど、
細かいこと言えば等幅フォントであってもどの文字がどの幅で
描画されるかはフォントに依存するはずだと思うので、（一般的に半角の文字だと
されているものが半分の幅で描画される保証なんて実はないんじゃないか？）
グラフィック関係なら>>371みたいに実測するのが一番確実だよね 同じ文字で同じ等幅フォントで表示しても、アプリによって全角/半角相違することもあるよ
MS製品間でもVisualStudio/Officeで幅が一致しなくて以前困った記憶がある httpclientでpostした時にレスポンスヘッダーのlocationが取れないんだけど取る方法なかんかな HttpClientをnewするときに渡すHttpClientHandler(.NET Core/5ならSocketsHttpHandler)の
AllowAutoRedirectをfalseにすればいけるような パネルに貼り付けているlabelの数を数えることってできませんか？
テキストファイルの1行目ならlabel1へ表示するってな感じにしたいのですが、
行数が少なければ↓でいいんですが、
label1.Text = File.ReadLines(FileName).Skip(0).Take(1).First();
数が多くなるとコードが長くなって修正等に時間がかかると思うんですよ。
そこでラベルの数が数えられるなら繰り返し文を使えばコードがスッキリするんじゃないかと思ったんです。
良い案のある方いらっしゃいましたらレスをお願いします。 >>384
var count = this.panel1.Controls.Cast<Control>().Count( x => x is Label ); >>386
Controlにキャストする必要あるのか
つかOfTypeで良いんじゃねえのか
ちなみにControlsの列挙順って一定なのか？ >>387
思わずCastで書いちゃったけど、OfTypeの方がいいね >>387
designerの登録順に依存するけどイジるたびに変更を確認するの馬鹿馬鹿しいから
自分はコントロール名やタブ順で並び替えてる >>390
(デザイナーでの)登録順ってのは「保障」されているのか？って話なんだが
ディクショナリとか一見登録順に見えても、それは条件が良いだけか実装依存な場合がほとんどだぞ
まあデザイナの定義もVSでいじるとどう変わるかわからんけどな >>391
自分で調べもせずに何でそんなに偉そうなんだw
Control.ControlCollectionはIListインターフェースを実装してるとDocsに書いてある >>388
いやCastの方がいいよ
失敗しない確信を持ってるんだから >>384
なんかやりたいことと質問の内容が噛み合ってないような気がw
n番目のLabelにn行目の内容を表示したいんだったら
欲しいのはLabesの数じゃなくてIEnumerable<Label>とかじゃないの？
っていうかそういう目的ならLabelじゃなくてListViewとか使った方がいいんじゃないの？w 皆様回答ありがとうございます。
Controlsプロパティに関しましては↓に
https://www.atmarkit.co.jp/fdotnet/dotnettips/224controls/controls.html
＞PanelコントロールやGroupBoxコントロールなどを利用している場合には、フォームのControlsプロパティからすべてのコントロールにアクセスできるわけではない。
と書いていたのでスルーしていました。
>>394
まだ入門書を終わったばっかりでなにが正しいのかわかｒない状態なので、変な感じなってるっぽいです。
ご指摘ありがとうございます。
とりあえずやりたいことはできたので、皆様本当にありがとうございました。 >>396
一応釘を刺しておくけど、コントロール名を変えるだけで動かなくなるような実装にならないよう気をつけてね >>397
横からすみません。
そういう事態を避けるにはどういう実装にすればいいでしょうか。 >>399
現在、ToolStripのクリックされたボタンをNameで判別してます。
if(e.ClickedItem.Name == "") { }
この場合、Name以外のプロパティを使うようにするだけでいいでしょうか。 >>400
Nameじゃなきゃいいわけじゃないよ
じゃあTextで″削除″だった時にって分岐をすると、後にダイアログを出すから″削除...″に修正しなきゃってなって動かなくなる
派生してカスタムコントロールを作るとかTagを利用するとかが一般的かな >>400
どのプロパティーを使おうが、そのコードを書いた時と違う値が設定されてしまったら
識別子として使えないのは同じじゃないの？w
素直に「クリックされたのは○○か？」を検査するコードを書けばいい。
if (e.ClickedItem == hogeButton) { ... }
そもそもボタン自身のイベントを使えば何がクリックされたか識別するコードを書く必要がない ありがとうございます。
>>402
以前、その方式でやっていたのですが、理由あってToolStripと、そのコンテナになるFormを別にした結果、以下のコードになってしまいました。
結果、FormからMenuItemを直接参照出来なくなりました。
https://ideone.com/dlhYMG
対策的に、別途、MenuItemの一覧のenumと、クリックされたItemを伝播するイベントを作りました。
https://ideone.com/da5kPY
ただし、この場合はMenuItemを追加する時に、enumに要素を追加する必要がありますが、
enumは定数なので、アプリ使用中にItem追加した際、enumにそのボタンを登録出来ないのです。
それで結局Nameを参照するようになりました・・・ >>403
メンバー(fileMenuItem)のアクセスレベルを非privateにして晒すのが嫌なら
素直にイベントを作っちゃうのがいいんじゃないの？
public class MyToolStrip : ToolStrip
{
private ToolStripMenuItem fileMenuItem = new ToolStripMenuItem();
public event EventHandler FileMenuItemClick
{
add
{
fileMenuItem.Click += value;
}
remove
{
fileMenuItem.Click -= value;
}
}
} >>404
それで行きます！ありがとうございます！ 動的にオブジェクト追加してるならそのオブジェクトの参照は持ってるはずだから
Nameプロパティとか見る必要ないはずだが 言語の機能でインスタンスを特定しようとするのはギルティ
だいたい作っていくと痛い目にあう >>405
本来はToolStrip自身じゃなくて、ToolStripやMenuStripを持った
Formを継承した方がいいような気もするけどね。
まあそれじゃ満たせない要件なのかもしれないけど。
でもToolStripやMenuStripってFormの継承と相性悪いんだよな確か。
修正されずに放置されてるバグがてんこ盛りだった気がする >>397-408
入門書がNameプロパティでの判別をしていたので、当たり前のようにやっていましたが、
あまりよくないやり方なんですね。
ありがとうございます。勉強になりました。 >>409
よくないかどうかは状況次第だと思う。
自分や他人がコントロールのNameを変更した時に、判定する側もきちんと変更すれば問題ないはず。
そもそも変更しないなら問題になることもないし。 >>410
「〇〇を変更した時には××も変更すべし」みたいな自明じゃないルールが存在すると、
そのルールをコードを保守する人が忘れているか知らない場合には
正常に動作しなくなるリスクが発生していることになる。
プログラミングの目的は要件を満たすことなので、他に手段がなければ
あえてそういうリスクのある方法を採用することはあってもいいけど、
今の話は明らかにそうじゃない Windows,LInux,Macで動作するものを作る場合は.Net coreとmonoどっちがおすすめですか？ 今からなら.NET 5 (.NET Coreの後継)
今年中には更に後継の.NET 6が登場予定
.NET Coreは既に終了済、monoはモバイル向け(.NET 6に統合される予定) .NET Core 3.1の次バージョンを.NET 5とリネームしただけだから.NET Coreが終わったわけじゃない インターフェースや抽象クラスのメリットとは？
つまりvirtualで処理をかかない純粋仮想関数を作る意味はあるのかということです。
そもそもvirtual指定するのであればデフォルト処理というものを書いておけば必要に応じてオーバーライドすればよいと思うのですが。 >>418
>インターフェイス
多重継承
>抽象クラス
デフォルト処理が決まらないメソッドを継承先でオーバーライドで強要する ちゃんとifやcase文で書いた方が実は後で楽だけどね
使うかどうかはかっちょええかどうかである場合が多い 将来的にスパゲティ化することを防ぐために多少手間でもインタフェースや抽象クラスを使って制約を設けるもんじゃないの？ そういうのは大抵、いざ要件が増えたときには、今の引数だけでは〇〇の情報が足りないとか、拡張を想定していなかった部分を拡張しなければならなくなったとかで破綻するんだよ
要件にないなら後で実際に拡張が必要になってからリファクタリングした方がよい 俺は>>422派だな。
要件が増えたときにパラメータが増えたとしても、ファクトリーに渡す拡張用の値増やすだけで元の処理に手を入れなくていいから もしかして抽象クラスとインターフェースって使う必要ない？
メリットはスパゲティコードにしない制約を追加するだけで有れば設計ミスの方じゃないか？ >>425
まあでも知ってると他の誰かが使ったときに欠点がわかるよ
下地がそうやってできてるのにそれに逆らって作ってもしゃーないし
合わせるのは大事
ただメリットはよくわからん
List<object>やobject型の悪用とあんま変わらん気がする
落ちてもどこで落ちたかわからんのもいっしょ interfaceはこのクラスにはこのメソッドがありますよと言う事を約束するだけで
実装が共通化しようもないようなものに使うものだし
（例としてforeachで回せるようにする為のIEnumerable）
抽象クラスは良くある例はFruitクラスの子クラスがAppleやら関連性のあるものに対して使うものだろうし
そもそも用途が違うような >>425
アーキテクチャ綺麗だとあんまし使わないね
依存関係グチャグチャのスパゲティになってるとインターフェースで切ってDIしないとキツイ
けどそれは最初から設計ミスなんだよ クラスを他の人に使わせてまうとあとで変えれなくなってのっぴきならなくなることがあるからやがな。
interfaceにしておくことでサイズゼロにしておくことが出来る。
相手が不特定多数だと「変更したから変えてくれ」とはいえないわけですわ。 多態性を利用するために必須なんだから使わなきゃ不便じゃない？
純粋に楽になるついでに、構造に制約を設けて将来的に品質維持する保険にもなるっていう複数のメリットあるので、使わない理由が無いというか
一回つくって終わりの書き捨てならいらないけど
426の後半２行は意味がよくわからない >>432
多様性を使う為に必須というのは初耳だった
別に普通のクラスでも継承してインスタンス化すれば多様性は使えると思ってたんだけど
同じ親クラスやvarの配列にしてfor回したり
そこでインターフェースや抽象クラスにしてしまうよりかは
少なくとも何も処理しないダミー関数でも書いて仮想メソッドで実装しておいた方が良いとおもてる >>431
いやいやinterfaceから触るでしょうよｗ ちゃんとcase文書いた方がいくつ分岐してるかわかっていいじゃん
これをメリットと思えないのってなんでなの？
ソース読むときいくつに処理が別れてるか知らずに済むことって皆無だと思うけど >>436
いくつに分岐しているかを気にしなくてすむのがinterfaceによる抽象化のメリットの1つだろうに >>431
interfaceって実装しなくてもいいの？
詐欺にならない？ OOPの歴史も30年以上あるのでさすがに本質的に不要なものが
淘汰されずに生き残っているってことはないよ。
インターフェイス不要論とか抽象クラス不要論とか
staticおじさん級に幼稚で非生産的な書生論w
もっとマシなことに時間使った方がいいよ >>440
実装しなくても良いのではなく、interfaceそのものには実装は書けない。必要なメソッドを定義するだけ
良くある例としてIDisposableがあるけど
using(var obj = new TestClass()) {
}
みたいな使い方したければ上記のTestClassにDispose()メソッドを用意してねって事で
class TestClass : IDisposable
{
public void Dispose() {何らかの終了処理}
}
みたいに実装を用意しないとそもそもエラーになる >>434
普通の継承でも使えたね。すまん
具象クラス継承の適切なケースがわからんので考えなくなって、出来るって事も忘れてた >>440
単一継承しか許されないクラスと違い多重継承が許されるインタフェースでは、実体を実装するとC++同様に基底メンバの衝突の問題が発生する
この問題を回避するために実装を派生先に委ねてしまうことにしてインタフェース内では実装は禁止されている 教えて下さい。VBから書き換えて勉強してます。
フォーム1と2があり、それぞれTextBoxが無数にあります。フォーム1→2まで入力をして最後入力した情報を保存したいのですが、どういった形式、方法で保存するのが望ましいですか？
VBは区切り文字を入れ、datファイル1つに２行で書き込んでます。再度呼び出す際にsplitでそれぞれのTextBoxに入れてます。
が、何かのタイミングでTextBoxが増減したとか面倒そうなんですが一般的にはどんな感じでしてるんですかね？ 自分で使ったことはないけどinterfaceはデフォルト実装持てるようになってなかったっけ？ まあどうしてもバイナリ互換性を崩したくない時に使うもんだよね あるdll（A）にインターフェイスが定義されており、別のdll（B）にその実装があった場合、Aを修正してもBに影響がなければバイナリ互換性があると言う。
たとえばAのインターフェイスに実装を持たないメンバーを追加するとBはコンパイルエラーになってしまうので互換性が崩れる。
Aにメンバーを足す際にデフォルトの実装を書いてあげれば、Bはコンパイルエラーにならない。
破壊的変更にならないようにフレームワークやライブラリを改修したいってのがインターフェイスのデフォルト実装の動機。 まあCOMみたいにナントカ2とかナントカ3とか増えるのもまたアレ感があるんで "IsDisabled": false,
"Name": "Tap",
"Arguments": [
"Keys.O",
"112",
"12600",
"True"
これって、キーボードのOを112ms間押して、12600ms離すって意味だよね？
約24時間、キーボードのＰを押す時間も離す時間もランダム（10～10000msの範囲で）にしたい場合どう入力したらいいの？
あと24時間以内にとある画像を認識した場合、認識したその都度Ｗ、Ｓ、Ａ、Ｆを押すという時どう入力したらいいの？ アップキャストを行うと何が嬉しいのでしょう？
インスタンス化は普通
クラスA a = new クラスA();
なのに
クラスB b = new クラスA();
ってする意味です。入れれるのと使えるメソッドはイメージ通りですが、使うタイミングが不明です。 >>458
親クラスがクラスBで、クラスBを継承したのがクラスAってことなんだろうけど、
クラスBを継承したクラスCを追加して時に、クラスAとクラスCを同じように扱いたい時に使う。 >>458
foreachでまとめて処理するのに使ったかな。 >>458
あえて言えばサブクラスで隠蔽（new)を使ってるメソッドやプロパティがあると、
サブクラスのインスタンスをスーパークラスの変数に入れた場合に
動作が変わってくるんだけど、恐らくそういう目的でそれをやるケースは
ほとんどないんじゃないかな。
ほとんどの場合、それは積極的な意味を持たないと思う。 >>458
List<Human> list;
に派生したクラスとかを入れたい時に使う >>462
大阪人「は」人間なので、そんなことは不要。
class Human { }
class Osakan : Human { }
....
var o = new Osakan();
var hs = new List<Human>();
hs.Add(o); アップキャストってそれ自体を目的にするものなのかな？
意識せずに使ってるだけで、見方を変えればアップキャストが目的とも言えるのかもだが >>463
それ暗黙的にアップキャストをしてるから不要ではないよね？
質問が、アップキャストの嬉しさについてだから例としては適切だと思うけど
アップキャストとしての嬉しさではなく、
クラスB b = new クラスA();という変数を作る意味があるのかって話なら、大抵は暗黙的なキャストてどうにかなるからやる意味はない var s = new LinkedList<char>();
_ = Console.ReadLine().Select(x => s.AddLast(x));
これでsに標準入力が入る気がするのですが実際何も入りません
どうすればいいんでしょうか？ ポカミスだと思うけど、Selectはシーケンスを返すだけだよね。
Selectが実行された時点ではstringの中のcharを列挙したりしない。 >>467
var s = new LinkedList<char>();
_ = Console.ReadLine().Select(x => s.AddLast(x)).Count();
こうですね...
遅延評価にハマりました
ありがとうございました var s = new LinkedList<char>(Console.ReadLine());
というかこれで良かったみたい Select(x => s.AddLast(x))
はやっちゃ駄目だろう >>457
このスレってJSONを推してる人むっちゃ多いんだけど、CSVと比べて何がいいの？
CSVに出来なくてJSONに出来ることってあるの？ 階層構造を持たせられる
項目の追加が楽
シリアライザが充実している
方言の多いCSVと違い、仕様が統一されている CSVの方がよさそうならCSVって回答するけど
このスレくらいの質問者だと背景や用途を喋らないので最大公約数的回答になる >>473-476
ありがとうございます
なるほど、XMLでも階層構造は持たせられるけど仰々しいですよね
ああ、あれをシリアライザって呼ぶんですね
昔、一回JavaだかでJSON読んでみて満足した記憶があります
GW明けの使い捨てのスクリプトではJSONで書いて読んでみます unityでc#ぼちぼち覚えてきたけどc#って何ができるんや [ {"a" : "1"}, {"b" : "x"} ]
a列のみとか、b列のみしかないJSON が、CSV では、
a,b
1,
,x >>477
階層を持つのは後の欠点にもなるからね
結局はCSV形式で持ってた方がいずれ近いうちなるデータベース対応時に楽だよ >>484
なんでだよ
階層データじゃデータベース入んねぇだろ 楽じゃないな。
きちんとした形してるなら階層持ってるデータのほうがマシ。
正規化するよね？常識的に考えて。 jsonはそのままクラスに持たせられるから便利
あとパースできない読めないってことが少ない
xmlもcsvと比較するとjsonに近い
csvはそのまま行と列のデータだからDBにいれるだけなら悪くないしそれならサイズ的に軽い
改行ダブルクォーテーションとかあと上で言う方言とかあるから、なかなかトラブルを消しきれないこともある
Excelでもよみたいとか要件があるならcsvかな >>487
エクセルで読ませたら先頭のゼロ消すやつとか日付のフォーマット変えるやつとか、ハイフンがついた数字を日付にするやつが現れがちなのですごく嫌かな。 目的の違うデータ形式を個々人で違う基準で評価してあーだこーだ言っても仕方ないのと違うか。
ただ。
json 形式の意味があるのか分からない深い階層を持つデータに対応するクラス作ってたときは本気でイヤになったけど。w
きちんと正規化して意味のない階層だとかを排除してくれるなら扱いやすい方式だとは思う。 < json csvのrow/columnをjsonで表現できるが逆はできないからcsv⊂jsonだけど
大量のデータを扱うにはjsonは冗長だよな。 jsonで大量データだと、容量削減のために要素名を変数1文字とかやりだすしな >>491
そんなことするくらいなら圧縮するわ
冗長だから圧縮した状態同士での比較ならCSVと変わらん >>493
デカイ階層データで気になるのは処理速度だから圧縮されると余計時間かかる シリアル化方法（ＣＳＶをシリアル化とは普通は呼ばない気がするけど便宜上）を選択する上での
評価基準としては、
(1) 可搬性
(2) 対応するデータ構造の自由度
(3) 変換速度
(4) バージョン耐性
(5) テキストとしての可読性（これが重要なケースはほとんどないと思うが...）
こんなとこかね。
CSVで評価できるのは(1)ぐらいなので積極的に使う理由はないね当たり前だけど エクセルおじさん用のデータ交換フォーマットと割り切ったほうがいい >>494
展開時間かかる代わりにアクセス時間が相当減るから、変わらんか早くなるよ。 用途次第だけどjsonのままDBにつっこめばいいじゃん（） >>497
そんなのCPUとI/O次第としか言えん 結局、データベースに入れる運命なのに今の時代に階層データにするやつなんか頭悪いんだよ いまどきはどんなDBMSでもjson形式のデータインポートくらい出来るだろ
LINQでクエリ走らせるだけだろ >>496
じゃあjsonはテキストエディタおじさん用か。 最近のRDBMSだとjson型とかあったりするからな。
>>499
ライトはともかくリードは2021年だと殆どの場合で早いぞ。 >>504
いや、リードが速きゃ圧縮してなくても速いわけだが… >>500
もう言われてたけどjson型サポートされてるRDBMSもある。触ったことないのでパフォーマンスは知らぬ
mysql,PostgreSQLはカラムの型としてサポート済で、oracleとsqlserverは文字列型で格納して制約や関数でjsonとして扱う感じなのかな？
PostgreSQLだとjsonのキーに対してもインデックス作れるんだね。便利そう 激レアケースを例にあげて自分の失策を正当化するのは良くないぞ
今の時代にデータベースに入れにくいデータ構造にしたのは明らかにバカ
それがわからないならお前らも結局時代に対応できないんじゃんｗぷｗ >>507
rdbに突っ込むの前提ならcsvでも正規化されたテーブルが対象なんだから入れやすさなんかだけでは語れない。csvのデータは概ね正規化されたデータの結合と見れるので。
正規化·データの関連性を考えればjson·xmlの方が有利まである。
結局用途次第だと思うよ >>505
10MBのデータ読んでメモリに乗せるのと、100KBに収まったデータを展開してメモリに乗せるの、だいたい後者のほうが早いぞ。 >>509
は？じゃあjsonそのまま入れてみろよ CSVはインポートで有利とか言ってる人が居るけど
ほとんどの場合インポート用CSVに整形する手間があるからトータルで損してるんだよね >>509
そうやって実際にはできないことできるってなんで言っちゃうかな？ >>512
それはあるな
一応データエンジニア名乗ってて仕事でいろんなCSVをロードしてきたけど、貰ってきたCSVをそのまま取り込めるのは稀だわ 交通整理マンが出てこない時は（以下略
>>510
どんな圧縮率w >>515
そんな誰も使ってない上に階層構造のjsonに使えるかどうかもわからん上に
さらに絶対仕事で使えないもの持ってきて必死だなｗ
採用実績あるの？ソレｗ >>517
カラム名が長いなって思うようなデータだと、それぐらいの圧縮率になるぞ。
おまえやってみても無いだろ。 >>512>>516
英語が世界共通語として機能しているのは
英語が優れた言語だからではない。
可搬性と技術としての優位性は完全に別問題。 まぁすれ違いなんで最後で
>>513
そのままなんか入れないよ。
csvも正規化されたテーブルに分解·展開して入れる
jsonも正規化されたテーブルに分解·展開して入れる
データ構造の形で関連性が分かるのでこの点ではjsonのほうが有利
これはわかるでしょ？
まぁxml·jsonは言われている通りにdbmsがサポートしている場合があるから、その場合はそのまま入れればいいけども >>521
なんで嘘つかないとならんのだ。
知らなかった事は、勉強になった、で済ませた方がいいんじゃないか？ >>523
じゃあ、できないじゃん
>>524
やってないってさｗ
嘘つきくん >>525
俺は、やってるよ。
jqで突っ込む事もあるけど。
jsonで持ってるとnullと空文字の区別がついたりそこそこ便利なんよ。 じゃあ、jsonぶん投げて入れてみろよ
どこのテーブルのどのフィールドにどうやって入るかもわからんけどｗ
階層になってるデータをなｗ
なんでできないこと言っちゃうかなｗ 時空が歪んで20年くらい前の環境からレスしてるんだろ
火曜日のインターフェース不要さんと同じ人っぽいし データベース使うとインターフェースも出番ないよね
そういうテーブルないし データとしての互換性は全く無いが、同様にinserted,updated,deleted列を持っているデータ、なんかはインターフェイス作っても良いんじゃないの？ >>510
だいたいって言われてもねぇw
圧縮ソフトによるけど1/100に圧縮できるソフトだとそれなりにCPU負荷もかかるだろうしね >>527
> どこのテーブルのどのフィールドにどうやって入るかもわからんけどｗ
> 階層になってるデータをなｗ
マジで知らないなら黙ってなよ…
１つのフィールドにjson形式でそのまま（内部的にはデシリアライズしてるだろうけど）入るんだよ
jsonをサポートしてるrdbmsはjsonの階層も含めて検索などができる
ただ、rdbmsによるだろうけど制約かけられないとかインデックス効かないとか色々制限あるので使い所はよく考えた方がいい 流れあんま見てないけど何MBにもなるjson扱うって結構あり得る事なの？
GTA5も数十MBのjsonからのデータ読み込みがパフォーマンスのボトルネックになっててクラッカーが改善Mod作ったいうニュース見たけど、普通はそんな膨れ上がるならsqliteとか利用するもんじゃないのか？ >>538
あるよ。
ブラウザで3dモデル表示するときに使う形式にglTFってのあるんだけど、もろにデカいJSON。 プログラミングでファイル入出力を早くするにはやっぱり
良いGPUが必要なんでしょうか？
C#とGPUの関係を教えてください。 ちなみにGPUは欲しいですが3Dのゲームはしません(ゲーミングPCを購入予定ですが…)
プログラミングの良い環境を整えたいのでお勧めのがあれば教えてほしい
言語はもちろんC#です。 そんなレベルならMac買っとくのが無難
なんでC#なのか知らないけどC#を選んだのもその調子じゃどうせまともな理由じゃないだろう ファイル入出力はGPU関係ない
ストレージに左右される
HDDよりもSSDの方が速い
何のプログラム作るか知らないけど
WinFormsでアプリを作るならGPUは関係ない
WPFで作るならアプリの描画にGPUが使われる GPGPUってなんか暗号通貨のマイニング以外で聞かなくなっちゃた印象があるけど
C#から簡単に使えるライブラリとかあったりするん？ >>538
あるだろうね
サーバーもクライアントもDB持ってるけどその間のやり取りはjsonでとか普通にあるから
ストレージとしての用途ならsqliteでもいいけど伝送手順として使われることも多いので >>543
大学の課題でテキストを読み込んで文字列を探すプログラムを作ってます。
文字列を読み込むスピードをほぼ0秒にすると実行時間が短くてすむので
良いGPUはないかと思ってるんですがね。。。 折角回答してくれてる内容の1行目を声に出して10回読め >>546
GPU関係ないって書いてあるじゃん
重要なのはストレージとCPU
速ければ早いほどいいというだけ ありがとうございます。
どんな高性能なPCでも時間は0秒にはならないってことですね？
俄かに信じがたいですが、早くなる方法ないでしょうか。 信じられないなら信じられる別の場所で聞けばいいんじゃないの。 > どんな高性能なPCでも時間は0秒にはならないってことですね？
C#全く関係ないスレチ
あと元の質問自体が「サッカーで速く走るにはいいスパイクが必要なんでしょうか。シュートとスパイクの関係を教えてください」みたいな謎文脈なので、
こちらはそっちの脳内でどんな解釈されてるのか、まるで見当が付かない >>550
そういう根拠のない思い込みでこうなるはずなんて思考をしてたらプログラミングなんて理解できなくて詰むから、早いうちに矯正しろよ
まあ根っから性分だろうからもう手遅れだろうけど 今jsonの話で忙しいのに話の腰を折る荒らしにしか見えない 大学の課題でスペックの条件が必要なの？
無駄のないロジックを書くとか、そういうのが目標だったりしないのかな。
なんだったかな。C#だったらライブラリのメソッド一発で終わってしまう話だよ。
スペックが必要ならハードディスクじゃなくてSDとかの電子メモリにするだけ。 うっわ
ファイル名変更ってgit上で削除→追加になるのかよ
なんでこんな仕様なんだ面倒くさい 大学生が処理時間を0秒にできると考えてることが恐怖 まあgitはC#プログラマーでも使ってる人多いし、意味不明な大学の課題よりマシ c# でもファイル名変更はFile.Moveメソッドだし、考え方は同じだと思うがな。 真面目な話、設問の但し書きの部分を真に受けただけなんでは、とか思うのだけど。
「ただしファイルI/O などの処理時間は無視できる物とする」とかの。
大学の課題に取り組むのに私物のゲーミングPC を用意するって時点で意味が不明だもの。
私物の環境で設問をクリアできてもそれを持ち込むことなんて出来ないだろうし。
どこかを取り違えてたんだろ。 並列処理においてボトルネックになりやすいのがI/O
そこを改善しようと試みるのは良い
ただしこの場合C#とは関係ない話なのでスレタイすら読めない脳足らずという事になる 最近はサーバーで、データベースのCPU が不足する事も多い C#とJAVAを併用してるけど、C#の解説者のほうが深く理解していて簡潔に解説してるね。
JAVAはコピペで説明していて、動かないことも多々ある。採用人口が多いのに不思議
androidの仕様変更が原因のときもあるけど、C#は洗練されて理解しやすい。
つまりC#を扱う人はレベルが高いと感じる /// 問題点 ///
処理をどのクラスに持たせるのかの指標がわかりません。。。
同時にクラスの分ける粒度感もわかりません。。。
/// 質問 ///
どのクラスにどの処理を持たせれば良いのでしょう？
そもそも何をクラスにしたらいいのでしょう？
/// 具体例 ///
前者でいえば例えばドキュメントクラスとプリンタークラスがあって印刷するメソッドはプリンターに持たせるのかドキュメントに持たせるのか決めきれないということです。
後者でいえば例えばキャラクタークラスがあってそのクラスはHPクラスやMPクラスを作りインスタンスを持つべきかそれともただ単に値型のフィールドとして持つのかどちらが良いのか判断しきれないです。 >>573
前者の例は現実と一緒じゃダメなん？
印刷の機能は書類じゃなくてプリンターの仕事。
後者はどうなんだろう。
自分なら、値型の方が代入比較が簡単で早そうだから、ギリギリまで何でも値型で。
でも、参照型の方がクラス継承とか参照渡しとか出来るから、その時の都合で使う。
機能と性能、仕様と規約、自分の主義で決めたらいいかと。 >>573
お答えしましょう
どこに書いても動きます
好きなところでいいですよ C#関係ないやね
折角なので答えると正解はない問いだと思う。みんながベストを探してる
つくるソフトや環境で適切なモノを周りと相談して作り上げるしかない
とりあえずの指標という意味であればDDDについて調べると具体例の質問については答えが得られるかもしれない
特に後半はvalueObjectとEntityと言われるもの
ただしこれも小規模のソフトで取り入れても冗長になるだけという問題もある >>573
1. どういう選択肢があるのかを把握できる力
2. それぞれの選択肢のメリットとデメリットを理解する力
3. 用途に対してより適切な選択肢はどれなのかを判断する力
あらゆる設計判断には上の3つの力が必要だが土台となるのは1と2の力
それらの力をつけるためには考えられる複数の選択肢をそれぞれ簡易実装してみて比較検討するのが一番
失敗を数多く繰り返すのが上達の近道
どのクラスにどの処理をもたせるのがいいのかは用途次第でケースバイケース
one size fits allな答えはないのでやる前からそれを求めていても進歩しない どっちでもいいからまず作れ
なんかへんだなと思ったらリファクタ >>573
そういうのはやる前からいろいろ考えるより
「失敗したらやり直せばいい」と考えてとにかくいろいろコードを
書いてみることが大事。
老人より子供の方がスマホなんかの操作を覚えるのが早いけど、
あれと同じだね。
アントニオ猪木のポエムのノリでw 574から579の方々
ありがとうございます。
とりあえずやってみるというアドバイスが多かったので実装から着手していきたいと思います。
この質問の背景としてはクラス図やUMLでの設計をしてC#コードに落とし込もうとしてクラス図がごちゃごちゃし出してコーディングまで行けなかったという経緯です。
(OOPの話でc#そのものの質問でなかったのは申し訳ない。とはいえc#初心者の人でオブジェクト指向が初めての人は少なくないはずなのでやはりこういう質問になりがちな気もする)
様々な意見感謝です☺
参考させて頂きます。 この前質問したバカですが(一応国公立)
何故レースゲームは膨大な建物や道路データをリアルタイムに
読み込めているんでしょうか？どういう仕組みなんですか？
例えば1Gのテキストファイルを読み込もうとすると実験しましたが、10秒かかってしまいます。
テキストファイルではなく、グラフィックデータを瞬時に読み込めるのはなぜですか？
C#より速い言語なんでしょうか？ >>581
streamとして必要な分だけ読み込む、圧縮したデータを読み込んで展開する、あらかじめパーツを指定しその配置だけ読み込むなどなど
最初以外C#は関係ないから該当する板でやってくれ
ゲ製作技術
https://mevius.5ch.net/gamedev/ >>581
そのレースゲームがどんなんだか判らないけど、
ゲーム中じゃなくて起動するときに10Gでも100Gでも、
あらかじめ10分かけて読んでおけば良いんじゃないかな。
圧倒的に問題に対する条件が乏しくて、どう考えればいいのかこちらも判らないよ。 >>583
市販のゲームは10分もかかりませんが、何故でしょうか？ 地図上の物体検索とかなら
numerical recipes の3rd edition に
説明があるからそれを読みたまえ。
なお日本語もC#版も無い >>584
583は分かりやすく極端な例を出しただけで常識的に考えて10Gのデータ読み込みなんてしないっしょ
大体重めのゲームでも起動時やマップ入場時のロードは500MBくらいじゃね？
つまりそのレースマップ入場時にそこで必要なグラフィックデータを数十秒かけて読み込ませればいい >>584
君のレス追ってみたけどゲームじゃなくて目的はテキストファイル？
ファイルI/Oにボトルネックがあると思ってるようだけど、テキストファイルだとしたらボトルネックはエンコードにあるんじゃない？
File.ReadAllTextは割とオーバーヘッド大きいから、.NetCore3以上でSpanを利用したエンコードを構築すればいくらか早くなるかもしれない >>581
自分もゲームまったく知らないので偉そうなことは言えないけど、
いきなりそんな高度な話より、例えば40年前のゲームのスーパーマリオは
たった30kBの中にどうやって32面分オーバーのマップデータを詰め込んだかを
考える方が有益だと思う。
要するに本質はI/Oじゃなくてデータをどうやって圧縮/展開するかじゃないの？
「リアルタイムで（ストレージやネットワークから）読み込み」なんかしてるはずがないと思うけど。 馬鹿は的確な質問ができないってのを凄い的確に示してくれている ファミコンカセットはROMアドレス指定でCPUからダイレクトアクセス出来る
初期以外はアドレス足らないからマッパーで切り替えてる。物理で プレイステーションのすごいところは
ファミコンやPCエンジンと違って
ロード中にギャラガができる事
作りての工夫によってロード時間ゼロにすることが可能
ドラクエなんかはマップ切り替え直後はエンカウントしないよね サガフロの5連携が3連携で一休みしたりサガフロ2の連携が我々のレベルになると通常と変わらず目で追えたり
RAMが少ないと苦労が耐えないですね
えーっと500MBでしたっけ？ウフフ >>591
ファミコンはそもそもロード時間ないだろ >>594
ファミコンやPCエンジンと違ってって自分で言っとるやん ？
つまりdiskとdiscについて話し合いたいってこと？
スレ違いでは？？ >>581
結婚式場を出たら、もう披露宴会場が準備されていました
これを披露宴会場の支度を瞬時に終えたと言うことだと思うか？ MIDIとかMMLの方がたとえ話としては適切だったかな
たった数10kBのMIDIファイル一つで16bit-48kHzの音を何分も出力できるのはなぜなのか。
1分音を鳴らすのに6MBの量子化データが必要なはずなのに >>586
10Gは大きいとか目安が分かるのすごいですね。
ゲーム制作者じゃなくてもわかるんですか？
>>587
そうなんですよ。テキストファイルを読んで、特定文字列の抽出カウントを
行いたいわけです。C#じゃなくてC言語なら夢見れますか？
低級感があって爆速なイメージですが。
>>588
難しいですがゲームプログラマが夢なんで、思考自体は高度になりがちです。
まず30kbってのはメモリ領域でですか？磁気領域でですか？
そもそも何でCPUの進化バージョンGPUは存在するのに
HDDの進化バージョンGHDDみたいなのは無いんですかね。
あったら困るんですかね？ うん、C#じゃなくてC言語がいいと思うよ。
頑張れ 高度どころか怠慢な素人丸出しなんだが。
高度なことを望むならまず地道に足場を固めていくべきじゃない？
すごいことをやってる(みたいだ)から、その方法を教えて！じゃなくて、自分でその理由を調べることをしないと成長はないよ。 少しずつ積み上げた方がいいという意味を早めに分かった方が良いかと思う・・・ GPUはCPUの進化バージョンではない。
テキストファイルから特定文字のカウントするのに、全部メモリに乗せる必要は無くて、適当なサイズずつ読み込みながら文字カウントしたら？
別にC#でもそんなに重くないと思うけど。 >>600
まだいたんか
ファイルの読出しにGPUが関係するとか変なこと言ってたから素人だとは思うけど
まず>>602が言うように足場から固めていった方がいいよ
ゲームは小さい処理の積み重ねなんだし
ファイルIO
データの圧縮展開
CPU/GPU制御
並列制御
アルゴリズム
etc・・・
一人でやるんだったら全部自分で制御しなきゃいけないんだし このセンスの無さすぎはひどいな
ゲーム作りたい中学生でも簡単に理解できる話なのに 597には応えてくれなかったな
質問を変えよう
母に呼ばれてリビングからダイニングに行ったら食事の用意がされていました
これはリビングから呼ばれた者がダイニングに行くまでの一瞬に、
母が食事を用意したと思うか？ >>600
ストレージの「革新」については15年ぐらい前にこんなのがちょっと話題になった。
だけど、自分が知らないだけかもしれないけどその後の進展を聞かないね。
https://gigazine.net/news/20060710_mram/
NVRAM的な物のコストが下がれば記憶デバイスのカーストの中にある
メモリーとストレージの間の分厚い壁が崩壊するわけで、かなり革命的な
ことなはずなんだけど。 しかしいつもの交通整理の人はこんだけ質問者が罵倒されてるのに何で黙ってるのかね。
ここはそういう行為が禁止されているはずのスレではなかったのか（笑） それ以前に連休で暇だとしてもなぜこんなみえみえの嵐に付き合うんだよ… >>607
いやわかりますよ。料理を調理する時間が
HDDアクセスってことですよね？ただ料理と違う部分は、煮えるまで待つとかなくて
目的のものをとってくるだけでいいから、一瞬でその場所にいけたら、
基本的には0秒なんですよね。HDDのシークバーがその場所から動く必要がなければ最速ってことですよね。
すいません、そろそろ去ります。
基本的にC#単独では無理という結論にしました。。。 本人に聞きたいわけじゃないのだが、基本的に０秒ってどういう意味なんだろう
文中に出てくる一瞬って言葉は0秒じゃないし、なのに一瞬で行けたら基本的に０秒ってのはどういうことなんだろう
小数部は切捨てて整数部だけを考えることを基本的にって言うのかな？ HDDの代わりにGPUにデータファイルを置けば速いって意味だろ その後に思ったことなんだけど、ファイルI/O 以外の処理速度が気になる。
100MB だっけ。そのテキストファイルの中身がメモリにあったとして、検索が終了するまでの時間はどのくらいだったんだろう。 >>612
君は面白いおもちゃだな
実際に1秒で100MBでしか読めなかったらそれを使ってどうやって派手だったりリアルな画面を作ってやろうかと思うのが
PGやゲーム制作者です
ハードに自分の要望を求めるのは単なる消費者です
昔はもっと制約が厳しかった
自分たちは子供のころからそればかり考えてた
あおりでもなんでもなくあなたには向いていません いわゆる「ロード中」っていう処理待ちをさせずマップ切り替えが可能なゲームがあったけど、そういう話かな。
古い時代の話だから、今じゃ大したこと無いかもね。 そもそもPCのマザボに
CPU、メモリ、HDD、グラボ乗ってんだから
それぞれに行き来するのに時間かかるってわかるやろ
CPU↔メモリ↔HDD
メモリ↔グラボ
とりあえず物理的にどうやってくっついてるのか調べるべきだと思う まぁ自作したことすらない子も多い。
うちの会社もゲームやゲームハードも作ってるとこなのに開発メンバーなのにスカジーケーブルすら知らん子が入ってきてる。
抽象化や隠蔽化が進んで上のレイヤーばかり意識するようになってるから地盤が無い。 >>618
そお？
動作を「速く見せる」ための制約条件としては確実に必要な要素なんだけどね。
いまさらだけど。 >>624
SCSIなんか知らなくて当然だし別に何も問題ないと思うよ
むしろ「お前らこんなの知らないだろう」オジサンの方が問題だw もうISAやCバスだって知らない人の方が多いよね。下手したらAGPも
それどころかPS/2やLPTみたいなちょっと前のレガシーポートだって
今の20代の大半は知らないだろう その辺の事務や営業じゃなくて、コンピュータハード作ろうという子がバリバリ現役のスカジー知らんとか相当不勉強なんだけとw
Unityでちゅろっとゲーム作るような層じゃあるまいし。 >>628
SCSiが現役な程度にはISAバスだって一部の産業用途で現役だけど、
さすがにあなたもISA知らんのは不勉強とか言わんでしょ（笑）
要するにそれ自分中心主義なんだよ
そういうおじさんみっともないよマジで 一部業界でしか生き残っていないものを知らなくて当然
SCSIが一般的でなくなってから相当経つからな コンシューマゲーム機だとSCSI使ってたのは、ドリームキャストとかGBAの世代までだったなー
SCSIは相性があるから結構厳密に型番指定されてたっけ
そしてそれら以降のハードはみんなUSBだった気がする 「SCSIを知ってる」ってどのレベルでのことを言ってるんだろう。
名前を知っていればいいレベルなら、必要になったときに調べれば済むんじゃ。
昔に流行ったの技術を知らないのは不勉強、って言われても困るような気がする。 SCSIは抽象化されて残ってるじゃん
物理インターフェースだけの存在じゃない
iSCSIなら当たり前に見かけるだろ
そもそも0と0を超えた時間とを同一視し、
0にならないことをにわかには信じられないと宣う国公立大学生って嘘くさい
国公立中学生っぽいからまずは基本情報技術者の勉強でもして、
言語とハードウェアの関係から学ぶのがよさそうだね 抽象化や隠蔽化の進んでいない下のレイヤーの話としてのSCSIケーブルだから
iSCSIやSASは想定していないと思うけどなぁ それは今の必須知識じゃないからね
SCSIバスやケーブルの知識があっても、今となっては古いシリアル規格の知識でしか無い > C#に関係の無い話題や荒らしの相手や罵倒レスや酔っぱらいレスはやめてください
> C#に関係の無い話題や荒らしの相手や罵倒レスや酔っぱらいレスはやめてください
大事なことなので… インターフェースって継承以外でインスタンス化してフィールドに持たせるように使う場合があるけど、それって違う場所に定義している関数を呼び出して使うような感じ？
いまいちインターフェースの使い方がわからぬ 「コントロールがきかない、再コンパイル依頼が効かない」第三者にバイナリのdllを公開してかつ、3年5年と更新しつづけていけばいやでもわかる。 オブジェクト指向の言語やってて、デザインパターンの勉強しない奴とか居るんだな。 それぐらいなら別にinterface要らんけどな
自社DLLの指し替えOKならメソッドの中身変えるのはできる
TypeScriptのinterfaceぐらいになったら便利だけどC#やJavaのinterfaceはそこまで重要じゃない >>638
実装を入れ替え可能にするために使う
インターフェースを使う側はインターフェースがどう実装されてるかを気にしない
関心事の分離や責務の分割というやつ
public class CustomerService
{
private readonly ICustomerRepository customerRepository;
public CustomerService(ICustomerRepository customerRepository)
{
this.customerRepository = customerRepository;
}
}
CustomerServiceはcustomerRepositoryがどういう永続化技術を使ってるか関知しない
RDBMSを使った実装からKVSを使った実装に変更したとしてもCustomerServiceクラスは変更する必要がない
単一責任の原則や依存性逆転の原則というオブジェクト指向設計の基本原則に従ってる >>638
全然違うものを透過的に扱いたい場合ってあるでしょ？
例えばビデオゲームで入力デバイスとしてゲームコントローラーだけでなく、
キーボードやタッチパネルも使えるようにしたいとか。
とりあえずはInterfaceはそういう要求を満たすためのものだと
理解しておけばいいよ。それ「だけ」ではないけどね 汎用性を高めるためって考えた方が分かりやすいかもね。
昔テレビデオってあったけど、世の中にHDMIみたいなインターフェイスが存在せずに
ああいうモノリシック構造の機械しか存在しなかったらどんだけ不便か考えれば
インターフェイスの意味なんてイチコロだと思うけどな 関数を渡すとしても、引数なり戻り値なりの型を定義しないとならんしな。
実装を含まない定義を切り出しておかないと、容易に循環参照になってクリーンビルド出来なくなるぞ。 >>645
デリゲートで済む用途に（無理に）インターフェイスを流用しなくて済むようになっただけ。 インターフェイスつかってるとVisualStudioで定義に飛んでもメソッドの実装見れないから腹立つんでやめてください。 >>648
逆に、実装を見るなという意思表示では？ >>649
見られたくない恥ずかしい実装してるってことですねわかりました class X: IX {
private IY y;
public X(IY yy) {y=yy;}
public T foo(U u) { ... }
↑こんなの冗長で面倒くさいだけじゃん
↓これでいいんだよ
static class X {
public static T foo(Func<...> y , U u) { ... }
C#最大の欠点はTSなどと違ってトップレベル関数を定義できないことだな
まあそのうち導入されるだろうけど
>>647
まあそうだね
そしてデリケートで済まない用途なんてのは、ないんだなこれが OKでは
(1) IEnumerableと機能的に等価なものを実装してみせてほしい
(2) IComparable<T>はComparison<T>で置換できるが、
(a) ジェネリックでIComparableで制約をかけるのと同じことはどうやって実現するのか？
(b) 毎回いちいちComparisonを指定しなきゃならん煩雑さはどうしてくれる？ >>651
Funcの型と、Uはどこで定義した何なの？
俺ならUはインターフェイスにすると思うけど。
fooを呼ぶ側も、foo側からも参照できる型である必要があるよね。
なんとなくプリミティブしか意識してない気がする。 制約の問題はIComparableぐらいならコンストラクタで必要なデリゲートを指定しないと
インスタンス化できないようにするみたいなことで解決できるけど、
インターフェイスのメンバーが多かったりイベントを含んでたりするとそうもいかんね。 >>652
(1)
var (moveNext, getCurrent) = MyGetEnumerator(x);
シンタックスシュガーは流石にコンパイラのサポートないと無理よ
(2)
(a)言語サポートないと無理だね
逆にいうとそういう機能を言語でサポートすりゃいいんじゃない？
言語機能の利点であってinterfaceの利点じゃないよねこれ
(b)もっともらしいデフォルトを用意するだけ
>>653
Funcはシステム定義だが？
TやUは架空のコードでよくあるただのプレースホルダであって特に意味はない
どこかで定義されていると考えていいよ >>655
プレースホルダはわかってる。
引数の型の定義場所が問題だって言ってんだけど。
実務したことない？ >>656
言ってること意味不明だから多分君なんか勘違いしてる >>648
実装へ飛ぶ的な右クリックメニューがある >>657
クラスに実装するのなら、ドメインに焦点を当てたクラスにその実装も凝集されるけど、
外部からデリゲートで渡す場合はそのデリゲートをどこに定義すんのって事じゃない？
1回しか使わないのなら匿名関数でいいけど、複数箇所から同じ用途で使うのなら書き捨てじゃなくどこかで定義しておきたいと思うし、
更にそれが一体何のための処理なのかを設計に落とし込むなら適切な場所で宣言実装しないとだし
抽象的な話してると自分の頭じゃ理解しきれないな
こういう設計の場合こうすればよくね/こういう問題があるやんっていう具体例が欲しい >>657
>>661が殆ど言った。
インターフェイスはインターフェイスで切り出しておかないと、
完全に単一のアセンブリでやらない限り、循環参照しがちだぞ。
AクラスのメソッドFooがBクラス受けてて、
BクラスのメソッドBarがAクラス受けてるだけで困ったことになる。
これはA.Foo(B)→B.Bar(C)→C.buz(A)と遠回りになってもそう。 >>661
構文レベルでクラスで書く意味はなく、関数でこう書けばいいでしょ、って意図のレスに対して
その疑問(設計レベルの問題)って方向性ズレてるってことは理解してる？
まあいいけど
ドメイン上のある責務に関連した処理をまとめたいって意図で聞いてるなら、モジュールで分ければいいよ
クラスは要らない
例えばOOPでIY, YがリポジトリでIX, XがリポジトリのCreateメソッドを使う何らかのサービスだったとするよ
関数で書くときはYモジュールにget, update, create, deleteなどの関数を定義する
Xにはfuncを定義して、もし関連性が高い別の機能もあればまあ一緒に定義してもいい
んで実行時にはX, Yをインポートして
func(create, u);
みたいにして呼び出すだけでしょ
funcとcreateをバインドして
_func = u => func(create, u);
みたいにしてDIでやってるようなこともできる
これならインターフェースもクラスも要らんよね？
関数だけがあればいい
構文上のムダが多いクラスを使う利点はほとんどないよ
>>662
相変わらずなにが言いたいかわからん >>663
できるできないの話ならアセンブラなら何でも実現できるよw
> 構文上のムダが多いクラス
と言うなら何がどうムダなのかを書かないと単なる個人の感想にしかならないよ >>665
＞できるできないの話ならアセンブラなら何でも実現できるよw
意外にこれが本質だろうね。
一昔前のOOP批判にも「構造体でも同じことが実現できる」ってのがあった。
そりゃできるに決まってるが、そういう批判には無理してそうやって
書いたコードが果たして人に理解しやすいのか、
人間の認知能力に親和的なのか、という視点が欠けていた。 おじいちゃんこないだから暴れ過ぎ
OOPもInterfaceも不要って何でC#使ってるんだろう xview/sunview のAPIは全部構造体だったなぁ >>663
構文レベルでは引っかかるところは無いので、設計レベルの質問した感じ
自分の理解があやしいのは自覚してるので質問しつつ補おうとしてる ※自分は半人前くらいなので
663読んで見えてなかった場所が見えたのだけど、
>>651のコード例でいうとIYとYの定義が無くなって、代わりにYモジュール増えてるんだよね？
差し引きで言うほど構文が楽になってる？この辺は個人の感覚だけど、そんな変わらないような気がした
ついでにいうと、Xから見たときに何やってるのか解らなくなってる気がした
インターフェース使った時であれば詳細は良くわからんけどリポジトリ用のIYインターフェース使ってそっちに任せてるんだなという隠蔽だけど、
デリゲートでやると何か良くわからん関数受け取って処理させてるわってならない？ >>666
関数のほうが認知しやすいよ
OOPみたいにあちこち参照しないし
interfaceのように不要なメソッドにも依存しなくなる
>>667
ぶっちゃけ昔は選択肢が少なくJavaよりC#のがマシだからって理由かな
あとは惰性
>>669
C#だとトップレベル関数がないからあんま変わらんかもな
C#も近いうちに変わっていくと思うよ
デリゲートが何やってるかわからないなら命名に失敗してるってこと
命名に失敗したらデリゲートだろうがinterfaceだろうが同じようにわからないよ >>667
突き詰めるといらない
だってc言語で完成されてるし
だから場面場面で使用するメリットを説明できるかってのは重要になると思う
先読みでの将来的に～になる見込みで
先行投資を現場のPGの勝手な判断で行ったってのは相当アホな所業 Interfaceが不要なメソッドってのも意味がわからんのだがな。
OOPでなくとも、型のキャスト可/不可には、インターフェイスがあったほうが良い。
これはGoみたいな、トップレベル関数で書ける他の言語でも同じ。 ここはC#初心者のためのスレのはずなんだけど
このおじいちゃん、なんでこのスレで自分の主義主張を振りまいてるんだろう？
自分の書き方が2021年時点で一般的な書き方と大きくかけ離れた時代錯誤なものと分かったうえで
初心者にもそういう書き方を強要したいの？
それとも誰かに構ってもらうのが目的なの？ 自社の若手に煙たがれて敬遠されてるとこういうスレでクダを巻きたくなるのかな？
率直に言って、このおじいちゃんは
Rubyガイジ並みorそれ以上の害悪だからもうこのスレで書きこまないでほしい 構う奴もガイジって20年前から言われてるはずだがいい加減学習できないのかねチンパン君 昨日は触れなかったけど、関数のメリットの中でも特に大きいのは、テストのしやすさね
インターフェースにしちゃうと、テストモック作んのが面倒くさすぎんのよ
いちおうモックフレームワークみたいなのもあるけど、ありゃプログラミングパズルみたいでマトモじゃない
長くメンテナンスするには疲弊が勝る
そもそもなんでモックが必要になるかって
、OOPでインターフェース使ってDI、なんてことをやるから無駄にオブジェクトの数とオブジェクト間の参照が増えていくからだ
関数なら簡単だ
都合のいいラムダを渡すだけ
関数には無駄なオブジェクトも参照もない
これ以上にシンプルなものはない
これを知ってしまうとOOPなんてやってられんくなるよ まあ１対１のインターフェースは要らないな
複数のクラスを同じ仕組みで扱うときに有効になるものだ 都合の良いラムダを渡すだけ。
そのラムダの引数の型は？
普通ベースクラスかインターフェイスでは？
なんか勘違いしてる気がする。
アセンブリ1つが前提になってる？ >>677
それ関数でいいよ
>>678
意味不明 どう意味不明なのかマジでわからん。
OOを捨てて関数型推したいのはわかるけど。
IDisposableなんかはどう不要にしていく？
IEnumerableは？
IDbConnectionは不要で、クラスがだけあれば良いって話？ >>676
興味あるのですが、参考になるサイトとかありますか？ 初期のC++がCにトランスレートできてたようにクラスやインターフェースなんて無くてもコードは書けるわな
その方が楽とか言うならそれでいいと思う
俺のプロジェクトに関わらない限りは >>682
IDisposableとかIEnumerableのような、言語が特別扱いしてるインターフェースを代替することはできない、ないし難しいだろうね
そういう特別なインターフェースを引き合いに出して、インターフェースのほうが優れてると主張することはアンフェアだとも思う
実際きみたち、特別扱いのインターフェースでしか優位性を主張できてないよね？
ちなみにGoだとdeferという構文があって、
いちいち特別なインターフェースの実装を”強いられる”ことなく、破棄関数を遅延実行させることができる
こちらのほうが洗練されてるね
C++だとこれはデストラクタの仕事になる
インターフェース？関係ないね
C#はどういうわけか、破棄関数の遅延実行にIDisposableというインターフェースを選択したが、だからといって、それがインターフェースの優位性を示すということにはならない >>685
アンフェアでもなんでもない。
IDbConnectionみたいな、何らかのデータベースへのコネクション、を表すものの代替も出来てないよね。
具象クラスでは事足りないし「データベースへ接続する関数を渡すイニシャライザ」からの返り値は同じように、汎用的なインターフェイスにキャストされてないといかん。
Goでもこれはsqlパッケージの中にインターフェイスが定義されてるよね。
と言うか、アセンブリの循環参照もわかってないんじゃないの？
Goのdefer文は破棄の遅延実行ではない。その関数を抜けるときに必ず実行する、だけ。
破棄以外にも使えるんよ。
finally節だと思えば妥当でしょ。 >>685
特別扱いされているinterfaceが例にあげられたのはそれがよく知られたinterfaceの一例というだけの話であって、特別扱いされていることは本筋ではないだろう >>686
データベース接続も関数でいいよ
同じシグニチャの関数セットを異なるモジュールに定義して必要なものを必要な時にインポートするだけ >>688
シグニチャが同じなら、引数も戻り値も同じなんよね。
DBごとに違うコネクションをどう表現するの？
GoでもDriverインターフェイスでさばくよね。DB。
具象クラスのメソッドが呼びたい時はアサーションするよね、 無駄をなくしたとかシンプルにしたとか言ってるけど、言語仕様側で受け持ってた制約を無駄と評して人任せにしただけに感じてしまう
>666で言われてるけど その関数のシグニチャを定義して強制するのがインターフェイスじゃないのかね そう。結局インターフェイスのこと言ってるの。基底になるオブジェクトとかそういう話になるだろうけど。
定義場所の問題。
そんで、それを定義だけ外に出せないのが問題だと俺は思う。 >>682
それを許すならコールバックのがいいなー
結局、実装見てみないとそいつらってわかんなくない？
MSが作ったメソッドなら実装されているだろう多分って言えるけど
それって組む人間の信頼性の話でさ
昔のデバイスコンテキストみたいに
え？解放されてんの？されてないの？
どっち？
みたいなのソースから無駄にわからんじゃん
こういうの欠陥品として捨てていくべきだと思うよ俺は >>693
コールバックはどうかなぁ。
それこそ、呼んでくれるかどうかわからんくない？
例外のハンドリングがいよいよ大変になるから、async awaitみたいにうまく隠蔽してくれる方が良いかなぁ。
確かにまぁ、開放したはずが開放できてなくて再起動するはめになったりしたし、わからんでもないけど、それこそIDisposableなんかでハンドリングした方が良いんじゃないかな。 >>694
ぶっちゃけよんでるかどうかわからんのは退化だと思う デリゲートvsインターフェースの戦いはつまるところ気軽に使いたい派vs丁寧に型付けしたい派の宗教戦争なのだろうな
JavaのFunctional Interface、TypeScriptのStructural Subtyping、オブジェクトリテラルがあれば両陣営とも納得すると思われる >>696
むしろこうだね、
適材適所派 vs. バカの一つ覚え
あるいは
常識派 vs. 俺だけがネットde真実に覚醒したんだ！！派 単純に、7割位のケースで有効な方法が、銀の弾丸な気がする時期じゃない？
Interfaceなり、型クラスなり、トレイトなり、定義と実装を分離する方法は色々だけど、どの言語でも完全に無くなってない事はゆっくり考えたらわかると思うんだけど。
どっちも出来ればいいんよ。
関数型も良いけど、世の中の殆どは状態を持っているんだから、結局モナドなんかを持ち出すぐらいなら手続き型でデータドリブンぐらいでバランスが良いとか、Entityクラスを軸にするんだ、とか、色んな考え方もあるわけだし。 循環参照だけど、例えば、FileLoggerと、StreamWriterみたいなクラスがあるとして、両方別アセンブリになってて、
FileLoggerはStreamWriterを使ってログ出力する事もできる、とすんじゃん？
で、
ここまでは普通にビルドできる。
StreamWriterもログを出力することになって、FileLoggerを使うことにするとすんじゃん？
前回の結果からの増分コンパイルはできるけど、クリーンビルドは出来なくなるよね。
結局は、最低IWriterなりILoggerなりとして、どちらかを定義と実装に分けておいて、
具象クラスをコンストラクタなり、ラムダを渡す初期化関数なりで渡すしか無くなると思うんだが。
ベースクラスと派生クラスにしておいて、ジェネリクス使えばそれで良いのでインターフェイスは要らない、と言うのは一見それで良さそうに見えるけど、
今度はダイアモンド継承になるから、WriterでありLoggerであるものが作れない。
関数型と排他の存在ではないと思うよ。
嫌いなら、必要悪ぐらいに思っといたら？ Action<string> logなりAction<string> writeLineなり必要な関数を引数で渡すだけ
FileLoggerをリビルドするのはFileLoggerを変えた時だけ
StreamWriterをリビルドするのはStreamWriterを変えた時だけ
どちらもコアライブラリであるActionにしか依存しないので常に単体でクリーンビルド可能 >>699
受け渡しする関数のシグニチャ(=デリゲートの型)が
メソッド1つだけのインターフェースと同じ働きをするので
IWriterやILoggerがメソッドを1つしか持たないなら高階関数で処理したほうが適切な可能性もあるよ
map/filter/reduceのように毎回一つ一つの関数を渡すのが便利なものと
リポジトリのように事前に定義された一連の機能セットに互換の型を利用することで
クライアントコードは実装の詳細を気にせず使うほうが便利なものとそれぞれある
比較関数を毎回渡してソートする方式とIComparableを使ってソートする方式の違い
どういう種類の仕様変更に対してどこまで影響が波及するかを比較して考えるといいかも >>700
Action<string>が、どう「ログ出力関数」になるわけ？
そんな漠然としたシグニチャになるわけ無いでしょ。
百歩譲ってAction<LogInfo>だろう。
ログレベルとか発生場所とか全部プリミティブで渡すの？ってのが、>>653だよ。そのログ出力内容が変わったらシグニチャ全部変えてくの？
>>701
うーん、まあ、それもまた然りかな。
一つしか持たないインターフェイスはたしかにそうかもしれん。
俺のイメージはLoggerもWriterも、状態を持たざるを得ないイメージだったので、IDisposableも一緒に持つイメージだった。
ログレベルとか、開いてるファイルと書き込み状態とか。マルチスレッドだとうまく排他しないとログが乱れるから。
IWriterもILoggerも、もう少しメソッドを持つイメージかな。
頑張ればLoggerは一つのメソッドでいけるかもしれないけど、LogLevelみたいなLogger側にEnumは持たせないといかんかも。
DIするなら、ILoggerの方が楽だと思う。 なんか「こうすると後始末が楽」ってのと、「これてもできる」ってのは違うと思うんだが。
Action<string>とかAction<int,string,string>みたいなものでログ出力関数をロガーとして関数に突っ込むのは「これでもできる」側としか思えんのだ。
それでホントに改修も含めた総工数が下がるとも思えないし、
確かに今風だけどメリットはすごく薄いし、
合理的かと言われたら俺は違うって言いそう。 意味不明と言い続けてたのも、
全く解決になってない方法をゴリ押しすんのも、
もしかして、OOP・Interfaceが不要と思ってるんではなくて、OOP・Interfaceの考え方とか活用法を理解できてない？
>>666
本当にこれなのかな。 >>702
stringでもLogInfoでもなんでも好きにしなよ
お前ずっと反論がズレまくってんだよなぁ
ただの例示のコードスニペットの重箱の隅をつついて本質に触れないのは、ワザと話をそらそうとしてんのかな？
業務で書いてるコードじゃねえんだから、細かいとこは省略してエッセンスだけ書くに決まってんだろ
>>703
これでもできるじゃなく、そのほうが楽でわかりやすい、な
DIなどでおなじみの大量生産される型定義、プライベート変数定義、コンストラクタ定義が消えてスッキリ
コードの可読性を著しく下げる予測困難なコード≒隠蔽されたコード、長いスコープ変数(メンバ変数)などが消えてスッキリ
前にも書いたが、テストしやすくてスッキリ
>>704
いや真面目に、俺が意味不明ってつけたレスは、本当に意味不明だよ
頼むから、わかる日本語で書いてくれ
ちなみに俺も昔は、OOP信者でもちろんインターフェースも大好きだった
デザインパターンを1つ学んでは、一喜一憂してたのもいい思い出だ
ま、知識をアップデートしようってことだな >>705
あのさあ。ホントにズレまくってるのそっちなのよ。
逸らそうとしてるんじゃなくて、業務で使うようなコードで、イニシャライザに任意の関数を渡すスタイル「のみ」でうまく行ったパターンは無いし、どのみちその関数のシグニチャは定義することになるんよ。
Kestrelでセルフホストする時に、どちらの方法も使うことになるけど、インターフェイスを受ける、具象クラスを返すラムダで初期化したりするよね。
GenericHostBuilderExtensions.ConfigureWebHostDefaults(IHostBuilder, Action<IWebHostBuilder>
とかもそうじゃない？
スッキリはしないよ。はっきり言って。
知識はアップデートしてるつもりだが、だからこそ、高階関数で万事解決だとは思ってない。
なんでも高階関数でやればスッキリする、依存を減らそう、呼んでほしいロジックは渡せば良いんだ、って発想は一時期かぶれたけど、
結局、相互に依存してるのと変わらんことに気づいた。
別にそれ自体がテスタブルでもなんでもない。
結果的にテスタブルになっただけであって、同じように気をつけてInterface使えばどちらもテスタブルになる。 >>706
既存のフレームワークはまだ追いついてないんだよ
中心的なフレームワークをOOPでインターフェースも使う前提で作っちゃったんだからある程度”使わざるを得ない”のは仕方がない
あとはそこから如何にして脱却していくかだな
依存を排除しようとしてるのに、相互に依存してるんならOOP、関数以前に設計が下手な可能性が高いな
テスタビリティは明らかに関数のほうが上
おぞましいモックオブジェクトの大群に襲われなくて済む
関数ならモックオブジェクトはただのラムダに置き換えられる
テストコードは短く、シンプルに、理解しやすくなり、テストのための黒魔術(モックフレームワーク)への依存関係を完全に断ち切れる
これがいかに素晴らしいことか、業務で真面目にテストを書いたことがあるなら、わかるはずだ
もしわからないなら、本気でテスト書いたことがない”ニワカ”でしょ >>708
追いついてないわけではなくて、現実見てるんじゃん。
結局、相手方にラムダなり関数なりの自分の一部分を「呼ばせる」仕組みになるのであれば、それは結局は依存してるのと同義だと思うぞ、俺は。見た目上依存が排除できてるようには見えるけど。
モックオブジェクトの作り方が悪いのでは？
結局、短くて大量のラムダに襲われるだけだし。
モックフレームワークとか開発の規模感にあってなかっただけではなかろうか。
別に俺は、完全にラムダを渡すスタイルが悪いと言ってるんじゃないんよ。
インターフェイスは必要な部分では必ず必要って言ってるだけであって。
インターフェイスと拡張メソッドでめちゃくちゃ効率的にできる事もあるし、抽象的に扱う必要があるものはある。
IDbConnectionをどういう関数にするかまだ答え貰ってないけど、どうするつもり？
宗教戦争じみてきたけど、絶対にインターフェイスは要らないって言いたいだけ？ 実を言うとね
関数には様々な利点があるわけだけど、それらの利点がもし全くなかったとしても
この”テストコードの生産性の向上”だけが理由でも、俺は関数に取り組むべきだと考えてる
レガシーコードとはテストのないコードのことだ、とは有名なフレーズだが、心から同意する
テストコード生産性の低いOOPは、レガシーコード予備軍と言ってもいい
モックフレームワークは本当に君たちの良き友人だろうか？
よく考えてみてほしい そもそも論だが、モックフレームワーク自体がまず必須ではない。
インターフェイスを満たしていればそれで良い。
依存性の注入をしはじめるとそりゃモックは作る必要があるかもしれないが、フレームワークを使う必要は無い。
そもそもそれは関数やラムダを渡す方法でも同じ。もちろん関数やラムダのテストはするよね。それが、結局依存してるって言ってるの。注入してるからあたり前よね。
なんか嫌な記憶があるんだろうけど、インターフェイスという概念が完全に使い物にならなかったら、世間はそう変わっていってる。でも、どの言語にもあるよね。型クラスだったり、少しずつ実現方法が変わることはあっても。
自分の使い方が悪いのを、ものが悪いと言うのはよろしくないぞ。 >>709
短くて大量のモックラムダの定義は常にテストと共にあり、全てが目に見えて、嘘も隠し事もなく、理解容易だ
モックオブジェクトの大群は全てが隠蔽されており、その実体はお世辞にも理解しやすいとは言えない黒魔術で構成されている
モックオブジェクトを扱う人間はモックオブジェクト独特の世界観を深く理解し、信仰しなければならない
僕らはただ楽に単純明快なテストを書きたいだけなのに… >>712
自分で作れば、モックオブジェクトも別に隠蔽されてないし、理解しづらくも無いんだが。
必要十分なものを作れば良いと思うよ。
なんかフレームワークに振り回された思い出があるの？
それは俺にもあるからわからんでもない。 これ回線2つ使った自演芸やんけ
せめて文体変えようよ・・・ >>711
何故モックフレームワークのような出来損ないが、世の人々にありがたがられているか理解してる？
モックフレームワークを使わなければいいと、言うだけなら簡単だよ
でもねその代償に今度は、大量のモッククラスを書かなければならなくなるんだ
世の人々はそんな大量のモッククラスを書くのは嫌だ、ということでモックフレームワークを作ったんだ
苦肉の策だったんだろうけど、世の人々は薄々疑問を感じながらも自分を納得させてモックフレームワークを受け入れた
大量のクラスを書くよりは、たぶんマシだから
さてなんでこうなってしまったか、根本原因はもうわかるね？
依存性分離のためにインターフェースを採用しちゃったからだよ
インターフェースに実装を与えるのは、関数と比べるとものすごい労力かかるんだね ID:9VBk1Szv0
ID:/WM42vypM
いい加減議論スレへ行け
ふらっと C#,C♯,C＃（議論用） [無断転載禁止]©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1469538912/ >>714
違うぞ。
>>715
やり方が悪い。そして関数のシグニチャはインターフェイスそのもの。
>>716
すまん、そんなスレあったのな。
ありがとう。
まあ水掛け論だろうし、もうやめとくわ。 >>713
僕らはテストを書きたいんだ
大量のモッククラスを書きたいわけでもない
モックフレームワークを自作したいわけでもない
モックフレームワークを利用して疲弊したいわけでもない
僕らはただたんにテストを書きたいんだ ま、インターフェースなんかいらんな
データベースが当たり前になってきた頃からインターフェースを積極的に使うやつは確実に減ってきた
だってこれやっぱテーブルにしにくいじゃん
いやね
差分だけ本当にまとまってるならそういう手もありなんだけど
実際は虫食い状態の共通部と固有部分を分けるのって現実的じゃないと思うんだよね 属性のメリットが全然わからなくてとまどってる
obsoleteなど例外を除いて、summaryなどと違って参照時に開発者側へメッセージを呼び出すわけじゃないんだな
obsoleteのような開発時のエラーメッセージの表示を条件分岐したかったけど見当たらないし、obsolete自体が継承できないときた
メソッドの代わりとして使うしかないのか？ >>720
組み込み属性以外だと、リフレクションでメソッドなりクラスなりを探すときに、特定のAttributeがついてるものを対象にしたり、呼び出し元に特定のAttributeがついてるかをコールスタックから探したりするためのものでは？
あとはAttributeUsageAttributeで制限かけたりかなぁ。 属性は、
EntityFrameworkとかASPNETとか属性利用ありきのライブラリを使ったり自作したりしない限り
特にメリットなんてないという理解でいいと思う
逆に言えばそういうライブラリを使うときに初めて意味を持つんで
ひとまず書き方使い方だけ頭の片隅にいれておけば十分 >>720
属性はメタプログラミングで利用するもの
C#ではダイナミックに型情報にアクセスすることできるが、属性はその型情報に”お好みのラベル”を付与するための機構だ
ただラベルを貼り付けるだけではなんの意味もない
ラベルを解釈して振る舞いを変えるクライアントプログラムを作ることで、初めて属性に意味が生じる
同じ事をあちこちでやってるけど、クラスや関数など従来の言語基盤ではモジュール化しにくいもの
いわゆるアスペクトというものをモジュール化するための道具として使われることが多い
またIDEを初めとする周辺ツールなどからも参照できるためツールの拡張などに使われることも多い
はっきり言って泥臭い、洗練された機構ではないのでメンテナンスは大変だが、ただの利用者の立場では便利なものだ
python、TypeScriptなどでは属性より柔軟性は低いものの十分な効果が得られ、より理解、実装が容易なデコレータというアイデアが導入された(ちなみにこれは関数を受け取り関数を返す関数だ)
C#にもデコレータがあれば良いのだが……まだまだ遅れてるね 同じものってどこかに書いたっけ？
属性とはこういうものだ
他の言語では(アスペクトの実装手段として)より洗練されたデコレータというものがあっていいなあ
という文脈だが？ で、デコレータでどうやって開発時にObsoleteのようにメッセージを出すんだ？
Pythonみたいなデコレータじゃ実行時にしか出せないだろ 俺がいつデコレータで開発時メッセージを出す話をしたのかな？ 質問者は”属性の有用性が理解できない”と聞いてきてる
Obsoleteはその例でしかない
であるので属性の一般的な説明と用途を説明し
その後に参考としてデコレータを紹介した 質問自体が”開発時メッセージを表示させたい、コントロールしたいがどうすればいいか”だったら、デコレータの話はなかっただろう いや質問者はObsoleteのようなことがやりたくて属性を調べたけど結局何ができる機能なのかよく分からなかったと言ってるだろ
この文脈で>>724のように書かれたらデコレータでならやりたいことができると質問者が誤解してもおかしくない
不適切というか意地悪な回答だと思うぞ お前が俺を攻撃したいのはわかったが、もう少し冷静に考えてから攻撃したらどうだ？
毎回、返り討ちにされてはつまらないだろう？ 属性とデコレータは似てるようで全然違うので、同列に扱うのがよくわからん。
TSのreflect-metadataなんかでもわかるように、あれはデコレータで属性を与えるようなものなのよ。
逆にJavaのように属性でデコレータを与えるようなものももちろんある。
javax.decoratorとかな。
属性は属性でデコレータとは本質的に無関係で同列で引き合いに出すものではない。
その言い方してると、Serializableの説明がしにくくなる。 >>733
攻撃したいんじゃなくて、間違ってる。
頭でっかちでしかない。 >>734
2回目だが同じとは誰も言ってないぞ
(アスペクト指向という)目的を達する手段が複数あり、片方がより洗練されていると言ったんだ
なぜこれで”属性とデコレータが同じものだ”になるのか理解し難い >>736
誰もアスペクト指向の話は求めてないし、アスペクト指向にも使えるのは事実だが、アスペクト指向のためだけのものではない。
属性は属性。
Webフレームワークのパンドラとかロガーみたいな、特定のアスペクト指向に使う用途しか知らないならそう言いなよ。 データバリデーションのIndexやRequired、シリアライズのJsonPropertyとかColumnなんかは、別にアスペクト指向として割り込むためのものでも集約するためのものでもない。
XamarinのAndroidのActivityなんかはビルド時にXML産むために定義したり。 >>737
はぁ…何度目だ？
質問者は明にアスペクト指向の話を求めているわけではないが、属性の有用性についてコメントを求めている
で、あるならば属性の利用形態として大きなウェイトを占めるアスペクト指向について、言及しないわけにはいかない
属性は単なるラベルであり、クライアントによって様々な利用形態が考えられることは、俺が先に説明した通り そうか？
C#で属性使ってアスペクト指向ってあまり一般的じゃないだろ
ヘルスバーグがAOP嫌いなのも有名な話だ >>739
属性の有用性はそれ以前の問題。
アスペクト指向に属性は実際問題必須ではない。
インターフェイスは要るがなw
単なるラベルであり様々な利用形態が、ってのは、わかってる相手に説明する方法であって、全く知らない人間に対しては何の説明でもない。せめてググるためのワードを出せよ。 初心者にまったく役に立たない話はここでしなきゃいいのでは？ 別にね、アスペクト指向はルールベースでも良いのよ。
Rubyなんかだと命名でフックしたりするようにね。 >>741
属性はAOPに必須ではないが、ないと非常に大雑把な実装になり、挙動のコントロールが難しくなるため、実用上はほぼ必須だよ
太平洋横断に船は必須ではない、と言うようなものだ、最後の旅にならないといいね
いやいや、何もわかってない人にこそ、属性とはただのラベルでしかない、と説明したほうがいい
ただのラベルということを理解してないと、元の質問者のように属性には開発者メッセージを出力したり、色んなことができる、なにか不思議な力がある魔法の道具なのかな、と誤って認識してしまうんだ
1. 属性には本当にラベル以上の意味は何もないし、何もしない
2. 何かするのは、そのラベルを見て処理をするクライアントプログラム
3. 何をするかは、そのクライアントプログラム次第で全く異なる
これが属性の基本の基本な
このシンプルな3つの事実を教えないで、有耶無耶にはぐらかすと、初心者が属性を理解できなくなってしまう ほぼ必須といったのは誤解を生むかもしれないな
デコレータのようなより洗練された機構が無く、AOPをメタプログラミングで実装する以外の選択肢に乏しい言語にとっては、ほぼ必須と訂正しておこう だから、そんな話はしてないの。AOPとか。
デコレータの話が蛇足な上、その根拠のAOPの話が蛇足だったのよ。
属性はただのラベルではない。
誰かが読み取るためのラベル。
それはシリアライザだったり、コンパイラだったり、Webサーバのランタイムだったり様々だけど。
だから、Obsoleteなんかが意味を成すんであって。
現実的にC#の属性はAOPのためのものではない以上、蛇足そのものでしょ。
だから頭でっかちだと言ってるんだよ。
「ただのラベル」こそ「うやむやにはぐらかしてる」でしょ。 >>746
>属性はただのラベルではない。
>誰かが読み取るためのラベル。
それをただのラベルっていうんだよ
読み取る側がそのラベルを見て何らかの作用を起こすまではなにもしない
まさにただのラベルだな お前の理想以外聞き入れないなら、ブーメランでもなんでもないわ。 >>723
ビルド時にカスタムのエラーや警告を出したいなら
Code Analyzer使って属性をチェックすればいい 昨日は頭のおかしい人が大活躍してたみたいだな
策っとNGしときましょう WebClient使ってWebサイトのhtmlを文字列として取得したいんですが、
読み込みに数十秒かかるような重いページだと、途中でエラーします。
そんなページでもエラー無く読み取る方法有りますか？ >>757
HttpClientクラス使った方が良いと思うけど
WebClientクラスの場合は、GetWebRequest()をオーバライドして
WebRequest.TimeoutプロパティとHttpWebRequest.ReadWriteTimeoutプロパティを設定 >>760
ありがとうございます。
>GetWebRequest()をオーバライド
は既に試したんですが、相変わらずエラーで中断します。
>HttpClientクラス使った方が良いと思うけど
それは何故でしょうか？ DLしたいサイトのURL教えてもらっただけでだいぶはかどるよね。 デフォルトだとタイムアウトが足りてないだけなんじゃないの? > 途中でエラーします。
エラーしますとか変な日本語使う奴の相手はしない >>764
ふたばってもう誰も見てないだろうけどどんな理由で攻撃してくるの？ #region って使わない方が良いのですか？
プライベートメソッドがたくさんあるとき隠すのは駄目ですか？ 好きにしたらいいよ
長いコードをリージョンで隠すより
短く書いたほうがいいと思うがね ウザい
使うメソッドの周辺に置いておいてよ
publicとかprivateでリージョン切るやついるけどセンスの欠片もないな レガシーコード解読してるときに、コメントがてら一先ずregion使った #region使わんといけないほどになったらクラス分けてほしいな
実際にはなかなかそういう自由はないかもしれないけど 分ける方向がクソなときにウザい
１つのpublicにいくつかのprivateがくっついてるのに
publicやprivateでリージョン切るなや下手クソ >>780
身もふたもないけど使い方次第だね。
#regionディレクティブはコードを分類するのとあまり見る必要がないコードを隠すのに
使えるけど、後者の使い方はあまり必要がない
自分はデカいクラスでMSのドキュメントみたいにメンバーを種類ごとに分類するのに使ったり、
ある程度以上の規模のFormで例えばメニューのイベントハンドラを分類するのに使ってる private隠す#regionは使うけどな。どのへんがダメ？ 隠したくなるということは、隠さないと鬱陶しいぐらい長いコード、ということだから、そのあたりだろうね 呼び出し階層を無視して十把一絡げに「private」だけで括ろうとするのはどうかなとは思う コードスメル的な意味かな？具体的に何が悪いのかよくわからんけど。 /// <summary>
/// ・・・
/// </summary>
private int mHoge;
/// <summary>
/// ・・・
/// </summary>
public int Hoge { get => 0 == this.mHoge ? 1 : this.mHoge; }
で、それぞれに同じコメント書くのが非常にだるい。
なにかうまい方法ないですか？ >>794
ぉぉ、コメントも継承できるんですね。
ありがとうございます、やってみます。 >>789
privateの意味を誤解してる気が
privateの意味はそのコードを利用する側の人は見る必要がないって意味だよね？
ソースコードを見てる人はその時点で「利用する側」か？
普通は違うよね？書く側の人に対して隠す意味は普通はない。
もちろん「まず見る必要がないから畳んでおきたい」需要が絶対にないとまでは言い切れんとは思うけど。 ちなみに、VSのエディタにはメソッドのシグネチャ以外の部分を畳む機能もあるけど俺はあれは嫌い。
ただの食わず嫌いかもしれないが >>797
あー、それそれ。併用してCのヘッダみたいにして見てる。
ヘッダ代わりに毎回インターフェースを定義するのも面倒だしね。 長大なメソッドの中身をregion使って折りたたんだら短く見えるからいいよね コンストラクタとかで引数チェックする場合ってDebug.Asset使う？ ifと組み合わせて例外投げる？ macOSに新しい.NET Core SDK/ .Net 5 SDKを入れ続けていると、何バージョン分もディレクトリが掘られて増えていきます
公式では、いらないものを単純にディレクトリごと削除して良いようなことが指示されていますが、これらのディレクトリのパスをdotnetコマンドに知らせている設定部分はどこにあるのですか？ ありがとうございますm(_ _)m
#region は気を付けます >>800
コンストラクタで例外投げたくないな
引数はフィールドにセットするだけでそれ以外は基本しない
検証するなら別のメソッドにするかコンストラクタ隠蔽して検証しつつインスタンス返すstaticなメソッド作る >>800
普通にifで調べて、普通に例外を投げてくれ
引数がおかしいならArgumentExceptionとか適当なのあるでしょ
引数が増えるとifを書くのがしんどくなるかもしれないが、そのときは関数化しよう
そもそもDebug.Assertは滅多に使わないものと考えていい
デバッグビルドとリリースビルドで挙動が違うというのは、それだけで本番でしか発生しないバグを生みかねないものなので、可能な限り避けるべきだ
コンストラクタで例外を投げたくないとか言ってる人は、気にしなくていい
昔はそういう流派もあったんだな、とでも考えてくれ .net frameworkのコンストラクタでもそうやってた
今のは知らん コンストラクタで例外投げろ
それ以外はゆるさない
XXX.Create("test");の戻り値nullチェックみたいのはバグの温床だから許さん UnhandledExceptionの処理やるだろうしコンストラクタで例外投げてもいいと思うけどね 9.0のrecordってデータベースとのやり取りに使うシンプルなクラスには積極的に使っていったほうがええんかね？ 単純計算の時間って完全に比例するんですか？
繰り返し処理で
10万回 2桁同士の掛け算を行う。
12万回 2桁同士の掛け算を行う。
これって後者のほうが平均とると必ず時間がかかるんですか？ コンストラクタで例外投げるかどうかは宗教論争感あると思うので棚上げにしてます。質問が悪かったです
自分が聞きたいことはDebugあるいはTraceのAssertメソッドの使い所でした
>>806
使い所ないんですかね
どんな値が渡されるのかわからない関数などは例外処理、その逆（外部に公開しない関数）の値チェックになら使えそうなのかなと思ったんですが
.Net1.1やその前からあるみたいなので、テストフレームワークが流通してないころに使われてた過去の遺産なのかな >>812
汎用PCの場合
速度なんか測ったって
その場合はそうだったんだろとしか言いようがない
裏でウィルスバスターや
セキュリティソフトや
会社の監視ソフト
WindowsUpdateなど
色んな複合要素がありすぎてみんな速度なんか測るのやめちまったよ >>813
検証処理が非常に高価な場合はDebug.Assertを使う理由にならんこともないが、そんなことは滅多にないよ
ほとんどの場合、検証は安価であり本番で検証をスルーしてしまうリスクとは比べるまでもない
C言語のようにほんの些細なオーバーヘッドすら嫌うような言語とは考え方が違う そもそもアサーションをいつの段階で期待してんだ
まさか実運用環境をデバッグビルドで走らせるのか
コンストラクタでの例外は、やるなっていう言語が存在するのは確かだが、宗教以前に言語の問題
C#では別に問題なかったはず Debug.Assert()はバグってる原因を探る時に、想定通りの値になっているかを確認する時に使うな
確認が終わったらソースから消すけど、万が一消し忘れても影響無いし
Trace.Assert()は使ったことない 803だけど昔「コンストラクタで例外投げたりアカンぞ」みたいなことを本で読んだ記憶があったんだがいま読み返したら完全に自分の記憶違いだった 申し訳ない 職場でExcelVBAとACCESSをある程度動かせるようになったので、ステップアップしてC#を勉強してみたい。
勉強用のサイトやオススメの本などあったら、教えて頂けませんか？ 2D格闘ゲームって3Dのapiがなくても作成可能ですか？
何か昔っぽいゲームを作りたくなってワクワクしてます。
環境はvisualstudioです。 誰か助けて。WebView2を使ったプログラムなんだけど
以前動くやつを作ったプロジェクトを今日久しぶりに触ったら
「System.NullReferenceException: 'オブジェクト参照がオブジェクト インスタンスに設定されていません。'」
と出てまったく動かなくなってしまってた… 一行も弄ってないのに
本当に何にも触ってないんだけど一体何が悪いのか。 >>820
速度イラネってなら別だが、2Dでも細かい事やろうとするとC#の手に余る
せめて描画エンジンはC/C++で書いた方がいい 原因が分かった。プロジェクトのディレクトリを移動すると動かなくなるみたい。
でも何故なの？どこを修正したら良くなるか誰かおしえて！ >>823
WebView2ランタイムが見つからないんだとエスパーすると、
ソース内でWebView2ランタイムの場所指定してるとこ要チェック。 >>819
c#でググるとすぐ出てくる入門サイト。
何故かというと、今後も何か調べるときにすぐ出てくるサイトだから。 >>819
ネットで漁る
独習C#
実戦で役立つ C#プログラミングのイディオム/定石&パターン いやコンストラクタで例外投げるな、投げたい時にはファクトリーメソッドを使え、
という議論は確かに見たことある。
自分はコンストラクタで例外投げたいと思ったことがないので興味が持てず
詳細はよく覚えてないけど、それなりに説得力はあったような気がしたけどな 自分の知らんところでコンストラクタ使われたら例外拾えないとかそんな腐った理由だろう
何があってもインスタンスが帰って来る状態が欲しいんだろうがその後処理を誤ると簡単に詰む
そんな甘いことを言ってるとバグ作るだけ コンストラクタで例外投げるとオブジェクトが中途半端に作成されたものがゴミとして残るからだよ ・コンストラクタで例外おきるとデストラクタが呼ばれない説
⇒確認できた
・デストラクタが呼ばれないのでGCされずにメモリリークが起きる説
⇒確認できず。list.add(new Hoge())を1000回で、Hogeコンストラクタ内で例外起こすかどうかで確認。
例外起こさなければ使用メモリ増えるけど、例外ありの方は増えない。やり方が悪い？
メモリリーク云々はC++とかの話が元みたいで、それも例外投げるなではなく投げる場合は適切に参照を削除してから投げろみたいな話だったと思うのだが、
c#の方は問題ないのか？
標準ライブラリにもコンストラクタで例外返すやつあるのでそれの実装が見たい 残って気持ち悪いとしたらDispose持ちのネイティブリソースだろうけど
そのへんクリーン書こうとしたらファクトリメソッドでもやること変わらんでしょ 古いガイドラインだけど
＞✔ 必要な場合は、インスタンス コンストラクターから例外をスローします。
だからダメってことはないんだよね
コンストラクターのデザイン - Framework Design Guidelines | Microsoft Docs
https://docs.microsoft.com/ja-jp/dotnet/standard/design-guidelines/constructor ちょっと大きめのメモリ割り当てたら1回の例外発生時にGC呼び出されてるのも確認できた >>813
> どんな値が渡されるのかわからない関数などは例外処理、その逆（外部に公開しない関数）の値チェックになら使えそうなのかなと思ったんですが
ざっくりその認識で正しいよ
内部的にはあり得ない状態ならAssert投げる
デバッグ終えたら削除とかアホのやること
注意すべきなのはassertの条件の所に副作用を含む式を書いちゃいけないことぐらい そもそもなんでもかんでもエラー処理を例外任せにするのが間違ってるような C#ではコンストラクタで例外が出るとファイナライザが呼ばれないことから
コンストラクタでは例外を出すべきでないとする派閥が昔は存在した
しかしこれが問題になるのはコンストラクタでアンマネージドリソースを確保してDisposeで解放するパターンを採用したクラスだけだ
ネイティブライブラリをPInvokeで呼び出すような低レベルの仕事では気を付ける必要があるが
そうでなければ気にしなくてよい
またそのようなアンマネージドリソースを扱う場合でもC#ではSafeHandleを実装して使うことになっている
SafeHandleを使う側はリークをことさら恐れる必要はない
コンストラクタで例外を投げてもよろしい >>833
例外投げるなら、その前に既にnewしたものを全部綺麗にDisposeしなきゃいけないわけだけど
そこまで考慮して正しく実装されたコンストラクタなんてドカタのコードで見たことないな
自分でthrowしなくても呼び出し先から例外が飛んでくるケースもあるから、本来は常に考慮が必要
あくまで可能性の問題としてだけど、コンストラクタで例外を投げるとDispose漏れが起こりやすいのは事実だと思うよ
漏れを完全に防げなくても、GC任せで問題にならない程度に頻度を抑えることはできる >>836-837
ちょっと何いってるのかわからないw
>>838
なるほどね。
コンストラクタで例外投げてもほとんどの場合
問題がないことはよくわかったけど、
それでも個人的にはやっぱり避けるかな。
コンストラクタで例外が飛んでくることを想定してないプログラマが多い気がするから。
あえて違和感を感じさせるためにファクトリーにすると思う。
まあ屁のツッパリ程度の効果しかない気もするが。 >>836
プログラマが内部的にありえないと考えている状態が実際に発生するかしないかはプログラマにはわからない
それがバグというものの性質だ
バグはプログラマの意識の外からやってくる
プログラマが間違えるからバグが発生する
なので絶対に起こらないから本番では外しちゃえなどと安易に考えずに
俺の考えではまあまず起こらないと思うけどもし起こったらやばいから念の為に残しておこうと考えたほうがよい >>838
.NET 5以降ではCERが廃止されたからSafeHandleは意味ないよ ちなみに.NET Framework(非Core系)でもCriticalFinalizerObjectに意味があるのは複数のAppDomainを使ったアプリケーションの場合だけだよ
あまり理解されてないけど、99.9%の人には無関係な極めてニッチな機能 また空中戦やってるな
設計はどうなってるのか？もこだわらず
どう処理したいかばっかり
客がエラー扱いにしたいって言ったら
テメーの例外のこだわりなんかゴミ箱だ
逆もまた然り いや客ってのがユーザーのことなら例外処理なんて客と無関係な純粋に技術的な問題でしょw
多重下請けならその限りではないかもしれんが >>842
SafeHandleはCERのためのものではなく
アンマネージドリソースハンドルのラッパーを提供するための共通基盤でありCER対応はその部分でしかない
SafeHandleは依然として有用だよ
初心者は参考にするといい
https://docs.microsoft.com/ja-jp/dotnet/standard/garbage-collection/implementing-dispose もちろんオレオレハンドルラッパーをDIYしたいならそれを止める権利は俺にはない
しかし趣味ならともかく仕事ではDIYを避けたほうがいいだろうねとアドバイスだけはさせてもらおう >>846
それは眉唾だな
docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.safehandle?view=net-5.0
例えばこのサンプル、SafeHandle派生クラスを実装した上で更にそれを適切に解放するために普通にDisposeパターンを実装してる。
これが典型的な正しいSafeHandleの使い方だ。
CERが無いなら手間とミスしうるポイントが余計に増えるだけにしか俺には思えないね。 newしたものが綺麗にdisposeされないって馬鹿のコードだろ
そもそもが引数チェックではじいてからnewするだろ馬鹿じゃないかと .netの内部でもこんな感じで普通にコンストラクタで例外投げてる
これ以外でどうやって通知すんだよ
馬鹿者が
if (path == null)
throw new ArgumentNullException("path", Environment.GetResourceString("ArgumentNull_Path"));
if (path.Length == 0)
throw new ArgumentException(Environment.GetResourceString("Argument_EmptyPath")); >>851
ArgumentExceptionは開発時のバグであり、ソースの修正が必要だ
そのまま実行を継続すべきものではないから、リソースの開放漏れ云々は全く関係ない コンストラクタで例外は投げても良い
でもおかしなことをする奴がいるからコンストラクタでは例外投げるなは暴論 >>849
プラットフォーム呼び出し時の参照カウントなどはどうする? クラスとかメソッドとか分けるときの命名が大変で時間が掛かるお…
適当にそれっぽい英単語繋げてるけど、メソッド名が50文字以上になることがよくあるお…
ForとかByとかFromとかも使うとより長くなるんだお…
どうしたらいいんだお？ >>857
俺は命名には
https://codic.jp/engine
使ってる
文字数減らすためじゃなくて、英語力不足を補うためだけどｗ
50文字超えることはあんまりないかなぁ。 >>800
自分は投げますね
MSが作ったデフォのクラスにも投げてるやつあったと思うのでそれを言い訳にしてます 引数エラー一個一個出してくわけには行かない場合例外だと処理しにくいな コメント打つ代わりにフルスペルで命名するっていう手もあるよね。
そうすれば入力する手間は変わらない。
でも英語が見慣れてなくて辛い。 命名に悩んで手が止まるのアホらしいので、一旦日本語で命名して後で英語に変えてる 下手に英語やローマ字使うより日本のプロパティ名を使った方が分かり易いこともありますな
敢えて外人だけに意味を理解しにくくさせたいときなんかにも使えそうですな >>866
どんな場面を想定しているのか、すげぇ気になる enumの要素が日本語だとコメント要らずではある
本体がアルファベットならインテリセンスも問題ない 国民健康保険保険者番号、という単語を変数名にするときは、だいぶ議論した上で、
kokuho_hnoになったな。
national_health_insurance_insurer_numberはとても反発が大きかった。 英語力がボトルネックになってるケースはむしろ少ない気がするね。
命名下手な人は日本語でも意味不明な名前付けそうな気がする
というより、だいたい命名以前の問題で既に失敗してるんだよね
普通のプログラマはそれが何をするメソッドなのか、「何者」なのかを
明確にしてからメソッドを書き始める。
命名で止まっちゃう人はそこがいい加減なんだよね。抽象化が出来てない。 >>841
良い心掛けをお持ちですね
大事になすってください >>869
プロジェクト全体で使えるならnhi_insurer_numberみたいな略語ならありだと思うけどね グロサリーは作った方がいいけどNHIで辞書に載ってるから（普通何だこれと思ったらググるよね？）
それはNhiIDでいいでしょ 俺も別に良いと思ったんだけど、とにかく反発がやばかった。
HNI_Insurer_No推しだった。
俺的には番号とついてるものにIDはまずい気がする。 kokuho_hnoだと保険者番号と被保険者番号の区別がつけにくいので
nhi_insurer_numberとnhi_numberくらいがいい気がする
kokuho_insurer_numberでも別にいいかな 変数名は単体で使ってるのか？
それともPersonクラスなどののメンバーなのかによって扱いが違う >>877
被保険者番号はhhnoという悲しいスタイルに。。 >>876
識別のために割り当てる符号は数字だろうがギリシャ文字だろうがID(identifier)でしょうw
ただ、保険者（業者）と被保険者を区別する必要があることに気づかなかった
この場合NhiIDはまずいね
まあスレ違い甚だしいな hhnoかぁ
nhiもそうだけどhhnoやhnoみたいな普段の会話で使わない略語よりも
kokuho_hokensha_noとkokuho_hihokensha_noみたいに
普段の会話で使う日本語読みに寄せたほうが何かと良さそうだね 被保険者番号みたいなのは
コーディング規約をいじる裁量があれば日本語変数名が最強なんだよなあ
入力はちょっと大変だけど、視認性最強でドキュメントコメント不要になるし
英字表記に悩んだり表記ゆれに煩わされることもない、変な英略語覚えるのに頭使わなくて済む 基底クラスでenumのステータス持ってて
継承してそのステータスの種類が増えるとき
enumが継承できないとステータスの種類が増やせなくない？ >>885
enumは決まった値しか取り得ない型
継承して取りうる値が増えたら、それは基底クラスにおける「決まった値のみを取る」という規約を破ってしまうことになる
規約を破らずに値を追加するには、継承せず普通にenumに追加しなければならない >>886
したらステータス値はどうやって持つべきだと思ってる？
ここでenumが使えないと言うなら一体どこで使えと言うの？
まあ、const intで頑張ってるけど >>871
出来ぬ、出来ぬのだ
俺も出来たら便利だよなーと思ったけどダメだった 率直に言ってenumを継承するって発想自体が理解不能w
>>885
enum Eを継承してFを作れるとして、Eの型のプロパティHogeを持つクラスAを継承してBを作っても、
Hogeの型をFに変えることはできないよね？
スーパークラスでステート値を増やすって発想に無理がある気がする >>889
継承してステータスの取りうる状態が増えるときはどーするの？
ステータスはenum使えってみんなが言うから使ったらこのザマだよ
所詮、プログラムなんか組んだことないアホの戯言だった
継承して増える可能性のある値はenumなんか使っちゃ駄目だってことだね
俺は一生使わないと思う >>890
まずそういうケースがあんまりありそうもない気がするけどあるとして、
(1) ベースクラスを書く段階でサブクラスでありうる拡張を織り込んで予約しておく
(2) それが無理なら
enum BorderStyle {None, Single, Double, ExtendedStyle };
みたいにしておいて、BorderStyle == BorderStyle.ExtendedStyle
の時には別のプロパティでスタイルが決まるようにする > Console.WriteLine("Hello, {0}! Today is {1}, it's {2:HH:mm} now.", name, date.DayOfWeek, date);
> Console.WriteLine($"Hello, {name}! Today is {date.DayOfWeek}, it's {date:HH:mm} now.")
上の書き方の場合、文字列部分を定数で宣言できたってメリットあったと思うんだけど、$使う文字列挿入だとできないよね
使い分ければ良いだけだと思うんだけど、他に冴えたやり方あったりする？ class作ってメンバでconst intにしようと思ったら
採番が面倒だから結局intになったわ
と思ったらそれもログ出力が面倒で
結局、状態クラス作ったわ enumは基本的に定数をならべただけだから不変のものにしか使っちゃだめ
ステータスを表すクラス作れよ >>894
不変よ
少なくともプログラムが実行されてからは
だって状態を表してるんだから
変更が必要になるのは継承で分岐するソースコードの修正作業時だけ
こういう形でenumが使えないなら
今後継承を行う可能性が少しでもあるならそのクラスではenumは一切使えないということ
実際使わないほうがいいと思う
赤青ランプを継承して
赤青黃ランプを作ったときに
状態赤青がenumで作られてたらゴミ箱にブチ込むしか道はない 挿入文字列はコンパイル時に解析される（実行時に解析されるわけじゃない）と思うので（知らんけど）
stringの変数に挿入文字列自体を入れるとかできないと思うけど、そもそも何でそんなことがしたいの？
多言語化のために文字列リソースにしておきたいという動機なら理解できるけど
変数に入れたい動機が思いつかない >>895
enumの定義をclassの外に出して独立させれば >>898
赤青黄と赤青緑に継承で分岐したとき
どんなenum定義するって言ってる？ >>900
派生元も派生先も関係なく1つのenumで定義すればって意味で書いた
使う時はプロパティやメソッドでそのクラスで利用可能な値かをチェック だからそもそも根本的に考え方がおかしいと思うよw
集合論的に考えてみて
例えば、
自然数⊂整数
ってことは明らかに「整数 is 自然数」ではないでしょ。
自然数を継承して整数を作る、とう発想がそもそもおかしい。 >>895
赤青ランプを継承して赤青黄ランプを作るってのがそもそも筋が悪いだろう
N色ランプを作って赤青でも虹色でも好きに作ればいい は？設計書にそう書いてあって
矛盾なく動くのに何がおかしいんだよ
頭いかれてんのか
いいからこの場合どういうenumになるのかさっさと書けよクズ 普通そう言う場合enum使わんしょ
継承後色がどうなるか確定的じゃないし
stateを普通にintで管理して、それにRGB入りの配列で色を割り当てたら？ >>905
それだとプログラムの拡張の際に取りうる値が増える（実行時ではない。ソース修正時）可能性がある項目は全部enum使えないじゃん
まあ、実際使えないけど >>904
実装上の都合で赤青ランプに後付けで黄色を取り付けたのだから、色を表す定数として赤青のenumとは別に黄色の定数を定義することになるのは自然だろう。
それをあたかも三色同格のランプだと見せかけてるんだから、定数についても見かけ上同列に扱うためのenumを新たに定義しなければならないのは仕方ない。設計がいびつなのだから、内部処理的にもいびつになる。 >>907
何言ってるかわかってる？
基底に20個ぐらいステータスあってさらに増え続けてるとき
継承した分だけenumに同じステータスを追加しまくれっていってんだよ
継承10も20もやったら大変だぞ
もう実際はハードごと20種類以上追加しないといけなくてやってられないから
俺はenumはゴミと切り捨てたけどね >>908
だから追加できたところでそのステータスを何に使うんだよ
増やしたところで基底型では扱えない未知の値なんだから継承の意味がないだろ >>909
は？
お前、状態遷移組んだこと無さそうだからいいやｗ >>908
まだ言っとるんだねw
だから根本的に考え方が間違ってるんだってw
特化/汎化って言い方をすると思うけど、継承っていうのは
汎用的なものを特定用途に「特化」するものなんだってw
だから>>902に書いた通り汎用性が小さい自然数を継承して整数にする、って考えは根本的におかしいし、
汎用性が小さい2ステートを継承して3ステートの物にするというのも間違ってる
考え方が逆だ。
多ステートの特殊形が3ステートで、3ステートの特殊形が赤青黄でしょ。
赤青のロジックの一部を赤青黄で使いまわしたいなら継承以外の方法で考えましょう。
例えば、RGB.RをRB.Rに変換する変換関数は書けるんだから、
Color ToColor(RGB rgb){ ... }
というメソッドは、中で
Color ToColor{RB rb){ ...}
と使いまわすことはできる >>912
赤青黄はあくまで例であって実際にはハードの差分管理してんだよ
だから全部定義し直したらものすごい量になっちゃうの はっきり言うけど
べき論は結構だけど
enum型がこの仕様のままなら
なんにも使えない
もしくは使わないほうがいいと思う俺は じゃあ、いっそenumって定義をやめよう
state型が必要です
これでおｋ？
おそらくこれができたら
enumなんか誰も使わない
それだけの話 >>895
不変っていうのは、実行時に変わらないって意味じゃないぞ
修正／機能追加でも変わらないってことだ
結論としては自分で書いてる通り
>今後継承を行う可能性が少しでもあるならそのクラスではenumは一切使えない
だよ。Enum継承したいってことはつまり変更したいってことだから
Color.RedやColor.BlueはEnumじゃないだろ
まあSystem.Drawing.Colorは構造体で継承できなかった気がするけど
そんな感じで作っとけ >>915
話が通じない人だなw
問題はenumにあるんじゃない。
>>902にはどこにもenumなんか出てきてないでしょw
汎化するのに継承を使うのがおかしい。
継承は特化するのに使うんだってw どれの話をしてるのかわからんけど困ったことない
Enumでやる
virtual List<enum> Lamps => 赤、青を返す
override List<enum> Lamps => base.Lampsと黄を返す
Flagでやる
virtual Color Lamp => Color.赤 | Color.青
override Color Lamp => base.Lamp | Color.黄
Flag側で継承
[flag]
enum Color{
赤=1,
青=2,
黄=4,
Hoge=赤 | 青,
Hoge2=Hoge | 黄
} >>917
そんなの未来永劫保証できないじゃん
enum作った人本当にバカなんだね
使えないもん作ってろよって感じ >>921
別に俺が作ってる訳じゃないからそんなこと言われても知らんがな
enumでやりたくないならそれでいいと思うし好きにやりなよ >>919
enumの利点はコンパイル時に名前の集合を型として定義できる、
名前の集合が確定していて、だからインテリセンスが使えたり
集合に含まれないはずの名前が使われている間違いをコンパイル時に検出できることなので
それは代用にならんでしょ。
質問している人の問題はたぶん継承に固執してること。
部分集合を再利用して上位集合を定義したいって問題意識は分からんでもないけど、
emumなんてただの名前の集合なんだからそういう場合はコピペ継承するのが多分正解。 C#や諸々の言語はそもそも、継承の仕様が出来損ないなんだよね
Java 16みたいにSealed Classを定義できるなら、まだしもねぇ
どんなクラスでも継承できます、なんて言われてもね
全てのサブクラスの面倒を見るなんて、事実上不可能だろ
だからサブクラスを限定する仕組みが必要なのだが…
C#はまだまだ、遅れてるね >>923
ああ、そういう事ね
Nullとか空とかのEnumを用意しとくべきかみたいな話と似てるな >>925
Javaのことは知らんけど
C#のsealed classでは駄目なの 自分ならカスタム属性と拡張メソッド作って、集合.Hoge.Colors()で一覧を取れるようにするかな
まあケースバイケース
enum 集合{
[AddColor(Color.赤, Color.青)]
Hoge,
[InheriteColor(集合.Hoge)]
[AddColor(Color.黄)]
Hoge2
} >>927
そっちじゃなくて継承できる型を限定する機能だね
ShapeインターフェイスをRectangleクラスとCircleクラスのみ実装可能にする
他の奴がTriangleクラスを作ってShapeを実装するのは認めない >>929
なるほどC#に限定する機能はないね
コンストラクタのアクセス権をinternalにしてアセンブリを分ければ実用上はそんなに困らなそうだけど >>919
>override List<enum> Lamps => base.Lampsと黄を返す
これはEnumでやってるんじゃなくListでやってるだけのような・・
取りうる状態の範囲をEnumで表現してないしコンパイル時のチェックも無理だよね
>override Color Lamp => base.Lamp | Color.黄
こっちも型としてはColorになるので既存のColor定義が赤と青だけなら
全く別のEnumを新しく定義することか、既存の定義自体を変更して黄を足すかになるので
既存のコードを維持したまま新しいコードを追加することはできないよね？
Enumを使うべきユースケースじゃないからできなくて当たり前なんだけどさ >>896
文字列の雛形をDBに持たせて、パラメータ部分を置換して出力するみたいなことやってたのよ
『置換して出力』部分を$使う挿入文字列で置き換えられたらいいなって夢想した
pythonの似たような機能でキーワード引数による指定が出来るから、似たようなこと出来ないかなって
> print('{first} and {second}'.format(first=a, second=b))
string.format使えばいいだけなんだけどね >>932のやりたいことが挿入文字列を共通化したいってことならおとなしくメソッド化して
string ToHelloText(string name, DateTime date) => $"Hello, {name}! Today is {date.DayOfWeek}, it's {date:HH:mm} now.";
で
Console.WriteLine(ToHelloText(name, date));
みたいな使い方するほうがいいんじゃ プラごみを減らすためにレジ袋有料化するって話と似てるな
そもそもピントがずれてるし前提も可笑しい リソースで他言語対応すると考えると欲しい気持ちは分かる
"Hello, I'm {givenName} {surname}."
"こんにちは、私は {surname}{givenName} です。"
みたいに書きたい All your base are belong to us evalをやりたいと言うことだな
テスト不可になるからいらんけど c#ってvisual studioインストールしたときに入ってるコンパイラじゃなくて
.Net 5に移行するのが良いでしょうか？
Microsoftも.Net 5移行を推進していきますかね？ なんで今更感が半端ない
アンダースコアつけて怒られた記憶あるわ 今まで記載がずっとなくて、同じMicrosoftの子会社が出してるStylecopっていうコード解析ツールの言ってることなら正しいだろうって風潮だったんだけど逆転敗訴した感じ 前までただのキャメルだったよな？ 何かしっくりこないなあと思いつつあわせてたのに
というか>>942はちゃんとprivateのメンバ変数って書いてくれ 俺は今まで通り m_ + PascalCase でいく キャメルケースの事をキャメルって略すのはどうも抵抗がある スコープで付けると便利だけどね
gグローバルgUnko
mメンバmUnko
in引数入力inUnko
out引数出力outUnko
valローカルvalUnko >>942
さすがにアホなガイドラインでほとんど同意は得られない気がする。
バッキングフィールド限定なら少なくとも俺は賛成するけど。
まあ、普通のフィルドもバッキングフィールドも出番減ってるから
どうでもいいと言えばどうでもいいかも アンダースコアはライブラリと被った記憶
C言語時代だが ぶっちゃけ客先のカスタマイズできない環境で文字ちっちゃくて見にくいときあるからイラネ しかし、_でプリフィクスしとくとインテリセンスでフィールドが一覧できて便利だよ、
ってコメントは泣けてくるねw
普通逆じゃないかw
インテリセンスの候補に登場して欲しくない奴を_でプリフィクスするのが普通のセンスだと思うけど。 >>953
そのコメントどこに書いてある？
ところで別の話なんだけど、
とあるデータの集計や加工をメソッドチェーンで書きたい考えと、その集計や加工をデータとは別のクラスかつステートレスで書きたい考えって両立できるのかな？
拡張メソッド使うくらい？ >>954
コンテナ(データ).加工(…).集計(…)
インスタンスメソッドは暗黙的にthisを使ってるのでステートレスじゃないってことなら拡張メソッドも同じじゃない？ オセロのプログラム作っています。
オセロが盤面にの上にくると影を描きたいのですが
これはフォームアプリでできますか？ >>946
publicなメンバ変数って一般的か？ >>956
半透明の影を書き込んだ画像と影なしの画像の2種類を用意しといて切り替えたらいい
それ以上を求めるならFormsなんか捨ててちゃんとゲーム作りとしてUnityとかに再入門した方がいいよ >>956
あくまでもWinFormでやるならGDI+っていう機能を調べて、
円をキャンバスに描けばオセロ程度のアプリケーションを作るのは楽かもね。
そりゃあ本気でｹﾞｰﾑ作るならUnityだろうけど、
オセロの内容にこだわるなら、コンソールで十分なんだけど。 >>946
いや、そもそもそんなコーディングガイドラインは存在しなかった。各ツールやライブラリごとに好き勝手やってる
あと、privateだけじゃなくてinternalもな >>956
「オセロが盤面にの上にくる」っていうのがどういう状況かよく分からんのだけど、
プレーヤーが置いた位置まで石が移動するアニメーション的な演出をしたいってこと？ m_とかアンダースコアつけるとかは原始人に見えてしまう フィールドにmつけるのは割とそんな悪い習慣じゃないと思うけどアンダースコアは要らんね
mFooでいい。m_Fooにする意味が分からん フィールドにメンバーのmをつけるのもどうなのかとｗ プロジェクトで統一されてりゃなんでもええよ
センスだのなんだのは個人の信仰でしかあらへんのじゃ 一般的な流儀はキャメルmFooかスネークm_fooのどちらか >>968
キャメルとスネークの差異は単語の区切り方にあると思うけど、フィールド（メンバー）にmつけるのは
ハンガリアンだと思うので本来はちょっと別物だよね。
>>967
確かに人間には適応能力があるので基本的にはその通りだけど、
それでも優劣の差がないというのも欺瞞だとは思う
あるとしてもどうでもいい程度の差だろ？はいその通りですw >>969
そういうゴタクはキャメルとスネークより一般的な流儀出してから言いなよ >>954の>>953が書いてるコメントって
https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/inside-a-program/coding-conventions
のヒントのことか・・・・・公式ドキュメントでお墨付きつけてるのはちょっと酷いような
VS2019標準のLintでアンダースコア始まり変数名って許容されてたっけ？
最近VSCodeでしか書いてないから分からん 作ってるやつがゴミカスなんだな
昔のインド人は頭が良かったということで 複数ルール混在するのが一番面倒なので、mでもm_でも_でもいいから統一してくれればいいかなあ
そんで_に統一しませんかって事か ほんまそれなんやが
アホな中華は1クラス1万ステップとか作ってくるからめちゃくちゃになるんや c#のprivateメンバー変数にアンダースコア付けろだと…
これが今後のルールになるのかな? ゴミカスが普段組んでもいないのにいいと思って考えちゃったクソルール 一般的にって根拠を示しにくいけど、Microsoft公認のコーディングルールって言うとStylecopが示しているキャメルケースしかありえないんだよな
mHogeやm_Hogeは論外で今回の更新によって_Hogeが台頭したけど >>985
_Hogeじゃなくて_hogeな
MS自身が書くコードでは昔から一般的に使われてるルールなんで、そんなに驚くほどのことでもない
意識高いとこだとわりと採用されてるよ いま入門書で勉強中の初心者です
コードは基本的に上から下に処理されていくと理解しているのですが
本に出てくるサンプルコードは呼び出す側のあとに呼び出される側のコードが書かれていることが多くてしっくりきません
何か理由があるのでしょうか？ そんなん言うたら、呼び出すメソッドが別ファイルの別クラスにあるのはいいんか？っちゅう話だよな。 >>987
さすがにs_を標準にしちゃうのはかなり疑問だけどね >>988
多くの場合「全体 -> 部分」の順で理解したほうが
「部分 -> 全体」の順で理解するよりも圧倒的に脳にやさしいので
コードの構造もそれに合わせることで読みやすくしてる >>988
呼び出し元を上から下に進んで
呼び出し先に亜空間ワープして
呼び出し先を上から下に進んで
呼び出し先が終わったらまた亜空間ワープで呼び出し元に戻って
呼び出し元をまた上から下に進む >>988
昔のC言語は呼び出す前に関数宣言しておくか関数を定義しないとエラーだったから考え方は正しいよ
単にプログラム言語としての利便性が上がっただけ 前方参照が不可でプロトタイプ宣言が必要だったのは単に当時の技術的な制約に過ぎず
本質的な物じゃないと思うよw
メソッドのソースコード上の位置（どのファイルの何行目にあるか？）は
「技術的には」何の意味も持たない、と言うのが正しい。
一か所からしか呼ばれないメソッドがあるとき、呼ばれる側のメソッドを呼ぶ側より上の行に
書きたがる人がいるし気持ちは分からんでもないけど、そんなのあくまで好みの問題。どーでもいいよそんなの、が正解。 最近の言語だとどこでも関数宣言できるし、かと言って関数内だと一番下で宣言した関数を上で使えるって訳でもない場合もあるからね
トップレベルの処理は言語仕様によって分けられていることを理解するのは最初は結構大変なもんだ >>988
呼び出される側のあとに呼び出す側のコードが書かれていても
> コードは基本的に上から下に処理されていくと理解しているのですが
ならしっくり来なくね？
Pythonみたいに動的に関数定義したいということかな？ このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 53日 20時間 17分 52秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
