tellg() 返回输入流当前读取位置（std::streampos），需检查是否为-1；务必用二进制模式打开文件，且调用前确保流状态良好；tellp() 为其输出流对应函数。
用 tellg() 读取输入流的文件指针位置
当你用 std::ifstream 或带输入功能的 std::fstream 打开文件后，tellg() 返回当前“获取”（get）位置，也就是下一次 read()、getline() 或 operator>> 将从哪开始读。它返回的是 std::streampos 类型，通常可直接转为 std::streamoff（有符号整数）做计算。
注意：如果流未处于良好状态（比如刚打开失败、已到 EOF、或发生读错误），tellg() 返回 std::streampos(-1)，必须检查：
std::ifstream fin("data.txt");
if (!fin.is_open()) return;
fin.seekg(100); // 移动到第100字节
std::streampos pos = fin.tellg();
if (pos == std::streampos(-1)) {
// 错误：可能流不支持定位（如管道）、或状态位 failbit/setbadbit 已置位
}
常见坑：
-
tellg()在文本模式下行为不可靠（尤其 Windows 换行符 \r\n 被转为 \n，字节数与逻辑位置不一致），务必用二进制模式打开：std::ifstream fin("file.txt", std::ios::binary); - 调用
tellg()前不能有未处理的失败操作（如上一次getline()失败但没清状态），否则返回 -1 - 对
std::cin调用tellg()几乎总失败——标准输入不支持定位
用 tellp() 获取输出流的文件指针位置
tellp() 是 tellg() 的“写入侧对应物”，用于 std::ofstream 或带输出功能的 std::fstream，返回下一次 write() 或 operator 将写入的位置。和 <code>tellg() 一样，它也返回 std::streampos，且同样要求流处于 good 状态、且以二进制模式打开才能保证字节级准确。
立即学习“C++免费学习笔记（深入）”；
典型使用场景是记录日志时动态截断或补全：
std::fstream log("log.bin", std::ios::in | std::ios::out | std::ios::binary);
if (!log) return;
log.seekp(0, std::ios::end); // 定位到末尾
std::streampos end_pos = log.tellp(); // 得到当前文件大小（字节数）
log.seekp(end_pos - 4); // 回退4字节，准备覆盖最后一条记录
关键限制：
- 仅当文件以
std::ios::in和/或std::ios::out打开，并且底层支持随机访问（普通磁盘文件可以，socket 或 pipe 不行）时，tellp()才有效 - 若文件以
std::ios::app模式打开，所有写操作强制追加到末尾，此时tellp()可能返回末尾位置，但任何seekp()都会被忽略 - 文本模式下
tellp()的值不等于实际写入字节数（换行符转换干扰），必须用std::ios::binary
tellg() 和 tellp() 能混用吗？
在 std::fstream（同时支持读写）中，tellg() 和 tellp() 各自维护独立的指针位置——这是 C++ 标准明确规定的。也就是说，你调用 read() 后 tellg() 变了，但 tellp() 不变；反之亦然。
这意味着：如果你希望读写共享同一个位置（比如边读边改），必须显式同步：
- 调用
seekg(pos)后，再调用seekp(pos)，或反过来 - 或者统一用
seekg(pos, std::ios::beg)+seekp(pos, std::ios::beg)保持一致 - 更安全的做法是只用其中一个（比如统一用
seekg()+tellg()），避免混淆
一个容易被忽略的事实：C++ 标准不要求 std::fstream 的两个指针物理上分离；某些实现（如 libc++）内部确实共用一个位置，但你不该依赖这个——行为未标准化，跨平台不可靠。
为什么 tellg() / tellp() 返回 -1？怎么排查
返回 std::streampos(-1) 是唯一明确的错误信号，不是偶然。常见原因包括：
- 流未打开，或打开失败（
is_open() == false） - 流状态位异常：
failbit（格式错误）、badbit（底层 I/O 错误）、eofbit（虽不影响 tell，但常伴随其他问题）——调用前先clear()并确认是否真需要忽略上次错误 - 底层文件描述符不支持
lseek()（例如：Linux 下的/dev/stdin、命名管道、socket） - 文件以只读方式打开却调用了
tellp()，或以只写方式打开却调用了tellg()
调试建议：不要只看返回值，立刻检查 fin.fail()、fin.bad()、fin.eof()，并确认打开模式匹配操作类型。二进制模式和显式状态检查，比任何技巧都管用。
