[回到版面]
回應模式
名 稱
內 文
附加圖檔[] []
  • 可附加圖檔類型:GIF, JPG, JPEG, PNG, WEBM,瀏覽器才能正常附加圖檔
  • 附加圖檔最大上傳資料量為 3072 KB。
  • 當檔案超過寬 125 像素、高 125 像素時會自動縮小尺寸顯示
  • 目前附加圖檔使用量大小: 175965 KB / 500000 KB
  • 回覆時程式碼縮排會被trim消掉,請善用[code][/code]標色或貼到ideone等網站
  • LaTeX記法可以用「$$」或「\( \)」包起來,例如「$\sum_{k=1}^{k=n} k^2 = \frac{n(n+1)(n+2)}{6}$」
  • 投稿時請點擊畫像認證後,再按下 [送出] 按鈕提交。
  • 鬧板、攻擊性發言、煽動性發言請無視(回應者也無視),並使用del或在貓管理部向管理員回報。
  • 新介面尚處於測試階段,如果有任何問題可以向管理員或於程設交流版反映。

檔名:1553142976955.jpg-(546 KB, 1167x1500)
546 KB
無題無名19/03/21(四)12:36:16 ID:frvlz13YNo.13102del
來問個比較基本的C++問題
很多函式庫有自己的整數型別
不會跟你講明是多少bit
例如標準庫的std::string::size_type就是
雖然十之八九用int32_t去處理是ok的
但就是怕萬一
怕不同平台有不同的規格
各位在型別轉換時有什麼好方法嗎?
有什麼慣用手法來檢查嗎?
無名19/03/21(四)15:29:48 ID:tOUw.qRgNo.13103del
>>13102
sizeof
無名19/03/21(四)15:57:43 ID:frvlz13YNo.13104del
>>13103
只用sizeof檢查的話
最後會逼得我一直用uintmax_t來處理
拿size最大的整數型態會導致計算變慢
況且沒人會去處理那麼長的字串(只是舉個例啦)

我目前是使用std::numeric_limits去判斷
衡量我給的變數裝不裝的下
即便std::string::size_type實際上是誇張的128bit
上面裝的數字99%的情況用uint32_t就可以儲存了
算完要丟回給std::string時又需要在撿查一次
因為也有可能std::string::size_type其實是int32_t
uint32_t裝的數字有那麼一點點機會可能會超出std::string的容量

變成輸出輸入都要檢查
會寫的很醜
所以才會上來問有沒有什麼慣用手法
無名19/03/21(四)19:32:49 ID:QghfrccUNo.13105del
你的輸入輸出有可能會出現這種極端狀況嗎?
很少的話等拋錯誤再處理也不遲

程式碼切得夠好就不會有很醜的問題
好好思考一下那些地方是可以抽離出來的
無名19/03/21(四)19:47:17 ID:frvlz13YNo.13106del
>>13105
這種極端狀況會自己拋錯誤?
依然要我自己檢查吧?

>>程式碼切得夠好就不會有很醜的問題
有在想這麼做
專寫一系列同名的函式去判斷數值能不能無損賦值
只是覺得島民也許會有比較有經驗的做法
所以才上來問的
無名19/03/21(四)21:24:29 ID:P/XWd7rANo.13107del
除非你寫的是出錯一次會虧幾千萬的重要大案
或是你的資料整天走在溢位邊緣
不然我是傾向當作沒看到硬轉,等真的爆了再說

或是假設它的實際型態為某種慣用的int
然後叫編譯器幫你注意你是不是猜錯了
編譯器噴error你再來看要怎麼轉換
無名19/03/21(四)22:46:07 ID:BfL7CHK6No.13108del
>>13107
如果要處理那種好幾G的大檔案很容易遇到吧?

>>等真的爆了再說
這種不定時炸彈處理起來最痛
都要玩好一陣子才會看到bug
安插幾個printf進去
編譯個幾次
玩個幾回
一天就過了==
無名19/03/21(四)23:33:49 ID:P/XWd7rANo.13110del
>>13108
>>好幾G的大檔案
那就是遊走溢位邊緣啊
只能認了乖乖檢查

編譯時或執行開頭統一檢查所有型態是否如同預期、
把外部函式庫都包一層,檢查完是否溢位再傳出去、
再不然整個函式庫用自己確定能用的型態重寫...


我自己的習慣是一律使用預設的signed int32
21億很夠日常使用了
程式內部的交流基本上不會出現那麼大的數字,完全不做檢查
少數幾個會超出或瀕臨上限的資料另外做特例處理,例如分割成多個小塊
來自外部的輸入則先給一個看起來合理的上限,例如數萬,有人越線了再專案列管
列管時也要考慮那個資料到底正不正常,有時你需要的是拒絕他而不是讓自己配合他

高階程式語言的大概念就是程式好寫好修比起字字句句雕琢到完美還重要
你認為不太可能會發生的事情就不要花太多心力處理,只做簡單的攔截、回報就好
等真的出包了再來認真修
不要還沒遇到實例就自己嚇自己,整天擔心轉型溢位把開發進度丟到一邊去

附帶一題我個人認為用unsigned處理太大的資料非常愚蠢
除非你在玩bit運算或剛好你的資料就是精確地落在那個範圍,或是配合函式庫
不然會遇到3G的使用環境遲早也會讓你遇到5G,多一個bit不會讓你多活多久
int32不夠就該直接上int64,不要讓遊走int32邊緣的資料繼續在uint32邊緣游走
無名19/03/22(五)19:33:04 ID:t5rKxn2kNo.13118del
>>13105
>>13110
其實我今天實作之後
看起來也還好

a=b;
變成
a=func<decltype(a)>(b);
出問題就throw個異常出來
C++11新增的語法真的太重要了


【刪除文章】[]
刪除用密碼: