关于c#:虚虚实实亦假亦真的-ValueTuple绝对能眩晕你

50次阅读

共计 3038 个字符,预计需要花费 8 分钟才能阅读完成。

一:背景

1. 讲故事

前几天在写一个 api 接口,须要对衣物表进行分页查问,查问的 output 须要返回两个信息,一个是 totalCount, 一个是 clothesList, 在以前我可能须要封装一个 PagedClothes 类,如下代码:


    public class PagedClothes
    {public int TotalCount { get; set;}
        public List<Clothes> ClothesList {get; set;}
    }

    static PagedClothes GetPageList()
    {return new PagedClothes()
        {
            TotalCount = 100,
            ClothesList = new List<Clothes>() {}
        };
    }

在 C# 7.0 之后如果感觉封装一个类太麻烦或者没这个必要,能够用快餐写法,如下代码:


    static (int, List<Clothes>) GetPageList()
    {return (10, new List<Clothes>() {});
    }

这里的 (int, List<Clothes>) 是什么意思呢?懂的敌人看到 (x,y) 马上就会想到它是 .NET 引入的一个新类:ValueTuple,接下来的问题就是真的是 ValueTuple 吗?用 ILSpy 看看 IL 代码:


    .method private hidebysig static 
        valuetype [System.Runtime]System.ValueTuple`2<int32, class [System.Collections]System.Collections.Generic.List`1<class ConsoleApp2.Clothes>> GetPageList () cil managed 
    {
        IL_0000: nop
        IL_0001: ldc.i4.s 10
        IL_0003: newobj instance void class [System.Collections]System.Collections.Generic.List`1<class ConsoleApp2.Clothes>::.ctor()
        IL_0008: newobj instance void valuetype [System.Runtime]System.ValueTuple`2<int32, class [System.Collections]System.Collections.Generic.List`1<class ConsoleApp2.Clothes>>::.ctor(!0, !1)
        IL_000d: stloc.0
        IL_000e: br.s IL_0010

        IL_0010: ldloc.0
        IL_0011: ret
    } // end of method Program::GetPageList

GetPageList 办法的 IL 代码能够很容易的看出办法返回值和 return 处都有 System.ValueTuple 标记,<font color=”red”> 从此以后你可能就会认为 (x,y) 就是 ValueTuple 的化身 </font>,是吧,问题就呈现在这里,这个教训靠谱吗?

二:(x,y) 真的是 ValueTuple 的化身吗

为了去验证这个教训是否靠谱,我须要举几个例子:

1. (x,y) 接管办法返回值时是 ValueTuple 吗

为了更加分明的表述,先上代码:

        (int totalCount, List<Clothes> orders) = GetPageList();

        static (int, List<Clothes>) GetPageList()
        {return (10, new List<Clothes>() {});
        }

当初曾经晓得当 (x,y) 作为办法返回值的时候在 IL 层面会被化作 ValueTuple,那 (x,y) 作为承受返回值的时候又是什么意思呢?还会和 ValueTuple 有关系吗?为了去验证,能够用反编译能力弱点的 dnspy 去看看反编译后的代码:

从图中能够看出,当用 (x,y) 模式接管的时候,貌似就是实现映射赋值 或者 叫做拆解赋值, 是不是有一点含糊,这个 (x,y) 貌似和 ValueTuple 有关系,又貌似和 ValueTuple 没关系,不过没关系,持续看下一个例子。

2. (x,y) 在 foreach 迭代中是 ValueTuple 吗

(x,y) 也能够呈现在 foreach 中,置信第一次看到这么玩还是有一点吃惊的,如下代码:


        var dict = new Dictionary<int, string>();

        foreach ((int k, string v) in dict)
        { }

接下来持续用 dnspy 反编译一下:

我去,这回就清晰了,从图中能够看出,我写的 (x,y) 压根就没有 ValueTuple 的影子,阐明在这个场景下两者并没有任何关系,也就是说同样是 (x,y),放在不同地位具备不同的表现形式,这就很让人琢磨不透了,可能有些敌人不死心,想看一下 Deconstruct 到底干了什么,晓得的敌人应该明确这个新玩法叫做解构办法,持续看代码:


    public readonly struct KeyValuePair<TKey, TValue>
    {
        private readonly TKey key;
        private readonly TValue value;

        public void Deconstruct(out TKey key, out TValue value)
        {
            key = Key;
            value = Value;
        }
    }

有些抬杠的敌人会发现一个法则,貌似 (x,y) 放在赋值语句的右边都和 ValueTuple 没有任何关系,放在左边可能会有奇观产生,那到底是不是这样呢?持续硬着头皮举例子呗。

3. (x,y) 放在赋值语句的左边是 ValueTuple 吗


    public class Point
    {public int X { get; set;}
        public int Y {get; set;}

        public Point(int x, int y)
        {(X, Y) = (x, y);
        }
    }

嘿嘿,看这句: (X, Y) = (x, y) 里的 (x,y) 是 ValueTuple 的化身吗?我猜你必定是懵逼状态,是吧,亦真亦假,虚虚实实,证据还是持续反编译看呗。

我去,又是和 ValueTuple 一点关系都没有,啥玩意嘛,乌七八糟的,莫名其妙。

三:总结

说 (x,y) 是元组吧,放在 return 中就变成了 ValueTuple,说 (x,y) 不是元组吧,放在其余处还真就不是的,是不是很纳闷,为了更加形象,在 Point 中再减少一个 Test 办法,对照一下源码和反编译的代码:


    // 原始的:public class Point
    {public int X { get; set;}
        public int Y {get; set;}

        public Point(int x, int y)
        {(X, Y) = (x, y);
        }

        public (int x, int y) Test()
        {return (X, Y);
        }
    }

    // 反编译的:public class Point
    {public int X { get; set;}
        public int Y {get; set;}

        public Point(int x, int y)
        {
            this.X = x;
            this.Y = y;
        }

        [return: TupleElementNames(new string[]
        {
            "x",
            "y"
        })]
        public ValueTuple<int, int> Test()
        {return new ValueTuple<int, int>(this.X, this.Y);
        }
    }

反正我曾经恼火了,就这样吧,少用教训推理,多用工具挖一挖,这样才靠谱!

正文完
 0