[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 2chのread.cgiへ]
Update time : 10/10 23:29 / Filesize : 217 KB / Number-of Response : 788
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

【VB.NET】LINQ友の会【C#, C♯, C#】



1 名前:デフォルトの名無しさん [2008/02/09(土) 23:51:34 ]
VisualStudio2008より追加された便利で強力な機能

  統合言語クエリ (LINQ : Language Integrated Query)

ちょっと使ってみると、意外と難しいし、テクニック的にも奥が深いものです。
関数型言語にしかないような機能ラムダ式(Lambda式)などはオブジェクト指向とは一味違う機能です。
DataBaseの操作にも、Xmlの操作にも、さらにもっと単純な配列なコンテナにさえ機能する
言語共通・高汎用な統合言語クエリを皆で一緒にマターリ勉強しましょう。
質問、便利なマイテクニックの発表、いろいろやっちゃってください。


381 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 00:00:11 ]
>>376
実際のところ、測ってみたら速くならなくない?
1段ラッパーされてる分のペナルティの方が大きくて。

そういうレベルの話よりは、
データ列の処理ってのを1段階抽象化してるから、
LINQ to SQL/Entity みたいなクエリ化もできるし、
PLINQ みたいな並列化もできるしって辺りの
もっと抽象度高い話しないと LINQ の価値出ない気も。


382 名前:デフォルトの名無しさん [2009/07/09(木) 00:09:58 ]
デリゲート呼び出しのコストがやっぱり大きいんじゃないかな
使い方を変えずにExpressionTreeで一つの大きな列挙子に展開することだって可能なわけで、
そういうところがLINQのポテンシャルなんだろうな

383 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 06:19:38 ]
Linqというよりデリゲート単独のパフォーマンスを調べたことがある。
サイズの小さい関数の呼び出しはJIT時にインライン化されるが、
デリゲートで呼び出された関数はどんなに小さいものでもインライン化されないようだった。
関数のサイズを大きなものに変えた場合はどちらもほぼ同じ結果になった。

こういう関数があった場合、
int Hoge1(int x) { return x * x; } // こっちはインライン化されるコード
インライン化されない関数の作り方としては、xは-10000以下にならないという前提で
int Hoge2(int x) {
  if (x > -10000) return x * x;
  : 実際には実行されない大量のコード
}


384 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 08:40:19 ]
くだらない事やらずに分かりやすく書けやクズ

385 名前:デフォルトの名無しさん [2009/07/09(木) 08:44:04 ]
インライン展開はMethodImpl属性で抑制できるぞ

386 名前:383 mailto:sage [2009/07/09(木) 09:18:21 ]
すまん、すまん。糞したり飯食ったりしてて続きを書くのを忘れていた。

Enumerable.Whereで条件を指定するところなどLinqの随所にdelegateが使われているわけだ。
その部分をdelegateを使わない形に書き直せば、yieldや拡張メソッドを使っていても、
多重ループで書いたのとそう変わらない結果がでる。

>>382
>デリゲート呼び出しのコストがやっぱり大きいんじゃないかな 
に同意と言いたかった。

>>385 おおありがとう。インラインの抑制はそのほうがスマートですな。

387 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 09:36:21 ]
デリゲート呼び出しは通常の関数呼び出しの一割り増しぐらいだと外人の誰かがブログでグラフ付きでかいとったな。
ああいうページいつもどこ行ったか忘れちゃうんだよな・・・


388 名前:デフォルトの名無しさん [2009/07/09(木) 09:50:59 ]
いかにデリゲート呼び出しが速かろうとベタに書くよりはそりゃ遅くなるに決まってる
最適化できなくなるんだから

389 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 10:00:52 ]
だから遅くても許容範囲なんじゃねーのって話だろ。
そんだけ速いの欲しかったらアセンブラで書いとけよ。



390 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 13:22:47 ]
それでも・・・僕はLINQを使うんだ!

391 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 01:06:06 ]
LINQで要素に連番をふりたいなーと思ったけど
 int index = 0;
 var numbered =
   from p in source
   let gomi = (++index)
   select new { Index = index, Data = p };
と、アホまっしぐらなコードに。

そもそも副作用のある式を入れている時点でマズイとは思うけど
これ以外に手はあるんでしょうか?

392 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 01:26:45 ]
クエリ式に固執しなければいいんじゃね?

393 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 05:27:16 ]
source.Select((Data, i) => new { Index = i + 1, Data });
クエリ構文だとやれることが少ないことに気づくと、だんだメソッド構文ばかり使うようになる

394 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 08:19:37 ]
トン
こんな便利なバージョンがあったとは。

395 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 16:21:58 ]
C#のLINQは大事なものはほとんど拡張メソッド版になっているよ
ムキになってメソッドでやるのもどうかと思うんだが……
VBのXMLリテラルなんぞを見ていると、やっぱ便利だし読みやすいし。
あんまり拡張メソッドに拘って欲しくないんだけどな

396 名前:デフォルトの名無しさん [2009/07/10(金) 22:45:31 ]
XMLリテラルってXLINQだろ
XLINQ自体は良いものだとは思うけどそんな普及するかどうかもわからない
実験的なものをいきなり言語に組み込むとか

397 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 23:20:37 ]
全然違うような

398 名前:デフォルトの名無しさん mailto:sage [2009/07/11(土) 00:00:36 ]
VBは使ったことはなかったけど…イコールではないよね。
XMLリテラルはXDocumentやXElementといった
LINQ to XMLのクラスを使っているだけで。

って、LINQ to Schema for VB SUGEEEE!!こりゃ楽だわ。C#じゃ使えないのか。

399 名前:デフォルトの名無しさん [2009/07/11(土) 00:09:02 ]
だからLINQ to SQLみたいにLINQ to XMLがコケたらどうしようもないだろ
言語仕様レベルで依存してるんだから
それくらいしないとVBユーザーは新しいものを使おうとしないだろうとか考えたのかな



400 名前:デフォルトの名無しさん mailto:sage [2009/07/11(土) 00:16:09 ]
Linq to Xmlは別にこけるこけないって次元の中身ではないと思うけど。
使ったことないで言ってるでしょ。

401 名前:デフォルトの名無しさん mailto:sage [2009/07/11(土) 01:13:05 ]
Linq to XMLはC#では言語構文の拡張は何もやってない。
使ってるのはLinq to Objectの構文だけで、拡張はクラスライブラリだけ。
VBでは言語構文の拡張もやってて、XMLリテラルもその一種。


402 名前:デフォルトの名無しさん mailto:sage [2009/07/15(水) 18:58:43 ]
この流れを見て、LINQ to XML触ってみた
書き方はすごく楽だね、こりゃ。

…けど、これってLINQ to XMLで書いてしまうと
XMLでデータの不整合や値のレンジ外が見つかった時に
XMLのエラー箇所を通知するのが難しい気がする。
例外できないんじゃ実用性って…

403 名前:デフォルトの名無しさん mailto:sage [2009/07/15(水) 22:02:46 ]
あるある。
LoadOptions.SetLineInfoを活用しようとして、
ToDictionaryの代わりにToLookup+重複のないことの検査したり、
Count != 1なら自前の例外を投げてから、Single呼んだりする羽目になっている。

404 名前:デフォルトの名無しさん mailto:sage [2009/07/15(水) 22:18:29 ]
>>402
スキーマ検証周りならベースにまず XmlReader を使え。
XmlReaderSettings で XmlSchemaSet が指定できる

XLinq 上でもエラー処理したいときは、読み込み周りのオプ
ションで XmlReaderSettings の指定とさらに LoadOptions の
SetBaseUri や SetLineInfo オプションも忘れずに


405 名前:デフォルトの名無しさん mailto:sage [2009/07/16(木) 00:18:20 ]
トン、とても参考になった。SetLineInfoはかなり便利そう

>>403
後、フィルタ以外を全部取り除いておいて最低限にしておいて
データ一個だけ処理する関数を作ってその中で処理したり
 return from p in hoge.Elements("Hoge")
   where (int?)p.Value < 0
   select CreateHogeInstance(p); ←この中で整合性チェックして例外を投げる
結構マヌケな作りな気がする。

406 名前:デフォルトの名無しさん mailto:sage [2009/07/16(木) 00:20:28 ]
C#なら拡張メソッドがんがん作ってそういうのをチェックしながらのWhereとか例外メッセージつきのSelectとかいろいろ作りゃいいんじゃねーの。
0スタートのindexがくっついてくるSelectWithCountとか自分的に便利。

407 名前:デフォルトの名無しさん mailto:sage [2009/07/16(木) 04:16:14 ]
>>406
それって標準のと何が違うの?
msdn.microsoft.com/ja-jp/library/bb534869.aspx

408 名前:デフォルトの名無しさん mailto:sage [2009/07/16(木) 08:01:45 ]
index 付きの Select、みんなが意外知らない便利機能だけど、
まったく同じ機能を再発明しちゃった人までいるのか。

409 名前:406 mailto:sage [2009/07/16(木) 08:29:31 ]
・・・(´・ω・`)
WhereWithCountとか色々作ったのに・・・



410 名前:デフォルトの名無しさん mailto:sage [2009/07/16(木) 10:22:56 ]
引数なしのAny()とかも影薄いよな
Count() > 0とかやっちゃってる人も多そう

411 名前:デフォルトの名無しさん mailto:sage [2009/07/16(木) 14:36:23 ]
作ってみると意外と簡単でつい自前で作ってしまう。
デバッグ用に意外と役に立ったり。
public static void ToVoid<T>(this IEnumerable<T> src) {
  foreach (var s in src) {};
}
public static void ToVoid<T>(this IEnumerable<T> src, Action<T> act) {
 foreach (var s in src) act(s);
}


412 名前:デフォルトの名無しさん mailto:sage [2009/07/16(木) 14:51:15 ]
手軽に作れるのが魅力の1つだよな

413 名前:407 mailto:sage [2009/07/16(木) 17:27:01 ]
>>410
> Count() > 0とかやっちゃってる人
……、ごめんなさい。私です。

>>411
それ、自分はC++から来たからForEachって名前にしたい、特に後者。

414 名前:デフォルトの名無しさん mailto:sage [2009/07/16(木) 17:42:57 ]
List<T>との整合性を考えても、ForEachの方がしっくりくるな

415 名前:デフォルトの名無しさん mailto:sage [2009/07/16(木) 19:36:16 ]
>>413
Count使うと最後まで読まないといけないからパフォーマンスが悪いはず
Anyは一件あるかないかだから速いはず

416 名前:デフォルトの名無しさん mailto:sage [2009/07/29(水) 01:05:17 ]
ttp://www.infoq.com/jp/news/2009/07/Reactive-Framework-LINQ-Events

417 名前:デフォルトの名無しさん mailto:sage [2009/09/12(土) 18:41:51 ]
ヌルポ

418 名前:デフォルトの名無しさん mailto:sage [2009/09/12(土) 19:39:22 ]
LINQと例外処理ってどうやって組み合わせている?

IEnumerableを参照する全ての場所で例外が起こるかもしれない、
となると例外安全の確保をしなきゃならない範囲が滅茶苦茶広くなるし、
任意のtry-catchで捕まえることもできない。
自分は「LINQ中に例外を外に投げる処理は入れるな」で対応している。

419 名前:デフォルトの名無しさん mailto:sage [2009/09/12(土) 23:31:27 ]
LINQからIEnum処理するところすべてtry-catch(´・ω・`)




420 名前:デフォルトの名無しさん mailto:sage [2009/09/13(日) 00:16:47 ]
それは、不毛過ぎるw

421 名前:デフォルトの名無しさん mailto:sage [2009/09/14(月) 20:55:08 ]
配列の要素を2個ずつ処理したいときにはどうすればいいでしょうか?

ruby の each_slice みたいなのがやりたいのですが。

422 名前:デフォルトの名無しさん mailto:sage [2009/09/14(月) 21:12:59 ]
static IEnumerable<IEnumerable<TSource>> Slice<TSource>(this IEnumerable<TSource> source, int n)
{
  var buf = new TSource[n];
  int i = 0;
  foreach (var item in source) { buf[i++] = item; if (i == n) { i = 0; yield return buf; } }
  if (i != 0) { yield return buf.Take(i); }
}

423 名前:421 mailto:sage [2009/09/15(火) 15:00:48 ]
>>422
ありがとう。

424 名前:デフォルトの名無しさん mailto:sage [2009/09/15(火) 21:59:43 ]
LINQらしさを追求してみた

source.Select((x, i) => new { Key = i / n, Element = x })
    .GroupBy(x => x.Key, x => x.Element)
    .Cast<IEnumerable<TSource>>();


425 名前:デフォルトの名無しさん mailto:sage [2009/09/16(水) 06:48:18 ]
まあどっちでもいいんじゃない?
拡張メソッドはガンガン使うべきなのかは迷うところ。

426 名前:デフォルトの名無しさん mailto:sage [2009/09/16(水) 21:47:09 ]
イベントをLINQっぽく操れるリアクティブフレームワークってのを最近知ってからというもの
.NET4.0とラブプラスのことで頭が一杯です。


427 名前:422 mailto:sage [2009/09/17(木) 11:04:44 ]
今更だけど>>422は使われ方によっては問題があるかも
static IEnumerable<IEnumerable<TSource>> Slice<TSource>(this IEnumerable<TSource> source, int n) {
var buf = source.ToArray();
for (int i = 0; i < buf.Length; i += n) yield return buf.Skip(i).Take(n);
}
メモリは食うけどこっちの方が確実

428 名前:デフォルトの名無しさん mailto:sage [2009/09/17(木) 11:22:16 ]
いやSkipやTake使ったらbufの意味がないな
こんなの用意して代わりに使うか
static IEnumerable<TSource> SkipTake<TSource>(TSource[] source, int skip, int take) {
for (int i = 0; i < take; i++) yield return source[i + skip];
}

429 名前:デフォルトの名無しさん mailto:sage [2009/09/17(木) 17:10:47 ]
次はforをForEach()にするんですね



430 名前:デフォルトの名無しさん mailto:sage [2009/09/17(木) 19:00:29 ]
427のはあまり良くないと思う。
422のyield return bufを
yield return buf.ToArray()に変えるだけで良いかと。
あと最後はbuf.Take(i)でいいかな。

431 名前:デフォルトの名無しさん mailto:sage [2009/09/17(木) 19:07:12 ]
sourceがIList<TSource>を実装しているか否かで場合分けするのが効率的か

432 名前:デフォルトの名無しさん mailto:sage [2009/09/27(日) 19:20:03 ]
条件に合うものと合わないものを分けるために、

bar = foo.Select(i=>Baz(i) );
foo = foo.Select(i=>!Baz(i));

みたいに2回Selectしてるんですが、
1回で済む方法ないですか?

433 名前:432 mailto:sage [2009/09/27(日) 19:23:15 ]
間違いました。 where を2回です。

434 名前:デフォルトの名無しさん mailto:sage [2009/09/27(日) 19:24:56 ]
欲しいのはどっちなの?
両方ほしいなら2回しないといけないと思うけど。
やりたいことが見えない。

435 名前:デフォルトの名無しさん mailto:sage [2009/09/27(日) 19:37:47 ]
両方欲しい場合、自前でループを廻せばワンパスで振り分けできるけど、
Linqで同じようにできないか、っていう質問だろうね。
気持ちは分かるけど多分できないんだろうなあ。

Linqの想定用途はあくまで選択や射影の簡略化だろうし、振り分け処理で
無理矢理Linq使う必要無いんじゃない?と思う。foreachでいいじゃん。

436 名前:デフォルトの名無しさん mailto:sage [2009/09/27(日) 19:49:14 ]
そういうメソッドを自作すればいい。
IEnumerable<T>受け取ってTuple<IEnumerable<T>, IEnumearble<T>>でもを返すようにしてさ。

437 名前:432 mailto:sage [2009/09/27(日) 19:58:37 ]
優先度のある条件を集合に適用する処理を
以下のように書きました。

foreach(var 条件 in 条件リスト){
var マッチしたもの = 集合.Where(条件)
集合 = 集合.Where(!条件)
 (マッチしたものに対する処理)
}

というループを書いていたのですが、
ruby の partition メソッドみたいなのがあれば
一回ですむじゃん。
と思ったのですが、ヘルプをみてもわからず、
ググってもわからず、なので質問させていただきました。

処理が重いので1パスにしたいというわけではないので、
2回 Where するままにしておきます。

レスありがとうございました。

438 名前:デフォルトの名無しさん mailto:sage [2009/09/27(日) 20:11:24 ]
やりたいのはこういうこと?

Func<int, bool> cond = x => x % 2 == 0;
var q =
from x in new[] { 1, 2, 3, 4, 5, 6, 7, 8, 9, }
let b = cond(x)
group x by b;

var even = q.First(x => x.Key);
var odd = q.First(x => !x.Key);


439 名前:デフォルトの名無しさん mailto:sage [2009/09/27(日) 21:04:04 ]
だね。
ruby の partition メソッドはズバりGroupBy。
ToLookupはその即時評価版。



440 名前:デフォルトの名無しさん mailto:sage [2009/09/29(火) 02:41:06 ]
ToLookupなんてあるんだな。
おもしろそうだからこれを使ってFizzBuzzをといてみた。


var nums = Enumerable.Range(1, 100);

var fizzbuzz = nums.ToLookup(num => (num % 15 == 0 ? "fizzBuzz" : (num % 5 == 0 ? "Buzz" : (num % 3 == 0 ? "fizz" : "Other"))), arg => arg);

foreach (var group in fizzbuzz)
{
Console.WriteLine("*****" + group.Key + "*****");
foreach (var num in group)
Console.WriteLine(num.ToString());
}

441 名前:デフォルトの名無しさん [2009/10/10(土) 19:43:10 ]
プログラミングC#でLINQの項目をちょっと読んでみたが、
C#のコード中に普通にselectとかfromとか書くのは違和感あるなぁ。
C#の予約語になってんのかね?


442 名前:デフォルトの名無しさん mailto:sage [2009/10/10(土) 19:44:40 ]
>>441
文脈キーワード

443 名前:デフォルトの名無しさん mailto:sage [2009/10/13(火) 12:02:58 ]
LINQって別に最適プランとか計算しないんでしょ?

ほんのちょっと前までデータベースからデータを「SELECT * FROM TABLE」で持ってきて
コード内でデータの取捨を行うなんて、やっちゃだめの最右翼だったのに、すんげえ
富豪的プログラミングだなあ…。

444 名前:デフォルトの名無しさん mailto:sage [2009/10/13(火) 12:30:06 ]
WHERE句はあるには有るけど
内部で式評価を最適化しているわけではない

445 名前:デフォルトの名無しさん mailto:sage [2009/10/13(火) 12:54:50 ]
Linq to Objectにはプランナはない。命令の順番で処理される。
Linq to SQLやEntity Frameworkの場合はDBMSのSQLに翻訳されるから、
DBMSのプランナが機能する。


446 名前:デフォルトの名無しさん mailto:sage [2009/10/13(火) 19:08:08 ]
LINQ to SQLって、要するに式ツリーからSQLを生成するORMという理解でOK?

447 名前:デフォルトの名無しさん mailto:sage [2009/10/13(火) 19:17:58 ]
LINQ to SQLの中身がわかってない奴が多いのな。
とりあえずDataContext.Logで吐かれるSQLを確認するところから
はじめたらどうだ?


448 名前:デフォルトの名無しさん mailto:sage [2009/10/13(火) 20:29:13 ]
ですな。
>>443 のような酷い勘違いは初めて見たけど。

449 名前:デフォルトの名無しさん mailto:sage [2009/10/13(火) 20:40:37 ]
LINQ to Objectsを最適化するとしたら,DynamicMethodでインライン展開かなあ
コード生成のコストが高いからあんまり意味なさそう



450 名前:デフォルトの名無しさん mailto:sage [2009/10/13(火) 21:37:17 ]
>>446
Whereの条件とかは式ツリーだけど、Where自体は式ツリーでない

>>447-448
まあ、LINQ to SQLで生成されるSQLも大概だがな
作成したクエリ(IQueryable)をそのまま変換してるからサブクエリが深すぎて何が何やら

451 名前:デフォルトの名無しさん mailto:sage [2009/10/13(火) 23:25:35 ]
>>446
そう。ただ実行の度に発行される。ToList()すりゃ1回ですむけども。

452 名前:デフォルトの名無しさん mailto:sage [2009/10/26(月) 18:34:12 ]
            /)
          ///)   ノ´⌒`ヽ
         /,.=゛''"/γ⌒´      \
  /     i f ,.r='"-‐'つ ""´ ⌒\  )
 /      /   _,.-‐'~  \  /  i )   こまけぇことはいいんだよ!!
   /   ,i   ,二ニ⊃ (・ )` ´( ・) i,/
  /    ノ    il゛フl    (__人_).  |
     ,イ「ト、  ,!,! \   `ー'   /
    / iトヾヽ_/ィ"   `7      〈

453 名前:デフォルトの名無しさん mailto:sage [2009/11/07(土) 12:28:38 ]
データは作成する回数よりも参照される回数の方が多いわけで、
キャッシュがないから遅延されても重くなるだけじゃないか?
結局はToList()しまくるハメになっている気がする。

454 名前:デフォルトの名無しさん mailto:sage [2009/11/07(土) 13:04:29 ]
SQLはちゃらっと書く分には楽だな。
最適化とか考えてくとだんだんめんどくさくなりそうだけど。

つーかいい加減データアクセスモデルはナイスな奴一つにまとめてくれ。
Oslo?

455 名前:デフォルトの名無しさん [2009/11/07(土) 19:58:09 ]
確かにMSは昔からデータアクセスの新方式を乱発しすぎなんだよな。


456 名前:デフォルトの名無しさん mailto:sage [2009/11/09(月) 14:02:34 ]
遅延評価も即時評価も都合に合わせて選択できるってことで
今のモデルで悪くないと思うがな。

そもそも本当にチューニングが必要な場所ならLinqは使わないだろ。

性能云々うるさいやつ向けに..Optimize()あたりを追加してみるか?

457 名前:デフォルトの名無しさん [2009/11/09(月) 17:37:01 ]
手段がいろいろ用意されて軽く破綻してるC++の二の舞ですね
パラダイムを混ぜこぜにするとよく起こる

458 名前:デフォルトの名無しさん mailto:sage [2009/11/10(火) 17:39:44 ]
結局のところ記述性と性能はトレードオフなんだよ

459 名前:デフォルトの名無しさん mailto:sage [2009/11/13(金) 00:55:32 ]
え、いや、Linq の遅延評価は記述性って言うか
スケーラビリティ?だべ。要素数がドカーンって
なっても使えるという意味での。



460 名前:デフォルトの名無しさん mailto:sage [2009/11/15(日) 02:05:16 ]
SelectMany の戻り値に一つだけ要素を足したいです。

今は、
var list = new List<T>();
list.Add(item);
list.AddRange(foo.SelectMany(i => bar(i)));
のように書いてますが、なんか
冗長な気がします。

1個要素を足すためだけに List のインスタンスを
生成するのは無駄な気がするんですが、
避ける方法ないでしょうか?

461 名前:460 mailto:sage [2009/11/15(日) 02:16:19 ]
すまん、Concat を見つけた。

foo.SelectMany(i=>bar(i)).Concat(new[]{ item });

と書けた。
でも、配列生成してんのが無駄な気がするが、
回避する方法ないよね?

( new List<T>(){ item } とかは無しでw)

462 名前:デフォルトの名無しさん mailto:sage [2009/11/15(日) 03:02:15 ]
() => { yield return item; }

463 名前:デフォルトの名無しさん mailto:sage [2009/11/15(日) 10:18:15 ]
ラムダ内をイテレーターブロックにはできないよ。
やるなら、拡張メソッド追加して、

public static IEnumerable<T> Concat(this T x, IEnumerable<T> list)
{
yield return x; foreach(var i in list) yield return i;
}
public static IEnumerable<T> Concat(this IEnumerable<T> list, T x)
{
foreach(var i in list) yield return i; yield return x;
}


464 名前:デフォルトの名無しさん mailto:sage [2009/11/15(日) 11:46:45 ]
>>461
Enumerable.Repeat(item, 1) で回避。

465 名前:デフォルトの名無しさん [2009/11/15(日) 12:01:40 ]
拡張メソッドにT使えたっけ?

466 名前:デフォルトの名無しさん [2009/11/15(日) 12:17:35 ]
Concat<T>が正解ね

467 名前:デフォルトの名無しさん mailto:sage [2009/11/15(日) 16:28:58 ]
>>464
それたぶん配列作った方が効率的
Rangeで作られるイテレータよりも配列のイテレータの方がずっと速いはず

468 名前:467 mailto:sage [2009/11/15(日) 16:30:40 ]
間違えたRepeatか

469 名前:デフォルトの名無しさん mailto:sage [2009/12/11(金) 00:11:22 ]
Linq to Object で List 内のデータを取り出した時に、そのデータを変更することはできるのでしょうか?
Linq to Object では、抽出するだけなのでしょうか?



470 名前:デフォルトの名無しさん mailto:sage [2009/12/11(金) 00:17:14 ]
>>469
List 自体の更新?
LINQ 以前に、GetEnumerator で列挙してる最中にリストのアップデートかけちゃダメ。

list[i] = xxx; 的なことがしたいって場合も、GetEnumerator じゃ無理。

list[i].Property = xxx; 的なことなら、
foreach (var x in list.Select(xxx)) x.Property = xxx; で可能。


471 名前:469 mailto:sage [2009/12/11(金) 23:15:10 ]
>>470
ありがとうございます。
LINQ は便利だなぁと(ソートもしてくれるし), PLINQ にもなるし;

抽出した内容を判別して、データを変更できるんだろうなぁと思っていました。



472 名前:デフォルトの名無しさん mailto:sage [2009/12/12(土) 14:18:30 ]
ちなみに、標準では Foreach メソッドみたいなのないけど、
それを認めると LINQ 中で副作用起こすのを推奨しちゃうことになるから避けたらしい。

list.Select(x => xxx).Foreach(x => x.Property = xxx);
みたいなのは邪道。
LINQ 中では副作用は起こさないこと推奨。

473 名前:デフォルトの名無しさん mailto:sage [2009/12/12(土) 14:47:28 ]
なれていない人って偶に
 int count = 0; var distList = from i in srcList select new { Val=i, Index=++count };
みたいな事をやっちゃうよねw

そういうノウハウってどこかにまとまっていないのだろうか?
MSDNにLINQの使い方ガイドラインってないよね?

474 名前:デフォルトの名無しさん mailto:sage [2009/12/12(土) 15:48:41 ]
外部スコープの変数を書き換えるといろいろ副作用が怖いね。
よほど理解して使わないと。

475 名前:デフォルトの名無しさん [2009/12/12(土) 18:32:10 ]
副作用?そんな表現はじめて聞いた。
msが言ってるの?

476 名前:デフォルトの名無しさん mailto:sage [2009/12/12(土) 18:45:02 ]
一般的な言葉じゃないか?
「ifの中に副作用のある式を書くな」なんて昔から言われているし

477 名前:デフォルトの名無しさん mailto:sage [2009/12/12(土) 18:50:51 ]
Linqというよりそこで使われてる静的クロージャの問題。
.NET2.0でクロージャが実装されたとき有名になったプログラム。
i, j がどんな値になるか想像つく?
using System;
using System.Collections.Generic;
delegate void F();
class Test {
  static void Main() {
    List<F> actionList = new List<F>(); 
    for(int i = 0; i < 10; ++i) {
      int j = i;
     actionList.Add(delegate(){Console.WriteLine("i={0}, j={1}",i, j);}); 
    }
    foreach (F f in actionList) f();
  }
}


478 名前:デフォルトの名無しさん mailto:sage [2009/12/12(土) 20:20:23 ]
LINQの副作用関連でのエンバグは、>>477以外に遅延評価に原因しているものもあると思う
標準的な使い方である「LINQ中でselect new」すら副作用のある式なわけで
(戻り値を使う場所も含め)ちゃんとその挙動まで把握しないと不味い。

var hoges = from p in hoge select new Hoge(p);
foreach(var hoge in hoges) { hoge.ValueChanged += Hoge_OnValueChanged(); }
foreach(var hoge in hoges) { hoge.Value = 3; } // Hoge_OnValueChanged………?

そこまで考慮している保証のないクラスや関数に
値を渡す/返す場合は常にToArray/ToListするのが正解か

479 名前:デフォルトの名無しさん [2009/12/13(日) 03:24:35 ]
そりゃそうだろw
何言ってんのw



480 名前:デフォルトの名無しさん mailto:sage [2009/12/13(日) 03:41:07 ]
>477
のは気をつけないと忘れてて、あれうごかねぇとかたまにやるw最近は体が覚えてきたが。
>478
うちのバカエンジニアとかでもおなじようなことしてそうでこえぇ。

481 名前:デフォルトの名無しさん mailto:sage [2009/12/13(日) 19:31:28 ]
>>479
自分一人ならこういうノウハウもすぐに納得して「そりゃそうだ」で済ませれるが、
仕事でチームでやっていると全員がLINQを理解しているわけじゃないから、そうもいかないのよね。

気がつくと新人がコメントに「//なぜかこのToListを外すとぬるぽ」とか書いてたりするw






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<217KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef