Они немного устарели, да. Но часть этих книг в том, что эти шаблоны полезны на нескольких языках и в разных стилях. Поэтому, хотя код немного устарел, идеи, лежащие в его основе, - нет, и именно эти идеи важны в этих книгах.
Я хотел бы увидеть некоторые реализации шаблонов, использующие преимущества методов метапрограммирования. Я сильно подозреваю, что некоторые шаблоны, такие как Bridge, Adapter и, возможно, Facade, гораздо менее утомительны для реализации с помощью метапрограммирования. Из другого ответа и прочтения описания это выглядит так: Современный дизайн C ++: применены общие шаблоны программирования и проектирования может быть хорошей книгой для такого рода вещей. Я не могу лично за это поручиться.
Помимо возможного использования универсальных методов программирования и шаблонов, основные отличия заключаются в том, что голые указатели в C ++ в наше время встречаются редко. Существуют эффективные типы интеллектуальных указателей, которые обычно следует использовать вместо этого, поскольку они решают многие проблемы управления ресурсами для вас. Честно говоря, если вы не очень хорошо знаете, что делаете, я бы в любом случае не рекомендовал бы использовать общий дизайн на основе программирования.
Вот несколько примеров того, какие умные указатели можно использовать в различных контекстах. В этих примерах предполагается, что у вас есть C ++, который включает в себя расширения TR1 (Технический отчет 1):
Если у вас есть указатель на то, что полностью принадлежит объекту, указывающему на него, используйте ::std::auto_ptr (или ::std::unique_ptr в C ++ 1x). Помните, что ::std::auto_ptr нельзя хранить в контейнерах STL, но у ::std::unique_ptr нет этой проблемы. Примерами могут быть шаблон «Компонент» (если не было поделено двух подкомпонентов), шаблон «Фасад» и шаблон «Адаптер». Кроме того, шаблон Factory, вероятно, должен выдавать ::std::auto_ptr s (или ::std::unique_ptr s в C ++ 1x), если нет действительно веской причины для создания ::std::shared_ptr s.
Если у вас есть указатель на то, что имеет общее владение, используется ::std::tr1::shared_ptr. Например, шаблон Flyweight. Кроме того, в некоторых случаях шаблон компонента также может иметь это свойство. Это также может быть полезно в паттерне Bridge.
Если у вас есть указатель на то, что не принадлежит вам логически, тогда ::std::tr1::weak_ptr - путь. Имейте в виду, что если вы используете ::std::tr1::weak_ptr, вам также следует использовать ::std::tr1::shared_ptr для всех объектов, которые логически владеют (или совместно владеют) указанным объектом. Примером этого является шаблон Observer.