sysprog
2019
2019spring
contributed by <czvkcui
>
做實驗:
矩陣乘法
程式碼:
result:
根據[4],在使用-ansi
或是-std
C標準規格中gnu的自己定義的keyword可能會引發問題(inline,asm,typeof),所以加上底線來避免不同標準的相容問題。__extension__
會告知編譯器使用的功能是gcc的擴充,而不會發出警告。在編譯時可以透過-pedantic
來告知gcc檢查非標準也非gnu擴充的警告。
man page 中有
用於計算member在struct中與起始位址的差異。
offsetof也可以使用下列macro實做:
(type*)會得到該type的pointer型態,((type*)0)會將該type的起始位置得到0,((type*)0)->member則會得到member的address,但這是在type 起始地址為 0 的情況下的地址,也就是這個 member 的 offset。
gne允許自己定義extension,在({...})
的範圍內可以使用statment來撰寫expression。最後一行的expression需要使用;
結尾來作為回傳值。
example:
more gnu extension:gnu extension cheetsheet
result:
const __typeof__(((type*)0)->member)* __pmember = (ptr)
:定義一個指向ptr
的__pmember
指標,該指標的型態是type結構的member的型態,對照offsetof,typeof(((type*)0)->member)便能到該member的型態,(type*)((char*)__pmember - offsetof(type, member));
該member在object中的address和該member在struct中的offset相減,便能夠得到該object的address,我們舊能夠對整個object進行操作。
list.h
還定義一系列操作,為什麼呢?這些有什麼益處?LIST_POISONING
這樣的設計有何意義?因為list刪除節點後,不會釋放list node,因此當重新使用這塊list node時可能會操作到不合法的區域。
list_for_each_safe
和 list_for_each
的差異在哪?"safe" 在執行時期的影響為何?list_for_each_safe
相較於list_for_each
,多了一個safe的pointer,這個pointer的指標會指向目前list node的下個list node,這麼做的好處是若我們在expression刪除list node,list仍然可以完成迭代。java和python中的list或是hash map,在使用for each語法時也會禁止使用者刪除list 或是hash map中的element。
提示:對照其他程式語言,如 Perl 和 Python
@
符號,這有何意義?你能否應用在後續的程式開發呢?提示: 對照看 Doxygen
Doxygen可以從程式碼的註解中直接生成說明文件,這樣修改程式碼時只要修改註解就能夠生成修改後的文件,保持程式碼和說明文件的一致。
doxygen 在使用之前必須加入設定檔
doxygen 會根據config-file 的內容選擇輸出的格式和目的地
支援的格式有HTML, RTF, , XML, Unix-Man page, DocBook
預設輸出是在doxygen 的config-file的位置
make doc便可以在doc目錄下得到文件
commit
tests/
目錄底下的 unit test 的作用為何?就軟體工程來說的精神為何?unit test[7]:
tests/
目錄的 unit test 可如何持續精進和改善呢?新增list_sort.h
到linux-list
用於排序:commit
list.h中有以下function:
int sort透過 enum傳入時list_sort_table就會執行指定的排序方法
加入list的支援:commit
修改Makefile引入list repository
讓qtest支援效能測試:commit
Makefile
加入繪圖命令
flurt
(flush out result)將結果輸出到指定的txt file
benchmark.txt結果:
還是需要透過手動修改成指定格式:
繪圖plot.gp
:
排序方法 | 最佳 | 平均 | 最差 |
---|---|---|---|
insert sort[8] | |||
quick sort[9] | |||
merge sort[10] |
比較三者在list的排序時間(random input):
比較quick sort和merge sort
from 2019社群
在 Linux 核心中,建議採用 heap sort 或 merge sort,有個重要的考量是,許多要排序的原始序列,已是幾乎排序好的 (例如個別 process 佔用 CPU 的比例,原本已排序好,只是新增新的 process 後,又需要重排序),或是期望順序剛好相反,這對於 quick sort 都是很大的衝擊。
參考from bauuuu1021
筆記:
insert sort
即使在best case下(以排序陣列,sequential input),仍然較quick sort
和merge sort
花費更多的時間quick sort
時間會大幅增加merge sort
影響較小