📄 questions
字号:
*** Can/should streambuf::sputbackc(char) assume that the putback areais writable?I.e. is the following a valid implementation:int streambuf::sputbackc(char c){ if (gptr() <= eback()) return pbackfail(c); gbump(-1); *gptr() = c; return zapeof(c);}Problem: what if the get area is a read-only string?Or a copy-on-write file buffer?How about:int streambuf::sputbackc(char c){ if (gptr() <= eback()) return pbackfail(c); gbump(-1); return zapeof(c);}Problem: What if we want to remember putback'ed charactersin a buffer? Solution: Make sure pbackfail is always calledin those cases.Or the paranoid solution:int streambuf::sputbackc(char c){ if (gptr() <= eback()) return pbackfail(c); gbump(-1); if (*gptr() != c) *gptr() = c; return zapeof(c);}The assumptions should be specified by the standard.*** The 2.1 Library manual page 3-19 section "Files" says:"A subtle point is that closing a file stream (either explicitly orimplicitly in the destructor) will close the underlying filedescriptor if it was opened with a filename, but notif it was supplied with attach."I assume the [io]fstream::attach(fd) rule also applies tothe [io]fstream::[io]fstream(int fd) constructors?How about filebufs? Will "delete (new filebuf(0))"close the underlying file descriptor? What about"(new filebuf(0))->close()"?
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -