推 wtchen: 不懂，不是已經有bit-field可以指定struct裡面的位元？ 07/30 15:06
→ wtchen: 真的需要自訂typedef struct不就好了？ 07/30 15:06
對阿，我知道有bit-field
只是覺得為什麼不要全部的variable都採用bit-field
除此之外，有時候只需要表達一些狀態（例如表達0-31），卻需要用char去存
或是有時候可能只需要21個bit，卻需要用long去存
不覺得這樣很浪費嗎？
（而且沒辦法一眼就看出，到底這個variable的range是多少）
→ wtchen: 而且這樣搞法如果不能用alignment不是效能更差？ 07/30 15:07
我沒想到alignment的問題...
但是如果原本做不到alignment，換成這種做法，反而有可能做得到不是嗎？
如果仍然做不到，那也會用padding來避免效能更差
所以從alignment方面來看，這麼做應該是不會效能更差吧？
推 CaptainH: 運算的時候還不是要做bit mask 07/30 15:11
恩...
所以這樣做的好處可能就不是在效能上，而是在語意的表達上
用這種方式，能更清楚說明，這個variable的值的範圍
→ ilikekotomi: 只是要清楚的話 在變數命名上加bit數這樣可以更清楚 07/30 15:49
可是變數命名不是我能決定的...
如果是用這種方法，那就是強制的了
→ MOONRAKER: 對不齊怎麼可能速度更快 噗 07/30 16:13
會改成這樣，表示新的做法的bit數一定<=現有做法的bit數
那表示說新做法的bit數，一定可以靠padding，來變回現有做法的bit數
那也就是說，現有做法能夠做到的事情（例如alignment），新的做法一定做得到
那這樣alignment所引起的效能問題就不存在了
我的理解是這樣啦
→ MOONRAKER: 原因就是不需要 C有那麼多user 對應那麼多硬體 07/30 16:13
→ MOONRAKER: 語言設計出來幾個常用寬度 不同實做可以各自決定 07/30 16:14
我其實有個問題是
如果未來的硬體實作都改變的話，那怎麼辦？
與其到時候才改標準，不如現在把標準弄得更彈性一點，不是比較好嗎？
反正對於那些主流的硬體，其實沒什麼不同
對於那些特殊的硬體，至少它現在可以說，能支援C語言
→ MOONRAKER: 這樣就很_實用_了 就算浪費空間也有限 而且方便互通 07/30 16:15
→ MOONRAKER: 你char寬度7 我寬度6 這種惡夢已經夠久了 不要再來了 07/30 16:16
→ james732: 問題應該是CPU處理的效率與空間的利用？ 07/30 16:19
→ james732: 畢竟CPU指令集對於數字通常都有固定的長度？ 07/30 16:20
推 james732: 呃我不覺得這個彈性有什麼好處耶…除了複雜化以外XD 07/30 17:18
大概就是 可以一眼就知道值的範圍
QQ 突然覺得這樣好沒用...
推 CoNsTaR: 與其讓使用者決定變數大小 還不如讓編譯器決定 07/30 17:23
→ CoNsTaR: 只要你這語言的語意可以表達得夠清楚(像fp語言) 07/30 17:23
→ CoNsTaR: 很多變數的值的上限都能在編譯期被求出來 07/30 17:23
→ CoNsTaR: 讓使用者不用擔心變數大小 真正的 bit 數編譯器會在編譯 07/30 17:23
→ CoNsTaR: 期幫你決定 你改程式也不用擔心變數大小 編譯器幫你算 07/30 17:23
→ CoNsTaR: 使用上整數就通通是 int 浮點數就全部用 double 之類的… 07/30 17:23
→ CoNsTaR: 至於無法求出上限的就照 C++ 原本標準來做 你覺得這樣如 07/30 17:23
→ CoNsTaR: 何 07/30 17:23
如果靠programmer能做得更好的，應該就讓programmer去做
舉例來說，假設我很確定使用者的輸入介於0~7
那我可以宣告
int:3 a;
來存放這個input
可是如果用現有做法，就是
char a;
那這樣programmer在讀我code的時候，前者所能表達的意思比後者更多（如果不用註解）
（當然也可以用struct包起來，但大概沒人會願意這麼做）
只用int跟double這方法很不錯（再加一個bool），希望C++能改成這樣 XD
→ CoNsTaR: 你說的是抽象化分類的極端 我講的是泛化統整的極端 07/30 17:23
→ CoNsTaR: 這種問題沒有答案 所以…還是照原本就好囉… 07/30 17:23
→ CoNsTaR: 畢竟 C/C++ 都是強調不做太多的語言(像是沒有GC) 這種事 07/30 17:23
不做太多->programmer要寫比較多code
所以我的提案也蠻符合的吧？
→ CoNsTaR: 情需要的人再用 bitfield 就好啦 XD 07/30 17:23
推 james732: 整數通通是int，浮點數通通是double←這我喜歡XD 07/30 17:26
→ james732: 我除了寫在嵌入式系統斤斤計較以外，通常都只用int...XD 07/30 17:26
推 wtchen: 覺得這樣做會讓可攜性變差.... stdint原本就是為了可攜性 07/30 17:51
→ wtchen: 增加的不用stdint反而各搞各的不是compiler要對應各種需求 07/30 17:52
→ wtchen: 變得更複雜，就是code移到別的平台後效能差很大 07/30 17:52
我覺得可攜性應該不變才對吧？
對於不支援這種功能（例如要求int 6 bit）的平台
就只是把這個int提升到8 bit或16 bit而已（就是換成現在的char或int）
只要你使用你所宣告出來的bit數內的值，換個平台仍然可以正常運作
反而是那些使用int8_t、int32_t的人，才有可攜性的問題
（其實我很好奇，到底是甚麼情況，一定要用int8_t，但是不能用int_least8_t？）
如果你要用int_fast8_t，那頂多就是寫成
int_fst:8 a;
但是compiler會需要做得更複雜，這就是真的了
推 CoNsTaR: 使用者輸入就是一個編譯器算不出上/下限的東西啊 這種東 07/30 17:58
→ CoNsTaR: 西照你的方法是很適合沒錯啦XD 07/30 17:58
→ CoNsTaR: 應該說是各有用途 用在不同地方吧 07/30 17:59
推 CoNsTaR: 或許你已經強制指定的編譯器就直接用你的特化版 07/30 18:01
→ CoNsTaR: 沒指定的它再幫你算 你沒指定它又算不出來看是要報錯 還 07/30 18:01
→ CoNsTaR: 是用原本標準 07/30 18:01
→ CoNsTaR: 這樣寫個程式也好累喔 XDDD 不過是滿不錯的構想啦說真的 07/30 18:02
→ CoNsTaR: 增加程式安全性 07/30 18:03
推 wtchen: 是覺得這種大部份新手不會用的功能不要加進去 07/30 18:04
可是常看到有人...
把int拿來當作32 bit來用（大部分情況是可以，但就是不符合標準，int只保證16 bit）
問bit field的實際大小是甚麼（都說是implementation defined，還一直問）
就會覺得還不如普及化這些知識
而且對我來說，把值的範圍寫得很精確的話，debug起來比較容易
→ wtchen: 真的必要用bit-field就好，否則debug起來又是災難 07/30 18:05
就是因為bit field要放在struct很麻煩，所以才提這方法的...
推 CoNsTaR: debug 災難沒錯 不過這做法也可以避免掉很多很多 bug 了 07/30 18:07
→ CoNsTaR: XD 07/30 18:07
推 Sidney0503: 你都說底層了 你知道c和組語的關係嗎........ 07/30 18:28
所以才上來討論，問問各位的看法，請求大師開悟 <(_ _)>
→ Sidney0503: 另外 C++已經可以說跟C截然不同了 07/30 18:29
推 Sidney0503: 首先你的目的是什麼? 你想要控制值的範圍? 07/30 19:05
1.明確表示值的範圍
int:6 a;
只表示至少6 bit，不要求實際大小是6 bit
2.省空間
如果能夠達到實際大小是6 bit，那就有省空間了
→ Sidney0503: 那就是一件很奇怪的事 因為都是2^n相關 07/30 19:05
→ Sidney0503: 你想要跑快一點 只要一次pipeline可以吃 幾bit都沒差 07/30 19:06
→ Sidney0503: 省空間? 與其省這個不如code寫好一點 07/30 19:08
→ Sidney0503: 基本上C往下挖就是組合語言 組合語言往下挖就是CPU 07/30 19:09
→ Sidney0503: 硬體架構會基於軟體 軟體會被硬體牽制 07/30 19:10
→ Sidney0503: 就算有你所謂的"未來架構" 那也會有"未來指令" 07/30 19:11
→ Sidney0503: 有"編譯器"的理論在 就會有對應的語言 07/30 19:11
推 wtchen: 在使用bit-field的時候endianness也要考慮進去 07/30 19:22
→ netsphere: type-safty表示 07/30 19:22
→ wtchen: （就可攜性來說，使用bit-field已經有點危險了） 07/30 19:23
→ wtchen: 全部type都變成bit-field，考慮到endianness結果有點可怕 07/30 19:24
我沒想到bit field會牽扯到endianness...
這部分我之後再看
推 descent: 我現在會用 type unsigned int u32, 然後用 u32 07/30 21:51
→ descent: 不想直接用 unsigned int 這樣的用法了 07/30 21:51
→ descent: 最近踩一堆雷 07/30 21:52
可是unsigned int也不保證是32 bit
你不用uint32_t或uint_least32_t
（話說有非用uint32_t不可的例子嗎？）
推 LiloHuang: 樓上改用 stdint.h 的 uint32_t 呢 07/30 22:49
推 descent: 字太多, 打起來累人, u32, u8, u16, 你打一個我打3個 07/30 22:54
→ LiloHuang: 個人覺得 C99 標準能用則用，打字累人則是另一回事了XD 07/30 23:01
→ wtchen: 為啥不typedef uint32_t u32，這樣不是安全些？ 07/30 23:11
對阿
descent不考慮嗎？
推 yvb: int 7:xxx; ==> union { int yyy:7 } xxx; 07/30 23:23
→ yvb: 然後再 #define xxx xxx.yyy 07/30 23:24
→ yvb: 接著 xxx = 127; ==> ok; xxx = 128; ==> warning 07/30 23:25
→ yvb: 當然若考慮 define 可能會有額外風險, 就直接用 xxx.yyy . 07/30 23:27
這是另一種做法，可是寫起來很麻煩
而且還有用macro，實在不是好方法
推 CoNsTaR: 可是樓上 xxx = func(); 預設是不會 warning 的 就算 fun 07/30 23:29
→ CoNsTaR: c 回傳常數 128 也一樣 07/30 23:29
→ yvb: 當然 , struct { int yyy:7 } xxx; 一樣效果. 07/30 23:30
→ yvb: 語法本身不提供 int:7 寫法, 轉個彎換寫法效果一樣. 07/30 23:31
→ yvb: 當然, 其中的 int yyy:7 和 long long yyy:7 應該會相同; 07/30 23:37
→ yvb: 但寫 char yyy:7 或 short yyy:7 會不同(前提用 32 bit 機器) 07/30 23:39
→ yvb: 上兩句可能和機器及編譯器,甚至編譯選項相關, 請忽略. 07/30 23:44
→ yvb: 回 CoNsTaR: 只是驗證是有 int:7 效果, 設128去印應該會是0. 07/30 23:47
推 kevingwn: 省空間是說想要vector<int6_t>這樣的操作嗎?應該是辦得 07/30 23:52
沒有想到這喔
我指的省空間是
如果是int:4和int:10
那可以擺在一起變成int:16（2個合起來，是至少14）
可是如果是現有的寫法，就是char和int
那這樣就是至少24 bit
兩個就差10 bit了
當然現有的做法可以用struct去包，可是那樣太麻煩了
→ kevingwn: 到,但效能應該比vector<int8_t>差很多 07/30 23:53
→ kevingwn: 通常只有在存成檔案或網路傳輸等會有這樣的需求吧? 07/30 23:55
推 TobyH4cker: 看來沒寫過組語 07/31 00:02
→ TobyH4cker: 哦，看懂了，不過我覺得指明跟不指明沒差，因為本來 07/31 00:16
→ TobyH4cker: 就是要看文件，把文件的規範讀的很精熟的話，coding 07/31 00:16
→ TobyH4cker: 起來比較容易 07/31 00:16
我知道
但如果能夠在不看文件下，能夠提高讀懂code的可能性，這樣就更好了
→ TobyH4cker: 至於你說那些新手，或是老手都還不知道實際大小那些 07/31 00:18
→ TobyH4cker: ，只是表面他們學得不夠或看得不夠而已 07/31 00:18
→ TobyH4cker: 但是你的想法其實可以帶來一個好處，就是整數型態就 07/31 00:23
→ TobyH4cker: 只要有int跟uint就夠了，手動指定最小bit數，compile 07/31 00:23
其實我是比較希望只有int啦
如果要增加uint，那我覺得就要有3種型態，分別是
sint //包含負數
int //不在意正負數。當作buf時，用這個最好
uint //只包含正數
→ TobyH4cker: r來安排它要用多大空間這樣，吧？ 07/31 00:23
bingo!
就是bit field
只不過不用包在struct
→ TobyH4cker: 嗯嗯那signed跟unsigned你會怎麼做0.0 07/31 15:35
目前應該會用
只有int，然後signed跟unsigned要在讀或寫時來決定
或
有int、sint、uint
→ wtchen: 還有一個問題，怎麼判斷是否overflow? 07/31 16:20
照常理來說，應該是不會overflow才對
因為你需要知道你的input的值的range
如果不知道，我們可以定義
sintmax_t //能表示的最小負數
uintmax_t //能表示的最大正數
如果連用這個都還能overflow，那表示就算用現在的做法（size_t），也還是會overflow
→ wtchen: 這樣搞的話要弄一個header把所有可能的max/min define進去 07/31 16:21
不
只要提供這2個就可以了
頂多就是再提供intptr_t這東西
不過我之後想跟各位討論，pointer存在的必要性就是了...
推 CoNsTaR: 樓上這麼做的優點就是不用考慮 overflow 啊… 07/31 17:05
→ CoNsTaR: 你已經知道它在這個程式裡有可能被賦的最大最小值了 怎 07/31 17:06
→ CoNsTaR: 麼會 overflow 07/31 17:06
推 CoNsTaR: 我也認同原 po sint int uint 的構想 07/31 18:15
→ CoNsTaR: 只是我覺得 signed unsigned (原本是 modifier) 可以變 07/31 18:15
→ CoNsTaR: 成像是 const 那樣的東西(qualifier) 07/31 18:15
→ CoNsTaR: int (specifier) 本身可以儲存任何整數 但是一旦加了 sig 07/31 18:15
→ CoNsTaR: ned/unsigned 07/31 18:15
→ CoNsTaR: 你就不能賦 正/負 數給他 07/31 18:15
→ CoNsTaR: 就像加 const 一樣，你就不能賦 non-const 給他 07/31 18:15
轉型會是個問題
我是覺得照以下這兩個想法比較好
如果是int，然後signed跟unsigned要在讀或寫時來決定，那就不需要處理轉型
如果是int、sint、uint，那轉型就是按照現在的標準來做就好
→ CoNsTaR: 這麼做 int 的本質不會改變 但是編譯器會為你做額外的檢 07/31 18:15
→ CoNsTaR: 查，保證你沒有把不對的值賦給變數 07/31 18:15
→ CoNsTaR: 這樣的好處是，這三種型態實際上是一模一樣的，只是你給 07/31 18:15
→ CoNsTaR: 他們一些限制 07/31 18:15
→ CoNsTaR: 所以 int 裝得下的數字其他兩種一定也裝得下(不會 overfl 07/31 18:15
→ CoNsTaR: ow，cast 的時候 binary 值也不會改變) 07/31 18:15
→ CoNsTaR: 至於 casting 規則嘛…… 07/31 18:15
推 wtchen: 原創的使用者可以自訂範圍，只是如果多人一起編輯 07/31 18:17
→ wtchen: 恐怕會加深code的複雜度.... 07/31 18:18
推 CoNsTaR: w大 不太懂你的問題耶… 07/31 18:20
→ wtchen: <= 16 bit好解決，如果是> 16 bit 那還要記不同bit的最大 07/31 18:29
→ wtchen: 最小值？ (我算術不好不能一眼看出來) 07/31 18:30
我想沒人能一眼就看出來，這應該不是問題才對...
→ wtchen: 除非一直用2進位或16進位，如果要轉到10進位就.... 07/31 18:30
推 wtchen: 至於bit field vs. endianness 可以看這裡： 07/31 18:41
→ CoNsTaR: 喔喔 其實沒有那麼複雜啊 因為只有某些特殊值的上下限是 07/31 19:01
→ CoNsTaR: 需要你手動定義的 像是 協定裡某個值的上下限/輸入輸出 07/31 19:01
→ CoNsTaR: 能接受的上下限 之類 剩下的其實都可以在編譯時期動態的 07/31 19:01
→ CoNsTaR: 決定 07/31 19:01
我的麻煩在那個.
如果語言能直接提供的話就好了
另外你的template寫法，很 厲 害 <(_ _)>
→ kevingwn: 倒是覺得vector<int4_t>比較困難 07/31 21:28
推 Sidney0503: 說真的我不懂你的需求 07/31 21:58
主旨的確有點不太清楚
但我要問的就是
為什麼不讓所有的int型態，都只能用bit field方式宣告（在不用struct的情況下）
好處是
1.可以很明確的表示，值的範圍
寫
int a;
跟
int:21 a;
後者在即使缺乏文件或註解的情況下，仍然知道a只需要用到21個bit
2.省空間（部份情況）
→ Sidney0503: 光你說擺再一起省空間 很想叫你去念計算機組織 07/31 21:59
這些概念都是只要求 至少 幾個bit
為什麼不能省空間...？
→ Sidney0503: 首先 管bit不是在管硬碟block 光是紀錄就要消耗多少 07/31 22:20
→ Sidney0503: 多少空間 其次先不談對齊問題 07/31 22:20
其實，我有一個疑問
我的作法只是把bit field拿來用
完全沒有新創的方法...
所以
缺點就是bit field的缺點
優點就是bit feild的優點
你講的這些我會再去查查看
→ Sidney0503: 你要如何設計一個CPU可以同時執行兩個指令? 07/31 22:21
→ Sidney0503: pipeline一次就是吃這麼多bit 你空下來又如何? 07/31 22:21
沒幹嘛
我提這點不是為了速度，主要是為了明確表示值的範圍
→ Sidney0503: 我覺得你拿去八卦版問比較好 人比較多 也不只C 07/31 22:23
→ Sidney0503: 說不定精通其他語言的人會幫你解答 07/31 22:23
拿去八卦版，感覺只會有一堆人亂回...
→ CoNsTaR: 樓上重點錯誤吧…… 07/31 22:36
→ yoco: 我覺得不是不行，只是沒有人寫 proposal 給標準委員會 07/31 22:39
→ yoco: 你寫一份吧 07/31 22:39
→ yoco: 就像 C++11 沒有 VAL，不是不行，單純只是沒人提 proposal 07/31 22:40
我倒是比較想提我之前說的bind+move
但一看到tuple+ C++17 apply，我就知道不用提了 XD
推 wtchen: Sidney0503講的是Write amplification嗎？ 07/31 22:52
推 Sidney0503: 樓上說的是我其中一個想法 我真的想不到如何省空間.. 08/01 06:48
http://ideone.com/Y9zcrs
這樣你能理解嗎？
B的做法，有些平台的size仍然會跟A一樣
但是C通常都會比A小
→ Sidney0503: 你現在又跟我說表示值的範圍 我最一開始就說很奇怪 08/01 06:49
我是覺得 我沒有"又"跟你說表示值的範圍...
表示值的範圍我一直都有說到
→ Sidney0503: 為甚麼值的範圍只能是2^n次方 根本就不符合使用 08/01 06:49
→ Sidney0503: 除了bool 大多數我們使用的數字範圍都不是2^n 08/01 06:50
→ Sidney0503: 天堂32767和戰神65535一看就知道是被硬體牽制 08/01 06:51
→ Sidney0503: 而不是使用需求才設這個範圍 08/01 06:51
推 Sidney0503: 這種邊界的問題生出物件的原則像JAVA慣用set和get 08/01 06:56
因為現在1個bit就只能表示0或1（所以才叫bit）
你如果要能夠表示任意範圍（不止2的倍數）
那你硬體上要怎麼設計？
我覺得用bit field來表示範圍，雖然沒有辦法每次都精準
但至少已經滿足我的需求了
噓 Sidney0503: 原來你知道什麼叫硬體不好設計阿 我還以為你不知道耶 08/01 16:48
→ Sidney0503: 我已經跟你說了就是慣用的set和get會限制邊界 08/01 16:54
→ Sidney0503: 難不成我用你的API還要看每個變數的範圍? 08/01 16:55
推 wtchen: 以後量子電腦如果成功量產，1 bit 就能表示成0~7 08/01 17:21
→ wtchen: 搞不好C standard也要全部重新定義 08/01 17:22
推 chchwy: 就CPU的角度來說 你的建議完全不會增加效能 08/01 18:11
推 goliathplus: 因為沒有意義阿 硬體架構要 ALIGN 單一變數指定bit 08/05 00:02
→ goliathplus: 沒有顯著優點阿 08/05 00:02
→ tomjpsun: RAM 越來越大碗,連 embedded system 也有受惠, 所以十年 08/05 17:09
→ tomjpsun: 前是應該考慮這些,但是現在其實容易 maintain 可能比較 08/05 17:12
→ tomjpsun: 重要吧！ 08/05 17:12
推 jeff04209: 你cache怎麼放？memory 怎麼放？拿資料一次要拿多少？ 08/12 18:55
→ jeff04209: 你處理器每次拿資料都要用額外的邏輯去判斷，這個複雜 08/12 18:55
→ jeff04209: 度... 08/12 18:55
推 jeff04209: 你以為你高階語言想怎麼寫就怎麼寫喔，硬體為了這點沒 08/12 18:58
→ jeff04209: 什麼幫助的功能所耗的cost有多大你知道嗎 08/12 18:58
我覺得我文章寫得一定不好，不然就不會有人提到一些其他方面的問題
我在文章裡面說明了，如果compiler沒辦法提供這功能，那就只要無視它就好
我要的是把bit field的功能，在平常變數宣告時就可以使用，而不用放在struct裡面
如果你們覺得這功能很沒用、一點都不會增進效能、只會增加硬體實作困難
那為什麼C還要提供bit field的功能？
有些人回覆說硬體架構很難做之類的，我可以接受
但是這問題都是早就被解決的，不然bit field早就不存在了
→ jun0325: 硬體沒有難不難做...只是要看compiler和硬體要如何合作罷 08/17 01:10
→ jun0325: 了。就算你新增了bit field的語意，要讓它跑在原本的CPU 08/17 01:10
→ jun0325: 也是可以，就只是讓compiler增加原本的工作去support你要 08/17 01:10
→ jun0325: 的語意，用原本的ISA去拼出你想要的functionality，反之 08/17 01:10
→ jun0325: 亦然，可以extend ISA減少compiler的工作。 08/17 01:10
→ jun0325: 不過要讓不同長度的變數pack到同一個register裡，你要讓 08/17 01:18
→ jun0325: 硬體如何對其中一個變數做運算XD。我能想到最接近的概念 08/17 01:18
→ jun0325: 就是SSE了。 08/17 01:18
→ jun0325: 會比較有概念 08/17 01:23
噓 Sidney0503: 那是struct 每一次使用就是會要一整個區塊空間 08/24 08:43
→ Sidney0503: 就算你變數真的用bit field 也是每次要一個變數的空間 08/24 08:44
→ Sidney0503: 不會省空間 08/24 08:44
→ Sidney0503: struct大太 就是倍數整區塊 08/24 08:45
→ Sidney0503: 怕你不懂 假設八位元 struct要到的空間就是 08/24 08:46
→ Sidney0503: 總 bit數/8 取天花板 *8 ok? 08/24 08:47
→ Sidney0503: 打包一群變數 可以靠命命開頭讓人知道是同群組資料 08/24 08:48
→ Sidney0503: struct是連硬體位置都連在一起 08/24 08:49
→ Sidney0503: 只能說你對c/組合語言/計算機架構完全沒概念 08/24 08:51
→ Sidney0503: 在你好好念書之前 你永遠都無法理解你的14+2=16bit 08/24 08:53
→ Sidney0503: 是多外行的說法 08/24 08:53
有多外行？
從這code來說，http://ideone.com/Y9zcrs
A的size是4，B跟C的size是2
用了bit field後，B跟C的size的確小於A
我說用bit field可以省空間，到底哪裡有問題？
噓 Sidney0503: 而硬體連續性也是陣列最重要的 因為struct把變數 08/24 09:04
→ Sidney0503: 的空間連續 陣列才能取用struct裡面的面數 08/24 09:05
→ Sidney0503: 用命名開頭表示群組 會被compiler打散 效能自然差 08/24 09:07
int a;
//do something
int b;
//do something
int c;
如果每個人都是要用到該變數時才宣告，那這樣子的bit field就沒用
可是，隨便翻一堆code，大部分都是先把會用到的變數宣告在一開始，如下
int a;
int b;
int c;
//do something
那這樣compiler可以嘗試把a b c當作一個struct來包，然後就可以直接套用bit field
（這前提當然是，a、b、c可以在struct外面使用bit field）
如果你跟我說，因為上面那原因，導致這想法不夠實際，所以這方法不會被採用
但實際情況不是這樣啊
寫下面那種形式的人比上面多很多
這功能可能很雞肋，但它至少還是有能用的地方的
噓 Sidney0503: 比起在這邊跟板友筆戰 不如先好好念底層的原理 08/24 09:10
→ EdisonX: 亂入一下,C++ 是建議變數用到時才宣告,所以是建議第一種 08/25 23:11
我猜會用第二種的原因，應該是很多人從C那邊轉來，所以才寫下面那種方法吧
推 EdisonX: 對，早期c所有宣告必須放在 Block 最前面 08/27 08:56
→ EdisonX: 但新標準已沒差了 (不過寫 FW 還是一樣) 08/27 08:57
→ EdisonX: 如果是要省空間的話,看過用 union 來省 08/27 08:58
話說C++17提供std::variant，來取代union
※ 編輯: Caesar08 (1.164.42.156), 08/27/2016 09:42:03