我注意到这个奇怪的东西
fstream obj(filename , ios::in);
obj.seekp(7);
与相同
fstream obj(filename , ios::in);
obj.seekg(7);
seekg
和seekp
执行相同的操作并导致相同的结果,尽管我在仅标记中指定了ios:
为什么他们都与fstream合作?使用fstream的seekp
和seekg
有什么区别?
basic_fstream
源自basic_iostream
,后者源自basic_istream
和basic_ostream
。因此,basic_fstream
具有来自basic_ostream
的函数seekp
和来自basic_ifstream
的函数seekg
。
简而言之,在您的情况下,对seekp和seekg的调用执行相同的操作,因为basic_filebuf::seekpos
执行的操作仅取决于basic_filebuf
的打开模式
basic_ostream<charT,traits>& seekp(pos_type pos);
效果:如果失败()!=true,执行rdbuf()->pubseekpos(pos,ios_base::out)。在故障的情况下,该函数调用setstate(failbit)(可能引发iosbase::failure)
其中pubseekpos
调用seekpos
(即virtual
,因此调用basic_filebuf::seekpos
)
pos_type seekpos(pos_type sp,
ios_base::openmode which = ios_base::in | ios_base::out);
如果可能,更改文件位置,使其与sp中存储的位置相对应(如下所述)。更改文件位置的操作如下:
if(om&ios_base::out)!=0,然后更新输出序列并写入任何未移位的序列;
将文件位置设置为sp;
3.if(om&ios_base::in)!=0,然后更新输入序列
其中om是传递给最后一次调用open()的打开模式。如果is_open()返回,则操作失败false。
由于您使用ios_base::in
函数打开文件,因此会执行2个和3个点。
basic_istream<charT,traits>& seekg(pos_type pos);
效果:表现为未格式化的输入函数(如27.7.2.3第1段所述),但该函数首先清除eofbit,它不计算提取的字符数,也不计算影响后续调用gcount()返回的值。构造哨兵对象后,如果失败()!=true,执行rdbuf()->pubseekpos(pos,ios_base::in)。如果失败,函数将调用setstate(failbit)(可能引发ios_base::failure)