O2是什么意思看清楚是O不是0噢
-O2表示优化选项，2表示最优优化，即编译器会优化你的程序；-o表示后边接的是文件名称；$@是Makefile的通配符，代指你前面指定的文件名，例如有规则%.o:%.c，那么$@表示xxx.o文件(xxx是你的源代码文件的名称前缀)；$<表示搜索到的第一个匹配的文件，对于规则%.o:%.c，$<表示第一个找到的.c文件。简而言之，假设在一个文件夹下有若干.c文件，那么下面的规则：%.o:%.c<TAB>gcc-O2-o$@$<#<TAB>表示Tab键表示把所有的.c文件编译成中间.o文件。
make用法do与todo区别
不存在makesbtodo的用法。在主动语态中，正确的用法是makesbdosth.在被动语态中，正确的用法是sbbemadetodo
makesb.dosth.使/让/叫某人做某事。在主动语态里，使用省略to的动词不定式作宾语补足语。但是在被动结构中，要加上不定式符号to，即要使用不定式作宾语补足语，sb.bemadetodosth
make为使役动词，在主动语态中，后面跟省略to的不定式作宾语补足语。类似的单词有let,have等，句式为：make/let/havesbdosth,意为“让某人做某事”
例如：Healwaysmakesmelaugh.他总是让我笑。
make在被动语态中，则需要还原省略的to,句式为sbbemadetodo.意为“让某人做”，例如：
Hewasmadetowaitintheclassroom.让他在教室里等着。
makesbdone，意为某人被动地完成了某一动作。
例如：Hismothermadehimstayedathome.他妈妈让他留在了家里。
makesthdone,意为让别人帮助完成某事。
例如：Shemadeherhaircut.她理发了。
更多用法:
makesbdosth和makesbdone区别
makesbdone.考察make的使动用法。意思是使某人被。。。
makesb.do.考察do表“主动用法。意思是，主语叫某人做某事
举例说明：被动：Mike'smothermadehimstayedathomebecauseitwasrainingheavily
Mike呆在家里不是自愿的，所以是被他妈妈留在家里的(一定注意这时的主语是Mike'smother，而不是Mike，所以用被动)
主动：Thebossmadetheworkersdotheworkallday.
老板迫使工人们整天干活。
现在学习编程，学什么语言比较好
程序语言大部分都是各有长短的
c语言硬件开发的比较多
java开发后台网站是主力
python目前的方向是数据挖掘和分析还有爬虫
个人推荐的话还是java，什么跨平台，安全，面向对象之类的就不说了
最大的感触就是应用广，社区活跃。
比如你有一个问题需要解释方案，去网上搜索会发现java已经有很多的开源项目能解决你的问题了。
当然python也有后来居上的趋势，至于c，如果你没有很强的毅力去深挖的话，还是不要选比较好（不过可以做为入门语言了解一下）
用什么软件写makefile
可以用任何文本文件编辑，用得顺手就行，保存纯格式，不能是富文本。
而且文本编辑器不能随意自动更改，格式化，比如把TAB制表符改为空格，会破坏makefile，因为这些制表符在makefile中有特殊含义。
^是什么意思
^，中文尚无通用名称，可以是乘方、插入符号、插入符、脱字符号[1]等；英文称为caret(英语发音：/?k?r?t/)，是个倒V形的字素。说得明白一点，^就是ASCII码位5Ehex或其他字符集称为帽子(hat)、控制符(control)又或上箭头(uparrow)的移格字符。
为什么C++没有Python那么多开源库
为什么C++没有Python之类语言这样活跃的生态？我觉得根本原因在于C++没有解决好一个问题：菱形依赖
什么叫菱形依赖呢？就是说A依赖B，A也依赖C，但是B和C同时依赖D，并且我们限定D并不是STL这样的标准库，BCD都是开源库。为了限定到C++，我们这里BCD都是C++库，采用源码的方式发布。
这种情况在生态活跃的语言中则是非常常见的。
在C++当中会怎样呢？
B和C中至少一个将D的源码合并到了自己的源码里面，放到thirdparty之类的目录里面。A将两份源代码加自己的一起放到thirdparty里面，编译，符号冲突，爆炸。B和C在install说明中提到，必须把依赖放到某个地方，然后修改Makefile/CMAKE/Bazel配置，将D的源码目录加进来。结果B和C编译出来的.a里面还是带着D的全部符号，A尝试二进制链接，符号冲突，爆炸。B和C在install说明中提到，需要将D的依赖放在某个地方，先编译成.a，设置好参数直接链接.a。但是B和C要求的D的编译参数不一样，链接不到一起，爆炸。把所有的依赖都一个一个放在独立的位置上，设置好include目录，每个都用自己的Makefile独自编译成.a，编译参数用同一套，最后再一个一个指定起来链接到一起——人工成本爆炸。A希望B和C通过动态链接方式连接，方便升级。动态链接库里面链接了D的符号，加载起来符号冲突，爆炸。B和C一个动态链接了D，一个静态链接了D，还是符号冲突，爆炸。D把自己改成了headeronly的库，终于不需要单独编译了。B和C在引用D的时候设置的宏不一样，导致编译出的弱符号不兼容，链接完运行崩溃，爆炸。以上种种，最后对于C++库的作者来说，就变成了这样一个结果：
如果我要提供一个好用、好编译、不给我天天找事情的库，那么我不能引用其它的开源库
没有比这更矛盾的事情了，要造轮子，第一件事情是不能用别人的轮子。但是如果你要正经开发一个系统，你能保证自己不会有一天需要把这个代码重构成一个通用的库吗？那你就得从第一天开始避免用第三方开源库……
在Linux上面唯一有点生态的意思的做法，是引用yum/apt源里面的xxx-dev这样的库，这些库通过pkgconfig的方式组织，而且通过包管理系统保证大家下载到的都是相同且兼容而且编译好了的二进制库，引用起来很方便。但是，只有把接口限定到纯C才能发布确保二进制兼容的库，那折腾了半天，就算内部是C++开发的，一到库的边界上还得转成纯C，也就失去了C++语言的优势了。
