為什麼很多公司做c++不用智能指針,也不自己封裝一個好用的？

01-05

我新入職的一家公司，以前別人寫的代碼，我們是基於這套代碼基礎之上修改。但是發現代碼當中到處亂new 跟delete各種違反 effective c++的款項。還有windows 下使用createthread創建線程。整個代碼沒有文檔。我新來的為了讀懂代碼我自己整理文檔。領導感覺我整理文檔他好像很不爽。他自己不整理文檔...我現在覺得這公司實在太差了。明年準備換工作。

QQ的Hummer架構是我到目前為止接觸的國內自研的最好框架了，基於COM。一個思想，盡量讓開發者與windows本身的編程介面隔離，你就在這個框架里折騰，只要按框架來，出的問題框架都能收拾的了。

這是一個積累的問題，一個公司如果沒有沉澱和積累技術的意識，天天就是三方庫，那也顯得太不思進取了。

另一方面是技術管理者的責任欠缺，比如技術總監或者CTO根本不操心公司的整體技術水平和主流技術方案，下面的人很少會有像題主這樣考慮這些問題的。像題主說的問題，從小來看，是開發者的問題，但是你不能要求所有的開發者都能意識到這種需要經驗積累才能感受到的問題，那怎麼辦？需要技術管理者去從整體開發環境來想辦法，力度輕一點就是通過定製開發規範來約束開發人員，高級一點就是開發一套可以規避那些問題的框架，然後所有的開發都基於這個框架吧。

說白了很多公司用C++，但是有多少公司在真正用心的用C++呢？

前面說的都可以理解... 畢竟有歷史原因,可是你寫文檔他不爽啥,我巴不得有人給寫文檔呢....

你想找一個

1. 用智能指針

2. 用std::thread

3. 有文檔

的公司，換句話說，大量採納C++11，並且文檔清晰的公司？別開這個玩笑了，現實一點。

WinXp里不是有個彈球的賭博遊戲嗎？後來怎麼沒有了呢？因為那個程序員離職了，沒人能看懂它的代碼，所以無法移植到新的win版本裡面。

因為指針這個設施太基礎了,要改進必須由語言來,靠庫來打補丁是行不通的.

換句話說, 不用才是最好的選擇.

只能說C++值得信賴的庫實在太少了，很多的項目都要用c的庫，所以智能指針的使用範圍還是很局限的。

當年做這系統的時候或許還沒c++11呢。

這是程序員的通病，看別人代碼都是如此。而且，越是新人，病的越重。我只想說，程序是用來跑的，不是用來欣賞的。盡信書不如無書。

1. 領導水平可能有問題

2. 智能指針寫起來長一點，很多人不喜歡

3. 智能指針也有不好用的地方，比如智能指針和裸指針不好混用，而有些(可能是在你們的項目里你沒有留意到的某個)地方(比如dll介面，cli等)不得不用裸指針

4. 沒有用最新技術，沒有文檔，都是各種原因權衡導致的，以上三點，學習成本，deadline，收益等等等等最後的權衡結果，存在的結婚肯定有它的道理

5. 題主要改變現狀，需自己重新權衡一下，例如是否把寫代碼的時間花在寫文檔會獲得更好的收益，收益是長期的還是短期的，如果收益是長期而項目本來就是短期或者也沒那麼重要怎麼辦。諸如此類問題都算更好，再決定要不要改變現狀。

6. 改變現狀很有可能得罪人，應當挑選什麼樣的方法避免。不能一邊賣力，一邊遭人恨。

7. 解決具體問題容易而權衡不易。維持現狀容易而改變不易。埋怨領導容易而做好員工不易。辭職走人容易而在現在的公司做好不易。

題主太天真。

我新入職的一家公司，以前別人寫的代碼，我們是基於這套代碼基礎之上修改。但是發現代碼當中到處亂new 跟delete各種違反 effective c++的款項。

這非常正常啊。題主你在這方面很在意很懂行，而別人不是，這種情況在大千世界裡到處都是，題主你是第一次參加工作嗎？很可愛啊。

還有windows 下使用createthread創建線程。

不行嗎？別人去百度複製了代碼，並且發現可以解決問題，那就行了。你看不慣？

整個代碼沒有文檔。我新來的為了讀懂代碼我自己整理文檔。領導感覺我整理文檔他好像很不爽。他自己不整理文檔...

題主你的任務列表都完成了？沒完成你整個JB文檔？完成了不知道向領導彙報，然後給你分派新任務嗎？不去完成任務，在這裡整什麼JB文檔，公司請你來搞文秘工作？領導看你拿著公司的錢卻把時間浪費在這些沒讓你乾的事情上，肯定不爽。

我現在覺得這公司實在太差了。明年準備換工作。

工作的招聘與求職是雙向的，你覺得公司太差你可以換啊，公司還覺得你太年輕太傻太天真正想辦法把你辭掉呢。

正確的做法應該是：只要錢到位，就算跪舔菊花都可以干！

我不知道題主所謂的整文檔具體是在做什麼工作...

如果是放著工作不做,在做資料整理,那我找你幹嘛...

如果是下班了,業餘時間整理文檔,那站在我的角度,我巴不得呢...

但是,如果你所謂的整文檔包含了整理代碼,.修改代碼的範疇的話,那我掐死你的心都有了...你能活到現在真的是那位領導開恩了...

這年頭，瞎雞吧寫程序的傻逼太多。。。

已經不奢求公司的代碼有文檔了，每100句有一句注釋就行。

正常，光正確使用new和delete就有一半的人做不到，而且這樣的人集中在應聘門檻較低的小公司。有的公司亂寫已經成了風氣，特別是小公司，人員流動更大，寫代碼的更不負責。

比如我待過的一個小公司，代碼慘不忍睹，bug層出不窮，而且那些人改bug時寧願在上層重新做適配也不在底層把問題解決了。更坑爹的是如果你在底層把bug改了，肯定會有一些介面不兼容的情況，主管就會責怪改bug的，久而久之就沒人管底層的bug了。最後的結果就是，項目的底層爛到根，又有很多中間層拐來拐去，有些問題永遠無法解決。後來在我的強烈譴責下公司推動重構，因為我們只是一部分研發，有些部分是在外地的分公司寫的，而主管讓他們各自負責重構，沒有統一的管理，結果有的人重構就是加個新類，裡面仍然調用原來的介面，還加入了事件這種東西，關鍵是事件定義還放在不同的庫里，各自定義的事件宏的值還有重合的，還沒人敢改，改了出問題要罰款的，簡直無力吐槽。後來我也完全不管了，搞了個自動打包腳本每天打個包給測試，出了問題笑看他們推責斯比，看他們每天走過門口的bug通報批評表，一種同情感油然而生。現在我早已不在那個公司了，偶爾和原同事聊天，他們還在通宵修改著bug，與自己做著沒有結果的鬥爭。

這裡吐槽一下。總結來說，寫安全的C++代碼難嗎，其實不難，別用那些高級特性，那些在多人合作時反而容易出問題，只用最簡單最基本的，寫程序其實不就是分配內存和調用函數嗎，完全夠做項目了。但是有的公司一種不負責的風氣已經進入到了公司文化里了，這種公司的共同點是：

1.寧願花3000招4個新手也不願意花1萬2招1個有用的。10個新手1個有經驗的，結果就是那1個有經驗的專門用來應付新手造出的bug了。

2.加班鼓勵政策。只要有這種政策，員工就會在白天消極怠工，把工作都放在加班做，最後還能得獎勵。

3.管理只看結果，無視自身的責任。導致出了問題員工互相推諉，勇於擔責的反而受到處罰。

解決方法：快點走人吧。

樓主不知道歷史這個詞嗎

不寫文檔，注釋，簡直不是人，我接手一個.net form項目，茫茫多重複代碼里，一行注釋都沒有，函數，方法命名的就像活在夢裡，這他喵的，我都得猜他寫的什麼意思。

送給你領導。

允許使用這些特性對從業人員水平的要求並沒有降低，而是提高了。

C++11 的 std::shared_ptr 也有坑的，比如把 this 傳進去就呵呵了（除非用 std::enable_shared_from_this）。