Мы все любим плюсы Но он кажется мне сильно усложнённым, особенно в последние годы, вследствие обеспечения обратной совместимости.

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

Здравствуйте, tdiff, Вы писали:

T>Мы все любим плюсы Но он кажется мне сильно усложнённым, особенно в последние годы, вследствие обеспечения обратной совместимости.

T>Как вы полагаете, была бы интересна такая версия языка, которая жертвовала бы обратной совместимостью ради упрощения правил языка? Насколько сильно бы отличался этот вымышленный язык от того, что мы имеем сейчас?

D?

Здравствуйте, vsb, Вы писали:

vsb>D?

Я не знаю, никогда не пользовался. Я понимаю, что он задумывался как развитие С++, и в этом отличие от того, о чем говорю я: они дополняли язык какими-то нужными им качествами, а я ратую за упрощение того, что есть сейчас.

Здравствуйте, tdiff, Вы писали:

T>Мы все любим плюсы Но он кажется мне сильно усложнённым, особенно в последние годы, вследствие обеспечения обратной совместимости.

T>Как вы полагаете, была бы интересна такая версия языка, которая жертвовала бы обратной совместимостью ради упрощения правил языка? Насколько сильно бы отличался этот вымышленный язык от того, что мы имеем сейчас?

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

А если уж хочется посмотреть на радикальные эксперименты, то попробуйте C++/CX (только с С++/CLI не спутайте).

Здравствуйте, VTT, Вы писали:

VTT>Ну вот например в текущем стандарте пожертвовали обратной совместимостью и изменили значение ключевого слова auto, тем самым радикально упростив объявление переменных. Чем вас такой подход не устраивает?

Они делают, что могут — в рамках своих ограничений на обратную совместимость и реально существующую практику применения языка.
Но в то же время, например, автоматически создаваемые функции класса. Правила для добавленных rvalue-функций отличаются от правил для старых lvalue-функций, при этом некоторые из последних объявляются deprecated. В итоге в языке два набора правил для схожих вещей, о которых надо иметь представление.

Здравствуйте, tdiff, Вы писали:

T>Мы все любим плюсы Но он кажется мне сильно усложнённым, особенно в последние годы, вследствие обеспечения обратной совместимости.

Это ложное впечатление. С++ "усложнен" в силу набора свойств.

T>Как вы полагаете, была бы интересна такая версия языка, которая жертвовала бы обратной совместимостью ради упрощения правил языка? Насколько сильно бы отличался этот вымышленный язык от того, что мы имеем сейчас?

Не произойдёт радикального упрощения. С++ нуждается в полировке, но это именно полировка. А, кроме того, он ведь развивается. В 17 году мы ждём концептов, и язык станет ещё сложнее.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, Шахтер, Вы писали:

Ш>Здравствуйте, tdiff, Вы писали:

T>>Мы все любим плюсы Но он кажется мне сильно усложнённым, особенно в последние годы, вследствие обеспечения обратной совместимости.

Ш>Это ложное впечатление. С++ "усложнен" в силу набора свойств.

Так ли? Я выше приводил один из примеров с автоматически создаваемыми функциями. Там именно что какая-то концепция признана "устаревшей", но отказаться от неё они не могут, дело не в уникальном наборе свойств. Ну или другой пример с vector<bool>, специализация которого, по моим представлениям, далеко не всем нравится, но приходится тащить за собой.

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


А насчёт концептов — здорово, что они будут в сх17. Это как раз добавление новых возможностей. Плохо будет, если в сх19 они поймут, что им что-то не нравится, и начнут сбоку пришивать 5ю ногу.

Здравствуйте, tdiff, Вы писали:

T>Мы все любим плюсы Но он кажется мне сильно усложнённым, особенно в последние годы, вследствие обеспечения обратной совместимости.
T>Как вы полагаете, была бы интересна такая версия языка, которая жертвовала бы обратной совместимостью ради упрощения правил языка? Насколько сильно бы отличался этот вымышленный язык от того, что мы имеем сейчас?

С++ кривой. В первую очередь из-за того, что программистам всегда хочется большего, а язык развивается медленно — из-за этого и появилось все это немыслимое метапрограммирование на шаблонах и макросах, которое в сочетании с древними и концепиуально неправильными include породило аццкую гремучую смесь, взрывающую мозг.

Нужно создавать новый язык, а не полировать С++. D годится на роль "заготовки" — по крайней мере в нем устранены некоторые ошибки С++, но вот дальше он тоже стал куда-то уходить не в ту степь. А совместимость можно и нужно ломать даже внутри одного языка; но соблюдая две вещи
1. в языке должна быть конструкция, определяющая версию (ну скажем какая-нибудь pragma version, которая пишется в начале каждого файла)
2. нужно тщательно описывать, документировать и сопровождать ОГРОМНЫМ количеством примеров все изменения в языке. Я наблюдал за развитием Rust — они довольно часто меняли что-то там... это печально. Документация охватывает обычно только "внешнюю" сторону языка; все что сложнее уровня hello world где-то скрыто. Может быть, есть какие-то форумы лично для разработчиков, но я бы хотел чтобы все это было на официальном сайте.

Здравствуйте, NeoCode, Вы писали:

NC>А совместимость можно и нужно ломать даже внутри одного языка; но соблюдая две вещи
NC>1. в языке должна быть конструкция, определяющая версию (ну скажем какая-нибудь pragma version, которая пишется в начале каждого файла)
NC>2. нужно тщательно описывать, документировать и сопровождать ОГРОМНЫМ количеством примеров все изменения в языке

Глупость. Мало кому захочется портировать или поддерживать две версии для кода, который отлажен, протестирован и приносит деньги. И пофиг, что все breaking changes будут любовно описаны на вики.
Например, сообщество в целом так и не приняло D во многом из-за отсутствия стабильности. Python3 сломал совместимость с Python2 ради пары плюшек 6 лет назад — и до сих пор не победил.

Здравствуйте, Константин, Вы писали:

NC>>А совместимость можно и нужно ломать даже внутри одного языка; но соблюдая две вещи
NC>>1. в языке должна быть конструкция, определяющая версию (ну скажем какая-нибудь pragma version, которая пишется в начале каждого файла)
NC>>2. нужно тщательно описывать, документировать и сопровождать ОГРОМНЫМ количеством примеров все изменения в языке

К>Глупость. Мало кому захочется портировать или поддерживать две версии для кода, который отлажен, протестирован и приносит деньги. И пофиг, что все breaking changes будут любовно описаны на вики.
К>Например, сообщество в целом так и не приняло D во многом из-за отсутствия стабильности. Python3 сломал совместимость с Python2 ради пары плюшек 6 лет назад — и до сих пор не победил.

А зачем портировать? Можно просто в компиляторе тащить поддержку старых стандартов и компилировать каждый файл используя соответствующий модуль.

Здравствуйте, vsb, Вы писали:

NC>>>А совместимость можно и нужно ломать даже внутри одного языка; но соблюдая две вещи
К>>Глупость. Мало кому захочется портировать или поддерживать две версии для кода, который отлажен, протестирован и приносит деньги. И пофиг, что все breaking changes будут любовно описаны на вики.

vsb>А зачем портировать? Можно просто в компиляторе тащить поддержку старых стандартов и компилировать каждый файл используя соответствующий модуль.

И что это даст? Вряд ли несовместимые изменения оставят совместимым ABI. Смогу ли я в приложении на C++-next-gen использовать непортированные библиотеки C++-prev-gen? Что там далеко ходить, сейчас это проблематично даже при обновлении компилятора.

Здравствуйте, Константин, Вы писали:

К>И что это даст? Вряд ли несовместимые изменения оставят совместимым ABI. Смогу ли я в приложении на C++-next-gen использовать непортированные библиотеки C++-prev-gen? Что там далеко ходить, сейчас это проблематично даже при обновлении компилятора.

На C++ — нет, и не из-за ABI, а из-за препроцессора и инклудов, тащить которые в новый язык (даже в режиме совместимости) крайне нежелательно.
Именно поэтому я сказал про новый язык.
А в новом языке на всякий случай можно завести такую прагму. Не думаю что ломающие изменения будут появляться чаще чем раз в 10 лет (если будут). Сейчас уже гораздо больше ясности с тем, каким должен быть дизайн языка, в отличие от тех времен когда создавался С++.

Здравствуйте, tdiff, Вы писали:

T>Мы все любим плюсы Но он кажется мне сильно усложнённым, особенно в последние годы, вследствие обеспечения обратной совместимости.

T>Как вы полагаете, была бы интересна такая версия языка, которая жертвовала бы обратной совместимостью ради упрощения правил языка? Насколько сильно бы отличался этот вымышленный язык от того, что мы имеем сейчас?

На язык всем насрать. Главное чтобы компилятор генерил шустрый код и были оптимизированные библиотеки. А язык — да хоть китайский.
Фактически это означает, что новый язык должен уделывать C++ в shootout-е хотя бы в половине тестов и проигрывать не более 10% в остальных тестах. И должна быть совместимость с Си на уровне ABI. То есть как у Фортрана и Си в GCC.
Если эти две задачи не решать, то можно даже не начинать.

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

LVV>Например, процедурная часть — без классов и шаблонов.

не получится. для c++ будут генерироваться конструкторы по-умолчанию.
разное поведение программы.

Здравствуйте, dad, Вы писали:

LVV>>Например, процедурная часть — без классов и шаблонов.

dad>не получится. для c++ будут генерироваться конструкторы по-умолчанию.
dad>разное поведение программы.
Пока ты их сам явно не пишешь — рояли не играет.
Структуры используются так же как в Си.

Здравствуйте, tdiff, Вы писали:

T>Как вы полагаете, была бы интересна такая версия языка, которая жертвовала бы обратной совместимостью ради упрощения правил языка? Насколько сильно бы отличался этот вымышленный язык от того, что мы имеем сейчас?

так сделали уже. шарп получился.