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

**デフォルトの名無しさん** · 2008/02/09(土) 23:51:34

VisualStudio2008より追加された便利で強力な機能

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

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

**デフォルトの名無しさん** · 2009/01/07(水) 14:07:35

>>321
確かに間違ってるな。
1クエリで書こうと思うとティマイザに期待しつつこう書くしかないか。

var result =
from _ in Table1
new
{
sum1 = Table1.Sum(item => item.col1),
sum2 = Table1.Sum(item => item.col2),
sum3 = Table1.Sum(item => item.col3)
}).Take(1).First();

**デフォルトの名無しさん** · 2009/01/07(水) 14:08:38

ティマイザ→オプティマイザ

**デフォルトの名無しさん** · 2009/01/31(土) 19:41:18

>>310
初心者なりに考えてみた。
全然スマートじゃないけど勘弁してね。

var result = table.Select((t, x) => new
{
seq = x + 1,
col1 = t.col1,
col2 = t.col2
}).GroupBy(t2 => t2.seq).Select(g=>new
{
sum1 = g.Sum(t2=>t2.col1),
sum2=g.Sum(t2=>t2.col2)
});

**デフォルトの名無しさん** · 2009/02/11(水) 13:05:19

var result = table.Select(t => new
{
col1 = t.col1,
col2 = t.col2
}).GroupBy(t2 => 1).Select(g => new
{
sum1 = g.Sum(t2 => t2.col1),
sum2 = g.Sum(t2 => t2.col2)
});

**デフォルトの名無しさん** · 2009/02/17(火) 18:54:14

初めまして、よろしくお願いいたします。
どうかアドバイスを下さい。

Visual　Studio　2008を使っていて、1台の自宅ＰＣにインストールしています。
インストールしているのは、SQLServer2005　developper　edtion　＋　VB　2008です。
この環境でC/Sアプリを作り始めました。

経緯としましては、ＶＢｱﾌﾟﾘを作るのにVSを起動して、ﾌﾟﾛｼﾞｪｸﾄの種類でVB、ﾃﾝﾌﾟﾚｰﾄで
Windowsﾌｫｰﾑｱﾌﾟﾘｹｰｼｮﾝ、をクリックして進み、ﾌﾟﾛｼﾞｪｸﾄ名をjob_testにしてOKをｸﾘｯｸしました。

VSが起動し、左にｻｰﾊﾞｰﾍﾟｲﾝ、右にﾃﾞｰﾀｿｰｽﾍﾟｲﾝが表示されました。

ここからが問題なのですが、ﾃﾞｰﾀｿｰｽﾍﾟｲﾝがうまく機能しないのです。　
１．　「ﾍﾟｲﾝの「新しいデータソースの追加」をｸﾘｯｸ
米ﾃﾞｰﾀｿｰｽ構成ｳｨｻﾞｰﾄﾞが軌道します。
２．「ﾃﾞｰﾀｿｰｽの種類」で「ﾃﾞｰﾀﾍﾞｰｽ」を選択して「次へ」をｸﾘｯｸして進みます。
３．「ﾃﾞｰﾀ接続の選択」で「・・・使用するデータ接続」で既存の接続を選択して、
　ﾗｼﾞｵﾎﾞﾀﾝ「はい、重要情報を接続文字列に含みます。」を選択してｸﾘｯｸして進みます。
４．「接続文字列をｱﾌﾟﾘｹｰｼｮﾝ構成ﾌｧｲﾙに保存しますか？」で「次へ」をｸﾘｯｸして進みます。
５．ここ（ﾃﾞｰﾀﾍﾞｰｽｵﾌﾞｼﾞｪｸﾄの選択）でｴﾗｰが発生します。ﾒｯｾｰｼﾞは、「ﾃﾞｰﾀﾍﾞｰｽから
情報を取り出すときに、ｴﾗｰが発生しました。MicrosohutoVisualStudio.datadesignsync.
designersync.Facedsync,TableConfigManager　のﾀｲﾌﾟ初期化
子が例外をｽﾛｰしました」と表示され先へ進めません。　

どうか解決方法を教えて下さい。

それと境い目の現象なのでDBのｽﾚにもﾚｽさせて頂きます。ご了承くださいませ。

**デフォルトの名無しさん** · 2009/02/20(金) 07:06:29

>>326
マルチ乙

**デフォルトの名無しさん** · 2009/02/20(金) 18:50:07

Microsohuto社製品なんて使うからだな

**デフォルトの名無しさん** · 2009/02/21(土) 04:59:59

＞Microsohuto社
中国のばったものの会社？

**デフォルトの名無しさん** · 2009/02/21(土) 21:28:41

株式会社精密工具

**デフォルトの名無しさん** · 2009/02/23(月) 00:42:52

Linq to Xmlでちょっと質問

<root>
<data>
<ID>1</ID>
</data>
<data>
<ID>3</ID>
</data>
<data>
<ID>4</ID>
</data>
</root>
というのを
<root>
<data>
<ID>1</ID>
</data>
<data>
<ID>2</ID>
</data>
<data>
<ID>3</ID>
</data>
</root>
に変換するにはどうすれば良いんでしょうか？
イメージとしては、IDを指定して<data>ごと削除、でもIDの値は1から順番になるように保つ、という感じです

**デフォルトの名無しさん** · 2009/02/23(月) 00:53:41

データが何個あるか調べて、XMLを作り直したほうが早いと思わんかね？

**デフォルトの名無しさん** · 2009/02/23(月) 02:38:35

いまひとつイメージがつかめないから、こうゆう解釈で行くよ～
<data><ID>1</ID><ext at=""true"">hoge1</ext></data>
<data><ID>2</ID><ext at=""false"">hoge2</ext></data>
<data><ID>3</ID><ext at=""true"">hoge3</ext></data>
<data><ID>4</ID><ext at=""false"">hoge4</ext></data>
ID=3の行を削除でIDが繰り上がる
<data><ID>1</ID><ext at=""true"">hoge1</ext></data>
<data><ID>2</ID><ext at=""false"">hoge2</ext></data>
<data><ID>3</ID><ext at=""false"">hoge4</ext></data>

**デフォルトの名無しさん** · 2009/02/23(月) 02:42:54

string xml = @"<root>
<data><ID>1</ID><ext at=""true"">hoge1</ext></data>
<data><ID>2</ID><ext at=""false"">hoge2</ext></data>
<data><ID>3</ID><ext at=""true"">hoge3</ext></data>
<data><ID>4</ID><ext at=""false"">hoge4</ext></data></root>";
var doc = XDocument.Parse(xml);
var rs = doc.Elements("root").Elements("data").Where(x => x.Element("ID").Value != "3")
.Select((x, cnt) => {
  var nx = new XElement(x);
  nx.Element("ID").Value = (cnt+1).ToString();
  return nx;} );
var el2 = new XElement("root2");
foreach (var s in rs) el2.Add(s);
var doc2 = new XDocument(el2);
Console.WriteLine(doc2);
今回は読み込んだXdocumentをいじらないようにしたが、いじっていいなら
Linqは使わず最初に読み込んだXDocumentを直接変更してもいいと思う。

**デフォルトの名無しさん** · 2009/04/14(火) 23:27:35

WPF の UIElementCollection に対して、
Linq の機能（Where メソッドとか）を使いたいのですが、
UIElementCollection にはそのメソッドがありません。

どうすれば Linq の機能が使えるでしょうか？

**デフォルトの名無しさん** · 2009/04/14(火) 23:34:03

あー、non-generic な IEnumerable に対する Where とかないのか・・・
いったん、 .OfType<UIElement>() っての通すと使える気がする。

**デフォルトの名無しさん** · 2009/04/15(水) 11:49:27

OfTypeじゃなくて，元のコレクションに違う型が入ってないことを仮定するCastのほうがベター
※foreach(UIElement item in collection)相当
OfTypeを使うのはOfType<Button>みたいに意図的に型をフィルタリングするときだけ

**335** · 2009/04/16(木) 21:20:12

>>336 >>337
ありがとうございました。

**デフォルトの名無しさん** · 2009/04/19(日) 23:45:46

良スレなのに過疎ってて残念。

**デフォルトの名無しさん** · 2009/04/20(月) 12:48:21

ＳＱＬは糞

**デフォルトの名無しさん** · 2009/04/20(月) 18:09:58

何をもって糞と判断してるのか

**デフォルトの名無しさん** · 2009/04/20(月) 20:08:48

互換領域の文字だからだな

**デフォルトの名無しさん** · 2009/04/20(月) 22:24:47

　int[] a = new int[] { 1, 2, 3 };
　a.ToList().ForEach(i => Trace.WriteLine(i) );

ForEach するために毎回 ToList() してるんだけど、
ToList() しなくてすむ方法ないの？

**デフォルトの名無しさん** · 2009/04/20(月) 22:33:14

>>343
素直に foreach (var i in a) するか、自分で IEnumerable 用の ForEach 拡張メソッド書くか。

**デフォルトの名無しさん** · 2009/04/20(月) 22:35:22

ttp://neue.cc/2009/04/04_145.html

**デフォルトの名無しさん** · 2009/04/20(月) 22:59:17

DataTrigger で特定の Rectangle だけ色を変えようと思って、
TargetName を指定したら、Style では TargetName は指定できないという
エラーが出てしまいました。

回避する方法はありますか？

**346** · 2009/04/21(火) 06:16:25

すんません、誤爆です。

**デフォルトの名無しさん** · 2009/04/25(土) 15:04:39

from age in

**デフォルトの名無しさん** · 2009/04/25(土) 15:04:53

**デフォルトの名無しさん** · 2009/04/30(木) 20:23:27

実際はLINQ to SQLなのですが、

class Order
{
string syohin;
DateTime transactTime;
}

class SpecialInterval
{
string syohin;
DateTime applyDayFrom;
DateTime applyDayTo;
}

で、Orderは数万件以上、SpecialIntervalは数十件以上あります。

これで、Orderの中から、syohinが一致してなおかつtransactTimeがapplyDayFrom～
applyDayToの間にあるOrderだけを取得したいのですが、どうしたら
いいでしょうか？

**デフォルトの名無しさん** · 2009/04/30(木) 20:46:13

from order in context.Order
join si in context.Special on order.shyohin equals si.syohin
where si.applyDayFrom < order.transactTime && order.transactTime < si.applyDayTo
select order

ではダメ？

**デフォルトの名無しさん** · 2009/05/21(木) 21:21:06

.NETとVisual Studioってどういう関係ですか？
.NETの後継？？

**デフォルトの名無しさん** · 2009/05/21(木) 21:32:08

.NETは.NET
Visual StudioはVisual Studio

**デフォルトの名無しさん** · 2009/05/21(木) 22:07:37

パイナップルと酢豚みたいなもんだな

**デフォルトの名無しさん** · 2009/05/21(木) 22:08:10

>>354
それだと、.NETは要らない子になっちまうじゃないか。

**デフォルトの名無しさん** · 2009/05/21(木) 22:59:46

>>354
吹いたｗｗ

**デフォルトの名無しさん** · 2009/05/21(木) 23:13:02

パイナップルのない酢豚なんて・・・

**デフォルトの名無しさん** · 2009/05/22(金) 13:52:09

オレも邪魔だと思ってたが、無いと寂しいｗ

**デフォルトの名無しさん** · 2009/05/22(金) 14:38:39

で、

.NET = パイナップル
VS = 酢豚

っていう結論でいいのか？ｗ

**デフォルトの名無しさん** · 2009/05/30(土) 17:03:50

.NET = フレームワーク
VS = IDE

**デフォルトの名無しさん** · 2009/06/01(月) 13:49:45

>>360

ありがと！謎が解けました！！

**デフォルトの名無しさん** · 2009/06/24(水) 16:09:02

>>244-246って他社製のプロバイダ使ってってこと？

**デフォルトの名無しさん** · 2009/07/08(水) 22:18:41

LINQ to Object やyield returnを使っていて
ふと「これ、何のために使っているんだろう」と思ってしまう。
旧.netと互換性がなくなる上に、実行速度は条件次第(そして多くの場合)落ちるし。

これらの目的は「可読性を上げる」って認識でおk？

**デフォルトの名無しさん** · 2009/07/08(水) 22:31:05

yield return は 2.0 からあるぞ。それより前となると
Generics もないので互換性気にするだけアレというか･･･

Linq to Objects は遅くなるのは確かだけどスケーラビリティは
あるんだよなぁ。Linq がといったほうがいいかもしれないけど

**デフォルトの名無しさん** · 2009/07/08(水) 22:35:58

とりあえず書いて楽になったとおもわんか？
思わないなら別に使わなくていいだろ。
自分はIEnumerable<T>系を自分のライブラリでも多用してるし、yield使わないでIEnumerable返すコードなんか書きたくもないが。

**デフォルトの名無しさん** · 2009/07/08(水) 22:36:57

MSはyield使いまくってるよ
yieldはフレームワークを作る人のための機能、LINQは使う人のための機能だな

**デフォルトの名無しさん** · 2009/07/08(水) 22:38:09

.NET 4.0 のPLINQに期待。
CTPで試したけど、お手軽並列化はかなり便利だった。

**デフォルトの名無しさん** · 2009/07/08(水) 22:38:59

トン。なるほど。
確かに非常に楽にはなるし、拡張も楽だし、バグも入りにくいと思う。

でも、コードレビューに速度至上主義者がいるとそれが理解されないのよね。

**デフォルトの名無しさん** · 2009/07/08(水) 22:48:23

実際にボトルネックになるような場所でlinq使って叱られるのは当然だが
「なんか遅そうなコード」を見ただけで騒ぐのは
速度至上主義者じゃなくてただの阿呆や

**デフォルトの名無しさん** · 2009/07/08(水) 22:49:54

別にそれ自身遅いもんじゃないよ
IEnumerableを返すメソッドを手で書いたところでyieldより効率のいいものができるとは考えにくい
LINQは素直すぎるだけだ

**デフォルトの名無しさん** · 2009/07/08(水) 23:08:48

妄想で語っている人多い気はするね、LINQは初回の実行の時はコンパイルが入るから遅いのは分かるが
一度実行されると、二回目からは高速化する構造になっているしね。
LINQを使わない場合は、平均して中速になる。
ある意味LINQを使わないというのはパフォーマンス的には使いやすいかもしれないが、コーディングの楽さとそこそこのパフォーマンスの両得確保を目指すなら
LINQは外せないはず

**デフォルトの名無しさん** · 2009/07/08(水) 23:14:43

そういうパフォーマンス厨いるけど、実行速度に影響するのはそういう部分じゃなくデータ構造とか効率的なアルゴリズムとか。
LINQでのパフォーマンスの劣化なんてよっぽどの所でないと誤差の範囲。

**デフォルトの名無しさん** · 2009/07/08(水) 23:20:03

>>371
式木とクエリ式混同してない？

少なくとも、LINQ to object は動的生成一切ないよ。
foreach でコレクション操作するのに比べて、
静的メソッド呼び出しがちょっと増えて、その分のパフォーマンス落ちる程度。
静的メソッド呼び出しのコストなんてほんとたかが知れてて、
ほんの数％の最適化が必要な超クリティカルな場面以外は気にする必要ない。

**デフォルトの名無しさん** · 2009/07/08(水) 23:24:03

パフォーマンスについては間違ってる
クエリ演算子を繋げることによってネストされた列挙子ができて、列挙自体のコストがちょっとだけ増えるんだよ

**デフォルトの名無しさん** · 2009/07/08(水) 23:26:16

ああ、そか。
かかるコストは静的メソッド呼び出し分じゃなくて、
仮想メソッド分になるか＜列挙子のネスト。

**デフォルトの名無しさん** · 2009/07/08(水) 23:27:55

なんか適当な事書かれているような気がするぞ
foreachなどでやる場合は、連続したシーケンス操作では計算した値を何処かに確保して
また計算してというのが繰り返されているのに対して、クエリをバシバシつなげた場合は、中間データが作られないで処理される。
データ処理が縦に輪切りで処理するか横に輪切りで処理するかが変わる
この時決定的な差として、キャッシュの使用量がLINQを使った場合の方が小さくなって結果的に高速化するケースは多い。
オレはこっちの効果を重要視している

**デフォルトの名無しさん** · 2009/07/08(水) 23:29:27

>キャッシュの使用量
CPUのデータキャッシュの事ね、今のプロセッサではこれが決定的なパフォーマンスを決める

**デフォルトの名無しさん** · 2009/07/08(水) 23:36:57

LINQ使うときは最後まで列挙や評価を行わせないのが重要
Reverseみたいに、遅延実行の演算子の中にも危ないのがあるので注意

**デフォルトの名無しさん** · 2009/07/08(水) 23:37:56

yieldは結構便利なことに気付いた。
配列を返させてたところはこれに変えられる。

**デフォルトの名無しさん** · 2009/07/08(水) 23:38:06

>>378
気にしなくていいと思うけどね、よほどの問題が発生しない限り

**デフォルトの名無しさん** · 2009/07/09(木) 00:00:11

>>376
実際のところ、測ってみたら速くならなくない？
1段ラッパーされてる分のペナルティの方が大きくて。

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

**デフォルトの名無しさん** · 2009/07/09(木) 00:09:58

デリゲート呼び出しのコストがやっぱり大きいんじゃないかな
使い方を変えずにExpressionTreeで一つの大きな列挙子に展開することだって可能なわけで、
そういうところがLINQのポテンシャルなんだろうな

**デフォルトの名無しさん** · 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;
: 実際には実行されない大量のコード
}

**デフォルトの名無しさん** · 2009/07/09(木) 08:40:19

くだらない事やらずに分かりやすく書けやクズ

**デフォルトの名無しさん** · 2009/07/09(木) 08:44:04

インライン展開はMethodImpl属性で抑制できるぞ

**383** · 2009/07/09(木) 09:18:21

すまん、すまん。糞したり飯食ったりしてて続きを書くのを忘れていた。

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

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

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

**デフォルトの名無しさん** · 2009/07/09(木) 09:36:21

デリゲート呼び出しは通常の関数呼び出しの一割り増しぐらいだと外人の誰かがブログでグラフ付きでかいとったな。
ああいうページいつもどこ行ったか忘れちゃうんだよな･･･

**デフォルトの名無しさん** · 2009/07/09(木) 09:50:59

いかにデリゲート呼び出しが速かろうとベタに書くよりはそりゃ遅くなるに決まってる
最適化できなくなるんだから

**デフォルトの名無しさん** · 2009/07/09(木) 10:00:52

だから遅くても許容範囲なんじゃねーのって話だろ。
そんだけ速いの欲しかったらアセンブラで書いとけよ。

**デフォルトの名無しさん** · 2009/07/09(木) 13:22:47

それでも・・・僕はLINQを使うんだ！

**デフォルトの名無しさん** · 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 };
と、アホまっしぐらなコードに。

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

**デフォルトの名無しさん** · 2009/07/10(金) 01:26:45

クエリ式に固執しなければいいんじゃね？

**デフォルトの名無しさん** · 2009/07/10(金) 05:27:16

source.Select((Data, i) => new { Index = i + 1, Data });
クエリ構文だとやれることが少ないことに気づくと、だんだメソッド構文ばかり使うようになる

**デフォルトの名無しさん** · 2009/07/10(金) 08:19:37

トン
こんな便利なバージョンがあったとは。

**デフォルトの名無しさん** · 2009/07/10(金) 16:21:58

C#のLINQは大事なものはほとんど拡張メソッド版になっているよ
ムキになってメソッドでやるのもどうかと思うんだが……
VBのXMLリテラルなんぞを見ていると、やっぱ便利だし読みやすいし。
あんまり拡張メソッドに拘って欲しくないんだけどな

**デフォルトの名無しさん** · 2009/07/10(金) 22:45:31

XMLリテラルってXLINQだろ
XLINQ自体は良いものだとは思うけどそんな普及するかどうかもわからない
実験的なものをいきなり言語に組み込むとか

**デフォルトの名無しさん** · 2009/07/10(金) 23:20:37

全然違うような

**デフォルトの名無しさん** · 2009/07/11(土) 00:00:36

VBは使ったことはなかったけど…イコールではないよね。
XMLリテラルはXDocumentやXElementといった
LINQ to XMLのクラスを使っているだけで。

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

**デフォルトの名無しさん** · 2009/07/11(土) 00:09:02

だからLINQ to SQLみたいにLINQ to XMLがコケたらどうしようもないだろ
言語仕様レベルで依存してるんだから
それくらいしないとVBユーザーは新しいものを使おうとしないだろうとか考えたのかな

**デフォルトの名無しさん** · 2009/07/11(土) 00:16:09

Linq to Xmlは別にこけるこけないって次元の中身ではないと思うけど。
使ったことないで言ってるでしょ。

**デフォルトの名無しさん** · 2009/07/11(土) 01:13:05

Linq to XMLはC#では言語構文の拡張は何もやってない。
使ってるのはLinq to Objectの構文だけで、拡張はクラスライブラリだけ。
VBでは言語構文の拡張もやってて、XMLリテラルもその一種。

**デフォルトの名無しさん** · 2009/07/15(水) 18:58:43

この流れを見て、LINQ to XML触ってみた
書き方はすごく楽だね、こりゃ。

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

**デフォルトの名無しさん** · 2009/07/15(水) 22:02:46

あるある。
LoadOptions.SetLineInfoを活用しようとして、
ToDictionaryの代わりにToLookup+重複のないことの検査したり、
Count != 1なら自前の例外を投げてから、Single呼んだりする羽目になっている。

**デフォルトの名無しさん** · 2009/07/15(水) 22:18:29

>>402
スキーマ検証周りならベースにまず XmlReader を使え。
XmlReaderSettings で　XmlSchemaSet が指定できる

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

**デフォルトの名無しさん** · 2009/07/16(木) 00:18:20

トン、とても参考になった。SetLineInfoはかなり便利そう

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

**デフォルトの名無しさん** · 2009/07/16(木) 00:20:28

C#なら拡張メソッドがんがん作ってそういうのをチェックしながらのWhereとか例外メッセージつきのSelectとかいろいろ作りゃいいんじゃねーの。
0スタートのindexがくっついてくるSelectWithCountとか自分的に便利。

**デフォルトの名無しさん** · 2009/07/16(木) 04:16:14

>>406
それって標準のと何が違うの？
http://msdn.microsoft.com/ja-jp/library/bb534869.aspx

**デフォルトの名無しさん** · 2009/07/16(木) 08:01:45

index 付きの Select、みんなが意外知らない便利機能だけど、
まったく同じ機能を再発明しちゃった人までいるのか。

**406** · 2009/07/16(木) 08:29:31

・・・(´・ω・｀)
WhereWithCountとか色々作ったのに･･･

**デフォルトの名無しさん** · 2009/07/16(木) 10:22:56

引数なしのAny()とかも影薄いよな
Count() > 0とかやっちゃってる人も多そう

**デフォルトの名無しさん** · 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);
}

**デフォルトの名無しさん** · 2009/07/16(木) 14:51:15

手軽に作れるのが魅力の1つだよな

**407** · 2009/07/16(木) 17:27:01

>>410
> Count() > 0とかやっちゃってる人
……、ごめんなさい。私です。

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

**デフォルトの名無しさん** · 2009/07/16(木) 17:42:57

List<T>との整合性を考えても、ForEachの方がしっくりくるな

**デフォルトの名無しさん** · 2009/07/16(木) 19:36:16

>>413
Count使うと最後まで読まないといけないからパフォーマンスが悪いはず
Anyは一件あるかないかだから速いはず

**デフォルトの名無しさん** · 2009/07/29(水) 01:05:17

ttp://www.infoq.com/jp/news/2009/07/Reactive-Framework-LINQ-Events

**デフォルトの名無しさん** · 2009/09/12(土) 18:41:51

ﾇﾙﾎﾟ

**デフォルトの名無しさん** · 2009/09/12(土) 19:39:22

LINQと例外処理ってどうやって組み合わせている？

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

**デフォルトの名無しさん** · 2009/09/12(土) 23:31:27

LINQからIEnum処理するところすべてtry-catch(´・ω・｀)

**デフォルトの名無しさん** · 2009/09/13(日) 00:16:47

それは、不毛過ぎるw

**デフォルトの名無しさん** · 2009/09/14(月) 20:55:08

配列の要素を２個ずつ処理したいときにはどうすればいいでしょうか？

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