Lnmp yum 安装脚本 (for CentOS)
心情大好,给VPS升级了一下系统,然后自己配了LNMP安装脚本,用yum源安装的话更新比较方便点哈 这个过程挺麻烦啊,所以果断要记下来,以防以后要用到 如果是其他系统的话,几个配置路径和软件源地址还有yum指令替换掉,应该就可以了
心情大好,给VPS升级了一下系统,然后自己配了LNMP安装脚本,用yum源安装的话更新比较方便点哈 这个过程挺麻烦啊,所以果断要记下来,以防以后要用到 如果是其他系统的话,几个配置路径和软件源地址还有yum指令替换掉,应该就可以了
最近研究了一下ARM的交叉编译环境搭建,太麻烦了必须作一下记录啊。 前两个方法比较简单一点,关键是淫家Google帮你弄好了大部分功能
使用Android NDK的第一步当然是下载Android NDK啦。 http://developer.android.com/tools/sdk/ndk/index.html 使用jni的话,还必须下载相应的Android SDK http://developer.android.com/sdk/index.html 下载完后可以使用 $ANDROID_SDK_ROOT/sdk/tools/android update sdk –no-ui 来更新SDK包 附注:ANDROID_SDK_ROOT指代Android SDK根目录,NDK_ROOT指代Android NDK根目录。下同。 为了方便可以把$ANDROID_SDK_ROOT/sdk/tools:$ANDROID_SDK_ROOT/sdk/platform-tools:$NDK_ROOT 加到环境变量PATH里去 另外,Android 如果要命令行编译,需要ant和ant扩展,需要安装 Android 依赖的32位库 大致上是 glibc.i686 libzip.i686 libzip-devel.i686 libstdc++.i686 ant ant-* jdk 其中 libc.i686 libzip.i686 libzip-devel.i686 libstdc++.i686 ant ant-* 可以用 yum install或apt-get install 安装 jdk最好是官网下一个rpm包安装 rpm -ivh *.rpm
使用代码生成代码是一件十分美妙的事情,于是有了各种代码生成器。但是生成代码,意味着要有对生成规则的分析和处理。 Boost.Spirit 就是这么一个语法分析工具,它实现了对上下文无关文法的LL分析。支持EBNF(扩展巴科斯范式)。 Boost.Spirit 的使用真的是把模板嵌套用到了极致。确实这么做造成了非常强的扩展性,生成的代码也非常高效,但是嵌套的太复杂了,对于初学者而言真心难看懂。 你能想象在学习阶段一个不是太明白的错误导致编译器报出的几十层模板嵌套错误信息的感受吗?而且,这么复杂的模板嵌套还直接导致了编译速度的巨慢无比。 其实在之前,我已经使用过Spirit的Classic版本,即1.X版本,但是过多的复制操作让我觉得当时用得很低效,还好分析的内容并不复杂所以没。体现出来 这回就来研究下功能更强劲的2.X 版本。
C++确实是一门复杂的语言。包括之前查看了一些C++11的文档和做了一些实践和总结,越来越觉得C++是门神奇的语言,也是个陷阱多多的语言。 我现在开发过程中最主要使用的语言就是C++,所以了解C++的一些细节和问题非常重要,后来看到某大神的一篇文章《C++的坑多吗?》,激起了我专门去看一看关于C++的一些常见的设计方法和问题的书。就是刚才提到的文章里有说的《Effecitve C++》和《More Effecitve C++》 共90个条款,所以说是90个坑。
C++11的新标准已经出台,各个编译器已经开始陆续支持。 主流编译器支持程度见(VC++, gcc, clang, intel c++等):http://en.cppreference.com/w/cpp/compiler_support
但是要让C++11应用与生产环境还需时日,所以就在这里记录一下在过渡时期可能用到的一些重要功能
终于要离开学校了,终于有时间可以静下来看看之前导师推荐的书籍。之前有看到说《程序员修炼之道》是对程序员影响最为深刻的书, 就从它开始吧。用这个还算可以的音响听着音乐,看书很惬意啊。 顺便吐槽下京东,我买了本地有货的三本书,三天了我还没见到。这效率实在是fuck。 第一本书的第一章是电子版上看的,还好我有kindle。这里基本上说的是沟通方面的。我发现我的沟通确实有点问题,不太主动,表达含糊。之前只和ultramanhu交流比较多,可能是多年的默契吧,表达清楚意思不怎么费劲。现在的一起合租的xboy(和qboy很像啊),和他交流经常文不对题,开始我总以为他习惯岔开话题,但是后来发现在其他有些人身上也出现过这种问题。看来我的表达力确实有问题,一直说ben大神的表达力低下,其实他只是我这种更恶化一些罢了。不管怎么说,之前看到过个视频,我觉得很有道理,对世界的理解应该是 “知其然 — 知其所以然 – 知其知其所以然 – 知其知其所以然所以然”。别人也是属于世界的一部分,了解别人看待事物和自己不一样、了解别人看待事物的角度、了解别人为什么和自己看待事物的和自己不一样,都是自身对这个世界的理解。同样,自己要表述的意思让各种各种各样的人有理解并且有兴趣听也是自身表达能力的一种体现。Maybe,这就是我大学生活孑然一身(不完整啊)的原因吧。T_T “注重实效的哲学”,其中最重要的部分当属那个WISDOM离合诗了吧。
原文地址:http://www.cnblogs.com/MeteorSeed/archive/2012/08/04/2621993.html
狼是自然界中真正的掠食者,而哈士奇不过是人类的玩物。两者长得确实很像,就如同IT界的Programer和Coder。如果用狼和哈士奇来隐喻这两种职业,Programer无疑是软件业真正的狼。
这是我对C++新特性系统学习的最后一部分,之后就靠实践中再来看新标准的新特性啦。
在之前,我对这部分没太在意,直到看到了一篇文章 [http://blog.csdn.net/pongba/article/details/1659952](http://blog.csdn.net/pongba/article/details/1659952) 才意识到,C++的多线程操作也是个麻烦的问题。
简而言之,C++编译器在进行编译优化的时候,认为当前是单进程的,并且遵循**可观察行为**(Observable Behavior)不变的原则。就是说在可观察行为不变的情况下,操作是可以被改变顺序的,而单进程可观察行为不变,不代表在多进程的情况下仍然不变。还是上大牛的例子:
_**例子一:**_
| x = y = 0; | |
| 线程1 | 线程2 |
| if(x == 1) ++y; | if(y == 1) ++x; |
完全可以优化成
C++在效率上有个硬伤。我们知道C#和Java对于类传递都是以引用的方式,而C++默认都是传值。在传值过程中就经常会进行复制构造,这完全没必要而且浪费CPU,为了解决这种问题,于是乎C++11 增加了一个新的非常数引用(reference)类型,称为右值引用(R-value reference)。我就专门看了一下关于右值引用的东西。 右值引用在GCC 4.3之后开始支持,VS 2010(VC 10.0)已经支持,再前一点的VC版本没试过所以不知道。 右值引用的申明标记为T &&,主要用于处理临时变量,比如函数返回的变量(暂时想不出其他例子,忽略返回值优化吧,(命名)返回值优化参见http://efnetcpp.org/wiki/Return_value_optimization,再说返回值优化能力有限是吧,比要求如单返回语句、不能使用异常等等),避免复制构造。同时在析构的时候就不会析构这个临时变量,从而提升效率。 上代码:
之前用Google的Protobuf感觉真是个很好用的东西,于是抽时间研究了下他的数据的存储方式,以后可以扩展其他语言的解析器。其实与其说是研究,不如说是翻译。这些文档里都有,可能有些地方理解的不太对,还请见谅。
详见: Linux编译安装GCC 4.7
系统:
现在的web的js开发很方便啊,但是碰到iframe里的东西还是不方便看到变量的内容,所以就写了这么个看json内容的玩意,还可以当控制台输出用。
其实这个部分是我觉得最没用的部分
注:这部分仅测过GCC,VS暂不支持
在旧的标准C++中支持两种字符编码。
直接使用””将产生const char。
使用L””将产生const wchar。
这各部分主要是一些很实用和在一些地方帮助编译器自动推断类型的库和函数 首先是引用包装 类名 template< class T > class std::reference_wrapper; 这个类保存了对一个类实例、(成员)函数(指针) 构造时必须传入所引用的对象或引用对象的右值引用 主要方法有 =号操作符, 用于重新绑定引用对象 类型转换操作符, 用于转换为模板目标类的引用类型 get方法, 用于获取引用的对象 ()操作符, 用于执行引用的函数
绑定函数是我认为C++新标准里第二有用的库了 绑定库的使用环境是:
先来看一段代码
C++ STL终于会放点实用的东西了。可喜可贺。
这个,显然是正则表达式库,作为一个强大而又NB的库,我表示对其理解甚少,只能先研究下基本用法,更具体的用法要等实际应用中用到的时候在细看了。 PS:正则表达式的资料见 http://www.regexlab.com/ 更多资料见 https://www.owent.net/2011/264.html