Namespace. Красивая иерархия или удобное использование

@Kertis138 · Регистрация: 25.02.2016

Студворк — интернет-сервис помощи студентам

Здравствуйте!

Для более логичного деления библиотеки использую иерархические namespace.

C++
1
2
3
4
5
6
7
8
9
10
11
12
namespace lib 
{
   
    namespace system { /*..*/ }
 
    namespace classes { /*..*/ }
 
    namespace tool { /*..*/ }
 
    /* и тд */
 
}

То есть по сути пространства имен практически полностью повторяют структуры файловой системы.
Правильно ли это? Или лучше использовать одно глобальное пространство lib ??

Если уровень вложенности большой - 2/3/4, то в cpp писать A::B::C::... не очень красиво...
Подскажите, что в таком случае верно?

И насчет файловой системы: подскажите, как лучше хранить файлы? Придерживаться логической иерархии как и с namespace или же все в одну папку (как по умолчанию делает VS)? VS все таки при создании фильтра не повторяет его в файловой системы, что не очень удобно.

.CPP лучше держать рядом с .H или делать ни Header/Source ?? Подскажите, как вы делаете? Что удобней и правильней?

@John Prick · 04.08.2017, 22:43

Я думаю, что каких-то железобетонных правил тут не существует. Всё зависит от конкретной задачи. Вот к примеру std или boost все используемые классы и функции кладут в основное пространство имён, но сколько там вложенных нэймспейсов - одному богу известно.

На счёт как хранить сами файлы на диске - тут тоже дело вкуса. Если это библиотека для стороннего использования, то обычно там предоставляют хэдеры и уже скомпилированный код, либо все исходники и какой-нибудь скрипт, который сам всё соберёт вашим компилятором, либо же файлы-проекты под самые популярные IDE - и собирайте сами (там уже всё будет подключено). А если это ваш проект, то тут хозяин == барин, как больше нравится, так и храните.

@Kertis138 · 05.08.2017, 05:24 **[ТС]**

Сообщение от John Prick

На счёт как хранить сами файлы на диске - тут тоже дело вкуса.

Мне интересно как делают другие, чтобы посмотреть некоторые идеи и найти что-то свое.

@Rolldan · 05.08.2017, 12:07

Сообщение от Kertis138

пространства имен практически полностью повторяют структуры файловой системы.
Правильно ли это?

Нет, неправильно. Пространства имён должны делить код на логические части, которые чаще всего не совпадают со структурой файловой системы.

Сообщение от Kertis138

Если уровень вложенности большой - 2/3/4, то в cpp писать A::B::C::... не очень красиво...
Подскажите, что в таком случае верно?

В данном случае (при длинных namespace) следует использовать директиву using namespace, в которой задавать для длинного namespace псевдоним. Слишком длинные namespace (больше 3-4 уровней вложенностей) не рекомендуются.

Сообщение от Kertis138

И насчет файловой системы: подскажите, как лучше хранить файлы? Придерживаться логической иерархии как и с namespace или же все в одну папку

Основной принцип такой: при просмотре списка файлов в файловом менеджере (в режиме таблицы), они должны помещаться на 1-2 экранах прокрутки. То есть, не более 30-50 файлов в папке. Так удобнее с ними работать. Но и когда много папок по 2-4 файла это тоже неудобно, и сложно что-то найти. Надо придерживаться середины, в зависимости от обстоятельств.

Сообщение от Kertis138

.CPP лучше держать рядом с .H

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

@Kertis138 · 05.08.2017, 12:54 **[ТС]**

Сообщение от cordfield

Лучше .cpp и .h держать рядом, если это внутренние файлы проекта.

А папки Header/Source, который полностью идентичны, за исключением того, что в одной .H, а в другой .CPP файлы - не подойдет?

@Rolldan · 05.08.2017, 13:31

Kertis138, деление на header/source возможно, но для меня непонятны преимущества. Минусы следующие:
- Visual Studio часто не может использовать функцию "Toggle Header/Source" - быстрого перехода от заголовочного файла к реализации и обратно
- Приходится в папках header/source дублировать иерархию подпапок, если проект сложный. При этом в файловом менеджере управлять этими файлами становится трудно. Например, в стандартном проводнике, можно выделить 2 файла .h и соответствующий ему .cpp, нажать F2 и переименовать разом оба файла.

@GbaLog- · 05.08.2017, 16:03

Сообщение от cordfield

В данном случае (при длинных namespace) следует использовать директиву using namespace

бред.
вообще стоит забыть про то, что такой способ существует.
он имеет место быть разве что в области видимости отдельно взятой функции.
для подобных ситуаций в c++ есть namespace aliasing.
http://en.cppreference.com/w/c... pace_alias

@Rolldan · 05.08.2017, 16:42

GbaLog-, я так и написал, читай внимательно:

Сообщение от cordfield

следует использовать директиву using namespace, в которой задавать для длинного namespace псевдоним

Сам я этим не пользуюсь, поэтому забыл, что при задании псевдонима не надо писать слово using.

@GbaLog- · 05.08.2017, 17:52

Сообщение от cordfield

следует использовать директиву using namespace, в которой задавать для длинного namespace псевдоним

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

Новые блоги и статьи Все статьи Все блоги /
Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .	Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .
Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .	Создание Single Page Application на фреймах krapotkin 16.11.2025 Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .	Фото: Daniel Greenwood kumehtar 13.11.2025	Расскажи мне о Мире, бродяга kumehtar 12.11.2025 — Расскажи мне о Мире, бродяга, Ты же видел моря и метели. Как сменялись короны и стяги, Как эпохи стрелою летели. - Этот мир — это крылья и горы, Снег и пламя, любовь и тревоги, И бескрайние. . .

@John Prick 2393 / 1913 / 763 Регистрация: 27.07.2012 Сообщений: 5,553
	04.08.2017, 22:43
	Я думаю, что каких-то железобетонных правил тут не существует. Всё зависит от конкретной задачи. Вот к примеру std или boost все используемые классы и функции кладут в основное пространство имён, но сколько там вложенных нэймспейсов - одному богу известно. На счёт как хранить сами файлы на диске - тут тоже дело вкуса. Если это библиотека для стороннего использования, то обычно там предоставляют хэдеры и уже скомпилированный код, либо все исходники и какой-нибудь скрипт, который сам всё соберёт вашим компилятором, либо же файлы-проекты под самые популярные IDE - и собирайте сами (там уже всё будет подключено). А если это ваш проект, то тут хозяин == барин, как больше нравится, так и храните. 1

@Rolldan 44 / 44 / 19 Регистрация: 04.05.2014 Сообщений: 190
	05.08.2017, 13:31
	Сообщение было отмечено Kertis138 как решение Решение Kertis138, деление на header/source возможно, но для меня непонятны преимущества. Минусы следующие: - Visual Studio часто не может использовать функцию "Toggle Header/Source" - быстрого перехода от заголовочного файла к реализации и обратно - Приходится в папках header/source дублировать иерархию подпапок, если проект сложный. При этом в файловом менеджере управлять этими файлами становится трудно. Например, в стандартном проводнике, можно выделить 2 файла .h и соответствующий ему .cpp, нажать F2 и переименовать разом оба файла. 1

Namespace. Красивая иерархия или удобное использование

Решение