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