鍊錶與指標 專治「疑難雜症」

2021-09-11 20:30:58 字數 2255 閱讀 8164

本文大概解決三個問題,實話說,鍊錶這些問題真是重新整理了以前我對鍊錶的「偏見」。

題目:輸入乙個單鏈表,輸出此煉表中的倒數第 k 個節點。(去除頭結點,節點計數從 1 開始)。

兩次遍曆法

/*計算鍊錶長度*/

int listlength(listnode* phead)

while(pcur)

return count;

}/*查詢第k個節點的值*/

listnode* searchnodek(listnode* phead, int k)

//迴圈len-k+1次

for(i=0; i < len-k+1; i++)

return pcur;//返回倒數第k個節點

}

採用這種遍歷方式需要兩次遍歷鍊錶,時間複雜度為o(n^2)。

遞迴法

解題思想:

(1)定義num = k

(2)使用遞迴方式遍歷至鍊錶末尾。

(3)由末尾開始返回,每返回一次 num 減 1

(4)當 num 為 0 時,即可找到目標節點

int num;//定義num值

listnode* findkthtail(listnode* phead, int k)

}

使用遞迴的方式實現仍然需要兩次遍歷鍊錶,時間複雜度為o(n^2)。

所以,重點來了,所以我更傾向於:雙指標法

解題思想:

(1)定義兩個指標 p1 和 p2 分別指向煉表頭節點。

(2)p1 前進 k 個節點,則 p1 與 p2 相距 k 個節點。

(3)p1,p2 同時前進,每次前進 1 個節點。

(4)當 p1 指向到達鍊錶末尾,由於 p1 與 p2 相距 k 個節點,則 p2 指向目標節點。

**實現:

listnode* findkthtail(listnode *phead, int k)

while (p1)//如果p1沒有到達鍊錶結尾,則p1,p2繼續遍歷

return p2;//當p1到達末尾時,p2正好指向倒數第k個節點

}

使用雙指標法只需遍歷鍊錶一次,這種方法更為高效,時間複雜度為o(n)。

上面問題中,讓其中乙個指標先不動,待條件滿足後再讓其「出發」,那若是兩個指標都在運動,即沒有限制條件了,又該怎樣考慮呢?

單鏈表中的環是指鍊錶末尾的節點的 next 指標不為 null ,而是指向了鍊錶中的某個節點,導致鍊錶**現了環形結構。

這種題當然可以用「窮舉法」:遍歷鍊錶,記錄已訪問的節點;將當前節點與之前以及訪問過的節點比較,若有相同節點則有環。

否則,不存在環。

but,效率過於低下,尤其是當鍊錶節點數目較多,在進行比較時花費大量時間,時間複雜度大致在 o(n^2)。忘了它吧。。。

這樣的題當然也可以用「雜湊快取法」,其大致思想是建立乙個以節點 id 為鍵的 hashse t集合,用來儲存曾經遍歷過的節點,然後以後再遍歷新節點時,與集合數值相比較,若等,則有環,若不等,則放入,接著比較。

but,不好意思,這種方法我不會。。。

我們依然用「雙指標法」,只是,這次變了乙個名字,稱之為「快慢指標法」:

(1)定義兩個指標分別為 slow,fast,並且將指標均指向煉表頭節點。

(2)規定,slow 指標每次前進 1 個節點,fast 指標每次前進兩個節點。

(3)當 slow 與 fast 相等,且二者均不為空,則鍊錶存在環。

若煉表中存在環,則快慢指標必然能在環中相遇。這就好比在環形跑道中進行龜兔賽跑。由於兔子速度大於烏龜速度,則必然會出現兔子與烏龜再次相遇情況。因此,當出現快慢指標相等,且二者不為null時(即二者不在尾節點處相遇),則表明鍊錶存在環。

bool i***istloop(listnode* phead)    

//到達末尾仍然沒有相遇,則不存在環

return false ;

}

C 指標疑難雜症

const修飾指標 防止誤操作 const修飾指標,指標指向可以變,但是值不可以改變 int a 100,b 200 const int p a 指向可以變 p 100 值是不可以變const修飾變數,指標指向不可以改,指標的值可以改 int const p a 既修飾指標,又修飾常量 int a ...

IBM Watson德國建基地,專治疑難雜症!

解決了基地和隱私問題,接下來就看watson的成果了。據外媒報道,ibm人工智慧watson系統在德國馬爾堡大學醫學院疾病中心成立實驗基地,即將被投入應用,以協助醫生診斷複雜 罕見的醫學病例。目前,該系統正處於測試階段。迄今為止,watson已診斷了6個病例,但在準確率方面,還尚未得到進一步證實。據...

C語言指標疑難雜症

c語言指標疑難雜症 許多時候,使用c語言編寫的 是難於閱讀的,但很多人卻熱衷於此。從軟體工和的角度出發,應該盡可能地易於閱讀,無論是多年後的你還是接手專案的別人。但c語言本身的就要比其他語言要難於理解許多,且很多人為了一時的方便,寫出了一些只有自己才能理解的 本文不是 所有的比較難於理解的 我們的主...