effective C++ (Item2) Prefer <iostream> to <stdio.h>

原创 2011年11月03日 23:52:00

  type safety and extensibility are cornerstones of the C++ way of life.

 int i;

Rational r;

cin >> i >> r;

cout << i << r;

if this code is to compile, there must be functions operator >> and operator << that can work with an object Rational.if these functions are missing,it's an error;

there are some situations in which it may make sense to fall back on the tried and true

first  some implementation of iostream operations are less efficient than the corresponding c stream operations;

Second the iostream library was modified in some rather fundamental ways during the course of its standardization,so applications that must be maximally portable may discover that different vendor support different approximations to the standard

Third because the classes of the iostream library have constructors and the function in <stdio.h> do not,there are rare occasions involving the initialization order of static objects when the standard c library may be more useful simply because you know that you can always call it with impunity


There is no such things as <iostream.h>,the standardization commitee eliminated it in favor of <iostream> when they truncated the names of the other non-c standard header names

if your compiler support both <iostream> and <iostream.h>,the header are subtle different,in particular, if you #include<iostream>,you get the elements of iostream library ensconced within the namespace std;but if you #include<iostream.h>,you get those same elements at global scope,Get them at global scope can lead to name conflicts,precisely the kinds of name conflicts the use of namespace is designed to prevent,besides,<iostream> is less to type than <iostream.h>. 

 

 

appendix:类模板中得友元声明
在类模板中可以出现三种友元声明,每一种都声明了与一个或多个实体的友元关系
1 普通非模板类或函数的友元声明,将友元关系授予明确指定的类或函数
2 类模板或函数模板的友元声明,授予对友元所有实例的访问权
3 只授予对类模板或函数模板的特定实例的访问权的友元声明
1 普通友元
非模板类或非模板函数可以是类模板的友元
    template <class Type> class Bar
    {
             .........
            friend class Foobar;
            friend  void fcn();
     }
这个声明是说,FooBar的成员和fcn函数可以访问Bar类的任意实例的Private成员和Protected成员
2 一般模板友元关系
友元可以是类模板或函数模板
template <class Type >  class Bar
{
    template<class T> friend class Fool;
    template<class T> friend void temp1_fcn1(const T& );
   ...........
}
这些友元声明的使用与类本身的类型形参,该类型形参指的是Fool和temp_fcn1的类型形参,在这两种情况下,都将
没有数目限制的类和函数设为Bar的友元,Fool的友元声明是说,Fool的任意实例都可以访问Bar的任意实例的私有元素,
类似地,temp1_fcn1的任意实例可以访问Bar的任意实例。
这个友元声明在Bar与其友元Fool和temp1_fcn1的每个实例之间建立一对多的映射。对Bar的每个实例而言,Foo1和Temp1_fcn1的
所有实例都是友元
3 特定的模板友元关系
类也可以只授予对特定实例的访问权
template <class T> class Foo2;
template <class T> void temp1_fcn2(const T&);
template <class Type> class Bar
{
    friend class Foo2(char*);
 friend void temp1_fcn2(char* const &);
 ........
};
即使Foo2本身是类模板,友元关系也只扩展到Foo2的形参类型为char*的特定实例,类似的,temp1_fcn2的友元声明是说,
只有形参类型为char*的函数实例时Bar类的友元,形参类型为char*的Foo2和temp1_fcn2的特定实例可以访问Bar的每一个实例。

下面形式的友元声明更为常见
 template <class T> class Foo3;
 template <class T> void temp1_fcn3(const T&);
 template <class Type> class Bar
 {
     friend class Foo3(Type);
  friend void temp1_fcn3<Type> (const Type&);
  ..........
 }
 这些友元定义了Bar的特定实例与使用同一模板实参的Foo3和temp1_fcn3的实例之间的友元关系,每个Bar实例有一个相关的Foo3和temp1_fcn3
 友元
 Bar <int> bi;      Foo3<int> and temp1_fcn3(int) are friends;
 Bar <string> bs;   Foo3<string> and temp1_fcn3(int)are friends;
 只有给定Bar实例相同模板实参的那些Foo3或temp1_fcn3版本是友元,因此Foo3<int> 可以访问Bar<int>的私有部分,但不能访问Bar<string>
 或任意其他Bar实例的私有部分。
 
 4 声明的依赖性
 当授予对给定模板的所有实例的访问权的时候,在作用域中不需要存在该模板或函数模板的声明。实质上,编译器将友元声明当做类或函数的声明对待
 想要限制对特定实例化的友元关系时,必须在可以用于友元声明之前声明类或函数:
  template <class T> class A;
  template <class T> class B
  {
       friend class A<T>  // ok A is known to be a template
    friend class C;     // ok,C must be an ordinary nontemplate class;
    template class <class S> friend class D; // OK D is a template
    friend class E<T>;  //error    E wasn't declared as a template
    friend class F<int> // error   F wasn't declared as a template
    ........
  };
  如果没有事先告诉编译器该友元是一个模板,则编译器将认为该友元是一个普通的非模板类或非模板函数。

 

 

 

c++头文件:stdio.h ,cstdio ,iostream ,bits/stdc++.h

关于c++头文件   看到计蒜课里c++课程里用了这些头文件,并不懂什么意思,于是百度得出结果= - =   首先,stdio.h是c语言主要的一个头文件,是指 “standa...
  • caotsinghua
  • caotsinghua
  • 2016年02月29日 16:38
  • 685

iostream和iostream.h和stdio.h的区别

#include 非标准输入输出流 #include 标准输入输出流 C++中为了避免名字定义冲突,特别引入了“名字空间的定义”,即namespace。 当代码中用时,输出可直接引用cout //...
  • qqyuanhao163
  • qqyuanhao163
  • 2015年07月04日 23:01
  • 2410

尽量用<iostream>而不用<stdio.h>

是的,scanf和printf很轻巧,很高效,你也早就知道怎么用它们,这我承认。但 尽管他们很有用,事实上scanf和printf及其系列还可以做些改进。尤其是,他们 不是类型安全的,而且没有扩展...
  • mbxc816
  • mbxc816
  • 2012年01月24日 21:59
  • 5395

条款2:尽量用<iostream>而不用<stdio.h> [effective C++ 学习笔记]

简而言之,这个属于C语言的头文件,在使用的时候,需要很明确所要操作变量的类型,这无疑会增加很多风险,因为一开始的时候,可能定义的这个属于int型,但是后期的需求变更或者异常的数据传入时,这个数据可能会...
  • sky200543012
  • sky200543012
  • 2015年01月29日 10:53
  • 709

解决方法:关于问题 "C++ - Unresolved inclusion: <iostream>"

问题描述用 eclipse for c++ 和CDT插件及编译工具MinGW开发C++程序,在C++源程序头部写#include #include 等此类标准库时,编辑器会提示:Unresolved...
  • tyhj_sf
  • tyhj_sf
  • 2016年07月12日 20:42
  • 2660

Effective C++ 2e Item2

 条款2:尽量用而不用是的,scanf和printf很轻巧,很高效,你也早就知道怎么用它们,这我承认。但尽管他们很有用,事实上scanf和printf及其系列还可以做些改进。尤其是,他们不是类型安全的...
  • lostmouse
  • lostmouse
  • 2001年06月29日 11:35
  • 771

解决NDK无法解析<iostream>的方法

NDK之所以无法解析是因为ndk使用的c++库是bionic。这个库几乎包含了所有c标准库,但是只包含了一个c++的轻量库,这里面没有。要想加载就必须加载c++标准库,我们分3个步骤完成:      ...
  • supergissss
  • supergissss
  • 2014年12月20日 00:32
  • 753

Effective C++ Item2

用const enum inlines 取代 #define 这个 Item 改名为“用 compiler(编译器)取代 preprocessor(预处理器)”也许更好一些,因为 #...
  • extend_die
  • extend_die
  • 2015年08月31日 17:23
  • 191

Item2: Prefer C++-style casts

从C过度到C++,总有些地方会不适应
  • lw2406
  • lw2406
  • 2014年07月05日 13:16
  • 134

eclipse - unresolved inclusion: <stdio.h> ???

在linux 上安装eclipse上配置好cdt后,新建项目时,当查找头文件时, 却出现如下错误提示: unresolved inclusion: 这是c/c++标准库未设置所致。 ...
  • xiaofan086
  • xiaofan086
  • 2012年12月08日 10:46
  • 29507
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:effective C++ (Item2) Prefer <iostream> to <stdio.h>
举报原因:
原因补充:

(最多只允许输入30个字)