Pull to refresh

Comments 41

С++ превращается в какого-то монстра, которого уже и создатели начинают побаиваться.
Я в свое время на rsdn предлагал такую идею…
Не вводить новые монстодиальные навороты в и без того навороченный С++. Текущий стандарт С++ заморозить и никаких изменений в него больше не вносить.
Вместо этого просто разработать новый язык (типа D), более мощный, и в то же время более стройный и логичный, учитывающий все ошибки дизайна С++, и назвать его «новым стандартом». Обязать компиляторы поддерживать оба языка, декларировать двоичную совместимость, какую-то совместимость на уровне заголовочных файлов. И все.
Никто бы не кинулся переписывать код, но в существующих проектах новые файлы можно было бы писать на новом языке, по мере рефакторинга переписывать неспеша старые модули. Новые проекты сразу бы писали на новом языке. Лет через 10 старую ветку прикрыть.
Да, такая идея мне по душе. Т.е. обладать полной совместимостью, но при этом иметь другой синтаксис, более удобный. А также иметь возможность, скажем, преобразовывать хедера из C++ в новый язык. Но такого никто не будет делать. Для ентерпрайза это все равно очень обременительно. В компании, где я работаю, GCC не обновляли 10 лет. 10 ЛЕТ!!! А вы говорите.
Капец. Наверное код теперь уже сложно будет заставить скомпилироваться в новой версии.
Вы при этом не учитываете психологию людей (как программистов, особенно начинающих, так и менеджерскую прослойку).
«Что? Новый язык? Зачем нам это, сколько лет на С++ работали, и дальше будем на нем работать.»
«Новые языки» бывают разные. И отношение к ним может быть разное.
Одно дело язык с синтаксисом, максимально близким к С++, но в то же время лишенный его недостатков и со множеством красивых и полезных фич, которые хорошо себя зарекомендовали в других языках — это одно. А нечто совершенно новое и непонятное — это другое.
Тут главное — «бесшовная» интеграция из коробки для основных компиляторов. Если программист без всяких танцев с бубном просто создает новый файл с новым расширением (типа cppx), добавляет его в существующий рабочий проект в своей IDE (в той же Visual Studio), вставляет в него код примера с интернет-страницы нового языка — и вуаля — все работает! — то это одно. А если нужно что-то там настраивать, шаманить, компилятор/линкер выдает загадочные ошибки или вообще отказывается работать — это совсем другое.

Насколько я помню, тот же D предоставляет такую возможность…
> Обязать компиляторы поддерживать оба языка
Под страхом смерти?

Большинство возможностей нового стандарта не не монстроидальныйе навороты. Что вам не понятно, auto, variadic templates, lambda? Это наоборот пойдет на упрощение многих конструкций.
Ага, интересно, кто-нибудь потом вообще сможет сказать — я знаю С++ ?!
Так его и сейчас никто толком не знает. Компиляторы Microsoft, Intel, gcc, Clang имеют кучу собственных несовместимых друг с другом флагов, поддержка С++11 у всех разная, плюс к этому есть С++\CLI и еще будет новый С++ для Win8.

Вот только это мало кого парит, поскольку каждый пишет на своей платформе\компиляторе и всё.
Тем не менее есть довольно много кросплатформенного С++ кода. Можно конечно ныть, но С++ поддерживается на большем количестве платформ чем любой другой язык (кроме С :-) )
Да и щас, если по чесноку, во всем мире это могут сказать не так уж и много людей…
Причём в монстра он превращается из монстра.
Я бы здесь немного уточнил: превращается из монстрика в монстра.
Ага, всё познаёт со в сравнении :).
(познаётся) Блин, клятая автозамена.
Стандарт языка(не включая либ) C++ не больше чем у C#/Java.
Не верю. В С++ намного более сложные синтаксические правила, чем в C#/Java. Перегрузка операторов, конструкторы копий, нюансы механики вызова функций и возврата значений (return const reference к примеру), константность, указатели на члены класса, friend-классы, множественное наследование, виртуальное наследование, — всего этого просто нет в C#/Java, поэтому и описание этих языков не может быть таким же большим, как С++.
И правда, около 400-500 страниц и там и там. Как же так-то…
C++98 — 714 страниц
Черновик C++0x на 2007 год — более 1000
C# 4 — 507 страниц
Java может быть, а в C# на самом деле очень много всего. Например недавно увидел вопросительный знак в декларации переменной и был дико в шоке.
Посмотрите доклад Саттера. Там где-то в районе часа после начала он рассказывает о главной проблеме С++ и приводит просто чудесную серию слайдов как раз о размерах языка и библиотек.
Если вкратце, то по личным подсчетам Саттера (я склонен ему поверить) размер «языков» без библиотек, С++11, С# и Java измереный в страницах спецификаций практически идентичен. Разброс в единицах процентов судя по слайду.
Он наоборот, превращается из монстра во что-то читабельное. Например, auto, лямбды и ranged for сделали код намного проще и читабельнее.
Имелось ввиду описание языка и его поддержка со стороны компиляторов. Конечно, auto и лямбды — это все отлично, но вот лямбды могут быть вложенные, переменные могут в первом случае браться по ссылке, во втором: по значению. И это все надо описывать.
Новый С++ меня радует всем. Код стало писать намного проще, и при этом он стал более эффективным и безопасным. Из всех докладов больше всего понравилась доклад Страуструпа, у него очень удачные примеры, которые действительно изменили ход моих мыслей о том как лучше программировать вообще и на С++ в частности.
Вот с чем согласен, так это с ненужностью в C++ GC. Его наличие создаёт больше проблем чем решает. Если он будет, половина кода будет написана с его использованием, а половина – без. Разобраться в этом бараке будет ещё сложнее.

Собственно, главный плюс GC: он позволяет не следить за временем жизни объекта (только если единственный ресурс объекта – память). Ещё, если GC перемещающий, он автоматически борется с фрагментацией памяти. Минусы: непредсказуемые запуски GC, Перерасход памяти, сложность при взаимодействии с не GC кодом (читай с функциями на C), проблемы с концепцией деструкторов.

В общём, называйте меня закостенелым старпёром, но я предпочту старое доброе ручное управление памятью, без непредсказуемых запусков GC.
а почему непредсказуемость запуска GC является атрибутом GC как концепции? Никто не мешает запускать GC в предсказуемые моменты времени.
Ничего не мешает, но с попытка определить самые удачные моменты для запуска GC это тот ещё геморой, сомневаюсь что на уровне приложения можно подобрать эти моменты существенно лучше чем на уовне GC.
Вот поэтому и нужно самому следить за памятью. Все таки C++ это не C#.
В конце выступления Герб эффектно описал самую слабую сторону C++, и рассказал, что планируется сделать, чтобы исправить ситуацию.

Заинтриговали! В двух словах, что является самой слабой стороной C++ и что планируется для исправления ситуации?
Если не ошибаюсь, то там говорилось про создание стандартных библиотек таких же как в Java/C#
Именно так. Отсутствие стандартных средств чтобы «из коробки» любого компилятора распарсить XML\JSON, сделать HTTP-запрос, разархивировать ZIP и т.д. — основная проблема. Новичкам тяжело понять, почему этого всего нет сразу, как в Java и .NET, зачем нужна куча библиотек, как выбрать самую лучшую и т.д. Плюс масса людей ежедневно пишет собственные велосипеды или прикручивает огромные внешние либы (типа буста) ради какой-то мелочи.
Про atomic переменные понравилось. Хорошо, что за многопоточность взялись.
И от OpenMP можно будет оказаться в некоторых случаях.
Ну все. Теперь вместо книг «С++ за 24 часа» буду «С++ за 26 часов». Печаль… )
Нет, время не изменилось. Не забудьте про эпилог.
Это прекрасно. Родные (native) программисты — замечательно.
И мне очень нравится появление неделимых (atomic) действий, лямбда-выражений и особенно типа auto (странно, что их не было раньше) в этом замечательном cross-platform assembler.
Где вы видели ассемблер со встроенным ООП? Оо
IlASM или MSIL, как хотите:)
Sign up to leave a comment.

Articles