Здравствуйте, 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 для всех литералов текущей библиотеки

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

I see

Здравствуйте, 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