Комментарии 43
Плохо все-таки, что auto статично определяется на этапе компиляции.
Юзайте типы наподобии QVariant, это прямой аналог var'а в динамических языках, может хранить практически что угодно(дополнительные типы можно добавлять с помощью макросов), и тип хранимого значения определяется в runtime, можно оборачивать в том числе и списки и наборы. Естественно им злоупотреблять не стоит.
А по моему — очень даже хорошо. У вас часто возникают задачи хранения разных логически несвязанных типов в одной переменной?
Если ввести в C++ динамическую типизацию — это получится совсем другой язык.
Если ввести в C++ динамическую типизацию — это получится совсем другой язык.
Это хорошо! Иначе появится еще один источник разнообразнейших ошибок. :)
программирование на бестиповых языках стимулирует написание юнит-тестов
А заодно и написание глюков. ;)
А если серьезнее, то ошибку всегда следует обнаруживать как можно раньше.
Выгоднее найти ошибку сразу при запуске юнит-тестов, чем при ручном тестирование или тем более использовании заказчиком. Выгоднее найти ошибку сразу на этапе компиляции, чем на этапе исполнения (запуске юнит-тестов).
А если серьезнее, то ошибку всегда следует обнаруживать как можно раньше.
Выгоднее найти ошибку сразу при запуске юнит-тестов, чем при ручном тестирование или тем более использовании заказчиком. Выгоднее найти ошибку сразу на этапе компиляции, чем на этапе исполнения (запуске юнит-тестов).
Спасибо за статью, в последнее время на хабре не часто встретишь подобные статьи.
Извиняюсь за банальность, но — спасибо за статью.
Статья хорошая, но пример с auto (Find_Incorrect), на мой взгляд, не очень удачный. В нём утверждается, что введение слова auto позволяет решить проблему с 64-битной версией, хотя если переменную n объявить как string::size_type это точно так же решит проблему и без применения новой конструкции.
Понятно, что в данном случае auto решает не проблему компиляции 64-битных программ, а просто упрощает синтаксис программы (что в данном примере, как раз, не очень-то и заметно, тут синтаксис и так простой).
Понятно, что в данном случае auto решает не проблему компиляции 64-битных программ, а просто упрощает синтаксис программы (что в данном примере, как раз, не очень-то и заметно, тут синтаксис и так простой).
Кажется, касательно правил разбора лямбда-выражений информация немного устарела: в новом стандарте throw-списки объявлены как deprecated (оставили только специальное ключевое слово nothrow или что-то в этом роде).
P.S. Было очень лестно увидеть себя в списке библиографии :))) Спасибо.
P.S. Было очень лестно увидеть себя в списке библиографии :))) Спасибо.
Спасибо за замечание. Я не знал.
P.S.
Провел эксперимент. При компиляции кода
Visual C++ выдает предупреждение:
C++ exception specification ignored except to indicate a function is not __declspec(nothrow)
Но, как я понимаю, это не связано с C++0x. Выдержка из Msdn:
C++ exception specification ignored except to indicate a function is not __declspec(nothrow)
A function is declared using exception specification, which Visual C++ accepts but does not implement. Code with exception specifications that are ignored during compilation may need to be recompiled and linked to be reused in future versions supporting exception specifications.
P.S.
Провел эксперимент. При компиляции кода
generate_n(back_inserter(indices), 5,
[&k]() throw(int) { return k++; });
Visual C++ выдает предупреждение:
C++ exception specification ignored except to indicate a function is not __declspec(nothrow)
Но, как я понимаю, это не связано с C++0x. Выдержка из Msdn:
C++ exception specification ignored except to indicate a function is not __declspec(nothrow)
A function is declared using exception specification, which Visual C++ accepts but does not implement. Code with exception specifications that are ignored during compilation may need to be recompiled and linked to be reused in future versions supporting exception specifications.
The following code sample generates C4290:
// C4290.cpp
// compile with: /EHs /W3 /c
void f1(void) throw(int) {} // C4290
// OK
void f2(void) throw() {}
void f3(void) throw(...) {}
Спасибо за статью. Фактически, краткий обзор новых возможностей плюсов.
шикарная статья! спасибо
Заплюсовал бы, если б смог :).
Эхх… И почему синтаксис С++ так ублюдочен…
1. Инициализация vector через {...} — штука самоочевидная, и почему этого не сделали раньше — вопрос.
2. Функторы объявляются через какие-то квадратные скобки! Читабельно, бля! А, самое главное, понятно, что это функтор. Иначе что же это ещё может быть. Вот, бля, до введения ключевого слова function не додумались ну никак.
3. Нулевой указатель был ещё в паскале! Наконец-то и сюда добрался! Браво, разработчики стандарта!
4. Опять же R-value только портит синтаксис. Ага. А на этапе компиляции определять что временное, а что нет, опять же, ну никак невозможно.
…
На коленке пальцем сделали когда-то, а теперь пытаются улучшить.
P.S. К сожалению, Qt написан на C++.
Эхх… И почему синтаксис С++ так ублюдочен…
1. Инициализация vector через {...} — штука самоочевидная, и почему этого не сделали раньше — вопрос.
2. Функторы объявляются через какие-то квадратные скобки! Читабельно, бля! А, самое главное, понятно, что это функтор. Иначе что же это ещё может быть. Вот, бля, до введения ключевого слова function не додумались ну никак.
3. Нулевой указатель был ещё в паскале! Наконец-то и сюда добрался! Браво, разработчики стандарта!
4. Опять же R-value только портит синтаксис. Ага. А на этапе компиляции определять что временное, а что нет, опять же, ну никак невозможно.
…
На коленке пальцем сделали когда-то, а теперь пытаются улучшить.
P.S. К сожалению, Qt написан на C++.
Видимо они с разработчиками Perl 6 пьют вместе!
Эхх… И почему синтаксис С++ так ублюдочен…
Эхх… И почему синтаксис С++ так ублюдочен…
Эхх… И почему синтаксис С++ так ублюдочен…
По-моему, вы зажрались :) Давайте для начала вспомним, сколько этому языку лет, от какого языка он произошёл, как часто в него добавляют фичи, ну и об обратной совместимости etc. Если после C#, обновляемого дважды в год, сесть за плюсы, то конечно синтаксис покажется ублюдочным…
Инициализация vector через {...} — штука самоочевидная, и почему этого не сделали раньше — вопрос.
Контейнер vector (как и остальные) — не часть языка, а всего навсего обычный шаблонный класс из библиотеки.
В C++ как раз фишка в том, что сам язык предоставляет кучу базовых возможностей для реализации каких-то фич, но в сам язык не добавляют миллион ключевых слов. Взять те же потоки (threads): их поддержка есть в виде библиотеки (в противовес — в том же C# есть ключевое слово synchronized, если я не ошибаюсь). А так, не устраивает вас работа с потоками — можно переписать на своё усмотрение.
С помощью библиотек в C++ добавили такие фичи как foreach (Boost.Foreach), да и почти такую же простую инициализацию контейнеров (Boost.Assign). А когда что-то становится частью языка, то это уже намертво.
Функторы объявляются через какие-то квадратные скобки! Читабельно, бля! А, самое главное, понятно, что это функтор. Иначе что же это ещё может быть. Вот, бля, до введения ключевого слова function не додумались ну никак.
Да, согласен, синтаксис немного странноватый, зато писать меньше :) Вот в Haskell мне нравится: там лямбды начинаются с \
Нулевой указатель был ещё в паскале! Наконец-то и сюда добрался! Браво, разработчики стандарта!
Ну, это уже не в C++ проблема — просто у его предка C такая специфика: просто, но мощно… :D По той же причине и встроенного строкового типа нет.
Опять же R-value только портит синтаксис. Ага. А на этапе компиляции определять что временное, а что нет, опять же, ну никак невозможно.
Ссылки на rvalue позволяют нам реализовать разную логику для работы с временными объектами и для работы с «обычными».
P.S. Не к сожалению, а к счастью ;)
1. Ну ладно. С++ является потомком С. Но где сказано, что С++ код должен компилиться на only-С компиляторе? Почему бы не сделать удобнее? Мне лично это не понятно.
2. stl входит в стандарт языка => vector — это стандарт
Кстати, и встроенный string можно б было сделать.
2. stl входит в стандарт языка => vector — это стандарт
Кстати, и встроенный string можно б было сделать.
1. Когда C++ создавался, одной из основных целей было сохранение совместимости с уже имеющимся C-шным кодом (в идеале без изменений вообще, в хорошем случае — с минимальными правками). С тех пор политика комитета касательно принципа сохранения совместимости со старым кодом не изменилась, что есть правильно.
ПочемуC++ сразу не сделали удобным? Потому что по тем временам он был реально удобным в сравнении со многими другими языками. Это сейчас понапридумывали фич и синтаксического сахара, и C++ уже считается не удобным, а «терпимым».
2. Напомню, что STL — это часть стандартной библиотеки. Вам о чём-нибудь говорит слово библиотека?
Касательно встроенного string’а я не согласен. Язык C был достаточно низкоуровневым и позволял работать со строками, как с обычным массивом символов, что удобно (в плане открывающихся возможностей по оптимизации), особенно по тем временам.C++ же дал возможность создать string самостоятельно. Обратный путь от string к char * вряд ли был бы возможен без изменений в самом языке.
Почему
2. Напомню, что STL — это часть стандартной библиотеки. Вам о чём-нибудь говорит слово библиотека?
Касательно встроенного string’а я не согласен. Язык C был достаточно низкоуровневым и позволял работать со строками, как с обычным массивом символов, что удобно (в плане открывающихся возможностей по оптимизации), особенно по тем временам.
НЛО прилетело и опубликовало эту надпись здесь
Эм, а как же лямбда-выражения, LINQ и т.п.?
Впрочем, я говорю не об этом. C# разрабатывался как раз с учётом ошибок прошлых поколений, и Microsoft даже позволяет себе не соблюдать обратную совместимость (например, .NET Framework 1.1 <==> 2.0).
Впрочем, я говорю не об этом. C# разрабатывался как раз с учётом ошибок прошлых поколений, и Microsoft даже позволяет себе не соблюдать обратную совместимость (например, .NET Framework 1.1 <==> 2.0).
НЛО прилетело и опубликовало эту надпись здесь
Я не понимаю, зачем цепляться за слова про «два раза в год», если Вы прекрасно понимаете о чём я, пусть даже я немного утрировал.
Сравним:
C++:
начало 80-х (C с классами) → 1998 (первый стандарт) → 2003 (несколько технических исправлений) → 2011(?) (вывод типов (auto), лямбда-выражения, ссылки на rvalue, decltype + ещё несколько мелочей).
C#:
2002 (учёл недостатки C++ и Java) → 2005 (partial, generics, yield, ??, nullable, анонимные методы) → 2008 (LINQ, лямбда-выражения, инициализация объекта со свойствами, вывод типов (var), безымянные типы, добавление методов в существующий класс и т.д.) → 2010 (именованные и опциональные параметры, code contracts, dynamic и т.д.).
P.S. Насколько я помню, в .NET Framework 2.0 нет даже некоторых классов, которые были в 1.1, так что вряд ли всё решается простой перекомпиляцией.
Сравним:
C++:
начало 80-х (C с классами) → 1998 (первый стандарт) → 2003 (несколько технических исправлений) → 2011(?) (вывод типов (auto), лямбда-выражения, ссылки на rvalue, decltype + ещё несколько мелочей).
C#:
2002 (учёл недостатки C++ и Java) → 2005 (partial, generics, yield, ??, nullable, анонимные методы) → 2008 (LINQ, лямбда-выражения, инициализация объекта со свойствами, вывод типов (var), безымянные типы, добавление методов в существующий класс и т.д.) → 2010 (именованные и опциональные параметры, code contracts, dynamic и т.д.).
P.S. Насколько я помню, в .NET Framework 2.0 нет даже некоторых классов, которые были в 1.1, так что вряд ли всё решается простой перекомпиляцией.
вы — дурак.
Ужас, я не понимаю, кто вообще теперь захочет пользоваться Си++. Его синтаксис давно уже устарел, и по хорошему, надо переписать его с нуля а не пристраивать кучу уродливых пристроек.
>> Ужас, я не понимаю, кто вообще теперь захочет пользоваться Си++.
А никто и не «хочет» специально как-то. Просто куда деваться с подводной лодки? То есть если 100Mb C++ исходников в проекте…
А никто и не «хочет» специально как-то. Просто куда деваться с подводной лодки? То есть если 100Mb C++ исходников в проекте…
Для старых исходников можно написать конвертер. Хотя Гвидо это слабо помогло.
Конвертер откуда и куда?
Если язык переписать с нуля без совместимости с новым, то потребуется конвертер для перевода наработанного кода со старого языка на новый. Например, так было с переходом с Python 2 на 3.
Нереальная задача, поскольку объемы наработанного кода таковы, что править ошибки в «автоконвертированном» коде можно бесконечно. Кроме того, по сложности языка C++ с Python не сравниться. Ну и, чтобы уж окончательно «закрыть» тему автоконвертации — сколько проектов на Python с объемом исходного кода в 100Mb? А на C++ таких проектов много…
В общем-то, синтаксис — дело привычки. Мне к примеру нравится. С той же библиотекой Qt пользоваться C++ можно вполне успешно и в новых проектах.
К стати, двойные угловые скобки << и >> во вложенных шаблонах уже сто лет Студией трактуются именно как вложенные шаблоны. А в gcc — нет (по дефолту нет, может с какой-то опцией и будут).
О, лямбда-функции порадовали
Вы уверены что такие скобки >> называются прямоугольными? А такие [ ] как же тогда называются? Может таки «угловые скобки»? angle brackets же.
#define NULL ((void*)0)
Qt уже вводили новые фичи в c++ (foreach, например, сигналы, слоты...) и это не помешало, имхо.
нововведения в принципе неплохие, наконец-то будет shared_ptr «out of the box», что само по себе круто уже.
согласно википедии, будет ещё конструкция for(auto x: array), заменяющая foreach для массивов, это тоже круть.
а про std::regexp я вообще молчу. давно пора.
вообще, в STL будет много чего вкусного. потоки (не ввода-вывода, а threads)! блин, там будут потоки!
строковые константы кстати тоже на месте не стоят: юникод наступает, об этом тоже можно было бы в статье упомянуть…
развивается мой любимый язык, подтягивается, старается идти в ногу со временем… хотя garbage collection имхо не нужно в c++, равно как и reflection
нововведения в принципе неплохие, наконец-то будет shared_ptr «out of the box», что само по себе круто уже.
согласно википедии, будет ещё конструкция for(auto x: array), заменяющая foreach для массивов, это тоже круть.
а про std::regexp я вообще молчу. давно пора.
вообще, в STL будет много чего вкусного. потоки (не ввода-вывода, а threads)! блин, там будут потоки!
строковые константы кстати тоже на месте не стоят: юникод наступает, об этом тоже можно было бы в статье упомянуть…
развивается мой любимый язык, подтягивается, старается идти в ногу со временем… хотя garbage collection имхо не нужно в c++, равно как и reflection
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Статический анализ Си++ кода и новый стандарт языка C++0x