时间:2014.05.27
地点:基地
---------------------------------------------------------------------------------------
cin和cout的类型是std::istream和std::ostream 。这两个类型又分别对应着
std::basic_istream<char> std::basic_ostream<char>即,是分别是这二者typedef后的别名而已,当然,这里省略的模板的默认参数,完整来说是:
std::basic_istream<char,std::char_traits<char>> std::basic_ostream<char,std::char_traits<char>>
流的rdbuf()成员函数返回某个流对象说使用的streambbuf指针,该指针直接指向流底层使用的streambuf,正如前面一篇博文所说,绕过上层直接操作流的底层非常高效。另外,我的操作符operator<<()也接受这样一个指向streambuf的指针,于是对于某些操作,就像把一个池子的水端起来直接倒往另外一个水池一样,比起架起水管来让细水漫流是不是很爽?
---------------------------------------------------------------------------------------
假设我们要写一个ECHO程序,简单的相应输入,能从cin获得输入,然后将输出发送到cout,也能从一个名为infile的文件获得输入,输往outfile文件。
有一条设计准则:
尽量提高可读性,避免撰写精简代码,避免晦涩。因为简洁代码难以理解和维护。
还有一条设计准则
尽量提高可扩充性
通过分析,我们知道,从获取输入到输出这个过程中,我们还可能要对数据进行一些处理,比如将字符进行大小写转换,删除一些字符,字符统计等,因此,我们需要将这一任务独立出来。
于是又有一条设计准则:
尽量提高封装性,将关系分离。
先来看整个程序框架:
int main(int argc, char* argv[]) { using namespace std; fstream in, out; if (argc > 1) in.open(argv[1], fstream::in, fstream::binary); if (argc > 2) out.open(argv[2], fstream::out | fstream::binary); Process(in.is_open()?in:cin,out.is_open()?out:cout); return EXIT_SUCCESS; }现在的问题是怎么去实现Process函数,我们将处理数据的任务交付给它,它应该能够处理不同的参数类型,我们想到的是多态,C++中有四种方式可获得多态行为:虚函数,模板,重载,转换。
通过模板实现多态也叫编译时多态,提供有被传递对象的合适接口,实现如下:
template<typename In, typename Out> void Process(In& in, Out& out) { ....一些数据处理, //或者只是简单的这样:out << in.rdbuf(); }
通过虚函数的方式的多态也叫运行时多态,它声明的参数类型是一个具有可能的接口们对应的公共基类即可。比如一种可能的实现如下:
void Process(basic_istream<char>& in,basic_ostream<char>& out) { //...执行某些操作 //或者只是这样 out<<in.rdbuf(); //把一池子水直接倒入另外一个池子 }这种方式具有一定的依赖性,它要求输入和输出必须分别从basic_istream<char>和basic_ostream<char>派生。(我们的istream,ostream,iostream,ifstream,ofstream,stringstream等都分别从二者派生而来,可如果不是呢,比如宽字符流是基于wchar_t的。或者有些流有着用户自定义的traits。于是为了提高可扩充性,应该使用模板,让编译器去推导这些合适的参数
template<typename C,typename T> void Process(basic_istream<C,T>& in,baise_ostream<C,T>& out) { ...... }
---------------------------------------------------------------------------------------
避免写出来的代码只能解决当前问题,几乎任何时候若能写出可扩充的方案,都是更好的选择。但在编写专用代码只解决当前问题(短视,难以扩充)和编写一个宏大的通用框架去解决本来很简单的问题(追求过度设计)之间要自己琢磨取得最佳平衡。第一种方法简单而灵活,更能适应新要求,没有束缚,不仅仅只能和iostream体系打交道。在函数或类的设计中,我们应该尽量考虑可扩充性。稍微多去思考下,当前正在解决的问题是不是某个更通用问题的特例,于是应该还多做一点工作,而不要仅仅满足于当前。
原文地址:http://blog.csdn.net/u012333003/article/details/27197693