Должна ли библиотека использовать интерфейс, использующий интеллектуальные указатели?

Я начинаю писать библиотеку и рассматриваю ее интерфейс. Все предыдущие библиотеки, которые я написал, используют необработанные указатели (как внутри, так и в своем интерфейсе), и теперь я хочу попробовать библиотеку интеллектуальных указателей, которая поставляется с VS2010.

  1. Должен ли интерфейс использовать интеллектуальные указатели? (Возможно, вынуждаете пользователей библиотеки использовать интеллектуальные указатели тоже?)
  2. Было бы грязно, если интерфейс использует необработанные указатели, но библиотека использует интеллектуальные указатели внутри? (Возможно ли это? Shared_ptr не имеет метода release () ...)
  3. Можно ли использовать две библиотеки интеллектуальных указателей, соответствующих c ++ 0x (скажем, boost и VS2010), взаимозаменяемо? (скажем, я использую VS2010 для написания своей библиотеки, а пользователи используют boost)

Пожалуйста, помогите: )

9
задан twf 27 August 2010 в 17:52
поделиться

4 ответа

Невозможно ответить на эти вопросы, не зная намного больше о ваших принципах проектирования и о том, как вы ожидаете, что библиотека будет использоваться.

Поэтому я могу ответить только исходя из своего опыта и того, как мне нравится использовать мои библиотеки.

  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;
}

Я уверен, что есть и другие способы сделать это.
Но уже поздно.

5
ответ дан 3 November 2019 в 07:11
поделиться

Я бы посоветовал использовать здесь правило 80-20. Если 80% клиентов будут лучше использовать совместимость с boost/stl/C++, пожалуйста, сделайте это. В остальном вы можете создать уровень адаптера и перенести сложность на этот уровень. Для таких целей мне больше всего нравится шаблон проектирования Adapter.

0
ответ дан 3 November 2019 в 07:11
поделиться

С точки зрения пользователя я бы сказал, что вам просто нужно четко указать в своем интерфейсе, что вам нужно.

Вам нужна копия объекта или просто указатель?

Внутри вы, вероятно, можете использовать тип указателя, который вам наиболее удобен, если он не слишком сильно снижает производительность и не вызывает ошибок.

Возникает вопрос: что именно вы будете делать с этим указателем? Вы удалите его? Могу ли я изменить ссылку, если я обновляю/удаляю объект (скажем, в случае библиотеки с графическим интерфейсом).

Как человек, который обычно не использует интеллектуальные указатели, когда они не нужны, увидев слишком много интеллектуальных указателей, просто скажет мне, что вы не обращаете внимания на то, что вы будете делать, и это является причиной потенциальных ошибок.

Как пользователь библиотеки, я предпочитаю сбой (при попытке разыменования явно недопустимого указателя) полувалидному указателю, который на самом деле не соответствует моим ожиданиям (что, как я подозреваю, может быть проблемой при использовании интеллектуальных указателей библиотеки). тип shared_ptr).

0
ответ дан 3 November 2019 в 07:11
поделиться
  1. Зависит от того, считаете ли вы №2 или №3 более важным.
  2. Да.
  3. Нет, если они не были преднамеренно разработаны.
0
ответ дан 3 November 2019 в 07:11
поделиться
Другие вопросы по тегам:

Похожие вопросы: