iostream與iostream.h的差別具體解析。本站提示廣大學習愛好者：（iostream與iostream.h的差別具體解析）文章只能為提供參考，不一定能成為您想要的結果。以下是iostream與iostream.h的差別具體解析正文
C++的尺度類庫被修訂了兩次，有兩個尺度 C92和C99,這兩個庫如今都在並行應用，用 .h 包括的是c92 ，不帶 .h 的是c99的頭文件，關於通俗用戶來講這二者沒有甚麼差別，差別是在外部函數的詳細完成上。舊的C++頭文件是官方明白否決應用的，但舊的C頭文件則沒有（以堅持對C的兼容性）。聽說從 Visual C++ .NET 2003 開端，移除舊的 iostream 庫。其實編譯器制作商不會停滯對客戶現有軟件供給支撐，所以在可以估計的未來，舊的C++頭文件還會猖狂一段時光。假如能明確字符串頭文件的應用，觸類旁通，其他的也差不多會用了:
<string.h>是舊的C/C++頭文件，對應的是基於char*的字符串處置函數；
<string>是包裝了std的C++頭文件，對應的是新的strng類；
<cstring>是對應舊的C頭文件的std版本。
假如編譯器都同時支撐< iostream >和< iostream.h >，那應用#include < iostream >，獲得的是置於名字空間std下的iostream庫的元素；假如應用#include < iostream.h >，獲得的是置於全局空間的異樣的元素。在全局空間獲得元素會招致名字抵觸，而設計名字空間的初志恰是用來防止這類名字抵觸的產生。
想象訊雷下載軟件一樣，先從辦事器肯定下載文件的年夜小，初始時即保留文件，全體填充0，多個線程下載數據直接寫入文件，對本身線程擔任下載的那段文件片的0停止改寫，個中就觸及到文件同享寫的操作
湧現的成績時：
vc7.1<fstream> 曾經不支撐 filebuf::sh_read等症結字，不知在vc7下若要用文件流來對文件停止非獨有讀和寫操作該若何完成？
而：
vc6.0中的iostream.h <fstream.h>
filebuf::sh_read
filebuf::sh_write
filebuf::sh_note
filebuf::sh_openprot
不管本身是用vc6或許vc7的IDE
當用到尺度的輸出輸入和文件流時都是：
include<iostream>
include<fstream>
using namespace std;
有兩種用法：
A:
include<iostream.h>
include<fstream.h>
B:
include<iostream>
include<fstream>
A是尺度用法，B是老式用法。
假如用了<iostream>，則必定要引入定名空間，即"using namespace std;".
假如用了<iostream.h>，則不那引入定名空間，不然會惹起編譯毛病，提醒找不到定名空間，例程以下：
//情形一：應用<iostream>和定名空間
#include <iostream>
using namespace std;
int main()
{
cout<<"<iostream> need to use namespace std!/n";
return 0;
}
輸入：
<iostream> need to use namespace std!
Press any key to continue
//情形二：應用<iostream.h>，不引入定名空間
#include <iostream.h>
//using namespace std;
int main()
{
cout<<"<iostream> need to use namespace std!/n";
return 0;
}
輸入：
<iostream> need to use namespace std!
Press any key to continue
//情形三：應用<iostream.h>，引入定名空間，這時候候編譯失足
#include <iostream.h>
using namespace std;
int main()
{
cout<<"<iostream> need to use namespace std!/n";
return 0;
}
編譯毛病信息：
error C2871: 'std' : does not exist or is not a namespace
從 Visual C++ .NET 2003 開端，移除舊的 iostream 庫。
尺度 C++ 庫和之前的運轉時庫之間的重要差別在於 iostream 庫。iostream 完成的詳細細節曾經更改，假如想鏈接尺度 C++ 庫，能夠有需要重寫代碼中應用 iostream 的部門。
必需移除任何包括在代碼中的舊 iostream 頭文件（fstream.h、iomanip.h、ios.h、iostream.h、istream.h、ostream.h、streamb.h 和 strstrea.h），並添加一個或多個新的尺度 C++ iostream 頭文件（<fstream>、<iomanip>、<ios>、<iosfwd>、<iostream>、<istream>、<ostream>、<sstream>、<streambuf> 和 <strstream>，一切頭文件都沒有 .h 擴大名）。
下表描寫新的尺度 C++ iostream 庫分歧於舊 iostream 庫的行動。
在新的尺度 C++ iostream 庫中：
open 函數不采取第三個參數（掩護參數）。
沒法從文件句柄創立流。
除幾個破例，新的尺度 C++ 庫中的一切稱號都在 std 定名空間中。有關更多信息，請拜見應用 C++ 庫頭。
零丁用 ios::out 標記沒法翻開 ofstream 對象。ios::out 標記必需在邏輯 OR 中和另外一個 ios 列舉數組合；好比，和 ios::in 或 ios::app 組合。
由於設置了 eofbit 狀況，達到文件尾後 ios::good 不再前往非零值。
除非曉得以後沒有設置基標記，不然 ios::setf(_IFlags) 不該和 ios::dec、ios::oct 或 ios::hex 的標記值一路應用。格局化的輸出/輸入函數和運算符假定只設置了一個基。改用 ios_base。例如，setf( ios_base::oct, ios_base::basefield ) 消除一切基信息並將基設置成八進制。
ios::unsetf 前往 void 而不是之前的值。
若湧現毛病，istream::get( char& _Rch ) 不分派給 Rch。
istream::get( char* _Pch, int _Ncount, char _Delim ) 有三點分歧：
沒讀取任何內容時設置 failbit。
提取的字符後老是存儲一個 eos（與成果有關）。
值為 -1 時 _Ncount 是一個毛病。
具有沒有效參數的 istream::seekg 不設置 failbit。
前往類型 streampos 是具有重載運算符的類。在前往 streampos 值（好比 istream::tellg、ostream::tellp、strstreambuf::seekoff 和 strstreambuf::seekpos）的函數中，應將前往值轉換成所需的類型：streamoff、fpos_t 或 mbstate_t。
strstreambuf::strstreambuf( _Falloc, _Ffree ) 中的第一個函數參數采取 size_t 參數而不是 long。
除上述修改外，以下作為舊 iostream 庫元素的函數、常數和列舉數不是新 iostream 庫的元素：
filebuf、fstream ifstream 和 ofstream 的 attach 成員函數
filebuf、fstream ifstream 和 ofstream 的 fd 成員函數
filebuf::openprot
filebuf::setmode
ios::bitalloc
ios::nocreate
ios::noreplace
ios::sync_with_stdio
streambuf::out_waiting
streambuf::setbuf（雷同的行動應用 rdbuf -> pubsetbuf）
STL FAQ 上有對尺度庫用法的一些建議，在《軟件研發》雜志上也有這方面的評論辯論的文章，惋惜，這麼好的雜志也復刊了（能夠下面的常識對中國的法式員太甚超前了，他人說的，奇異，我怎樣看得明確了）.
What's the difference between <xxx> and <xxx.h> headers
The headers in ISO Standard C++ don't have a .h suffix. This is something the standards committee changed from former practice. The details are different between headers that existed in C and those that are specific to C++.
The C++ standard library is guaranteed to have 18 standard headers from the C language. These headers come in two standard flavors, <cxxx> and <xxx.h> (where xxx is the basename of the header, such as stdio, stdlib, etc). These two flavors are identical except the <cxxx> versions provide their declarations in the std namespace only, and the<xxx.h> versions make them available both in std namespace and in the global namespace. The committee did it this way so that existing C code could continue to be compiled in C++. However the <xxx.h> versions are deprecated, meaning they are standard now but might not be part of the standard in future revisions. (See clause D.5 of the ISO C++ standard.)
The C++ standard library is also guaranteed to have 32 additional standard headers that have no direct counterparts in C, such as <iostream>, <string>, and <new>. You may see things like #include <iostream.h> and so on in old code, and some compiler vendors offer .h versions for that reason. But be careful: the .h versions, if available, may differ from the standard versions. And if you compile some units of a program with, for example, <iostream> and others with <iostream.h>, the program may not work.
For new projects, use only the<xxx> headers, not the<xxx.h> headers.
When modifying or extending existing code that uses the old header names, you should probably follow the practice in that code unless there's some important reason to switch to the standard headers (such as a facility available in standard<iostream> that was not available in the vendor's <iostream.h>). If you need to standardize existing code, make sure to change all C++ headers in all program units including external libraries that get linked in to the final executable.
All of this affects the standard headers only. You're free to name your own headers anything you like; see [27.9].
尺度庫擴大了原庫，例如新庫<string>還支撐寬字符集的操作,所以我以為在如今年夜多半的編譯器都已支撐尺度C++的情形下，一切的法式都應當應用尺度頭文件的導入方法！
關於名字空間 namespace std 的應用，C++ 的 FAQ 的答復是如許的
Should I use using namespace std in my code?
Probably not.
People don't like typing std:: over and over, and they discover that using namespace std lets the compiler see any std name, even if unqualified. The fly in that ointment is that it lets the compiler see any std name, even the ones you didn't think about. In other words, it can create name conflicts and ambiguities.
For example, suppose your code is counting things and you happen to use a variable or function named count. But the std library also uses the name count (it's one of the std algorithms), which could cause ambiguities.
Look, the whole point of namespaces is to prevent namespace collisions between two independently developed piles of code. The using-directive (that's the technical name for using namespace XYZ) effectively dumps one namespace into another, which can subvert that goal. The using-directive exists for legacy C++ code and to ease the transition to namespaces, but you probably shouldn't use it on a regular basis, at least not in your new C++ code.
If you really want to avoid typing std::, then you can either use something else called a using-declaration, or get over it and just type std:: (the un-solution):
Use a using-declaration, which brings in specific, selected names. For example, to allow your code to use the name cout without a std:: qualifier, you could insert using std::cout into your code. This is unlikely to cause confusion or ambiguity because the names you bring in are explicit.
just type std:: (the un-solution):
#include <vector>
#include <iostream>
void f(const std::vector<double>& v)
{
using std::cout;// ← a using-declaration that lets you use cout without qualification
cout << "Values:";
for (std::vector<double>::const_iterator p = v.begin(); p != v.end(); ++p)
cout << ' ' << *p;
cout << '/n';
}
Get over it and
#include <vector>
#include <iostream>
void f(const std::vector<double>& v)
{
std::cout << "Values:";
for (std::vector<double>::const_iterator p = v.begin(); p != v.end(); ++p)
std::cout << ' ' << *p;
std::cout << '/n';
}
I personally find it's faster to type "std::" than to decide, for each distinct std name, whether
or not to include a using-declaration and if so, to find the best scope and add it there. But
either way is fine. Just remember that you are part of a team, so make sure you use an approach
that is consistent with the rest of your organization.
