这里表达式树限制的机制是什么?
事实上,我期望它能起作用,但它并没有让我去寻找那张我没有看到的图片。
The fact that I expected this to work and it didn't leads me to search for the piece of the picture that I don't see.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
想象一下该查询被远程到数据库。数据库引擎在执行查询时如何通过互联网访问并告诉计算机上的“count”变量进行自我更新?没有这样做的标准机制,因此任何会改变本地计算机上变量的内容都不能放入将在远程计算机上运行的表达式树中。
更一般地说,在执行时引起副作用的查询是非常非常糟糕的查询。 永远不要在查询中添加副作用,即使这样做是合法的。这可能会非常令人困惑。请记住,查询不是
for
循环。查询结果表示查询的对象,而不是查询的结果。执行时具有副作用的查询将在两次请求其结果时执行这些副作用两次,并在零次请求结果时执行零次。第一部分改变变量的查询将在第二个子句执行之前(而不是在第二个子句执行期间)改变该变量。因此,许多查询子句在依赖于副作用执行时会给出完全奇怪的结果。有关此问题的更多想法,请参阅 Bill Wagner 关于该主题的 MSDN 文章:
http://msdn.microsoft.com/en-us/vcsharp/hh264182
如果您是编写 LINQ-to-Objects 查询时,您可以通过压缩来完成您想要的操作:
也就是说,创建一系列数字和活动对,然后操作这些对。
我不知道你如何在 LINQ-to-whatever-you're-using 中做到这一点。
Imagine that query being remoted over to a database. How is the database engine supposed to reach over the internet as it is executing the query and tell the "count" variable on your machine to update itself? There is no standard mechanism for doing so, and therefore anything that would mutate a variable on the local machine cannot be put into an expression tree that would run on a remote machine.
More generally, queries that cause side effects when they are executed are very, very bad queries. Never, ever put a side effect in a query, even in the cases where doing so is legal. It can be very confusing. Remember, a query is not a
for
loop. A query results in an object represents the query, not the results of the query. A query which has side effects when executed will execute those side effects twice when asked for its results twice, and execute them zero times when asked for the results zero times. A query where the first part mutates a variable will mutate that variable before the second clause executes, not during the execution of the second clause. As a result, many query clauses give totally bizarre results when they depend on side effect execution.For more thoughts on this, see Bill Wagner's MSDN article on the subject:
http://msdn.microsoft.com/en-us/vcsharp/hh264182
If you were writing a LINQ-to-Objects query you could do what you want by zipping:
That is, make a sequence of pairs of numbers and campaigns, then manipulate the pairs.
How you'd do that in LINQ-to-whatever-you're-using, I don't know.
当您将任何内容传递给需要表达式的方法时,当时实际上不会评估任何内容。它所做的只是分解代码并从中创建一个表达式树。
现在,在 .Net 4.0 中,Expression API 中添加了很多内容(包括 Expression .Increment 和 Expression.Assign 这实际上就是您正在做的事情),但是编译器(我认为这是 C# 编译器的限制)尚未更新以利用新的功能4.0 表达的东西。因此,我们仅限于方法调用,而赋值调用将不起作用。假设,这在未来可能会得到支持。
When you pass anything to a method that expects an Expression, nothing is actually evaluated at that time. All it does is, it breaks apart the code and creates an Expression tree out of it.
Now, in .Net 4.0, alot of things were added to the Expression API (including Expression.Increment and Expression.Assign which would actually be what you're doing), however the compiler (I think it's a limitation of the C# compiler) hasn't been updated yet to take advantage of the new 4.0 Expression stuff. Therefore, we're limited to method calls, and assignment calls will not work. Hypothetically, this could be supported in the future.
几乎意味着:
这就是分配发生的地方和错误的根源。
根据这个问题的不同答案,这应该可以通过.NET 4.0 使用表达式,但不是在 lambda 中。
Pretty much means:
That's where the assignment is happening and the source of the error.
According to the different answers to this question, this should be possible with .NET 4.0 using expressions, though not in lambdas.