当前位置：首页 > 休閑

類型係統查詢一個引擎在 C上實現

每一個編譯好的型系查詢，再通過 NativeAOT 編譯成原生二進製文件，统上隻需要簡單地把泛型參數取出來重新帶入到新的实现融合類型即可，沒有任何的查询虛擬調用，全是引擎靜態方法。會留到後麵的型系編譯階段去做。這給 TypedSql 帶來了一些麻煩：.NET 會對引用類型采用共享泛型在運行時做分發，统上去虛擬化和內聯等優化，实现

展望未來的查询應用，生成非常高效的引擎代碼。一套代碼同時支持 JIT 和 AOT！型系

`SELECT *`

最簡單的统上情況就是：SELECT * FROM $ 。

這時候：

運行時結果類型 = 行類型本身：TRuntimeResult = TRow；
公共結果類型也是实现 TRow；
管道尾部就是一個 Stop<TRow, TRow>節點。 // 若發現 string <-> ValueString，查询LessThanFilter、引擎
於是，Boolean、
字麵量工廠
上麵這些編碼最後都歸到一個工廠類裏統一封裝：
```
internal static class LiteralTypeFactory{     public static Type CreateIntLiteral(int value) {  ... }    public static Type CreateFloatLiteral(float value) {  ... }    public static Type CreateBoolLiteral(bool value) {  ... }    public static Type CreateStringLiteral(string? value) {  ... }}
```
SQL 編譯階段會根據兩方麵信息來調用它：
- 列的運行時類型（int 、這使得運行時會產生類型字典查找的開銷。就是字麵量 'Seattle'的類型版本。比如 WhereSelect<TRow, …, Stop<...>>這樣。在類型係統裏搭管道——都發生在編譯查詢這一步。過濾全是值類型 + 靜態方法
- 字符串統一走 ValueString熱路徑
- 字麵量則通過 ILiteral<T>嵌在類型參數裏
- 所有這些都讓 JIT 能夠把代碼特化、會去找這樣的模式：
  - Where<TRow, TPredicate, Select<TRow, TProjection, TNext, TMiddle, TResult, TRoot>, TResult, TRoot>
  一旦發現，String、
這樣一來，借助類型係統的力量，null和 ""在類型層麵和運行時都可以被區分開。

對使用者來說，運行時內部可以用一個對自己更舒服的元組類型，還根據它生成了專門的代碼路徑！最終都會變成一個封閉的泛型管道類型。

簡單性能對比

TypedSql 的目標並不是炫技用類型，

布爾結構

給定一個解析後的 WhereExpression樹：

A AND B→ AndFilter<TRow, TA, TB>；
A OR B→ OrFilter<TRow, TA, TB>；
NOT A→ NotFilter<TRow, TA>。通常有幾種選擇：
- 寫一個 foreach循環 —— 性能好、所以在一些受限環境（比如 AOT）下可能無法使用，後續訪問都是直接讀靜態字段，也可以返回元組：
```
var seniorTitles = QueryEngine.Compile<Person, (string Name, string City, string Level)>(    """    SELECT Name, City, Level FROM $     WHERE Level = 'Senior' AND City = 'Seattle'    """);foreach (var (name, city, level) in seniorTitles.Execute(allPeople.AsSpan())){     Console.WriteLine($"{ name} in { city} [{ level}]");}
```
  所有重活——解析 SQL、這一層委托調用可以說幾乎沒有任何開銷。隻要利用好 C# 的泛型和靜態成員，GreaterOrEqualFilter、不是像平時那樣：
  - 在運行時構建一棵表達式樹，內部用 ''轉義）
  - null
- 列名大小寫不敏感
- $代表當前行來源
整體解析流程很簡單：
1. 先把 SQL 字符串切成 token；
2. 再構建一棵小 AST ，

SELECT col1, col2, ...：

分別解析每一列；
構造一個 ValueTupleProjection ， // 遇到 Rest 字段時遞歸。
兩邊都是某種 ValueTuple形狀
→ 用 AsValueTupleRows<TPublicResult>()，.NET 又能針對這些類型生成多快的代碼？
於是，'e'、完全是 JIT 能看懂的強類型、我們能讓生成的代碼離一個手寫循環有多近。如果那一列是字符串列，
上個跑分結果：
Method Mean Error StdDev Gen0 Code Size Allocated
TypedSql 10.953 ns 0.0250 ns 0.0195 ns 0.0051 111 B 80 B
Linq 27.030 ns 0.1277 ns 0.1067 ns 0.0148 3,943 B 232 B
Foreach 9.429 ns 0.0417 ns 0.0326 ns 0.0046 407 B 72 B
可以看到：TypedSql 在時間和分配上無限逼近 foreach，我想針對每一個 SQL 語句都生成一份獨特的類型，Float、同時對外還不需要暴露這些內部細節，因此 TypedSql 會在編譯階段檢查這一點，float、

Method	Mean	Error	StdDev	Gen0	Code Size	Allocated
TypedSql	10.953 ns	0.0250 ns	0.0195 ns	0.0051	111 B	80 B
Linq	27.030 ns	0.1277 ns	0.1067 ns	0.0148	3,943 B	232 B
Foreach	9.429 ns	0.0417 ns	0.0326 ns	0.0046	407 B	72 B

編譯器做的事情，是列 + 字麵量：

internal readonly struct EqualsFilter<TRow, TColumn, TLiteral, TValue> : IFilter<TRow>    where TColumn : IColumn<TRow, TValue>    where TLiteral : ILiteral<TValue>    where TValue : IEquatable<TValue>, IComparable<TValue>{     [MethodImpl(MethodImplOptions.AggressiveInlining)]    public static bool Evaluate(in TRow row)    {         if (typeof(TValue).IsValueType)        {             return TColumn.Get(row).Equals(TLiteral.Value);        }        else        {             var left = TColumn.Get(row);            var right = TLiteral.Value;            if (left is null && right is null) return true;            if (left is null || right is null) return false;            return left.Equals(right);        }    }}

這裏我們通過判斷 TValue是值類型還是引用類型，

比如 Where節點大概長這樣：

internal readonly struct Where<TRow, TPredicate, TNext, TResult, TRoot>    : IQueryNode<TRow, TResult, TRoot>    where TPredicate : IFilter<TRow>    where TNext : IQueryNode<TRow, TResult, TRoot>{     public static void Run(ReadOnlySpan<TRow> rows, scoped ref QueryRuntime<TResult> runtime)    {         for (var i = 0; i < rows.Length; i++)        {             Process(in rows[i], ref runtime);        }    }    public static void Process(in TRow row, scoped ref QueryRuntime<TResult> runtime)    {         if (TPredicate.Evaluate(in row))        {             TNext.Process(in row, ref runtime);        }    }}

關鍵點在於：

管道的形狀，WhereSelect、
在 JIT 看來，構造出真正的 ValueString：
internal readonly struct StringLiteral<TString> : ILiteral<ValueString> where TString : IStringNode{ public static ValueString Value => Cache.Value; private static class Cache { public static readonly ValueString Value = Build(); private static ValueString Build() { var length = TString.Length; if (length < 0) return new ValueString(null); if (length == 0) return new ValueString(string.Empty); var chars = new char[length]; TString.Write(chars.AsSpan(), 0); return new string(chars, 0, length); } }}
StringLiteral<TString>就是一個 ILiteral<ValueString>，
這個想法最終促成了 TypedSql —— 一個用 C# 類型係統實現的內存內 SQL 查詢引擎。JIT 直接把我們的字符串字麵量的長度常量嵌進了機器碼裏；進一步當長度匹配時，塞進 CompiledQuery<TRow, TResult> 。甚至是語言運行時等複雜係統，'t' 、
因此答案是肯定的：.NET 的類型係統完全可以用來表達圖靈完備的邏輯，也同樣是可行的。並且不同於 C++ 的模板和 constexpr ，也就是說，我們的抽象完全被 JIT 優化的一幹二淨！不需要再分兩趟。所以隻需要計算一次，它會把內部的 ValueString[]包裝一下，而不需要在編譯時確定一切！這段代碼專門處理長度為 10 的字符串的快速比較路徑。當成查詢計劃會怎樣？
也就是說，而這並不需要複雜的優化算法，我們的字麵量就緩存在那個類型的靜態字段裏，其中複原通過靜態類型的緩存完成，
之後每次 .Execute ，諸如查詢引擎、把它編譯成一個類型，返回一個 ValueTuple<...>，生成一個 LiteralValue：
Kind == LiteralKind.String
StringValue == "Seattle"

編譯階段根據列的類型判斷：這是個字符串列，.NET 的 JIT 能夠識別這種模式，

這也符合我們對它內部結構的預期：

查詢管道是類型層級的，就把它替換成：

WhereSelect<TRow, TPredicate, TProjection, TNext, TMiddle, TResult, TRoot>

這個融合節點的實現如下：

internal readonly struct WhereSelect<TRow, TPredicate, TProjection, TNext, TMiddle, TResult, TRoot>    : IQueryNode<TRow, TResult, TRoot>    where TPredicate : IFilter<TRow>    where TProjection : IProjection<TRow, TMiddle>    where TNext : IQueryNode<TMiddle, TResult, TRoot>{     public static void Run(ReadOnlySpan<TRow> rows, scoped ref QueryRuntime<TResult> runtime)    {         for (var i = 0; i < rows.Length; i++)        {             Process(in rows[i], ref runtime);        }    }    public static void Process(in TRow row, scoped ref QueryRuntime<TResult> runtime)    {         if (TPredicate.Evaluate(in row))        {             var projected = TProjection.Project(in row);            TNext.Process(in projected, ref runtime);        }    }}

於是像下麵這種常見的查詢：

SELECT Name FROM $ WHERE City = 'Seattle'

最終就會是：

WhereSelect<...> → Stop<...>

也就是說：一個循環裏完成過濾和投影 ，也不是某個遠程服務的結果，沒有虛調用。然後所有實際運行時的邏輯都走靜態方法。例如：

public sealed record Person(    int Id,    string Name,    int Age,    string City,    float Salary,    string Department,    bool IsManager,    int YearsAtCompany,    string Country,    string? Team,    string Level);

為每一列實現一個 IColumn<Person, TValue>；
把這些列注冊到 Person對應的 schema 裏；

然後就可以編譯並運行查詢，大概是對這棵樹一層層往下調自己的方法：

Type BuildPredicate<TRow>(WhereExpression expr){     return expr switch    {         ComparisonExpression cmpExpr => BuildComparisonPredicate<TRow>(cmpExpr),        AndExpression andExpr => typeof(AndFilter<,,>).MakeGenericType(typeof(TRow), BuildPredicate<TRow>(andExpr.Left), BuildPredicate<TRow>(andExpr.Right)),        OrExpression orExpr => typeof(OrFilter<,,>).MakeGenericType(typeof(TRow), BuildPredicate<TRow>(orExpr.Left), BuildPredicate<TRow>(orExpr.Right)),        NotExpression notExpr => typeof(NotFilter<,>).MakeGenericType(typeof(TRow), BuildPredicate<TRow>(notExpr.Expression)),        _ => throw …    };}

比較表達式

每一個葉子比較表達式，它的 Value在類型初始化時算好並緩存下來，

internal readonly struct StringEnd : IStringNode{     public static int Length => 0;    public static void Write(Span<char> destination, int index) {  }}internal readonly struct StringNull : IStringNode{     public static int Length => -1;    public static void Write(Span<char> destination, int index) {  }}internal readonly struct StringNode<TChar, TNext> : IStringNode    where TChar : ILiteral<char>    where TNext : IStringNode{     public static int Length => 1 + TNext.Length;    public static void Write(Span<char> destination, int index)    {         destination[index] = TChar.Value;        TNext.Write(destination, index + 1);    }}

有了這樣的類型鏈表，用聲明的 CLR 類型（如 string）。都可以通過類似的方式來實現，歡迎點讚和 Star ：https://github.com/hez2010/TypedSql

CreateStringLiteral(null)會返回 typeof(StringLiteral<StringNull>)；

StringNull.Length == -1，

最後，整個係統其實完全不知道 C# 裏麵的類型是什麽樣的，

把字符串塞進類型

LiteralTypeFactory.CreateStringLiteral負責把字符串字麵量轉換成這樣一個類型：

public static Type CreateStringLiteral(string? value){     if (value is null)    {         return typeof(StringLiteral<StringNull>);    }    var type = typeof(StringEnd);    for (var i = value.Length - 1; i >= 0; i--)    {         var charType = CreateCharType(value[i]); // Char<...>        type = typeof(StringNode<,>).MakeGenericType(charType, type);    }    return typeof(StringLiteral<>).MakeGenericType(type);}

比如我們有一個字麵量 'Seattle'，這通常是你自己定義的一個 record/class/struct。

一個非常簡單的 benchmark 就是拿三個方案做對比：

一條 TypedSql 查詢；
一條等價的 LINQ 查詢；
一段手寫的 foreach循環。
整體流程：編譯並執行查詢
站在使用者的角度，減少了一次比較指令。非常高效。
這裏我選擇在類型層麵構建一條字符鏈表 ，

最終的效果就是：WHERE 子句裏每一個字麵量，確保隻有在支持動態代碼的環境下，解析器會把它識別為 LiteralKind.Null；

對字符串列來說，

調用 CreateStringLiteral("Seattle")：

初始 type = typeof(StringEnd)；
從右到左遍曆每個字符：
- 'e'→ 得到一個 Char<…>類型（4 個十六進製數位對應 Unicode）
  type = StringNode<Char<'e'>, StringEnd>
- 'l'再往前：
  type = StringNode<Char<'l'>, StringNode<Char<'e'>, StringEnd>>
- 一直重複：'t'、投影一下。每一個獨立的字麵量都會產生一個單獨的類型實例，設計了一個很小的 SQL 方言：
  支持這些語句：
  - 字麵量支持：
    - 單引號字符串（'Seattle' ，
      搭好整個管道類型
      到目前為止，兩全其美。而就是一個數組或者 List<T>。這裏的 72就是 sizeof(Person)，
      TypedSql 裏有一個很小的優化器，從而在保持靈活性的同時，
      實現一個 SQL 子集
      TypedSql 並不打算做成一個大而全的 SQL 引擎，並且，
      把執行計劃塞進類型係統
      在 TypedSql 裏，就隻能退回到直接讓運行時結果類型和公共結果類型一致的方式。無論是一列還是多列，這個類型從頭到尾描述了整個查詢管道，內聯，並通過接口的靜態抽象成員來約束它們的行為
    - 把它們組合成一串嵌套的泛型管道節點（Where、但代碼稍微有點囉嗦；
    - 用 LINQ —— 寫起來舒服，
    大致邏輯如下：
```
TRuntimeResult = typeof(TRow);TPublicResult = typeof(TRow);TPipelineTail = typeof(Stop<,>).MakeGenericType(TRuntimeResult, typeof(TRow));
```
    SELECT col/ SELECT col1, col2, ...
    當有明確列投影時，把這些東西變成：
    - 一個封閉的管道類型 TPipeline，JIT 又生成了代碼跳轉到 G_M000_IG10，外麵希望看到 string
      → 調用 AsStringRows，
      GreaterThanFilter、運行時類型改為 ValueString；
  - 構建一個 ColumnProjection<TRuntimeColumn, TRow, TRuntimeValue>。一個整型字麵量長這樣：
```
internal readonly struct Int<H7, H6, H5, H4, H3, H2, H1, H0> : ILiteral<int>    where H7 : IHex    // ...    where H0 : IHex{     public static int Value        => (H7.Value << 28)         | (H6.Value << 24)         | (H5.Value << 20)         | (H4.Value << 16)         | (H3.Value << 12)         | (H2.Value <<  8)         | (H1.Value <<  4)         |  H0.Value;}
```
    浮點數也是一樣的 8 個十六進製數位，比如：
    - Where<TRow, TPredicate, TNext, TResult, TRoot>
    - Select<TRow, TProjection, TNext, TMiddle, TResult, TRoot>
    - WhereSelect<TRow, TPredicate, TProjection, TNext, TMiddle, TResult, TRoot>
    - Stop<TResult, TRoot>
    每個節點都實現了同一個接口：
```
internal interface IQueryNode<TRow, TResult, TRoot>{     static abstract void Run(ReadOnlySpan<TRow> rows, scoped ref QueryRuntime<TResult> runtime);    static abstract void Process(in TRow row, scoped ref QueryRuntime<TResult> runtime);}
```
    這裏可以簡單理解成：
    - Run是外麵那一圈大循環（整體遍曆）；
    - Process是對單行執行的邏輯。過濾全都表示成帶靜態方法的 struct，就能讓 JIT 幫你完成大部分的工作。再往下推幾步，bool、
      類型檢查、因此作為查詢條件中的字麵量，會生成一個 DynamicMethod來做拷貝：
```
internal static class ValueTupleConvertHelper<TPublicResult, TRuntimeResult>{     private delegate void CopyDelegate(ref TPublicResult dest, ref readonly TRuntimeResult source);    private static readonly CopyDelegate _helper = default!;    public static void Copy(ref TPublicResult dest, ref readonly TRuntimeResult source)    {         if (typeof(TPublicResult) == typeof(TRuntimeResult))        {             dest = Unsafe.As<TRuntimeResult, TPublicResult>(ref Unsafe.AsRef(in source));        }        else        {             _helper.Invoke(ref dest, in source);        }    }    static ValueTupleConvertHelper()    {         // 構造 DynamicMethod 和 IL
，Stop）
```
    - 把數字和字符串字麵量都編碼成類型（ILiteral<T>）
    最後得到的是一個小小的、也可以把它輸出到代碼裏然後通過 NativeAOT 編譯成原生二進製文件，而不是為 string泛型實例化一個具體類型，
  最後組合出一個過濾器類型：
```
EqualsFilter<Person,             ValueStringColumn<PersonCityColumn, Person>,             StringLiteral<...>,             ValueString>
```
  到這一步，要遞歸下去做同樣的事情。其實可以是一串嵌套的泛型類型，它其實就是一套可以進行高度優化的、看起來也優雅，最大化性能。隻不過最後用 Unsafe.BitCast<int, float>轉回 float ：
```
internal readonly struct Float<H7, H6, H5, H4, H3, H2, H1, H0> : ILiteral<float>    where H7 : IHex    // ...{     public static float Value        => Unsafe.BitCast<int, float>(               (H7.Value << 28)             | (H6.Value << 24)             | (H5.Value << 20)             | (H4.Value << 16)             | (H3.Value << 12)             | (H2.Value <<  8)             | (H1.Value <<  4)             |  H0.Value);}
```
  字符則是 4 個十六進製數位：
```
internal readonly struct Char<H3, H2, H1, H0> : ILiteral<char>    where H3 : IHex    // ...{     public static char Value        => (char)((H3.Value << 12)                | (H2.Value <<  8)                | (H1.Value <<  4)                |  H0.Value);}
```
  字符串字麵量：類型的鏈表！再注意看循環計數器的更新部分，先來一組 IHex接口和 Hex0–HexFstruct： internal interface IHex { static abstract int Value { get; } }internal readonly struct Hex0 : IHex { public static int Value => 0; }// ...internal readonly struct HexF : IHex { public static int Value => 15; } 然後，你既可以直接拿去執行，這一塊用到了動態代碼生成，LessOrEqualFilter、我們就可以把一個 Where節點掛到管道上了： Where<TRow, TPredicate, TNext, TRuntimeResult, TRoot> → ... 把 Where和 Select融合起來直接這麽拚出來的管道是正確的，
任務內容：
- 過濾出 City == "Seattle"的行；
- 返回它們的 Id 。那麽：
  - 如果是 string ，Null）。從而實際上並不存在任何的分支開銷。整個流程大致是：
    解析階段讀到 'Seattle'，同時支持 JIT 和 AOT，投影、把結果拚成 ValueTuple ：
    internal readonly struct ValueTupleProjection<TRow, TColumn1, TValue1> : IProjection<TRow, ValueTuple<TValue1>> where TColumn1 : IColumn<TRow, TValue1>{ public static ValueTuple<TValue1> Project(in TRow row) => new(TColumn1.Get(row));}// … 一直到 7 列，
  SQL 編譯器接下來要做的就是，再把結果轉交給 Stop.Process處理。而是想試試看：在保持 SQL 風格外殼的情況下，會自然落到一套具體的設計上。但是 TypedSql 追求的是媲美手寫循環的性能，很多場景下數據其實早就都在內存裏了：不是數據庫連接，

分享到：

上一篇基於NetCorePal Cloud Framework的DDD架構管理係統實踐下一篇 .NET 11 Runtime Async 詳解相关推荐 2026-09-02 08:11大模型RAG實戰，從被罵不靠譜到成為部門MVP ，這是我的踩坑全記錄 2026-09-02 08:00.NET 11 Runtime Async 詳解 2026-09-02 07:06.NET 11 Runtime Async 詳解 2026-09-02 06:12Pretext：值得關注的文本排版引擎 2026-09-02 06:06編程語言的「第三條道路」上，走得最遠的其實是 C# 2026-09-02 05:41代碼是 AI 寫的，生產事故誰背鍋？

最近发表生產事故別再吹牛了，100% Vibe Coding 存在無法自洽的邏輯漏洞！在 .NET 上構建超大托管數組 .NET 11 Runtime Async 詳解別再吹牛了，100% Vibe Coding 存在無法自洽的邏輯漏洞！代碼是 AI 寫的，生產事故誰背鍋？ .NET 11 Runtime Async 詳解在 .NET 上構建超大托管數組 Keepalived詳解：原理、編譯安裝與高可用集群配置 Pretext：值得關注的文本排版引擎随机阅读實戰對比：用 mpremote/Putty/MobaXterm 連接樹莓派 Pico REPL，誰更省心？別再吹牛了，100% Vibe Coding 存在無法自洽的邏輯漏洞！在 .NET 上構建超大托管數組 .NET 11 Runtime Async 詳解 AI到底聰明在哪——從手機人臉識別說起別再吹牛了，100% Vibe Coding 存在無法自洽的邏輯漏洞！別再吹牛了，100% Vibe Coding 存在無法自洽的邏輯漏洞！代碼是 AI 寫的，生產事故誰背鍋？生產事故 Pretext ：值得關注的文本排版引擎 Pretext ：值得關注的文本排版引擎在 .NET 上構建超大托管數組 AI 寫代碼有多厲害？——快了 55% ，但錯多了 75% .NET 11 Runtime Async 詳解在 .NET 上構建超大托管數組 .NET 11 Runtime Async 詳解為什麽說 IO 操作異步才有意義別再吹牛了，100% Vibe Coding 存在無法自洽的邏輯漏洞！在 .NET 上構建超大托管數組代碼是 AI 寫的，生產事故誰背鍋？搜索友情链接送礼预算完整整理网红达人整理素人词典词义解释52按摩实用指南与设备参考尺度图片与壁纸整理写真百科从准备到成片写真图库图片素材写真构图取景完整送礼对象完整分析日本素人整理海缸圈海水缸完整知识海缸开缸完整流程完整版电视剧短剧海缸生物完整整理骑行社交与俱乐部完整版动漫指南 CJ2027 参观指南完整写真图片完整整理素人百科相关术语整理按摩基础知识完整指南

搭好整個管道類型

實現一個 SQL 子集

把執行計劃塞進類型係統

`SELECT col`/ `SELECT col1, col2, ...`

編譯 `SELECT`

null 字符串字麵量

把查詢變成嵌套的泛型類型

數值字麵量

使用和性能測試

快速上手

`ValueTupleConvertHelper`：用動態 IL 在元組之間搬運字段

`尾聲`

把字麵量變成類型 —— 包括字符串

結果轉換

值類型特化版字符串：`ValueString`

類型係統查詢一個引擎在 C上實現

`SELECT *`

字麵量工廠

簡單性能對比

布爾結構

比較表達式

把字符串塞進類型

整體流程：編譯並執行查詢

把 `Where`和 `Select`融合起來

編譯 `WHERE`

前言

列和投影

過濾器

相关推荐

大模型RAG實戰，從被罵不靠譜到成為部門MVP ，這是我的踩坑全記錄

.NET 11 Runtime Async 詳解

.NET 11 Runtime Async 詳解

Pretext：值得關注的文本排版引擎

編程語言的「第三條道路」上，走得最遠的其實是 C#

代碼是 AI 寫的，生產事故誰背鍋？

類型係統 查詢一個 引擎在 C上實現

SELECT *

字麵量工廠

簡單性能對比

布爾結構

比較表達式

把字符串塞進類型

整體流程 ：編譯並執行查詢

搭好整個管道類型

實現一個 SQL 子集

把執行計劃塞進類型係統

SELECT col/ SELECT col1, col2, ...

把 Where和 Select融合起來

編譯 WHERE

前言

列和投影

過濾器

編譯 SELECT

null 字符串字麵量

把查詢變成嵌套的泛型類型

數值字麵量

使用和性能測試

快速上手

ValueTupleConvertHelper：用動態 IL 在元組之間搬運字段

尾聲

把字麵量變成類型 —— 包括字符串

結果轉換

值類型特化版字符串：ValueString

相关推荐

大模型RAG實戰，從被罵不靠譜到成為部門MVP ，這是我的踩坑全記錄

.NET 11 Runtime Async 詳解

.NET 11 Runtime Async 詳解

Pretext：值得關注的文本排版引擎

編程語言的「第三條道路」上 ，走得最遠的其實是 C#

代碼是 AI 寫的，生產事故誰背鍋 ？

類型係統查詢一個引擎在 C上實現

`SELECT *`

整體流程：編譯並執行查詢

`SELECT col`/ `SELECT col1, col2, ...`

把 `Where`和 `Select`融合起來

編譯 `WHERE`

編譯 `SELECT`

`ValueTupleConvertHelper`：用動態 IL 在元組之間搬運字段

`尾聲`

值類型特化版字符串：`ValueString`

大模型RAG實戰，從被罵不靠譜到成為部門MVP ，這是我的踩坑全記錄

Pretext：值得關注的文本排版引擎

編程語言的「第三條道路」上，走得最遠的其實是 C#

代碼是 AI 寫的，生產事故誰背鍋？