1樓：匿名使用者
資料結bai構和演算法極為重要，說是du最重要的
zhi也不為過，學生時dao我即已認識到回它的重要性答
。但要熟練應用，不能只有理論，得靠你勤於實踐。具體要多長時間，得視你的勤奮程度而定,不過這些東西就是練了再長時間，也沒人敢說自己就精通了。
學生時就是練得少，缺少實際經驗，希望你勤於練習
資料結構和演算法在實際的軟體開發中都有哪些
2樓：
應用太多了。
基本上來說c#是基於面嚮物件語言，你所定義的所有類/結構體都算是資料結構，而且在.net類庫中已經定義中諸多可用的型別以供使用。實際開發中根本就離不開結構與演算法。
題主之所以有這樣的問題，基本上認識到了很多程式設計師易犯的一個毛病——理論知識與實際應用中的脫節問題，不少程式設計師都說自己寫程式用不上理論知識，或者是理論無用。我一直認為理論才是真正程式設計的指導，別說你所學的理論知識了，有時我們必須遵守一些軟體活動上的標準/規範/規定。比如iso29500標準有多少程式設計師讀過或聽說過？
他實事就是關於openxml的一個國際標準，我們要想達到通用的程式，這些標準還是讀一讀的好。
扯回你的問題，什麼是資料結構，什麼是演算法？如果你真的狹義理由資料結構，或者只是從課本上例子來說，資料結構被定義成一個只有屬性成員的類或結構體才算是資料結構嗎？事實上並不是，那麼是不是隻有連結串列/棧/佇列才算是資料結構呢？
可以說這是某些人狹義理解資料結構時的一種常規定勢思維，但事實上來說，類或結構是資料結構的基本，否則你連結串列存在的實體到底是什麼東西？所以資料結構包含著基本結構與狹義上的順序表/連結串列/棧/隊等存在實體的集體。為什麼我說資料結構在實際運用中廣泛體現呢？
就資料結構而言，課本上只是為了講明白結構而已，弱化了其中實體的真正含義，而且不語言的具體實現亦不盡相同，所以他們所講的資料結構是基本理論的。
我來個例子：連結串列（c#語言）
public class member
public string responsibility
public string posotion
}public class membernode
public member next
}// node其他就是連結串列中的一個結點結構，這個結點結構除了指明當前的member之下還指向下next的下一個結構結構，它最終可以形成一個連結串列。這就是定義的一個連結串列。
從以上例子上你可以看出這是一個類似於課本的標準定義，但事實上在c#語法中存在泛型的特點，那麼這類似的結構我們不須要一個個地定義了！所以在不同的語言中為了方便程式設計者，我們甚至可以把這樣的結構進行簡單化，從而達到一種最簡單的使用方式。以c#為例，我們可以使用node來表示連結串列/list表示順序表/stack表示棧/queue表示佇列，在這種情況下，我們只需要定義我們的泛型即可，結構鏈之類的本身使用泛型已經在類庫中實現了——雖然你不用定義，但不代表不使用或者不用理解這其中的知識。
而在課本講理論的時候，他不可能附帶泛型來講的，所以很多人認為自己去定義資料結構才行，那才是「真正」的資料結構，其實不然。以連結串列為例，我們需要一個節點除了其實體意義之外，還存在指向下一結點的指標（其實是地址引用）才算是資料結構。根據課本，他們必須這麼定義（c#）：
public class membernode
public string responsibility
public string position
public membernode next
}// 死讀書的只會承認這種才是真正的資料結構吧（連結串列節點）
事實上，連結串列講的只是一種形式，能最終形成的一種組織資料結構的形式。這個**會導致我們出現一種極大的誤解——每個型別的結構都需要重新定義一次。如果有多個型別結構的話，我們會出現多個不同的定義，這會導致將來類的定義越來越多，對於維護上來說是比較麻煩的。
由於設計模式/面向切片等各種開發方式的介入，我們會使用相對比較簡單的形式。所以才會有我定義兩個類的進步，而後可以出現泛型的更進一步。
你可以這樣理解，這種課本上的結構，會導致我們造成每種結構基本上都需要重新定義一次，我最開始給出的例子可以使用繼承的方式，實現某個基類的資料結構（下面的似乎也行，但在使用中可能會出現部分問題），而node則從根本上解決了這個問題，可以支撐多種型別。
所以此時在理解資料結構時，比如node，他不旦要求理解連結串列的節點，還要理解t泛型，那麼在資料結構上來說，它指的不再是單一的節點結構，還在包括一個基礎的型別。
換句話來說，你在c#等語言中已經不需要再做類似的定義了，只需要定義其基本結構型別即可。但課本上在講知識的時候，它不可能只針對物件導向或支援泛型的語言來講，若不支援泛型時，我們必須使用課本上或我最開始寫的例子中的形式，若不支援繼承的程序導向語言，那麼課本上的知識就是硬性的規定，你必須以這種形式來說，而引用則使用指標引用的方式（物件導向的引用其實是一種引用型引用，也就是址引用或稱地址引用，與指標類似）。
相信講到這裡你能明白，資料結構在不同的語言中只是變了個形而已，並不是必須是存在指標的才是，也不是隻說表面上的那點東西。早期教程都是以fortain語言為主的，而且課本的目的是講清道理，而不是一種規定。死讀書的人以為用不到資料結構，其實他們一直在使用。
再來說一下演算法，演算法是什麼？是解決問題的一種模式，比如解二元一次方程等等，所以演算法的定義其實已經告訴你，順序**他也算是一種演算法，不能說只有揹包問題，八皇后問題，回溯問題才算是演算法——你能明白嗎？其實你正常寫的就是一種演算法，這種演算法簡單，就是順序執行下來就可以了，他也是一種演算法的，就算解二元一次方程組有固定的模式（演算法），但不代表加減法就不是演算法了！
所以演算法也是常用的東西，那麼你學習的演算法其實算是開闢思路的一種而已。演算法自身的概念已經決定，基本上程式都是由結構與演算法構成。我也來舉個例子，怎麼判斷某個連結串列是否為迴圈連結串列？
是你的回溯演算法，貪心演算法還是揹包演算法？它們只是在解決一些典型問題的一種通用方式而已，很顯然，我的問題不是這種典型問題，但不代表他不典型，我們正常的演算法是設計兩個變數等於頭元素，然後開始進入迴圈，一個變數每次向下推一，即找到他下一個節點，而另一個變數每次找到其孫節點，就算當於兩個變數一個每次向下推進一次，而另一個每點推進兩次（如果可能），如果不是迴圈連結串列，則進兩次的那個會在連結串列總長度的一半時，遇到空引用，否則會在某一時間兩指標引用同一物件（不是物件相等，而是引用相同的物件），什麼意思呢，好象兩個人在圓型跑道上跑步，一個每秒1米，另一個每秒2米，同時同地同向出發，最歸跑得快的那個會追上跑得慢的那個！當然這種情況下你也可以給他起個名字，叫「追及演算法」？
如果只有你學的那幾個典型演算法是演算法的話，這個算不算演算法？
現在我們的問題是，如果語言層面上已經實現了這些東西，那麼這些理論我們是否可以不用理解就可以了？答案是可以——如果你只是一個不思進取的程式設計師或允許bug亂飛的沒有責任心的程式設計人員的話，可以不用理解——畢竟有些人只是「混」飯吃而已！
理解了不會去應用，這就是典型的理論聯絡不到實際，他們也不知道自己的**將如何控制。我舉一個例子，由於效能等各方面的要求，我們要使用多執行緒對某些資料進行處理。怎麼處理？
不好人會使用多執行緒——他們定義一個臨界資源，然後讓多個執行緒在讀取資料表(dataset)時進行阻塞，然後每個執行緒去處理那些超時長的問題，處理完的時個再按這種方式讀取資料——這樣有問題嗎？沒有，這也算是演算法的一種！反正如果程式設計**有功底的話沒有任何問題的，這種**算不算優雅呢——很多人認為**的優雅就是**編寫過程的形式或是良好的程式設計習慣！
這裡邊其實用不到資料結構與演算法的。
好吧，我承認，但如果我們換一句思路來看看，如果我用一個執行緒負責讀取資料，並不停地放入到一個佇列中，而多個執行緒從佇列中不停地讀取處理這些放入的資料，這樣如何？我的意思是說，並沒有直接在dataset中處理，而是選擇使用佇列的方式。
我們看一個問題，這個佇列queue，一個執行緒用來插入資料，多個執行緒用來讀取資料，而且要保證不能重複，那麼我們可以使用佇列的安全版本（correntqueue,在.net中如果非執行緒安全的情況下，多執行緒使用實應該找到其對應的安全版本或者控制執行緒安全)。
插入執行緒如果發現佇列中的長度（容量）較大時，可以暫緩插入。這樣可以保證佇列的長度基本固定，佔用記憶體得到控制（不是dataset批量讀來一大堆），由於使用安全佇列，所以各執行緒不用考慮執行緒之間的安全問題，每個執行緒從隊中獲得資料並刪除，可以保證資料只被處理一次。當然還可以考慮優雅的通知機制，插入執行緒在插入資料時通知處理執行緒啟動，如果插入速度過快，發現插入數量達指定的長度（比如30個），停止插入，插入執行緒阻塞；處理處理再次處理時可通知插入執行緒再進行插入。
這也算是一種演算法吧？它可以讓插入執行緒與處理執行緒同時工作，而使用dataset那種常規的結果時，只能是等待處理完或加入多個控制條件進行控制，既然這麼控制的話，何不直接使用佇列的方式？correntqueue中的t也完全可以是一條記錄datarow嘛！
如果你認為第一種是你經常使用方式，那麼演算法對於你來說學與不學無所謂的，你必須使用自己的程式設計/除錯功底以保證你的**儘量很少出錯或不出錯。而如果你認為第二種方案優雅一些的話，那麼你會認為你學習的演算法與結構還是有用的，理論與實踐結合了。
我之所以舉這麼一個例子，其實告訴你的無非是幾點非常重要的資訊：
你有選擇演算法的自由（只不過是**質量、後期維護的問題）
如果你知道的較多的演算法與結構，你會有更多的選擇。
演算法或結構在實際使用中，所謂的典型問題並不是使用場景和書上描述一模一樣（試想一下，我第二種考慮的例子中，是不是跟書上比他不典型？其實也是非常典型的）
分析問題時，應該拿要點，而不是整體去套。（如果整體去套用的話，你肯定會想不到使用哪種結構或演算法）
不管是資料結構/演算法/設計模式都要求是靈活運用，而不是場景對比使用，也不是生搬硬套。
試想一下，你的揹包問題，怎麼可能公司也讓你分拆包裝？你的八皇后問題公司恰好讓你下棋？你的貪心演算法公司恰好讓你找零錢？
你的回溯演算法公司恰好讓你走迷宮？學不能致用的原因就是太死板——這幾個舉個例子的場景你再遇到或理能遇到的機率是非常小的，所以如果覺得學了沒用，那就真沒用了——只不過不是演算法沒用，而是人沒人！
講個小故事：從前一個家人的板凳壞了，要找一個合適的兩股叉的樹杈重新制做一個板凳腿，讓孩子到樹園裡找了半天，孩子回來說「我都沒見過有向下叉的樹杈！他老爹氣得要死——怎麼會可能有向下長的樹杈呢！
這孩子是不是笨——你就不會把地刨了找一個向下分叉的樹根！
演算法也是一樣，迷宮找路可以使用回溯演算法，但不是所有的回溯演算法都用於迷宮找路——它還可以用來設計迷宮！嘿嘿嘿！
資料結構與演算法，哪種語言描述好，資料結構和演算法用什麼語言來學習入手比較好
關於資料結構與演算法的描述問題，現在是使用 c 語言進行描述的為多。因為 c 語言是目內 前比較流行的一種高階程式設計容語言。現在市場上就有售賣 資料結構 c語言版 的教材。該教材中的所有演算法 例如 各種排序演算法 以及查詢演算法 都是使用 c 語言進行描述的。根據我個人的體會就是 至於是學習哪一...
程式設計演算法資料結構如何理解
演算法 資料結構 程式 是一個著名的公式。程式執行的過程就是資料流的處理過程，怎麼處理，那就是演算法問題，資料怎麼組織，那就是資料結構了。程式設計是給出解決特定問題程式的過程，是軟體構造活動中的重要組成部分。程式設計往往以某種程式設計語言為工具，給出這種語言下的程式。程式執行的過程就是資料流的處理過...
學資料結構和演算法之前要先學什麼,學習資料結構需要先學習什麼科目？求指導
不需要其他的了，因為資料結構跟c一樣也是一麼基礎課，學了他是為後期學其他課程作準備的，如編譯原理！數學分析暫時還用不著但是可以鍛鍊思維能力！資料結構裡的內容跟離散數學關係很大，比如圖，等等！必須把離散學好！具備c語言或c 等基本的程式設計知識，其中指標的概念一定要清晰明瞭。最好能學習一些離散數學的知...