Comments 33
А когда примерно можно ожидать компилятор с полной поддержкой стандарта C++11 и новых фич стандартной библиотеки?
gcc.gnu.org/projects/cxx0x.html Здесь можно увидеть текущий прогресс. Уже почти все из синтаксических фич готово. Но до полной поддержки еще далеко.
Я так думаю — одновременно с браузером, полностью поддерживающим HTML5.
Alias-declarations — расширенный typedef, позволяющий использование шаблонов en.wikipedia.org/wiki/C%2B%2B11#Alias_templates
Всё так вкусно смотрится. Вообще, думаю, что язык сильно приобрёл с новым стандартом.
Скорее бы подобные вещи в VSC++ тоже появились.
Скорее бы подобные вещи в VSC++ тоже появились.
Ну, в VC11 будет несколько приятных фич.
Что особенно порадовало — обещали промежуточный релиз компилятора Visual C++, не привязанный к новому релизу Студии именно для еще большей поддержки стандарта.
Что особенно порадовало — обещали промежуточный релиз компилятора Visual C++, не привязанный к новому релизу Студии именно для еще большей поддержки стандарта.
Вкусные костыли для ошибок прошлых лет. :3
Да уж, скорее бы, а то даже variadic templates до сих пор нет.
Тройное ура делегации конструкторов! :)
Только теперь придётся ждать, когда свежая версия компилятора доедет до мейнстримовых дистрибутивов и немного стабилизируется.
Только теперь придётся ждать, когда свежая версия компилятора доедет до мейнстримовых дистрибутивов и немного стабилизируется.
А как там у clang 3.1 в сравнении с gcc по фичам?
Да судя по всему, тоже не плохо.
Судя по планам на 5ую ветку, у gccшников все плохо и они рискуют превратиться в догоняющих за llvm+clang+подставь имя языка
Жду когда будет в MinGW.
А кто-то может популярно объяснить зачем нужен override?
Вообще по уму синтаксис языка должен позволять явное указание того, что функция override. Так понятнее. Так что ввели правильно.
То есть это читая декорация что ли?
Переопределение функции должно быть явно обозначено, а то вдруг придумалась хорошая виртуальная функция, а она оказывается уже есть в предках.
Довольно часто бывает так, что в большой схеме наследования проследить за всеми методами практически невозможно. Например такой сценарий: есть базовый класс (или иерархия классов), от которого унаследованы потомки, переопределяющие некоторые методы. Допустим, работа с ними ведется через указатели. То есть, клиентский код имеет на руках указатель на базовый класс, не имея представления о том, какой именно из потомков используется. Довольно обычная ситуация виртуальных методов и фабрики.
Если же теперь какой-нибудь умник намеренно или по ошибке изменит прототип метода где-то в середине иерархии, то внезапно может нарушиться цепочка виртуальных вызовов. При этом, фактические перекрывающие методы вызываться уже не будут. Можно долго гадать, что за ерунда происходит.
К сожалению, это далеко не гипотетическая ситуация. По долгу службы мне уже приходилось сталкиваться с подобной ересью, когда один не в меру деятельный человек все ломал. Причем, далеко не всегда подобная ошибка может быть внесена программистом непосредственно. Она может возникнуть в случае переопределения типов, вереницы ifdef-ов и прочих прелестей больших кросс-платформенных проектов.
Введение же явного спецификатора позволит выявить ошибку на ранней стадии.
Если же теперь какой-нибудь умник намеренно или по ошибке изменит прототип метода где-то в середине иерархии, то внезапно может нарушиться цепочка виртуальных вызовов. При этом, фактические перекрывающие методы вызываться уже не будут. Можно долго гадать, что за ерунда происходит.
К сожалению, это далеко не гипотетическая ситуация. По долгу службы мне уже приходилось сталкиваться с подобной ересью, когда один не в меру деятельный человек все ломал. Причем, далеко не всегда подобная ошибка может быть внесена программистом непосредственно. Она может возникнуть в случае переопределения типов, вереницы ifdef-ов и прочих прелестей больших кросс-платформенных проектов.
Введение же явного спецификатора позволит выявить ошибку на ранней стадии.
Я так понимаю, для тех случаев, когда из родительского класса убрали абстрактный метод, чтобы увидеть, кем был реализован этот метод (по ошибкам) и подумать, куда девать эти реализации — либо оставить (убрав override), либо перенести куда-то, либо вообще убрать.
Меньше геморроя при коллективной разработке в том числе.
Движение в сторону JAVA.
C: 32 ключевых слова.
C++: 73(?) ключевых слова
С++11: 83 ключевых слова.
Английского толкового словаря хватит ещё надолго!
C++: 73(?) ключевых слова
С++11: 83 ключевых слова.
Английского толкового словаря хватит ещё надолго!
Brainfuck: 0 ключевых слов.
Что сказать то хотели?
Что сказать то хотели?
В Delphi посчитайте. Будете удивлены, сколько там слов — никаким сям и не снилось. :)
Ну, если верить Интернету, то их 53. А почему их должно было быть больше?
Ну проблемы С++ не в количестве ключевых слов, а в том что в нем слишком много, если много унаследованных вещей, спроектированных ИМХО не вполне правильно, в том что некоторые возможности С++ применяются не по назначению (метапрограммирование на шаблонах), в том что новые возможности вводятся не по принципу «как надо», а скорее «чтобы не навредить тому что уже есть». А количество ключевых слов можно и увеличить, это лучше чем использовать старые ключевые слова для новых целей, как делают в С++ (опять-таки, «лишь бы ничего не сломать».
Про метапрограммирование на шаблонах — спорное утверждение: что ещё делать разработчикам, если создатель языка не удосужился добавить нормальные средства метапрограммирования в язык, хотя не мог не знать о полезности такого функционала? Шаблоны — это, по сути, как раз средство метапрограммирования, но неполноценное и местами кривоватое.
С другой стороны, я согласен с вами в том, что главная проблема C++ — это обратная совместимость на уровне языка. К сожалению, Страуструп посчитал слишком жёстким оставлять совместимость лишь на уровне компоновки, и теперь, чтобы идти в ногу со временем (ну-ну) у C++ нет другого выхода, кроме как постепенно превращаться в уродливого монстра с сотнями тентаклей разных форм и размеров.
Конечно же, я намекаю на D. Скептики скажут, что язык и его компиляторы слишком далеки от production, но всему своё время. К тому же, у D та же проблема, что и у Lisp — закостенелость мышления и трусость менеджеров. Язык непопулярен потому, что на нём мало пишут, а мало пишут потому, что менеджеры не дадут писать на непопулярном языке. Тут тоже можно возразить про то, что бизнесу нужны надёжные, проверенные временем инструменты, а D — это кот в мешке, но мало кто берётся считать время, впустую потраченное на борьбу с несовершенством этих надёжных инструментов. Напоминает ситуацию с металлом Реардена в романе Айн Рэнд «Атлант расправил плечи».
По теме поддержки C++11: новость хорошая, бесспорно. Но сдаётся мне, D достигнет зрелости раньше, чем компиляторы с поддержкой C++11 избавятся от серьёзных багов, и поддержка дорастёт до уровня production.
С другой стороны, я согласен с вами в том, что главная проблема C++ — это обратная совместимость на уровне языка. К сожалению, Страуструп посчитал слишком жёстким оставлять совместимость лишь на уровне компоновки, и теперь, чтобы идти в ногу со временем (ну-ну) у C++ нет другого выхода, кроме как постепенно превращаться в уродливого монстра с сотнями тентаклей разных форм и размеров.
Конечно же, я намекаю на D. Скептики скажут, что язык и его компиляторы слишком далеки от production, но всему своё время. К тому же, у D та же проблема, что и у Lisp — закостенелость мышления и трусость менеджеров. Язык непопулярен потому, что на нём мало пишут, а мало пишут потому, что менеджеры не дадут писать на непопулярном языке. Тут тоже можно возразить про то, что бизнесу нужны надёжные, проверенные временем инструменты, а D — это кот в мешке, но мало кто берётся считать время, впустую потраченное на борьбу с несовершенством этих надёжных инструментов. Напоминает ситуацию с металлом Реардена в романе Айн Рэнд «Атлант расправил плечи».
По теме поддержки C++11: новость хорошая, бесспорно. Но сдаётся мне, D достигнет зрелости раньше, чем компиляторы с поддержкой C++11 избавятся от серьёзных багов, и поддержка дорастёт до уровня production.
Sign up to leave a comment.
Релиз GCC-4.7