Какие проблемы вы могли бы предвидеть при добавлении моей конструкции «использующий блок» в C ++?

Question

Заголовочные файлы с такими объявлениями:

void FooBar(System::Network::Win32::Sockets::Handle handle, System::Network::Win32::Sockets::Error& error /*, more fully-qualified param declarations... */);

распространены в определенных средах.И использование объявлений, которые могли бы смягчить эту проблему, обычно не считается кошерным для использования в заголовочных файлах, поскольку они могут влиять на правила поиска имен для заголовочных файлов, которые будут включены позже.typedefs внутри класса, которые объявлены как private, загромождают пространство имен класса и производное от него пространство имен.

Вот предлагаемое решение:

using {
   // A 'using' block is a sort of way to fence names in.  The only names
   // that escape the confines of a using block are names that are not
   // aliases for other things, not even for things that don't have names
   // of their own.  These are things like the declarations for new
   // classes, enums, structs, global functions or global variables.
   // New, non-alias names will be treated as if they were declared in
   // the scope in which the 'using' block appeared.

   using namespace ::std;
   using ::mynamespace::mytype_t;
   namespace mn = ::mynamespace;
   using ::mynamespace::myfunc;

   class AClass {
     public:
      AClass(const string &st, mytype_t me) : st_(st), me_(me) {
         myfunc(&me_);
      }

     private:
      const string st_;  // string will refer to ::std::string
      mn::mytype_t me_;
   };
// The effects of all typedefs, using declarations, and namespace
// aliases that were introduced at the level of this block go away
// here.  typedefs and using declarations inside of nested classes
// or namespace declarations do not go away.
} // end using.

// Legal because AClass is treated as having been declared in this
// scope.
AClass a("Fred", ::mynamespace::mytype_t(5));

// Not legal, alias mn no longer exists.
AClass b("Fred", mn::mytype_t);

// Not legal, the unqualified name myfunc no longer exists.
AClass c("Fred", myfunc(::mynamespace::mytype_t(5));

В отдельных файлах Java и Pythonобращаются особым образом.Вы можете иметь объявления импорта, которые вводят имена из других пространств имен в файл.Эти имена (ну, не совсем с Python, но это слишком сложно объяснить здесь) будут видны только внутри этого файла.

Я думаю, что C ++ нуждается в аналогичной конструкции.Существование препроцессора, директивы #include и концепции модуля перевода в C ++ затрудняет неявную область видимости импортированных имен.Поэтому некоторым, я думаю, необходим какой-то механизм для явного определения области действия таких временных псевдонимов.

Какие проблемы вы предвидите с этой идеей?Если проблем нет, или они очень мелкие и их можно исправить, как бы мне было представить их в качестве предложения в комитет по стандартам?

Answer 1

Комитет по стандартам ISO / IEC JTC1 / SC22 / WG21 (он же C ++) близок к завершению стандарта C ++ 0x ; у вас практически нет шансов включить это предложение в стандарт C ++ 0x.

Для любого предложения вы должны представить мотивацию для функции, объясняя, почему это должно быть добавлено к стандарту вместо 50 других предложений, претендующих на привилегию. (См. Объяснение Страуструпа в D & E - «Дизайн и эволюция C ++».)

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

То, что вы дали здесь, может быть интересным началом, но оно еще не близко к тому, что необходимо для получения стандартного предложения. Посмотрите документы на веб-сайте открытых стандартов. Подумайте, есть ли в вашем распоряжении ресурсы для этого. Скорее всего, вы этого не делаете, извините.

Answer 2

Смущает меня. Разница между вашим using блоком и обычным блоком состоит в том, что некоторые имена вылезают, и правило, для которого это кажется довольно произвольным, и люди будут придумывать угловые случаи, которые не работают так, как вы ожидаете. Я также не вижу, что это будет за общее использование.

Разве вы не можете сделать что-то очень похожее с пространством имен с уникальным именем и некоторыми using namespace::foo; операторами?

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

Следующее, что нужно сделать, это попытаться немного попрактиковаться в этом, что означает создание компилятора (вероятно, измененной версии g ++), который его реализует, и попытка сделать его популярным.

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

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

Answer 3

Вы имеете в виду, что у всех просто есть пространства имен, которые они резервируют для деталей реализации?Или как вы могли бы просто использовать класс и прикрепить участников как частные, если вы не хотите, чтобы к ним обращались?Дело не в том, что эта идея в корне неверна или плоха, я просто не вижу выгоды.Модель компиляции C ++ имеет много, НАМНОГО больших дыр, которые требуют исправления, а не тривиальности, подобной этой.