C++ 0X Понятия не стало. Который другие функции должны пойти также? [закрытый]

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

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

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

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

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

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

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

К сожалению, похоже, они отказались от его удаления. (В последний раз я проверял, что это даже не является устаревшим.)

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

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

Отбросьте потоки ввода-вывода, разработайте современную замену, и C ++ будет значительно улучшен.

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

даже?)

Отбросьте потоки ввода-вывода, разработайте современную замену , и C ++ будет значительно улучшен.

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

даже?)

Отбросьте потоки ввода-вывода, разработайте современную замену , и C ++ будет значительно улучшен.

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

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

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

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

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

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

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

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

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

Изменить (2009-10-01): Похоже, что это , в конце концов, .

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

Шаблоны выражений часто определяют типы, которые не следует использовать напрямую, Следовательно, тип должен иметь возможность сказать, какой тип должен быть выведен как (или предотвращать вывод с помощью синтаксиса = 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;
     }

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

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

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

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

Концепции RIP.