◎正当な理由による書き込みの削除について： 生島英之 とみられる方へ:ふらっと C#,C♯,C＃（初心者用） Part150 YouTube動画>1本 ->画像>1枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/tech/1616471904/ ヒント： 5chスレのurlに http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。
!extend:checked:vvvvv:1000:512
次スレを立てる時は↑を2行冒頭に書くこと（1行分は消えて表示されない為）
「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスや酔っぱらいレスはやめてください
>>980 を踏んだ人は新スレを建てて下さい。
>>980 が無理な場合、話し合って新スレを建てる人を決めて下さい。
■前スレ
ふらっと C#,C♯,C＃（初心者用） Part149
http://2chb.net/r/tech/1608085775/ ■関連スレ
C#, C♯, C＃相談室 Part94
http://2chb.net/r/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をクラスにしたい理由は？
>>3 単純に、ステータス、レベル、HP、MPをメンバ変数に持つクラスにすりゃええんちゃう？
レベルアップメソッドを呼ばれたら、それぞれを更新するだけ
最初は難しく考えないで、ありのまま設計して実装してみる
で、破綻しそうなら設計を変えて再実装
そういう試行錯誤も楽しいかもよ
ゲームはすべてのリアルタイムデータをエクセルに並べるつもりでプログラムを組め
でもまあ、とにかくやってみるってのには賛成。
根気よく続けて、それにちょっとした向上心があるなら、そのうちそれなりにはなる。
>>3 の人は、直接的なアドバイスを求めてるんだろうけど、ちょっとアドバイスしたくらいでどうにかなるようなもんでもないなぁって感じ。
>>3 オブジェクト指向言語だからクラスは物、オブジェクトであって、
RPGのキャラはそれぞれステータスを持つオブジェクト＝クラス。
キャラにはステータスがあるなら、それぞれのキャラクラスにはステータスクラスが保有されるべき。
・・・などと自分なりに整理して、設計してみてはどうか。
その設計で厄介なことがあっても、設計に納得出来るなら、それは通るしかない厄介事なのかもしれない。
それを回避したり厄介を軽減する手段はいろいろ有ると思う。
やってれば身についてくる。その過程がまた楽しい。
設計が正しいかどうか、それは自分が決めればいいが、想像が付かないなら書籍を漁る。
3だけど
>>4 パラメータクラスに最大値、最小値、現在値をプロパティで持つようにして
HP、MP、LV、EXP、クラスをパラメータクラスを継承して作ろうとしてる
さいごにステータスクラスとしてHPからEXPをフィールドに持つようにしてコンストラクタでインスタンス化させるようにしてる
class Prameter{
>>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でやってるステータス計算の再現なのかな。
なるほど、
最初はあんまり沢山クラス作らない方がいいかと思う
オブジェクト指向の学習が目的なら、ポケモンで学ぶオブジェクト指向みたいなのがいくつかあるから
ゲーム自体があんまりOOP向きの題材じゃないかもしれないよ。
そうか…
ちなみに、C#(プログラミング)初心者が理解しやすそうな題材ってあります？
どういうものを最終的に作りたいかによるけどゲームが目標なら
なるほどなー
いろんな種類のキャラを動かす系のゲームはOOPに向いてると思うけどな
>>27 向いてない
オブジェクト指向って
オブジェクト同士の処理を綺麗に書く
ように作られてない
全オブジェクトが存在するシーンにほぼすべての処理を記述することになる
マップ情報がないとキャラは移動すらできないことがすぐにわかる
ではマップとキャラのデータが混在した処理をどこに記述するべきか？
シーンに決まってる
なのでゲームシステムに関わるほぼすべての処理をシーンに記述することになる
もう仮にオブジェクト個別の処理が2～3個見つかった程度で個別のクラスなんかに書くのはバカってぐらい
全部シーンに書くことになる
言語そのものよりライブラリに何があるのか把握しきれなくて辛い。
>>29 わかる。会社に入るとドキュメントの無いライブラリも加わる。
ゲームって普通にOOP学習にはもってこいじゃね？
ゲームだと単純に楽しいし、良く知ってる世界だし。
ゲームはOOPより関数型のがやりやすい
unityやwpfで何か作ったらいいんじゃない？
Unityはやめといたほうがいいんじゃん？
なんか作るとき、ついつい無駄にインターフェース作ったり、クラスを継承させたりしたくなる。
質問です。
>>41 なるほど、理解出来ました。
ありがとうございました。
>>1 関連スレ
ふらっと C#,C♯,C＃（議論用） [無断転載禁止]©2ch.net
http://2chb.net/r/tech/1469538912/ >>38 「いつか使うだろう」という動機で作る機能の9割は結局使われないという法則があってだな
でも、ついでだし作っとくか、で作ったやつがその後のバグ対に効果大なこともあったな。結構。
一人で作ってるならいいんだけど別の人が対応する時に混乱させるだけなことが多いからな
個人的には
>>45 に同意
要件レベルだと「いつか使うかも」で入れた機能はゴミでしかないが、
開発者が気を利かせて入れたものは役に立つことが多い
>>47 センス悪い奴って絶望的じゃん
ユースケースを脳内で構築できないっつーの？
必要になると思って書いておいたプロパティやメソッドが結局まったく使われなかった、
っていうのはないことはないと思う。
YAGNIって普通はこういう話じゃないの？
>>38 が言ってるような要らんInterfaceや要らん継承関係を作ってしまうって
YAGNIとちょっと違う気がするし、そもそも普通はあんまりやらん気がするなあ。
コードレベルで呼び出されないのと運用上使用されないのは別問題だよ
>>44-50 横から便乗で質問ですけど、
「いつか使うだろう」とインターフェースや継承関係を作っておく自体は推奨されることですか？
例えば、インターフェースや継承関係が無くても、直付けで作れてしまう訳じゃないですか。
むしろ、そっちの方が楽（というか、直付けでしか作れない人もいますし）。
ただし、物事が複雑化してきたときに、インターフェースや継承関係があると拡張しやすい。
これって上級者なら、（どんなに小さいプログラムだろうが）常にインターフェースや継承関係を作った方がいいのか、
それとも、ケースバイケースで「このぐらい複雑ならインターフェースや継承関係が要る」という判断基準に則って作った方がいいんですか？
>>51 すれ違いになりました。
議論スレ、行きます。
>>52 推奨する人は確実にいないと思うよ。
「ついやっちまう」ことも普通はまずないんじゃないか。
IClonableみたいな実例があるから皆無とも言えないけど。
Seleniumで closeとquitをセットで使ってましたが
というのもなぜか、最近アップデートされたChromeドライバーのバグなのか
演算子のオーバーロードを定義したクラスを継承してそのクラスのオブジェクト同士を足したりしたいんだけど、
>>57 当たり前のことが起るべくして起こってるようにしか聞こえんよ
何か盛大に勘違いしてない？
>>59 その当たり前の事がわからないのですが…
子クラスのクラス変数に親クラスのインスタンスを入れれないのはわかりますが、それに対してどうすれば良いのですかと質問しています。
いやいやゲームはメチャクチャOOPに向いてる。
>>62 エアプ乙
ゲームはオブジェクト同士の関連処理が一番多い
それを綺麗に書く処理はオブジェクト指向言語には無い
これを議論するといっつも言語機能に用意されてないもんだから色んなワンダーランドがご披露されるだけのクソ展開になる
いいか
そんなもんないんだ
お前がどう書くかなんて俺は興味ない
ただ言語の機能にない
それだけだ
たんに解がひとつではないだけの話じゃね？
文面見ればオブジェクト指向を理解して言ってるのかどうかわかるやろ
議論スレに行った方が良いのか判らないけど、
ゴリゴリにスペック使うような案件にC#使うとは思えないけど
日本産のスマホゲーと大陸産のスマホゲーぐらいの速度差は出るだろうな
オブジェクト同士の関連処理を綺麗に書く機能、って具体的にどんな感じの物なのか興味はある。
ここ「初心者の質問スレ」で「初心者の雑談スレ」じゃないんだけどテンプレ読めないの？
>>68 中華の大手どころってマルチプラットフォーム対応なソシャゲもUnityとか使わずにそもそも自前エンジンで開発してね？
>>69 まあ言語機能云々は意味不明に聞こえるねw
前も書いたけど、ゲームの場合Mediator的な装置を用意すべき場面でも
目に見えるオブジェクトに引きずられて変な設計してしまいがちだと
いう意味なら分からんでもない。
バブルボブル（おっさんにしか分からんかも）で泡の相互作用を
Bubbleクラスに無理に実装したらたぶんハマるよね。
linq便利だなーって使いまくってたけど
>>75 でもLinqって古くから有る技術の延長にある気がする。
SelectしてWhereで選んでSortしてっていうのは、コマンドプロンプトでパイプリダイレクションとかいう手法に似てる。
ラムダ式とかは新しいのかな。数学の世界とかそういう所では古いのか。
やっててよかったラムダ式。
そうか、C#だとメソッドチェーンすらも一般的ではないのか…
>>75 そりゃ脳みそは使わないと衰えるだろうね
最適化重視で副作用を容認したコードを書こうとすると詰まることが増えた気がする
いきなりメソッドチェーンとか持ち出したのはLinqの話に絡めてか？
Linqのクエリ式自体はメソッドチェーンのシンタックスシュガーじゃん
メソッドチェーンの元々の意味はvoidのメソッドをthisを返すようにして....
>>73 純粋に、自分が知らない有用な書き方があるなら知りたいとは思うんだよな。
別スレの LINQ がらみの話題もやるかどうかは置いておいて勉強にはなったし。
もしくだんの人が出てきてくれて講釈してくれるなら専用のスレぐらいは立てる。
初歩的な事かもしれませんが教えて下さい。
>>85 どうすればいいじゃなくてどうしたいのかをお前が決めろ
平均年齢なのか最大年齢なのかそれともまた別の基準なのか
グループ化に使うキーが一意に定まらないならグループ化のしようがない
そもそもの設計ヤバない？AgeはMemberに持つのでは？
デフォルトで使われる比較関数じゃ欲しい結果が得られないからGroupByに独自の比較関数を渡すか、Groupクラスに比較方法を定義しておくかのどちらか
新卒研修の課題とかだろうから設計にツッコミいれてもしょうがないような
初心者以前の話だよな
>>92 動かないあれを見て分かるか？
そもそも構造すら間違ってるやろ
>>92 わかるんなら説明してくれよw
メンバーの年齢だけを保持してるグループってあまり見かけないし
俺はこういう場合、独自解釈して好きなように作る。
>>93 >独自クラス「Group」のリスト
>このリストをクラスのAgeListをキーにGroupByしたい
List<Group> list = new List<Group>();
// なんか処理
list.Groupby(x => x.AgeList)
ってしたいって理解したんだけど違うんかな
宣言でそもそも間違ってるのは知らん
Ruby なら、こういう感じ
C++とJavaを業務でやっていてc#始めた初心者です。
そもそもXamarinで作る必要あるのかという感じがする
>>104 人脈作りから始めよう。
objective cとcocoaの方が需要あるやろ
>>105-107 回答ありがとうございます。
マジですか。。。C#以外をお勧めされて複雑ですが
その言語も調べておきます。
まだC#学習して1ヶ月程度ですが機能が盛り沢山で面白いので
Macでも普及して欲しいですね(´･ω･`)
機能は盛りだくさんでもPythonやJavaの方が人気なんだよね。
今、統計的な素養があってPytorch触れると
>>108 どうしてもC#がいいなら採用出来るかどうかは別にしてもUnityという手はあるけどね
>>110 TensorFlowでもええん？ダメなん？
>>113 MSが共通Wrapper作りましたってことでDLL importは必要なくなるし、アンマネージ
部分についてもお約束を守ればよくなるみたいだけど、サンプル見ると色々手続きが
面倒臭そうで使い勝手は良くなさそう
void*とかobjectにするしかないだろうしアホみたいなオーバーロードの山になるだろうし
そもそもガンガンWin32API使うなら素直にC/C++使うし、C#だとちょっとつまみ食いする程度にしか使わんから今のままでもいいや
apiで使う構造体とかの面倒くささが無くなるならいいんじゃない？
OSのようなハードに近いレベルの言語となると、Rustが流行ってるのかな。
>>113 https://dot-sharp.com/net-getdetailsof/ Shell32.dllを使うとき、com参照を追加するだけでC#のライブラリと同じ程度の手軽さで使えました
これが増えるってならいいんじゃないかな
>>118 PyTorchはずっと不人気だったのに
今調べてみたら、ここ二年ぐらいでTensorFlowと拮抗してんな
ま、いいや、どっちか使えりゃ問題ないだろ
C#をネイティブコンパイルできうようにすればいいだけだと思うが。
>>123 無理せずPaddlePaddle使ってたんでえぇで
日本では需要ないけど
>>125 PaddlePaddleはダメダメだな
日本だけじゃなくて、世界でもダメな奴
AI関連は、何を使えるかよりどこの博士号を持ってるかの方が重要なんだろ？
以前画面解像度切り替えのツールを作った時にvanaraといwin32apiのラッパー使ったな
win32って一々ラッパー挟まずとも実はC#側で結構調節してくれるんだよな
a={1, 2, 3, 4}という配列が与えられて
>>132 >>133 その書き方だと通るんですよね..
下のように解説してるサイトがあったのでそう書いてみたのですが
なんかおかしいんです
ビット bit に i 番目のフラグが立っているかどうか if (bit & (1<<i))
え。
あ、やっと気づきました
>>134 それはたぶんC#ではなくてCのコード
「bit & (1<<i)」この式の型は何？
Cと違ってC#のifの()の中の式はboolでなければダメ
まあこれは初心者が知らずに混乱しても仕方ないかもしれない。
でも
>>132 のコードの何が間違ってるかは初心者でも自分で考えれば分かるでしょ。
とりあえず問題を小さい問題に分けて分割統治することから始めましょう。
>>133 はそういう意味で書きました。
Typescriptじゃインターフェース名にＩ（アイ）をつけないのが推奨されてるけど、
破壊的変更を.NETユーザーが受け入れてくれるなら良いんじゃね
C#でIが取れなかったのはCOMの影響があったからとかなんとか
エディタで色分けしてくれればいclass, struct, interface, abstract
プリフィクスのIは字面からインターフェイスだと分かるようにしたい、という強迫神経症的な動機というより、
どうせインターフェースにIを付けなくなっても、実装クラスのいい名前が思いつかずになんとかImplってサフィックスつけるんだろ？
Delphiだと、クラスにはTypeのT、パラメータにはFieldのFを付けるんだよね。
>>144 付けないよ
そんなの付けるのJavaやってたやつくらいやろ
命名規則で一番上手くいってるのはC#と思う
で、最近は名前がさらぶつかりにくくなるようにメンバ変数はm_を付けるスタイルに個人的に変更した
>>147 こういう適当な名前を付けるやつがいることにピキってるっぽいね
適切な名前にすりゃブッキングしねえから名前付けをサボるなってことらしい
なるほどなぁ
おまえ馬鹿か
そんなのに適切な名前なんかブッキングできねぇよカス
>>152 Microsoftの推奨する命名規則を参考にすれば良いんじゃない？
つまり、I付きPascal形式でスペル省略不可のフルネームで名詞を表せば良いのかな。
自由に付けても良いけど、.Net Frameworkと調子を合わせると違和感が無いと思う。
うちの会社、昔から変数名の1文字目にデータ型の略称（？）をつける文化みたいで、
>>156 郷に入っては郷に従え！
君の使って良い変数はI150からI300までな！
そこはFortran出身者の支配する村であった
皆さんコメント入れる？ 命名規約とか守ってたらコメント要らないような気がしてきた。
>>159 いわゆるドキュメンテーションコメント的なものは入れる。
あと、実例みたいなの。
//引数にXXとYYとZZを渡したら、戻り値はAAになる。
visualstudioだとクラスやメソッドの１行前に///入力で自動補完されるからそれは使ってるかな
日付、所属、名前、旧コードはコメントに残すのが常識でしょ
バージョン管理ツール使ってるのに旧コード残すやつにはイラッとする！
コメントって入れるものだったんだ。
なぜこんなコード書いたんですか？と書いて旧コードを残すわけですね
168が仕様を理解せずおかしな実装を
>>159 コメントは基本的には必要悪なので必要がない限り書かないのが正しいけど、
少なくともパブリックメンバーについては単純に「必要」かもしれんね。
ないと書いた人の意図を変に誤解してないか不安になって
結局中のコードを覗きたくなるかもしれない。
そんなことしなくて済むためのカプセル化のはずなのに
1年後に自分の書いたコード読んで、何をやっているかちゃんと理解できるならば
>>171 何をやってるかなんてコード読めば解るんだから、
そんなことのためにコメントは不要
「なぜ」そんなメソッドが必要か、
「なぜ」そのデータ構造やアルゴリズムを選択したか
なんていう、コードから見えない情報を記すのがコメント
MS含めアメリカ製の高品質なコードって「なぜ」のコメントが無茶苦茶充実してるよな
コードレビューでコメントを書けって指摘されるじゃんw
コメントなんて要らないんだよ
private なプロパティってフィールドにするべきですか？
>>172 言いたいことは分かるけど「何をやってるかなんてコード読めば解る」というのは
あくまで理想であって常にそうできるわけじゃない。
何をやっているか書いてくれた方がありがたい場合もあるよ。
>>176 そんなことをルールで強制する理由はないと思うよ。
>>177 何をやってるかがコメントとコードで乖離してる事があるのが問題
英語でthirteen daysって言ってるのに、
字幕には2ヶ月って書かれる戸田奈津子の翻訳みたいな事が起きうる
>>178 逆に、コメントを書かせることでコメントを書きやすいコードになるという面はあると思うよ
クラスやメンバの責務が十分に明確ならコメントと実態の乖離なんてそう起きるものではない
>>178 コメントはバグる可能性があるからコメント書くな、
なんて言ったらバグる可能性があるのはコードも同じなんだから
コードも書くなってことになっちゃうよw
「不必要なコメントは有害無益」は正しいけど、それは
必要なコメントを否定する根拠にはなりえない。
>>180 コメントがバグるって話じゃなく、
書いた人の「つもり」がコメントとして残るのが危うい
実行時にどう動くかを決めるのは、コメントではなくコードなのだから、
コメントを読んでコードを読んだつもりになれるのも危うい
入門書の多くがコメントの書き方を蔑ろにしてるのが元凶だと思うんだよね
「コードを読めば何してるか分かる」のだから、メンテ忘れで誤ったコメントが残ったとしても問題ないとも言える。
>>182 あれは解説を見ないとプログラムが理解できない人向けの本なんだからそれをコメントに書くのは当たり前じゃん
>>184 > 「コードを読めば何してるか分かる」
ならコメントなんていらんだろw
>>172 YOLOv5をC#に移植して内容を説明しては
くれまいか？
そんなに簡単な話なら誰も論文なんて読まないよ～ :-p
ドキュメント代わりにしてるから入れる
クラス図もシーケンス図もねぇのになにいってんだこのバカ
>>186 だから要らないって話だろ
var hoge = items.First();
で最初の要素を取得するなんてコメントは要らん
記載するならwhy何故取得するのかだけ書けばいい
もし動作について記載したくなったなら、それはメソッド化するとかを検討した方がいい
>>190 だからと言って
> メンテ忘れで誤ったコメントが残ったとしても問題ないとも言える。
ってアホだろ、って言う指摘なんだが…w
それはアホだけどコメント入らないも的外れって指摘なんだが
>>192 >>184 の全文読んでから出直してこいよw
宗教が合わないと作成者本人が綺麗に作ったつもりでも読みにくくてしょうがないからブロック毎に動作の概要ぐらいはコメントで書いといて欲しいわ
なんだよ、せっかく議論スレに移ったのについてきてねーじゃん
xxxInternal
パワーポイントやエクセル内の文字列を検索するクラスってありますか？
>>197 Windows Searchを使えば検索窓と同等の機能がプログラムから使える
>>198 素早い回答ありがとうございます！
そんなのあったのですね！検索力不足を痛感しました…
調べてみます。
議論スレに移れないってことは、
>>200 何度も言うけど、真の無能はそれが自分を棚上げした物言いである、
という簡単な事実に気づく程度のこともできないお方だよ。
これ割とマジで大丈夫かと思うわ
ついでに、これも何度も言ってるが、そんなくだらない「交通整理」に誰も従わないのは
他人を見下し自分が主導権を握りたいという自分勝手な承認欲求が行動原理
>>202 暴れて飛行機から下ろされ
飲食店で入店拒否されて暴れて警察を呼ばれ
警察を殴った誰かはTwitterで同じこと言ってたなｗ
>>193 その 184 だけど。w
「コードを読めば何してるか分かる」な人は、そもそもコメントがなくてもいいんだから、書かれていても無視すればいい。
コメントが欲しい人は、コメントの弊害(メンテ忘れとか)の現状を承知の上でそう言ってるんだから、そもそも問題ない。
つまり、コメントがいる／いらないの論争は無意味だからやめとけってことなんだよ。
その上で「コードを読めば何してるか分かる」ように丁寧な書き方を目指せば済むことじゃん。
まあ自分はブロックと言うか処理単位でのコメントは出来るだけ書くけど。
・コメントがあるとノイズになり視認性が落ちる
これは茶化しで書くけど。
>>206 > つまり、コメントがいる／いらないの論争は無意味だからやめとけってことなんだよ。
誰もそんな論争してませんよ…
もしかして
>>186 をコメント不要という主張だと思ったのか？w
そーなのか。
>>211 >> メンテ忘れで誤ったコメントが残ったとしても問題ないとも言える。
> ってアホだろ、って言う指摘なんだが…w
改修履歴をコメントで残すとかいうのさえなけりゃ
>>216 あれなぜコメントの機能を持たせないのか不思議だわ
{
"$comment": "コメント"
}
みたいな形でコメント書くという方法もあるみたいだけど気持ち悪いし
最初に作った人が「コレはデータだからコメント不要」って取り付く島もないんだとか
jsonなんて人間の読めるもんじゃないと思う
>>218 JSON自体は仕様がもう確定してるから。
jsoncとかJSON5とかRelaxed JSONとか拡張した別仕様ならある。
json便利だけど、protobufを使うようになってから使用頻度減ったなー
１つの一連の処理で一度に10回以上は失敗する可能性があるんだけど
できるよ
try{
デーモンコアと
マイナスドライバーを設定
try{
while(米が勝つまで回す){
①測る
②マイナスドライバーを動かす
}
}
finally
{
③デーモンコアを離す
④if(青い光りが見えた){
⑤みんなを退避
⑥逃げる
⑦救急車を呼ぶ
⑧遺書を書く
}
}
大体こんな処理なんだけど
③～⑧は途中で例外起きても
最後までやってほしいらしい
っていう一連の処理なんだ
どのエラーや例外も全部保存したい
>>224 なんかサンプルないですかね？
溜めておいた例外を最後にAggregateExceptionのInnnerExceptionsにセットして投げれば
>>227 なんかそういう処理の書き方の流れが知りたい感じです
NlogつかってファイルかDBに残すのが現実的じゃね？
https://nlog-project.org/ こんなやつ
>>223 失敗してても処理が継続される時点でそれを例外を呼ぶべきか、そもそも疑問に感じるね。
class DaemonSequenceException:Exception
DirectoryInfo.GetDirectories は例外を送出するけど処理は継続する
まあ、結論としては
>>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ってキャッチできますか？
たぶん欲しいのはエラーのログなんだろうね。
なぜかこういう人は何をしたいのか書かないんだよな…
>>243 それで出来るけど、catch( AggregateException ex )で受けた方が
AggregateException.InnerExceptionsを参照しやすくていいんじゃない
>>247 ありがとうございます
受け側はなんの例外がくるかしらないんですよ多分
例外を見ればどの処理で発生した例外なのか確実に分かる場合はいいけど
>>250 どこで発生した例外かを知りたいなら例外にその情報を入れとけば良いだけだろ
>>251 >>239 の例ではそれをやってないから困るんじゃねって話なんだけどさ
>>252 ExceptionでもSourceに入れるとかMessageの一部に入れるとかやりようはいくらでもあるだろ
エスパー回答すると、Disposeをしっかり作ってusingを使え、が顧客が本当に欲しかったもの
C#の話と関係無いかもしれませんが、パッケージの開発環境って今の時代何がありますか？
落ち着け(´･ω･`)
なんとなくエスパーすると、開発ソフトをインストールさえすれば、その後はネット非接続で何でも開発出来る環境が理想ってこと？
>>258 待て待て、標準ライブラリだけでもオフラインで開発できるなら、回答しては「Ｙｅｓ」じゃないか？
特に、その「他のPCでDLして開発PCに入れる事になりそうだけど」が出来るんだしさ
>>255 目的を話せ
俺のエスパー能力をフル発揮すると、
セキュリティ上、スタンドアローンで動かさんといかんPCがあって、そこで開発したいだよな？
>>258 ありがとうございます！！！
環境を自分で作る以外ないんですかね。無謀すぎますね。
コンパイラ作るわけじゃないですからね統合環境は。
>>259 そうそう単にセキュリティの心配です。
オフラインだと全く外部に漏れる心配ないわけじゃないですか。
めちゃくちゃ安心するじゃないですか。
何でインターネットに繋いでないとプログラミング環境が整わないような
状況なんでしょうか？どう考えたってオフラインのほうがよくないですか？
そういうセキュリティの気にし方をするのであれば、普段使いのPCとは別に
インターネットにつながっていないが故に管理がおろそかになってパッチ適用がされない弊害の方がやっかい
構造体(値型)を関数の参照渡し以外で、参照する方法ってありますでしょうか？
>>264 策士策に溺れてはいけない
愚直に一時変数を使いましょう
>>265 ref ってローカル変数に使えるんですね！
前に軽く試した時には右辺値にしかrefを記載してなかったので、
左辺の定義にもrefを記載すれば行けました。
有難うございました！
オフライン環境での開発だけど、
>>270 バグや脆弱性対応は？VS2019って頻繁に更新されてるけど
>>273 offlineインストーラーも知らないのは開発者としてどうかと思う
getsetプロパティをFuncで呼び出せるようにしたいのですが可能でしょうか？
よく分からん
>>276 返信ありがとうございます
イメージとしては複数のクラスで
public bool hoge {set => test = value; }
が複数あって
List<Func<bool, bool>> func;
に追加していってキャンセルとか何らかの処理後に一括して戻したい、と言うような処理です
やはりプロパティってメソッドみたくできないFuncに入れる事ができないんでしょうか
他の方法ですっきりする方法はないですかね？
やりたいことがさっぱりわからんな
>>277 List<Action<bool>> list;
list.Add(b => hoge = b);
こういうこと？
まあ気持ちはわかる
>>274 知らないって決めつけてるのはどうかと思う
単にどうしてるのか聞いているだけ
>>278 破棄と生成できれば良いのですがちょっと難しい。ユーザーコントロールでバインドしていて各コントロールは値を参照しあってます
今回は画面が切り替わったときに表示非表示を変える戻す、なので直接は関係ないのですが影響度を減らしたい
>>279 >>276 見直してプロパティを直接でなくてもラムダ式でいけそうなことに気付き
>>279 さんの形を思い浮かびました、今出掛けてるので確認は後ですが多分解決できそうです
皆様ありがとうございます
解決しなければまた聞くかもです
ありがとうございます
これあれじゃね？
何がしたいのかよく分からないね。
>>282 元に戻す処理を管理したほうがいいケースなのか
元の状態を管理したほうがいいケースなのかを考えたほうがいいよ
まあ、設定画面がモードレスでリアルタイムで値を変えたいときもあるかもしれんが
>>288 更にundo/redoの機能を付けてくれまいか？
で更なる深淵へw
>>290 影響する値でエラーが出てもそれとは関係ない表示はできる限り続けて欲しい（プレビューが見えないから）
エラーが出てるときは値の変更で表示は変わっても最後の反映はできないようにしてほしい
でも値を変更してる最中のundo,redoは効くようにして欲しい
って割とありがち要求だよね
モードレスやった時点で地獄を覚悟しろって感じ
>>283 めんどくさいのに本当にしてるのか気になったから聞いたんだけど何かおかしい？
うちにも本当にしてる端末はあるぞ。
>>293 ネットに繋げないならそうするしかないし言うほど面倒でもないだろ
そもそもネットに繋いでる場合でもアップデートがある度に適用なんてしないよ
>>294 が書いてるように修正内容見て影響ないとかワークアラウンドがあるなら適用しない
オフラインがめんどうとか何言ってんの？開発する時にはセキュリティ上当然やろ
今のVSって最新メジャーバージョンは完全に人柱向けだからなあ
>>298 中身読めよ
2017の方は脆弱性修正と軽微なバグ修正しかやってない
C#を勉強中です
delegateの機能が解説されていた箇所に書いてなかったの？書いてあったけどそれを理解できないってこと？
>>301 そのわかったというDelegateの機能を説明してみてもらってもいい？
>>301 真面目な話、無理に今理解しようとしなくていいと思うよ。
コード書き出ぜば自然に分かる。
後回しにして先に進んだ方が吉。
>>303 機能の解説だけでどのようなときに使うかは書いてなかったです
Delegate型の説明と作り方の後に例としてConsole.WriteLineでHelloと表示するメソッドを
新たに作ったDelegate型のaという変数に突っ込んでa()を実行して
ほら表示できたでしょという感じだったのだけれど
だからどうしたとしか思わなかったです
自分も変数のシャドーイングとか何が便利なのかわからないです
>>308 これがdelegateだとしたら意識しないで使ってました
まさかこれが..
デリゲートは自分で使うもんじゃないと思ってた。
>>306 試しにhello2 からhello100まで突っ込んでみよう
まあこういうものが腹に落ちるようになるのが楽しいとこでもある
例えば、Ruby では、Forwardable でインスタンス変数に委譲できる
>>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なフィールドを宣言する機会が多いいんだが、
メソッド内で1,2回とか参照しないのであればわざわざnon nullableなローカル変数に代入しないが
>>333 違うだろ。C#ならフィールドとプロパティをきちんと区別しないといかん。
x = a ?? b; ←null合体演算子
ピリオドとクエスチョンの位置逆だけどnull条件演算子
linuxとwindowsで動くguiソフト作りたいんですが、共通の開発環境と言語ってあるでしょうか？
>>341 C++の話をするのに何故C#のスレに来たの？
>>339 逆にnullだったらそのままにしたいってことが多いんだけどそういう演算子ないよね
int? x = null;
int? 2x = (x == null ) ? null : (2 * x);
みたいな
opengl関係無いアプリも作りたいので(´・ω・`)
>>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だった
その他の案
タスクスケジューラでアイドル状態を条件にプログラムを起動できる
>>359 率直に言って無理がある気が。
結局システムで正式に定義されたステートじゃないと
今たまたま何か方法を見つけ出してもいつまでそれが使えるか
わかんないよね。
スリープを抑止するプログラムが起動しているかどうかで
判定できないかとも思ったけど、ブラウザの動画再生は
たぶんスリープ抑止しないよね知らんけど
SetThreadExecutionStateを試してみます
>>360 同じような機能入れてたけど設定し忘れ&解除し忘れで意味なかったです
>>361 でよさそう(未確認)
>>368 GetLastInputInfo は数ヶ月前10で試したけどうまくいかなかった
.NETで文字列の見た目の幅を求めるライブラリってある？
>>370 シフトJISでエンコードした時のバイト数を数えればいいと思うけど
今時そんなの何に使うの？
>>371 ありがとう
でもできればプラットフォーム依存しないほうがいい
>>372 Markdownのテーブルをフォーマットしたり色々です
絵文字やサロゲートペアも考え出すとめちゃめちゃめんどくさいよね
>>370 雑にやるなら、StringInfo.ParseCombiningCharacters2倍して、半角文字の文字数引いたら良いんじゃないの？
アクセント付き文字も半角文字に入れればそれなりに並ぶんでは？
タイ語とかアラビア語まで考える？
MeasureStringの数字を見ながら、頭がウニになったGDI+の思い出
>>375 情報ども
とりあえず日本語対応できればいいかなと
>>377 あざす
これたぶん正解っぽいすね
Markdownのテーブルっていうのが何かよく分からないけど、
細かいこと言えば等幅フォントであってもどの文字がどの幅で
描画されるかはフォントに依存するはずだと思うので、（一般的に半角の文字だと
されているものが半分の幅で描画される保証なんて実はないんじゃないか？）
グラフィック関係なら
>>371 みたいに実測するのが一番確実だよね
同じ文字で同じ等幅フォントで表示しても、アプリによって全角/半角相違することもあるよ
httpclientでpostした時にレスポンスヘッダーのlocationが取れないんだけど取る方法なかんかな
HttpClientをnewするときに渡すHttpClientHandler(.NET Core/5ならSocketsHttpHandler)の
パネルに貼り付けているlabelの数を数えることってできませんか？
>>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 >>404 それで行きます！ありがとうございます！
動的にオブジェクト追加してるならそのオブジェクトの参照は持ってるはずだから
言語の機能でインスタンスを特定しようとするのはギルティ
>>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 Core 3.1の次バージョンを.NET 5とリネームしただけだから.NET Coreが終わったわけじゃない
インターフェースや抽象クラスのメリットとは？
>>418 >インターフェイス
多重継承
>抽象クラス
デフォルト処理が決まらないメソッドを継承先でオーバーライドで強要する
ちゃんとifやcase文で書いた方が実は後で楽だけどね
将来的にスパゲティ化することを防ぐために多少手間でもインタフェースや抽象クラスを使って制約を設けるもんじゃないの？
そういうのは大抵、いざ要件が増えたときには、今の引数だけでは〇〇の情報が足りないとか、拡張を想定していなかった部分を拡張しなければならなくなったとかで破綻するんだよ
俺は
>>422 派だな。
要件が増えたときにパラメータが増えたとしても、ファクトリーに渡す拡張用の値増やすだけで元の処理に手を入れなくていいから
もしかして抽象クラスとインターフェースって使う必要ない？
>>425 まあでも知ってると他の誰かが使ったときに欠点がわかるよ
下地がそうやってできてるのにそれに逆らって作ってもしゃーないし
合わせるのは大事
ただメリットはよくわからん
List<object>やobject型の悪用とあんま変わらん気がする
落ちてもどこで落ちたかわからんのもいっしょ
interfaceはこのクラスにはこのメソッドがありますよと言う事を約束するだけで
>>425 アーキテクチャ綺麗だとあんまし使わないね
依存関係グチャグチャのスパゲティになってるとインターフェースで切ってDIしないとキツイ
けどそれは最初から設計ミスなんだよ
クラスを他の人に使わせてまうとあとで変えれなくなってのっぴきならなくなることがあるからやがな。
多態性を利用するために必須なんだから使わなきゃ不便じゃない？
>>432 多様性を使う為に必須というのは初耳だった
別に普通のクラスでも継承してインスタンス化すれば多様性は使えると思ってたんだけど
同じ親クラスやvarの配列にしてfor回したり
そこでインターフェースや抽象クラスにしてしまうよりかは
少なくとも何も処理しないダミー関数でも書いて仮想メソッドで実装しておいた方が良いとおもてる
>>431 いやいやinterfaceから触るでしょうよｗ
ちゃんとcase文書いた方がいくつ分岐してるかわかっていいじゃん
>>436 いくつに分岐しているかを気にしなくてすむのがinterfaceによる抽象化のメリットの1つだろうに
>>431 interfaceって実装しなくてもいいの？
詐欺にならない？
OOPの歴史も30年以上あるのでさすがに本質的に不要なものが
>>440 実装しなくても良いのではなく、interfaceそのものには実装は書けない。必要なメソッドを定義するだけ
良くある例としてIDisposableがあるけど
using(var obj = new TestClass()) {
}
みたいな使い方したければ上記のTestClassにDispose()メソッドを用意してねって事で
class TestClass : IDisposable
{
public void Dispose() {何らかの終了処理}
}
みたいに実装を用意しないとそもそもエラーになる
>>434 普通の継承でも使えたね。すまん
具象クラス継承の適切なケースがわからんので考えなくなって、出来るって事も忘れてた
>>440 単一継承しか許されないクラスと違い多重継承が許されるインタフェースでは、実体を実装するとC++同様に基底メンバの衝突の問題が発生する
この問題を回避するために実装を派生先に委ねてしまうことにしてインタフェース内では実装は禁止されている
教えて下さい。VBから書き換えて勉強してます。
自分で使ったことはないけどinterfaceはデフォルト実装持てるようになってなかったっけ？
まあどうしてもバイナリ互換性を崩したくない時に使うもんだよね
あるdll（A）にインターフェイスが定義されており、別のdll（B）にその実装があった場合、Aを修正してもBに影響がなければバイナリ互換性があると言う。
まあCOMみたいにナントカ2とかナントカ3とか増えるのもまたアレ感があるんで
"IsDisabled": false,
アップキャストを行うと何が嬉しいのでしょう？
>>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>();
ポカミスだと思うけど、Selectはシーケンスを返すだけだよね。
>>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って回答するけど
>>473-476 ありがとうございます
なるほど、XMLでも階層構造は持たせられるけど仰々しいですよね
ああ、あれをシリアライザって呼ぶんですね
昔、一回JavaだかでJSON読んでみて満足した記憶があります
GW明けの使い捨てのスクリプトではJSONで書いて読んでみます
unityでc#ぼちぼち覚えてきたけどc#って何ができるんや
[ {"a" : "1"}, {"b" : "x"} ]
>>477 階層を持つのは後の欠点にもなるからね
結局はCSV形式で持ってた方がいずれ近いうちなるデータベース対応時に楽だよ
>>484 なんでだよ
階層データじゃデータベース入んねぇだろ
楽じゃないな。
jsonはそのままクラスに持たせられるから便利
>>487 エクセルで読ませたら先頭のゼロ消すやつとか日付のフォーマット変えるやつとか、ハイフンがついた数字を日付にするやつが現れがちなのですごく嫌かな。
目的の違うデータ形式を個々人で違う基準で評価してあーだこーだ言っても仕方ないのと違うか。
csvのrow/columnをjsonで表現できるが逆はできないからcsv⊂jsonだけど
jsonで大量データだと、容量削減のために要素名を変数1文字とかやりだすしな
>>491 そんなことするくらいなら圧縮するわ
冗長だから圧縮した状態同士での比較ならCSVと変わらん
>>493 デカイ階層データで気になるのは処理速度だから圧縮されると余計時間かかる
シリアル化方法（ＣＳＶをシリアル化とは普通は呼ばない気がするけど便宜上）を選択する上での
エクセルおじさん用のデータ交換フォーマットと割り切ったほうがいい
>>494 展開時間かかる代わりにアクセス時間が相当減るから、変わらんか早くなるよ。
用途次第だけどjsonのままDBにつっこめばいいじゃん（）
>>497 そんなのCPUとI/O次第としか言えん
結局、データベースに入れる運命なのに今の時代に階層データにするやつなんか頭悪いんだよ
いまどきはどんなDBMSでもjson形式のデータインポートくらい出来るだろ
>>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はインポートで有利とか言ってる人が居るけど
>>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扱うって結構あり得る事なの？
>>538 あるよ。
ブラウザで3dモデル表示するときに使う形式にglTFってのあるんだけど、もろにデカいJSON。
プログラミングでファイル入出力を早くするにはやっぱり
ちなみにGPUは欲しいですが3Dのゲームはしません(ゲーミングPCを購入予定ですが…)
そんなレベルならMac買っとくのが無難
ファイル入出力はGPU関係ない
GPGPUってなんか暗号通貨のマイニング以外で聞かなくなっちゃた印象があるけど
>>538 あるだろうね
サーバーもクライアントもDB持ってるけどその間のやり取りはjsonでとか普通にあるから
ストレージとしての用途ならsqliteでもいいけど伝送手順として使われることも多いので
>>543 大学の課題でテキストを読み込んで文字列を探すプログラムを作ってます。
文字列を読み込むスピードをほぼ0秒にすると実行時間が短くてすむので
良いGPUはないかと思ってるんですがね。。。
折角回答してくれてる内容の1行目を声に出して10回読め
>>546 GPU関係ないって書いてあるじゃん
重要なのはストレージとCPU
速ければ早いほどいいというだけ
ありがとうございます。
信じられないなら信じられる別の場所で聞けばいいんじゃないの。
> どんな高性能なPCでも時間は0秒にはならないってことですね？
>>550 そういう根拠のない思い込みでこうなるはずなんて思考をしてたらプログラミングなんて理解できなくて詰むから、早いうちに矯正しろよ
まあ根っから性分だろうからもう手遅れだろうけど
今jsonの話で忙しいのに話の腰を折る荒らしにしか見えない
大学の課題でスペックの条件が必要なの？
うっわ
大学生が処理時間を0秒にできると考えてることが恐怖
まあgitはC#プログラマーでも使ってる人多いし、意味不明な大学の課題よりマシ
c# でもファイル名変更はFile.Moveメソッドだし、考え方は同じだと思うがな。
真面目な話、設問の但し書きの部分を真に受けただけなんでは、とか思うのだけど。
並列処理においてボトルネックになりやすいのがI/O
最近はサーバーで、データベースのCPU が不足する事も多い
C#とJAVAを併用してるけど、C#の解説者のほうが深く理解していて簡潔に解説してるね。
/// 問題点 ///
>>573 前者の例は現実と一緒じゃダメなん？
印刷の機能は書類じゃなくてプリンターの仕事。
後者はどうなんだろう。
自分なら、値型の方が代入比較が簡単で早そうだから、ギリギリまで何でも値型で。
でも、参照型の方がクラス継承とか参照渡しとか出来るから、その時の都合で使う。
機能と性能、仕様と規約、自分の主義で決めたらいいかと。
>>573 お答えしましょう
どこに書いても動きます
好きなところでいいですよ
C#関係ないやね
>>573 1. どういう選択肢があるのかを把握できる力
2. それぞれの選択肢のメリットとデメリットを理解する力
3. 用途に対してより適切な選択肢はどれなのかを判断する力
あらゆる設計判断には上の3つの力が必要だが土台となるのは1と2の力
それらの力をつけるためには考えられる複数の選択肢をそれぞれ簡易実装してみて比較検討するのが一番
失敗を数多く繰り返すのが上達の近道
どのクラスにどの処理をもたせるのがいいのかは用途次第でケースバイケース
one size fits allな答えはないのでやる前からそれを求めていても進歩しない
どっちでもいいからまず作れ
>>573 そういうのはやる前からいろいろ考えるより
「失敗したらやり直せばいい」と考えてとにかくいろいろコードを
書いてみることが大事。
老人より子供の方がスマホなんかの操作を覚えるのが早いけど、
あれと同じだね。
アントニオ猪木のポエムのノリでw
574から579の方々
この前質問したバカですが(一応国公立)
>>581 streamとして必要な分だけ読み込む、圧縮したデータを読み込んで展開する、あらかじめパーツを指定しその配置だけ読み込むなどなど
最初以外C#は関係ないから該当する板でやってくれ
ゲ製作技術
https://mevius.5ch.net/gamedev/ >>581 そのレースゲームがどんなんだか判らないけど、
ゲーム中じゃなくて起動するときに10Gでも100Gでも、
あらかじめ10分かけて読んでおけば良いんじゃないかな。
圧倒的に問題に対する条件が乏しくて、どう考えればいいのかこちらも判らないよ。
>>583 市販のゲームは10分もかかりませんが、何故でしょうか？
地図上の物体検索とかなら
>>584 583は分かりやすく極端な例を出しただけで常識的に考えて10Gのデータ読み込みなんてしないっしょ
大体重めのゲームでも起動時やマップ入場時のロードは500MBくらいじゃね？
つまりそのレースマップ入場時にそこで必要なグラフィックデータを数十秒かけて読み込ませればいい
>>584 君のレス追ってみたけどゲームじゃなくて目的はテキストファイル？
ファイルI/Oにボトルネックがあると思ってるようだけど、テキストファイルだとしたらボトルネックはエンコードにあるんじゃない？
File.ReadAllTextは割とオーバーヘッド大きいから、.NetCore3以上でSpanを利用したエンコードを構築すればいくらか早くなるかもしれない
>>581 自分もゲームまったく知らないので偉そうなことは言えないけど、
いきなりそんな高度な話より、例えば40年前のゲームのスーパーマリオは
たった30kBの中にどうやって32面分オーバーのマップデータを詰め込んだかを
考える方が有益だと思う。
要するに本質はI/Oじゃなくてデータをどうやって圧縮/展開するかじゃないの？
「リアルタイムで（ストレージやネットワークから）読み込み」なんかしてるはずがないと思うけど。
馬鹿は的確な質問ができないってのを凄い的確に示してくれている
ファミコンカセットはROMアドレス指定でCPUからダイレクトアクセス出来る
プレイステーションのすごいところは
サガフロの5連携が3連携で一休みしたりサガフロ2の連携が我々のレベルになると通常と変わらず目で追えたり
>>591 ファミコンはそもそもロード時間ないだろ
>>594 ファミコンやPCエンジンと違ってって自分で言っとるやん
？
>>581 結婚式場を出たら、もう披露宴会場が準備されていました
これを披露宴会場の支度を瞬時に終えたと言うことだと思うか？
MIDIとかMMLの方がたとえ話としては適切だったかな
>>586 10Gは大きいとか目安が分かるのすごいですね。
ゲーム制作者じゃなくてもわかるんですか？
>>587 そうなんですよ。テキストファイルを読んで、特定文字列の抽出カウントを
行いたいわけです。C#じゃなくてC言語なら夢見れますか？
低級感があって爆速なイメージですが。
>>588 難しいですがゲームプログラマが夢なんで、思考自体は高度になりがちです。
まず30kbってのはメモリ領域でですか？磁気領域でですか？
そもそも何でCPUの進化バージョンGPUは存在するのに
HDDの進化バージョンGHDDみたいなのは無いんですかね。
あったら困るんですかね？
うん、C#じゃなくてC言語がいいと思うよ。
高度どころか怠慢な素人丸出しなんだが。
少しずつ積み上げた方がいいという意味を早めに分かった方が良いかと思う・・・
GPUはCPUの進化バージョンではない。
>>600 まだいたんか
ファイルの読出しにGPUが関係するとか変なこと言ってたから素人だとは思うけど
まず
>>602 が言うように足場から固めていった方がいいよ
ゲームは小さい処理の積み重ねなんだし
ファイルIO
データの圧縮展開
CPU/GPU制御
並列制御
アルゴリズム
etc・・・
一人でやるんだったら全部自分で制御しなきゃいけないんだし
このセンスの無さすぎはひどいな
597には応えてくれなかったな
>>600 ストレージの「革新」については15年ぐらい前にこんなのがちょっと話題になった。
だけど、自分が知らないだけかもしれないけどその後の進展を聞かないね。
https://gigazine.net/news/20060710_mram/ NVRAM的な物のコストが下がれば記憶デバイスのカーストの中にある
メモリーとストレージの間の分厚い壁が崩壊するわけで、かなり革命的な
ことなはずなんだけど。
しかしいつもの交通整理の人はこんだけ質問者が罵倒されてるのに何で黙ってるのかね。
それ以前に連休で暇だとしてもなぜこんなみえみえの嵐に付き合うんだよ…
>>607 いやわかりますよ。料理を調理する時間が
HDDアクセスってことですよね？ただ料理と違う部分は、煮えるまで待つとかなくて
目的のものをとってくるだけでいいから、一瞬でその場所にいけたら、
基本的には0秒なんですよね。HDDのシークバーがその場所から動く必要がなければ最速ってことですよね。
すいません、そろそろ去ります。
基本的にC#単独では無理という結論にしました。。。
本人に聞きたいわけじゃないのだが、基本的に０秒ってどういう意味なんだろう
HDDの代わりにGPUにデータファイルを置けば速いって意味だろ
その後に思ったことなんだけど、ファイルI/O 以外の処理速度が気になる。
>>612 君は面白いおもちゃだな
実際に1秒で100MBでしか読めなかったらそれを使ってどうやって派手だったりリアルな画面を作ってやろうかと思うのが
PGやゲーム制作者です
ハードに自分の要望を求めるのは単なる消費者です
昔はもっと制約が厳しかった
自分たちは子供のころからそればかり考えてた
あおりでもなんでもなくあなたには向いていません
いわゆる「ロード中」っていう処理待ちをさせずマップ切り替えが可能なゲームがあったけど、そういう話かな。
そもそもPCのマザボに
まぁ自作したことすらない子も多い。
>>618 そお？
動作を「速く見せる」ための制約条件としては確実に必要な要素なんだけどね。
いまさらだけど。
>>624 SCSIなんか知らなくて当然だし別に何も問題ないと思うよ
むしろ「お前らこんなの知らないだろう」オジサンの方が問題だw
もうISAやCバスだって知らない人の方が多いよね。下手したらAGPも
その辺の事務や営業じゃなくて、コンピュータハード作ろうという子がバリバリ現役のスカジー知らんとか相当不勉強なんだけとw
>>628 SCSiが現役な程度にはISAバスだって一部の産業用途で現役だけど、
さすがにあなたもISA知らんのは不勉強とか言わんでしょ（笑）
要するにそれ自分中心主義なんだよ
そういうおじさんみっともないよマジで
一部業界でしか生き残っていないものを知らなくて当然
コンシューマゲーム機だとSCSI使ってたのは、ドリームキャストとかGBAの世代までだったなー
「SCSIを知ってる」ってどのレベルでのことを言ってるんだろう。
SCSIは抽象化されて残ってるじゃん
抽象化や隠蔽化の進んでいない下のレイヤーの話としてのSCSIケーブルだから
それは今の必須知識じゃないからね
> C#に関係の無い話題や荒らしの相手や罵倒レスや酔っぱらいレスはやめてください
インターフェースって継承以外でインスタンス化してフィールドに持たせるように使う場合があるけど、それって違う場所に定義している関数を呼び出して使うような感じ？
「コントロールがきかない、再コンパイル依頼が効かない」第三者にバイナリのdllを公開してかつ、3年5年と更新しつづけていけばいやでもわかる。
オブジェクト指向の言語やってて、デザインパターンの勉強しない奴とか居るんだな。
それぐらいなら別にinterface要らんけどな
>>638 実装を入れ替え可能にするために使う
インターフェースを使う側はインターフェースがどう実装されてるかを気にしない
関心事の分離や責務の分割というやつ
public class CustomerService
{
private readonly ICustomerRepository customerRepository;
public CustomerService(ICustomerRepository customerRepository)
{
this.customerRepository = customerRepository;
}
}
CustomerServiceはcustomerRepositoryがどういう永続化技術を使ってるか関知しない
RDBMSを使った実装からKVSを使った実装に変更したとしてもCustomerServiceクラスは変更する必要がない
単一責任の原則や依存性逆転の原則というオブジェクト指向設計の基本原則に従ってる
>>638 全然違うものを透過的に扱いたい場合ってあるでしょ？
例えばビデオゲームで入力デバイスとしてゲームコントローラーだけでなく、
キーボードやタッチパネルも使えるようにしたいとか。
とりあえずはInterfaceはそういう要求を満たすためのものだと
理解しておけばいいよ。それ「だけ」ではないけどね
汎用性を高めるためって考えた方が分かりやすいかもね。
関数を渡すとしても、引数なり戻り値なりの型を定義しないとならんしな。
>>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では
>>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批判にも「構造体でも同じことが実現できる」ってのがあった。
そりゃできるに決まってるが、そういう批判には無理してそうやって
書いたコードが果たして人に理解しやすいのか、
人間の認知能力に親和的なのか、という視点が欠けていた。
おじいちゃんこないだから暴れ過ぎ
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が不要なメソッドってのも意味がわからんのだがな。
ここはC#初心者のためのスレのはずなんだけど
構う奴もガイジって20年前から言われてるはずだがいい加減学習できないのかねチンパン君
昨日は触れなかったけど、関数のメリットの中でも特に大きいのは、テストのしやすさね
まあ１対１のインターフェースは要らないな
都合の良いラムダを渡すだけ。
>>677 それ関数でいいよ
>>678 意味不明
どう意味不明なのかマジでわからん。
>>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。
具象クラスのメソッドが呼びたい時はアサーションするよね、
無駄をなくしたとかシンプルにしたとか言ってるけど、言語仕様側で受け持ってた制約を無駄と評して人任せにしただけに感じてしまう
その関数のシグニチャを定義して強制するのがインターフェイスじゃないのかね
そう。結局インターフェイスのこと言ってるの。基底になるオブジェクトとかそういう話になるだろうけど。
>>682 それを許すならコールバックのがいいなー
結局、実装見てみないとそいつらってわかんなくない？
MSが作ったメソッドなら実装されているだろう多分って言えるけど
それって組む人間の信頼性の話でさ
昔のデバイスコンテキストみたいに
え？解放されてんの？されてないの？
どっち？
みたいなのソースから無駄にわからんじゃん
こういうの欠陥品として捨てていくべきだと思うよ俺は
>>693 コールバックはどうかなぁ。
それこそ、呼んでくれるかどうかわからんくない？
例外のハンドリングがいよいよ大変になるから、async awaitみたいにうまく隠蔽してくれる方が良いかなぁ。
確かにまぁ、開放したはずが開放できてなくて再起動するはめになったりしたし、わからんでもないけど、それこそIDisposableなんかでハンドリングした方が良いんじゃないかな。
>>694 ぶっちゃけよんでるかどうかわからんのは退化だと思う
デリゲートvsインターフェースの戦いはつまるところ気軽に使いたい派vs丁寧に型付けしたい派の宗教戦争なのだろうな
>>696 むしろこうだね、
適材適所派 vs. バカの一つ覚え
あるいは
常識派 vs. 俺だけがネットde真実に覚醒したんだ！！派
単純に、7割位のケースで有効な方法が、銀の弾丸な気がする時期じゃない？
循環参照だけど、例えば、FileLoggerと、StreamWriterみたいなクラスがあるとして、両方別アセンブリになってて、
Action<string> logなりAction<string> writeLineなり必要な関数を引数で渡すだけ
>>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の方が楽だと思う。
なんか「こうすると後始末が楽」ってのと、「これてもできる」ってのは違うと思うんだが。
意味不明と言い続けてたのも、
全く解決になってない方法をゴリ押しすんのも、
もしかして、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をどういう関数にするかまだ答え貰ってないけど、どうするつもり？
宗教戦争じみてきたけど、絶対にインターフェイスは要らないって言いたいだけ？
実を言うとね
そもそも論だが、モックフレームワーク自体がまず必須ではない。
>>709 短くて大量のモックラムダの定義は常にテストと共にあり、全てが目に見えて、嘘も隠し事もなく、理解容易だ
モックオブジェクトの大群は全てが隠蔽されており、その実体はお世辞にも理解しやすいとは言えない黒魔術で構成されている
モックオブジェクトを扱う人間はモックオブジェクト独特の世界観を深く理解し、信仰しなければならない
僕らはただ楽に単純明快なテストを書きたいだけなのに…
>>712 自分で作れば、モックオブジェクトも別に隠蔽されてないし、理解しづらくも無いんだが。
必要十分なものを作れば良いと思うよ。
なんかフレームワークに振り回された思い出があるの？
それは俺にもあるからわからんでもない。
これ回線2つ使った自演芸やんけ
>>711 何故モックフレームワークのような出来損ないが、世の人々にありがたがられているか理解してる？
モックフレームワークを使わなければいいと、言うだけなら簡単だよ
でもねその代償に今度は、大量のモッククラスを書かなければならなくなるんだ
世の人々はそんな大量のモッククラスを書くのは嫌だ、ということでモックフレームワークを作ったんだ
苦肉の策だったんだろうけど、世の人々は薄々疑問を感じながらも自分を納得させてモックフレームワークを受け入れた
大量のクラスを書くよりは、たぶんマシだから
さてなんでこうなってしまったか、根本原因はもうわかるね？
依存性分離のためにインターフェースを採用しちゃったからだよ
インターフェースに実装を与えるのは、関数と比べるとものすごい労力かかるんだね
ID:9VBk1Szv0
ID:/WM42vypM
いい加減議論スレへ行け
ふらっと C#,C♯,C＃（議論用） [無断転載禁止]©2ch.net
http://2chb.net/r/tech/1469538912/ >>714 違うぞ。
>>715 やり方が悪い。そして関数のシグニチャはインターフェイスそのもの。
>>716 すまん、そんなスレあったのな。
ありがとう。
まあ水掛け論だろうし、もうやめとくわ。
>>713 僕らはテストを書きたいんだ
大量のモッククラスを書きたいわけでもない
モックフレームワークを自作したいわけでもない
モックフレームワークを利用して疲弊したいわけでもない
僕らはただたんにテストを書きたいんだ
ま、インターフェースなんかいらんな
属性のメリットが全然わからなくてとまどってる
>>720 組み込み属性以外だと、リフレクションでメソッドなりクラスなりを探すときに、特定のAttributeがついてるものを対象にしたり、呼び出し元に特定のAttributeがついてるかをコールスタックから探したりするためのものでは？
あとはAttributeUsageAttributeで制限かけたりかなぁ。
属性は、
>>720 属性はメタプログラミングで利用するもの
C#ではダイナミックに型情報にアクセスすることできるが、属性はその型情報に”お好みのラベル”を付与するための機構だ
ただラベルを貼り付けるだけではなんの意味もない
ラベルを解釈して振る舞いを変えるクライアントプログラムを作ることで、初めて属性に意味が生じる
同じ事をあちこちでやってるけど、クラスや関数など従来の言語基盤ではモジュール化しにくいもの
いわゆるアスペクトというものをモジュール化するための道具として使われることが多い
またIDEを初めとする周辺ツールなどからも参照できるためツールの拡張などに使われることも多い
はっきり言って泥臭い、洗練された機構ではないのでメンテナンスは大変だが、ただの利用者の立場では便利なものだ
python、TypeScriptなどでは属性より柔軟性は低いものの十分な効果が得られ、より理解、実装が容易なデコレータというアイデアが導入された(ちなみにこれは関数を受け取り関数を返す関数だ)
C#にもデコレータがあれば良いのだが……まだまだ遅れてるね
同じものってどこかに書いたっけ？
で、デコレータでどうやって開発時にObsoleteのようにメッセージを出すんだ？
俺がいつデコレータで開発時メッセージを出す話をしたのかな？
質問者は”属性の有用性が理解できない”と聞いてきてる
質問自体が”開発時メッセージを表示させたい、コントロールしたいがどうすればいいか”だったら、デコレータの話はなかっただろう
いや質問者はObsoleteのようなことがやりたくて属性を調べたけど結局何ができる機能なのかよく分からなかったと言ってるだろ
この文脈で
>>724 のように書かれたらデコレータでならやりたいことができると質問者が誤解してもおかしくない
不適切というか意地悪な回答だと思うぞ
お前が俺を攻撃したいのはわかったが、もう少し冷静に考えてから攻撃したらどうだ？
属性とデコレータは似てるようで全然違うので、同列に扱うのがよくわからん。
>>733 攻撃したいんじゃなくて、間違ってる。
頭でっかちでしかない。
>>734 2回目だが同じとは誰も言ってないぞ
(アスペクト指向という)目的を達する手段が複数あり、片方がより洗練されていると言ったんだ
なぜこれで”属性とデコレータが同じものだ”になるのか理解し難い
>>736 誰もアスペクト指向の話は求めてないし、アスペクト指向にも使えるのは事実だが、アスペクト指向のためだけのものではない。
属性は属性。
Webフレームワークのパンドラとかロガーみたいな、特定のアスペクト指向に使う用途しか知らないならそう言いなよ。
データバリデーションのIndexやRequired、シリアライズのJsonPropertyとかColumnなんかは、別にアスペクト指向として割り込むためのものでも集約するためのものでもない。
>>737 はぁ…何度目だ？
質問者は明にアスペクト指向の話を求めているわけではないが、属性の有用性についてコメントを求めている
で、あるならば属性の利用形態として大きなウェイトを占めるアスペクト指向について、言及しないわけにはいかない
属性は単なるラベルであり、クライアントによって様々な利用形態が考えられることは、俺が先に説明した通り
そうか？
>>739 属性の有用性はそれ以前の問題。
アスペクト指向に属性は実際問題必須ではない。
インターフェイスは要るがなw
単なるラベルであり様々な利用形態が、ってのは、わかってる相手に説明する方法であって、全く知らない人間に対しては何の説明でもない。せめてググるためのワードを出せよ。
初心者にまったく役に立たない話はここでしなきゃいいのでは？
別にね、アスペクト指向はルールベースでも良いのよ。
>>741 属性はAOPに必須ではないが、ないと非常に大雑把な実装になり、挙動のコントロールが難しくなるため、実用上はほぼ必須だよ
太平洋横断に船は必須ではない、と言うようなものだ、最後の旅にならないといいね
いやいや、何もわかってない人にこそ、属性とはただのラベルでしかない、と説明したほうがいい
ただのラベルということを理解してないと、元の質問者のように属性には開発者メッセージを出力したり、色んなことができる、なにか不思議な力がある魔法の道具なのかな、と誤って認識してしまうんだ
1. 属性には本当にラベル以上の意味は何もないし、何もしない
2. 何かするのは、そのラベルを見て処理をするクライアントプログラム
3. 何をするかは、そのクライアントプログラム次第で全く異なる
これが属性の基本の基本な
このシンプルな3つの事実を教えないで、有耶無耶にはぐらかすと、初心者が属性を理解できなくなってしまう
ほぼ必須といったのは誤解を生むかもしれないな
だから、そんな話はしてないの。AOPとか。
ふらっと C#,C♯,C＃（議論用） [無断転載禁止]©2ch.net
http://2chb.net/r/tech/1469538912/ >>746 >属性はただのラベルではない。
>誰かが読み取るためのラベル。
それをただのラベルっていうんだよ
読み取る側がそのラベルを見て何らかの作用を起こすまではなにもしない
まさにただのラベルだな
お前の理想以外聞き入れないなら、ブーメランでもなんでもないわ。
>>723 ビルド時にカスタムのエラーや警告を出したいなら
Code Analyzer使って属性をチェックすればいい
昨日は頭のおかしい人が大活躍してたみたいだな
WebClient使ってWebサイトのhtmlを文字列として取得したいんですが、
>>757 HttpClientクラス使った方が良いと思うけど
WebClientクラスの場合は、GetWebRequest()をオーバライドして
WebRequest.TimeoutプロパティとHttpWebRequest.ReadWriteTimeoutプロパティを設定
>>760 ありがとうございます。
>GetWebRequest()をオーバライド
は既に試したんですが、相変わらずエラーで中断します。
>HttpClientクラス使った方が良いと思うけど
それは何故でしょうか？
DLしたいサイトのURL教えてもらっただけでだいぶはかどるよね。
デフォルトだとタイムアウトが足りてないだけなんじゃないの?
> 途中でエラーします。
>>764 ふたばってもう誰も見てないだろうけどどんな理由で攻撃してくるの？
#region って使わない方が良いのですか？
好きにしたらいいよ
ウザい
レガシーコード解読してるときに、コメントがてら一先ずregion使った
#region使わんといけないほどになったらクラス分けてほしいな
分ける方向がクソなときにウザい
>>780 身もふたもないけど使い方次第だね。
#regionディレクティブはコードを分類するのとあまり見る必要がないコードを隠すのに
使えるけど、後者の使い方はあまり必要がない
自分はデカいクラスでMSのドキュメントみたいにメンバーを種類ごとに分類するのに使ったり、
ある程度以上の規模のFormで例えばメニューのイベントハンドラを分類するのに使ってる
private隠す#regionは使うけどな。どのへんがダメ？
隠したくなるということは、隠さないと鬱陶しいぐらい長いコード、ということだから、そのあたりだろうね
呼び出し階層を無視して十把一絡げに「private」だけで括ろうとするのはどうかなとは思う
コードスメル的な意味かな？具体的に何が悪いのかよくわからんけど。
/// <summary>
>>794 ぉぉ、コメントも継承できるんですね。
ありがとうございます、やってみます。
>>789 privateの意味を誤解してる気が
privateの意味はそのコードを利用する側の人は見る必要がないって意味だよね？
ソースコードを見てる人はその時点で「利用する側」か？
普通は違うよね？書く側の人に対して隠す意味は普通はない。
もちろん「まず見る必要がないから畳んでおきたい」需要が絶対にないとまでは言い切れんとは思うけど。
ちなみに、VSのエディタにはメソッドのシグネチャ以外の部分を畳む機能もあるけど俺はあれは嫌い。
>>797 あー、それそれ。併用してCのヘッダみたいにして見てる。
ヘッダ代わりに毎回インターフェースを定義するのも面倒だしね。
長大なメソッドの中身をregion使って折りたたんだら短く見えるからいいよね
コンストラクタとかで引数チェックする場合ってDebug.Asset使う？ ifと組み合わせて例外投げる？
macOSに新しい.NET Core SDK/ .Net 5 SDKを入れ続けていると、何バージョン分もディレクトリが掘られて増えていきます
ありがとうございますm(_ _)m
>>800 コンストラクタで例外投げたくないな
引数はフィールドにセットするだけでそれ以外は基本しない
検証するなら別のメソッドにするかコンストラクタ隠蔽して検証しつつインスタンス返すstaticなメソッド作る
>>800 普通にifで調べて、普通に例外を投げてくれ
引数がおかしいならArgumentExceptionとか適当なのあるでしょ
引数が増えるとifを書くのがしんどくなるかもしれないが、そのときは関数化しよう
そもそもDebug.Assertは滅多に使わないものと考えていい
デバッグビルドとリリースビルドで挙動が違うというのは、それだけで本番でしか発生しないバグを生みかねないものなので、可能な限り避けるべきだ
コンストラクタで例外を投げたくないとか言ってる人は、気にしなくていい
昔はそういう流派もあったんだな、とでも考えてくれ
.net frameworkのコンストラクタでもそうやってた
コンストラクタで例外投げろ
UnhandledExceptionの処理やるだろうしコンストラクタで例外投げてもいいと思うけどね
9.0のrecordってデータベースとのやり取りに使うシンプルなクラスには積極的に使っていったほうがええんかね？
単純計算の時間って完全に比例するんですか？
コンストラクタで例外投げるかどうかは宗教論争感あると思うので棚上げにしてます。質問が悪かったです
自分が聞きたいことはDebugあるいはTraceのAssertメソッドの使い所でした
>>806 使い所ないんですかね
どんな値が渡されるのかわからない関数などは例外処理、その逆（外部に公開しない関数）の値チェックになら使えそうなのかなと思ったんですが
.Net1.1やその前からあるみたいなので、テストフレームワークが流通してないころに使われてた過去の遺産なのかな
>>812 汎用PCの場合
速度なんか測ったって
その場合はそうだったんだろとしか言いようがない
裏でウィルスバスターや
セキュリティソフトや
会社の監視ソフト
WindowsUpdateなど
色んな複合要素がありすぎてみんな速度なんか測るのやめちまったよ
>>813 検証処理が非常に高価な場合はDebug.Assertを使う理由にならんこともないが、そんなことは滅多にないよ
ほとんどの場合、検証は安価であり本番で検証をスルーしてしまうリスクとは比べるまでもない
C言語のようにほんの些細なオーバーヘッドすら嫌うような言語とは考え方が違う
そもそもアサーションをいつの段階で期待してんだ
Debug.Assert()はバグってる原因を探る時に、想定通りの値になっているかを確認する時に使うな
803だけど昔「コンストラクタで例外投げたりアカンぞ」みたいなことを本で読んだ記憶があったんだがいま読み返したら完全に自分の記憶違いだった 申し訳ない
職場でExcelVBAとACCESSをある程度動かせるようになったので、ステップアップしてC#を勉強してみたい。
2D格闘ゲームって3Dのapiがなくても作成可能ですか？
誰か助けて。WebView2を使ったプログラムなんだけど
>>820 速度イラネってなら別だが、2Dでも細かい事やろうとするとC#の手に余る
せめて描画エンジンはC/C++で書いた方がいい
原因が分かった。プロジェクトのディレクトリを移動すると動かなくなるみたい。
>>823 WebView2ランタイムが見つからないんだとエスパーすると、
ソース内でWebView2ランタイムの場所指定してるとこ要チェック。
>>819 c#でググるとすぐ出てくる入門サイト。
何故かというと、今後も何か調べるときにすぐ出てくるサイトだから。
>>819 ネットで漁る
独習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#ではコンストラクタで例外が出るとファイナライザが呼ばれないことから
>>833 例外投げるなら、その前に既にnewしたものを全部綺麗にDisposeしなきゃいけないわけだけど
そこまで考慮して正しく実装されたコンストラクタなんてドカタのコードで見たことないな
自分でthrowしなくても呼び出し先から例外が飛んでくるケースもあるから、本来は常に考慮が必要
あくまで可能性の問題としてだけど、コンストラクタで例外を投げるとDispose漏れが起こりやすいのは事実だと思うよ
漏れを完全に防げなくても、GC任せで問題にならない程度に頻度を抑えることはできる
>>836-837 ちょっと何いってるのかわからないw
>>838 なるほどね。
コンストラクタで例外投げてもほとんどの場合
問題がないことはよくわかったけど、
それでも個人的にはやっぱり避けるかな。
コンストラクタで例外が飛んでくることを想定してないプログラマが多い気がするから。
あえて違和感を感じさせるためにファクトリーにすると思う。
まあ屁のツッパリ程度の効果しかない気もするが。
>>836 プログラマが内部的にありえないと考えている状態が実際に発生するかしないかはプログラマにはわからない
それがバグというものの性質だ
バグはプログラマの意識の外からやってくる
プログラマが間違えるからバグが発生する
なので絶対に起こらないから本番では外しちゃえなどと安易に考えずに
俺の考えではまあまず起こらないと思うけどもし起こったらやばいから念の為に残しておこうと考えたほうがよい
>>838 .NET 5以降ではCERが廃止されたからSafeHandleは意味ないよ
ちなみに.NET Framework(非Core系)でもCriticalFinalizerObjectに意味があるのは複数のAppDomainを使ったアプリケーションの場合だけだよ
また空中戦やってるな
いや客ってのがユーザーのことなら例外処理なんて客と無関係な純粋に技術的な問題でしょw
>>842 SafeHandleはCERのためのものではなく
アンマネージドリソースハンドルのラッパーを提供するための共通基盤でありCER対応はその部分でしかない
SafeHandleは依然として有用だよ
初心者は参考にするといい
https://docs.microsoft.com/ja-jp/dotnet/standard/garbage-collection/implementing-dispose もちろんオレオレハンドルラッパーをDIYしたいならそれを止める権利は俺にはない
>>846 それは眉唾だな
docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.safehandle?view=net-5.0
例えばこのサンプル、SafeHandle派生クラスを実装した上で更にそれを適切に解放するために普通にDisposeパターンを実装してる。
これが典型的な正しいSafeHandleの使い方だ。
CERが無いなら手間とミスしうるポイントが余計に増えるだけにしか俺には思えないね。
newしたものが綺麗にdisposeされないって馬鹿のコードだろ
.netの内部でもこんな感じで普通にコンストラクタで例外投げてる
>>851 ArgumentExceptionは開発時のバグであり、ソースの修正が必要だ
そのまま実行を継続すべきものではないから、リソースの開放漏れ云々は全く関係ない
コンストラクタで例外は投げても良い
>>849 プラットフォーム呼び出し時の参照カウントなどはどうする?
クラスとかメソッドとか分けるときの命名が大変で時間が掛かるお…
>>857 俺は命名には
https://codic.jp/engine 使ってる
文字数減らすためじゃなくて、英語力不足を補うためだけどｗ
50文字超えることはあんまりないかなぁ。
>>800 自分は投げますね
MSが作ったデフォのクラスにも投げてるやつあったと思うのでそれを言い訳にしてます
引数エラー一個一個出してくわけには行かない場合例外だと処理しにくいな
コメント打つ代わりにフルスペルで命名するっていう手もあるよね。
命名に悩んで手が止まるのアホらしいので、一旦日本語で命名して後で英語に変えてる
下手に英語やローマ字使うより日本のプロパティ名を使った方が分かり易いこともありますな
>>866 どんな場面を想定しているのか、すげぇ気になる
enumの要素が日本語だとコメント要らずではある
国民健康保険保険者番号、という単語を変数名にするときは、だいぶ議論した上で、
英語力がボトルネックになってるケースはむしろ少ない気がするね。
>>841 良い心掛けをお持ちですね
大事になすってください
>>869 プロジェクト全体で使えるならnhi_insurer_numberみたいな略語ならありだと思うけどね
グロサリーは作った方がいいけどNHIで辞書に載ってるから（普通何だこれと思ったらググるよね？）
俺も別に良いと思ったんだけど、とにかく反発がやばかった。
kokuho_hnoだと保険者番号と被保険者番号の区別がつけにくいので
変数名は単体で使ってるのか？
>>877 被保険者番号はhhnoという悲しいスタイルに。。
>>876 識別のために割り当てる符号は数字だろうがギリシャ文字だろうがID(identifier)でしょうw
ただ、保険者（業者）と被保険者を区別する必要があることに気づかなかった
この場合NhiIDはまずいね
まあスレ違い甚だしいな
hhnoかぁ
被保険者番号みたいなのは
基底クラスで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);
class作ってメンバでconst intにしようと思ったら
enumは基本的に定数をならべただけだから不変のものにしか使っちゃだめ
>>894 不変よ
少なくともプログラムが実行されてからは
だって状態を表してるんだから
変更が必要になるのは継承で分岐するソースコードの修正作業時だけ
こういう形でenumが使えないなら
今後継承を行う可能性が少しでもあるならそのクラスではenumは一切使えないということ
実際使わないほうがいいと思う
赤青ランプを継承して
赤青黃ランプを作ったときに
状態赤青がenumで作られてたらゴミ箱にブチ込むしか道はない
挿入文字列はコンパイル時に解析される（実行時に解析されるわけじゃない）と思うので（知らんけど）
>>895 enumの定義をclassの外に出して独立させれば
>>898 赤青黄と赤青緑に継承で分岐したとき
どんなenum定義するって言ってる？
>>900 派生元も派生先も関係なく1つのenumで定義すればって意味で書いた
使う時はプロパティやメソッドでそのクラスで利用可能な値かをチェック
だからそもそも根本的に考え方がおかしいと思うよw
>>895 赤青ランプを継承して赤青黄ランプを作るってのがそもそも筋が悪いだろう
N色ランプを作って赤青でも虹色でも好きに作ればいい
は？設計書にそう書いてあって
普通そう言う場合enum使わんしょ
>>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って定義をやめよう
>>895 不変っていうのは、実行時に変わらないって意味じゃないぞ
修正／機能追加でも変わらないってことだ
結論としては自分で書いてる通り
>今後継承を行う可能性が少しでもあるならそのクラスではenumは一切使えない
だよ。Enum継承したいってことはつまり変更したいってことだから
Color.RedやColor.BlueはEnumじゃないだろ
まあSystem.Drawing.Colorは構造体で継承できなかった気がするけど
そんな感じで作っとけ
>>915 話が通じない人だなw
問題はenumにあるんじゃない。
>>902 にはどこにもenumなんか出てきてないでしょw
汎化するのに継承を使うのがおかしい。
継承は特化するのに使うんだってw
どれの話をしてるのかわからんけど困ったことない
>>917 そんなの未来永劫保証できないじゃん
enum作った人本当にバカなんだね
使えないもん作ってろよって感じ
>>921 別に俺が作ってる訳じゃないからそんなこと言われても知らんがな
enumでやりたくないならそれでいいと思うし好きにやりなよ
>>919 enumの利点はコンパイル時に名前の集合を型として定義できる、
名前の集合が確定していて、だからインテリセンスが使えたり
集合に含まれないはずの名前が使われている間違いをコンパイル時に検出できることなので
それは代用にならんでしょ。
質問している人の問題はたぶん継承に固執してること。
部分集合を再利用して上位集合を定義したいって問題意識は分からんでもないけど、
emumなんてただの名前の集合なんだからそういう場合はコピペ継承するのが多分正解。
C#や諸々の言語はそもそも、継承の仕様が出来損ないなんだよね
>>923 ああ、そういう事ね
Nullとか空とかのEnumを用意しとくべきかみたいな話と似てるな
>>925 Javaのことは知らんけど
C#のsealed classでは駄目なの
自分ならカスタム属性と拡張メソッド作って、集合.Hoge.Colors()で一覧を取れるようにするかな
>>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));
みたいな使い方するほうがいいんじゃ
プラごみを減らすためにレジ袋有料化するって話と似てるな
リソースで他言語対応すると考えると欲しい気持ちは分かる
All your base are belong to us
evalをやりたいと言うことだな
c#ってvisual studioインストールしたときに入ってるコンパイラじゃなくて
なんで今更感が半端ない
今まで記載がずっとなくて、同じMicrosoftの子会社が出してるStylecopっていうコード解析ツールの言ってることなら正しいだろうって風潮だったんだけど逆転敗訴した感じ
前までただのキャメルだったよな？ 何かしっくりこないなあと思いつつあわせてたのに
というか
>>942 はちゃんとprivateのメンバ変数って書いてくれ
俺は今まで通り m_ + PascalCase でいく
キャメルケースの事をキャメルって略すのはどうも抵抗がある
スコープで付けると便利だけどね
>>942 さすがにアホなガイドラインでほとんど同意は得られない気がする。
バッキングフィールド限定なら少なくとも俺は賛成するけど。
まあ、普通のフィルドもバッキングフィールドも出番減ってるから
どうでもいいと言えばどうでもいいかも
アンダースコアはライブラリと被った記憶
ぶっちゃけ客先のカスタマイズできない環境で文字ちっちゃくて見にくいときあるからイラネ
しかし、_でプリフィクスしとくとインテリセンスでフィールドが一覧できて便利だよ、
>>953 そのコメントどこに書いてある？
ところで別の話なんだけど、
とあるデータの集計や加工をメソッドチェーンで書きたい考えと、その集計や加工をデータとは別のクラスかつステートレスで書きたい考えって両立できるのかな？
拡張メソッド使うくらい？
>>954 コンテナ(データ).加工(…).集計(…)
インスタンスメソッドは暗黙的にthisを使ってるのでステートレスじゃないってことなら拡張メソッドも同じじゃない？
オセロのプログラム作っています。
>>946 publicなメンバ変数って一般的か？
>>956 半透明の影を書き込んだ画像と影なしの画像の2種類を用意しといて切り替えたらいい
それ以上を求めるならFormsなんか捨ててちゃんとゲーム作りとしてUnityとかに再入門した方がいいよ
>>956 あくまでもWinFormでやるならGDI+っていう機能を調べて、
円をキャンバスに描けばオセロ程度のアプリケーションを作るのは楽かもね。
そりゃあ本気でｹﾞｰﾑ作るならUnityだろうけど、
オセロの内容にこだわるなら、コンソールで十分なんだけど。
>>946 いや、そもそもそんなコーディングガイドラインは存在しなかった。各ツールやライブラリごとに好き勝手やってる
あと、privateだけじゃなくてinternalもな
>>956 「オセロが盤面にの上にくる」っていうのがどういう状況かよく分からんのだけど、
プレーヤーが置いた位置まで石が移動するアニメーション的な演出をしたいってこと？
m_とかアンダースコアつけるとかは原始人に見えてしまう
フィールドにmつけるのは割とそんな悪い習慣じゃないと思うけどアンダースコアは要らんね
フィールドにメンバーの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_でも_でもいいから統一してくれればいいかなあ
ほんまそれなんやが
c#のprivateメンバー変数にアンダースコア付けろだと…
ゴミカスが普段組んでもいないのにいいと思って考えちゃったクソルール
一般的にって根拠を示しにくいけど、Microsoft公認のコーディングルールって言うとStylecopが示しているキャメルケースしかありえないんだよな
>>985 _Hogeじゃなくて_hogeな
MS自身が書くコードでは昔から一般的に使われてるルールなんで、そんなに驚くほどのことでもない
意識高いとこだとわりと採用されてるよ
いま入門書で勉強中の初心者です
そんなん言うたら、呼び出すメソッドが別ファイルの別クラスにあるのはいいんか？っちゅう話だよな。
>>987 さすがにs_を標準にしちゃうのはかなり疑問だけどね
>>988 多くの場合「全体 -> 部分」の順で理解したほうが
「部分 -> 全体」の順で理解するよりも圧倒的に脳にやさしいので
コードの構造もそれに合わせることで読みやすくしてる
>>988 呼び出し元を上から下に進んで
呼び出し先に亜空間ワープして
呼び出し先を上から下に進んで
呼び出し先が終わったらまた亜空間ワープで呼び出し元に戻って
呼び出し元をまた上から下に進む
>>988 昔のC言語は呼び出す前に関数宣言しておくか関数を定義しないとエラーだったから考え方は正しいよ
単にプログラム言語としての利便性が上がっただけ
前方参照が不可でプロトタイプ宣言が必要だったのは単に当時の技術的な制約に過ぎず
最近の言語だとどこでも関数宣言できるし、かと言って関数内だと一番下で宣言した関数を上で使えるって訳でもない場合もあるからね
>>988 呼び出される側のあとに呼び出す側のコードが書かれていても
> コードは基本的に上から下に処理されていくと理解しているのですが
ならしっくり来なくね？
Pythonみたいに動的に関数定義したいということかな？
このスレッドは１０００を超えました。
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/ ▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
このスレへの固定リンク： http://5chb.net/r/tech/1616471904/ ヒント： 5chスレのurlに http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。 TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「ふらっと C#,C♯,C＃（初心者用） Part150 YouTube動画>1本 ->画像>1枚 」 を見た人も見ています：・ふらっと C#,C♯,C＃（初心者用） Part152 ふらっと C#,C♯,C＃（初心者用） Part160 ふらっと C#,C♯,C＃（初心者用） Part139 ふらっと C#,C♯,C＃（初心者用） Part134 ふらっと C#,C♯,C＃（初心者用） Part154 ふらっと C#,C♯,C＃（初心者用） Part155 ふらっと C#,C♯,C＃（初心者用） Part159 ふらっと C#,C♯,C＃（初心者用） Part147 ふらっと C#,C♯,C＃（初心者用） Part148 ふらっと C#,C♯,C＃（初心者用） Part121 ふらっと C#,C♯,C＃（初心者用） Part149 ふらっと C#,C♯,C＃（初心者用） Part119 ふらっと C#,C♯,C＃（初心者用） Part151 ふらっと C#,C♯,C＃（初心者用） Part148 ふらっと C#,C♯,C＃（初心者用） Part143 ふらっと C#,C♯,C＃（初心者用） Part129 ふらっと C#,C♯,C＃（初心者用） Part132 ふらっと C#,C♯,C＃（初心者用） Part133 ふらっと C#,C♯,C＃（初心者用） Part141 ふらっと C#,C♯,C＃（初心者用） Part138 ふらっと C#,C♯,C＃（初心者用） Part128 [無断転載禁止] ふらっとC#,C♯,C＃（初心者用） Part92 ふらっとC#,C♯,C＃（初心者用） Part88 ふらっと Q#,Q♯,Q＃（初心者用） Part 1 何か楽しい教本・曲集ないの？（初心者用） ブラックなベンチャーについて語るスレ（初心者用） C#でゲームを開発したいんだけど、、、（初心者） ■第二回ParaFla！初心者教室 ■ 詰めチェス部（初心者歓迎） くだすれFORTRAN（超初心者用）その7 （初心者向け）ニー速の楽しみ方 女（初心者）だけど、耳コピします 街コン行く人集まれ（初心者向け）Part5 【PSO2】初心者を追い出せ！初心者潰し4つの秘技 キックボクサーのスレ（初心者＆中級者歓迎） 【将棋】藤井聡太七段初監修！初心者向けSwitch用「棋士・藤井聡太の将棋トレーニング」発売決定 お前らって何年も描いてるやつと数ヵ月の初心者比べて絵の才能ないとか言って恥ずかしくないの？ くだすれAjax（超初心者用） くだすれFORTRAN（超初心者用）その6 線形代数（初心者レベルから中級まで） くだすれDelphi（超初心者用）その１6 超初心者女装っ子いらっしゃい（大阪） ヘッドバンキング初心者なのですが玄人の方いらっしゃいましたらちょっとアドバイスいただけないでしょうか 初心者にありがちなこと FF11初心者にありがちなこと 初心者のころ勘違いしていたこと テニヌ初心者にありがちなこと 自炊初心者になって気付くこと キャンプ初心者にありがちなこと ＴＯＥＩＣ初心者にありがちなこと MoE初心者がやっておくべきこと day3 ポケモン初心者が考えそうなこと TOEIC初心者が知っておくべきこと 初心者のころ勘違いしていたこと ★２ 競馬初心者の皆藤愛子をオレたちの立場に置き換えると キャンプ初心者にありがちなこと Part.3 初心者卒業したての戦闘機ファンにありがちなこと 【芸人】天津・向が解説 アニメ初心者が知っておきたい人気女性声優6人 花澤香菜、内田真礼、三森すずこ、早見沙織… #はと [muffin★] C＃初心者に教えてくれ～～ 0からの、超初心者C#相談室 プログラミング初心者はC#から学ぼう ガチのプログラミング初心者なんだがいきなりC#ってヤバいのか？ 初心者 初心者
22:11:58 up 66 days, 23:10, 1 user, load average: 8.13, 9.52, 9.35
in 0.20705795288086 sec
@0.20705795288086@0b7 on 062311
ブックマークへ