Хороший ли стиль скрыть shared_ptr за typedef?

Я хотел бы уменьшить некоторый визуальный шум в коде и скрыть 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);

С другой стороны, я беспокоюсь, что я уменьшаю объяснительность кода.

Какой стиль лучше?

Ответы

Ответ 1

Учитывая, что std::string сам является typedef, я думаю, что все в порядке. Я делаю это сам.

Даже Скотт Майерс рекомендует typedef для удобства чтения кода в таких случаях, как ваш.

EDIT: Эффективное С++, второе издание, стр. 120, пункт 28, четвертый абзац. "... предоставить typedefs, которые устраняют необходимость..."

Более эффективный С++, 7-й печать, Страница 237, пункт 31 Первый абзац.

Более эффективный С++, 7-й печать, Страница 238, Item 31 Первый абзац после примера кода.

По существу, не стоит беспокоиться.: -)

Ответ 2

Мы используем TypePtr typedefs в нашем коде для объектов shared_ptr<Type>. Также полезно иметь a TypeConstPtr для shared_ptr<const Type>.

Ответ 3

Вы можете назвать typedef 'SomeLongClassSharedPtr', который явный и простой для ввода.

Негативным следствием этой практики является то, что некоторые реализации автозаполнения (например, в Eclipse CDT) не проходят через нее. Это не остановило меня лично от его использования, хотя.

Ответ 4

Я вроде как против typedefs, которые скрывают, являются ли вещи реальными указателями (или ссылками), увидев слишком много нечитаемого кода на C, который это делает. Но, применяя некоторые казуистики, я думаю, shared_ptrs не являются настоящими указателями, и поэтому typedef в порядке. Но вы теряете информацию - вы уже не можете сказать, просто посмотрев на объявление функции (или определение!), Какова ее семантика.