编译程序

https://my.oschina.net/u/728245/blog/184550 摘要: GCC 4.8.2 在 CentOS 6.5 下编译安装小记，遇到一些问题并解决。 以前从没有升级过GCC，一直用系统默认的GCC版本，最近在研究好久没有用过的 C， 便有了升级GCC的想发，大致如下。 环境： CentOS-6.5-i386 , gcc-4.4.7 系统必须已经安装有一个编译器，因为 gcc 也是需要编译的 首先 gcc 编译需要三个额外库，下载并按照下面的顺序安装它们，如下: 1. gmp ftp://ftp.gnu.org/gnu/gmp 2. mpfr ftp://ftp.gnu.org/gnu/mpfr 3. mpc http://www.multiprecision.org/mpc 1. 编译安装 gmp # tar -zxvf gmp-5.1.3.tar.gz # cd gmp-5.1.3 # ./configure # make && make install 2. 编译安装 mpfr # tar -zxvf mpfr-3.1.2.tar.gz # cd mpfr-3.1.2 # ./configure # make && make install 3. 编译安装 mp c # tar -zxvf mpc-1.0.tar.gz # cd mpc-1.0 #

模版引擎XTemplate是一个仿T4设计的引擎，功能上基本与T4一致（模版语法上完全兼容T4，模版头指令部分兼容）。 自己设计模版引擎，就是为了代码生成器、网站模版、邮件模版等多种场合，也就是要能拿出来单独使用、功能强大并且容易控制的。T4是个很好的引擎，但是它的设计基本上倾向于vs，几乎不顾别的场合。 XTemplate特点如下： 1，完全使用C#作为模版语言。跟ASP、ASP.Net页面的解析一样，把<##>标签外的文本内容当作字符串，用一个StringBuilder，标签内作为C#原生代码，拼在一起编译，进行模版替换时，实质上就是执行编译后的程序集，这就是XTemplate的核心原理！网络上现有的许许多多模版引擎，要么采用标签替换，要么自创模版语言，这些都增加了使用者的学习难度。XTemplate使用C#作为模版语言，这个世界安静了！ 2，支持“调试”。不是运行时调试，而是XTemplate能够把模版编译的中间类文件以及程序集等输出，方便检查错误。如果把模版编译后的程序集保存下来，可以在没有模版文件的情况下直接使用模版功能。 3，不需要ASP.Net支持。有部分模版引擎，是模拟一个ASP.Net服务器，然后以ASP.Net作为模版来实现，这就要求有一个ASP.Net服务器作为宿主，限制了模版引擎的使用范围。 4，支持批量编译。可以把多个模版放入模版处理器，进行一次编译

$ pip install future 安装PyInstaller之前需确认首先安装了pywin32 下载地址： http://nchc.dl.sourceforge.net/project/pywin32/pywin32/Build%20218/pywin32-218.win32-py2.7.exe PyInstaller安装 1 下载地址：http://www.pyinstaller.org/wiki 2 最新版本：PyInstaller 2.0 3 直接“解压缩”之后即可使用，解压到您想让他在的路径即可 PyInstaller配置 1 事先写好py程序 2 在命令行执行： Python Makespec.py --console --onefile NotePad\notepad.py 报错：Configfile is missing or unreadable. Please run Configure.py before building 3 在命令行执行：Configure.py 报错：Python 2.6+ on Windows support needs pywin32，Please install http://sourceforge .NET /projects/pywin32/ 4 安装最新版本的 pywin32-217.win32-py2.7.exe

1、学习时遇到的问题 在学习Makefile时，首先是对其的语法不太了解，造成对项目的Makefile文件阅读很吃力；其次是在寻找资源上，着实的浪费了很大的精力；最后就是对makefile的工作原理一知半解，导致走了很多弯路。 下面我将自己对Makefile的理解和认为好的资料分享给大家，希望大家在接触它时，可以少走弯路。 2、为什么需要Makefile 1、在大型的项目中，源文件和目录不计数，文件间的依赖关系及其所在路径非常复杂； 2、文件间的编译顺序，哪些需要先编译，哪些需要后编译，哪些需要重新编译，我们不能通过简单的编译命令来完成； 3、当我们仅仅修改了部分文件的代码，我们不能通过只编译更新过的文件来更快的完成编译或者说是模块化编译。 这些问题，Makefile都可以解决， 一旦写好，只需要一个make的命令，整个工程就会完全自动编译，极大的提高了软件开发的效率。 3、Makefile是什么 可以理解为一种自动化编译的工具，里面 包含了整个工程项目的编译规则 ，并且可以将项目分成 多个模块进行分别编译 ，而且里面可以 包含执行操作系统的命令 。当我们需要编译代码时，只需要一个命令就可完成整个工程项目的编译或者某个模块的编译。 4、 Makefile的工作原理 大家都编译过工程项目，对 编译过程 应该了解， 简单说就是： 源文件首先会生成中间目标文件

1 手动编译链接 我们知道源文件生成可执行文件的过程可能需要一些依赖文件（头文件或者其他源文件）。[2]中提到对于C语言，产生可执行程序包括这样的步骤： 1 预处理源文件（.c） 替换预处理命令（如 #define） 展开头文件（.h，包括静态链接库的头文件）到引用的源文件 2 依次编译处理过的源文件，然后进行汇编，生成对应的目标文件（.o） 3 链接（静态链接）目标文件和静态链接库（静态链接库的源文件生成的目标文件，.a），生成可执行的二进制文件。 我们假设这里有三个c文件： hello.c #include<stdio.h>//sys lib head file int main() { int a=33; int b=22; printf("Min value is %d\n",min(a,b)); printf("Max value is %d\n",max(a,b)); return 0; } max.c int max(int a,int b) { return a>b?a:b; } min.c int min(int a,int b) { return a<b?a:b; } 很明显，hello.c编译必须依赖max.c和min.c。我们手动编译生成可执行文件，并执行： fsj@ubuntu:~/templates$ ls hello.c max.c min.c fsj

C语言中 *.c和*.h文件的区别！ http://blog.163.com/jiaoruijun07@126/blog/static/68943278201042064246409/ 这是HR面试我的一道题，没技术上含量，不过细想起来，还是C语言的最基本的知识！俗话说，目标决定动力，细节决定成败！ C文件就是C语言系列的源文件，而H文件则是C语言的头文件，即C系列中存放函数和全局变量的文件，因为C中的函数是被封装起来的,即无法看到其代码。 子程序不要定义在*.h中。函数定义要放在*.c中，而*.h只做声明.否则多引用几次，就会发生函数重复定义的错误。*.h只做声明，编译后不产生代码。这样做目的是为了实现软件的模块化，使软件结构清晰，而且也便于别人使用你写的程序。 纯粹用 C 语言语法的角度，你当然可以在*.h 中放任何东西，因为 #include 完全等价于把*.h 文件 Ctrl-C Ctrl-V 到*.c 中，*.h 中应该都是一些宏定义和变量、函数声明，告诉别人你的程序“能干什么、该怎么用”。*.c 中是所有变量和函数的定义，告诉计算机你的程序“该怎么实现”。当然，如果一个*.h 被多个*.c 包含，而且*.h 中有对象（变量或函数）的定义，就会发生重复定义的错误了，声明可以无穷多次，定义只能一次。 一般来说，一个C文件应该是一个模块，如果你的程序仅仅有一个模块

阅读了《 单片机 与 嵌入式 系统应用》2005年第10期杂志《经验交流》栏目的一篇文章《Keil C51 对同一端口的连续读取方法》(原文)后,笔者认为该文并未就此问题进行深入准确的分析 文章中提到的两种解决方法并不直接和简单。笔者认为这并非是Keil C51中不能处理对一个端口进行连续读写的问题,而是对Kei1 C51的使用不够熟悉和设计不够细致的问题,因此特撰写本文。 本文中对原文提到的问题,提出了三种不同于原文的解决方法。每种方法都比原文中提到的方法更直接和简单,设计也更规范。(无意批评,请原文作者见谅) 1 问题回顾和分析 原文中提到：在实际工作中遇到对同一端口反复连续读取,Keil C51编译并未达到预期的结果。原文作者对C编译出来的汇编程序进行分析发现,对同一端口的第二次读取语句并未被编译。但可惜原文作者并未分析没有被编译的原因,而是匆忙地采用一些不太规范的方法试验出了两种解决办法。 对此问题,翻阅Keil C51的手册很容易发现：KeilC51的编译器有一个优化设置,不同的优化设置,会产生不同的编译结果。一般情况缺省编译优化设置被设定为8级优化,实际最高可设定为9级优化： 1. Dead code elimination。 2.Data overlaying。 3.Peephole optimization。 4.Register variables。 5

作为Python爱好者，需要了解.py脚本的基本运行机制及特性： 在很多工作上Python的运行流程基本上取决于用户，因此源码不需要编译成二进制代码（否则无法实现大部分贴近用户的特性），而直接从源码运行程序。当我们运行python文件程序的时候，Python解释器将源码转换为字节码，然后再由解释器来执行这些字节码。 因此总的来说，它具有以下三条特性 源码距离底层更远（根据官方文档的解释。不说，你们也感觉得到。） 运行时都需要生成字节码，交由虚拟机执行。（你们问我虚拟机在哪儿？！你们也不看看各自都是用什么软件执行的！没错，就是解释器，别和我说是IDLE啊。虚拟机具体实现了由switch-case语句构成的框架函数PyEval_EvalFrameEx，刚刚说的字节码就是这货执行的。） 每次执行脚本，虚拟机总要多出加载和链接的流程。（所以呢，相比于编译型语言就有点慢了。这与“有丝分裂间期”一样，准备东西也要花时间啊！） 那么，有人要问了：“不是说，运行时总要生成字节码么！那，字节码都去哪儿了？” 咳咳，别急！容我先说说，虚拟机它是怎么执行脚本的： 完成模块的加载和链接； 将源代码翻译为PyCodeObject对象（这货就是字节码），并将其写入内存当中（方便CPU读取，起到加速程序运行的作用）； 从上述内存空间中读取指令并执行； 程序结束后，根据命令行调用情况（即运行程序的方式

SFINEA in C++ 作者：唐风 出处： http://www.cnblogs.com/liyiwen 本文版权归作者和博客园共有，欢迎转载，但请保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。 SFINAE(substitution failure is not a error) 主要用于模板函数，它是指，编译器在使用具体类型来替换模板类型参数，对模板进行实例化（展开模板）时，如果发生替换失败，那么并不会直接引发编译错误（Error），而只是简单地把这个模板从重载候选者中去除掉。 还是看看代码吧（一个在SFINAE中常遇到的例子）： 代码段1： template <typename T> bool is_class(int T::*) { return true; } template <typename T> bool is_class(...) { return false; } struct Test { }; int main(void) { std::cout<<is_class<Test>(0)<<endl; std::cout<<is_class<int>(0)<<endl; } 运行的结果是输出： 1 0 这表明，如果传给 is_class 的模板参数是一个类，那么返回 true 的那个版本就会被选中

　　刘未鹏(pongba) /文 　　 　　看起来只是在C++后面多写了一个“/CLI”，然而其意义却远不止于此，google的c++.moderated版上为此还发起了数星期的讨论，在国内大部分人对C++/CLI还不是很了解的情况下，google上面已然硝烟四起... 　　就像我们作出其它任何选择一样，在选择之前最重要的是先要清楚为什么作出这样或那样的选择——C++/CLI到底提供了哪些优势？为什么我们（标准C++程序员）要选择C++/CLI而不是C#？我们能够得到什么？CLI平台会不会束缚C++的能力？ 　　这些都是来自标准C++社区的疑问。从google上面的讨论看来，更多来自标准C++社区的程序员担心的是C++/CLI会不会约束标准C++的能力，或者改变标准C++发展的方向，也有一部分人对C++/CLI的能力持怀疑态度。另外一些人则是询问C++/CLI能够带来什么。 　　这些被提出的问题在google上面一一得到了答案。好消息是：情况比乐观的人所想象的或许还要更好一些—— 　　世界改变了吗？ 　　对于谙于标准C++的程序员来说，最为关心的还是：在C++/CLI中，世界还是他们熟悉的那个世界吗？在标准C++的世界里，他们手里的各种魔棒——操作符重载|模板|多继承（语言），STL|Boost|ACE（库）——还能挥舞出五彩缤纷的火焰吗？是不是标准C++到了