作者查詢 / ddavid
作者 ddavid 在 PTT [ C_and_CPP ] 看板的留言(推文), 共262則
限定看板:C_and_CPP
看板排序:
全部TypeMoon9274H-GAME4282GO3826GameDesign2611FATE_GO2571FBG1867AC_In1774nobunyaga1708JinYong1667LoL1533Wrestle1251StarCraft879Poker797Python752CGI-Game645Detective621C_Chat531Steam402Old-Games342Magic338DMM_GAMES336OverWatch317Little-Games303C_and_CPP262historia256Inference253DataScience222WorldCup222RealPlaying219Programming194TRPG182ToS118Olympics_ISG114Expansion07109PathofExile85Prob_Solve81Salary53eSports47marvel41BattleRoyale35PUBG33C_Sharp30BlizzHeroes26NDS26SLG26NTUCCG25Palmar_Drama23politics23LeafKey18basketballTW17KanColle16Web_Design15ck51st31614Gossiping14PhD14NTU-Fantasy11mud10AndroidDev6Baseball6CS_IGO6KS92-3196AHQ4Ahqwestdoor4MATLAB4Toy4b885060xx3cat3CVS3HotBloodYuan3joke3LGS3NTUEE108HW3NTUVGC3SuperIdol3XiangSheng32nd_NTUCCC2AC_Music2b90902xxx2ck55th3332CLHS-50-142DummyHistory2FJU-ACC90a2FJU-AM-902GAMEMUSIC2japanavgirls2JD_Lover2KS93-3042NCCU08_SW2NTUST-DT92-12OrangeRoad2SC-91-3012SCU_Talk2tabletennis2talk2Viator94Ding2About_Clubs1AngelPray1b89902xxx1b92902xxx1C_GameBoard1CCU_COMM_ANT1cksh83rd3031CMWang1CSMU-MED901Dynasty1G-REX1HatePolitics1Hunter1KS94-3101Mabinogi1MobileComm1NDHU-His961PuzzleDragon1sex1SOFTSTAR1specialman1Sportcenter1SYSOP1WomenTalk1<< 收起看板(119)
48F推: number 為 0 就已經被 if(number > 0) 擋掉了,不會出事啊03/18 12:39
49F→: 至於 number 過大,原Po已經說「考官有提到number 跟03/18 12:39
50F→: array A[] 的size是一樣的」,你要搞出一個 stack 宣告得03/18 12:43
51F→: 出來但是 unsigned int 存不下的陣列大小?03/18 12:43
52F推: 因為是 int 陣列,似乎需要 > 16GB 的 stack 大小呢XD03/18 12:50
53F→: 在這之前,這個陣列要怎麼宣告出來XD03/18 12:51
8F推: Gosper's Hack 跟這題差一步是擺到 mask 中為 1 的位數上01/25 10:01
9F→: ,可以拿來取代我那篇的 generateCombinations,但還是需01/25 10:03
10F→: 要最後填位置的步驟01/25 10:03
11F推: 因為 Gosper's Hack 速度快的前提是每個 bit 都可以用,01/25 10:08
12F→: 才能用他那套位元運算加速01/25 10:09
21F推: @peter98 說是這樣說,但刷 LeetCode 的人有高比例都不只05/20 09:51
22F→: 是為了測試演算法,多學一點語言特性都不會是壞事XD05/20 09:51
23F→: 而且這年頭演算法別說語言特性了,連硬體特性都要考慮,已05/20 09:52
24F→: 經不太純了XD05/20 09:55
7F→: system("echo \"4 5 7 2\" > file2.txt");09/28 17:34
8F推: 對exception的態度其實人人不同,沒有統一規則09/28 11:33
9F→: 相對比較中庸的說法是你想得到的錯誤就直接檢查,想不到的09/28 11:35
10F→: 就留給例外去抓,但即便如此還是很模糊09/28 11:35
11F→: 比如硬碟壞軌,這是一種可以預想到的錯誤,但你不可能為了09/28 11:36
12F→: 想得到這個發生機率相對低的狀況,就在所有讀寫前面都加上09/28 11:36
13F→: 壞軌檢測過了才讀寫09/28 11:36
14F→: 另外就是有些語言根本已經把exception內化成一種流程控制09/28 11:37
15F→: 手段而非單單的錯誤處理,所以某些地方用起來只是另一種if09/28 11:38
16F→: ,而且「可能」寫起來比較簡單,這又是另一種狀況了09/28 11:39
20F推: 我是比較不會用能否回復來做為區分,自己的基本概念是預防09/28 14:20
21F→: 與治療,你事先寫好的判斷就是預防它發生或者發生了也不會09/28 14:20
22F→: 造成問題,所以反而不會有恢復行為。比如事前判斷除以零會09/28 14:22
23F→: 出錯,所以提早發現0,直接不除,所以預防了事情直接發生09/28 14:23
24F→: 治療則是事情讓它發生了,事前沒有預料、或者就算預料到也09/28 14:24
25F→: 無法不讓它發生,所以只好讓它發生後做一些治療方案,看要09/28 14:25
26F→: 盡可能繼續跑或至少留些log再死09/28 14:25
27F→: 所以我的區分標準比較像是「你能否阻止它發生」09/28 14:26
28F→: 但是因為某些便利性或者語言特性(如Python),我其實也沒09/28 14:27
29F→: 這麼遵守這概念就是,還是很彈性去處理這問題XD09/28 14:28
31F推: Python也是啊,連基本的for loop行為就是一直call09/28 17:01
32F→: next()直到iterator丟出StopIteration exception而中斷09/28 17:02
33F→: Python也有不少基本跟常用package根本上就完全使用例外來09/28 17:04
34F→: 回應所有正常完成以外的狀態,完全讓你被迫使用09/28 17:06
35F→: 我抱持上面講到的概念剛從C/C++轉而接觸到Python想說「靠09/28 17:06
36F→: ,怎麼滿地都是exception強迫使用啊?」結果現在也是用爽09/28 17:07
37F→: 爽了XD09/28 17:07
5F→: 完全是定義啊,你完全可以定義出補數不等於變號值的系統05/12 12:20
6F→: ,只是可能不好用而已XD05/12 12:20
1F推: 你講的是++p03/15 20:50
6F→: 寫過六年以上的MFC沒有感覺自己未老先衰嗎(誤)02/07 03:28
5F推: 樓上是想講一般論還是單指這題?01/15 15:23
17F推: 這完全要看他整體是怎麼設計的12/16 17:48
18F→: 有的時候只是用-1表達某個意思,但有時可能是某種tricky用12/16 17:50
19F→: 法(比如呼叫者會拿來+1再往回丟之類的),這沒法只看這邊12/16 17:50
20F→: 得到結論12/16 17:50
21F→: 不過要我猜的話,我會猜這邊的-1只是拿來當error code,但12/16 17:51
22F→: 還是要強調這只是猜測12/16 17:51
26F推: 樓上這樣說很合理也很常見XD12/17 16:01
27F推: 願意使用exception的在這種情況可能就會選擇使用來做區別12/17 16:42