⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 questions

📁 早期freebsd实现
💻
字号:
*** 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 + -