ふらっと 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 >>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
コードの中に埋め込んでる状況が一番依存性が高いだろうｗｗｗ
本当の馬鹿ってこんなところにいるんだな… タプルはその型にちょうどいい名前がつかない時が使いどころ
なくてもそんなに困らないけどあると便利な場面は多い タプルは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の温度を気にしろ ■ このスレッドは過去ログ倉庫に格納されています
