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
    ........
  };
  如果没有事先告诉编译器该友元是一个模板,则编译器将认为该友元是一个普通的非模板类或非模板函数。

 

 

 

Effective C++ (3rd Ed) 读书笔记(一)Item 2: Prefer constS, enumS, and inlineS to #defineS

#includecxvxv

effective C++ Item 2: Prefer consts, enums, and inlines to #defines

前面一款基本上就是介绍性的内容,这一节进入主题。   条款二:尽量以const,enum,inline代替#define   1:使用const代替#define定义常量。     如果你定义圆...

Effective C++(Item1) Prefer const and inline to #define

1 compare const and #define   This can be called perfer the compiler(编译器) to the preprocessor(预处理器)...

<Effective Mordern C++>笔记:Item 5:Prefer auto to explicit type declarations.

很多时候我们定义一个变量,都是直接的int x;根据编译器的不同,没有初始化的变量往往会有不同的未定义结果,进而产生各种各样的问题,在《Effective C++》中也有建议要养成初始化变量的习惯,使...
  • cqk0100
  • cqk0100
  • 2017年05月06日 15:56
  • 163

<Effective Mordern C++>笔记:Item 9:prefer alias declarations to typedefs.

转载自原博:原博 C++11中引入的std::unique_ptr智能指针是个好用的东西,在我们使用unique_ptr的时候往往会写出这样的类型std::uniqeu_ptr,看上去很臃肿,因此大多...
  • cqk0100
  • cqk0100
  • 2017年05月11日 19:43
  • 148

Effective C++(Item3) Prefer new and delete to malloc and free

string* stringArray1 = static_cast(malloc(10*sizeof(string))); string* stringArray2 = new string[10...

Effective C++,rule 2,Prefer const,enum and inlines to #define

前言rule2主要讲的是#define相关的一些东西,由标题可知,这里说的是#define的在某些方面的不足以及一些可行的建议。另外,本节一个重要的内容就是enum hack技术。enum hack ...
  • jmh1996
  • jmh1996
  • 2017年04月27日 01:07
  • 196

Effective Objective-C 2.0:Item 48: Prefer Block Enumeration to for Loops

Item 48: Prefer Block Enumeration to for Loops Enumerating a collection is a very common task in ...

Effective Objective-C 2.0: Item 4: Prefer Typed Constants to Preprocessor #define

Item 4: Prefer Typed Constants to Preprocessor #define 曾经面试被被问到 Preprocessor #define 有什么缺点, 这篇文章很...

Effective Objective-C 2.0: Item 41: Prefer Dispatch Queues to Locks for Synchronization

Item 41: Prefer Dispatch Queues to Locks for Synchronization Sometimes in Objective-C, you will com...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:effective C++ (Item2) Prefer <iostream> to <stdio.h>
举报原因:
原因补充:

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