Использование stl-контейнеров без указателей наддува

Question

Моя компания в настоящее время не завоевана библиотеками Boost, и, хотя я использовал их и заставлял их продвигаться для какой-то работы, некоторым проектам из-за их характера не будет разрешено использовать Boost. В основном библиотеки, такие как Boost, не могут быть использованы для работы, поэтому я ограничен библиотеками, доступными по умолчанию (в настоящее время используется Visual Studio 2005).

Итак ... Мой вопрос: если я не могу использовать Boost :: shared_ptr и его младших братьев, какова альтернатива при использовании контейнеров STL с указателями?

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

Answer 1

Если они не собираются принимать повышение, я предполагаю, что другие «не разработанные здесь» библиотеки исключены.

Мне кажется, у вас есть два варианта:

• Сверните свой собственный shared_ptr.
• Используйте сырые указатели и управляйте памятью самостоятельно.

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

Answer 2

В Visual Studio 2008 доступно std::tr1::shared_ptr. Я не уверен, что он доступен в VS2005, вы должны проверить.

Answer 3

Это определенно зависит от того, что вы хотите сделать. Нельзя сказать, что shared_ptr абсолютно необходим для проекта, использующего указатели.

Если они вам действительно нужны, импортируйте те классы / шаблоны / функции, которые вам действительно нужны, в свой собственный проект, если это возможно, без импорта всей библиотеки Boost.

Answer 4

Не зная предыстории, трудно сказать, почему библиотеки boost не разрешены.Если причина состоит в том, чтобы избежать сложных зависимостей, вы можете легко обойти эту проблему: почти все библиотеки boost работают только с простым заголовком #include: короче говоря, они не нуждаются в связывании и, таким образом, избегают dll-hell или любого его варианта.

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

Для ясности и упрощения будущих обновлений и обслуживания, я бы не стал переименовывать библиотеки повышения (чтобы будущие кодеры знали, откуда появился код).Если «они» не хотят таких простых включений в код, ну, вы можете привести аргумент, что немало надстроечных заголовков направлено на включение в спецификацию, и что они сэкономят всем кучу головных болей и времени.С юридической точки зрения лицензия на буст специально разработана для максимально простой и безопасной интеграции: все файлы имеют явную лицензию, которая разрешает все соответствующие действия, и почти все библиотеки имеют одинаковую лицензию.

ЯЛюбопытно, почему именно буст-заголовки не разрешены?