PTT數位生活區 / C_and_CPP (C/C++)

[問題] 請問命名的_t 以及幾個習慣問題

看板C_and_CPP (C/C++)作者 (.....)時間11年前 (2014/08/30 09:39), 11年前編輯推噓1(1推 0噓 31→)
留言32則, 6人參與, 最新討論串1/1
開發平台(Platform): (Ex: VC++, GCC, Linux, ...) MSVC2012 windows. (機器則是linux, ARM) 問題(Question)： 1. _t :在程式裡面,常常會看到 size_t uint32_t _t 的意思我查了一下,那個是制定規格的人使用的保留字 沒事不要亂用,這部分的觀念是對的吧 @@" 補充說明 Names that end with ‘_t’ are reserved for additional type names. 這是在gnu.org看到的一句話 某些地方把它解釋為這是保留的後綴命名,避免使用以免發生衝突 但是又在某些地方看到typedef或struct加上 _t 跟 _s 所以有點搞混了....@@ 2. 一組 .cpp .h 通常只會放一個class 今天一個檔案命名叫做 GuiABC 我頂多只會把GuiABC的衍生物放在裡面 3. 我在寫抽象物件 (Abstract classes) 會有一個習慣 一定會放在一個很好找的位置,通常會獨立出一個檔案,命名加上Abstract等等 絕對不會將抽象物件寫成class的內部class 例如: Class A { Class B{}; // B是抽象物件 給別人繼承用.... }; 請教一下 以上 1,2,3點的觀念上應該是正確的吧? 補充說明(Supplement)： 這是我目前新工作碰到的困難 一進去,就看到大量自訂的struct跟class都加了 _t 2跟3則是這家公司的coding style,跟主管反映後他完全不覺得這有問題 其他的小問題就類似.... 會在兩千多行的cpp中間塞一個 #if 0 ..... #else ..... #endif 這個問題是因為我遇到一個很詭異的bug 問了以後才知道有這麼一個#if ...||| 這邊是想確定我自己的觀念上應該是正確的吧 自己未必會再跟主管反映一次,但是得先確定自己的認知是正確的. -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.231.16.253 ※ 文章網址: http://www.ptt.cc/bbs/C_and_CPP/M.1409362753.A.2F1.html
→
08/30 09:44, , 1F
1幾乎是標準習慣了
08/30 09:44, 1F
→
08/30 09:44, , 2F
也不是保留字, 更不是"沒事不要亂用"...如果定義了
08/30 09:44, 2F
→
08/30 09:45, , 3F
type (struct/class/typedef/enum/union), 我還建議要
08/30 09:45, 3F
→
08/30 09:45, , 4F
適當多用 XD
08/30 09:45, 4F
→
08/30 09:46, , 5F
喔喔 所以這邊是說自訂義struct最好後面加上 _t吧
08/30 09:46, 5F
→
08/30 09:46, , 6F
所以這邊可能是我看錯討論串了@@~
08/30 09:46, 6F
※ 編輯: hidog (36.231.16.253), 08/30/2014 10:03:29
推
08/30 11:52, , 7F
#if 0 ... #endif 可以看成是個可以巢狀包含的 /* */
08/30 11:52, 7F
→
08/30 11:52, , 8F
如果中間有 #else 那就變成切換用
08/30 11:52, 8F
→
08/30 11:53, , 9F
0 選下半段, 改成 1 就選上半段
08/30 11:53, 9F
→
08/30 11:53, , 10F
有些編輯器(如 vim)看得懂這個結構會把適當的部份上註解色
08/30 11:53, 10F
→
08/30 11:54, , 11F
不過這基本上是過渡時期的程式寫法就是了...
08/30 11:54, 11F
→
08/30 11:55, , 12F
_t 的部份我會覺得它是拿來定義資料結構的
08/30 11:55, 12F
→
08/30 11:56, , 13F
基本上 typedef 裡會出場的比較多, 告訴使用者這名字是個
08/30 11:56, 13F
→
08/30 11:57, , 14F
型態, 這樣一來不容易撞名二來意義也清楚
08/30 11:57, 14F
→
08/30 12:16, , 15F
我知道切換用 主要是塞的太隱密了 沒看到XD
08/30 12:16, 15F
→
08/30 12:17, , 16F
類似在程式中間塞個#define _debug的感覺 就變bug了
08/30 12:17, 16F
→
08/30 12:18, , 17F
因為完全沒注意到某塊程式是沒在用的 參考錯範例 直接gg
08/30 12:18, 17F
→
08/30 12:21, , 18F
這邊有點難解釋 就大量#define放在程式中間 而不是.h或程
08/30 12:21, 18F
→
08/30 12:21, , 19F
式最上方 最後沒注意到 就爆炸了
08/30 12:21, 19F
→
08/30 12:22, , 20F
但是用法又不是讓整個class不編譯 IDE沒變黑 所以頭痛
08/30 12:22, 20F
→
08/30 12:23, , 21F
也還在想怎麼處理比較好 囧 需要建議
08/30 12:23, 21F
→
08/30 14:36, , 22F
想辦法讓IDE打開這種情況的syntax最實際
08/30 14:36, 22F
→
08/30 14:37, , 23F
畢竟沒辦法永遠避免面對legacy code
08/30 14:37, 23F
→
08/30 14:54, , 24F
ok thx~
08/30 14:54, 24F
→
08/30 22:05, , 25F
跟命名慣例一樣, 習慣加的就會加, 也沒有說 "很普遍"
08/30 22:05, 25F
→
08/31 01:02, , 26F
有這問題的話 gcc -E 看一下實際輸出是什麼
08/31 01:02, 26F
→
08/31 01:02, , 27F
通常來講大多數這種莫名其妙的macro issue都可以發現
08/31 01:02, 27F
→
08/31 01:03, , 28F
當然 少用macro 然後把新code濫用macro地拖出來打一頓
08/31 01:03, 28F
→
08/31 01:03, , 29F
是最治標而且治本的方式（以上誤 別真的開扁啊 XD
08/31 01:03, 29F
→
08/31 01:24, , 30F
感謝樓上 XD gcc -E倒是沒用過
08/31 01:24, 30F
→
08/31 07:36, , 31F
-E是展開所有header跟macro 所以macro issue可以
08/31 07:36, 31F
→
08/31 07:36, , 32F
很輕易的發現。當然前面header會很龐大就是...
08/31 07:36, 32F
‣ 更多 hidog 的文章
文章代碼(AID): #1K0Ij1Bn (C_and_CPP)
C_and_CPP 近期熱門文章
更多 近期熱門文章 >>
PTT數位生活區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 hidog 的文章
文章代碼(AID): #1K0Ij1Bn (C_and_CPP)