精彩
OpenGL透視投影下的模型視圖矩陣/投影矩陣/觀察者矩陣一.首先我們先來看看這些矩陣在透視投影下的位置 特別說明:objectFrame是用來記錄物體發(fā)生旋轉/平移/縮放等的矩陣（暫且命名為模型矩陣吧），模型視圖矩陣（model...
IP屬地：四川
-
-
OpenGL透視投影下的模型視圖矩陣/投影矩陣/觀察者矩陣一.首先我們先來看看這些矩陣在透視投影下的位置 特別說明:objectFrame是用來記錄物體發(fā)生旋轉/平移/縮放等的矩陣（暫且命名為模型矩陣吧），模型視圖矩陣（model...
-
這就是大佬的實力嗎
iOS------OpenGL 圖形專有名詞與坐標解析
一.OpenGL簡介 OpenGL（英語：Open Graphics Library，譯名：開放圖形庫或者“開放式圖形庫”）是用于渲染2D、3D矢量圖形的跨語言、跨平臺的應用...
-
iOS------OpenGL 圖形專有名詞與坐標解析一.OpenGL簡介 OpenGL（英語：Open Graphics Library，譯名：開放圖形庫或者“開放式圖形庫”）是用于渲染2D、3D矢量圖形的跨語言、跨平臺的應用...
-
@jackhans atomic?給set和get方法加了個自旋鎖，如果你在thread1調用set方法，其他thread使用它，都會等待thread1的set方法執(zhí)行，包括get方法；所以，取值時需要等待。atomic修飾的是指針，它只對指針負責，它也保證了寫入指針的完整性，所以，atomic沒啥毛病，有毛病的是人。
atomic修飾的對象，比如NSMutableArray，執(zhí)行addObject時，它是不安全的，因為atomic不負責array的添加，atomic只負責這個對象的指針，需要你自己負責addObject時的線程安全。使用atomic一定是線程安全的嗎？
這個問題很少遇到，但是答案當然不是。atomic在set方法里加了鎖，防止了多線程一直去寫這個property，造成難以預計的數(shù)值。但這也只是讀寫的鎖定。跟線程安全其實還是差...
-
@kosser小屋 因為一個實例對象的指針實際上分配了16個字節(jié)。
使用atomic一定是線程安全的嗎？
這個問題很少遇到，但是答案當然不是。atomic在set方法里加了鎖，防止了多線程一直去寫這個property，造成難以預計的數(shù)值。但這也只是讀寫的鎖定。跟線程安全其實還是差...
-
po主理解錯了。atomic是絕對安全的。
我們知道，在64位的操作系統(tǒng)下，所有類型的指針，包括void * 都是占用8個字節(jié)的。超過4個字節(jié)的基本類型數(shù)據都會有線程并發(fā)的問題。
那所有的指針類型都會有這個問題。
以oc 下的 NSArray * 為例子，如果一個多線程操作這個數(shù)據，會有兩個層級的并發(fā)問題
1、指針本身
2、指針所指向的內存
指針本身也是占用內存的，并且一定是8個字節(jié)，第二部分，指針所指向的內存，這個占多少字節(jié)就不一定了，有可能非常大，有可能也就1個字節(jié)
所以我們考慮NSArray * array 這個數(shù)據array 多線程操作的時候，必須分成兩部分來描述，一個是&array這個指針本身，另一個則是它所指向的內存 array
大家注意下 &array 和 array 的區(qū)別 ，其實不用糾結，你就想象現(xiàn)在有兩塊內存，一塊是8字節(jié)，一塊n字節(jié)，8字節(jié)里面放的值，就是n字節(jié)內存的首地址，
ok 現(xiàn)在聯(lián)系上atomic，如果用@property(atomic)NSArray *array 修飾之后，會有什么影響？網上說的很多，不再贅述，我只想從內存的角度來解釋這個過程
首先第一點，你要記住，@property(atomic)NSArray *array 其實修飾的是這個指針，也就是這個8字節(jié)內存，跟第二部分數(shù)據n字節(jié)沒有任何關系，被atomic 修飾之后，你不可能隨意去多線程操作這個8字節(jié)，但是對8字節(jié)里面所指向的n字節(jié)沒有任何限制！這就是所有網絡上所說的 atomic 不安全的真相 ?。?！
我們來看一下，這能怪atomic？ 本身你修飾的是一個指針，并且atomic 已經完美的履行了它的指責，你現(xiàn)在不可能對這個8字節(jié)進行無序的多線程操作，這就夠了呀！atomic沒有任何鳥問題。有問題的是人，你本身并未對n字節(jié)做任何的限制，所以把問題怪罪到atomic 上真的是很不合理 -
隨便說說 alloc 和 init先拋出一個小問題,然后延伸引入接下來要說的 zuyuClass *z = [zuyuClass alloc]; zuyuClass *z1 = [z init]; zuyuC...
-
九年大佬，恐怖如斯
隨便說說 alloc 和 init
先拋出一個小問題,然后延伸引入接下來要說的 zuyuClass *z = [zuyuClass alloc]; zuyuClass *z1 = [z init]; zuyuC...
-
po主理解錯了。atomic是絕對安全的。
我們知道，在64位的操作系統(tǒng)下，所有類型的指針，包括void * 都是占用8個字節(jié)的。超過4個字節(jié)的基本類型數(shù)據都會有線程并發(fā)的問題。
那所有的指針類型都會有這個問題。
以oc 下的 NSArray * 為例子，如果一個多線程操作這個數(shù)據，會有兩個層級的并發(fā)問題
1、指針本身
2、指針所指向的內存
指針本身也是占用內存的，并且一定是8個字節(jié)，第二部分，指針所指向的內存，這個占多少字節(jié)就不一定了，有可能非常大，有可能也就1個字節(jié)
所以我們考慮NSArray * array 這個數(shù)據array 多線程操作的時候，必須分成兩部分來描述，一個是&array這個指針本身，另一個則是它所指向的內存 array
大家注意下 &array 和 array 的區(qū)別 ，其實不用糾結，你就想象現(xiàn)在有兩塊內存，一塊是8字節(jié)，一塊n字節(jié)，8字節(jié)里面放的值，就是n字節(jié)內存的首地址，
ok 現(xiàn)在聯(lián)系上atomic，如果用@property(atomic)NSArray *array 修飾之后，會有什么影響？網上說的很多，不再贅述，我只想從內存的角度來解釋這個過程
首先第一點，你要記住，@property(atomic)NSArray *array 其實修飾的是這個指針，也就是這個8字節(jié)內存，跟第二部分數(shù)據n字節(jié)沒有任何關系，被atomic 修飾之后，你不可能隨意去多線程操作這個8字節(jié)，但是對8字節(jié)里面所指向的n字節(jié)沒有任何限制！這就是所有網絡上所說的 atomic 不安全的真相 ！??！
我們來看一下，這能怪atomic？ 本身你修飾的是一個指針，并且atomic 已經完美的履行了它的指責，你現(xiàn)在不可能對這個8字節(jié)進行無序的多線程操作，這就夠了呀！atomic沒有任何鳥問題。有問題的是人，你本身并未對n字節(jié)做任何的限制，所以把問題怪罪到atomic 上真的是很不合理使用atomic一定是線程安全的嗎？
這個問題很少遇到，但是答案當然不是。atomic在set方法里加了鎖，防止了多線程一直去寫這個property，造成難以預計的數(shù)值。但這也只是讀寫的鎖定。跟線程安全其實還是差...
-
#define UIColorFromHex(s) [UIColor colorWithRed:(((s & 0xFF0000) >> 16 )) / 255.0 green:((( s & 0xFF00 ) >> 8 )) / 255.0 blue:(( s & 0xFF )) / 255.0 alpha:1.0]
一個宏定義就OK了
調用 UIColorFromHex(0xffffff)iOS開發(fā)-一句代碼輕松實現(xiàn)十六進制顏色（#開頭）轉RGB顏色
我們在做iOS開發(fā)，給一個 view添背景顏色時，一般都是用到RGB顏色，比如下面這樣的 然后美工給我們作圖的時候往往給我們的色值都是十六進制的顏色， 比如這樣的 如果老大不...
-
如果你是程序員，或者有一顆喜歡寫程序的心，喜歡分享技術干貨、項目經驗、程序員日常囧事等等，歡迎投稿《程序員》專題。 專題主編：小彤花園 http://www.itdecent.cn/users/4a4eb4feee62/ 【程序員】專題拒稿指北：http://www.itdecent.cn/p/7c8b33b5f63b 投稿須知： 1.收錄相關技術文章，但不限于技術，也可以是項目經驗類的文章和程序員日常。 2.文章內不得有任何推廣信息。包括但不限于公眾號、微博、微信，更不得在通過投稿后再修改文章加入推廣信息。你可以將這些推廣以及個人信息放在個人主頁介紹里。 3.字數(shù)極少，段落混亂，大段代碼沒有放到代碼框的文章不收錄 4.不相關的內容不收錄，請確認文章內容和本專題相關 目前針對優(yōu)質作者及愛好者，開設了官方程序員微信群，希望加入請發(fā)簡信給主編小彤花園索取個人微信，主編會將你加入到【程序員】微信群，分享內容，收獲知識。添加微信時備注昵稱。
