C++0X Концепции ушли. Какие еще функции должны идти?
Как вы, возможно, слышали, последнее заседание комитета по стандартам C++ проголосовало за удаление концепций из следующего стандарта C++. Конечно, это повлияет на другие функции и, похоже, снова откроет стандарт. Если это так, какие другие функции, по вашему мнению, следует удалить (или добавить) и почему?
Ссылки:
Удаление понятий - Дэнни Калев (о решении удалить понятия)
Упрощение использования концепций - Бьярн Страуструп (о проблемах с концепциями, как они выглядят сейчас)
Длинный полюс становится длиннее - Мартин Таскер (о влиянии на график для C++0x, если концепции должны быть исправлены)
Решение C++0x "Удалить концепции" - Страуструп по вопросу о докторе Доббсе
Отчет о поездке: концепции выхода, окончательный проект ISO C++ за ~18 месяцев - Херб Саттер
Концепции проголосовали за C++0x Island - Джереми Зик защищает текущую концепцию концепции
Что случилось во Франкфурте? - Даг Грегор на C++Next (об истории и удалении концепций).
9 ответов
Конечно, это повлияет на другие функции и, похоже, снова откроет стандарт.
Едва. Они по-прежнему хотят в ближайшее время обернуть стандарт, что является одной из основных причин удаления концепций. Сделать его "широко открытым" для несвязанных изменений просто отбросит все, что они получили, отказавшись от концепций.
Во всяком случае.... Из оставшихся дополнений C++0x я не могу думать ни о чем другом, что хотел бы удалить. Я согласен с их решением относительно концепций. В работе Страуструпа действительно были изложены некоторые серьезные проблемы. Текущая спецификация концепций, по общему признанию, упростит сообщения об ошибках в шаблонах, но это будет сделано за счет значительного снижения полезности универсального программирования - цены, которую я не готов платить.
Когда я впервые прочитал эту статью, меня это напугало, потому что я предполагал, что уже слишком поздно для внесения серьезных изменений в спецификацию. Оказывается, это не так, и комитет был готов принять драматические меры.
Но кроме этого, я думаю, что C++0x находится в хорошей форме. Все остальные новые функции выглядят достойными.
Конечно, есть много существующих функций, которые я бы хотел удалить. Прежде всего vector<bool> специализация. Есть и другие популярные примеры функций, которые не сработали (ключевое слово экспорта, спецификации исключений), но специализация на векторах - единственная из них, которую нельзя игнорировать. Пока мы не пытаемся экспортировать шаблоны, не имеет значения, что ключевое слово существует (и не реализовано компиляторами), и мы можем просто воздерживаться от использования спецификаций исключений, но каждый раз, когда нам нужен вектор bools нас укусила глупая преждевременная оптимизация, которая проскользнула в текущий стандарт.
К сожалению, похоже, что они отказались от его удаления. (Последнее, что я проверил, это даже не устарело).
Конечно, большое количество старых C-фрейтов тоже можно было бы выбросить, но недавно я обнаружил, что единственное изменение, которое я действительно хотел бы увидеть - это отказ от библиотеки Iostreams. Выбросьте его и создайте новую библиотеку ввода-вывода в стиле STL на основе общего программирования.
Текущая библиотека Iostreams в стиле ООП уродлива, медленна, слишком сложна и негибка. Слишком много вуду вовлечено в определение новых потоков, слишком мало стандартных типов потоков, слишком мало гибкости (проблема, которая заставила меня осознать, насколько ограничена библиотека, заключалась в том, что мне нужно было извлечь float из строки. Легко сделать с помощью stringstream, но если вам нужно делать это часто, вам не нужно каждый раз копировать входную строку (как это делает поток строк) - где поток, работающий в существующем диапазоне итераторов? Или даже в необработанном массиве?)
Выбросьте IOstreams, разработайте современную замену, и C++ будет значительно улучшен.
И, возможно, что-то сделать с классом string. Он работает вроде хорошо, как сейчас, но на самом деле, что с огромным количеством функций-членов? Большинство из них будут работать лучше и будут более общими, как свободные функции. Слишком большая часть стандартной библиотеки опирается конкретно на строковый класс, когда она в принципе может работать с любым контейнером или даже с итератором (std::getline, Я смотрю на тебя)
Лично я хочу, чтобы C++ наконец оторвался от C. Больше нет препроцессора, больше нет заголовочных файлов. Я в основном хочу D, но без всего того, что D использует, используя STL.
Есть две вещи, которые, я думаю, должны быть добавлены в C++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;
}
Ни один, я думаю, что остальная часть проекта была великолепна - большое количество очень маленьких частей, которые могут быть правильно реализованы независимо, позволяя поставщикам развиваться до полной поддержки и позволяя пользователям использовать подход "списка покупок".
Совсем другая ситуация с контрактами, так как они походили на совершенно новую систему параллельных типов и, вероятно, привели бы к тому, что у разных компиляторов возникали собственные проблемы обратной совместимости, очень похожие на CSS в веб-браузерах.
Для меня проблема не в том, какие другие функции должны быть удалены, а в том, насколько сложными будут другие функции после удаления концепций. Это и сколько времени потребуется для перефразирования остальных функций без понятий.
Многие особенности предполагали, что понятия будут приняты в языке, а формулировка выражена в терминах понятий. (Интересно, зависит ли какая-либо предложенная функция от концепций).
Мне также интересно, как будут развиваться другие библиотеки (например, boost::type_traits), чтобы занять нишу, оставленную концепциями. Часть из представленных концепций может быть реализована (даже если более громоздким образом) в терминах признаков, применяемых к аргументам типа.
Для меня самой важной вещью, которая добавляла в язык концепции, была выразительная формулировка ошибок компиляции, которая в настоящее время является одним из мест, где C++ подвергается наибольшей критике.
Концепции RIP.
Делайте с концепциями все, что хотите, но ради бога, держите нити и атомарность, они нам абсолютно необходимы. Возможно, добавьте группы потоков и поддержите совместные потоки, такие как волокна. ИМО это гораздо важнее, чем концепции, потому что каждый использует / скоро будет использовать потоки.
Уберите страницы сообщений об ошибках в коде шаблона!
Концепции IIRC должны решить большую проблему кодера C++: удобочитаемые сообщения об ошибках для STL. Плохая новость, что эта проблема не решена.
Я хотел бы удалить =delete,
Уже есть распространенная и общепринятая идиома для достижения того же эффекта (объявите данную функцию как приватную). Я думаю, что эта функция будет генерировать много "я использовал =delete удалить функцию базового класса из моего производного класса, но она все еще может вызываться с использованием вопросов указателя базового класса.
Не говоря уже о том, чтобы сбивать с толку людей между (сейчас) двумя значениями delete ключевое слово.
Неназванные функции / лямбда-функции заставляют меня нервничать. Функциональные объекты отлично работают и являются явными, поэтому их легче читать и находить.
С другой стороны, мне нравились концепции, хотя я, конечно, не использовал бы их каждый день.