本笔记仅供自己以后复习使用,记录以前没接触过或者对自己有启发的知识点,并做一定的思考与拓展
1.C++编程简介
主要介绍C++的发展历史,这个以前自己就看过,因此不再赘述。
2.头文件与类的声明
- 头文件
为防止重复声明,头文件的防卫式声明格式如下:
#ifndef _COMPLEX_
#define _COMPLEX_
...//一些声明语句
#endif
头文件的基本布局格式如下:
#ifndef _COMPLEX_
#define _COMPLEX_
#include <cmath>
class ostream;
class complex; //前置声明
complex& _doapl (complex* ths, const complex& r);
class complex //类-声明
{
...
};
complex::function //类-定义
#endif //_COMPLEX_
思考与拓展:
为什么头文件要有防卫式格式?这个要从编译器如何对头文件进行预处理说起:
- 编译器将处理掉所有注释,以空格代替;
- 删除#define,展开所有宏定义;
- 处理条件编译指令#if、#ifdef、#elif、#else、#endif;
- 处理#include,展开被包含的头文件(直接将头文件复制进文件)
- 保留编译器需要使用的#progma指令等等。
是不是只有这一种防卫式声明呢?除了课程中出现的这种,还有另外一种格式:
#pragma once
...//一些声明语句
两者的差别:
#ifndef的方式依赖于宏名字不能冲突,这不光可以保证同一个文件不会被包含多次,也能保证内容完全相同的两个文件不会被不小心同时包含。当然,缺点就是如果不同头文件的宏名不小心“撞车”,可能就会导致头文件明明存在,编译器却硬说找不到声明的状况
#pragma once则由编译器提供保证:同一个文件不会被包含多次。注意这里所说的“同一个文件”是指物理上的一个文件,而不是指内容相同的两个文件。带来的好处是,你不必再费劲想个宏名了,当然也就不会出现宏名碰撞引发的奇怪问题。对应的缺点就是如果某个头文件有多份拷贝,本方法不能保证他们不被重复包含。当然,相比宏名碰撞引发的“找不到声明”的问题,重复包含更容易被发现并修正。
方式一由语言支持所以移植性好,方式二 可以避免名字冲突。
到底选哪一种呢,这是个兼容性和效率的问题。
3.构造函数
- 初始化列表
一个变量的数值设定有两个阶段:一个是初始化,一个是后面的赋值操作,而初始化列表就是在初始阶段。如果放入大括号里面来做,结果相同,但相当于放弃了初始化,效率会差一些。
- 构造函数放在private
class A
{
public:
static A& getInstance();
setup() {...}
private:
A();
A(const A& rhs);
...
};
A& A::getInstance()
{
static A a;
return a;
}
使用:
A::getInstance().setup();
对不改变数据内容,只是取出来的,加const
4.参数传递及返回值
- 参数传递:pass by value or pass by reference(to const)
pointer参数和reference参数的重要差异:传入的pointer可能为0,因此必须得先检查确定其值是否为0,而reference则必定会代表某个对象,所以不须做此检查
- 返回值传递return by value vs return by reference(to const)
一个函数的操作结果放在什么位置?如果必须创建一个位置供他放,那返回的就是新的local对象,这时候不能return by reference,因为local 变量,函数一结束就已经死亡了,这样就会出错。若放在函数某个位置,那就可以传递reference。
5.操作符重载
- 操作符重载-成员函数
- temp object临时对象
注意对于这些临时对象绝不可return by reference。因为它们是local object。
小结:
- 头文件防卫式声明;
- 构造函数的初始化问题;
- 数据尽量放在private里面;
- 传递参数:尽量用 pass by reference;
- 传递返回值:若不是local object,尽量用return by reference;
- 若是函数调用不用改变参数,则加上const;
参考文章
http://blog.csdn.net/huangyizhi/article/details/50760522?locationNum=4
http://www.cppblog.com/szhoftuncun/archive/2007/10/28/35356.html
http://blog.csdn.net/monroed/article/details/50710161