库应该使用使用智能指针的接口吗?

发布于 2024-09-16 08:04:51 字数 300 浏览 9 评论 0原文

我开始编写一个库并考虑它的界面。我以前编写的库都使用原始指针(无论是在内部还是在其接口中),现在我想尝试一下VS2010附带的智能指针库。

  1. 接口应该使用智能指针吗? (可能会迫使库用户也使用智能指针?)
  2. 如果接口使用原始指针但库内部使用智能指针,会不会很混乱? (这甚至可能吗?shared_ptr没有release()方法...)
  3. 两个c ++ 0x兼容的智能指针库(例如boost和VS2010)可以互换使用吗? (假设我使用 VS2010 编写我的库,用户使用 boost)

请帮助:)

I'm starting to write a library and considering its interface. Previous libraries I've written all use raw pointers (both internally and in its interface), and now I want to try the smart pointer library that comes with VS2010.

  1. Should the interface use smart pointers? (Possibly forcing the library users to use smart pointers too?)
  2. Would it be messy if the interface uses raw pointers but the library uses smart pointers internally? (Is it even possible? shared_ptr doesn't have a release() method...)
  3. Can two c++0x compliant smart pointer libraries (say boost and VS2010) be used interchangeably? (say I use VS2010 to write my library and the users use boost)

Please help :)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

难以启齿的温柔 2024-09-23 08:04:51

如果不进一步了解您的设计原则以及您期望如何使用该库,就不可能回答这些问题。

所以我只能根据我的经验以及我喜欢如何使用我的库来回答。

  1. 是的。
  2. 是的。不要这样做。
  3. 混合它们可能不是一个好主意(尽管我从未尝试过)。
    但你可以弥补这一点:
    由于大多数开源都是作为源代码分发的,因此您可以构建源代码,以便将其配置为在许多环境中使用。

例如:

#if   defined(MY_PROJ_SHARED_PTR_FROM_BOOST)

#include <boost/shared_ptr.hpp>
#define MY_PROJ_SHARED_PTR_NAMESPACE    boost

#elif defined(MY_PROJ_SHARED_PTR_FROM_STD)

#include <memory>
#define MY_PROJ_SHARED_PTR_NAMESPACE    std

#elif defined(MY_PROJ_SHARED_PTR_FROM_TR1)

#include <tr1/memory>
#define MY_PROJ_SHARED_PTR_NAMESPACE    std::tr1

#else
#error "MY_PROJ_SHARED_PTR_FROM_<XXX> not defined correctly"
#endif


namespace X
{
    using ::MY_PROJ_SHARED_PTR_NAMESPACE::shared_ptr;
}


int main()
{
    X::shared_ptr<int>  data;
}

我确信还有其他方法可以做到这一点。
但已经晚了。

It is imposable to answer those question without understanding a lot more about your design principles and how you expect the library to be used.

So I can only answer based on my experience and how I like my libraries to be used.

  1. Yes.
  2. Yes. Don't do it.
  3. Its probably not a good idea to mix them (though I have never tried).
    But you can compensate for this:
    As most open source is distributed as source you can build your source so that it can be configured for use in many environments.

For Example:

#if   defined(MY_PROJ_SHARED_PTR_FROM_BOOST)

#include <boost/shared_ptr.hpp>
#define MY_PROJ_SHARED_PTR_NAMESPACE    boost

#elif defined(MY_PROJ_SHARED_PTR_FROM_STD)

#include <memory>
#define MY_PROJ_SHARED_PTR_NAMESPACE    std

#elif defined(MY_PROJ_SHARED_PTR_FROM_TR1)

#include <tr1/memory>
#define MY_PROJ_SHARED_PTR_NAMESPACE    std::tr1

#else
#error "MY_PROJ_SHARED_PTR_FROM_<XXX> not defined correctly"
#endif


namespace X
{
    using ::MY_PROJ_SHARED_PTR_NAMESPACE::shared_ptr;
}


int main()
{
    X::shared_ptr<int>  data;
}

I am sure there are other ways to do this.
But it is late.

摘星┃星的人 2024-09-23 08:04:51
  1. 取决于您认为#2 还是#3 更重要。
  2. 是的。
  3. 不,除非它们是故意设计的。
  1. Depends on the whether you consider #2 or #3 more important.
  2. Yes.
  3. No, unless they were deliberately designed to.
猫卆 2024-09-23 08:04:51

我想说这里使用 80-20 规则。如果 80% 的客户最好使用符合 boost/stl/C++ 的标准,那么请这样做。对于其余的,您可以构建适配器层并将复杂性转移到该层。对于此类目的,适配器设计模式是我最喜欢的。

I would say to use 80-20 rule here. If 80% of clients would be better of using boost/stl/C++ compliant, then please do so. For the rest, you can build adapter layer and move the complexity to that layer. The Adapter design pattern is my favourite for such purposes.

谁把谁当真 2024-09-23 08:04:51

从用户的角度来看,我想说你只需要在界面中清楚地了解你需要什么。

您需要对象的副本还是只需要一个指针?

在内部,您可能可以使用您最方便的指针类型,只要它不会过多降低性能并且不会导致错误。

要问的一个问题是您到底要如何处理该指针?你会删除它吗?如果我更新/删除对象(例如 GUI 库),我可以更改引用吗?

对于那些在不需要时通常不使用智能指针的人来说,看到太多智能指针只会告诉我你没有注意你将要做什么,并且会导致潜在的错误。

作为一个库用户,我更喜欢崩溃(当试图取消引用一个明显无效的指针时),而不是有一个半有效的指针,这实际上并不是我所期望的(我怀疑这可能是使用shared_ptr类型的智能指针的问题) 。

From a user's point a view I'd say that you just need to be clear in your interface about what you need.

Do you need a copy of the object or just a pointer?

Internally you can probably use the type of pointer that you're most convienant off as long as it don't degrade performance too much and don't cause bugs.

A question to ask is what exactly will you do with that pointer? Will you delete it? Can I change the reference if I update/delete the object (say in the case of a GUI library).

As someone who don't usually use smart pointers when they are not needed seeing too much smart pointers will just tell me you don't pay attention to what you will do and is cause for potential bugs.

As a library user I prefer a crash (when attempting to dereference a clearly invalid pointer) to having an semi-valid pointer around that is not actually what I expect (which I suspect can be a problem with using smart pointers of the shared_ptr kind).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文