把long賦值給int不就會被截?cái)嗦锇蹋灰獙?shí)際的數(shù)值可以被int所容納不就行了嘛评雌。頂多也就是個警告而已蝇刀。
為啥要使用數(shù)值的對象類型呢螟加？
因?yàn)樗鼘緮?shù)值類型做了封裝，屏蔽了環(huán)境32位和64位的差別吞琐，讓你專注于邏輯上的思考捆探。
NSNotFound居然是個數(shù)字！
本節(jié)說32位編譯器以4字節(jié)為單位對齊站粟，64位編譯器以8字節(jié)為單位對齊黍图。原因?yàn)?2位編譯器中的32除以8等于4，同理可知64位環(huán)境中8的由來奴烙。
32位環(huán)境以4字節(jié)為對齊單位助被，64位環(huán)境以8字節(jié)為對齊單位。
本節(jié)中還舉了這樣一個struct結(jié)構(gòu)體的例子切诀。
書中說在32位環(huán)境下由于前三個變量都各占4個字節(jié)揩环，并且符合32位環(huán)境下的對其單位，所以前三個成員總共占了12個字節(jié)幅虑，最后一個變量自身大小占8個字節(jié)丰滑，又是對齊單位的倍數(shù)，所以沒問題倒庵。
但是在64位環(huán)境下前兩個成員占了8個字節(jié)正好一個對齊單位褒墨，但是第三個成員自身是4個字節(jié)，對齊單位是8個字節(jié)哄芜，所以它占不到8個字節(jié)貌亭。這樣會導(dǎo)致第四個成員的前四個字節(jié)被填充到第三個字節(jié)空余的那個4個字節(jié)中柬唯，后四個字節(jié)在新的內(nèi)存對其單位中认臊。CPU想訪問第四個成員的時(shí)候需要先訪問第三個成員所在的8個字節(jié)中的后四個字節(jié)，再訪問第四個成員所在的新的8個字節(jié)中的前4個字節(jié)锄奢。造成讀寫效率的低下失晴，為了避免這種情況的出現(xiàn)剧腻，所以需要把第三個成員變量的所造成的空白的4個字節(jié)填充滿。
所以寫結(jié)構(gòu)體的慣例是先寫占用內(nèi)存大的類型涂屁，然后寫占用內(nèi)存小的類型书在。你也可以不遵守這個慣例而使用強(qiáng)制對齊。
所謂緊湊型的數(shù)據(jù)結(jié)構(gòu)拆又，是從內(nèi)存的排布角度來說的儒旬，就是無論是32位環(huán)境下還是64位環(huán)境下所占用的實(shí)際內(nèi)存盡量的小，為什么呢帖族，因?yàn)橛袀€填充的機(jī)制栈源。如果數(shù)據(jù)設(shè)計(jì)得不好填充所需要的空間會很大。
