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