ふらっと 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 >>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
今のは開かないのか
前のは普通におｋだったけど >>533
普通に開けるよ
方言でトラブル多いCSVよりTSV使って欲しいわ どっとも同じにしか思えないけどw
CSVで起こるトラブルは全部起こるんじゃないの？
セパレーターが違うだけじゃんw
ただ、TSVってクリップボード経由でエクセルに矩形（N列×M行）のデータ
貼り付けに使えるんだよね。
それ以外の用途で使ったことないなあ >>536
いやいや普通のテキストには普通にコンマ入ってるけどタブは入ってない
これが重要 TVで報道されない真実
集計マシーン ムサシ
作ってる会社は？
ｗｗｗｗ
一番触れられたくない部分ｗｗｗ 税金垂れ流しで身内がばぶってる糞安倍特需 >>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
コードの中に埋め込んでる状況が一番依存性が高いだろうｗｗｗ
本当の馬鹿ってこんなところにいるんだな… タプルはその型にちょうどいい名前がつかない時が使いどころ
なくてもそんなに困らないけどあると便利な場面は多い タプルは7.0のタプル型になってから戻り値で使うようになった C#はバージョン毎に結構あれこれ追加されて常識が変わってくからな
最新バージョンを追い掛け続けてる人とそうでない人で、話が通じなくなる事もしばしば
俺も割りと4.0くらいで頭の中が止まってるかもしれない せっかくJavaやCが戻り値はひとつにしようと糞コード撲滅の努力をしてきたのに >>606
戻り値のためにクラス作るのがなんか心理的に重い >>608
戻り値にデータが複数必要ってどんなときだべ?
もちろんなかったわけじゃないが
エラーとエラーログみたいな? >>609
たとえば画像データだと画素データだけでなくチャンネル数や各チャンネルの大きさ、縦と横の（特に横）の長さが必要になる
これだけで例えばバイト配列といくつかのintが必要になる >>610
全然適切な例になってない気が
それ、明らかにクラスまたは構造体にまとめるべきデータでしょ
まあ、一つの型にまとめたくない複数のデータを一つのメソッドから返したい、
なんて率直に言ってうんこの臭いしか感じないね。 >>611
「クラスや構造体でまとめられないデータ」に対する回答でなく
「複数の戻り値が必要なデータ」に対する回答なんだけど 別の場所でも入力にも使うようならクラスなりで定義すべきだけど
なんちゃらResultとか名前を付けたくなるような
特定の場所の戻り値でしか使わないデータのまとまりはタプルって感じかなあ 一連のDBと入力の整合性チェックをまとめたとき
処理途中でとってきたDBの値を使いまわしたい場合とか
Result 処理途中でとってきたDBのDtoいっぱい = checkなんちゃら（画面入力.id, 画面入力.数量）
とかのためにクラスつくるのがなんとなくイヤで
タプルで楽したくなる >>613
スコープの範囲次第で使い分けかなと考えているけど、職場ではTaple使えない悲しい現実 ■ このスレッドは過去ログ倉庫に格納されています
