[問題] 不傾向使用std::vector的原因

看板C_and_CPP (C/C++)作者 (Q馨)時間13年前 (2012/11/03 13:43), 編輯推噓3(3013)
留言16則, 6人參與, 最新討論串1/5 (看更多)
開發平台(Platform): (Ex: VC++, GCC, Linux, ...) Linux VC++ 額外使用到的函數庫(Library Used): (Ex: OpenGL, ...) C++ Standard Library(C++標準程式庫) C++ Standard Template Library (STL) 問題(Question): 這應該算是剛入行沒多久的菜鳥問題。 主要是工作到現在,常常看到一些class寧可自行管理動態陣列, 而不喜歡直接使用vector,其中的原因自己研究不太出來, 所以想問問是不是有一些業界的相關經驗,導致有什麼不適合使用vector的狀況發生。 1.首先我碰過前輩寫的(目前不在公司問不到)系統, 建立的類別以目的來說,本身沒有可能移植到無法使用STL的環境。 2.第二是排除掉class使用vector的時候, 好像要定義operator=還是複製用的建構子其一, 但就連一般的字串、整數、浮點數這些複製上沒問題變數,也是用動態陣列自行管理。 3.連window.h的一些綁平台的功能, 都使用到class裡面做一些主要的管理(WinProc之類的), 同樣是STL的std::map也用了不少次,唯獨就幾乎不用vector。 4.程式碼裡面,沒有什麼特別vector無法實現的特殊操作。 個人的觀察,大概的訊息就像上面那樣,不知道純粹只是個人習慣, 還是vector有些不太適用的地方,想了解一下,否則每次使用vector的時候都抖抖的orz 以上,請各位前輩指教。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 123.193.163.46 ※ 編輯: QHsin 來自: 123.193.163.46 (11/03 13:46)

11/03 14:25, , 1F
vector 很好啊
11/03 14:25, 1F

11/03 14:26, , 2F
除非你們在做 embedded system 不然其實找不太到理由不用
11/03 14:26, 2F

11/03 14:27, , 3F
應該是因為vector在配置空間上面有一些特性
11/03 14:27, 3F

11/03 14:27, , 4F
所以會不是很好用,例如會多配置一倍的空間,以及
11/03 14:27, 4F
^^^^^^^^^^^^^^^^ 這部分不太懂。 我知道會有一些額外的資訊來保有vector的操作功能,不過不知道有到一倍這麼多。

11/03 14:28, , 5F
配置空間後記憶體位置有可能改變,以致iterator不能用
11/03 14:28, 5F

11/03 14:30, , 6F
樓上這些可以用 reserve 解決...
11/03 14:30, 6F

11/03 15:39, , 7F
vector 的 capacity 可能會到 size 的兩倍的樣子
11/03 15:39, 7F

11/03 16:02, , 8F
這是因為 vector 需要連續的記憶體空間,當它發現不夠用
11/03 16:02, 8F

11/03 16:04, , 9F
就會去跟系統要求換一塊更大的連續空間。
11/03 16:04, 9F

11/03 16:07, , 10F
在一般使用的情況下,如果知道最多會用到多大的空間,
11/03 16:07, 10F

11/03 16:08, , 11F
可以在操作 vector 之前先用 reserve 保留一塊空間,
11/03 16:08, 11F

11/03 16:09, , 12F
以免操作的時候 vector 自動去進行 realloc 的動作。
11/03 16:09, 12F
感謝解說:) 看來用的時候要多留意一點 ※ 編輯: QHsin 來自: 220.133.45.115 (11/03 17:07)

11/04 00:26, , 13F
我覺得其實是vector比較好寫而map比較難寫 XD
11/04 00:26, 13F

11/04 00:27, , 14F
如果map也很好寫的話 就會看到很多人自己寫了
11/04 00:27, 14F

11/04 10:31, , 15F
推樓上 xDDDDD
11/04 10:31, 15F

11/04 15:08, , 16F
AntaresStar+1, 光 rb tree 就令人傷透腦筋
11/04 15:08, 16F
文章代碼(AID): #1GbAxo0q (C_and_CPP)
文章代碼(AID): #1GbAxo0q (C_and_CPP)