便携式终端
有没有办法根据所使用的操作系统自动使用正确的 EOL 字符?
我在想类似 std::eol
的东西?
我知道使用预处理器指令非常容易,但很好奇它是否已经可用。
我感兴趣的是,我的应用程序中通常有一些消息,稍后我会将这些消息组合成一个字符串,并且我希望将它们用 EOL 分隔开。我知道我可以使用 std::stringstream << endl 但有时它似乎比常规追加有点矫枉过正。
is there any way to automatically use correct EOL character depending on the OS used?
I was thinking of something like std::eol
?
I know that it is very easy to use preprocessor directives but curious if that is already available.
What I am interested in is that I usually have some messages in my applications that I combine later into a single string and I want to have them separated with a EOL. I know that I could use std::stringstream << endl
but it seems to be an overkill sometimes instead of a regular append.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
std::endl
被定义为除了将'\n'
写入流并刷新它之外不执行任何操作(第 27.6.2.7 节)。 Flushing 被定义为对 stringstream 不执行任何操作,因此您可以用一种漂亮的方式来表示 mystringstream << '\n'。您的操作系统上的标准库实现会适当地转换\n
,因此这不是您所关心的。因此,
endl
已经是性能和可移植性的终极选择,您唯一需要的就是<< '\n'
如果您试图有效地写入文件(而不是字符串流)。嗯,<< '\n'
也消除了对stringbuf::flush
无意义的虚拟调用。除非分析显示空函数调用需要时间,否则不要考虑它。std::endl
is defined to do nothing besides write'\n'
to the stream and flush it (§27.6.2.7). Flushing is defined to do nothing for astringstream
, so you're left with a pretty way of sayingmystringstream << '\n'
. The standard library implementation on your OS converts\n
appropriately, so that's not your concern.Thus
endl
is already the ultimate in performance and portability, and the only other thing you could want is<< '\n'
if you are trying to efficiently write to a file (not a stringstream). Well,<< '\n'
does also eliminate the pointless virtual call tostringbuf::flush
. Unless profiling shows that empty function call to be taking time, don't think about it.如果要将行分隔符写入流:
或
或
如果流是文本模式并且操作系统使用 LF 以外的任何内容作为分隔符,它将被转换。
如果您想编写行分隔符并刷新流:
如果您出于某种原因有二进制模式输出,并且您想编写特定于平台的换行符,那么我认为您可能必须间接执行此操作(编写
'\n'
到文本流,然后以二进制模式检查它以查看得到的内容)。可能有某种方法可以直接从实现中获取换行序列,但我不知道。无论如何,这不是一个好主意:如果您以二进制模式写入或读取文件,那么它应该采用独立于操作系统定义换行符的格式,或者根本没有行。这就是二进制模式的用途。If you want to write a line separator to a stream:
or
or
If the stream is text mode and the OS uses anything other than LF as a separator, it will be converted.
If you want to write a line separator and flush the stream:
If you have binary-mode output for whatever reason, and you want to write a platform-specific line break, then I think you might have to do it indirectly (write
'\n'
to a text stream and then examine it in binary mode to see what you get). Possibly there's some way to directly get the line break sequence from the implementation, that I'm not aware of. It's not a great idea, anyway: if you're writing or reading a file in binary mode then it should be in a format which defines line breaks independently of the OS, or which doesn't have lines at all. That's what binary mode is for.只需以文本模式打开一个文件
,然后
操作系统就会根据其标准处理 EOL。
Just open a file in text mode
and then
and the OS will take care of the EOL accordingly to its standards.
好吧,STL 有 std::endl,您可以将其用作
注意,除了添加结束行之外,std::endl 还会刷新缓冲区,这可能会产生不良的性能后果。
Well, the STL has std::endl, which you can use as
Note that besides adding an endline, std::endl also flushes the buffer, which may have undesirable performance consequences.
文件,甚至文本文件,经常在机器之间传输,因此“操作系统特定的换行符”是一个矛盾的说法。
确实,操作系统在这个问题上有发言权,特别是一个又名 Windows 的操作系统,尽管许多 Windows 程序会正确读取 \n 间隔的文件,即使 winapi 多行编辑控件不会。我建议您仔细考虑什么适合您:它不一定是您的操作系统推荐的。如果您的文件要存储在可移动媒体上,请不要使用操作系统标准。使用全球标准 0xA。
Files, even text files, are often transferred between machines, so "os-specific new line character" is an oxymoron.
It is though true that operating systems have a say on that matter, particularly one operating systems aka Windows, although many windows programs will read \n-spaced files correctly, even though the winapi multiline edit control would not. I suggest you consider twice what is the right for you: it's not necessarily what your OS recommends. If your files are ever to be stored on removable media, do not use OS standard. Use global standard, 0xA.