Какова Ваша конвенция для typedef'ing shared_ptr?
Я - переброс зеркального отражения между соглашениями о присвоении имен для typedef'ing повышение:: шаблон shared_ptr. Например:
typedef boost::shared_ptr<Foo> FooPtr;
Прежде, чем обосноваться на конвенции, я хотел бы видеть то, что используют другие. Какова Ваша конвенция?
Править:
Тем вложение определение типа в Foo разве это не беспокоит Вас, что Foo теперь "знает" о том, как оно будет роздано? Это, кажется, повреждает инкапсуляцию. Как насчет этого:
class Foo
{
public:
typedef std::vector<Foo> Vector
};
Вы не сделали бы этого теперь, не так ли?:-)
9 ответов
Мое предпочтение:
class Foo
{
public:
typedef boost::shared_ptr<Foo> SharedPointer;
};
Проблема только с FooPtr в том, что у вас могут быть разные типы указателей (например, weak_ptr s). Аббревиатуры меня тоже не особо интересуют, но это совсем другое дело.
Мой первый ответ - спросить: «Почему typedef это?»
В ответ на вашу правку: На самом деле это довольно интересный подход, который может быть полезен во многих ситуациях. Используя его, чтобы вернуться к исходному вопросу, вы можете получить:
struct object
{
typedef object* ptr_t;
typedef shared_ptr<object> shared_ptr_t;
typedef weak_ptr<object> weak_ptr_t;
typedef unique_ptr<object> unique_ptr_t;
etc...
}
Я использовал как внешний, так и инкапсулированный typedef, но в итоге остановился на первом,
typedef boost::shared_ptr<Foo> FooPtr;
исключительно потому, что в комбинированных выражениях он выглядит чище, чем Foo :: Ptr .
Вас не беспокоит, что Foo теперь «знает» о том, как он будет передаваться?
Достаточно часто эти классы создаются только с помощью фабричного метода:
struct Foo
{
static FooPtr Create() { return FooPtr(new Foo); }
protected:
Foo() {}
}
Это вроде «сильнее», чем инкапсулирующий typedef, но очень распространенный шаблон.
Лично в коде, за который я отвечаю, вы обычно видите определение типа FooPtr в той же области пространства имен, что и Foo , а Foo будет содержать определение типа 'SmartPtr' с общим именем для тот же тип, что и FooPtr. Наличие FooPtr позволяет легко использовать неполную информацию вручную. наличие вложенного typedef для 'SmartPtr' или некоторого эквивалента позволяет легко использовать универсальное в шаблонах, макросах и т. д. без необходимости знать этот фактический тип интеллектуального указателя.
Также я бы посоветовал добавить к этому вопросу метку «субъективный».
Ответ: не делайте этого. Это удобно вам и никому другому. Скажи что ты имеешь в виду.
Это было одно из условностей, к которым я прибегал:
typedef boost::shared_ptr<Foo> FooProxy;
... видя, что boost :: shared_ptr является приложение шаблона Прокси .
Приятно, когда он заканчивается на _t .
class Bar
{
public:
typedef boost::shared_ptr<Bar> Ptr_t;
};
Я не большой поклонник венгерских соглашений об именах, я обычно использую:
typedef boost::shared_ptr<Foo> FooSharedPtr;
Достаточно подробный, чтобы быть понятным, но достаточно короткий, чтобы не быть огромным хлопот. В любом случае, я бы определенно указал, что это конкретно общий указатель, особенно если вы не единственный, кто будет использовать этот тип в будущем.
Я обычно инкапсулирую typedef внутри класса. Причина в том, что у нас есть код, чувствительный к памяти, и он позволяет легко переключаться между boost :: shared_ptr и boost :: intrusive_ptr
Поскольку intrusive_ptr - это что-то что класс должен поддерживать, для меня имеет смысл знать, какой общий указатель использовать в классе.