LINUX.ORG.RU

Обратная совместимость в плюсах

 , ,


0

5

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

Ответ на: комментарий от RazrFalcon

Мне кажется, что так называемые «C++ Epochs» мы увидим, как минимум, не скоро

snake266 ★★
() автор топика
Ответ на: комментарий от RazrFalcon

Как это никто, на сумрачных мейнфреймах с EBCDIC использовали

annulen ★★★★★
()

Как вы думаете, возможно ли такое что, стандарт, в какой-то момент, сломает обратную совместимость в угоду удобства, красоты кода и т.д.?

Если такое случится, то это будет уже другой язык и называться он будет по-другому. Такое было уже пару раз. В первый раз получилась Java, во второй Rust.

NeXTSTEP ★★
()

Как вы думаете, возможно ли такое что, стандарт, в какой-то момент, сломает обратную совместимость в угоду удобства, красоты кода и т.д.?

Комитет, вроде, обсуждал возможность введения директивы, задающей версию синтаксиса в пределах файла. Т.е. чтобы можно было явно согласиться на «обратную несовместимость». Если будут делать что-то существенное, то скорее всего в таком стиле.

Что бы вы улучшили, пожертвовав обратной совместимостью?

Мне кажется, что стандарт разрешает использовать не-латиницу в идентификаторах. Я бы запретил такую шизу. Также unsigned == unsigned int. int скорее не должен здесь быть опциональным. Запретить забывать return. override и final в кошерное место перенести бы. Может ещё что-то.

ваше отношение к такому пристальному соблюдению обратной совместимости.

Это же отлично! Код не надо переписывать по приколу. Я даже не представляю как в расте люди git bisect делают, если им приходится код под версию компилятора с обеих сторон подгонять.

xaizek ★★★★★
()
Ответ на: комментарий от xaizek

Я даже не представляю как в расте люди git bisect делают, если им приходится код под версию компилятора с обеих сторон подгонять.

В расте просто нет легаси.

RazrFalcon ★★★★★
()

Ну сходу на ум приходит сразу auto - ключевое слово в 11м стандарте поменяло свое значение. Правда в старом значении его никто не использовал =)

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от RazrFalcon

И на тебя еще не вылили за такие слова ушат помоев?) Наверное, правоверные плюсишники уже сладко спят в кроватках.

Virtuos86 ★★★★★
()
Ответ на: комментарий от DELIRIUM

В первом компиляторе С использовали!2121

Deleted
()
Ответ на: комментарий от RazrFalcon

Раст сам в отдалённой перспективе станет легаси. Синтаксис этому поможет. Даёшь ещё больше закорючек!😉

anonymous
()
Ответ на: комментарий от anonymous

Даёшь ещё больше закорючек!

Раст никогда не переплюнет braced initialization из C++.

RazrFalcon ★★★★★
()
Ответ на: комментарий от DELIRIUM

register

Automatic storage duration specifier (deprecated). (until C++17)

The keyword is unused and reserved. (since C++17)

Из-за него proxygen с C++17 не собирается, ибо в core сидят оптимизации из 90-х.

anonymous
()
Ответ на: комментарий от anonymous

А контрол+аш по дереву сделать не судьба. Тяжело быть плюсовиком.

anonymous
()
Ответ на: комментарий от loyd

Спросили каждого плюсовика лично. Это же просто, сделать рассылку по всем, кто купил стандарт.

fluorite ★★★★★
()
Ответ на: комментарий от annulen

ага, только __cplusplus в STL, которым проверяется версия плюсов, которую можно указать флагом компилятора, и для старых плюсов будет auto_ptr

SR_team ★★★★★
()
Ответ на: комментарий от SR_team

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

Это все на усмотрение реализации

annulen ★★★★★
()

Уже ломали несколько раз. Например auto и триграфы.

KennyMinigun ★★★★★
()
Ответ на: комментарий от RazrFalcon

Которые никто не использовал?

Для «изощрённого» программирования (напр. квайнов) утрата довольно болесная.

KennyMinigun ★★★★★
()
Последнее исправление: KennyMinigun (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

Почти всегда это или неправда, или жуткий говнокод. Может сломаться то, что завязано на внутренностях, которые никто не обещал сохранять совместимыми (в терминах С++ - прикастовать std::vector к char* и юзать его внутренности по захардконенному оффсету), например. А так там всё настолько обратно совместимо, что уже куча дублирующихся классов, когда проще сделать новый API, т.к. старый был слишком плох, но старый всё равно тянут. По-мне давно пора всё поломать к чертям.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 2)

возможно ли такое что, стандарт, в какой-то момент, сломает обратную совместимость

Нет. Совместимость - священная корова Комитета, спасибо Питону за хороший урок.

Разве что в виде опции, и это скорее всего будет, а то карточный домик уже пошатывается.

Что бы вы улучшили, пожертвовав обратной совместимостью?

D уже есть.

anonymous
()

Если этого не сделают, язык погрязнет под тяжестью легаси. Совместимость с говноС уже сильно его портит. По факту совместимость ломается и так, ибо с каждым новым стандартом старый код перестаёт собираться, так что ничего плохого в том чтобы ввести например новый кейворд вместо какого-нибудь ублюдского конструкта из нагромождения скобок сломав немного кода где он используется как имя переменной я не вижу.

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Ну, в C++20 убирать приставку co_ у co_return, co_await, co_yeld отказались. Видимо не хотят конфликта имён, или какой-то другой коллизии

snake266 ★★
() автор топика
Ответ на: комментарий от slovazap

Совместимость с говноС уже сильно его портит.

Что именно она портит?

кейворд вместо какого-нибудь ублюдского конструкта из нагромождения скобок сломав немного кода где он используется как имя переменной я не вижу.

Никаких нагромождений скобок в С/С++ нету. А ввести новый кейворд можно без проблем этому совместимость никак не мешает. Проблема для только в том, что в комитете сидят хоть и не совсем адекватные, но не настолько поехавшие люди как тебе хочется.

anonymous
()
Ответ на: комментарий от snake266

Ну, в C++20 убирать приставку co_ у co_return, co_await, co_yeld отказались. Видимо не хотят конфликта имён, или какой-то другой коллизии

Зачем вы повторяете одну и ту же херню из интернета? Вот ты подумай о том. Уже есть ключевое слово return. Есть ключевое слово из корутин обладает той же семантикой, то зачем вводить co_return? Это же так просто.

anonymous
()
Ответ на: комментарий от anonymous

Да, я забыл упомянуть про co_return. Мне тоже непонятно введение нового кейворда с такой-же семантикой что и у старого кейворда.

snake266 ★★
() автор топика
Ответ на: комментарий от snake266

У него не та же семантика, очевидно.

anonymous
()
Ответ на: комментарий от slovazap

ввести например новый кейворд

Из уже сотня или больше. Ну да, одним больше, одним меньше, никто и не заметит...

hbee ★★★★
()
Ответ на: комментарий от anonymous

Их 73 в C++14. Но какая разница, сколько их.

95 в C++17, как пишут (сам не считал). Когнитивная перегрузка: больше усилий на борьбу с языком.

hbee ★★★★
()
Ответ на: комментарий от hbee

95 в C++17, как пишут (сам не считал). Когнитивная перегрузка: больше усилий на борьбу с языком.

Типичная для фанатиков ситуация - сравнение жопы с пальцем. Толку тебе сравнивать кейворды в С++ со скриптухой, когда твоя скриптуха не умеет и 10% того, что имеет С++?

Это как кукарекать о том, что в салоне авто так много кнопок, а вот у на твоём руле от трёхколёсника их мало. Да, ты гений-разоблачитель.

anonymous
()
Ответ на: комментарий от hbee

Непонятно как считали. С учетом «Alternative representations» (формально не кейворды) выходит 84, что в 14-м, что в 17-м. В 20-м добавляется еще 7.

Училия на борьбу с кейвордами? Чего-то я не понимаю о когнитивных перегрузках.

anonymous
()
Ответ на: комментарий от slovazap

Совместимость с говноС уже сильно его портит.

Её нет.

anonymous
()
Ответ на: комментарий от anonymous

Никаких нагромождений скобок в С/С++ нету.

Навскидку, ()[]{}, [[]] и мешанина с uniform initialization и initializer list’ами - () vs. {} vs. ({}) vs. {{}}, не слежу что там добавится с корутинами и контрактами. А дальше будет хуже.

А ввести новый кейворд можно без проблем этому совместимость никак не мешает

Мешает. Пока кейворд является валидным идентификатором, он может использоваться в существующем коде.

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Навскидку, ()[]{}, [[]]

И что это за херня? Ну показывай мне кейворды.

и мешанина с uniform initialization и initializer list’ами - () vs. {}

Опять услышал где-то херню и давай повторять. Как это связано с кейвордами? Тебе дали {} - используй. Никакой мешанины нету - меньше жри пропаганды.

({}) vs. {{}}, не слежу что там добавится с корутинами и контрактами. А дальше будет хуже.

Опять какая-то херня. ({}) - это блоки из gnuc, {{}} - это базовые инициализаторы - они везде такие. Не понимаешь что и как работает - пиши {.field = {}}, либо даже {field: {}} в gnuc есть.

Я так и не увидел кейвордов и каких-то проблем. Показывай кейворды и показывай как они решают твои «проблемы».

Мешает. Пока кейворд является валидным идентификатором, он может использоваться в существующем коде.

Меньше жри пропаганды. Там добавили дохрена кейвордов. consteval concept, requires - тысячи их начиная с 11 крестов.

anonymous
()
Ответ на: комментарий от slovazap

У меня один вопрос и я его повторю. Ты уже много раз сообщил о каких-то кейвордах как замене скобок - показывай пример. Каким образом кейворд может заменить списки инициализации, оператор(), capture list у лямбды. Показывай.

anonymous
()
Ответ на: комментарий от annulen

а ты прям пользуешься этим калом мамонта - триграфами или auto_ptr? или может знаешь кого-то, кто пользуется?

я например даже не знал, что такое триграфы. не думал, что такое вообще может быть нужно.

example_cat
()
Ответ на: комментарий от slovazap

Какая разница сколько их?

Как какая разница? Количество ключевых слов — показатель общей сложности использования языка.

hbee ★★★★
()
Ответ на: комментарий от slovazap

Конечно же нет.

Значит, я чего-то фундаментально не понимаю в человеческой деятельности.

Любой инструмент должен иметь насколько возможно простое управление. Аналогия: автоматическое оружие намного сложнее внутри, чем меч, намного эффективнее, но управляться с ним намного проще: достаточно пары часов обучения, тогда как меч требует годы тренировок и владения десятками приёмов. Первое — простой в использовании язык программирования (мало ключевых слов), сложный внутри и потому мощный в решении задач. Второй — сложный «снаружи» язык программирования (куча ключевых слов, поддерживаемых парадигм и т.д.), тоже позволяющий решить те же задачи, но намного «дороже».

hbee ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.