LINUX.ORG.RU

C++ namespace policy

 ,


1

5

В .net/Java мире принято делать внешнее пространство имён как namespace <company name>. Я в своей плюсовой практике такого не встречал. Есть какие-нибудь мнения за и против?

★★★★★

Последнее исправление: UVV (всего исправлений: 1)

Я в паре контор встречал такое. Плюс ещё в UBS когда работал там было правило в coding standards делать C++ namespaces в стиле джава классов: com::ubs::zhopa::anus::govno::MyClass.

DELIRIUM ☆☆☆☆☆
()

Аргумент против: после таких namespace остаётся только использовать using везде, иначе неюзабельно, но в C++ нет никакого автоматического импорта при использовании using, и #include/using всегда идут раздельно.

Поэтому я предпочитаю плоские namespace, глубина вложенности более 1 разумна только для специальных пространств имён типа `std::chrono_literals` или `mylibrary::details`.

quiet_readonly ★★★★
()

смысл namespace есть, смысла делать именем компании нет

anonymous
()
Ответ на: комментарий от quiet_readonly

более, того, в .h using namespace де-факто нельзя использовать

в результате, от namespace лучше вообще воздерживаться

например, в qt нет namespace

next_time ★★★★★
()
Ответ на: комментарий от next_time

Что-то с логикой у вас совсем не лады. Да, using в .h нельзя. Нет, никакого такого «результата» что от namespace лучше воздержаться нет.

anonymous
()

возможно, так они пытаются гарантировать, что пространства имён разных библиотек не будут пересекаться. типа, если считать, что имя компании уникально.

вообще, если пространство имён можно сделать, то лучше его делать. пересечения имён - большая головная боль. лучше перебдеть, чем недобдеть. проблем они не создают, зато потенциальные конфликты могут разрешить.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)

Есть какие-нибудь мнения за и против?

слишком много писать - утомляет и в глазах рябит.

Потому что

version::country::company_name::domain::application::module::submodule
Уже перебор.

invy ★★★★★
()
Последнее исправление: invy (всего исправлений: 1)

Namespace - это слабое место Си++ из-за особенностей файлов хедеров *.h. Namespace не очень-то и удобно делать длинными в отличие от Java и .NET.

Тоже не встречал namespace с {company name} в своей практике.

dave ★★★★★
()
Последнее исправление: dave (всего исправлений: 1)
Ответ на: комментарий от invy

обычно внешние интерфейсы и экспортируемые функции имеют довольно низкий уровень вложенности неймспейсов. а модули и подмодули - это уже внутренности библиотеки. зато если придётся компилять разные куски статически, это может очень облегчить жизнь.

Iron_Bug ★★★★★
()
Ответ на: комментарий от dave

Namespace - это слабое место Си++ из-за особенностей файлов хедеров *.h. Namespace не очень-то и удобно делать длинными в отличие от Java и .NET.

А в чем разница в написании длинного неймспейса в CLion и IDEA/Java?

xpahos ★★★★★
()

В uno(api open office) используется и встречается в com.

В исконно плюсовых вещах - тоже не встречал.

pon4ik ★★★★★
()

Есть какие-нибудь мнения за и против?

Мне вот интересно :-) Почему у *тебя* нет своего собственного мнения? :-) Почему ты по такому суетливому поводу спрашиваешь мнения некоего сообщества? :-) Какая кому разница, где твои классы или функции будут определены? :-) Если они будут реально что-то из себя представлять, то, поверь, всем будет безразлично что писать using lib = my::super:cool::lib; lib::cool_function, что просто lib::cool_function :-) Важно не то, где ты определил что-то там из своих фантазий, а то, что именно делает твоё творение :-) Разве ты до сих пор ещё не понял? :-) Лол :-_

anonymous
()

Имя компании как неймспейс еще имеет смысл, если это отдаваемая вовне библиотека. У нас так и используется

CatsCantFly
()
Ответ на: комментарий от dave

Как по мне - сильно вложенные namespace даже в C# и Java - перебор.

peregrine ★★★★★
()
Ответ на: комментарий от CatsCantFly

Название библиотеки (осмысленное) на самом деле лучше в роли namespace, хотя попиарить компанию приятно для руководства и части сотрудников.

peregrine ★★★★★
()
Ответ на: комментарий от xpahos

Лучше рекомендации Саттера и Александреску почитать

dave ★★★★★
()
Ответ на: комментарий от anonymous

Мне вот интересно :-) Почему у *тебя* нет своего собственного мнения? :-)

Вот это тебя бомбануло! А я считаю, что человек просто старается сделать, как правильно, и в этом нет ничего плохого.

Важно не то, где ты определил что-то там из своих фантазий, а то, что именно делает твоё творение :-)

Угу, насмотрелись уже на такие вроде бы нужные творения, когда программа-то полезная, хочешь пропатчить - а внутри эпичный говнокод, приправленный кучей костылей, чтобы работало.

anonymous
()
Ответ на: комментарий от anonymous

А я считаю, что человек просто старается сделать, как правильно, и в этом нет ничего плохого.

«Правильно» - это значит в соответствии с какими-то правилами :-) Кто-то следует своим, а кто-то - чужим правилам :-)

Угу, насмотрелись уже на такие вроде бы нужные творения, когда программа-то полезная, хочешь пропатчить - а внутри эпичный говнокод, приправленный кучей костылей, чтобы работало.

Определение кода в каком-нибудь неймспейсе com::example::project от костылей не избавит :-)

anonymous
()
Ответ на: комментарий от anonymous

«Правильно» - это значит в соответствии с какими-то правилами :-) Кто-то следует своим, а кто-то - чужим правилам :-)

правильно. молодец.

anonymous
()
Ответ на: комментарий от anonymous

результат заключается в явном прописывании неймспейсных префиксов, как минимум, в заголовочнике и к нему ещё using namespace в реализации, из-за чего страдает читабельность.

но зачем? если свою библиотеку для общего пользования не пишите

next_time ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.