作者查詢 / dirkc
作者 dirkc 在 PTT 全部看板的留言(推文), 共395則
限定看板:全部
看板排序:
80F推: 14年聖誕Stroustrup給社群的禮物,之前版上分享過#1Ka_rQ5d02/28 16:05
81F→: 二階段手邊有沒有考古題? 看了題目才知道能給什麼建議02/28 16:16
82F→: 比如說考試以解題為主,花時間看完整本Primer就不如多練題02/28 16:18
7F推: 樓上說的沒錯。另外把記憶體都耗掉是否能有效抓出原來的02/15 00:32
8F→: 蟲或許更值得深入討論。02/15 00:32
9F→: 這樣的debug方式,在server上風險相當高02/15 00:39
11F推: 其實改了,只是之後用到符號x的時候極可能會直接置換成常數102/09 15:36
12F→: 改成int y=1;const int x=y;或volatile const int x=1;02/09 15:37
13F→: 就會看出一樓說的差別,因為會強制使用可讀寫位址存放x02/09 15:38
14F→: 編譯器也不會把符號x置換成常數102/09 15:38
15F→: @RJ 你把x丟入函式(例如printf)再看組語就知道02/09 15:42
16F→: 丟x和丟*p是不同結果,因為x可能會直接被置換成常數02/09 15:43
17F→: const這個字在執行期沒有意義,執行後只看memory protection02/09 15:55
18F→: 本質上不是效率考量,精確說是根本不考量02/09 15:56
25F推: 通常要確定就是用debugger去看編譯後結果,像樓上的反組譯02/10 09:53
26F→: 顯示x存在0x409050,p則是用堆疊esp+1c的位址;然後現在os基02/10 09:55
27F→: 本上除了堆疊和堆積幾乎都是唯讀,也可以用debugger查詢02/10 10:07
28F→: 怎麼配是編譯器的決定,不過字面常數或全域const容易配唯讀02/10 10:09
29F→: 應該說怎麼配是編譯器的初稿,os的定案;編譯器決定位置,os可02/10 10:16
30F→: 決定rwx讀寫執行權限,也可能修改區塊基底位址(ASLR)02/10 10:17
31F→: (這裡說的編譯器指的是同時有編譯,組譯,連結功能的程式)02/10 10:25
32F→: 有點想說通常寫程式不用去探究這些;今天就是因為某種程度02/10 10:40
33F→: 而言欺騙了編譯器(先告訴它const而後又要去改),既然越過了02/10 10:41
34F→: 編譯器,就需要更底層的資訊來解釋發生的現象02/10 10:42
19F推: 我比較好奇的是為什麼你的address不是4的倍數01/26 21:08
21F→: src是global address01/27 08:01
22F→: 除非"ABCDE"也放到global(怪?),或沒貼出來的code還有什麼01/27 08:05
23F→: 另一怪是dest是較小位址,方便問一下你的gcc版本和編譯參數?01/27 08:47
27F→: 回樓上,dest在stack中比&src要小所以執行strcpy才會蓋到src01/27 14:38
28F→: 從src=8040030看來後面0030是'0'和'\0',所以&src=bffa7e5c01/27 14:42
29F→: 老gcc常把先宣告的dest放在stack底層就是高位址01/27 14:43
30F→: 年輕gcc容易把char[?]放在stack底層,也是高位址01/27 14:44
31F→: 但是現在dest是低位址,所以我覺得有趣01/27 14:45
32F→: &"1234567890"應該是在.data,沒別的原因應該不會配奇數位址01/27 14:54
7F推: 不要開-fstack-protector-all:codepad.org/RjgAOLjB01/11 11:18
8F→: 註解有個地方筆誤,不是4 bytes,是sizeof(void*) bytes01/11 16:51
4F→: 從O(mn)到O(mn)外加小蟲12/03 18:16
32F推: 全域或static陣列都可,或者用ulimit -s改預設stack大小12/03 18:02
33F→: 如果有支援ulimit又有這個需求的話12/03 18:02
34F→: 題外話,不管是 **p 或 ********p,我會都叫它們指標12/03 18:03
35F→: 英文是pointer. A pointer to pointer is still a pointer.12/03 18:10
36F→: 初始化的全域或static變數通常放在檔案的.data區域中12/03 18:31
37F→: 函式內的區域變數則通常用stack來管理12/03 18:34
11F→: @caxz: 0x00003938 = 14648, 32位元long*等於4個byte, 所以12/02 20:13
12F→: *(long*)s=0x33323130, 0x30等於'0', 0x31等於'1',依此類推12/02 20:14
13F→: "0123"四個byte就變成0x30313233,little-endian就反過來12/02 20:15
14F→: 依此類推*((long*)s+2)指到最後"89\0",再多一個'\0'是湊巧12/02 20:17
15F→: 不過陣列宣告用堆疊記憶體,一般都會多配置空間,所以多'\0'12/02 20:17
16F→: 的湊巧幾乎總是會發生。12/02 20:18
18F→: 另外一種想法是CPU賦值到記憶體還是以4或8bytes來對齊,所以12/02 21:02
19F→: 底層會多個'\0'是必然的。總之,大概是這些原因。12/02 21:03
29F→: 有時候不大懂考偏冷寫法的考官動機是什麼12/03 18:07
30F→: 語法在那但是正常寫程式不會跟自己過不去12/03 18:08
24F→: inline+1,寫或不寫inline func.看那一段之後會不會常改或者12/01 14:15
25F→: 重複call,以上例也可直接化為算式放在第二層內12/01 14:15
26F→: array[i-1~i+1][j-1~j+1] 如果情況許可,我自己是會思考是12/01 14:16
27F→: 不是有類似dynamic programming或一些資料結構可以來加速12/01 14:16
28F→: 個人經驗,我想還是看設計師的喜好吧12/01 14:17
12F→: 一個小建議:先模仿看過的例子使用,覺得不需要的地方就不用12/01 01:26
13F→: 常用STL和<algorithm>,經驗和感覺就會慢慢建立了12/01 01:27
14F→: 按下return才發現樓上已經說過一樣的話了... orz12/01 01:30