Используя повышение:: shared_ptr в открытом интерфейсе библиотеки

Одно возможное решение состоит в том, чтобы поставить повышение:: shared_ptr с Вашим проектом. Поскольку все это состоит из заголовков, это освободило бы Ваши клиенты от необходимости установить библиотеки повышения вручную. Можно использовать BCP для получения всех файлов, необходимых конкретной библиотеке повышения, включая библиотеки самой. Я сделал это, когда я работал на компанию тогда и нуждался boost::shared_ptr и это на самом деле работало значительно.

Если семантика является действительно передачей права собственности, почему бы не использовать auto_ptr, так как это - стандартный C++? Внутренне, Вы можете все еще создать свой shared_ptr из auto_ptr и затем совместно использовали владение при необходимости в нем.

Это - C++. Вы знаете, Вы могли обработать интерфейсный класс по шаблону по общей реализации указателя.

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

В первую очередь, если Вы распределяете свою библиотеку как исходный код, а не как скомпилированная библиотека, можно игнорировать этот ответ. Существуют также некоторые окна определенные проблемы, которые не могут быть важны для других платформ.

Я лично думаю, что необходимо постараться не иметь слишком много броского C++ в открытом интерфейсе библиотеки, так как это может вызвать много проблем в клиенте.

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

Другая проблема, с которой можно столкнуться, состоит в том, что различные компиляторы C++ могут исказить те же символы по-другому, что означает, что потенциально необходимо обеспечить отдельную библиотеку для каждого компилятора, который Вы хотите поддерживать, даже если они используют ту же версию Повышения. Проверьте книгу "Имперфект C++" для обсуждения этого.

В текущем мире различных компиляторов C++ и сред я думаю, что печальная истина - то, что необходимо постараться не иметь что-либо кроме C в интерфейсе и удостовериться, что Вы связываете свою библиотеку динамично (для предотвращения конфликтов, когда соединение клиентов связывает библиотеку, библиотека времени выполнения окон может быть реальной болью здесь). Можно все еще использовать повышение и в качестве большого количества необычного C++ на внутренней части библиотеки, как Вы хотите, так как все Ваши символы будут изолированы от Вашей среды заказчика в dll.

Если Вы действительно хотите иметь интеллектуальные указатели и другую хорошую функциональность C++ в интерфейсе Вашей библиотеки, создать слой удобства, для которого Вы распределяете исходный код. Это удостоверится, что всегда компилируется в среде заказчика. Этот интерфейс затем вызывает Ваши выставленные функции C умными способами. Я не думаю, что это - хорошая идея использовать повышение того слоя или так как это вынудит Ваших клиентов принять его, даже если они не захотят, однако легко заменить его или найти другое решение, так как тот слой распределяется как исходный код.

Другая хорошая функция - то, что обычно легче вызвать функции C в dll, чем функции C++ со странным искажением имени, если Вы хотите подвергнуть свою библиотеку другим языкам, чем C/C++.

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

Это - интересный вопрос, который я имел в течение некоторого времени. Вы вынуждаете своих пользователей в любую библиотеку, Вы обеспечиваете или позволяете им выбрать то, что является лучшим в их проекте? Как всегда, вопрос - то, что Вы предлагаете и чего Вы требуете от пользователя.

При использовании необработанных указателей Вы позволяете все виды возможностей. Пользовательский код может использовать необработанный указатель, сохранить его в станд.:: auto_ptr, shared_ptr (или повышение или TR1), или их homebrewed версия интеллектуального указателя. Но это может также получить пользователя в проблему, если они забывают освобождать память, и требуется еще некоторый код в их стороне, если они просто хотят временный файл, созданный для вызова метода (если Вы обеспечиваете необработанные указатели, они должны будут сохранить указатель в невременном файле [возможно умный] переменная указателя).

Теперь при использовании интеллектуального указателя, Вы вызываете свое решение в пользователя. Если они планируют использование их собственной версии интеллектуального указателя (скажите использование повышения:: shared_ptr и они хотят станд.:: tr1:: shared_ptr) им больше не разрешают использовать его, если они работают с Вашим интерфейсом. Безотносительно интеллектуального указателя Вы выбираете (помимо станд.:: auto_ptr, который является особенным) Вы не только вызываете решение, но также и проблемы, которые он имеет.

Если у Вашего пользователя есть многопоточное приложение, и Ваше решение не ориентировано на многопотоковое исполнение, пользователь связывается с небезопасным решением. Если, с другой стороны, интеллектуальный указатель ориентирован на многопотоковое исполнение, но несет расходы блокировки, те затраты продвинуты Вашим пользователям, даже если они работают в многопоточном приложении. При компиляции библиотеки (не заголовок только lib) затем, Вы вызываете не только тип интеллектуального указателя, но также и конкретную версию его, так как любые изменения в библиотеке интеллектуального указателя повредят совместимость Вашего кода.

Как примечание стороны, повышение:: shared_ptr (повышают 1.33 +) ориентирован на многопотоковое исполнение в большинстве ситуаций, и он использует свободную от блокировок реализацию во многих платформах. Так или иначе это должно дать Вам общее представление о вещах, которые необходимо рассмотреть.

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

повышение:: intrusive_ptr, возможно?

Используйте auto_ptr или придерживайтесь интерфейса на Си. Принуждение C++ libs в ваш интерфейс всегда некрасиво, убивает любой шанс быть кроссплатформенным и вызывает кошмар сопровождения для клиентов с различными "downstream" конфигурациями.

Как только C++0x станет достаточно популярным для ваших клиентов, переходите на std::shared_ptr.

введение boost :: shared_ptr заставляет вашего клиента использовать boost. для некоторых это второстепенная проблема.

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