Я хотел бы уменьшить некоторый визуальный шум в коде и скрыть shared_ptr за typedef следующим образом:
typedef boost::shared_ptr<SomeLongClass> SomeLongClassPtr;
Итак, это:
void foo(const boost::shared_ptr<SomeLongClass>& a,
boost::shared_ptr<SomeLongClass>& b);
становится следующим:
void foo(const SomeLongClassPtr& a, SomeLongClassPtr& b);
С другой стороны, я беспокоюсь, что я уменьшаю объяснительность кода.
Какой стиль лучше?
Учитывая, что std::string сам является typedef, я думаю, что все в порядке. Я делаю это сам.
Даже Скотт Майерс рекомендует typedef для удобства чтения кода в таких случаях, как ваш.
EDIT: Эффективное С++, второе издание, стр. 120, пункт 28, четвертый абзац. "... предоставить typedefs, которые устраняют необходимость..."
Более эффективный С++, 7-й печать, Страница 237, пункт 31 Первый абзац.
Более эффективный С++, 7-й печать, Страница 238, Item 31 Первый абзац после примера кода.
По существу, не стоит беспокоиться.: -)
Мы используем TypePtr typedefs в нашем коде для объектов shared_ptr<Type>. Также полезно иметь a TypeConstPtr для shared_ptr<const Type>.
Вы можете назвать typedef 'SomeLongClassSharedPtr', который явный и простой для ввода.
Негативным следствием этой практики является то, что некоторые реализации автозаполнения (например, в Eclipse CDT) не проходят через нее. Это не остановило меня лично от его использования, хотя.
Я вроде как против typedefs, которые скрывают, являются ли вещи реальными указателями (или ссылками), увидев слишком много нечитаемого кода на C, который это делает. Но, применяя некоторые казуистики, я думаю, shared_ptrs не являются настоящими указателями, и поэтому typedef в порядке. Но вы теряете информацию - вы уже не можете сказать, просто посмотрев на объявление функции (или определение!), Какова ее семантика.