哪个 C++概念更适合对数据库查询进行建模 - 流还是输入迭代器？
我想将数据库查询视为标准 C++ 输入迭代器。 另一方面，可以将数据库查询视为查询结果项的输入流。 您认为更好的数据库查询模型是输入迭代器还是输入流？
就我个人而言，我的印象是 C++ IO 流应该仅对字符进行操作，但我从未见过任何字符不是 char 或 wchar_t 的流示例。代码>.据我所知，流的模板化性质允许我将任何内容作为字符传递，因此从理论上讲，我似乎可以将查询结果项视为字符以便进行流式处理，但我不确定它是否是一个好主意。
欢迎提出建议。
谢谢。
I would like to treat a database query as a standard C++ input iterator.
On the other hand, one can view a database query as an input stream of query result items.
What do you think is a better model for a db query - an input iterator or an input stream?
Personally, I have an impression that C++ IO streams are supposed to operate on characters only, where I have never seen any example of a stream where characters would be something other than char or wchar_t. I understand, that the templated nature of the streams allows me to pass anything as a character, so theoretically, it seems that I can treat the query result item as a character for the sake of streaming, but I am not sure if it is a good idea.
Advices are welcome.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您用作流字符类型的任何内容都需要具有字符特征，也许还需要一些与语言环境有关的东西，因为有人可能会尝试将语言环境注入您的流中。这可能是无稽之谈，但它仍然存在于界面中，即使您将其设置为错误，您也可能需要将其设置为明智的错误。
我肯定会使用输入迭代器，在 C++ 中，它是对象序列的简单模型。
流除了呈现序列之外，还可以做很多其他事情（格式化、streambuf 的控制、神秘的错误状态模型）。其中大部分内容可能不适用于您的数据库项目，尽管我认为其中一些可能适用。例如，控制数据库查询结果流的缓冲区大小是有意义的，但从中进行格式化读取则没有意义。
istream_iterator 存在的事实证明，即使您为某人提供流，他们也可能更喜欢/需要迭代器接口。
Anything you use as a stream character type needs to have character traits, and maybe some stuff to do with locales, since someone might try to imbue a locale into your stream. Which might be nonsense, but it's still there in the interface and even if you make it an error you probably need to make it a sensible error.
I'd definitely use an input iterator, in C++ it's the simple model for a sequence of objects.
Streams do a lot of other stuff as well as merely presenting a sequence (formatting, control of the streambuf, the arcane error state model). Much of that probably isn't applicable to your database items, although I suppose some of it could be. For example controlling the buffer size of a DB query result stream would make sense, but formatted reads from it wouldn't.
The fact that
istream_iteratorexists is proof that even if you offer someone a stream, they might well prefer/need the iterator interface.