Привет
помогите принять решение
пишу либу, которая состоит из разных частей
и вот думаю поместить каждую часть в свой отдельный 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 и работать без префиксов.
— выбор названий подсистем стал понятнее и осмысленнее
У меня прижился первый вариант
Здравствуйте, 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;
}
