Декларация объекта с указанием неймспейса

romanslonpp
romanslonpp

В C++17 наконец-то добавили возможность не писать так:

 

namespace A {
  namespace B {
    class C {};
  }
}

 

Хочется так же иметь возможность писать так:

 

class A::B::C {}

 

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

 

 

9
рейтинг
7 комментариев
Andrey Davydov
А для чего может быть полезно определять свой класс в уже существующем namespace?
Зачем определять функцию (скажем, чтобы, находилась по ADL) или специализировать класс (std::hash, к примеру) я понимаю.
Предлагаете ли Вы также разрешать объявлять класс? А объявлять и/или определять функции и переменные, объявлять typedef'ы и typealias'ы?
В случае nested namespace definition внутренние namespace автоматически создаются, если они не были к тому моменты известны компилятору, Вы предлагаете делать то же самое? Но если в случае namespace квалификатор обязан быть namespace, то для всего остального это не так.
Кажется, что такая фича приведет к существенному усложнению языка, позволив пользователю сократить всего O(1) слов/букв (в отличие от nested namespace definition, где экономиться O(количество вложенных namespace).
Andrey Davydov
romanslonpp
Andrey Davydov, Что значит в существующий? Мы определяем класс внутри неймспейса - существует он, либо нет - неважно.



Я не особо понимаю смысла в ваших рассуждениях. Естественно ответ на все вопросы - да т.к. это просто сахар.


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


Это не сокращает буквы - это в первую очередь сокращает лапшу, как это делает и nested namespace definition. Лапша в данном случае это бессмысленная вложенность. Да и подсчёт неверен т.к. это более частый юзкейс нежели nested namespace definition. Если взять реальную вложенность 2-3неймспейса, то эти на 1-2 вложения больше никак не перекрывают то, что засунуть что-то в detail требуется ой как более часто. А это только один из юзкейсов.
romanslonpp
Andrey Davydov
romanslonpp,
> Что значит в существующий?
Это цитата из Вашего предложения.
> По поводу "усложнения" - я так же понимаю как, чем и что конкретно это усложнит.
Наверное, я нечетко выразился. Я имел в виде неоднозначность как уже написал @mrgordonfreman комментарием ниже. Приведу еще пару примеров не с классами.
size_t A::counter_ = 0; // это статическое поле класса или глобальная переменная?
void B::foo() {} // это функция-член или свободная функция?
Сейчас, если при определении класса/функции/переменной используется qualified name, то соответствующий класс/функция/переменная должны были ранее быть объявлены, а значит, точно должен резолвитья name qualifier. Вы же предлагаете снять это ограничение, сказав, что если квалификатор не резолвиться, то будем считать его namespace'ом. Это, мне кажется, как при отсутствии типа предполагать int -- не очень хорошая идея, от которой отказались.
Andrey Davydov
mrgordonfreman
Такая запись уже используется для определения вложенных классов.

struct A { struct B; };
struct A::B {};

Если еще "нагрузить" это неймспейсами, то получим ambiguity problem. Что может скрываться за записью class A::B::C {} ?
1) namespace A { namespace B{ class C; } }
2) namespace A { class B { class C; } }
3) class A { class B { class C; } }
mrgordonfreman
dix75
mrgordonfreman,
1. Не хочу вас обидеть, но автор в начале своего предположения написал
"В C++17 наконец-то добавили возможность не писать так:", это и говорит о вложенности.

2. Никакой неоднозначности нет.
dix75
yndx-antoshkka
С одной стороны, идея интересная, так как позволит подобные записи:

namespace detail {
inline boost::filesystem::path program_location_impl(boost::system::error_code& ec);
} // namespace detail

Сократить до:

inline boost::filesystem::path detail::program_location_impl(boost::system::error_code& ec);

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

Неразрешимых технических проблем при реализации подобного механизма в компиляторах я не вижу.

Опишите более подробно вашу идею:
* можно ли писать `class A::B::C {}` если namespace A и B раньше не были определены
* будет ли эта техника работать для функций/enum/переменных
* поможет ли этот синтаксис если захочется сущность объявлять в анонимном namespace
yndx-antoshkka
dix75
yndx-antoshkka, Идея действительно интересная,но нужно обсуждать.
dix75
Другие идеи
Группа создана, чтобы собирать предложения к стандарту C++, организовывать их внутренние обсуждения, помогать готовить их для отправки в комитет и защищать на общих собраниях в рабочей группе по С++ Международной организации по стандартизации (ISO).