为非本地容器(数据库后端)重载/专门化STL算法
我想要做的是,在一个单独的命名空间中,定义我自己的 sort()、copy() 等实现,这些实现与数据库表/视图/等容器而不是内存中的 std 容器一起使用。如果我定义自己的 sort() 来接受自定义前向迭代器,编译器如何解决这个问题?或者,我需要做什么才能正确解析,即使用我的自定义 sort() 而不是 std sort(),即使我可能传入与标准迭代器类型要求匹配的自定义迭代器类型?
如果它使用 std sort(),它实际上仍然可以工作,只是效率极低,因为它不会将排序移交给数据库,而我的 sort() 实现会。我只是不确定当它们具有相同的名称并接受相同的类型时如何在 std sort() 上正确调用我的 sort() 。我的描述中可能遗漏了一些细节,所以请耐心等待我解决这个问题。
另外,我发现以下问题与我要问的问题最相似(提到 ADL 和部分专业化),但我不确定它是否直接解决了我的问题或描述了执行我的操作的最佳方法已经描述过: 针对特定迭代器类型重载 for_each
What I want to do is, in a separate namespace, define my own sort(), copy(), etc implementations that work with database tables/views/etc containers instead of in-memory std containers. If I define my own sort() that accepts my custom forward iterator, how does the compiler resolve that? Or, what do I need to do so that it will resolve properly i.e. use my custom sort() instead of std sort(), even though I may be passing in custom iterator types that match the standard iterator type requirements?
If it uses std sort(), it would actually still work, it would just be extremely inefficient because it wouldn't be handing over the sort to the database, whereas my sort() implementation would. I'm just not sure how to properly invoke my sort() over std sort() when they have the same name and accept the same types. I may have missed some details in my description, so please bear with me on bludgeoning my way through this issue.
Also, I found the following question to be the most similar to what I'm asking (mentions ADL and partial specialization), but I'm not sure if it directly addresses my issue or describes the best way to go about doing what I've described:
Overloading for_each for specific iterator types
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
它实际上是为您自己的 UDT 专门化 std 命名空间算法而定义的行为。
编辑: Oopsie Sort 而不是排序。
再次编辑:天啊,我写了一些完全错误的东西。这根本不是明确的规范语法。
It's actually defined behaviour to specialize std namespace algorithms for your own UDTs.
Edit: Oopsie Sort instead of sort.
Edit again: Oh man, I wrote something totally wrong. That's not explicit spec syntax at all.