精彩
OpenGL透视投影下的模型视图矩阵/投影矩阵/观察者矩阵一.首先我们先来看看这些矩阵在透视投影下的位置 特别说明:objectFrame是用来记录物体发生旋转/平移/缩放等的矩阵（暂且命名为模型矩阵吧），模型视图矩阵（model...
IP属地：四川
-
-
OpenGL透视投影下的模型视图矩阵/投影矩阵/观察者矩阵一.首先我们先来看看这些矩阵在透视投影下的位置 特别说明:objectFrame是用来记录物体发生旋转/平移/缩放等的矩阵（暂且命名为模型矩阵吧），模型视图矩阵（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方法执行，包括get方法；所以，取值时需要等待。atomic修饰的是指针，它只对指针负责，它也保证了写入指针的完整性，所以，atomic没啥毛病，有毛病的是人。
atomic修饰的对象，比如NSMutableArray，执行addObject时，它是不安全的，因为atomic不负责array的添加，atomic只负责这个对象的指针，需要你自己负责addObject时的线程安全。使用atomic一定是线程安全的吗？
这个问题很少遇到，但是答案当然不是。atomic在set方法里加了锁，防止了多线程一直去写这个property，造成难以预计的数值。但这也只是读写的锁定。跟线程安全其实还是差...
-
@kosser小屋 因为一个实例对象的指针实际上分配了16个字节。
使用atomic一定是线程安全的吗？
这个问题很少遇到，但是答案当然不是。atomic在set方法里加了锁，防止了多线程一直去写这个property，造成难以预计的数值。但这也只是读写的锁定。跟线程安全其实还是差...
-
po主理解错了。atomic是绝对安全的。
我们知道，在64位的操作系统下，所有类型的指针，包括void * 都是占用8个字节的。超过4个字节的基本类型数据都会有线程并发的问题。
那所有的指针类型都会有这个问题。
以oc 下的 NSArray * 为例子，如果一个多线程操作这个数据，会有两个层级的并发问题
1、指针本身
2、指针所指向的内存
指针本身也是占用内存的，并且一定是8个字节，第二部分，指针所指向的内存，这个占多少字节就不一定了，有可能非常大，有可能也就1个字节
所以我们考虑NSArray * array 这个数据array 多线程操作的时候，必须分成两部分来描述，一个是&array这个指针本身，另一个则是它所指向的内存 array
大家注意下 &array 和 array 的区别 ，其实不用纠结，你就想象现在有两块内存，一块是8字节，一块n字节，8字节里面放的值，就是n字节内存的首地址，
ok 现在联系上atomic，如果用@property(atomic)NSArray *array 修饰之后，会有什么影响？网上说的很多，不再赘述，我只想从内存的角度来解释这个过程
首先第一点，你要记住，@property(atomic)NSArray *array 其实修饰的是这个指针，也就是这个8字节内存，跟第二部分数据n字节没有任何关系，被atomic 修饰之后，你不可能随意去多线程操作这个8字节，但是对8字节里面所指向的n字节没有任何限制！这就是所有网络上所说的 atomic 不安全的真相 ！！！
我们来看一下，这能怪atomic？ 本身你修饰的是一个指针，并且atomic 已经完美的履行了它的指责，你现在不可能对这个8字节进行无序的多线程操作，这就够了呀！atomic没有任何鸟问题。有问题的是人，你本身并未对n字节做任何的限制，所以把问题怪罪到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位的操作系统下，所有类型的指针，包括void * 都是占用8个字节的。超过4个字节的基本类型数据都会有线程并发的问题。
那所有的指针类型都会有这个问题。
以oc 下的 NSArray * 为例子，如果一个多线程操作这个数据，会有两个层级的并发问题
1、指针本身
2、指针所指向的内存
指针本身也是占用内存的，并且一定是8个字节，第二部分，指针所指向的内存，这个占多少字节就不一定了，有可能非常大，有可能也就1个字节
所以我们考虑NSArray * array 这个数据array 多线程操作的时候，必须分成两部分来描述，一个是&array这个指针本身，另一个则是它所指向的内存 array
大家注意下 &array 和 array 的区别 ，其实不用纠结，你就想象现在有两块内存，一块是8字节，一块n字节，8字节里面放的值，就是n字节内存的首地址，
ok 现在联系上atomic，如果用@property(atomic)NSArray *array 修饰之后，会有什么影响？网上说的很多，不再赘述，我只想从内存的角度来解释这个过程
首先第一点，你要记住，@property(atomic)NSArray *array 其实修饰的是这个指针，也就是这个8字节内存，跟第二部分数据n字节没有任何关系，被atomic 修饰之后，你不可能随意去多线程操作这个8字节，但是对8字节里面所指向的n字节没有任何限制！这就是所有网络上所说的 atomic 不安全的真相 ！！！
我们来看一下，这能怪atomic？ 本身你修饰的是一个指针，并且atomic 已经完美的履行了它的指责，你现在不可能对这个8字节进行无序的多线程操作，这就够了呀！atomic没有任何鸟问题。有问题的是人，你本身并未对n字节做任何的限制，所以把问题怪罪到atomic 上真的是很不合理使用atomic一定是线程安全的吗？
这个问题很少遇到，但是答案当然不是。atomic在set方法里加了锁，防止了多线程一直去写这个property，造成难以预计的数值。但这也只是读写的锁定。跟线程安全其实还是差...
-
#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开发-一句代码轻松实现十六进制颜色（#开头）转RGB颜色
我们在做iOS开发，给一个 view添背景颜色时，一般都是用到RGB颜色，比如下面这样的 然后美工给我们作图的时候往往给我们的色值都是十六进制的颜色， 比如这样的 如果老大不...
-
如果你是程序员，或者有一颗喜欢写程序的心，喜欢分享技术干货、项目经验、程序员日常囧事等等，欢迎投稿《程序员》专题。 专题主编：小彤花园 http://www.jianshu.com/users/4a4eb4feee62/ 【程序员】专题拒稿指北：http://www.jianshu.com/p/7c8b33b5f63b 投稿须知： 1.收录相关技术文章，但不限于技术，也可以是项目经验类的文章和程序员日常。 2.文章內不得有任何推广信息。包括但不限于公众号、微博、微信，更不得在通过投稿后再修改文章加入推广信息。你可以将这些推广以及个人信息放在个人主页介绍里。 3.字数极少，段落混乱，大段代码没有放到代码框的文章不收录 4.不相关的内容不收录，请确认文章内容和本专题相关 目前针对优质作者及爱好者，开设了官方程序员微信群，希望加入请发简信给主编小彤花园索取个人微信，主编会将你加入到【程序员】微信群，分享内容，收获知识。添加微信时备注昵称。
