Привет
помогите принять решение

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

пока оно всё лежит в одном большом namespace, к примеру назовём just::
и мне это не особо нравится

Рассматриваю для начала два варианта:

#1. Вложенные пространства имён
just::ui::
just::st::
Плюсы: В частях будут видны общие определения из just::
Минусы:
* выглядит не очень (нагромождение resolution operators)
чтобы достучаться до типа это 3 штуки писать вместо двух (just::st::bla_bla вместо just::bla_bla)

#2. Отдельные верхнеуровневые пространства
just_st::
just_ui::
just_flags::
Минусы:
* общие определения остаются в just:: и в частях придётся писать длиннее, либо делать using namespace just;
* пользователю может это не понравится, что либа фигачит несколько верхних нэймспейсов

#3. мда
оставить всё в одном just::
Но сделать префиксы у самих определений
just::st_concat<>
just::st_concat_separated<>
just::st_literals // sub namespace
just::ui_button
just::ui_form

	hide
	И не парить никому мозг своими префиксами t_ в именах типов)

Минусы: word complete (inteli sense)
Сейчас Когда набираю имя и знаю точно что нужен тип, то сразу отсекаю остальное по префиксу t_
* И это пропадёт в таком варианте #3.

p/s:
4. Рассмотрю ещё предложения и другие идеи

Здравствуйте, Sm0ke, Вы писали:

S>4. Рассмотрю ещё предложения и другие идеи

А можно ещё оставить всё как есть, то есть just::. По сути все твои предложения сводятся к созданию ненужной смысловой нагрузки для систематизации.
1. Первый вариант вложенные пространства имён.
2. Второй вариант несколько пространств имён одного уровня (окончания).
3. Третий вариант вариации на тему венгерской нотации (приставки).

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

Запись большого количества знаний без систематизации

И вот тут возникает другая проблема. Чужой источник знаний можно не систематизировать. Книгу записать согласно оглавлению. Код согласно файловой системе. Но с собственными знаниями такой трюк не прокатит, так как они фрагментарны.

Да, мозгу гораздо проще выхватывать фрагменты с источника знаний, обрабатывать, и возвращать в источник знаний в виде изменений создавая новые знания. Потому при систематизации личной базы знаний важно уметь добавлять знания с отложенной систематизацией.

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

1. Выдели предметные каталоги, у тебя это just::.
2. Положи туда все понятия, которые посчитаешь нужными.
3. Получай доступ к понятиям с помощью предметного каталога.
*. Можешь когда-нибудь создать документацию в котором понятия из предметного каталога будут систематизированы.

Вот так оно должно выглядеть в алфавитном порядке, если считать классы и шаблоны имён в одном предметном каталоге.

just::button
just::concat<>
just::concat_separated<>
just::form

Что касается подпространств имён, таких как

just::literals:: // sub namespace

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

По моей теории допустимо разделять на предметные каталоги и на предметные подкаталоги входящие в предметные каталоги по типу элементов, но не по систематизации.

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

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

distros
 1c
 3dobjectconverter
 3dsmax
 7zip
 adobeaftereffects
 adobedreamweaver
 aida64
 akapella
 alcohol
 alfresco
 alldup
 androidstudio
 anki
 aomeipartitionassistant
 archicad
 arduinoide
 asciiartstudio
 audacity
 autocad
 ...

И так же всё остальное, типа anime, audiobooks, books, distros, lessons, manga, movies, music, podcast, ranobes, serials, youtube. С этой системой я наконец получил огромное преимущество, предотвращающее превращение диска в файлопомойку из интернета.

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

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

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

В предметном каталоге just:: можно объединить шаблоны+классы, может даже +перечисления, так как это типы созданные пользователем. Сделать подкаталог литералов just::literals::, потому что литералы это не типы созданные пользователем, а закодированные данные.

И пространство имён сделает из этих данных единый модуль. Опять же это может быть удобно чтобы всякая мелочь не мешалась в главном предметном каталоге типов определяемых пользователем. Или можно покурить тему насчёт статических литералов в классе или структуре, то есть сделать так just::literals, а не так just::literals::.

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

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

Тот же Qt просто огромный, но там люди не стали извращаться с кучей пространств имён. Буковка Q вначале это конечно не путь тру программиста C++, но одно пространство имён для всей библиотеки алгоритмов вполне. А для исполняемой программы можно ничего не делать, и так сойдёт.

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

Здравствуйте, Sm0ke, Вы писали:

S>Привет
S>помогите принять решение

Сам перешел от 3-го варианта к 1-му. Для меня стало намного удобнее. На практике длина имен с префиксом и с указанием пространства имен не отличается, по сути это тоже самое, но появились дополнительные плюсы:
— внутри подсистемы не нужно указывать префикс
— названия становятся короче из-за контекста
— часто в локальном контексте можно сделать using some_namespace и работать без префиксов.
— выбор названий подсистем стал понятнее и осмысленнее

У меня прижился первый вариант

Здравствуйте, Sm0ke, Вы писали:

S>#1. Вложенные пространства имён
S>just::ui::
S>just::st::
S>Плюсы: В частях будут видны общие определения из just::
Этот бери.
S>Минусы:
S>* выглядит не очень (нагромождение resolution operators)
S>чтобы достучаться до типа это 3 штуки писать вместо двух (just::st::bla_bla вместо just::bla_bla)
Есть алиасы

Здравствуйте, velkin, спасибо за ответ

Вы писали

V>Что касается подпространств имён, таких как
V>

V>just::literals:: // sub namespace
V>

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

V> ...

V>В предметном каталоге just:: можно объединить шаблоны+классы, может даже +перечисления, так как это типы созданные пользователем. Сделать подкаталог литералов just::literals::, потому что литералы это не типы созданные пользователем, а закодированные данные.

V>И пространство имён сделает из этих данных единый модуль. Опять же это может быть удобно чтобы всякая мелочь не мешалась в главном предметном каталоге типов определяемых пользователем. Или можно покурить тему насчёт статических литералов в классе или структуре, то есть сделать так just::literals, а не так just::literals::.

В namespace literals только литеральные операторы operator "" _st () т.е. описание способов формирования данных.
На них делается using namespace в пользовательском коде.
Например для использования "123"s из стандартной библиотеки предварительно пишут using namespace std::string_literals;
Или using namespace std::literals::string_view_literals для "abc"sv

Эти операторы можно ли делать как статические методы структуры? Будут ли они работать в этом случае?

--

По воводу префиксов я писал

S> Минусы: word complete (inteli sense) Сейчас Когда набираю имя и знаю точно что нужен тип, то сразу отсекаю остальное по префиксу t_

Оказывается в ide есть фильтр при автокомплите слов


(_All, Vars Fns Types Ns Interfaces)

Так что скорее всего уберу у типов префикс t_

--

Далее вы писали

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

V>Можешь попробовать разные варианты сам. Я ведь тоже до предметных каталогов пробовал всякое, в том числе с пространствами имён, и получалась всякая ерунда, которая не давала мне ничего, но требовала "обслуживания" на каждом шагу написания кода.

Действительно замедляет разработку
так что мне это Знакомо

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

	cut
	Была недолгая мысль оформить без namespace j_concat j_button Всё в глобал, кроме литералов j_literals_st // namespace для j_static_text operator "" _st j_literals // namespace для всех литералов текущей библиотеки Идея с j_ в глобал мне кажется сомнительной, но красивой

V>Я последний раз повторю главную мысль, чисто технически пространства имён созданы не для систематизации, а для того, чтобы имена созданные разными независимыми группами программистов объединяемые в одном проекте не пересекались.

I see

Здравствуйте, Videoman, Вы писали:

V>Здравствуйте, Sm0ke, Вы писали:

S>>Привет
S>>помогите принять решение

V>Сам перешел от 3-го варианта к 1-му. Для меня стало намного удобнее. На практике длина имен с префиксом и с указанием пространства имен не отличается, по сути это тоже самое, но появились дополнительные плюсы:
V>- внутри подсистемы не нужно указывать префикс
V>- названия становятся короче из-за контекста
V>- часто в локальном контексте можно сделать using some_namespace и работать без префиксов.
V>- выбор названий подсистем стал понятнее и осмысленнее

V>У меня прижился первый вариант

В таком случае возможно для concat() будут отдельные определения, а не перегрузка
just::st::concat<>() // для compile-time текста в параметрах шаблона (он уже написан)
just::str::concat() // для run-time строк, если я однажды возьмусь их в либу добавлять
Кстати concat у меня работает с переменным числом параметров (можно больше двух)
Думал сперва его назвать implode() как в php

--

side test с перегрузкой функции:

#include <cstddef>

struct st {};

using index = std::ptrdiff_t;

template <st ... T> void fn() {}
template <index ... I> void fn() {}

int main ()
{
  fn<st{}>();
  fn<5>();
  return 0;
}

Здравствуйте, Sm0ke, Вы писали:

S>Привет
S>помогите принять решение

S>пишу либу, которая состоит из разных частей
S>и вот думаю поместить каждую часть в свой отдельный namespace !
S>есть такое желание ...

S>пока оно всё лежит в одном большом namespace, к примеру назовём just::
S>и мне это не особо нравится

Я сам традиционно парюсь с подобными проблемами и пришел к тому, что переразбиение это так же плохо, как и недоразбиение. И руководствоваться при разбиении на подпространства лучше не объемами кода, а логическими связями между сущностями. Например(!), может оказаться, что есть смысл в выделении подпространства ui, но подпространства st и flags избыточны и лучше их не заводить.

S>Минусы:
S>* выглядит не очень (нагромождение resolution operators)
S>чтобы достучаться до типа это 3 штуки писать вместо двух (just::st::bla_bla вместо just::bla_bla)

Вот это как раз совсем не страшно, имхо. Если в каком-то конкретном месте использования такая запись и мелькнет пару раз, то код это сильно не нагрузит, зато сразу понятно что и откуда. А если в каком-то другом месте подобные конструкции мелькают слишком часто, то прямо там же пишешь "namespace st = just::st;" и дальше по коду пишешь просто "st::bla_bla", все просто, понятно и читабельно.