並列にしてるのが思い込みらしいから放置でいいよ やってみねぇでやろうとしちゃうんだな
情報サイト教えて下さい 例えば、 int型の連番配列全てを(for文,等を使わずに)文字列にしたり 一発で配列内の位置を特定して抜き出してから削除する(通常のコードとは違う方法) 便利な命令文とか教えて欲しいです。
>>4 何がしたいの? 10年以上やってる俺が必要だと思えない機能なので多分やりたいことが間違ってると思う ビジアルC#(フォームアプリケーション)でトランプゲーム作ってます。 その為に、配列操作を簡潔にしたいと考えてます。 ボタン入力→コンソールで操作→コンソールから値を受けとる→画像出力 間違ってますか?
ポインヨ使いの俺にはお前が何を言ってるのかさっぱりわからないぜ
なるほど。 つまり、FlowSimulator見たいなソフトが作りたい! って事です。
>>11 よくわかんねーからポーカーやろうぜ プレーヤー2人ね ジョーカー入れて53枚から5枚選べる? もちろんダブっちゃ駄目よ んでもう一人の分の5枚選べる? 一人目のカードを引いちゃ駄目よ お互いにいらないカードを捨てて捨てた枚数補充して お互いに捨てたカードとか相手が持ってるカード補充しちゃ駄目よ (*゚∀゚)コール!花京院の魂をかけろ! ここまでで何か行ったか? なければ完璧だ!健闘を祈る! >>13 自分で作りやすいように書いたのでもちろん作れる! でも今時トランプゲームなんていらないや(・∀・) んで必要な配列の処理は洗い出せたのかい? 思ってたんと違う感じになったんじゃないかな? それは、個人で調べてる。 別の問題で、コードの暗号化(exeファイル)が逆アセンブルで閲覧されてしまうんだが、 何か良い方法無いですか?
>>15 難読化ツール Visual Studioに付いてくる >>15 むしろGithubで公開したら? 自分の価値を高めることを目的とするなら隠すことには全くメリットはないよ Dotfuscatorを検索したけど見つからない。 Visual Studio C# 2008でも付いてる?
商用で売るんでなければ難読かなんてする理由はまずない
>>23 フリーソフト公開したら、 わざわざ逆アセンブルして、もっとコウしろコードはこう書けとか沢山飛んで来る。 下手クソ、俺ならこう書くぞ! とか、キツイんだよ! >>24 いっそソース公開した上で基本無視して有用そうな情報だけ生かしとけ、それかGithubに上げてプルリクしろIssue立てろと書いとけ 少し、混乱してるから、 一旦、落ち着く。 どうも、ありがとう。
参考にしたのですが、厳しいです。 Azure in microsoft Visual Studio 2017 || Anthony Cangialosi VIDEO 設定の方法を紹介しているサイトは豊富ですが、 使い方を詳細まで乗せているサイトが見つかりません。 やりたい事 Visual Studio C#2017(フォームアプリケーション)で入力したデータとモデルを指定して、 Azureへデータを渡してから、結果を受け取り。 C#内の表に格納してから、グラフを自動で作成する事はできますか? できれば、詳しく説明しているサイトを教えて下さい。 それと、個人利用での値段も教えて下さい。 普通はソースごと上げても無反応なのに、たくさん指摘が飛んでくるなんてありがたい環境じゃん 無価値な指摘は無視すればいいし、有意義な指摘は参考にすればいいだけ >>27 どこまでまわかってるのか、何がわからないのか具体的に Azureのサービスは立てられてるの?表からグラフは作れてるのか、そこもわからないのか? >>28 冗談抜きで、何も分かって無いから顔面蒼白してる。 C#も初心者です。 まずその設計が不自然すぎる Azure使うならASP.NETでWebサービスとして作りなよ ASP.NETなら書籍買って読めば簡単に使えるようになる
資料分析任されてけど、一切、来なくなった。 あなたのポジションがなくなりました。とツイッターのメールで飛んで来た。
ねーねー Windows10でアクションセンター出すコマンドラインとかあるの? 探しきれなくて、もし出来ることがわかればC#の処理で開くことができると思うんだけど… やっぱWinAPIなんかなぁ
>>35 ありがとうございます。 やっぱあるんですね! 質問です。 C#でIEは操作できますが、 C#でMicrosoft Edgeを操作する事は出来ますか?
c#からはやったことないけどできるよ。 ie,chrome,edgeの自動テストを作ってる。
C#でやりたいんだよね >>42 API使ってやってるの? WinForm使って3D表示するとしたら、何が一番手軽なんでしょう? 1枚絵を3D表示して色んな角度から見る程度なら、OpenTKでいいのかな? ガッツリやるならWPFやUnityに移行した方が良いのかもしれないけども。
最初はBitmap画像を表示するだけだったんで、WinFormで作ったんです。 そしたら後で「これもうちょっと見易くする為に3Dで表示して」って言われたので・・・。
WinFormsにこだわるならElementHostでそこだけWPF使うのが簡単じゃないかな DirectXを意識するような方法だとゲーム的な作法になるので経験ないならかなりハードルが高いよ
テトリス作ったり3D言い出す奴とか アホしかいないですね。このスレッドは。
>>56 まるで自分なら作れるかのような物言いですね でも現実をご覧なさい >>43 webdriverをつかってる c#用のライブラリもあるよ。 >>52 NuGetにOpenTK v2.0.0あったぞ。 TextFieldParserってバグってんね 連続改行あると処理できねーし これ地味に困るな
外人の作ったもんっていつもこんな感じだな テストやってんのかよてめー
CsvHelperでReadメソッド読んだら元の処理に差し替え出来た ぐぐるとマッピング方式ばっかりなんだけどマッピングなんてしねーよボケがって状況なので マッピング無し方式を見っけるのに時間かかった
>>59 これなに? OpenGLで高度なグラフィックコントロールができるってこと? ってかLinux向けかな OpenGLはどちらかというと低レベル層のコントロール
OpenGLをまともにサポートしていないIntelの古いオンボードビデオのPCがまだまだ生き残ってるから、 なるべく多くのPCで動かしたいアプリでOpenGLの採用は厳しいな。
いままでずっとVB.netでwinformアプリ作ってて いい加減C#の勉強しようと思ったらnamespaceのせいでインデントが余分にいっこ右に行くんだけど もちろんVBでも一見して見えないだけでNamespaceが宣言されてるのはわかってるんだが、インデント減らす方法ないかな
namespace Unko { class Unker { } } package文が欲しい
初心者スレで標準スタイルを破ることを推奨するわけにはいかないだろ 郷に入れば郷に従えとしか
>>71 VGAやプリントアウトして机上デバッグする時代じゃないんだから意味ないよw 違和感を感じているのならそんなのすぐ慣れる。 恐らく1週間かからない TextFieldParserで思うんだけど 俺が不満なのは連続改行が処理されないことだけだったのに このクラスは使えない認定せざるを得なかった クラスの汎用性なんて幻想だよな じゃ、仮にTextFieldParserの動作を今から変更ってきっとできないんだよな 少なくともそれを待っているよりはCsvHelperを使ったコードに変更したほうが話が早い クラスなんて所詮こんなもんだよな
ゲーム制作するためにc#を勉強しています。 確かな力が身につく「超」入門 シリーズのc#版が発売されたのですが、読まれた方はいませんか? または他にプログラム初心者にオススメのc#の本などがあれば教えていただけますか?
少し古いがCLR via C#ってのがいいよ 細かいところまで嘘や誤魔化しをしないでしっかり書いてくれてる いい入門書は初心者を煙に巻くような誤魔化しが少ない 俺はこれで入門した
>>77 ありがとうございます! 色々と調べているんですが、評価もまちまちなので迷っていました。探してみます。 クラスとオブジェクトについてですが、クラス(雛形)に対して実体化されたものがオブジェクト(実態)と考えていいんですよね? 例えばRPGなんかでいうと 敵クラス HP(変数) 攻撃力(変数) HPがある数値を下回ると逃げる(関数) スライム(敵オブジェクト) HP 5 (メンバ変数) 攻撃力 3(メンバ変数) HPが2以下になると逃げる(メンバ関数) といった感じの理解で良いのでしょうか?また本によってはオブジェクトとインスタンスの説明が似ているので、違いがよくわかっていません。
スライムクラスが敵クラスを継承していて 個々のスライムがスライムクラスのインスタンスという認識
オブジェクトはオブジェクト指向にかぎらず広い定義での「物 (変数に入れたり、引数で渡したりできる)」 でオブジェクト指向が出てきて、クラスを実体化したものがインスタンス 言い換えると、クラス(設計書)をインスタンス化(オブジェクトとして実体化)したものがインスタンスって感じでいいんじゃないかな
ざっくりとした俺のイメージ 家の設計図がオブジェクト 家そのものがインスタンス
クラスと構造体をひっくるめた総称がオブジェクト オブジェクトを実体化した物がインスタンス
凄い!短時間でこれだけ回答をいただきありがとうございます。 オブジェクトは設計図とか概念って考えた方がいいんでしょうか? となるとさっきの敵クラスを継承したスライムクラスはオブジェクトというよりインスタンス?
C#では単体で概念的なオブジェクトの話はほとんど出てこない 大体object型というすべてのクラスの元になる型の話
オブジェクトって単語は使わないほうがC#を理解し易いと思う
>敵クラスを継承したスライムクラスはオブジェクトというよりインスタンス? class 派生クラス : 基底クラス{} // これはオブジェクト(クラス) 派生クラス 変数名 = new 派生クラス // これがインスタンス
敵 (クラス) ↓継承 スライム (クラス) ↓インスタンス化 スライムA,スライムB,スライムC (インスタンス)
今は気にしなくてもいいけど C#での話と一般的なオブジェクト指向とでは話がまた違う C#のクラスも構造体も一般的なオブジェクト指向じゃクラスでひとくくり
敵クラスもスライムも攻撃パターンもオブジェクトとして考えるみたいな感じがオブジェクト指向ですよね?(ざっくり) c#はオブジェクト指向に基づいて作られているけど、オブジェクトという概念自体はあまり考えずともプログラムは組める、という考えでいいのでしょうか?
>攻撃パターン そこはメンバ関数じゃないかな >オブジェクトという概念自体はあまり考えずともプログラムは組める、という考えでいいのでしょうか? それでいいよ 正しいオブジェクト指向とは〜とか覚えなくていい 学者や思想家になるんでもなければ 覚えるべきなのは、C#での適切なコーディング
つか、C#ってマルチパラダイム言語なので 純粋で完全なオブジェクト指向を適用しようとすると、かえって面倒な事になりかねないしな
ある本によると、 クラスを実体化したものをオブジェクトといい、実体化することをインスタンス化する、またはオブジェクトを生成する、などといいます。クラスはオブジェクトになってから初めて利用できるのです。 と書かれているのですが、実際にはクラスもオブジェクト指向で考えるとオブジェクトの一つだけれど、そこまで考えるとややこしいから無視してていいよ、って感じですかね?
つまり 敵クラス(雛形クラス) HP(変数) 攻撃力(変数) HPがある数値を下回ると逃げる(関数) スライムクラス(継承クラス) HP 5 (メンバ変数) 攻撃力 3(メンバ変数) HPが2以下になると逃げる(メンバ関数) インスタンス化 スライムA、スライムB、スライムC・・・ でも言ってしまえば、これら全てオブジェクト。 という理解でよろしいでしょうか?
>>96 インスタンス化したもの(メモリに割り当てられた)がそう。 君がいうようにスライムA,スライムB…がオブジェクトでおk またオレオレ定義でグダグダになっとる w イメージなら>>83 がまあまともだと思うわ オブジェクトって言葉はふわふわしがちな印象だから 実際のプログラム言語ベースで考える場合とかは使わないほうが安全 C#ならクラス(構造体含む)とインスタンスで事足りる
C#(VB.NET)の継承は、なんちゃってだからなぁ
ぶっちゃけ 継承とかして実装するから 可読性が悪くなって保守コストがかかる事分からんのかねぇ
リアルタイムゲームはすべてのパラメータをリアルタイムでエクセルで閲覧できるような構造で作らないとデバッグ間に合わない 縦軸インスタンス、横軸パラメータで バグったら前後のデータを自動出力 オブジェクト指向(ツリー構造的な意味で)は合わないと思う
>>96 オブジェクトとは何か、みたいな哲学的疑問(笑)が気になるのは よく分かるけど、そういうのは後回しで十分だし後回しにした方がいいと思うよw たぶん、不毛なだけw 初心者は具体的なコード例を見て、どういうコードがどう機能するか、 何が実現できるのか、そういうところに集中した方がいいと思う >>98 いやこういう例え方って初心者にとっては一番ふわふわしてて分からないと思うんだけど >>104 そう? たいていの人は設計図とか家自体はイメージできるしそのイメージとそんなに解離してないと思うけどな オブジェクトはともかく、インスタンスなんて変な例えや哲学的な話じゃなくて、 もっと現実のコード寄りに「newすると作られて使えるようになる何か」 ぐらいにに理解した方がいいよw しつこいけど、初心者にとって重要なのは「インスタンスって何?」みたいな意味論じゃなくて インスタンスを作るコードをどう書くか、どう記述したらインスタンスのメンバーにアクセスできるか、 っていう機能主義的な具体論
new = メモリ確保して初期化する でいいんだよ くだらねえ例え話はいらん
>>107 それは強く同意だな 俺としてはオブジェクトとかインスタンスとかの言葉すら知らなくていいとも思ってる newしたらなんか動いた!すげー! くらいの軽い感覚が理想 みなさんありがとうございます。>>96 です。 皆さんがおっしゃるように、とにかくオブジェクトが云々と考えるより構文をたくさん打って感覚で覚えていくのが一番の近道なのかもしれません。 でも皆さんの話を聞いて少し頭の中が晴れてきました。 ありがとうございました。 オブジェクト指向って本来はモジュール設計のベストプラクティスに現実世界のアナロジーをこじつけたものだから、 高尚な理論なんか無視して単なるモジュール化の一手法として導入すべきなんだよな C言語を使っていれば自然とlist_add(&list, item)のようなパターンに行き着いて、 そこからのオブジェクト指向への発展はきわめて自然なもの
>>95 とりあえずその本のタイトルと筆者をさらせ オブジェクト指向ってのもいくつかの流派があるから、一概には言えないが C#ベースで説明してるならその本は焼き捨てた方が良い >>83 ,98 その例えならクラスは何よ? その答え見ないとまともかどうかは何とも言えん それがC#での一般的な用法になじむかどうかは別だがな >>112 誰に向かって何を威張ってるのか知らんけど、>>95 にあるような記述は 初心者向けのざっくりとした説明としてはまあ妥当なもの。 最初から重箱の隅つつく勢いで厳密に矛盾がないように書いたら初心者は理解できないよ。 ばっかじゃないの 私が参考にしたのは「c#の絵本」という本です。 立ち読みした本の中で一番わかりやすく感じたので買いました。 classって、共通の性質や特徴を有するものの分類とかいう意味みたい。 オブジェクト指向の言語は、大体がobjectを基本として、そこから色んな性質に分けていったものをクラスにして「名前をつけて」あげる。 オブジェクト指向でいうクラスは「分類整理のやり方、結果」と言えるんじゃないかな。 動物とか車とかに例えたりする説明の仕方もありだと思う。けど、分類整理のやり方という文脈がないと、継承とか派生、つまり上下・並列の概念が分かりにくくなったりしないかな。 いま目の前にライオンが2匹いたとして、同じライオンとして分類していいのか、タテガミの長さが分類のポイントなのかとか、片方は外敵から身を守るために火を噴くとか。ペンギンと比べてどの程度同じ分類が出来て、どの程度違いがあるのかとか。 まとめると、モノでも生き物でも何かしらの特徴とか性質を持っていて、特徴で分けたのがクラス。 オブジェクト指向とは指向、言い換えると、方向性としてはモノを「最小の単位」として扱うことを表している。元素や光といった、もっと根本的な最小になる要素もあるけど、そのレベルで扱おうとすると色々細かすぎたり、人が理解しにくいから。 かな?俺もよく分からなくなってきた。 個人的には日本に来るとき訳する際に、継承とかいう普段使い慣れない概念語じゃなく、「環境適応」とか「マイナーチェンジ」とかがよかったのかなと勝手に思ってる。
>>117 後半に行くに連れて、段々変になっていってるぞ 最も重要な点は、 「データ(プロパティ)」と「振る舞い(メソッド)」を1つにパッケージする事だろう 一々現実世界の物体に例えて説明する必要は無い stackoverflowでも回答者によってマチマチだし 考えたら負けな気がしてきた
>>118 データと振る舞い、そこが理解できたらパッと先が開ける感あるんだけど、灯台元暗し的に回り道しちゃうよね。 質問者の人には、その疑問は忘れず、さりとて目の前の事をこなしてみて、たまーにまた疑問に立ち返って欲しいなあ。試行錯誤してるある瞬間に、パッと思い出してすんなり受け入れられる時が来ると思う。 オブジェクト指向だとかなんだとか、結局はどっかのオッチャンインスタンスが考えたものだろうし、完全な答えはないんだろうなぁ。 厳密な定義も元からないし実装によって変わるし そもそもクラスベースじゃないものまである 設計段階と実装段階でも別のことがある ひとくくりに語るのは難しい でも意思の疎通はかなりできてしまうという曲者
哲学的な話は初心者には意味ないって自分で書いておいてあれだけど、 あえてそういう話をすれば、オブジェクトっていうのは「〜であるかのように振舞う仮想機械」 だと考えるのが一番いいと思うよ。 従来の構造体+関数より分かりやすく仮想機械を記述するための仕組みがクラス。 仮想機械の組み合わせでプログラムを作りましょう、っていうのが(もっとも素朴な)オブジェクト指向
>>113 あれは「オブジェクトとインスタンスの関係性」をハイパーざっくり示すだけでほかに流用できるほど高尚な例えじゃないよ ごめんね 引っ越して来ました。 いろいろ、よろしくお願いします。 ┌(_Д_┌ )┐
皆さん、float、double、intの使い分けはどうされてますか?例えばドラクエのようなRPGでせいぜい4桁程度の整数しか使わない場合でしたら、intを使っておけば間違いはありませんか?
bool a = true; bool b = false; bool c = null; // error CS0037: Null 非許容の値型であるため、Null を 'bool' に変換できません bool d = 0; // error CS0029: 型 'int' を 'bool' に暗黙的に変換できません
>>127 普通に整数が使いたければint アニメーションなどで込み入った計算をするときは無理に整数でやるよりdoubleの方が職人芸がいらなくて楽floatは精度の低さが問題になりやすいから描画などの最終的な出力以外には使わない方がいい >>127 とりあえず、整数ならint、小数点以下が必要ならdoubleを使っておけば良い。 floatを使うメリットはあまり無い。 情報落ちを起こしてるんじゃないか? 浮動小数点数は大量の値を前から順に加算したりしたらダメだよ
>>136 誤差を累積させるような演算をしてるからだろうねえ。 誤差の性質を理解して累積しないようなコードを書かなきゃだめでしょう 要求される精度にもよる double /frortは2進数表現だから表現できない小数がある dicimal は10進数表現
>>139 デジャビューだけど、こういう寝言を書く人は誤差の問題の初歩の初歩も理解してない double/frort(笑)の表現が2進数だからdicimal(笑)と違って誤差が…みたいな話をする奴は本質を理解してないよな 実数型は常に連続な近似値として扱うべきで、最終的には要求される精度に応じて必ず丸めて使うんだよ decimalとは扱う問題の性質が違う
任意の範囲(C#に組み込まれてないようなのも含めて)の整数型を総称してintegerと呼ぶなら double/frortはinteger / 2^integerでdicimalはinteger / 10^integerなのじゃ
誰かに突っ込まれるまでボケ続けるつもりかなw frortってどういう発音なんだろw
frortはfrort型だろ 読み方はfrortって読むんだ
>>116 みたいな人もおるんやし ちょまどさんもそろそろ本書いてみたらどないやろ? 真奈たその後釜じゅうぶん狙えるんちゃう? >>134 そういのがいるからC♯たんが馬鹿言語扱いされちゃう >>157 intっぽい型を自動判別 string,double,date,boolの値が入ってきたらアウト decimal,char,int,byteはセーフ でもさ、ソモソモなんで型分けてるかと言うと 消費する容量が違うからじゃないの? バリアント型って結構デカイとかないの? 例えばbyteで済むならbyteの方がよくね?
>>161 違うよ 型ってのはあくまで気分なんだよ 厳密に定義したらわかりやすいし でも厳密にし過ぎると使いにくい マシンみたいなPGにはこんなもん必要ない メモリ上にはアドレスと実際の値 それしかない そこになんのデータを入れてるかなんて知ったこっちゃない >>163 まあ、c言語とかアセンブラやんないとわかんないと思う 気分だな。unionとか使い出すともう本当どう扱いたいかの気分でしかない。 浮動小数点と巨大整数と、それらのテンソルの型作ったことあるけど、SIMD的な命令として流し込むためにバラバラにしたりしやすいように都合よく書いてた覚えがある。
>>161 C#に限った話なら byteはSystem.Byte構造体のエイリアスだし、 intはSystem.Int構造体のエイリアスだから 当然、消費するメモリ容量に差は出るが 大昔ならいざ知らず、現代のマシン環境において そこまでメモリ容量を切り詰めて考えなきゃならん場面なんざ、そうそうねえよ メモリを節約したきゃ、変数のスコープや生存期間を見直した方がいい 型を厳密にしたいかどうかだな 仕事で設計書書いて実装してるときは varとか邪魔だし
CLRの型はVMレベルで実装されていて、気分で扱えるのはbittableな値型だけだよ それ以外はメタデータを含んでてアホなことするとAccessViolationException
C#はどこもかしこもvar推奨だぞ 数値計算以外はvarでええやろ
今まで型厳密に書いてたけど、var推奨だったのか・・・
>>169 さすがにvar推奨は見たことないな 禁止は結構見る 右辺を見て明確な場合はな 全体を見渡す力のない俺は使うとしてもローカル変数までにしとかなきゃ死ぬ
>>172 var unk = GetUnko(); の型を追跡するの面倒じゃね? 印刷はあんまりしないけどブロックで取り出したときにIDEが無いと読めないんだよね
パッと見で型が明確な場合は、varで問題無いと思ってる varで訳が分からなくなるなら、メソッドを肥大化させ過ぎという意見も理解は出来る しかし、それはそれとして 型名をきちんと書くのが手癖として身に付いてしまってるのだ
>>174 GetUnko()がUnko型を返さないのならそれは命名がおかしくね? >>177 インターフェースってそういうもんだってさ 型が目に見えたら何かメリットあるの? 全ての型のAPIと振る舞いを覚えてるならともかく普通覚えてないよね public UnkoNagashi() { Unko unko = unkodb.GetUnko(); unko.Nagasu(); unkodb.SaveUnko(unko); } というコードをみてなるほどunkoはUnko型なのかとわかる でもUnko型がNagasu()以外に何をできるかは僕は知らない そしてこの文脈ではNagasu()以外の振る舞いを知る必要もない だったらそれって型名を書く意味あるの? unkoがNagasu()できる事だけ知ってればいいよね それはコードがコンパイルできる事から自明でしょ
>>174 デジャブかな? もう何回みたことか。。つーか毎回言われてると思うけどカーソルあてるのそんな面倒か? var に拒否反応示してるのは老害だけだろ 自動的に型名に置き換えてくれるだけなのにな
>>171 var禁止なんて見たことがないから参考までに教えてほしい >>186 わざとvarってクラスを作って型推論を阻止するやつらがいるとかなんとか >>182 1000行あるうち300行そんなのがあったら300回当て無いといけないんだぜ >>189 1000行ものメソッドを作る時点で設計を見直そう >>189 1/3が変数宣言って前提に無理があるのでは? >>189 当てなきゃわかんないようなやつがそんなにある時点でクソ >>191 結構あるぜ でもここで考えて欲しいのは そもそもvarなんて使わなければ当てる必要などないということ 当てなければ読めないソースと 当てなくても読めるソースのちがいしかない >>193 や、だからメソッド単体で1000行だったら何かしら設計あぶないっての 自分はなんでもvarは使わない派 右辺見ればわかるときだけ使うからマウスカーソル当てる必要もない var list = new List<int>(); こういうのも気に入らないの?
>>194 その前に考えるべきことは 型を読めないと全体が読めないメソッドなど書くべきではないということ そもそも型を読まなくてもいいならvarを使わない理由を考える必要などない >>195 メソッド1個しか読まねーわけじゃねーじゃん じゃあ30万行のコードのプロジェクトがあって1万行もvarがあったら 1万回もマウスの素振りすんだぞオメー 単純に害にしかならないと思う varを本来の型に1発変換できるリファクタリングができればえーけどね >>199 しねーよアホ 当てなきゃわかんない書き方がクソなんだよ >>200 それをアホにわかるように説明するのが難しい なので一律でvar禁止が楽 これを禁止で困る奴がこの世にいない var禁止はめちゃ困るわ いちいち書かなくてもいい型を書いてたら手が疲れるじゃん 単純に文字数が多いだけでも読みにくくなるし最悪
C#2.0で止まってる老害結構いるやろ LINQ禁止すらあるんやろ
>>201 Microsoftのコーディング規則に違反するってツッコミには何も反応せずにオレオレ理論かよ >>201 俺は型を明示するタイプだがvarを否定はしない 限られた区域内で扱われる分にはとても効果的だと思ってる またアルルハイマーどものが繰り言言い合ってるのか。 繰り言を楽しく感じる奴は比喩じゃなく本当に病気だからマジでまずは精神科で 診てもらった方がいいよ。これ本当にそう思う。 重症化してからではもう遅い。
>>204 誰が言ったかを強調するやつとまともに話をする気はない それにMSなんて後5年持たない どうでもいい >>208 5年もたないワロタwwwお前なんでこんなところいるんだよwww >>208 MSが死んだらC#も確実に消滅するんだからその仮定は意味を持たない >>208 C#はMSの技術だろカス(標準化されてるけど) お前がMSのことをどう思っていようがC#を使う以上無視はできねーよ なんか発狂してるな 逆鱗に触ったの誰だよ 爆弾抱えて心中しろ
このスレ時々タイムスリップしたのかと思う時があるな オープン化してるし万に一つマイクロソフトが死んでもC#は残るよ マイクロソフトが死んでもメンテナは死なん
C#という言語仕様は残るかも知れんけど VisualStudioが死んだら、C#も実質的に心中する様なもんだと思う
開発止まったら言語としては遅れって死ぬだろ マニア向け言語でいいなら構わんが
>>217 VSCodeもオープンだしジェットブレインもある C#専門の奴ってWin & VS以外の環境知らなすぎだろ 言語なんて結局は大企業のちょっとした判断であっという間に消えるよ 最近だとGoogleがKotlinをAndroidで公式にサポートすると言っただけでScalaコミュニティが一瞬で消滅したな
>>220 まー仮にVisualStudioとC#が死ぬようなことがあれば、代替となるものが既に広まってるだろうからね >>221 既存の膨大な資産を活かしたままC#から移行できるものってあるかい? >>199 リファクタリングのAnalyzer作ればいいじゃん 今はRoslyn使えるんだから簡単に作れるでしょ VSとVSCodeはぜんぜん違うだろ C#なんてVSのために言語仕様変えるレベルだから
C#とVSは表裏一体 C#の開発が止まればVSの開発も止まる逆も然り
>>203 LINQはDB接続時に使うもの、varはvariant型だから禁止な我社環の悪口はやめてもらおうか コードレビューの相手がそれだからどうにもならんわ >>228 そんなところでしか仕事できないなら君もその程度だよ 2.0のコードレビューはさすがに草 技術者殺し過ぎ
Youtuberヒカルが月収を明らかに!!おはよう朝日です出演 VIDEO 第1回案件王ランキング!YouTuberで1番稼いでるのは誰だ! VIDEO &t=61s ユーチューバーの儲けのカラクリを徹底検証! VIDEO &t=504s 【給料公開】チャンネル登録者4万人突破記念!YouTuberの月収公開! VIDEO &t=326s 誰も言わないなら俺がYouTuberのギャラ相場を教えます VIDEO &t=118s YouTuberになりたいのは馬鹿じゃない!YouTuberになる方法 VIDEO 最高月収5000万円だとさ。年収じゃなくて「月収」な おまえらもyoutubeに動画投稿したほうがいい 顔出したくないならラファエルみたいに仮面かぶればいい 手っ取り早く視聴数稼ぐにはシバターみたいな有名ユーチューバーへの物申す系動画がオススメ varでいいなら全部varにする派なのでこういう議論は少し新鮮に感じる
>>235 Microsoft自身がそうしてるもんな すでに3回目ぐらいの話題で毎回全く内容が変わらんので新鮮もクソもない
MSもプロジェクトによっては newみたいな明示的なとき以外var使うなって言ってる まぁこの辺は好みもあれば運用するプログラマのレベルによるね 底へばかりならルールは厳しくせざるを得ない
>>238 あいにくvarを使えないほどの底辺と一緒に仕事をする機会がないのでね あいにくvarを乱用するほどの底辺と一緒に仕事をする機会がないのでね
バカって整数の符号とかオーバーフローとかを意識しないバカのこと?
varで書けば書くほどクラスの使用箇所がわけわからなくなりそう IDEのクラスの参照でvarを見つけてくれるんだろか? やっみりゃいいんだけど
>>243 var を使ったことないのが分かっちゃうよ >>244 で、どうなん? 今、IDE起動するの超面倒臭い >>243 またお前か VisualStudioすら触ったことなかったのかよ たぶんVBの人で、var = Variant 型と思い込んじゃってるんだろうな
>>248 コード書かないタイプのSE多い varはVBのVariantと同じで型情報が消えるので禁止 スクリプト言語と同じになってしまいます 真顔で言われた時はいったいどうしようかと思ったよ >>238 > MSもプロジェクトによっては > newみたいな明示的なとき以外var使うなって言ってる どこで言ってるんだ? 脳内じゃないならソースよろ >varを使うか使わないか 初心者用スレで宗教戦争すんなよお前ら
>>253 安価ミスったwww俺まで頭おかしくなったわ 初心者のみなさんは積極的にvarを使いましょう MSも使えるときは使えって言ってるしヘルプでもvar使ってる
var[] array = {}; こーゆうのできゆる?
初心者の質問で申し訳ないんですが、c#のスクリプトって必ず最初にクラスを作成(または継承)しないといけないんでしょうか?
>>259 その書き方では駄目。 var array = new int[ 0 ]; var array = new int[ 3 ] { 0, 1, 2 }; var array = new [] { 0, 1, 2, 3 }; >>250 MS のC# のコーディング規則には、 When the type of a variable is not clear from the context, use an explicit type. コンテキストから明らかでないときには、型を書け とある。 まだやってんのか >>262 >>250 に反論してるだけなのは分かるが、そういう「訓詁学」に意味はない。 だいたいその文章はちょっとおかしい。 コンパイラに型が分かるなら"clear"じゃないかって言われたら反論できないでしょ。 っていうか、いい加減論点整理して終わりにした方がいいよ。 (1) varが使える場面では全部varを使え。あるいは使って問題ない (2) var容認だが明示的に型を書いた方が分かりやすい場万もあるので、 情況によって柔軟に使い分けるべき (3) varを使うと可読性が落ちるので一律禁止 なんか誤解してるのがいるとしか思えないが、var使え論者(というかC#プログラマの大半)の立場は、 一部のバカを除けば恐らく(2)だと思われる。 varによってむしろ可読性が落ちるケースなんか存在しないと思っている人間は、おそらくむしろ少数派。 その多数派の見解が正しいとすれば、var禁止プロジェクトは一定の合理性があることになる。 メンバーのvarを使うべき場面かどうか判断する能力が疑わしければ、 var禁止の方が多少コスト増であったとしても少なくとも安全だからだ
>>264 さすがにそれは言いがかりだろw 例も挙げられてるし、人間が見てってことだろう。 >>262 > コンテキストから明らかでないときには、型を書け と > newみたいな明示的なとき以外var使うなって言ってる では相当違うと思うぞ w >>238 は脳内確定? >>260 名前空間にフィールドやメソッドは直接書けないからね。 ただ、メインはProgramクラスじゃなくてもビルドできる。 初心者すぎて恥ずかしいんですがVisualstudioのC#でLINQをつかいAccessのDBにアクセスしようと考えています。 そこでLINQという項目をVisualstudioで探しているんですが見つけることができません。 どこを探せばよいでしょうか?
>>270 LINQ to SQLのことを言ってるんなら、もう非推奨だからやめときな >>271 まじですか!!知らなかったです。 別の方法考えます助かりました。ありがとうございます。 EntityFrameworkてAccessに使えるん?
JetEntityFrameworkってライブラリがあるにはある
access c# 接続でググると System.Data.OleDb とか出てくるけどこれでいいんちゃうの?
用途によっては MDB 使うよ (複数端末からアクセスしない、データサイズが知れてる等) dbOpenTable で開いてインデックスにジャストミートした使い方だと とにかく速い。べらぼうに速い Access で簡単に読み書きできるのも素晴らしい
あ OpenRecordset(テーブル名, dbTable) だったっけ? SQL文じゃない、それ以前の Btrieve みたいなアクセスの仕方するやつね
22k$とか半端ないな。完全にバブル まあスレと関係ないけどねw
ポストSQLiteと言われるRealmってどうなんだろうな? 元はiOSらしいが、最近UWPに対応したそうな
staticとかクラスで配列呼びとかこれ直すとどうなるか気になるけど、目的の物への直し方が分からない初心者
>>288 逆にどうしてそれで初期化できると思ったのか聞きたいな また始まったよ 質問者叩いてる奴こそ>>1 のテンプレを「基本から見直せ」バカが。 俺はもともと「ふらっと」スレの存在意義なんか認めないけど、 こうやって質問者叩いてるバカに限ってスレ統一しろっていうと反対するのな >>294 じゃあお前が率先して回答しなよ 口だけじゃないって証明してくれ それは君がこのスレを便所だと思っているから言える発言であって 便所に住んでる人からしたらここが自分の部屋なんですよ スレ民は自分が便所に住んでることを思い出してください
>>296 それはおかしい 彼はここが便所であると思っていて ヤジは飛ばせど、関わりあいたくないと考えているのだから 質問には答えないし、そのつもりも無いハズだよ 答えるのはあくまでスレ民の仕事だと 質問です 最近チンコが痒いんですが どうすればよいか教えて臭い (´・ω・`)
hospital.Ablation( Chinko );
>>294 存在意義認めないのに自治するやつなんか初めて見た 288に対しては無意味な回答しているのは>>290 だけだ お前は2度と来るな あ、>>304 のPointクラスのコンストラクタ間違えた。 ま、分かるでしょ。 >>301 直し方分からんから俺も気になるレベルの無意味なレスしたのはすまん pointの呼び方の直し方がわからんかった >>304 の書き方でpoint呼べばいいのね つい最近C#を学習し始めた者です。 null演算子について質問させてください。 null条件演算子/合体演算子を解説しているサイトや書籍に 下記のような両者の併用が紹介されていたのですが、 良く理解できませんでした。 result = a?.xxx ?? b a.xxxのnullチェックは合体演算子がやってくれているように見えるのですが、 何故a.xxx自体にも条件演算子を設けているのでしょうか? 合体演算子だけを利用した場合とどのように違うのでしょうか?
aがnullならa.xxxやるとヌルポ例外が発生するでしょ
>>307 これと同じ if(a != null && a.xxx != null) result = a.xxx; else result = b; >>309 こう書いてくれたほうが分かりやすいのにな >>310 それはないと思うよw っていうか。等価コードこうじゃなかったっけ? if (a == null) result = null; else if (result = a.xxx == null) result = b; >>311 こういう初見で見てわからん気持ち悪いコード書く奴早く死ねって思う 一生一人だけでプログラム組んでろよって感じ >>316 でも言語仕様を確認しなきゃ何やってるかわからないぜ わざわざなんでこんな書き方するの? 気持ち悪い >>317 同じものをを複数回かくことに疑問を持たないのは、センスがない >>319 ああ、そうだねw ビール飲みながら適当にレスするとこうなる >>316 こんな偉そうなこと書いてるのに笑えるなw >>317 言語仕様を知らずにプログラミングできると思う頭をどうにかしろwww >>320 だっせーな ほら、間違えたじゃんバーカ >>317 よくある処理の割に記述が長くなるから、簡潔に記述出来るように追加された文法だし。 記述が減ればそれだけバグが入り込む余地が減るし、慣れれば等価コードより読みやすい。 >>323 それ、自分のことしか考えてないよね 素直にダサい >>324 ラムダ式や3項演算子も毛嫌いしてそう。 今時Accessとか使ってる奴いたんだ。 煽りじゃなくて割とまじで
皆さんレスありがとうございます。 >>309 >>310 なるほど! 仮に>>307 の式を合体演算子だけでやると、 a.xxxのnullはチェックできてもa自体のnullは検知できないから aがnullだと例外になってしまうという事ですね、やっと理解できました C#ってわりかし言語仕様追加される方だと思うけど C#2.0で頭止まってんの?
自分が使う機能を他人が使えない方が悪いと考えるタイプの人間 自分が使えない機能を使う他人の方が悪いと考えるタイプの人間 どっちもどっちの気がするけど チームや会社の成長や将来性を考えると前者の方がいいよね 後者が群れると互いの足の引っ張り合いになって永遠に停滞する
>>331 役職の手前、後者。 でも、内心は前者って人も少なくないだろうな。 本音と建前だと 正直 result = a?.xxx ?? bは気持ち悪い どのレベルが等価なのかよくわからないから でも代案を聞かれるとわからない result = ?a.xxx ?? b result = a ? a.xxx : b
原本がVS2005だから2005で開発してねとか、開発環境縛りで使いたくても使えない言語仕様多すぎて泣きそう 今2017年なのに・・・
うちの親戚の子供がそうだった。 生まれたときからウォシュレット付きの洋式便所だったからウォシュレットがないところは嫌がるし、、 和式にしゃがむこともできない。たぶんボットン便所なんて怖がって近寄らない。
そういう例えだと選ぶ方がワガママで悪いみたいなイメージだけど 企業が社員の移動に馬車を使わせてるようなものだと例えるとイメージが変わるね
>>327 普通にいるだろ データベース自体の機能は無償のSQL-Server Expressとかでもいいけどレポート機能とかが便利らしい 言語仕様は知らねー方がバカなんだよ 例えばExcelに入った商品リストの合計額調べるとき ・SUM関数使う ・セル1個ずつ選択して足す ・電卓で1個ずつ計算して記入する どのレベルに合わせるべきかってことよ SUM関数なんてExcel関数知らんとわからんやんセル一個ずつ足せって言うバカいるかって話 データがそもそもExcelじゃなくて紙ベースデータみたいなときはしゃーない電卓で計算するがの
>>337 理由があってそうしてるならしょうがないんじゃない? 坂道が多い長崎の住宅地は荷物を馬で運ぶことも多いとか。 使うには使うけどA?.Bという書式が不気味 先行した多言語があるからそれに合わせたんだから仕方ないが c#が先にnullチェック演算子をきれいな形で実装できていれば…
そういうの、大昔の{}が見づらいみたいな思い込みに基づいた言い掛かりと同じだと思うよ 不気味てw
?演算子の後にドット演算子が来ているようだし 単体で?だと三項演算子とかぶるからMSは ?. と ?[ (?[ ] ではない)の二つを null条件演算子と呼んでいる 充分気持ち悪い
UI部をバージョン依存にして 中の処理をバージョン非依存とかに する造りじゃないと駄目だな 同じc#で作ったものすら移行できないのは俺らのせいじゃなくて言語作ってる奴が馬鹿なんだから
何言ってるのかさっぱり分からんが 多分俺らじゃなくて言語作ってる奴でもなくて347が馬鹿なんだと思う
C#2.0で作ったプロジェクトとソースなら現行のものでビルドしたら問題なく動くんだが 初心者スレで間違った情報広められても困るし業界談義は他でやってもらえないかな
2.0はラムダがないのが致命的だな LINQライクなライブラリ書いたけどエレガントに記述できない
>>350 細かいこというと、VS2005の時代のプロジェクトはUAC対応のマニフェストが 自動生成されないので、たぶん単純に変換しただけではGUIアプリの場合は問題が出ると思う 元MSだった奴がいってたけど VS2010当初でも開発に2,000人関わってたらしいよ。 旧バージョンを使って次のバージョンを作っていたとか VS2010でVS2015といった具合
SharpDevelopを使ってとあるソースを開いて、ビルドしたらNewtonsoft.Jsonが無いよ、と。 ↓ SharpDevelopに組み込まれてるNuGetでNewtonsoft.JsonをインストールしようとしたらNuGetが古過ぎてインストールできません、と。 ↓ NuGetコマンド単体の最新版を落としてNewtonsoft.Jsonパッケージを導入した。 でもビルドするとNewtonsoftっていうNamespase知りません、みたいなエラー(CS0246)に。 ↓ パッケージがGACに入ってる必要があるの?と思ってGacutil.exeを使おうとするも、Visual Studioにしか入ってないっぽい。 でも諸事情でVisual Studioはいま使えない。 何とかSharpDevelopでビルドを通したいんです。何が足らない || 間違ってるのでしょうか?
アセンブリロードのアルゴリズムってどっかに文書化されてたと思う それ探して読んで一個一個ステップを確認すればいいんじゃないか
ビルドオプションで、エラーメッセージを詳細に表示できないの? そして、そのエラーメッセージで検索すれば?
358の繰り返しになるけど NuGet単体版ならプロジェクトがパッケージを自動的に参照とかしないだろうから 明示的に参照させる必要があると思うけど大丈夫?
Publicクラスの中にPublicクラスを定義しているソース見かけたんだけど、これって何の意味があるの?
>>362 書いた人に聞かないと分からないでしょ まあ、推測だけど、たぶんクラスAと一緒にしか使われない、 従属的なクラスBがあったとして、BをAの内部クラスにしたら そういう従属的な関係が分かりやすくしたいという意図なんじゃないか。 たぶん今時の流儀じゃないと思うけど、.NET 1.0の時代からあるWindows Formなんか そういうのいくつかあった気がする Formクラス1つに対応するビジネスロジッククラス1つを作ること 0個でもだめだし2以上でもだめ っていう頭のおかしいコーディング規約を押し付けてきたバカSEがいて そのアホくさい制約を回避するために内部クラスを多用したことがある
>>364 formと紐付かないクラスを作ればよかったんじゃないの? >>363 読み返してみたら確かに内部クラスは従属的な位置付けだわ、サンクス >>365 だから作っちゃいけない規約なんだって FormA LogicA FormB LogicB FormC LogicC って風に最初からクラス構成が固定 なので内部クラスを使うしかなかった 頭おかしいやつの下で働かなくちゃいけないなんて哀れだな
それを疑問に思わないレベルのバカPGばかり相手にしてるんだろうから仕方ない PGの能力に全く期待しない前提なら悪くないルールだと思う 参考にさせてもらうわ
>>366 あと、内部クラスって外側の非publicのメンバにもアクセスできるので (当然インスタンスメンバの場合は参照握ってる必要があるけど) publicにはしたくないけどある特定のクラスにだけアクセスを許したい、 っていう事情もあった可能性もあるね。 >>367 Formの数しかクラスが存在し得ないとしたらたしかに頭おかしい規則だが、Applicationはどうしたの? wpfのmodelファイルみたいに作って欲しいんちゃう?
何にせよ 「なんでそんな事するのか」をハッキリさせとかないと本末転倒になるな ルール守るために余計に無駄なことしてたら
あるブランチの、あるブランチ(例えばmaster)との差分が わかる方法ってないですかね? 今は別ディレクトリにクローンしてディレクトリの差分を見ています
あるファイルと削除しようとすると 「別のプロセスで使用されているため、プロセスはファイル XXXX' にアクセスできません。」と出ます。 vshost32.exe がファイルを掴んでいるので削除できないようです。 なのでVSを終了すれば削除はできます。 自分自身が掴んでいるファイルを削除するのはどうすればいいですか? 別にexeを作成して終了後に起動して削除するくらいしか思いつかないのですが・・・
>>376 「あるファイル」も状況もよくわからないが プロパティからデバッグの項目開いて「Visual Studio ホスティング プロセスを有効にする」のチェックを外す コード上で掴んだファイルがそのままとか言う話ならそのコード示して >>376 もし画像表示中に削除できない問題なら、ググれば色々やり方が見つかると思うよ xmlとかxlsをusingで読み込んでdisposeだかreleaseだかしてない系?
>>380 旧コードはされないらしい また、クラスを作った奴がやる気なくてもusingで解放されないらしい usingの自動解放は言語機能ではなく努力目標 関係ないが、HttpClientも一時期話題になったよな
クライアント側アプリでは一通りやりたいことできるようになったので、webアプリというか、サーバーサイド系に進みたいのですが、ASP.Netでお勧め書籍ありますか?
>>381 usingが努力目標ってなんだそりゃ。usingはスコープを抜ける時に必ずDisposeを呼ぶだけ。 そのクラスのDisposeの実装に問題があるだけだろ。 >>384 え?C#の話だとおもったんだけど違う? >>383 ASP.NETとASP.NET MVCは別物なので注意。 今から勉強するなら、ASP.NET MVCの方。 今は非常に時期が悪いのでMVCすらお勧めできないよ
>>390 idisposeさんと共犯なので合わせ技で死刑 >>388 ASP.NETとASP.NET Web Formsとを同一視してないかい? >>393 いや全然ちげーよw ASP.NETの中にMVCとWeb Forms(とその他諸々)が含まれるんだから >>392 ASP.NETだけだと、WebFormsを指す場合が多いからね。特に書籍。 補足として書いとくべきだったな。 >>395 ASP.NET Core MVCの方にしか力入れてないけどね あ、最近だと特にSignalRもか >>388 ちょww 古い本買ってしまいましたぁー 情報ありがとう(>_<) >>389 どのように時期がわるいのですか? 宜しければ業界背景とか教えてください あ、ちなみに私は別業界の週末趣味プログラマで、あまりトレンドとかわからんのです
ASPの話題なんでちょっと聞きたいんだけど、linuxサーバー用のwebアプリ作ろうと思ったら.net coreでやるのとjavaでやるのとどっちが敷居低いかな?昔javaでちょっとやってたらマッピングやらがえらい面倒だった記憶あるんだけど
JavaならSpring Boot使えば楽 .NET Coreは敷居とか気にするレベルの人が手を出しちゃダメ
>>399 今新しいのに移り変わったんだけど全然普及してない OSSにいるライバル達が強すぎてびくともしてない 従来使ってた人が離れつつある 目新しさがないのが非常にまずい 今後新しいなにかを提案できなければ 早い時期に丸々消える可能性がある >>403 なるほどですね。 しかし、本も買ってしまったし、一通りは知識として吸収しておこう。 結局、今Webアプリを構築するなら、何がベストなんでしょうか? クライアント側はjavascript一択ですよね。 サーバ側が、自分はweb formで止まっています。 .net coreなるものを調べてみればいいんでしょうか?
>>403 .NET Standard2.0あたりを理由として持ち出すならまだしも、そんな理由かよwww >>405 Webアプリで何をしたいの?言語はc#縛りなの? >>407 イントラ環境で、DBを絡めた様々な情報を提供したいです。 目的によってGridViewで表示したり、グラフで表示したり。 C#縛りではないですが、VS2008時代にゴリゴリ作った経験があるので一番馴染みがあります。 Node.jsとかでいいんじゃね Coreも含めた今時のWebはWinFormsや昔のASP.NETとは全く思想が違ってて、コンポーネントというものが存在しない MVC系なら何選ぼうが似たようなもんだから環境の整えやすさとかで選べばいいと思うよ
>>410 vs2008使ってた人なら、相当な理由がない限りNode.jsを選択する理由はないな >>412 本人にJavaScriptを書く気があるということは十分な理由になりうる >>413 DB連携が主だろうからASP.NETでいいだろ フロントエンドはもちろんjavaScript使うだろうが Web初心者ならWebAPl + html + js + cssが簡単でオススメ 難解で無駄の多いサーバーサイドレンダリングは初心者には厳しい 厄介なWebフレームワークも最初は避けたほうがいい
>>415 初心者でWebAPIいきなり立ち上げさせるのか?認証はIdentityServer? 初心者だからこそフレームワークの流儀に従えば簡単にできるものを選択した方がいい どうせイントラなんだし >>416 難しい事は考えなくていい 初心者の作るイントラサービスならCookie認証で十分 モデルバインディングとかテンプレートエンジンとかのあれこれ考えるより 素のhtmlとapiの方が素朴でずっとわかりやすいよ >>418 MVCなら言語だけの違いになっちゃうから、もちろんWebFormsを意図してるんだろ? LinuxでWebFormsが問題なく動作する構成を教えてくれないか まさかMonoとか言わないよね >>420 トンデモ理論ワロタwww LinuxだからASP.NET Coreに決まってるだろカス >>415 SPAやjQueryなんかの動的DOM操作をサーバーサイドレンダリングに移行するとかの話じゃなければ サーバーサイドの方が分かりやすいと思うがな。動的なページがほとんど無いってんなら話は別だけど。 >>422 結局MVCやれってこと? なら 知っている言語 + 新しいアーキテクチャの習得 でNode.jsと対等じゃん 必死に噛み付く意味がわからないな >>425 もともとVisualStudioでc#書いてたっぽいしね サーバーサイドコンプレックスにまみれたフロントエンドエンジニアが、必死にHTML&javaScriptをアピールしているようにしか思えない >>417 Linuxとは一言も言ってないじゃん お前の目は腐ってるの? >>426 対等だと本気で思ってるのかこのアスペは >>426 c#知らない人がなぜ偉そうにしてんのかwww >>429 まさかと思うけど、Nodeにサーバーサイドレンダリングのフレームワークが無いとでも思ってるのかな? >>432 何がそんなに気に障るのが知らないけど、Web MVCへの移行を前提とした場合において、 入りやすいWeb開発プラットフォームの例としてNodeを挙げただけだよ サーバーサイドレンダリングだけでいいなら情報の豊富なRailsやPHPの方がもっと入りやすいだろうね 君がその選択肢としてASP.NET Coreを推すなら否定するつもりはないし、俺を攻撃するよりお勧めの本やサイトでも教えてあげたら? >>433 お前がなぜここにいるのかわからんわ 別のスレに誘導してさしあげろ フロントエンドとバックエンドを疎結合に保つほうが実装も保守も簡単だよ サーバーサイドレンダリングはその点で劣る ユーザーインターフェースはフロントエンドに責務を割り振る サービスはrest apiでバックエンドに責務を割り振る やることが明確で実装もシンプル、保守も楽チン おまけに動作も軽快になってユーザーもにっこり
次のASP.NET core 2.0で.net frameworkが捨てられるって 明言されてるから他に移るにはいい時期だと思うよ 海外の人達はどんどんASP.NETを捨てて新しい言語と別のフレームワークに移ってる最中 2.0が安定するのはリリースされてから1年後あたりだから本当に時期が悪い
どの人がキチガイじゃないんですか? ほぼ全てキチガイだと思うので、キチガイじゃない人を挙げてもらった方が早いかなと思いました
>>441 道にキチガイとそうでない人が多数混雑していたという どんな質問をすればキチガイとそうでない人がわかるでしょうか? c#で答えなさい(5点) >>443 ググって答え探して見つからなかったんだな かっこ悪い >>446 いまだに訂正記事出さないってどういう神経してるんだろうか クライアント10台分のサーバ間送受信処理100回を並列で処理しようと考えているんだが、 Enumerable.Range(1, 10).AsParallel().ForAll(t => { Enumerable.Range(1, 100).ToList().ForEach(c => { クライアントの送受信処理 } } と var taskArray = Enumerable.Range(1, 10).Select(t=> { return Task.Run(() => { Enumerable.Range(1, 100).ToList().ForEach(c => { クライアントの送受信処理 } }).ToArray(); Task.WaitAll(taskArray ); でそれぞれ実行すると実行順が明らかに違う理由を教えてください。 どちらも10台が順不同で各100回実行すると思いきや、なぜか前者は任意の1,2台だけ100回実行した後に残りを順不同で各100回実行して、後者は狙い通り10台順不同で各100回実行する・・・
.ForAllのせいじゃないかな… Enumerable.Range(1,10)の出力だけが並列で実行されて、 .ForAllの中味は現スレッド1本で順次行われてない?
>>451 CPUがデュアルコアだからじゃね? Enumerable.Range(1, 10000).AsParallel().ForAll(i => { Console.WriteLine("{0} 処理開始", i); Thread.Sleep(1000); Console.WriteLine("{0} 処理終了", i); }); 昔XPのころVS2010ExpressでC#で遊んでました 7年ぶりにまたいじってみようかと思い立ったのですが 最新版の無償版ってVS2017Comunityとかいうやつになるんですか? これで2010時代のソリューション読み込めますか? 当時はC♯としかいってなかったはずだけど今はC#7というみたいですがずいぶん内容は変わったのでしょうか? 浦島状態ですみません。乙ちゃ〜ん!
>>455 開く時にコンバートする必要あるけど問題なく開けるよ 仕事だと未だにVS2010現役だわ >>456-458 どうもありがとう! なんとかインストールできました とりあえずフォームアプリのビルドはできました 昔のソリューション読み込みまだ試してません 使い方思い出しながら頑張ります! expressと違ってフル版だからそこは新規に覚えるとこかな
スレ違いかもしれませんが 基本認証のID/PASSでしっかり認識される最大文字数はどうなっていますか? 桁数を増やせば安全かと思い 30桁オーバーで設定していますが そもそも基本認証では、前方8文字までしか認識されない、といったブログがありました。
webbrowser1のボタンを押す処理でhtmlにnameが無くても foreach (省略) { if(省略) { // 要素をクリック he.InvokeMember("click"); } } で今まで全て問題なく押せましたが、今日、この書き方で押せないボタンがありました。 he.InvokeMember("click");を実行しても何も反応しないということです。。 ここに居る人でこのような問題を解決した人は解決方法か解決のヒントを教えてください。
>>461 仕様上の制限は特にない サーバの実装上の制限は知らん >>463 1GB超える文字列アタックで死にそうだな インターネット上のbasic認証っていざとなったら破られても 実害のないものぐらいにしか使わないほうがいいよ とにかく破られる前提で
>>465 ハッシュ化にcrypt使ってたらそうなる みんな、どういう現場でC#使ってるの? ゲーム開発?
>>471 マッコイ「精神的に疲れているようだな、メディカルステーションに行こう」 C#(windows)しか知らん奴ばかりかと思ったけど 意外とlinux周りの知識ある奴もいるんだね。 雑魚ばかり、という訳ではなさそうだ
>>475 linux周りの知識がないと雑魚なの? >>476 > C#(windows) の時点で雑魚以下の奴に構うなよ >>482 ああ、そういえば、C#でできることはVBでもできるって言ってた人がいたけど、そういうこと? >>484 というか、linux周りの知識があれば雑魚ではなくなるのかなって… 目糞が鼻糞笑っててそれを耳糞が煽ってるだけならそれはそれでいいんだけど… 鍛え抜かれた筋肉がないと真のプログラマとは呼べんな
しょうもないことで荒れてまんなw 山形治生だと思ったけど、UNIX系の人が威張って他を見下してる (今はそんなことないと思うけど)のは、昔メインフレーマーに同じことをされたからだって書いてたな
>>486 なるほどー。なんか名言のような気がする。 >>487 たとえばさ、何万個ものジャガイモの皮を剥いてきた料理人と料理好きの芸能人(グッチ裕三とか)とはやっぱ違うんだよね。 グッチを料理人と思う人はいないもんね。 そしたら君の言う真の料理人達は グッチ祐三をバカにしてると思うか?
>>490 たしかに! 真の料理人は他の料理人をバカにはしない。 でも弟子には厳しいよ。 プログラミング自体初めてで(3日目)、MSのチュートリアルをやってる最中です https://msdn.microsoft.com/ja-jp/library/dd553230.aspx このページの内容で質問があります Listで並べたアイコン(text)をテープルレイアウト上に並べたラベルにランダムで次々に流し込むという内容ですが 次々に流し込むというのはテーブルレイアウトの次のマスへ順番に勝手に流れ込んでいくのですが どこのマスへ…という指定がなくても、作動しています で、そのテーブルレイアウトのマスを次々変えているのは簡単に言うと foreach (Control control in tableLayoutPanel1.Controls) でループしている間、その都度tableLayoutPanel1.Controlsを変更(適用?)して次のマスへ行く様に作動している という認識で良いのでしょうか? >>497 foreachは含まれる要素全てに実行される tableLayoutPanel1.Controlsを変更じゃなくtableLayoutPanel1.Controlsに含まれる要素(inの前のControl control )にたいして実行される デバッガでforeachの中にブレークポイント置いてcontrolの値がどう変わるか確認したほうが分かりやすい >>498 ありがとうございます 超初心者の自分にも凄く分かりやすい説明で助かりました デバッガの使い方調べてみます 初めてとか超初心者を強調しすぎ。 ここは初心者用スレなのにしつこく強調する意図を勘ぐったり勘ぐらなかったり…
for文でデータスキャンしながら、不正データを除外するPGを C#で書いて、SharpDevelopでVB化したら正常に動作しません。 同じ事が出来るっていう人は嘘つきだと思います。
>>502 申し訳ない。 必要の無いことをしつこくやってる人がいるとどうも気になってしまう体質でして… 外部のアプリ(EXEファイル)を別プレセスで複数実行させるのどうやんの
>>506 天才 インスタンス化したかったんだありがとう >>508 タプルはコレクションではないのでそんな間違った発送は捨てる >>508 自前のメソッドなんて使わなくてもSelect使えばIEnumerableなTaple作れると思うが new[]{ hoge, hoge } だと冗長やん? (hoge, hoge) ならスクリプト言語並みにスッキリするから 科学技術計算かなにか向けに数値のリストを渡そうなんて時にはいいよね 一次元ならint[] Nums(params int[] nums) => nums; みたいなのを書けば Nums(3,4,5)といった感じで可読性もバッチリだけど 問題は二次元になった時 new int[][]{ Nums(1,2), Nums(3,4,5) } 毎行Numsが出てきたら冗長すぎて耐えられない どうしてもこうしたい var hoge = NumArray2( (2, 3), (4, 5, 6) ); int[][] NumArray2(params IStructuralComparable[] tuples) => tuples.Select(tuple => tuple.TupleToArray<int>()).ToArray();
でもそれメタプロで遅いし型チェック効かなくなるじゃん だったらスクリプト言語を使いなよ
>>511 そんなもん一次元で渡してから二次元に変換すりゃいいだろ 括弧すら必要ない >>515 1, 2, Delim, 3,4, 5, Delim みたいに区切りを書くの? それだとNum(1,2)みたいにするのと冗長さは変わらんでしょ >>516 科学技術計算なら矩形しか使わないからデリミタなんか要らん numpyなんかだとreshapeで行列の型を読み替えたりするのは普通に行われている 遅すぎわろた public struct TupleWrapper<T> { public TupleWrapper(object tuple) { tupleOrValue = tuple; } public T Value => (T) tupleOrValue; public int Length => CountItemField() < 8 ? CountItemField() : 7 + GetRest().Length; public TupleWrapper<T> this[int index] => GetItem(index + 1); private TupleWrapper<T> GetItem(int i) => i < 8 ? new TupleWrapper<T>(GetItemField(i).GetValue(Tuple)) : GetRest().GetItem(i - 7); private FieldInfo GetItemField(int i) => Tuple.GetType().GetField($"Item{i}"); private TupleWrapper<T> GetRest() => new TupleWrapper<T>(GetRestField().GetValue(Tuple)); private FieldInfo GetRestField() => Tuple.GetType().GetField("Rest"); private int CountItemField() => Tuple.GetType().GetGenericArguments().Length; private object Tuple => tupleOrValue; private readonly object tupleOrValue; } var t = ( (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20), (11, 22, 33, 44) ); var w = new TupleWrapper<int>(t); for (int i = 0; i < w.Length; ++i) { for (int j = 0; j < w[i].Length; ++j) { Console.Write($"{ w[i][j].Value } "); } Console.WriteLine(); }
>>517 矩形しか使わないわけないやろ まあ一行の個数が決まってるなら普通にTuple指定すれば型安全にちゃちゃっと書ける たとえば1回目の実験では15人の被験者がいました 2回目では13人で3回目は20人でN回目はM人でしたと 一人分のデータには名前とか年齢とかいろんな型のデータが使われます これを一気に処理しようとすれば一人分のデータの型は固定の2次元ジャグ配列になるよね このデータを書く時にVisual Studioで書けば、データ型のエラーは即検知してくれるしデータを修正するときにもエクセルとか立ち上げなくて済むしJSONみたいな冗長な型式にして可読性を犠牲にしなくてもいい 別のスクリプト言語を実行するための環境を用意しなくても済むしその言語の変な仕様に足をすくわれることもない いいことづくめでしょ タプルを使えばね
>>522 そんなデータをソースにリテラルで書くことがどれだけあるのだろう そういうデータ処理はわりとよくやるけどPythonやPerlですらソースに書くなんてやったことないわ まあ実験IDか実験日を持たせるわな 重複が嫌なら正規化するべきだし
Nが少ないなら高速処理要らないんだしファイル経由でいい N多いならそもそもデータベースかファイル群として格納しとけっていうデータやね 数値計算で扱うデータではないよ
だからデータはソースじゃなくて外に出せよ c#入門したてでファイルの読み込みできないのかもしれないけど 勉強したほうがいいぞ 最低でもcsvにしとけば他でも使いやすい
なるべく細かく設計するならこんな感じだな 実験(実験ID, 実験日, …) 実験結果(実験ID, 被験者ID, 項目1の結果, 項目2の結果, …) 被験者(被験者ID, 氏名, 年齢, …) 1項目ごとに結果の値が複数個あるなら項目ごとに別々の実験結果テーブルを作ったしたほうがいいかもね
実験するたびに手作業でタプル書いてリビルドするとか斬新な修行方法だな
最近は横着しだしてcsvじゃなくてタブ区切りにしてる
>>532 所謂TSVってやつだけど、知名度いまいちだね。 Excelでそのまま開いてくれないから、採用し辛い。 >>533 今のは開かないのか 前のは普通におkだったけど >>533 普通に開けるよ 方言でトラブル多いCSVよりTSV使って欲しいわ どっとも同じにしか思えないけどw CSVで起こるトラブルは全部起こるんじゃないの? セパレーターが違うだけじゃんw ただ、TSVってクリップボード経由でエクセルに矩形(N列×M行)のデータ 貼り付けに使えるんだよね。 それ以外の用途で使ったことないなあ
>>536 いやいや普通のテキストには普通にコンマ入ってるけどタブは入ってない これが重要 TVで報道されない真実 集計マシーン ムサシ 作ってる会社は? wwww 一番触れられたくない部分www 税金垂れ流しで身内がばぶってる糞安倍特需
>>537 確かにカンマの方が頻度が圧倒的に高いのはそうだね プログラマの端くれだからどうしても「例外的な状況でも問題を起こさないか?」 って視点で考えちゃうけど、現実論としてはそうかもしれん >>537 それを区別するためにダブルクォーテーションを先頭と末尾につけて更にドツボにハマるケースとかあるしな >>535 え、もしかしてcsvのcって、カンマで、tsvのtってタブなの?? だから言ってるだろ ソースに書いたほうが何もかもいいんだよ いちいち別ファイルにして読み込んで混乱してもなんにもいいことはないし 修正にも手間がかかる 仮想的にデータを修正して結果がどうなるか調べていって新たな実験のプランを立てたりもするのだから デリケートでミスが多い型式にするのも可読性を犠牲にするのも何も合理的じゃない ソースにデータを書いてはいけないというのはただの思いこみに過ぎない
>>544 もちろん C#なら一瞬 なんならプロジェクト分ければそこしかコンパイルされない TSVを使えると言うならソース側のソフトもいじれることを示すわけで 両方いじれるならIPCでも使ったほうが使い勝手が良さそう ケースバイケースだけどね
もっと根本的なことを言えば、なぜこの世にスクリプト言語があるかと言えば プログラミングの外側にスクリプティング 作ったライブラリをただ呼び出すフェーズがあり その外にさらにデータを作るフェーズ これはプログラミング言語を使う必要もなく データ記述に特化したアプリを使うことが多いわけだが 出来るものは全部C#でやったほうがいい Visual Studioはそれだけ優れた記述環境だ ライブラリを呼び出す時のインテリセンスのサポートは圧倒的だし データの型式エラーもリアルタイムに発見できる 言語自体の記述の冗長性の低さもタプルで一段先に進んだ
こういう時期あるよね 俺も経験あるわ 君が言っているようなことは誰でもみんな一度は考えて試したことがあるんだよ プログラミングのベストプラクティスは自分の考えでやってみて壁にぶち当たって初めて身につくものだから、君はそのままでいいと思うよ
こういう時期あるよね 俺も経験あるわ 君が言っているようなことは誰でもみんな一度は考えて試したことがあるんだよ プログラミングのベストプラクティスは自分の考えでやってみて壁にぶち当たって初めて身につくものだから、君はそのままでいいと思うよ
自演はするのに書き込みにロジックはない 恥ずかしいなお前
>>546 お前がそれでいいならいいけど俺ならそんなどうでもいいことまで保守しなきゃならないプログラムは避けるなぁ >>551 君の言っていることは理屈の上では正しいからな 教科書的な否定意見を述べることはもちろんいくらでもできるけど、君がそれを受け入れないことも分かってる なぜなら俺自身がそうだったからね これはプログラムというものがどういう状況で使われたりどういう理由で変更されたりすることが多いか、といった、 きわめて経験的な問題であって、演繹的なロジッで白黒付けられるような問題じゃないの >>553 議論の目的は相手を言い負かすことではないから俺が受け入れるかどうかなどどうでもいいし ロジックでは説明できないと言い張るのも全く論理的な態度ではない 少なくともプログラマーが取るべき態度ではない >>552 データの管理をプログラマーがやらなきゃならなくなるって話か? データを書いて管理するのもスキルが必要だしそのスキルを学べたならC#のデータ記述ぐらい学べる プログラミング技術ではなくデータ書式を覚えるだけなんだから それにこの方式なら自然にデータがバージョン管理されるから何か問題が起きた時に再現したりも簡単にできる ソース管理履歴が入力データの数値変更とかある意味斬新な使い方だな
>>554 その使い方を他人に教えるのは少なくとも最初はお前の仕事なんだぞ? VSのインストール方法、ソースの変更箇所や変更方法、ビルド方法、全部教えるの? 外部のスクリプトから毎回パラメータを変更して繰り返し実行したいときはどうするの? 実験データの処理なんかだとよくあるよね 毎回本体に手を入れるの? 他人にもそれを求めるの? データが変わったり増えたりするたびにコンパイルしなおす環境を 是とするのは初心者だけ コンパイル5分とかのプロジェクトが普通にあるんだけど
実際初心者なんだからいいだろ 何をムキになってんの お前も初心者Lv2くらいなんしゃねーの
だからプロジェクトを分ければそこだけしかコンパイルされない VSの使い方は別に難しくない しかもデータを書くだけなんだから使う機能はほんの一部 データほどバックアップが必要なものはないからバージョン管理するのも当然 上書きしたデータはしばしば必要になるがデータは消えたらまず戻らない ソースコードの変更履歴なんてのは消えても必要なら書き直せばいいだけだからな パラメータを変えながら繰り返し実行したいならC#で書けばいい 繰り返しになるがそこだけプロジェクトを分ければそこしかコンパイルされない スクリプト層のように一方的に使う側は書き換えても何も他に影響を及ぼさない データのように書き換えてもプログラム上のインターフェースが変わらないものも同じだ
>>557 プログラムにデータベタ書きは日本のSIerなら常識だぞ。 変更のたびに改修費取れるからな。消費税率なんかみんなベタ書きだ。 >>555 データをバージョン管理ツールに突っ込むのはたまにやる >>557 コンパイル5分はさすがに設計が悪いとしか >>559 だからこそ外に出したほうがいいんではないかと普通に思うんだけど 外に出しておけばほかのツールなどでも使えるし 馬鹿な初心者はなんで食い下がりたがるんだろうか?という疑問はいつか解消されるのか なんかしょうもないことで揉めてるなあ。 こんなの要件その他しだいのケースバイケースでしょ。 まさか文字列や数値のリテラルまで否定する人はいないわけで、 そういう感覚で複雑なデータをコードに直書きした方が好都合な場合もそりゃないことはないと思うよ。 いつでもどんな場合もそうした方がいいと言ってるならお馬鹿さんだけどさ
>>563 テストケースで使うデータはテストコードと強く結びついてるからコード中に書く場合もある ひとつの手段を「普通」と言い切ってしまうのは浅はか c#でjsonにシリアライズしたいんですが、キーは文字、値は文字と数字としたい場合 どのような型を使えばいいのでしょうか? 例えば、jsonの表記を以下のようにしたいということです。 { "test": [ { "a": "aaaa", "b": 123456789, "c": "ccc", "b": "987654321, }, { "a": "aaaa", "b": 123456789, "c": "ccc", "b": "987654321, }] }
>>562 6年ほど前に某F通のフレームワーク使ったときはビルドに10分とかかかってたわ いや訂正 >>566 なら普通にa, b, c, dをプロパティとして定義した型を使えばいいな >>566 var obj = new { test = new [] { new { a = "aaaa", b = 123456789, c = "ccc", d = "987654321" }, new { // ry } } }; var s = NewtonSoft.Json.JsonConvert.SerializeObject(obj); お二方とも、ありがとうございました。 オブジェクトを使って無事にやりたいことができました。
>>563 データを別の環境から使いたいならJSON.NETでも使えばいいだけ しかしJSONは冗長だから管理には向かないが CSVみたいなのも自分が何の値を触ってるのかわからなくなりがちだから難しい だから元データにはC#&VSを使うべき タプルのいいところはもうひとつあるな こっちの方が重要かもしれないが コードでデータを書こうとする場合、データの型とプログラムに依存関係が発生してしまう場合がある C#でデータを書くには型が必要で プログラムで処理するにも入力する型が必要 「プログラムは再利用するものだ」という観念があるとここで型を使いまわして依存関係が発生してしまう プログラムで処理したい型に合わせて元データを書いていると、プログラムの方の仕様変更で型が変わっても元データをいじるわけにはいかず対応が難しくなる もともとデータはデータであってデータの汎用性を最大にするためにも変更に強くするためにもプログラムと依存関係は持つべきじゃない 依存関係はコンパイルにも影響する しかし同じ型を二つ作ってやりとりするのはめんどくさかった (まあJSONやCSVを使える型に直すよりはずっと楽だが) この問題はタプルで解決する タプルの型が使いまわせるうちはそのまま渡せばいいし 使いまわせなくなったら必要な変換コードを書けばいい >>564 見積りに入ってねぇのに勝手にやったらぶっ殺すけどな テスト工数とかものすげー増えんじゃん >>572 タプルってpythonのごった煮のゴミだろ いらねーよ >>572 そうそう それを突き詰めていくと「CSVかJSONでよくね?」となるんだよ こっち側まであと半年くらいかな pythonのお仕事が来ると あまりにも変態的な使い方をするやつが多かったのか 使用禁止例もいっしょに出るので注意な
Pythonのタプルが要素の取り違えを非常に起こしやすいのは確か C#のタプルは常にフィールド名を型に含めておけるからだいぶマシだと思うよ
>>577 いやいや どんな設計になっとんねん 将来的にデータベースに移すとかなったらそんなテーブルどう作んねん >>572 素晴らしいアイデアだ 是非とも世界中に広めてくれ ちなみにこのスレのみんなはもう君の素晴らしいアイデアは理解したから 別のコミュニティに行って啓蒙した方がいいと思うぞ 業界のデファクトスタンダードになったら業務にも導入するよ なんでもできちゃう仕組みは実は何にもしない これがわからんうちは素人 俺らは制限を加える代わりに機能を作成している
>>554 そう考える方もいるんだね データと処理は分けたい!ってクセになってるので状況に応じて柔軟に考えるようにするわ >>581 せめて客と打ち合わせして 誰向けにどんな頻度で読み込むのか 相談しろよ しかしやはりテスト工数とか超無駄 頼んでもいねー機能が入っちゃってるし コードレビューやるとこだと 会議室静まり返るわ >>584 お前扱いにくいやつになっちゃったんだな 場所によっては通用しないだろうな 加不足なくキッチリ作ってこそプロ 塗装屋に屋根だけじゃなく壁も塗られたら嫌だろ
>>582 大雑把に言えば間違ってはいないな 俺は基本的にLinuxファーストで構成組むけど、どうしてもどうしてもWindowsを使わざるを得ない場合にC#を使う >>582 LinuxできないのにC#は今後キツイぞ >>587 やっぱりそうだよな。 スキルとか知識面で Linuxベース+Windowsの人間の方がきもいけど知識は豊富 >>570 library使ってるの言わなきゃわかんねーだろw タプル使っても結局戻り値の受け皿となる型用意しなきゃいけないし、だったら最初からその型で返却すればいいとおもうのですが。
>>572 コードの中に埋め込んでる状況が一番依存性が高いだろうwww 本当の馬鹿ってこんなところにいるんだな… タプルはその型にちょうどいい名前がつかない時が使いどころ なくてもそんなに困らないけどあると便利な場面は多い
タプルは7.0のタプル型になってから戻り値で使うようになった
C#はバージョン毎に結構あれこれ追加されて常識が変わってくからな 最新バージョンを追い掛け続けてる人とそうでない人で、話が通じなくなる事もしばしば 俺も割りと4.0くらいで頭の中が止まってるかもしれない
せっかくJavaやCが戻り値はひとつにしようと糞コード撲滅の努力をしてきたのに
>>606 戻り値のためにクラス作るのがなんか心理的に重い >>608 戻り値にデータが複数必要ってどんなときだべ? もちろんなかったわけじゃないが エラーとエラーログみたいな? >>609 たとえば画像データだと画素データだけでなくチャンネル数や各チャンネルの大きさ、縦と横の(特に横)の長さが必要になる これだけで例えばバイト配列といくつかのintが必要になる >>610 全然適切な例になってない気が それ、明らかにクラスまたは構造体にまとめるべきデータでしょ まあ、一つの型にまとめたくない複数のデータを一つのメソッドから返したい、 なんて率直に言ってうんこの臭いしか感じないね。 >>611 「クラスや構造体でまとめられないデータ」に対する回答でなく 「複数の戻り値が必要なデータ」に対する回答なんだけど 別の場所でも入力にも使うようならクラスなりで定義すべきだけど なんちゃらResultとか名前を付けたくなるような 特定の場所の戻り値でしか使わないデータのまとまりはタプルって感じかなあ
一連のDBと入力の整合性チェックをまとめたとき 処理途中でとってきたDBの値を使いまわしたい場合とか Result 処理途中でとってきたDBのDtoいっぱい = checkなんちゃら(画面入力.id, 画面入力.数量) とかのためにクラスつくるのがなんとなくイヤで タプルで楽したくなる
>>613 スコープの範囲次第で使い分けかなと考えているけど、職場ではTaple使えない悲しい現実 >>603 会社が4.0の環境でasynce await使えないからよくわかるわ。 >>609 今時のAPIなんてほとんどjsonだろうに。 >>617 環境変えるとビルド結果のバイナリが変わってしまうかも知れない、て不安があるとどうしてもな C#の話じゃないけど、Borland C++ Compiler(5.5.1)のコマンドライン版は問題なく使えるのに 後発の2006年版Turbo C++に含まれてる奴は、リソースコンパイラにバグがあってコマンドラインから呼ぶと正常に機能せずにしばらく頭を捻るとか そういうしょーもない例も過去にある 分解構文は気持ちがいいぞ タプルの存在意義なんてほぼ全て分解構文のためだろ 手軽に変数をまとめたいとかそんなんどうでもいいんだわ
Linuxの覚えることの多さに挫折した奴が Visual Studio使って開発もどきをしている
意味ワカンネ Linuxむしろ全然楽じゃん windowsめんどくせー
>>622 linuxの画面表示版 最速HelloWorldってどーなんの? >>626 win32api思い出したわ そうかlinuxで組むとそうなるか Visual Studio意外でC#書いてるやつはマゾなのか??
>>630 最近ずっとプライベートではVSCode… VSCodeがいまんとこベストかな C#だけならVS IDEでもいいけど
>>635 NuGetのパッケージマネージャーが軽くてびっくりした Nugetから持ってきたパッケージがウイルス感染している危険性は無いの?
>>637 MSのサーバーがやられてバイナリが感染する可能性を考慮すると Windows UpdateもVS本体のオンラインインストールも、あらゆるダウンロード行為が何一つ安全でなくなるので、それは考慮しなくていいだろう その上でNuGet特有のリスクは、第三者によるレビューなしに誰でもパッケージを登録でき、登録した本人であればいつでもそれを更新できること 例えばJSON.NETの作者がこっそりマルウェアを仕込んだらとんでもない被害が出るだろうね その点についてMSが保証するのは他人のなりすましによる登録や更新が行えないことだけで、作者の人格を信用するかどうかはお前自信の責任 ソースチェックすればいいじゃん なんのためのオープンソースだよ
>>639 公開されているソースとバイナリが一致している保証はない ソースが公開されても誰もチェックしないよ。OpenSSLで証明済みじゃないか。
PCですが、室温が何度までだったら耐えられますか? これ以上あがるとまずいという温度があれば教えてください。
スレチだが一応答えると 室温じゃなく、CPU・グラボ・HDDの温度を気にしろ
以下のようなHogeクラス型を定義して、List<Hoge> hoges というリストがあるとします。 class Hoge{ public string Name{ get; set; } public int Age { get; set; } public int Point { get; set; } } この時、hoges の各リストのAgeやPointの合計を1行で取れるクールなLinqを教えてください! foreachなどでくるくるするしかないでしょうか?
>>648 うおおお!超クール!! ありがとうございます。 >>648 こーゆうコード集みたいなものどこかありませんか? 書籍でもいいです。 >>650 LINQの基礎の基礎なんだから これ知らないならコード集の前に基礎学習したほうがええんと違うか >>653 腰据えて勉強なんてしない、必要に迫られて都度聞いたりググったりして断片的な情報でその場をやり過ごすプログラマが大半 それでいいんだよ 時間は有限なんだから腰を据えて勉強する対象は厳選しなきゃ
結局やらなきゃ忘れるしな こうすれば出来るって頭の片隅にでもあればok もちろん知ってるに越したことはない
腰据えて勉強なんかしなくても使うだけなら全然問題ない
30桁の英数字混在パスワード って総当たりで解析無理だよね?
>>657 別に使わなくても同じ事書けるし。 ただ行が短くなるだけ ユニットテスト必須の土壌じゃないとLINQとか他人に薦める気にならんわな メソッドがクソ長くても単体テスト通れば良いんだろで終わっちゃうし
うまく動かないときに ループのときみたいに ハイじゃあどうして第一要素にゼロが入ってるんでしょうか? 的な追い方ができない いっせーのせ! で動かして途中経過が皆無なのは辛い
>>661 メソッドがクソ長いのは別問題 そんなんまともにUnitTestできんだろ >>662 しょっぼw どういうレベルでプログラムを書いてるのか余裕で知れるな お前らマウンティングしないと死んじゃう病か何かなの
独立な処理に途中経過もクソもないわな 処理の詳細を無視して入出力のルールにフォーカスする考え方ができてないとそりゃ難しいだろうな
ラムダ式の部分にブレークポイント置けばそこだけ追えない?
メモリに常駐しているプロセスって簡単に取得できますか?
DOSの時代じゃないので常駐って概念に意味があるとは思えない気が 今でも慣用句的に常駐とか言うけどね
もしかしたらすれ違いかも知れませんが気にせず質問させていただきます 先日パソコンが壊れました 電源をつけると5秒後に再起動を繰り返してしまいます 原因がわからないのですが どなたか対応方法などご存知の方いたら教えてください
>>676 OSは? 機種は古いの? 型番とかわかる? 5秒で再起動する直前の画面はどうなってる? このスレはLINQ大嫌いおじさんがいるからしゃーない もう新しいこと覚えられないんだよ
Linqが新しいってタイムスリップでもしたのか とっくに枯れてるだろ
>>684 そこは立ち位置的に枯れてるって云えよw 普及するわけがないと誰かが言ってたがその通りになった。 ネラーはなかなか先見の目がある。
LINQ普及してないってどこの世界の話? よっぽどレベル低い職場なのかな
>>687 おk、LINQは超流行ってる でも初心者向けじゃないから別スレでやってな お仕事でC#使っている人の何割がC#4.0以降の表記使っているか気になるわ
>>688 むしろ初心者向けじゃね? パフォーマンス気にしだすと、StackOverflowの中の人みたく、全ての.csファイルからusing System.Linqを消し去ったりするw http://libro.tuyano.com/index3?id=1247003 このページにある MyObject obj = new MyObject(); obj.name = "つやの"; obj.age = 123; obj.printData(); MyObjectクラスを使うこの部分はなんといいますか? また、obj を変えて複数の上記のような構成を作るとそれに伴いちゃんと表示は増えますが、 objに当たる部分を必要に応じて動的に増やすということは可能のなのでしょうか? インスタンスを動的に増やす で検索しても見当違いなものがヒットしますので、自分の中で言葉が間違ってるとは思いますが よろしくお願いします よくパフォーマンス云々言う奴が居るけど C#使う用途でLINQ程度のオーバーヘッドが気になるのってどんな場合だよ 書きやすさ捨てても速度ほしいならC++でも使ったほうがいいんじゃないの
>>691 そのレベルならまずは入門書を一通り読もう 時間の無駄だ そのレベルの回答ならまずは入門書を一通り読もう 時間の無駄だ
>>692 StackOverflowの例が出てるやないか .netnativeは早いぞ アレがFormsとかWPFに降りてくることはなさそうだが UWPで作れる範囲は移行するべきだと思うわ
>>695 ググっても出てこなかったんだけどソースある? LINQスレがあったぞ。そっちで聞いてはどうか。 10年で1スレ消費できないぐらい過疎ってるが。
いやStackOverFlowの開発者がLINQ全消ししたって情報出した本人がすぐ上にいるのに なんでそっちで聞かなきゃいけないの
大規模のプログラムを解読する場合にはどういう方法でアプローチしますか?
>>697 >.netnativeは早いぞ >アレがFormsとかWPFに降りてくることはなさそうだが なぜ降りて来ないんだろうなあ 普及させれば良いのに WinFormsとWPFはMSに捨てられたから仕方ないね
>大規模のプログラムを解読する場合にはどういう方法でアプローチしますか? これだけど、本質的を手短に説明できるちょっとレベルの高いひといる?
>>701 リファクタリング コミットはしなくていいぞ >708 バインドって意味不明なんだが、 TEXT = データ って書くのと TEXT ={ バインド データコンテキスト} って書くのでどんなメリットがあるの? というか1000万個のデータある時に1000万個にバインド できんでしょ。バインドできるのはその中の一個だから、データを選択しないといけないよな。 でボタンを押されたら、データを選択して、データコンテキストにほりこむんだろ。代り映えがないような きがする。
>>701 そう、その言葉をまっていました。そのリファクタリングを掻い摘んで説明してください。 >>710 実際、大したメリットはない 最近の流れとしては、Web分野でも一時期バインドが流行っていたけど結局はユーザー操作時の代入に回帰しつつある 所詮は「手作業で代入すんのめんどくせえ」ってだけの問題であって、バインディングはそれだけのために過剰な複雑さを持ち込みすぎている リファクタリングで ★継承を委譲に置き換える 継承では基底クラスのすべてのメンバを、サブクラスに許さなければならない。 基底クラスの一部だけの機能を利用する場合は、継承の代わりに委譲を使う。 これはどういう意味?
>>710 セキュリティチェックが簡単だからでしょ 代替方法あるなら拘る必要ない >>716 それはプログラムを読むための手法でなく最適化するための段取りってのはわかっている? あとはオブジェクト指向とかのキーワードでググってみるほうが速い >>714 デザイン(View)はアーティストの俺が書いて、「土方ロジックは知らん。お前等に任した」っていう時にはいいかもしれない。 しかしその場合にもボタンと同期してデータを切り替えないといけないよね。その仕組みってどうなってるの? ボリュームを回すから、データはそれに合わせてかえてよねっていうようなこと。 >>718 VB6をC#に変更するんだが、VBソフトを解読する場合にはどこから手をつける? 画面数が70程度、クラスが10個、標準モジュールが30個位ある。 とりあえずクロスリファレンスを作ってみようとおもってるんだが、何か方法論とかないかなーとおもっている。 そこでリファクタリングをするというのは一つの手ではある。 VB6ってのは知らないかもしれないが、VBAと同じで標準モジュールというのは グローバル変数で、これが大量にあるので難儀している。
>>716 お前の会社の経営が厳しくなり、無能なお前をリストラしてお前の業務を外部委託することになったとする そのとき、外部の人間を社内に常駐させるか?、それとも社外に丸投げするか? ということ 社内とのやりとりが多い業務であれば前者の方がスムーズだろうけど、 そうでもないなら後者の方が安上がりだし委託先を後で変えることも容易で好ましいだろ >>720 VBなんか知らんし 仕様書があれば仕様書見て作り直し必要な部分だけ元のソース参照する 仕様書が無いのなら動作確認して自分で仕様書書くところから >>719 デザインセンター持ってる会社なら、ホントに分業出来るから楽だと思うよ。 ボタンと同期して中身変える、ってのは、ダミーデータ返す関数と、メソッドのスタブ最初に用意して、それを渡す。なかったら「くれ」って言ってくるし。 どちらも無意味な不幸の無いプロジェクトになる。 >>722 分かり安い説明だが、愛がない。そこもかなり重要だと思う。ところでWPFって やったことないのだが、やってみたい。 最初はVB6のフォームのコントロールのリストと位置を拾いだせば画面は自動的に変換できそうなので そうしようかと思ったのだが、XMALでやるってのは難しいだろうか? >>724 そうだね。アーティストの俺には土方仕事を丸投げできるからかなり有利かも。 >>720 解読するって言うのはまず間違いじゃないかな 顧客から要望聞いてSEが再設計して仕様書作るのが正しい >>仕様書が無いのなら動作確認して自分で仕様書書くところから ソースを解読してその仕様書を書く手順を考えている。うまくコンパイルして動かすこともできたん でソースを解読しつつ整理して、最終的に変換をする。 具体的には 整理 1.クロスリファレンスをだしてグローバル変数を整理 2.画面がやたら多いので手書きで書き直すのはとっても大変だ。 しかし殆どはパラメータの設定のような単純な画面なので、画面の書き換えはプログラムで変換できそうだ。 しかし内部のイベントロジックをどうするかだな。画面はC#でもVBでも好きなように変換できるが、ロジック はC#に変更するのは正気の沙汰ではないな。 やはりVB.netに置き換えるべき。となるとやはりVB.NET Winform以外の選択肢はないのか?
>顧客から要望聞いてSEが再設計して仕様書作るのが正しい もともと正しくないところから出発しているので、正しい方法は取れない。唯一できるのは 自由に作れるということだけ。しかも動きさえすればいいというレベルの客。ただし.netで 作るというのが条件でソースも提出することになっている。C#でもVBでもWPFでも問題ない。 大半をDLLにして、上っ面だけNETでもいい。
ソース提出って下手な仕様書出すより厳しいと思うんだが
>>729 レスを読んで思ったけど本人は真面目なのかもしれないが やってることは素人の趣味の延長レベル それで給料がもらえるって非常にありがたいことだね >プロに頼んだほうがいいよ 頼んだのだけどやる人がいない。
>>720 VS2008まではVB6⇒VB2008へのコンバーターがついてたので、 VS2008かVB2008 Expressをなんとか手に入れて、とりあえずVB2008に変換して みたらどうかなと。 まあ変換精度は高くないので手直ししないとまず正常に動かないし、 返還後のコードはMicrosoft.VisualBasic名前空間とかVBランタイム関数とか 使いまくりなので、それをさらにC#で書き直すのはかなり大変だと思うけど >>720 それは調べてやってみたが、1時間かかっても変換できなかったよ。 一時間たってキャンセルしたら1kのLogファイルが残ってた。 多分簡単なものなら変換できるだろうと淡い期待はもっている。リファクタリングして疎結合にすれば 3つに分解できそう。 IOコントロール DBアクセス 画面 IOが厄介だなーとは思う。多分この部分がよくわからないのでプロは逃げ出す。 >使いまくりなので、それをさらにC#で書き直すのはかなり大変だと思うけど 混在してつかえるし、VBのクラスはそのまま呼び出せるので不都合のある部分だけラッパーすればいいだけでは? それならVBで書けよって話になるかもしれないが、追加部分だけでもC#にしたい。
VB6置き換えは元が酷いスパゲティだしCOMコンポーネントの代替ライブラリが見つかんないと詰むしロクなことにならない 要件定義からリビルドしたほうがマシだぜ
htmlの文章をC#で書くメリットは有りますか? 無ければテンプレ落として来て挿入するだけなんですけど。
>>740 一般論的に言ってリプレースは最後の手段だ 少なくとも数ヶ月はリファクタリング、リアーキティングなど試せることは試した上で それでも手に負えないと判断してからリプレースに着手する いきなりリプレースはリスクがデカすぎる しかしながら経験上VB6の移植は結局リプレースになることが多いんだわ >>738 確かにそういうばあいもある。モジュールが多いのが問題だけれどもクラスを使っているから、そんなに下手なプログラムではないね。 VB6でクラスを使っているとまあまともだね。 >>742 UI class : other class : static class = 7 : 1 : 3 かなりバランス悪いと思うぞ 綺麗なソースになってるとは期待できない >>726 工業デザインの人に、アーティストと言うと鉄拳飛んできたイメージだが、今のデザイナーはアーティストはなのかな。 俺もデザイン系の単位も資格も持ってるけど、アートと思った事は無いなぁ。 VB6のコードを解読しないといけないアーティストw システムの内側からじゃなく外側から整理して ユースケース単位や機能単位でコードリーディングしていくのが効率的
プログラム本体やシステム全体の仕様が分かってるならゼロから書き直した方が 結局早いと思うけどね。 そもそも今更C#でに移行するのは、将来手を入れる可能性があるからじゃないの? だとしたら長期的なメリットデメリットを考えてもそうした方がいいよね。 「動いてるプログラムを触ってはいけない」ってのは個人的にはダメな人の台詞だと思うね。 それ、自分のコードを理解する能力が不十分だって語るに落ちてないか?
COMとドトネトの相性が良くないのは意外だったなあ
>>747 理論上触らなければバグらない以上 用も無いのに触る一手はないな >>749 だから、「用がある」から今更C#で書き直すんでしょw 間違った前提から間違った結論を導いてもしょうがないよww 既存のクラスを触りたくないといって 間違った場所にコードを追加していったやつがおってな 気がつくと見事なスパゲティの塊が出来上がっていたんだとさ
>>747 詳細仕様が分かってないからコードを読もうとしてるんじゃ? >>750 それは現状が正解じゃない状態になったのかい? 技術的アプローチに対してアーティスト的アプローチもある。そもそも専門家が遣らないという のは技術的に興味がない。もしくは打算的技術者なら経済的に見てもメリットがないということだ。 つまり儲からない。そういう結論がでている。 しかしアーティストの見解は違う。アーティストにとっては技術とか打算とかの優先順位は かなり低い。すべての仕事はどう料理するかがアーティストのアーティストたる能力の発揮し どころだから、技術屋から見るとかなりリスキーであっても敢てやってみる。
>>752 表面的な仕様というかパラメータの設定とか動作などの取り扱い方法は客先で大体はわかる。 しかしメカの細かい動作なんかの部分は一切分からない。動作検証は客先でやってくれる。 結果が正しいかどうかは客先でわかる。 >>720 昔、なんかのツール使ってVB6を.NETにしたよ。 急には上がらないから2005にして2008にして2010だったかな。 段階的に変えていく。 それぞれの.NETstudio使う。 前のバージョンを上げられるよ。 2005から2010とかは確かできない。 で、最後にC♯にすればよくね? VB6から2010までは一気にいけたはず そのあと2013までいったら2017まで共通
上にすでに書いたけど、VB6のコンバーター(アップグレードウィザードとか言ったと思ったけど) がついてたのはVS2008までだよw
マジか VB6を2010で開いた記憶があったがボケちゃったな すまんこ
>>763 発言には責任を持って手で変換してね はぁと コンバーターってロクな結果にならないアレか 手で移植したほうがマシって有名なやつ
前VB6を.NETに移行する案件あったなスルーしてよかった新人突っ込んだらしいし 配列要素の1始まりとか鬼門過ぎるVB6触ったこと無いが
>>766 だめな会社だな そういう案件にこそ玄人を投入すべき (玄人=知らない言語でもコードが読める能力を持つ者) VB.NETの配列はX(N)で宣言するとX(0)〜X(N)まで確保される仕様だから、 VB6からの移植の場合はX(0)を無視すればインデックスはだいたいそのままで動くぞ 汚いといえば汚いけどこの仕様を決めた奴は有能だと思う
BASICのBの意味を考えれば、その方がとっつきやすいという判断でしょう。 プログラマの視点で考えれば、0オリジンの方がきれいに実装できるに決まってるし
VB6でもデフォルトはOption Base 0だろ?
配列が0スタートのせいでバグが量産されてるという気もするが それは個人の考え方次第 配列1個目が0番 配列2個目が1番 配列N個目がN-1番
>>768 ソースが出てこないが.Net化の際にゼロで統一するようにしたら ベータ版の段階で世界中からクレームのフィードバックが沢山あったので その折衷仕様になったはず。 ゼロで統一じゃないや。C系に揃えるってことでした。 ExcelのCellオブジェクトと関連させる場合は 1スタートto要素数=最終行or列で合う
Cの基本はポインタで、配列ってのはポインタのシンタックスシュガーだからね 添字は*(p+x)のxだから0始まり
折衷っていうか文化の違いでしょ C系と違ってVBの配列作成時に指定する値は、添え字の最大値ってことになってたはず
抽象クラスのoverride で、型を変えるような事はできるでしょうか? 以下のようなコードが書けるかなと思ったのですが 戻り値はあくまでList<object>でないとダメみたいなので 書く方法があればお教えください public class hoge { } public class fuga { } public abstract class Base { public abstract List<object> GetData(); } public class SubOne : Base { public override List<hoge> GetData() { return null; } } public class SubTwo : Base { public override List<fuga> GetData() { return null; } }
それはシグニチャが違うから別メソッドじゃ? overrideはずしてみ
これじゃいかんの? public abstract class Base<T> { public abstract List<T> GetData(); }
同じGetDataメソッドで別のデータ取得させたいのはなんか理由あるのかね hogeとfugaが抽象化できるならともかく
typescriptやjavascriptから流れてきたんだろうな と勝手に妄想
>>784 戻り値の型だけ違うシグネチャは判定ができないから設定できない 関係ないけど戻り値はインタフェースで返してくれよな
>>788 他言語で実現できてるのは戻り値型の共変性ってやつなんやね。 勉強になったわ。ありがと。 本来は継承で解決すべき事柄じゃないものも何でも継承で 解決しようとする
一見>>785 でよさそうに思えるが よくよく考えると使い道が分からん Base<hoge> と Base<piyo> は違う型になるので それらを継承したクラス同士も違うクラスから派生しているっつーことで 統一的には扱えなくなる 差分プログラミングがしたいならそれでよいが なら、Baseクラスのabstractの意味は何だ? 783ですが、抽象化したテーブルクラスを作って、テーブル単位で選択結果を返す具象クラスを作りたかったのですが、Dapperを使うのでメソッドの戻り値がList<T>となり戻り値の型が具象クラス毎に違っています こういう例が無さそうということはアンチパターンやってるでしょうか
>>795 interface IDao<TEntity, TId> { TEntity ReadOne(TId id); IEnumerable<TEntity> ReadPage(int pageSize, int pageIndex); void Create(TEntity e); void Update(TEntity e); void Delete(TEntity e); } class FooDao : IDao<Foo> { ... } これじゃいかんのか? >>797 テーブルのみを扱うので同様の属性という意味で抽象クラス使ったのですが、インターフェイスで選択したデータを返す機能として定義した方が良いでしょうか 抽象とインターフェイスの使い分けに今ひとつ自信がなくて >>798 使い分ける必要はない is Aだのcan Aだの言ってたのは昔の話で、今時はどうしても実装を継承する必要がある場合以外は基本的にインターフェースを使う もっというと、実装継承のために抽象クラスを使う場合はインターフェース継承とは本来区別して考えるべきで、 インターフェース←抽象クラス←具象クラス という継承関係にするのが理想 抽象クラスはあくまで実装の共通化のためのツールに過ぎない Table<T>を作ってGetData<T> それ以上の機能を使いたかったら適当なクラスを作ってTable<T>をコンポジション
>>799 何が良くてそんなことやってんの? 変更があったら変更すればいいじゃん >>799 それはDIってデザインパターンでしょうか なんか教科書のインターフェイスと使い方が違うので理解出来なかったのですが インターフェースは、has-a、部品化。車とハンドル。 抽象クラスは、is-a、継承。車と消防車 継承は、クラスに親子関係がある。 非常に似ているもの同士 部品化は、全く異なるもの同士 DI は、XMLなどの設定ファイルから、クラスを自動的に作る、ジェネレーター
>インターフェースは、has-a、部品化。車とハンドル。 ↑これマジ? でも>>799 では「can A」って書いてあるよ 大マジ? そんな説、聞いたことないんだけど てかそんな(脳の)状態でプログラム書けるものなの? C#優秀すぎだろ
スッキリわかる Java入門 第2版、2014 Javaの人は皆、この本で、オブジェクト指向を学ぶ。 というか、日本では、この本しか無い だから皆、C#をやる前に、Javaから勉強する オブジェクト指向の最初のクイズが、is-a, has-a の例題
>>808 外国人みたい言葉遣いしてんな いつの間にか2chもグローバル化してたのか そして謎の熱いjavaのステマ付き で、最初のクイズで間違ってたら、どうしようもなくね? has-aはコンポジションであってインターフェースは関係ない
この人あちこちのスレに突如出現しては的外れで一方的な持論とともに書籍を紹介する変な人だよね 書籍宣伝のボットなんじゃないかという気もするけど、もし人工知能だとしたらかなり優秀だと思う
「たのしいRuby」「みんなのPython」とか、 掌田津耶乃の「はじめてのJavaScript」では、 オブジェクト指向の説明は、数十ページ 一方「スッキリわかる Java入門」では、250ページ! 他を圧倒してる 漏れは、10言語・数十冊以上は読んでる 本を読む順番は、 1. スッキリわかる Java入門 2. たのしいRuby 3. みんなのPython C# なんかは、後の方
>>812 文法解説ばっかりで作って覚える系の本が無いな なんか具体的にアプリケーション作れる本があった方がいいんじゃないか? >>812 >10言語・数十冊以上は読んでる バカじゃねぇの? java,ruby,pythonの入門書に共通してるのが作って覚える系の本があまりない javaはandroidのアプリの本が数冊だが出ているがandroidなんだよね エミュでしか動かせなかったりイマイチ そういう意味で入門書にはc#をオススメしたい これならwindowsアプリが具体的に作って動かせるので絶対に初心者にはこちらのがいい csvやxlsファイルの処理やDB接続の処理が書いてあったりするのもGood
スッキリは詳しい説明をはぐらかして初心者を誤魔化そうって思惑が透けて見えんだよね
>>812 ちゃんとコテハン登録しとけよ NG登録しとくから >>806 has-a capability 部品化とは違うけどね UnityのためにC#もちょこちょこ勉強し始めたけど、Javaと大分似てるんだなこれ 本買おうと思ったけど、完全な新規向けのじゃなくて 言語仕様についてわりとがっつり書いてあるような本でお勧めってあります?
クラスの機能はできるだけ簡素にを守っていると is-aでいられるのは本当に基本的なクラスだけになる 普通にやってると絶対has-aの関係になる 継承を有効に使えるのはほんの一部
>>823 c#最新? で無いなら折角買ってもなぁ >>821 少し古いがCLR via C# C#やってて読んでないとモグリと言われる一冊 >>831 独習c#ってc#のバージョン的に最新出てんの? >>831 どれもハズレだな CLR via C# まずはこれを読もう >>832 出版日から見るに最新のバージョンには対応していないように見えます >>833 ひとまずはコンソール上で動くプログラムを作ってみようと思ってます 後々はデスクトップアプリやUnityなどに手が出せるという理由でC#にしました >>834 英語に疎いおかげで良書でも読めません・・ C#7.1なら本どころかMSDNのリファレンスじゃないと無理だろ >>831 上に出ているじゃないか>>823 基本部分網羅してあってタダで見られるのだから本買う必要はない >>836 最新版を追うなら本では厳しいということですね 目次を流し見してみましたが確かに入門には十分すぎる内容でした ここで勉強してから本の購入を検討してみようと思います 今のC#ってgithubで言語仕様決めてるからな もうプログラミング言語は本で覚える時代じゃない
>>838 githubってそんなに活発なんですね 仕様が議論させるとは >>835 "CLR via C#"は和訳本出てるよ。 タイトルは"プログラミング .NET Framework"。 最新のは第4版。 >>840 和訳ありましたか、ありがとうございます .NETとやらが必要になったタイミングで買おうと思います 書籍もいいがM$燻製のChannel9とかもありじゃね 偶に裏話とかあるし なんでC#(名称)になったとか(あっ知ってたらスルーね)
>>841 .NETが必要じゃないc#の用途の方が珍しいと思われ >>837 えーでも結局誰かが書いたコードを辞書的に調べたいからそういう本欲しいんでしょ? 最新に対応してないのは困るなぁ タプルとか出てこないね 最近書籍の対応遅いよね >>844 小さなバージョンアップを繰り返すようになったからね C#開発のメインストリームがWeb系のバリバリな連中の方に移ってしまって、 書籍の主な購買層であったドカタ系が完全に取り残されて新機能に興味を示さなくなってしまったのも大きい >>831 独習とイディオム読んだ独学だけど、一通りの事はできるようになったよ。 api呼んでみたり、データベース連携したりね、 独学やったあと、イディオム読めばええんちゃう? このプログラムを作りたいんだけど 仕様が ・ルートフォルダ 手入力でディレクトリ先のパスフォルダを削除する事ができる ・参照 押してフォルダを選択してパスをルートフォルダのテキストボックスに表示 start ・クリックするとカレンダーが出てきて、そこから日付を選択 End ・start〜Endの期間の日付フォルダをまとめて削除できる 上記二つはできたけどstart〜endが分からん… 新人プログラマーで入ってまだ4日目なんですが 20時間以上やってるけど全くできない… みんなこんなの本当にできるの? 入ってすぐ社内ではもう既に無能扱いされてますヾ(。>?<。)ノ >>847 そりゃそうだよ 無能に決まってるじゃん そんな問題は10分でできるようになってから入社するのが世界の常識 日本は非常識だから素人でも雇っちゃうけどね >>848 やっぱそーなんですねぇ(´・ω・`) 日曜日1日使って、出来なかったら 向いてないので退職してきます 有難うございます >>847 「C# Forms カレンダー」と「C# ファイル 削除」でググれ >>842 C#に決まった由来は気になるので時間あるときにみてみます >>843 となると遅かれ早かれ必要になりそうですね 学ぶタイミングが難しい気もしますが >>844 もともとその用途で購入を考えてましたが周りの方が言う通り ネットの恩恵に預かろうかと思います >>846 参考になる経験談ありがとうございます WEBの勉強で不足を感じたら独習→イディオムのように勧めていこうかと思います >>847 勉強の基本なんだけど。 「分からない」時にはなにが分からないかを列挙して、それをさらに細かい要素に分解していく。 分解して考えれば・調べれば分かるようになったら、それをひとつひとつ解決していく。 847 を読んでもなにが分からないのかこちらに伝わらない。 つまり自分でなにが分からないのか分かってないんでしょ。 もっと整理してみたら? ちなみに新人というか数年程度のヤツにそんなたいしたことは求めてない。 きちんと適切な質問を出来るようになればそれで OK だと思うよ。(ちょー難しい要求だが) 特に1年目なんて、なにを聞いても許される二度とない重要な期間なんだから、それを有効活用しない手はない。 最悪なのは自分で抱え込んでなにも進まない状態だよ。 >>849 今できることよりも 継続して勉強できるかどうかのほうがずっと大事 1~2年継続して勉強すれば周りのやつ全員追い抜けるよ ただし基礎的な能力が高いやつに限るが (論理的思考力、自然言語能力、メタ認知能力等) >>849 >>853 のアドバイスをよく聞くといい 自然言語能力・メタ認知能力をある程度身につけてる良い手本 勉強の仕方を勉強すること 無能な働き者に分類される人は自然言語に傾倒しがちだよね ダラダラと長く曖昧でわかりにくい文章が数式なら僅かな記述で明確に表現できることもある 理解するのに時間がかかる難解な文章が図表なら瞬時に把握できることもある もちろん自然言語を全て否定する訳ではないがバランス感覚は大事なんだな 自然言語はあくまでツールのひとつ
最近、イディオム買って読んでるけど、この本読んでる方って多いんでしょうか? 独習C♯読んでから、独学で色々とプログラム作ってましたけど、 OOPの考え方とかまったく知らないでやってたもので、コードが散らかってます staticおじさんになってたり、クラス分けても結局再利用しないような内容、関数コピペ メインメソッドから分離してるだけで、メインメソッドに膨大な量書いてるのと大差無い感じです 再利用の仕方とか勉強する為にイディオム本どうかなって見ましたが、みなさんはどの様に覚えたんでしょうか?
>>849 はまだ入って4日目だろ こんなツール作らせてる教育環境がどうかしてるんじゃないの? >>860 せめてツール作らせるなら段階的にやらせるわな クラスやメソッドの組み合わせ考えずに、とりあえず出来ましたで終わりそう >>859 再利用は出来れば良いね程度の気持ちで クラス分けの目的は色々あるけど主に責務の分割な 例えばパソコンに暖房がついてたら嫌だろ 持ち運びもできず 夏場は邪魔になるだけ 暖房機能が壊れたら壊れてないパソコン部分もまとめて修理に出さないといけない 普通と勝手が違うから暖房の起動方法がわからない(セットのパソコンでコントロール?リモコン?) パソコンを拡張したいけど暖房機能を壊してしまわないか不安になる 問題だらけだ だからパソコンとエアコンに責務を分けようってわけ これなら先に挙げたようなアホくさい問題が全部解決するだろ >>863 機能の分離でクラス分けすると今度は必要なクラス探すの大変になる感じですかね? 後はどこまで繋げてどこから分離するかも中々難しく感じます 例えばエアコンのコレクションを扱うとして、エアコンの寒暖房機能、温度検知機能、タイマー機能、設定 などエアコンの中を細かくするのが苦手なんですよね 自分がよく作るのは株価を扱うプログラムですが・・・ >>863 どうでもいいがテレビデオを思い出した >>864 >中を細かくするのが苦手なんですよね それはクラス設計つーより、要件定義の段階でないの 要件が明確なら、作るべきクラスも自然に決まって来るっしょ >>864 オブジェクト指向設計の本質は、設計を人間の感覚に合わせることだよ 分けることを目的にしたらダメ 人間の直感は設計の指針として明確でわかりやすいし、 オブジェクトの単位が直感に合っている限りは破綻しない(というか、少々無理が出ても破綻したように感じない) >例えばパソコンに暖房がついてたら嫌だろ 俺もそう思っていた時期があったけど Skylake-XとVEGAの組み合わせだと真剣に暖房かもしれない こういうのも出るし https://www.apple.com/jp/imac-pro/ 後、質問者に何か助言できるなら、オブジェクト指向はそんなに真剣にしなくてもよいよ 大事なのは手続き型プログラミングが ・データ構造 ・制御構造 という二大要素で出来上がっていることに気づくこと データ構造とアルゴリズムともいう データ構造と制御構造をそれぞれ別々に思い描いて その上で、データ構造と制御構造の両方を持つ「class」に分割するには 何処で切り分けたら一番「制御構造の見通しが良いか」を考える 大事なのは制御構造について意識することで、というのもオブジェクト指向でやると データ構造の方は勝手にきれいになるから意識する必要はないのでね C#のasync/awaitも制御構造をきれいに保つための仕組みだしね 最近の流行りというか、流れ、トレンド なんであまりオブジェクト指向に肩入れしていると この人はややこしい人だと思われる風潮 オブジェクト指向設計というのは 制御構造とデータ構造という二つのものを考えて 小分けにしてclassという一つのものにまとめる作業 と考えていいと思うよ 二つのものを綺麗に切って一つにして小分けにするのは 高度な作業かもしれないけど、十や百じゃなくて高々二つなんで まぁ慣れです
>>866 設計書を表現することだろ? 直感は人間同士でズレる 過去の自分とも 実装レベルの設計とドメインのモデリングの話がごっちゃになってる気がする ドメインモデルはまず人間の感覚から入って、そこから実装に落としていく段階で制御構造の観点を入れていく感じだね
ありがとうございます OOPの人間の感覚に合わせる意識が大事であって、分けることを目的にしないってのは大事だなって思います 難しいですが・・・ そういう意味だと、プログラムを少し修正したい、機能追加したいって思った時にバグが出にくい、追加しやすい状態にしたいですね OOPに拘りは特に無く、あくまでソース管理や生産性の向上が目標です 曖昧な目標なので、実現するための手段で手こずってますが 自分の作るプログラムは目的上、同じデータから色んな値を作ったり検証させるので、使いまわせるところは汎用性がほしいんですよね 毎回別のプログラム作るたびにプロジェクト作って一部関数使いまわし、既存プロジェクトのクラス参照で使ってますが、 いつの間にかプロジェクト別で関数が別物になってしまったり、参照クラスの仕様変更で他のプロジェクトに影響出たり、設計が大変なので・・・
>>847 いまいるおっさんたちは就職する時点でアマチュアプログラマ歴10年以上だよ 新卒でプログラミング経験なしだと無能扱いされて当然 まずは答えを見つけて写経しろ ペンでもキーボードでもいいから丸暗記するまで書き写せ 話はそれからだ ちなみにベテランだったら30秒ぐらいで作るぞ コントロールを配置するだけで30秒はかかるんだけど
高校から始めたから、新卒時点で10年以上では無かったな 大学から始める様な人もいるし、適当言い過ぎだろ 新卒未経験は流石に、採用されてもPGじゃなく別部署に回される気がするが
新人は研修する前提だから最初からそんなに高度なことはできなくてもいい 実験データのテキスト読み込んでデータベース化しましたとか サークルのWebサイトをメンテナンスしてましたとか 論文書くために自力でLinux TeX環境整えましたとか エロ画像収集ツール自作しましたとか そういう学生らしい微笑ましいIT体験談を聞ければ充分 あとはやばそうな精神疾患とか障害がなければ合格だね ただし 何にもしてこなかったけど興味と熱意はありますってやつと エクセルでマクロ組んでましたをやたら強調する意識たかそうなやつ プログラムは書かないけどITパスや基本情報をアピールするやつ これは地雷なのでその場で不採用にチェックします
あと彼女いないやつは不採用だな あれは人間として駄目すぎる
「ぼくにとってはコンパイラが彼女のような存在でした」
オブジェクト指向はプロジェクトが大きくなるほどベストの設計は存在しないんじゃないかと思う ベストを目指しベターを繰り返していくけど結局正解はないと思い知らされる
成果物に問題がなくて、そこそこ保守性が良ければ 無理にベストを目指す必要も無いからね ベターをベストにする労力を掛けるより、 その労力で別の事をした方がいい
>>879 そういうものだよ だからカイゼンを繰り返せるように設計する 最悪な設計は間違った設計ではなく変更が難しい設計 現代のOOPの常識だね 変更のしやすさって開発スタイルに依存するからなあ システムを作る側とそれを利用する側とで責任が分かれてる体制下においては、 綺麗なドメインモデルを継続的に改善し続けるなんて不可能 ひたすらコントローラでSQLを垂れ流す方が遥かに変更しやすい
長大で無数のSQLなんてメンテしたくないよ リポジトリパターンにしておけば1時間もかからない仕様変更に何日もかかるようになる テストの工数も考えると辟易するね
>>882 コントローラーでSQL垂れ流しって時点で、UnitTest考慮ゼロだな 設計フェーズでちゃんと客と握ってれば仕様変更は客に相応のコストを請求すればいいでしょ 変更にかかる工数はトランザクションスクリプトなら高精度で簡単に見積もれる 変更しない前提ならテストなんか画面でポチポチしてExcelにスクショ貼り付けた方が早い >>882 で変更しやすいと言ったのは運用保守フェーズに入ってからの話ね 簡単に変更コスト見積れるトランザクションスクリプトのシステムなんて見たことないな どこで何をやってるかすぐにはわからない SQLが酷いと優しく言っても地獄
> だからカイゼンを繰り返せるように設計する 思いつきで仕様決める奴の理想。現実は一度決めた仕様を捨てることは困難。
>>887 仕様と実装の区別も付かないあたり初心者スレらしくて微笑ましい List<int> suuji に入ってる一桁、数百の整数リストを3個ずつに纏めて新たなList<int> suujibunkatuに入れる作動を希望 C#の仕組みを理解するためにいろいろな方法を試しています 以下ソース List<int> suuji = new List<int>(); //この後、suujiにはLoopで回した一桁の数字が数百入ります List<int> suujibunkatu = List<int>(); foreach (var unit in suuji.Chunks(3)) { Console.WriteLine(unit); suujibunkatu.Add(unit); } //以下ネットからコピペした拡張メソッド public static class Extensions { // 指定サイズのチャンクに分割する拡張メソッド public static IEnumerable<IEnumerable<T>> Chunks<T> (this IEnumerable<T> list, int size) { while (list.Any()) { yield return list.Take(size); list = list.Skip(size); } } }
やりたいことはforeachの中でList<int>suujibunkatu に三個ずつに纏められたunitの中身を次々に入れていく作動です ここで、以下のエラーがでます 引数 1: は 'System.Collections.Generic.IEnumerable<int>' から 'int' へ変換することはできません。 場所はsuujibunkatu.add(unit)のunitに赤線になります 引数1 はList<int> suujiの最初の数字である1だと思います。 どうやって解消したら良いでしょうか? unitに入ってるのがint[]のような配列だと思うのですが…それが原因なのかもわかりません int[]に入ってる配列をint化する必要があるという感じでしょうか? 拡張メソッドの中身はまだ理解できてないので、拡張メソッドの方を改造しない方向で、のちのち拡張メソッド内を把握していこうと思っています 3つずつまとめる他の方法は出来るのですが、この拡張メソッドの中身を把握するために、使う部分でのエラーをなくしたいと思ってます よろしくお願いします
>>890 List<int> suujibunkatu = List<int>();にint[]をAddしようとしてエラーになってる 3つずつ格納するならList<int[]>にしないと エラーメッセージに全て書いてあるのに何で読まないんだろ
>>891 うぉぉおできました ありがとうございました なるほど… リスト入れ子で使ってたけど、最近はクラスで中身決めてから使うようにしてます・・・
ディクショナリリストリストディクショナリディクショナリリストリスト…
女性客はリストの演奏で興奮のあまり失神者多発だったからなあ
練習でコンソールアプリケーションで迷路のようなのを作ってます 開始からゴールまでの時間を表示することはできたのですが、これを毎回記録しつつ、あなたは○○秒です〜現在○位です! のようなランキングを表示できたらと思ってますが、どのような方法が考えられるのでしょうか?
>>906 MySQL使ってDB構築してるわ DB構築、そこからプレイヤーのidをキーに保持して、秒を保存すればええんでね? ランキングはListとかでソートしてインデックス+1で表示 同率とかの処理必要ならメソッド作る感じで オススメのDBはよく分からないけど >>906 1. 記録はファイル出力/ 順位表示時に毎回ソート 2. SortedList等を使って記録時にソート済みでファイル出力、起動時等にSortedListの構築が必要 3. DBに記録、順位表示はDBからソートした結果を取得して表示 自分だけでプレイするのなら1で十分だと思うが 練習なら上から順番にやっていくのでもいいかもね DB使うならSQL CEかSQLiteかな ブラウザに記録する、Web Storage どこかのサイトのランキング・サービスとか
つか、その程度のデータならxmlかjson使ってクラスをシリアライズするのが良いよ
適当なBaaS使うのが簡単だろうね やる気があればAWSで API Gateway + Lambda + DynamoDB ならほぼメンテナンスフリーで余裕で無料枠に収まる
@ 記憶媒体からデータを読み込む。読み込んだ順番を保ちつつリストを作成する A ゲーム開始→終了 B @のリストの先頭から見て行き、新しい記録より大きい要素の1つ前に挿入する。(挿入した位置が順位) C 表示処理 D リストデータを記憶媒体へ書き込む ソートは不要。 DBを使う要件がないのであれば記憶媒体はtxtファイルで十分。
>>906 テキストファイル名に名前秒数を適当な区切りを入れて保存 山田,60,田中,75,伊藤,81.scr エクスプローラーからF2で編集可能 エディタもいらない もちろんファイル名に使えない文字はあらかじめ除外だ ネットを見ていたら、インターフェースで依存性を排除するコードが 例として出ていたのですが「コンストラクタでengineに実装を注入する」とある部分は、どのように書けるのでしょうか? インターフェースには実装が書けず、コンストラクタでメソッドを書くこともできないので見当がつきません よろしくお願いします public interface Engine { void start(); } public class Car { public Engine engine; public Car() { // コンストラクタでengineに実装を注入する } public void go() { engine.start(); // <- Engineはインターフェースなので依存性がなくなった } }
Engineインターフェースを実装したエンジンのインスタンスを 何らかの手段で手に入れてengineに代入しろってことだな つまり、君の買った車にはエンジンが付いてないので 買ってくるか、自分で作るか、好きにしてもらったらよいが エンジン作る部分までは説明しないよ、ってことだな
>>915 CarはEngineに依存してるよ インターフェース使えばEngineの実装には依存しないようにできるけど インターフェースなので依存性がなくなったというのは認識として間違ってると思う んで実装を注入する方法はいくつかあって、例えばコンストラクタ・インジェクションなら Carインスタンスを生成するときにEngine実装のインスタンスを渡してあげるイメージ public Car(Engine engine) >>915 依存性云々はとりあえず今は聞き流して、インターフェイスの使い方を覚えるのがいいねw >>915 基本的にフィールドをpublicにしちゃだめ メソッド名はPascal 質問とは無関係だけど >>915 なんで依存性を無くしたいの? 変更が必要になったら変更に必要なお金を貰えばいいじゃない? 君が依存性を無くした機能が将来的に役に立つ可能性は100%なの? >>921 こういう質問からズレた的はずれなこと言うやつってどこにも湧くよな yahoo知恵袋とかにも多いけど 初心者スレだし 意味のないことをやってる人間を止めるのも優しさだろ 明らかに意味がない
>>921 将来保守される保障あんの? で、突き詰めたらメインメソッドだけで良いという結論に行き着きそうだな >>924 実際、機能10個作って10年で内3つしか変更が入らないときって 残りの7つに費やした依存性解消の時間って無駄じゃね? いつ精算できんの? 変更することになってからゆっくり金貰って変更すればいいよ 予めやっておく必要も金も時間も欠片もない >>921 え?ユニットテストしないの? まじかよ >>915 を書き直すとこういう感じだろうか public class Car { private Engine engine; public Car(Engine engine) { // engineのインスタンス生成は外部で行い、 // その参照をEngineインターフェースの変数として保持する // (渡されたクラスにEngineインターフェースが実装されているか // どうかしか感知しない) this.engine = engine; } public void go() { // コンストラクタで渡されたEngineを使うので、 // インスタンスの実装には依存しない // (実際に渡されるクラスで変更があっても、 // それがEngineインターフェースに関わらない部分なら影響がない) engine.start(); } } あと、↓に従ってくれると、他の人からも読みやすい インターフェイスの名前付けのガイドライン https://msdn.microsoft.com/ja-jp/library/cc433279 (v=vs.71).aspx "インターフェイス名には、この型がインターフェイスであることを示すために、プリフィックス I を付けます。" メソッドの名前付けのガイドライン https://msdn.microsoft.com/ja-jp/library/cc433282 (v=vs.71).aspx "Pascal 形式を使用します。" >>927 命名規則持ち出すんなら、メソッド名もPascalにしろよ それからフィールドはreadonlyにして_engine、thisは消せ >>926 依存先を先に作ればいいだけだよ まさかDI使うプロジェクトは作るクラス全部疎結合にするとでも思ってるのか? 下位のモジュールを結合した状態で単体テストするのはおかしなことではないでしょ MSだって普通にクラスの中でnewしてるよ 見境なくDIすると結合したときとのギャップが大きくなりすぎる ○○サービスと呼べるような粒度の低いクラスだけにとどめるのがいいと思ってる
>>930 こいつUnitTestしたことないだろ 粒度も基準としてはあるが 自前のコードで完全に制御できないものはどこかで注入したほうがいいな 注入は別にインターフェースでなくてもいい 単にoverrideでもdelegateでも用途(今の文脈だとユニットテストか)に合えば良い 古い言語だとテスト用のモジュールをリンクしたり マクロやインクルードで注入することもある
>>934 単体テストと結合テストの違いはテストケース 単体でも通るテストか、結合してないと通らないはずのテストか、それだけのこと 開発順序の都合とかネットワークに依存しててクソ遅いとか意図的に発生させるのが難しいエラーがあるといった特別な理由がない限り、 単体でも通るテストを結合して動かすことはなんら単体テストの意義を損なうものではないよ 職場はユニットテスト何それ?だから1メソッドが数百行どころか千行超えるコードざらに見かけます・・・
>>936 結合してテストして失敗したら テスト対象が悪いのか依存先が悪いのか切り分けが面倒だろ やれやれだぜ >>939 よく考えよう それ結合テストで起きる問題を先送りにしてるだけだろ? むしろ単体テストレベルで見つかったほうが範囲が絞られてる分原因を特定しやすいよね ワッチョイ b769-ZN1Y) ワッチョイ 236e-nkYL) ブーイモ MM26-nkYL) w
>>938 わかる 汎用機型のプログラミングから抜け出せなかった企業はこれからどんどん終わってくよね >>926 それしないとユニットテストってできないの? 無駄なことやってない? 使い方知らないの? 質問者そっちのけで盛り上がってるねw >>915 が読んだ記事の著者のいう依存性の排除っていうのは恐らく、 Enineのコードが修正されてもCar側のコードがその影響を受けないようにする、 っていう程度の意味。(CarとEngineは別の人やチームが書いてると考えて) そのための手段として、Carのコードでは具体的なクラスEngineではなく、 Car側のコードを書いている人、または第三者が定義したIインターフェイスEngineを使い、 EngineにはIEngineの実装を強制する。 そうすればEngineを書いている人はIEngineによって拘束され、 Car側(Engineを使う側)のコードが動かなくなるような変更はできなくなる。 まあたぶんこんな感じ。 だけど、下位の側のコード(この場合はEngine)を拘束するために わざわざインターフェイスを使って抽象度を上げる(つまり可読性は下がる)必要が 本当にあるのかは、個人的にはかなり疑問。鶏を割くのに牛刀を使う感がある。 まあ質問者に確実に言えるのは、上にも書いたけど 依存性云々なんて理解しなくても問題ないから安心して読み飛ばしていいよってことw 依存性をどっかで断ち切らないと、変更の影響が波及し過ぎるからだよ その例で言うなら、Carの実装内容がEngineに直接依存してると Engineを修正した時に、Carも修正しなくちゃならなくなるので、それを断ち切りたい訳だ 実際には、その2クラス間にしか依存関係が発生しないなら纏めて修正でもそこまで困らないんだけど クラスAにクラスBが依存、クラスBにクラスCが依存、クラスCにクラスDが依存……って連鎖してく様な形になってると最悪で クラスAを修正した結果、クラスB〜Dも全部修正とかになる可能性がある
すまん 汎用機は細かくプロセス分けて作るから単体テストはわりと容易だよ そのノリでVBやJavaモノリシックなアプリを作ろうとしたところでおかしくなった
>>947 設計変わってねぇのに テスト数が増える話してんの? ないとは言い切れないないけど考慮に入れるには頭悪くね? >>951 まともじゃない人って 何年もビジネスでやってるのに 金にならないプログラム組む人? 未だにVB5の保守案件を手放せていない俺は、きっとまともじゃないです
1秒毎にボーリング処理するなかであるクラスのメソッドを呼び出す場合、毎回newするのは悪手ですか?staticが基本でしょうか?
自分で分かってるくせに 中身をしらん俺には答えは分からんがな
>>957 staticってのは意味不明だけど(フィールドじゃないの?) 基本的にどっちでも書きやすい方でOK もちろん高価な共有リソースを使う場合は別 >>957 重いリソース抱えてないなら毎回インスタンス作って良いよ >>957 そのメソッドをアクセスしやすい場所に置けばいいだけじゃないの? 単純に使うクラスにメソッドをコピーするか必要なメソッドだけ分離してクラスにして今まで使っていたクラスではフィールドで持っておけばいい >>957 >>958 の言うとおり 1秒毎にポーリングする処理というだけでは 毎回newするのが悪手かどうかstaticメソッドにするのがいいかどうかは誰も分からない 1. どういう選択肢があるのか考える(調べる) 2. それぞれのメリット・デメリット/トレードオフを理解する 3. 状況や目的に最も適している選択肢を選ぶ こういう選択思考を繰り返すのが設計・コーディング時の考え方の基本 他にも選択肢あるから怠けず1.からやるのがいい 状況や目的をきちんと提示すればいいアドバイスが貰えるかもね もう実際にやってパフォーマンスモニタでログでもとってみりゃいーじゃん的な
パフォーマンス的に問題ないかを確認するのが目的ならね。
JSON のシリアライズで教えてください。 派生先クラスのインスタンスを、派生元クラスのシリアライザで処理できないでしょうか。 こんなクラスがあるとします。 (書き方については大目に見てください) class Data; class ItemData : Data; これをこんなことは出来ない物でしょうか。 var data = new ItemData(); (new DataContractJsonSerializer( typeof( Data ) )).WriteObject( stream, data ); この場合なら、こんな風に回避できるのですが。 (new DataContractJsonSerializer( data.GetType() )).WriteObject( stream, data ); こんなクラスのインスタンスに (AssemblyDataのインスタンス).data = new ItemData(); でシリアライズしようとすると実行時にエラーになります。 class AssemblyData { public Data data {set; get;} } ネットで見た範囲では DataContractJsonSerializer は多態に対応していると書かれた記事もあったのですが、どうにもうまくいかず。 方法があるようでしたら教えてください。
EventArgsとか毎回newしてるし全然問題ないでしょ
>>966 例外メッセージにどうすれば良いか書かれてると想うけど > DataContractSerializer を使用している場合は DataContractResolver を > 使用することを検討するか、静的に認知されていないすべての型を既知の型の > 一覧に追加してください。このためには、たとえば KnownTypeAttribute 属性を > 使用するか、シリアライザーへ渡される既知の型の一覧にこれらの型を追加します。 newの質問したものです。 newにかかるオーバーヘッドの時間調査して、パフォーマンスを比較するのを怠ってましたが、やはりやってみないとわかりませんね。 やります。皆さん色々アドバイスありがとうございます。
いやいやいや、それはどっちかというと頓珍漢な言い掛かりの部類でアドバイスじゃないと思うよw 今年は何年よw コンストラクタ呼び出しが時間的に高コストなんてよっぽど特殊なクラス以外ありえないよwww µsオーダでもmsオーダーでもなく、たった1回/秒の呼び出しなんだからw だから最初から言ってるように、普通は書きやすい方法で書いて何も問題ないよ本当。
いわゆる無駄な最適化の部類だとは思うが まぁ自分で検証するというのれは良いことなのでどんどんやるといい
>>970 いや、気にしてるのはnew連発の穴ボコメモリだろ? そのうちosがうまいことやってくれるのはなんとなくわかるがそのコストって具体的にどうよ? ってのが本当に知りたいことだろ? 環境次第だしパフォーマンスモニタ動かしてみろよって話 3日も動かすと5秒だけ動作が止まるような動きをするってなったらそれが運用上許容できるのか?バグるのか? それもやっぱりやって見なきゃわからないんちゃうん? >>972 何がいやか分からないけど、だから最初から 高価な共有リソースを使う場合は別だと言ってるでしょ 今頃何を言ってるのかね そういう例外的なケースを除けば、毎秒数個のオブジェクトを使い捨てにしたって 問題なんか起こらない。 そんなのXPの時代だってそうだから データベースへのコネクションを using で括ると コネクションプールが機能しなくなる?
>>973 問題起こらないってどういう範囲で言ってるの? 何度も確保したnewの領域をosがどう処理するから問題ないって言ってるの? 仕様によっては問題起きるよ 1つはメモリ限界ギリギリまでガベコレしないときは定期タスクの動きを止めてメモリ処理するよ 1分以上止まっちゃってたことあるよ >>975 具体的にどうぞ。 君が問題が起こる具体的な一例を挙げればそれで話は終わる。 もちろん、極端な特殊例でなくどこでもありうるような一般的なものでお願いしますよ。 あのねえ、今はPC-98の時代じゃないんですけどw とりあえずガベコレ動くときにプログラムの動作止まっちゃうよって1つあげてるよね
>>978 すぐに使い捨てるなら確実にGen0GCで回収されるから止まる原因になることはないよ こっちは具体例上げるけど、もっと高頻度(例えば10回/秒とか)で 画面を更新する必要があるアプリなんてごく普通にあるわけで、 そういう場合、例えばGDI+なら、ペンとかブラシとかデバイスコンテキスト(普通は作るのはシステム側で ユーザーコードじゃないけど)とか、描画ごとに使い捨てすることになるけど、 こんなのが問題を引き起こすなら使い物にならないよ。 実際.NET1.1の時代に今じゃ考えられないような貧弱なWin98のマシンで そういうアプリをテストしたことあるけど、何の問題もなかったよ。 当たり苗だけどw
>>979 とりあえず解決した方法は 10分に一度程度で強制ガベコレ実行することで解決したよ 溜めるとガベコレの時間は長くなるっぽい やってみた感じね パフォーマンスモニタでもメモリリークしてる?ってぐらい増えてく ガベコレが動くと解消される でもそのとき10秒タスクなんかは動かない 小刻みに強制ガベコレを実行しておくとそれが解消される そんな動きをしている その動きをされると困るときに小刻みに強制ガベコレを実行する必要がある これが問題があったときな これを問題ないって言われちゃうとどう返していいかわからんけどね
ちなみに趣味でゲームも作ってるけど 頻繁に強制ガベコレを動かさないと 重いガベコレを実行されるときがある ゲームでは多少重い動作をした程度なので問題にならないが これを周期的にデータを収集するタスクを動かしてるときにやられると不味いときがある
だから具体的にどんなサイズのオブジェクトを どういう頻度でインスタンス化したのか教えてくれないと そういうどんくさい実装も可能だろうね でも一般的な話じゃないよねとしか言えないんだよ
>>984 それがわかったところでだからどうなの? 何がしたいん? まあ、今回の件がどうなのかパフォーマンスモニタで測ってやってみんのが一番いいよね そのアプリが連続実行される要件に合わせてって話だけど
>>980 描画ごとに使い捨てにするのはデバイスコンテキストのハンドルで デバイスコンテキスト自体じゃないじゃないんじゃないのかな? 少なくとも一般的には あとスレ立てヨロ nmecabに例の辞書入れて動かしてたら時々遅くなって何かと思ったらガベコレだった サービスにぶっこんでて気付かなかった
質問者がいなくなった後の要件のはっきりしない議論とか次に持ち越すなよ >>988 スレたて乙 >>990 いや、君が人間的に幼稚なだけ。 どうでもいいけど、反論するなら事実で反論してよ つーか、今時毎秒オブジェクトを使い捨てしたぐらいで何か問題が起こると 真顔で主張するって、大丈夫かしらん。 普段どんなコード書いてるのかねw
そもそもポーリング処理じゃなくて ボーリング処理だからな 何が行われてるのかさっぱりわからない
>>994 これは恥ずかしい ポーリング(polling)とは、通信やソフトウェアにおいて、 競合を回避したり、送受信の準備状況を判断したり、 処理を同期したりするために、複数の機器やプログラムに対して 順番に定期的に問い合わせを行い、一定の条件を満たした場合に 送受信や処理を行う通信及び処理方式のことである。 キミの用途はそうではなくても、常識としてnewやstringは遅いという認識を共有してくれないかな。 今時とか、普段とか、遅くて使い物にならなかった昔のJava屋のセリフそのままじゃないか。 どんな時代でもCPUのリソースは有限なんだよ。
>>996 上から目線で頓珍漢なことを言ってるお型を見るほど滑稽な物はないなw
mmp2
lud20190707164950ca
このスレへの固定リンク: http://5chb.net/r/tech/1500327645/ ヒント: 5chスレのurlに
http ://xxxx.5ch
b .net/xxxx のように
b を入れるだけでここでスレ保存、閲覧できます。
TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「ふらっと C#,C♯,C#(初心者用) Part130 [無断転載禁止]©2ch.net YouTube動画>7本 ->画像>11枚 」 を見た人も見ています:・ふらっと C#,C♯,C#(初心者用) Part140 ・ふらっと C#,C♯,C#(初心者用) Part144 ・ふらっと C#,C♯,C#(初心者用) Part150 ・ふらっと C#,C♯,C#(初心者用) Part141 ・ふらっと C#,C♯,C#(初心者用) Part138 ・ふらっと C#,C♯,C#(初心者用) Part141 ・ふらっと C#,C♯,C#(初心者用) Part142 ・ふらっと C#,C♯,C#(初心者用) Part143 ・ふらっと C#,C♯,C#(初心者用) Part136 ・ふらっと C#,C♯,C#(初心者用) Part132 ・ふらっと C#,C♯,C#(初心者用) Part133 ・ふらっと C#,C♯,C#(初心者用) Part135 ・ふらっと C#,C♯,C#(初心者用) Part139 ・ふらっと C#,C♯,C#(初心者用) Part145 ・ふらっと C#,C♯,C#(初心者用) Part134 ・ふらっと C#,C♯,C#(初心者用) Part131 ・ふらっと C#,C♯,C#(初心者用) Part137 ・ふらっと C#,C♯,C#(初心者用) Part146 ・ふらっと C#,C♯,C#(初心者用) Part120 [無断転載禁止] ・ふらっと C#,C♯,C#(初心者用) Part148 ・ふらっと C#,C♯,C#(初心者用) Part148 ・ふらっと C#,C♯,C#(初心者用) Part147 ・ふらっと C#,C♯,C#(初心者用) Part121 ・ふらっと C#,C♯,C#(初心者用) Part128 ・ふらっと C#,C♯,C#(初心者用) Part119 ・ふらっと C#,C♯,C#(初心者用) Part157 ・ふらっと C#,C♯,C#(初心者用) Part151 ・ふらっと C#,C♯,C#(初心者用) Part155 ・ふらっと C#,C♯,C#(初心者用) Part156 ・ふらっと C#,C♯,C#(初心者用) Part149 ・ふらっと C#,C♯,C#(初心者用) Part118 ©2ch.net ・ふらっと C#,C♯,C#(初心者用) Part129 [無断転載禁止] ・ふらっと C#,C♯,C#(初心者用) Part127 [無断転載禁止]©2ch.net ・ふらっと C#,C♯,C#(初心者用) Part125 [無断転載禁止]©2ch.net ・ふらっとC#,C♯,C#(初心者用) Part88 ・ふらっとC#,C♯,C#(初心者用) Part92 ・ふらっと C#,C♯,C#(初心者用) Part160 (874) ・ふらっと Q#,Q♯,Q#(初心者用) Part 1 (10) ・Webサイト制作初心者用質問スレ part250 ・Webサイト制作初心者用質問スレ part249 ・Webサイト制作初心者用質問スレ part251 ・【キンスレ】キングスレイド初心者用スレpart1【初心者】 ・【キンスレ】キングスレイド初心者用スレpart2【初心者】 ・くだすれC++/CLI(初心者用)part2 ・Webサイト制作初心者用質問スレ part239 ・Webサイト制作初心者用質問スレ part241->動画>2本 ・Webサイト制作初心者用質問スレ part252 ・Webサイト制作初心者用質問スレ part244 ・初心者用・人形の素朴な疑問Q&A Part18 ・Webサイト制作初心者用質問スレ part247 [無断転載禁止] ・Webサイト制作初心者用質問スレ part248 [無断転載禁止] ・Webサイト制作初心者用質問スレ part248 [無断転載禁止] ・【キンスレ】キングスレイド初心者用スレpart3【初心者】 ・【Esperanto】エスペラントの初心者用スレッド【国際補助語】 parto1 ・Webサイト制作初心者用質問スレ part246 [無断転載禁止]©2ch.net->動画>2本->画像>19枚 ・くだすれFORTRAN(超初心者用)その6 ・UWSC初心者用スレ ・くだすれPython(超初心者用) その37 ・くだすれPython(超初心者用) その36 ・くだすれPython(超初心者用) その39
06:21:06 up 3 days, 16:45, 0 users, load average: 17.23, 13.26, 11.55
in 0.033676862716675 sec
@0.033676862716675@0b7 on 121520