推 LPH66: 這個錯誤最常見的原因是陣列存取越界, 特別是容器類的存取 08/16 21:53
→ LPH66: 檢查一下你的 vector 存取會不會在某個奇怪的時候越界 08/16 21:53
→ nh60211as: 你的while(no_sign[i] >= 48 && no_sign[i] <= 57) 08/16 23:12
→ nh60211as: 在全部的文字都是有效數字的時候會讀到no_sign[end+1] 08/16 23:13
→ Killercat: 一個小技巧,STL老問題了 08/16 23:32
→ Killercat: vector少用[]多用.at() 08/16 23:32
→ Killercat: []完全不會做任何檢查 所有的out-of-bound都是undefine 08/16 23:32
→ Killercat: d behavior 什麼奇怪的東西都會跑出來 08/16 23:33
→ Killercat: .at()則會相當盡責地做boundary check跟丟std::excepti 08/16 23:34
→ Killercat: on出來,所以別用[]了 08/16 23:34
→ Killercat: 看第三段Portable programs......那行 08/16 23:51
→ loveme00835: 為了 portability 更不應該用 at(), 因為在需要效能 08/17 00:09
→ loveme00835: 的時候會因為 at() 快不起來, 而且因為編譯器會產生 08/17 00:09
→ loveme00835: 例外處理的程式碼, 所以也要特別注意介面的設計是否 08/17 00:10
→ loveme00835: 合理, 如果需要檢查建議使用 BOOST_ASSERT() 這類可 08/17 00:13
→ loveme00835: 以切換行為的 contract programming lib, 靜態大小就 08/17 00:14
→ loveme00835: 用 bounded_integer, 到 C++23 時稍微改一下就好了 08/17 00:15
→ loveme00835: 學希佳佳第一件事就是把 cplusplus.com這網站 ban 掉 08/17 00:19
→ Killercat: 這個就看你喜歡哪種風格了,但是undefined behavior絕 08/17 10:09
→ Killercat: 對是最有害的,那麼有把握能做到完全檢查的話,你說的 08/17 10:10
→ Killercat: 應該就沒錯,但是實務上這幾乎是不可能的 08/17 10:10
→ Killercat: 另外我覺得把std::exception視為洪水猛獸...maa,也是 08/17 10:11
→ Killercat: 一種主流學說啦,只是我個人覺得不太贊同就是 08/17 10:11
→ Killercat: 另外其實portability跟效能無關 不然java早就吃屎啦... 08/17 10:11
→ Killercat: 另外BOOST_ASSERT()是個非常好的解決方案,這我贊同 08/17 10:12
→ Killercat: 反正就別搞到不想用std::exception結果跑去setjmp就好 08/17 10:13
→ hydebeast: 感謝各位!問題的確是出在n大講的部分 其他大大的建議 08/17 12:19
→ hydebeast: 我也會去研究一下的m(_ _)m 08/17 12:19