ふらっと C#,C♯,C#(初心者用) Part130 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、
質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスはやめてください
>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。
■前スレ
ふらっと C#,C♯,C#(初心者用) Part129
http://mevius.2ch.net/test/read.cgi/tech/1497000961/
■関連スレ
C#, C♯, C#相談室 Part94 [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/tech/1492843013/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/
■情報源
https://msdn.microsoft.com/en-us/library/gg145045.aspx
http://referencesource.microsoft.com/
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured >>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ってどーなんの? >>625
最速ってのがわからないけどこんなん?
http://www43.atpages.jp/opicon69/xlib/t05.html
昔やってたwindowsSDKみたいな感じだな。まあ普通はGUIライブラリ使うんだろうけど >>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
どういうレベルでプログラムを書いてるのか余裕で知れるな お前らマウンティングしないと死んじゃう病か何かなの 独立な処理に途中経過もクソもないわな
処理の詳細を無視して入出力のルールにフォーカスする考え方ができてないとそりゃ難しいだろうな ラムダ式の部分にブレークポイント置けばそこだけ追えない? ■ このスレッドは過去ログ倉庫に格納されています