用fstream如何截短一个文件，在一个指定streampos结束文件？

[ooolinux]

比如一个文件是很多记录，有的记录打了删除标记，现在要把有删除标记的记录真正删除，用文件后面的记录来填补删除记录的位置，最后的文件肯定变短，如何让文件在一个指定streampos结束？我这里问的是在同一个文件里面pack操作，当然实际上不如写入一个新文件再改名更安全。

[赵4老师]

写入一个新文件再改名不会死人的。 楼主非要在同一个文件中pack，请注意： 使用binary、read、write模式打开 每次读前要明确地seekg 每次写前要明确地seekp 最后还得_chsize（windows），ftruncate（linux）

[ooolinux]

引用 1 楼 zhao4zhong1 的回复:

写入一个新文件再改名不会死人的。 楼主非要在同一个文件中pack，请注意： 使用binary、read、write模式打开 每次读前要明确地seekg 每次写前要明确地seekp 最后还得_chsize（windows），ftruncate（linux）

_chsize（windows）是Windows API吗？fstream流本身没有办法？比如写入一个文件结束标记（文件中有这个标记吗？）

[赵4老师]

引用 2 楼 u010165006 的回复:

[quote=引用 1 楼 zhao4zhong1 的回复:] 写入一个新文件再改名不会死人的。 楼主非要在同一个文件中pack，请注意： 使用binary、read、write模式打开 每次读前要明确地seekg 每次写前要明确地seekp 最后还得_chsize（windows），ftruncate（linux）

_chsize（windows）是Windows API吗？fstream流本身没有办法？比如写入一个文件结束标记（文件中有这个标记吗？）[/quote] 纯文本文件可以写一个'\x1a'作为文件结束标记，但仍然不会修改实际的文件大小。 所以劝楼主还是使用FILE *系列的函数吧。fileno(fp)用来获得FILE *对应的handle int _fileno( FILE *stream );//windows int _chsize( int handle, long size );//windows int fileno(FILE *stream); //linux int ftruncate(int fildes, off_t length); //linux 在每次读写前要明确地fseek 乍看起来c++的cin、cout、ifstream、ofstream在输入、输出上比c的scanf、printf、fscanf、fprintf、fread、fwrite简单，不用格式控制符！ 但是不用格式控制符，输入输出恰好是你期望的格式的时候好说；等到输入输出不是你期望的格式的时候，你就会觉得还是用格式控制符更方便、更靠谱。 摒弃cin、cout、ifstream、ofstream！ 使用scanf、printf、fscanf、fprintf、fread、fwrite。

[赵4老师]

FILE *fp=fopen(...,"rb+");

[赵4老师]

推荐使用WinHex软件查看硬盘或文件或内存中的原始字节内容。 不要把 fopen("...","...");fscanf,fprintf,fgets,fgetc,fclose //读时把\r\n替换成\n，写时把\n替换成\r\n;读到\x1a就设置EOF;读写的内容当字符看待 和 fopen("...","...b");fseek,ftell,fread,fwrite,fgetc,fclose //不作以上替换，遇到\x1a仍继续读;读写的内容当字节看待 弄混了

[ooolinux]

引用 5 楼 zhao4zhong1 的回复:

推荐使用WinHex软件查看硬盘或文件或内存中的原始字节内容。 不要把 fopen("...","...");fscanf,fprintf,fgets,fgetc,fclose //读时把\r\n替换成\n，写时把\n替换成\r\n;读到\x1a就设置EOF;读写的内容当字符看待 和 fopen("...","...b");fseek,ftell,fread,fwrite,fgetc,fclose //不作以上替换，遇到\x1a仍继续读;读写的内容当字节看待 弄混了

好 虽然FILE *序列函数也很好用实用，而且据说读写大文件的速度比C++流更快，但是在C++中使用感觉风格不统一？还是说实用最重要？

[赵4老师]

请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。 意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。 试对比 图书馆（对图书的分类够结构化了吧） 和 搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索） 哪个处理信息更方便、更高效。 所以 与其费劲去重构代码让其看上去更简洁、更合理 不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。 结构越复杂，越难修改，越难除错。 有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。 程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George

[ooolinux]

引用 7 楼 zhao4zhong1 的回复:

请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。 意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。 试对比 图书馆（对图书的分类够结构化了吧） 和 搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索） 哪个处理信息更方便、更高效。 所以 与其费劲去重构代码让其看上去更简洁、更合理 不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。 结构越复杂，越难修改，越难除错。 有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。 程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George

这个我不完全同意，难道一团乱麻的代码是为了让后来者维护时感到困难？ 一团乱麻的代码确实容易修改，因为怎么修改都可以。而“看上去越合理、越简洁的代码”，修改起来可能会破坏原来的设计，修改以后变了不简洁了，所以才说修改越费劲。 有一种情况比如像Linux的开放源代码，如果代码不是合理、简洁，那怎么open source。

[赵4老师]

说代码一团乱麻，满身臭味的人只不过是因为他不会全文搜索替换，不会带防毒面具。

[zeloas]

fstream的不会，ftruncate