Внутрішні типи в C ++ - хороший стиль чи поганий стиль?

Щось, чому я останнім часом часто зустрічаюсь, - це оголошення typedefs, що стосуються певного класу всередині цього класу, тобто

class Lorem
{
    typedef boost::shared_ptr<Lorem> ptr;
    typedef std::vector<Lorem::ptr>  vector;

//
// ...
//
};

Ці типи потім використовуються в іншому місці коду:

Lorem::vector lorems;
Lorem::ptr    lorem( new Lorem() );

lorems.push_back( lorem );

Причини, які мені подобаються:

• Він зменшує шум, що вводиться шаблонами класів, std::vector<Lorem>стає Lorem::vectorтощо.
• Він служить як заява про наміри - у наведеному вище прикладі клас Lorem призначений для посилання, що підраховується через boost::shared_ptrі зберігається у векторі.
• Це дозволяє змінювати реалізацію - тобто якщо Лорему потрібно було змінити, щоб настирливо посилатись (через boost::intrusive_ptr) на наступному етапі, то це мало б мінімальний вплив на код.
• Я думаю, що це виглядає «красивіше» і його, мабуть, легше читати.

Причини, які мені не подобаються:

• Іноді виникають проблеми із залежностями - якщо ви хочете вставити, скажімо, Lorem::vectorв інший клас, але потрібно лише (або хочете) переслати оголошення Lorem (на відміну від введення залежності у його заголовок), тоді вам доведеться використовувати явні типи (наприклад, boost::shared_ptr<Lorem>а не Lorem::ptr), що трохи непослідовно.
• Це може бути не дуже часто, а значить, важче зрозуміти?

Я намагаюся бути об'єктивним зі своїм стилем кодування, тому було б добре отримати деякі інші думки щодо нього, щоб я міг трохи розсікати своє мислення.

Я вважаю, що це відмінний стиль, і я ним сам користуюся. Завжди краще максимально обмежити область імен, а використання класів - найкращий спосіб зробити це в C ++. Наприклад, бібліотека стандарту C ++ широко використовує typedefs в межах класів.

Він служить заявою про наміри - у наведеному вище прикладі клас Lorem призначений для посилання, що підраховується через boost :: shared_ptr і зберігається у векторі.

Це саме те, що він не робить.

Якщо я бачу в коді "Foo :: Ptr", я абсолютно не маю уявлення, чи це спільний_ptr або Foo * (у STL є: typedefs вказівника, що є T *, пам’ятайте) або будь-що інше. Esp якщо це спільний покажчик, я взагалі не надаю typedef, але зберігаю явно використовувати код shared_ptr у коді.

Насправді я навряд чи використовую typedefs поза метапрограмуванням шаблонів.

STL робить цей тип речі весь час

Дизайн STL з поняттями, визначеними з точки зору функцій-членів та вкладених typedefs - це історичний культ, сучасні бібліотеки шаблонів використовують вільні функції та класи ознак (пор. Boost.Graph), оскільки вони не виключають вбудованих типів із моделювання концепції та тому, що це спрощує адаптацію типів, які не були розроблені з урахуванням концепцій бібліотек шаблонів.

Не використовуйте STL як причину робити однакові помилки.

Typedefs - це те, на чому заснований на політиці дизайн та риси, побудовані в C ++, тому сила родового програмування на C ++ випливає з самих typedefs.

Typdefs, безумовно, хороший стиль. І всі ваші "причини, які мені подобаються" - хороші і правильні.

Про проблеми, які у вас є з цим. Ну, авансова декларація - це не святий грааль. Ви можете просто розробити код, щоб уникнути багаторівневих залежностей.

Ви можете перемістити typedef поза класом, але Class :: ptr настільки гарніший, ніж ClassPtr, що я цього не роблю. Це як з просторами імен, як на мене - речі залишаються пов'язаними в межах сфери.

Іноді я

Trait<Loren>::ptr
Trait<Loren>::collection
Trait<Loren>::map

І це може бути за замовчуванням для всіх класів домену та з певною спеціалізацією для певних.

STL постійно займається цим типом речі - typedefs є частиною інтерфейсу для багатьох класів STL.

reference
iterator
size_type
value_type
etc...

- це всі typedefs, які є частиною інтерфейсу для різних класів шаблонів STL.

Ще один голос за те, що це гарна ідея. Я почав це робити, коли писав моделювання, яке повинно було бути ефективним як у часі, так і в просторі. Усі типи значень мали тип Ptrdedef, який починався як загальний покажчик підвищення. Потім я зробив декілька профілів і змінив деякі з них на посилений нав'язливий покажчик, не змінюючи жодного коду, де ці об’єкти використовувалися.

Зауважте, що це працює лише тоді, коли ви знаєте, де будуть використовуватися класи, і що для всіх застосувань є однакові вимоги. Я б не використовував це в коді бібліотеки, наприклад, тому що ви не можете знати при написанні бібліотеки контекст, в якому вона буде використовуватися.

В даний час я працюю над кодом, який інтенсивно використовує такі типи typedefs. Поки це добре.

Але я помітив, що досить часто є ітеративні typedefs, визначення розділені між кількома класами, і ви ніколи не знаєте, з яким типом ви маєте справу. Моє завдання - узагальнити розмір деяких складних структур даних, прихованих за цими typedefs - тому я не можу покластися на існуючі інтерфейси. У поєднанні з трьома-шести рівнями вкладених просторів імен, і тоді це стає заплутаним.

Тому перед їх використанням слід врахувати деякі моменти

• Хтось ще потребує цих типів? Чи багато використовується класом в інших класах?
• Чи я скорочую використання чи приховую клас? (У разі приховування ви також можете подумати про інтерфейси.)
• Чи працюють інші люди з кодом? Як вони це роблять? Вони вважатимуть, що це простіше, чи заплутаються?

Рекомендую перемістити ці типи типів поза класом. Таким чином ви видаляєте пряму залежність від загальних класів вказівників та векторів і можете включати їх лише за потреби. Якщо ви не використовуєте ці типи у своїй реалізації класу, я вважаю, що вони не повинні бути внутрішніми типами.

Причини, які вам подобаються, як і раніше узгоджуються, оскільки вони вирішуються типом псевдоніму через typedef, а не шляхом їх оголошення у вашому класі.

Коли typedef використовується лише в самому класі (тобто оголошується приватним), я вважаю, що це гарна ідея. Однак, саме з наведених вами причин, я б не використовував його, якщо типdef повинен бути відомий поза класом. У такому випадку я рекомендую перемістити їх поза класом.