Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 41
С++ превращается в какого-то монстра, которого уже и создатели начинают побаиваться.
Я в свое время на rsdn предлагал такую идею…
Не вводить новые монстодиальные навороты в и без того навороченный С++. Текущий стандарт С++ заморозить и никаких изменений в него больше не вносить.
Вместо этого просто разработать новый язык (типа D), более мощный, и в то же время более стройный и логичный, учитывающий все ошибки дизайна С++, и назвать его «новым стандартом». Обязать компиляторы поддерживать оба языка, декларировать двоичную совместимость, какую-то совместимость на уровне заголовочных файлов. И все.
Никто бы не кинулся переписывать код, но в существующих проектах новые файлы можно было бы писать на новом языке, по мере рефакторинга переписывать неспеша старые модули. Новые проекты сразу бы писали на новом языке. Лет через 10 старую ветку прикрыть.
Не вводить новые монстодиальные навороты в и без того навороченный С++. Текущий стандарт С++ заморозить и никаких изменений в него больше не вносить.
Вместо этого просто разработать новый язык (типа D), более мощный, и в то же время более стройный и логичный, учитывающий все ошибки дизайна С++, и назвать его «новым стандартом». Обязать компиляторы поддерживать оба языка, декларировать двоичную совместимость, какую-то совместимость на уровне заголовочных файлов. И все.
Никто бы не кинулся переписывать код, но в существующих проектах новые файлы можно было бы писать на новом языке, по мере рефакторинга переписывать неспеша старые модули. Новые проекты сразу бы писали на новом языке. Лет через 10 старую ветку прикрыть.
Да, такая идея мне по душе. Т.е. обладать полной совместимостью, но при этом иметь другой синтаксис, более удобный. А также иметь возможность, скажем, преобразовывать хедера из C++ в новый язык. Но такого никто не будет делать. Для ентерпрайза это все равно очень обременительно. В компании, где я работаю, GCC не обновляли 10 лет. 10 ЛЕТ!!! А вы говорите.
Вы при этом не учитываете психологию людей (как программистов, особенно начинающих, так и менеджерскую прослойку).
«Что? Новый язык? Зачем нам это, сколько лет на С++ работали, и дальше будем на нем работать.»
«Что? Новый язык? Зачем нам это, сколько лет на С++ работали, и дальше будем на нем работать.»
«Новые языки» бывают разные. И отношение к ним может быть разное.
Одно дело язык с синтаксисом, максимально близким к С++, но в то же время лишенный его недостатков и со множеством красивых и полезных фич, которые хорошо себя зарекомендовали в других языках — это одно. А нечто совершенно новое и непонятное — это другое.
Тут главное — «бесшовная» интеграция из коробки для основных компиляторов. Если программист без всяких танцев с бубном просто создает новый файл с новым расширением (типа cppx), добавляет его в существующий рабочий проект в своей IDE (в той же Visual Studio), вставляет в него код примера с интернет-страницы нового языка — и вуаля — все работает! — то это одно. А если нужно что-то там настраивать, шаманить, компилятор/линкер выдает загадочные ошибки или вообще отказывается работать — это совсем другое.
Одно дело язык с синтаксисом, максимально близким к С++, но в то же время лишенный его недостатков и со множеством красивых и полезных фич, которые хорошо себя зарекомендовали в других языках — это одно. А нечто совершенно новое и непонятное — это другое.
Тут главное — «бесшовная» интеграция из коробки для основных компиляторов. Если программист без всяких танцев с бубном просто создает новый файл с новым расширением (типа cppx), добавляет его в существующий рабочий проект в своей IDE (в той же Visual Studio), вставляет в него код примера с интернет-страницы нового языка — и вуаля — все работает! — то это одно. А если нужно что-то там настраивать, шаманить, компилятор/линкер выдает загадочные ошибки или вообще отказывается работать — это совсем другое.
Насколько я помню, тот же D предоставляет такую возможность…
> Обязать компиляторы поддерживать оба языка
Под страхом смерти?
Большинство возможностей нового стандарта не не монстроидальныйе навороты. Что вам не понятно, auto, variadic templates, lambda? Это наоборот пойдет на упрощение многих конструкций.
Под страхом смерти?
Большинство возможностей нового стандарта не не монстроидальныйе навороты. Что вам не понятно, auto, variadic templates, lambda? Это наоборот пойдет на упрощение многих конструкций.
Ага, интересно, кто-нибудь потом вообще сможет сказать — я знаю С++ ?!
Так его и сейчас никто толком не знает. Компиляторы Microsoft, Intel, gcc, Clang имеют кучу собственных несовместимых друг с другом флагов, поддержка С++11 у всех разная, плюс к этому есть С++\CLI и еще будет новый С++ для Win8.
Вот только это мало кого парит, поскольку каждый пишет на своей платформе\компиляторе и всё.
Вот только это мало кого парит, поскольку каждый пишет на своей платформе\компиляторе и всё.
Да и щас, если по чесноку, во всем мире это могут сказать не так уж и много людей…
Причём в монстра он превращается из монстра.
Стандарт языка(не включая либ) C++ не больше чем у C#/Java.
Не верю. В С++ намного более сложные синтаксические правила, чем в C#/Java. Перегрузка операторов, конструкторы копий, нюансы механики вызова функций и возврата значений (return const reference к примеру), константность, указатели на члены класса, friend-классы, множественное наследование, виртуальное наследование, — всего этого просто нет в C#/Java, поэтому и описание этих языков не может быть таким же большим, как С++.
Java может быть, а в C# на самом деле очень много всего. Например недавно увидел вопросительный знак в декларации переменной и был дико в шоке.
Посмотрите доклад Саттера. Там где-то в районе часа после начала он рассказывает о главной проблеме С++ и приводит просто чудесную серию слайдов как раз о размерах языка и библиотек.
Если вкратце, то по личным подсчетам Саттера (я склонен ему поверить) размер «языков» без библиотек, С++11, С# и Java измереный в страницах спецификаций практически идентичен. Разброс в единицах процентов судя по слайду.
Если вкратце, то по личным подсчетам Саттера (я склонен ему поверить) размер «языков» без библиотек, С++11, С# и Java измереный в страницах спецификаций практически идентичен. Разброс в единицах процентов судя по слайду.
Он наоборот, превращается из монстра во что-то читабельное. Например, auto, лямбды и ranged for сделали код намного проще и читабельнее.
Новый С++ меня радует всем. Код стало писать намного проще, и при этом он стал более эффективным и безопасным. Из всех докладов больше всего понравилась доклад Страуструпа, у него очень удачные примеры, которые действительно изменили ход моих мыслей о том как лучше программировать вообще и на С++ в частности.
Вот с чем согласен, так это с ненужностью в C++ GC. Его наличие создаёт больше проблем чем решает. Если он будет, половина кода будет написана с его использованием, а половина – без. Разобраться в этом бараке будет ещё сложнее.
Собственно, главный плюс GC: он позволяет не следить за временем жизни объекта (только если единственный ресурс объекта – память). Ещё, если GC перемещающий, он автоматически борется с фрагментацией памяти. Минусы: непредсказуемые запуски GC, Перерасход памяти, сложность при взаимодействии с не GC кодом (читай с функциями на C), проблемы с концепцией деструкторов.
В общём, называйте меня закостенелым старпёром, но я предпочту старое доброе ручное управление памятью, без непредсказуемых запусков GC.
Собственно, главный плюс GC: он позволяет не следить за временем жизни объекта (только если единственный ресурс объекта – память). Ещё, если GC перемещающий, он автоматически борется с фрагментацией памяти. Минусы: непредсказуемые запуски GC, Перерасход памяти, сложность при взаимодействии с не GC кодом (читай с функциями на C), проблемы с концепцией деструкторов.
В общём, называйте меня закостенелым старпёром, но я предпочту старое доброе ручное управление памятью, без непредсказуемых запусков GC.
В конце выступления Герб эффектно описал самую слабую сторону C++, и рассказал, что планируется сделать, чтобы исправить ситуацию.
Заинтриговали! В двух словах, что является самой слабой стороной C++ и что планируется для исправления ситуации?
Если не ошибаюсь, то там говорилось про создание стандартных библиотек таких же как в Java/C#
Именно так. Отсутствие стандартных средств чтобы «из коробки» любого компилятора распарсить XML\JSON, сделать HTTP-запрос, разархивировать ZIP и т.д. — основная проблема. Новичкам тяжело понять, почему этого всего нет сразу, как в Java и .NET, зачем нужна куча библиотек, как выбрать самую лучшую и т.д. Плюс масса людей ежедневно пишет собственные велосипеды или прикручивает огромные внешние либы (типа буста) ради какой-то мелочи.
Про atomic переменные понравилось. Хорошо, что за многопоточность взялись.
Ну все. Теперь вместо книг «С++ за 24 часа» буду «С++ за 26 часов». Печаль… )
Это прекрасно. Родные (native) программисты — замечательно.
И мне очень нравится появление неделимых (atomic) действий, лямбда-выражений и особенно типа auto (странно, что их не было раньше) в этом замечательном cross-platform assembler.
И мне очень нравится появление неделимых (atomic) действий, лямбда-выражений и особенно типа auto (странно, что их не было раньше) в этом замечательном cross-platform assembler.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обзор конференции Going Native'2012