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

【VB.NET】LINQ友の会 ..

288:デフォルトの名無しさん
08/11/05 00:12:26
URLﾘﾝｸ(channel9.msdn.com)

ちなみに、パスを1段削って、
URLﾘﾝｸ(channel9.msdn.com)
にするとPDCのセッションの一覧が出てくる。

289:デフォルトの名無しさん
08/11/05 00:31:16
ｔｈｘ

290:デフォルトの名無しさん
08/11/06 01:31:48
C#インタプリタ、すげぇ！

291:デフォルトの名無しさん
08/11/06 09:38:50
>>282
URLﾘﾝｸ(ufcpp.net)
これ？

foreach で置き換えるだけじゃたいして性能変わらない。
ここで違いが出てるのはそれの次の節の話で、
「if をループの外に出せ」と同じ原理で
「可能な限り where を from の上に」ってやるとパフォーマンス結構変わる。

292:デフォルトの名無しさん
08/11/06 10:16:15
LINQのクエリ式とSQLの一番の違いがプランナの有無。
クエリ式は書いた順番どおりに処理していくが、
SQLはプランナが最適な実行計画を立てる。

293:デフォルトの名無しさん
08/11/06 10:39:15
LinqtoObjectも気合い入れてプロバイダ書けばプランナ相当のもの記述可能？
いや書く気毛頭無いですが

294:デフォルトの名無しさん
08/11/08 12:26:24
やろうとおもえばLINQでスクリプト言語書けるよ

295:デフォルトの名無しさん
08/11/09 21:52:31
>> 294
出だしだけでもKWSK

296:デフォルトの名無しさん
08/11/11 17:07:42
LINQ to SQLって無くなるの？
なんつーか、ぶちまければ良いってもんじゃねぇだろ。
そんなのはオプソ系に任せとけよ。

297:デフォルトの名無しさん
08/11/11 18:08:39
何で無くなると思ったのさ？

298:デフォルトの名無しさん
08/11/11 18:35:18
なくなるっつーかLinq to Entityに置き換えでしょ。
別に今のところは対して書き方が違うわけじゃないし
Linq to Entity完成までの代打的存在として十分用を果たしたような。

299:デフォルトの名無しさん
08/11/11 22:44:48
うむ。かなりの部分でSQLの開発楽にしてくれた。
ストーリーにちゃんと沿わないと痛い目あうがなｗｗｗ

300:デフォルトの名無しさん
08/11/11 23:18:07
>>296
開発が止まるだけで今後も当面は.NET Frameworkに標準搭載が続くんじゃないの？

301:デフォルトの名無しさん
08/11/12 00:12:05
Entity Frameworkは絶対こける。
間違いない。

302:デフォルトの名無しさん
08/11/12 00:44:11
>>301
まあVer.3ぐらいになるまでは毎回大変更の嵐だろうな。

303:デフォルトの名無しさん
08/11/12 17:23:24
Entity FrameworkはLinq to SQLの問題点が色々と解決されてるんだけど
デザイナが使いにくすぎる。

RailsのActiveRecordみたいに
ちょこちょこっとクラスに属性を付ければモデル完成、
ってのフレームワークだったらよかったのに。

304:デフォルトの名無しさん
08/11/20 12:30:10
LINQ to SQLってADO.NETより目茶苦茶いいな。
更新系では、生のSQL文に完全なWHERE句を入れてくれるし、
非接続型・楽観的制御（←赤間さん流）では文句なし。
あと、生SQLのサブクエリ相当の組み合わせを段階を踏んで書けるのもいい。
デバッグも迅速になりそう。

305:デフォルトの名無しさん
08/11/20 15:06:45
俺、LINQ to P2P で当てたら結婚すんだ。

306:デフォルトの名無しさん
08/11/20 21:51:19
>>304
消える運命にあるが

307:デフォルトの名無しさん
08/11/20 22:15:10
なんらかの形で残るよ。使ってみれば、この方向性で進化していくんだろうと判る。
今のはちょっとSQL Serverに特化しすぎてるからディスコンかもしれないけどさ。

308:デフォルトの名無しさん
08/11/20 22:16:56
>>307
この方向性で進化した結果がLinq　to　Entityなんだけど、今のところいまいちの出来。

309:デフォルトの名無しさん
08/11/20 22:32:43
>>308
Entity Framework自体まだ手を付けてないのだが、どういまいち？

310:デフォルトの名無しさん
09/01/04 23:25:17
例えば、
Select Sum(col1),Sum(col2),Sum(col3) from Table1
なSQLだとLINQではどう書くの？

311:デフォルトの名無しさん
09/01/04 23:46:52
>>310
そんな質問はつい最近掲示板で見た事あるな

312:デフォルトの名無しさん
09/01/04 23:59:48
これか。ググったら一発で出てきたw
URLﾘﾝｸ(bbs.wankuma.com)

313:デフォルトの名無しさん
09/01/05 00:53:25
ただのマルチじゃねーかｗ

314:デフォルトの名無しさん
09/01/07 02:50:59
>>311 >>312 >>313
ケチは付けられても結局答えられる奴いねぇんだな
暇なカス野郎だけかよ

315:デフォルトの名無しさん
09/01/07 03:06:42
var result =
from item in Table1
select new {Sum1 = item.col1.Sum(), Sum2 = item.col2.Sum(), Sum3 = item.col3.Sum(), }

でいいんじゃね？

316:デフォルトの名無しさん
09/01/07 04:16:09
いや、良くない。範囲変数itemは単なる1レコードで、item.col?はスカラー
1回のループで計算したいなら、アキュムレータ使うしかないはず

var sum = Table1.Aggregate(new[] { 0, 0, 0 }, (y, x) => {
　　y[0] += x.col1;
　　y[1] += x.col2;
　　y[2] += x.col3;
　　return y;
});

317:デフォルトの名無しさん
09/01/07 05:35:25
>>316
それはクエリプロバイダ次第じゃなかろうか。

確かにLINQ to Objectのみなら>>316の書き方の方が速い。

しかしTable1.Aggregateのオーバーロード解決次第によっては
クエリプロバイダの提供する最適なクエリ演算子ではなく
LINQ to Objectの低速なパスで実行されるため>>316はかえって遅くなる。

式木的に
Select Sum(col1),Sum(col2),Sum(col3) from Table1
というSQLに対応するのが何かと聞かれれば>>315を推したい。

あとは>>310が何を期待して聞いたか次第かな。
LINQ to SQLでの書き方を期待していたなら>>315でも最適化されたと思うが。

318:デフォルトの名無しさん
09/01/07 08:09:53
LINQ to SQL、生成されたSQLクエリがどんなのか見れるから試してみればいいんでは。

319:デフォルトの名無しさん
09/01/07 08:21:29
いつもながらLinq to ほにゃららを明記しないと話がこじれるな。
Linq to Entityかもしれない。

320:デフォルトの名無しさん
09/01/07 10:45:44
マルチに答えるとつけあがるからやめとけ

321:デフォルトの名無しさん
09/01/07 12:34:27
>>317
考え方はいいとして、>>315のコードが間違っているのは無視か

var sum1 = Table1.Sum(item => item.col1);
var sum2 = Table1.Sum(item => item.col2);
var sum3 = Table1.Sum(item => item.col3);

やるならこうだろ

322:デフォルトの名無しさん
09/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();

323:デフォルトの名無しさん
09/01/07 14:08:38
ティマイザ→オプティマイザ

324:デフォルトの名無しさん
09/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)
});

325:デフォルトの名無しさん
09/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)
});

326:デフォルトの名無しさん
09/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のｽﾚにもﾚｽさせて頂きます。ご了承くださいませ。

327:デフォルトの名無しさん
09/02/20 07:06:29
>>326
マルチ乙

328:デフォルトの名無しさん
09/02/20 18:50:07
Microsohuto社製品なんて使うからだな

329:デフォルトの名無しさん
09/02/21 04:59:59
＞Microsohuto社
中国のばったものの会社？

330:デフォルトの名無しさん
09/02/21 21:28:41
株式会社精密工具

331:デフォルトの名無しさん
09/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から順番になるように保つ、という感じです

332:デフォルトの名無しさん
09/02/23 00:53:41
データが何個あるか調べて、XMLを作り直したほうが早いと思わんかね？

333:デフォルトの名無しさん
09/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>

334:デフォルトの名無しさん
09/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を直接変更してもいいと思う。

335:デフォルトの名無しさん
09/04/14 23:27:35
WPF の UIElementCollection に対して、
Linq の機能（Where メソッドとか）を使いたいのですが、
UIElementCollection にはそのメソッドがありません。

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

336:デフォルトの名無しさん
09/04/14 23:34:03
あー、non-generic な IEnumerable に対する Where とかないのか・・・
いったん、 .OfType<UIElement>() っての通すと使える気がする。

337:デフォルトの名無しさん
09/04/15 11:49:27
OfTypeじゃなくて，元のコレクションに違う型が入ってないことを仮定するCastのほうがベター
※foreach(UIElement item in collection)相当
OfTypeを使うのはOfType<Button>みたいに意図的に型をフィルタリングするときだけ

338:335
09/04/16 21:20:12
>>336 >>337
ありがとうございました。

339:デフォルトの名無しさん
09/04/19 23:45:46
良スレなのに過疎ってて残念。

340:デフォルトの名無しさん
09/04/20 12:48:21
ＳＱＬは糞

341:デフォルトの名無しさん
09/04/20 18:09:58
何をもって糞と判断してるのか

342:デフォルトの名無しさん
09/04/20 20:08:48
互換領域の文字だからだな

343:デフォルトの名無しさん
09/04/20 22:24:47
　int[] a = new int[] { 1, 2, 3 };
　a.ToList().ForEach(i => Trace.WriteLine(i) );

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

344:デフォルトの名無しさん
09/04/20 22:33:14
>>343
素直に foreach (var i in a) するか、自分で IEnumerable 用の ForEach 拡張メソッド書くか。

345:デフォルトの名無しさん
09/04/20 22:35:22
URLﾘﾝｸ(neue.cc)

346:デフォルトの名無しさん
09/04/20 22:59:17
DataTrigger で特定の Rectangle だけ色を変えようと思って、
TargetName を指定したら、Style では TargetName は指定できないという
エラーが出てしまいました。

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

347:346
09/04/21 06:16:25
すんません、誤爆です。

348:デフォルトの名無しさん
09/04/25 15:04:39
from age in

349:デフォルトの名無しさん
09/04/25 15:04:53
.

350:デフォルトの名無しさん
09/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だけを取得したいのですが、どうしたら
いいでしょうか？

351:デフォルトの名無しさん
09/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

ではダメ？

352:デフォルトの名無しさん
09/05/21 21:21:06
.NETとVisual Studioってどういう関係ですか？
.NETの後継？？

353:デフォルトの名無しさん
09/05/21 21:32:08
.NETは.NET
Visual StudioはVisual Studio

354:デフォルトの名無しさん
09/05/21 22:07:37
パイナップルと酢豚みたいなもんだな

355:デフォルトの名無しさん
09/05/21 22:08:10
>>354
それだと、.NETは要らない子になっちまうじゃないか。

356:デフォルトの名無しさん
09/05/21 22:59:46
>>354
吹いたｗｗ

357:デフォルトの名無しさん
09/05/21 23:13:02
パイナップルのない酢豚なんて・・・

358:デフォルトの名無しさん
09/05/22 13:52:09
オレも邪魔だと思ってたが、無いと寂しいｗ

359:デフォルトの名無しさん
09/05/22 14:38:39
で、

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

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

360:デフォルトの名無しさん
09/05/30 17:03:50
.NET = フレームワーク
VS = IDE

361:デフォルトの名無しさん
09/06/01 13:49:45
>>360

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

362:デフォルトの名無しさん
09/06/24 16:09:02
>>244-246って他社製のプロバイダ使ってってこと？

363:デフォルトの名無しさん
09/07/08 22:18:41
LINQ to Object やyield returnを使っていて
ふと「これ、何のために使っているんだろう」と思ってしまう。
旧.netと互換性がなくなる上に、実行速度は条件次第(そして多くの場合)落ちるし。

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

364:デフォルトの名無しさん
09/07/08 22:31:05
yield return は 2.0 からあるぞ。それより前となると
Generics もないので互換性気にするだけアレというか･･･

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

365:デフォルトの名無しさん
09/07/08 22:35:58
とりあえず書いて楽になったとおもわんか？
思わないなら別に使わなくていいだろ。
自分はIEnumerable<T>系を自分のライブラリでも多用してるし、yield使わないでIEnumerable返すコードなんか書きたくもないが。

366:デフォルトの名無しさん
09/07/08 22:36:57
MSはyield使いまくってるよ
yieldはフレームワークを作る人のための機能、LINQは使う人のための機能だな

367:デフォルトの名無しさん
09/07/08 22:38:09
.NET 4.0 のPLINQに期待。
CTPで試したけど、お手軽並列化はかなり便利だった。

368:デフォルトの名無しさん
09/07/08 22:38:59
トン。なるほど。
確かに非常に楽にはなるし、拡張も楽だし、バグも入りにくいと思う。

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

369:デフォルトの名無しさん
09/07/08 22:48:23
実際にボトルネックになるような場所でlinq使って叱られるのは当然だが
「なんか遅そうなコード」を見ただけで騒ぐのは
速度至上主義者じゃなくてただの阿呆や

370:デフォルトの名無しさん
09/07/08 22:49:54
別にそれ自身遅いもんじゃないよ
IEnumerableを返すメソッドを手で書いたところでyieldより効率のいいものができるとは考えにくい
LINQは素直すぎるだけだ

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

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

373:デフォルトの名無しさん
09/07/08 23:20:03
>>371
式木とクエリ式混同してない？

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

374:デフォルトの名無しさん
09/07/08 23:24:03
パフォーマンスについては間違ってる
クエリ演算子を繋げることによってネストされた列挙子ができて、列挙自体のコストがちょっとだけ増えるんだよ

375:デフォルトの名無しさん
09/07/08 23:26:16
ああ、そか。
かかるコストは静的メソッド呼び出し分じゃなくて、
仮想メソッド分になるか＜列挙子のネスト。

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

377:デフォルトの名無しさん
09/07/08 23:29:27
>キャッシュの使用量
CPUのデータキャッシュの事ね、今のプロセッサではこれが決定的なパフォーマンスを決める

378:デフォルトの名無しさん
09/07/08 23:36:57
LINQ使うときは最後まで列挙や評価を行わせないのが重要
Reverseみたいに、遅延実行の演算子の中にも危ないのがあるので注意

379:デフォルトの名無しさん
09/07/08 23:37:56
yieldは結構便利なことに気付いた。
配列を返させてたところはこれに変えられる。

380:デフォルトの名無しさん
09/07/08 23:38:06
>>378
気にしなくていいと思うけどね、よほどの問題が発生しない限り

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

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

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

383:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/07/09 08:40:19
くだらない事やらずに分かりやすく書けやクズ

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

386:383
09/07/09 09:18:21
すまん、すまん。糞したり飯食ったりしてて続きを書くのを忘れていた。

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

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

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

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

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

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

390:デフォルトの名無しさん
09/07/09 13:22:47
それでも・・・僕はLINQを使うんだ！

391:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/07/10 01:26:45
クエリ式に固執しなければいいんじゃね？

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

394:デフォルトの名無しさん
09/07/10 08:19:37
トン
こんな便利なバージョンがあったとは。

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

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

397:デフォルトの名無しさん
09/07/10 23:20:37
全然違うような

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

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

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

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

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

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

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

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

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

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

405:デフォルトの名無しさん
09/07/16 00:18:20
トン、とても参考になった。SetLineInfoはかなり便利そう

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

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

407:デフォルトの名無しさん
09/07/16 04:16:14
>>406
それって標準のと何が違うの？
URLﾘﾝｸ(msdn.microsoft.com)

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

409:406
09/07/16 08:29:31
・・・(´・ω・｀)
WhereWithCountとか色々作ったのに･･･

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

411:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/07/16 14:51:15
手軽に作れるのが魅力の1つだよな

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

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

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

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

416:デフォルトの名無しさん
09/07/29 01:05:17
URLﾘﾝｸ(www.infoq.com)

417:デフォルトの名無しさん
09/09/12 18:41:51
ﾇﾙﾎﾟ

418:デフォルトの名無しさん
09/09/12 19:39:22
LINQと例外処理ってどうやって組み合わせている？

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

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

420:デフォルトの名無しさん
09/09/13 00:16:47
それは、不毛過ぎるw

421:デフォルトの名無しさん
09/09/14 20:55:08
配列の要素を２個ずつ処理したいときにはどうすればいいでしょうか？

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

422:デフォルトの名無しさん
09/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
09/09/15 15:00:48
>>422
ありがとう。

424:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/09/16 06:48:18
まあどっちでもいいんじゃない？
拡張メソッドはガンガン使うべきなのかは迷うところ。

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

427:422
09/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:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/09/17 17:10:47
次はforをForEach()にするんですね

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

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

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

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

みたいに２回Selectしてるんですが、
１回で済む方法ないですか？

433:432
09/09/27 19:23:15
間違いました。 where を２回です。

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

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

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

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

437:432
09/09/27 19:58:37
優先度のある条件を集合に適用する処理を
以下のように書きました。

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

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

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

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

438:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/09/27 21:04:04
だね。
ruby の partition メソッドはズバりGroupBy。
ToLookupはその即時評価版。

440:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/10/10 19:43:10
プログラミングC#でLINQの項目をちょっと読んでみたが、
C#のコード中に普通にselectとかfromとか書くのは違和感あるなぁ。
C#の予約語になってんのかね？

442:デフォルトの名無しさん
09/10/10 19:44:40
>>441
文脈キーワード