C和C++混用
Yes， C和C++混用的确是natural，毕竟绝大多数C++学习者都从C学起，C++兼容C就是为了降低学习门槛。但是C和C++混用却不一定是necessary。 我们把C和C++归为一类，通常写作C/C++，那是因为从语言角度讲C的问题就是C++的问题，但是反过来就不成立，因此具体到某个工程的时候，你在开工之前就必须决定到底使用C还是C++，或者说到底是面向过程还是面向对象。当然，上面两种说法都不正确，因为C并不一定就是面向过程，C++也并不一定就是面向对象。不过面向过程的设计已经不适应潮流了，因此准确的提问应该是：到底使用C风格（以函数为元素）的面向对象还是C++风格（以类为元素）的面向对象。 在系统设计阶段就必须确定设计风格，因为这很重要，关系到代码的样式、兼容性、可移植性，风格的选择依据就是你手头的库，看你手头上能够使用的库有哪些，以哪一个库为基准，以及开发进度要求，这些因素必须平衡考虑，不能顾此失彼。 如果只是开发一个小程序（就是类似那种用C++Builder或者Dephi可视化功能再加上一些控件组装出来的程序），那么把各个能够使用的库糅合起来就可以了。 如果是一个大的需要持久维护的工程，就必须考虑库与库之间的兼容性、效率、耦合度。所谓兼容性就是这个库的概念（包括你所知道的任何能够保存的量）能否传递给另外一个库直接使用；所谓效率，就是不能直接传递的概念是必须转换的，这个转换的花费是高还是低；所谓耦合度，就是当需求按照预期变化的时候（如果系统设计师没有考虑这一点的话，那么他应该下岗了）你能否轻松的转换接口或者库（接口是外部的，库是内部的）。 很显然，如果你直接把所有能用的库糅合起来的话，虽然兼容性和效率在绝大多数情况下符合要求，但是耦合度这一关就很难过了。当你发现某个库不能满足需求了，必须转换到另外一个库的时候，你就追悔莫及了。因此直接耦合肯定是不行的，必须转换接口和概念（接口是外部的，概念是内部的），类似于《Design Patterns》里面介绍的Adapter模式，许多读过这本书的人一定对基于接口的Adapter影响深刻，但似乎很少有人注意到包括Adapter模式在内的其他模式都可以适用于范型，而范型是内部概念转换的最好方法。 所以说，你在一个工程里面使用多个风格迥异的库完全可行，但是最好不要直接使用，要学会偷换概念或者通过分层设计以降低对外来代码（就是说不是你写的代码）的依赖性，同时还可以保证自己的代码风格一致。（STL把C标准库的函数inline到std名字空间下，VCL则把ST
相关文档：
http://msdn.microsoft.com/en-us/library/2e70t5y1(VS.80).aspx
#pragma
pack( n )
n : Valid values are 1, 2, 4, 8, and 16.the
alignment of a member will be on a boundary that is either a multiple of
n
or
a multiple of the size of the member
,
whichever is smaller.
......
转载请注明出处：编程笔记BLOG
工欲善其事，必先利其器。用了这么久的linux，现在比较主流的几个C/C++的IDE基本已都用过了，现在来对他们做一下简单的比较。
1、VIM
首先要说的是VIM。我认为，VIM只是一个编辑器，不能算是IDE。虽说VIM有很多插件，例如代码折叠、递进等，可以将VIM组建成几乎类似一个IDE，但始终它不是� ......
在netbeans中编辑C/C++是一种不错的选择，下面我就说一下整个流程的配置
1.先下载MinGW
这是编译c/c++的编译器，在windows下直接以.exe的方式运行，下一步的操作，一直到安装完成。
2.下载msys
这是和MinGW同步使用
3.配置环境
在我的电脑->属性->高级->环境变量中设置MinGW和msys目录中bin所在的路径
4.测试
用命令行方式� ......
