最近又開始了一波GPT4的散播焦慮活動，而實際上，ai并不能在特別精細的地方替代人類，例如一個基于GPT4的工具——cursor，它可以用來生成代碼，但如果代碼涉及一些特別麻煩的東西，那指定還是不行的，比如我在試用該工具的時候讓它編寫的c代碼（經(jīng)過我修改了不妨類型和指針轉(zhuǎn)換后勉強可以通過編譯，但會segmentation fault）：

這里我一步步的要求它編寫了一個只有很小一部分功能的ecs，從一個allocator（我猜錯誤多半發(fā)生在這個allocator，但我沒有仔細研究）開始，編寫一些數(shù)據(jù)結(jié)構(gòu)，然后用這些數(shù)據(jù)結(jié)構(gòu)構(gòu)建一個簡單的ecs的數(shù)據(jù)部分

這里我們來復(fù)現(xiàn)一下這個過程，看看是否為之前操作不當

然后我們得到這樣的代碼，顯然和分頁不能說是完全符合，只能說是毫無關(guān)系

很神奇的是，這次它居然知道用mmap（這里我們先不管對不對，先讓它寫著）

于是，就獲得了一個回收的函數(shù)

這里我們不自己檢查代碼，讓它來檢查

它似乎沒有理解到位

這里，只是做了基于頁的內(nèi)存綁定，但我們需要這個類型同時還幫我們處理指針的內(nèi)存分配和回收，于是我們這樣告訴他：

然后它就把這個類型變成專門管理某一個指針內(nèi)存的類型了

于是，我們問它：

但我們顯然不滿意，我們著是page allocator，限制其的一個是內(nèi)存，而不是指針的數(shù)量

當然，這里會不會有內(nèi)存錯誤我們是沒有確認的，讓它提供一個例子我們來試試：

那么我們先暫時這樣，開始下一步：

看起來不錯的樣子

但是只能存整數(shù)有點一般

這里，它只是把int替換成了void*，就不貼上全部的代碼了，老規(guī)矩讓它提供一個使用例：

其實，這里就已經(jīng)有錯了，因為并沒有提供回收內(nèi)存的邏輯，只是簡單的整個釋放，而它卻出現(xiàn)了這樣的調(diào)用：page_free(&list->allocator, current);需要讓它自行修復(fù)，果然刪除了第二個參數(shù)

于是我們直接提錯誤給它：

我們剛才就說了，這里的free其實一次性釋放了所有依托于該allocator的內(nèi)存，所有多次調(diào)用必然會崩，其實這樣就行（其實看到這里就知道ai其實還是替代不了程序員，至少目前還不能替代我）

而且，當前實現(xiàn)的問題其實已經(jīng)很明顯的暴露出來了，只能一次性開所有內(nèi)存，也只能一次性回收所有內(nèi)存，沒有回收單個指針的內(nèi)存的解決方案，由于沒有考慮獲取到的內(nèi)存是分頁的，可能還存在跨頁內(nèi)存的問題，我倒要看看這個ai怎么解決，先告訴它一點小毛病

強調(diào)一下：

那么，我們剛才說的問題都得解決對不對，我們一項一項來

先安排它解決單個指針的內(nèi)存回收問題：

看來得給出更明確的說法：

血壓已經(jīng)上來了，可能是我英文不好？試試中文和它說？

那我們先accept，待會兒再看有沒有bug再讓它改，那么當務(wù)之急時讓它修改鏈表的邏輯來適應(yīng)新的allocator

但是有一個問題，那就是該鏈表使用了這個allocator，但不代表它具有該allocator的所有權(quán)，你鏈表釋放關(guān)我allocator什么事，你把我內(nèi)存全釋放了干嘛

讓它自己檢查一下：

實際上，當前的問題已經(jīng)多到我一時半會不知道怎么解決的地步了，我讓它自己解釋一下它在寫什么吧：

問題是，我們要的是一個分頁管理內(nèi)存的allocator啊，這種方式顯然是不合理的

那么，如果我們寫好聲明，讓它來實現(xiàn)呢？

你猜怎么著，能用：

那我們就先加功能：

看似沒有問題，但是還是有點問題的：

那么，這里我們肯定不能讓bst釋放內(nèi)存的時候直接把內(nèi)存管理器的內(nèi)存全釋放了，畢竟我們不只是為這一個類型準備的

刪除節(jié)點應(yīng)該是試用中序遍歷比較方便吧

這樣就不會和allocator沖突了，然而到這里已經(jīng)花了兩個小時時間了，自己寫雖然不一定更好，但我想應(yīng)該還是能快點兒

那么我繼續(xù)讓它優(yōu)化代碼

那么，問題來了，寫這個bst和ecs有沒有關(guān)系呢？其實未必，畢竟可以使用的數(shù)據(jù)結(jié)構(gòu)很多，倒也不必非得使用樹，但樹比較容易暴露管理內(nèi)存的問題，等等，它這樹好像不平衡

讓它平衡一下

然后我們需要來創(chuàng)建一個hashmap，由于要求比較復(fù)雜，考慮到個人英文水平，這里還是用中文吧：

到一半就沒了

那么我們試試分布實現(xiàn)要求吧

看起來貌似沒有問題

然后問問它有沒有優(yōu)化方案：

那么，老規(guī)矩，讓它寫點例子試用一下：

居然沒有錯誤，可以的啊

然后我們來加點要求：

這里直接問它有沒有更好的辦法：

這里我給這個類型加了一個函數(shù)指針，然后讓它更新代碼：

然后，我們需要它提供一種默認的hash實現(xiàn)：

接下來就需要它編寫一些常用的hash函數(shù)了

要么是類型強轉(zhuǎn)，要么是xorshift（對于數(shù)據(jù)結(jié)構(gòu)學到不好的小朋友可能不明所以，只需要知道該方法不好即可），同時這里它假定了uint32_t是32位，而double是64位（其實有的平臺不是這樣的）

那么，基于我們以上的問題，我們來要求它修改：

修改了這么多，得再試試看能不能用（老實說，由于不是我自己寫的，我現(xiàn)在有點太長了不看的想法）：

老實說，到現(xiàn)在已經(jīng)感覺比我自己寫代碼更累了（一直在看別人寫的代碼有沒有毛病，還只提供修改意見，代碼審核了屬于是）

但是，有一點需要注意的是，我們現(xiàn)在才剛剛擁有兩個基本的數(shù)據(jù)結(jié)構(gòu)而已（還不一定對）

廢話不多說，我們繼續(xù)

這是啥啊你這是

繼續(xù)

老規(guī)矩，試試看：

然后bug就來了：

由于專欄圖片數(shù)量限制，我把改專欄拆分成了兩份，并非有意而為之