Это - хороший стиль для сокрытия shared_ptr позади определения типа?
Я хотел бы уменьшить некоторый визуальный шум в коде и скрыться shared_ptr позади определения типа как это:
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);
С другой стороны, я волнуюсь, что уменьшаю явность кода.
Который является лучшим стилем?
4 ответа
Учитывая, что std :: string сам по себе является typedef, я думаю, у вас все в порядке. Я сам это делаю.
Даже Скотт Мейерс рекомендует typedef для облегчения чтения кода в случаях, подобных вашему.
РЕДАКТИРОВАТЬ: Эффективный C ++, второе издание, стр. 120, пункт 28, четвертый абзац. «... предоставить определения типов, которые устраняют необходимость ...»
Более эффективный C ++, седьмая печать, стр. 237, элемент 31 Первый абзац.
Более эффективный C ++, 7-е издание, стр. 238, пункт 31 Первый абзац после образца кода.
По сути, не беспокойтесь. : -)
Мы используем TypePtr в нашем коде для shared_ptr объектов. Также полезно иметь TypeConstPtr для shared_ptr.
Я как бы против определений типов, которые скрывают, являются ли объекты реальными указателями (или ссылками), поскольку я видел слишком много нечитабельного кода C, который делает это. Но, применяя некоторую казуистику, я предполагаю, что shared_ptrs не являются настоящими указателями, и поэтому typedef в порядке. Но вы теряете информацию - вы больше не можете сказать, просто взглянув на объявление (или определение!) Функции, какова ее семантика.
Вы можете назвать typedef 'SomeLongClassSharedPtr', что и явно, и легко.
Негативным последствием этой практики является то, что некоторые реализации автозаполнения (например, в Eclipse CDT) не справляются с ней. Однако лично меня это не останавливает от его использования.