Концепции С++ 0X исчезли. Какие другие функции должны идти тоже?

Ответ 1

Конечно, это повлияет на другие функций и, казалось бы, стандартный широко открытый снова.

Вряд ли. Они по-прежнему хотят скоро закрыть стандарт, что является одной из основных причин удаления концепций. Сделать это "широко открытыми" для несвязанных изменений просто отбросит все, что они приобрели, с помощью четких концепций.

В любом случае.... Из оставшихся добавлений С++ 0x я не могу придумать ничего, что я хотел бы удалить. Однако я согласен с их решением относительно концепций. В статье Stroustrup действительно были обозначены некоторые серьезные проблемы. Текущая спецификация концепций, по общему признанию, упростит сообщения об ошибках в шаблонах, но это сделало бы это, резко снизив полезность общего программирования - цену, которую я не желаю платить.

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

Но кроме этого, я думаю, что С++ 0x в хорошей форме. Остальные новые функции выглядят достойно.

Конечно, есть много существующих функций, которые мне бы хотелось удалить. В первую очередь специализация vector<bool>. Существуют и другие популярные примеры функций, которые не сработали (ключевое слово export, спецификации исключений), но векторная специализация является единственной из них, которые нельзя игнорировать. Пока мы не пытаемся экспортировать шаблоны, не имеет значения, что ключевое слово существует (и не реализовано компиляторами), и мы можем просто воздерживаться от использования спецификаций исключений, но каждый раз нам нужен вектор bools, мы укушены глупой преждевременной оптимизацией, которая проскользнула в текущий стандарт.

К сожалению, похоже, что они отказались от его удаления. (Последнее, что я проверил, оно даже не было устарело).

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

Текущая библиотека Iostreams, созданная OOP, является уродливой, медленной, сложной и негибкой. Там слишком много вуду, участвующих в определении новых потоков, слишком мало стандартных типов потоков, слишком мало гибкости (проблема, которая заставила меня понять, насколько ограничена библиотека, было то, что мне нужно было извлечь поплавок из строки., но если вам нужно делать это часто, вы не хотите копировать входную строку каждый раз (как это делает stringstream) - где поток, который работает в существующем диапазоне итераторов? Или необработанный массив, даже? )

Выбросьте IOstreams, разработайте современную замену, и С++ будет значительно улучшен.

И, возможно, сделайте что-нибудь и в классе строк. Он работает вроде как ok'ish, как сейчас, но действительно, что с огромным количеством функций-членов? Большинство из них будут работать лучше и быть более общими, как свободные функции. Слишком большая часть стандартной библиотеки полагается конкретно на класс строк, когда она может в принципе работать с любым контейнером или даже с итератором (std::getline, я смотрю на вас)

Ответ 2

Лично я хочу, чтобы С++ окончательно оторвался от C. Нет больше препроцессора, больше нет файлов заголовков. Я в основном хочу D, но без всего, что D накладывает, используя STL.

Ответ 3

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

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

Ответ 4

Есть две вещи, которые, по моему мнению, должны быть добавлены в С++ 0x, я подумал обо всех этих двух, и затем обнаружил, что другие предложили их раньше, но похоже, что они не будут.

1. По умолчанию конструкторы перемещения и перемещения операторов присваивания

Написание конструктора перемещения - это ручная и подверженная ошибкам активность, если член добавлен, он должен быть добавлен в конструктор перемещения, а операторы присваивания и std::move должны использоваться религиозно. Вот почему я думаю, что эти функции должны быть недействительными.

movable(movable&&) = default;
movable& operator=(movable&&) = default;

Изменить (2009-10-01): Похоже, что произойдет.

2. Переопределить тип вычета для шаблонов выражений

Шаблоны экспрессии часто определяют типы, которые не должны использоваться напрямую, примером является возвращаемое значение std::vector<bool> operator[](size_type n), если auto или decltype используются для такого типа объектов, может возникнуть непредвиденное поведение. Поэтому тип должен иметь возможность сказать, какой тип должен быть выведен как (или предотвратить вычет с использованием синтаксиса = delete).

Пример добавления вектора.

// lazy evaluation of vector addition
template<typename T, class V1, class V2>
class vector_add {
     V1& lhs_;
     V2& rhs_;
public:
     T operator[](size_t n) const
     { return lhs_[n] + rhs_[n]; }
     // If used by auto or decltype perform eager creation of vector 
     std::vector<T> operator auto() const 
     {
         if (lhs_.size() != rhs_.size()) 
             throw std::exception("Vectors aren't same size");
         std::vector<T> vec;
         vec.reserve(lhs_.size());
         for (int i = 0; i < lhs_.size(); ++i)
            vec.push_back(lhs_[i] + rhs_[i]);
         return vec;
     }

Ответ 5

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

Многие функции предполагали, что концепции будут приняты на языке, а формулировка выражается в терминах понятий. (Интересно, зависит ли какая-либо предлагаемая функция от концепций).

Мне также интересно, как будут развиваться другие библиотеки (думаю boost:: type_traits), чтобы занять нишу, оставленную концепциями. Часть предоставленных концепций может быть реализована (даже если это более громоздко) с точки зрения характеристик, применяемых к аргументам типа.

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

R.I.P. понятия.

Ответ 6

Делайте все, что хотите, с концепциями, но для богов держать потоки и атомы, они нам абсолютно нужны. Возможно, добавьте группы потоков и поддержку совлокальных потоков a.k.a. волокна. IMO это гораздо важнее концепций, потому что каждый использует/скоро будет использовать потоки.

Ответ 7

Я хочу удалить =delete.

Там уже есть общая и принятая идиома для того, чтобы получить тот же эффект (объявите рассматриваемую функцию как конфиденциальную). Я думаю, что эта функция будет генерировать много "я использовал =delete для удаления функции базового класса из моего производного класса, но его все равно можно вызвать с помощью вопросов с указателем базового класса.

Не говоря уже о запутывании людей между (теперь) двумя значениями ключевого слова delete.

Ответ 8

Удалите страницы сообщений об ошибках в коде шаблона!

Концепции IIRC должны решить большую проблему с С++-кодером: сообщения о возможности чтения человеком для STL. Его плохая новость о том, что этот вопрос не рассматривается.

Ответ 9

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

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