在C ++ 17或C ++ 20中，文件I / O操作中是否存在“ preferred_end_of_line_separator”？

Question

当我尝试操作文本文件时，希望将行尾字符设置为目标操作系统上的首选字符，例如linux文本文件中的LF和Windows文本文件中的CRLF。

相关问题

根据问题C++: Is there a standard definition for end-of-line in a multi-line string constant?，eol字符取决于源文件中的字符。那就是说，当我使用

std::ofstream out{"hello.txt"};
out << R"(Hello
World)" << std::endl;

即使源文件以Windows文本格式存储，“ hello.txt”中的eol字符也映射为单个“ \ n”字符。

根据问题Detect Windows or Linux in C, C++和Standard #ifdef for Cygwin，我可以使用

#if defined(_WIN32) || defined(__CYGWIN__)
#define END_OF_LINE "\n\r"
#else
#define END_OF_LINE "\n"

但是，我不知道如何将这些代码放入前一个代码段中。

Java解决方案

在Java中，使用

System.getProperty("line.separator");

将返回相应的行尾字符。

JDK 7将以上行替换为System.lineSeparator()，效率更高。

C ++解决方案？

C ++ 17文件系统提供了一个常量：std::filesystem::path::preferred_separator，用于告知各种OS平台上的路径分隔符。我认为这是一种很好的形式。

C ++ 17或更新的标准中是否存在提供std::xxx::preferred_eol_separator这样的便利的现有设施？

Answer 1

是的，很有趣-它叫做'\n'。原因是，标准库（printf()，cout及其家族）的输出I / O操作中对NEW LINE字符的解释取决于您如何打开文件进行写入。例如

fopen("path", "w");

在POSIX上将文件标记为“可写文件”，在Windows上将其标记为“可写文本文件”。 POSIX不会转换输入缓冲区的内容，而在Windows上，每个'\n'都将存储为CRLF对。另一方面，

fopen("path", "wb");

（再次）在POSIX上将文件标记为“可写文件”，在Windows上将其标记为“可写二进制文件”。这次，POSIX和Windows都不会做任何翻译。

输入文件也会发生同样的情况："r"将被视为“可读文本文件”，"rb"将被视为“可读二进制文件”，并且在Windows上，对“文本”文件会将所有CRLF作为单独的\n报告回应用程序。

此方法在iostream中也可用，其中所有cout，cerr和clog都被视为文本文件，而ofstream和ifstream可以构造函数中有一个std::ios_base::binary标志来区分文本模式和二进制模式。