Есть какой-то компилятор, у которого рыночная доля сравнима с Microsoft C++???
Конечно есть — Microsoft C++ предыдущих версий. Каждая со своим рантаймом и своим ABI, вопросами совместимости которого до недавнего времени в MS не заморачивались.
А про «get out»… поживём, увидим
Я внезапно осознал, что был в корне неправ, get out не нужен. Больше легаси — сложнее язык — выше порог входа — меньше конкуренция — работа будет всегда. Ура комитету!
«Грубо говоря». Они, несомненно, есть, но какова их рыночная доля?
это про язык у которого есть три способа разбора командной строки
«А у вас негров линчуют»? Я далёк от мнения, что Python идеален и не привожу его в пример, но идеи в Zen вполне здравые. Лучше перенимать у других хорошее, чем плохое, не так ли?
А есть языки, где «80% стандартной библиотеки морально устарела»… но ими люди пользуются
Ну да, the ones people complain about and the ones nobody uses.
Однако, у того же автора есть и другая цитата, про much smaller and clearer language struggling to get out. Рант, в основном, о том, что в языке достаточно легаси на уровне кода, если тянуть за собой еще и бинарное легаси — 'get out' не наступит никогда: в C++23 решили ABI не ломать «с небольшим перевесом», а в 26 решат не ломать единогласно, потому что:
— за 6 лет никто и не почешется подготовиться к этому ломанию
— кода, верующего в ABI, станет тупо вдвое больше.
Вы сейчас описали ситауцию в Windows. А вот в мире Linux и Unix — всё было совсем по другому.
Ну да, потому что там, грубо говоря, на всю экосистему один компилятор и одна библиотека, можно упарываться от души.
Вот документ, там всё стандартизовано и описано
Речь не столько о calling convention или там virtual table layout (это всё десятилетиями прекрасно работает в том же COM), сколько о структурах данных.
Пример: std::vector можно реализовать как { BlockBeginPointer, DataEndPointer, BlockEndPointer }, а можно и как { BlockBeginPointer, DataSize, BlockSize }. Документ этого не оговаривает, стандарт этого тоже не оговаривает. Ваш пример с COW сюда же.
И вот именно повторения этой ситуации (затягивание внедрения новой версии C++ лет так на 5-7) комитет и решил избежать…
Пройдет ещё 10 лет и в стандарте появятся какие-нибудь sane_regex, fast_unordeded_map, mutable_initializer_list и т.п. потому что прогресс неизбежен, но то, что есть — священная корова. Не трожь, а то GCC сломается.
А через 20 лет 80% стандартной библиотеки окажется морально устаревшей, но будет висеть мертвым грузом, ибо совместимость.
«There should be one-- and preferably only one --obvious way to do it» — это, увы, не про C++.
С небольшим перевесом голосов решили ABI в C++23 не ломать.
У меня недостаточно слов, чтобы описать весь спектр когнитивного диссонанса, вызванного этой ситуацией.
Я вот всегда считал очевидным и самим собой разумеющимся, что Стандарт описывает интерфейс, а не имплементацию, а потому никакого ABI в C++ нет, не было и не будет.
Если вдруг надо вынести код в библиотеку — используем C-интерфейсы между модулями. Всё. Работает с любой версией любого компилятора.
Выставлять наружу C++ объекты тоже, в принципе, можно, но будет работать только с той же версией того же компилятора и с теми же параметрами сборки, поэтому имеет смысл только в том случае, когда контролируем всю кодовую базу и можем всё пересобрать при необходимости, т.е., в основном, «только для внутреннего потребления».
Банальности уровня «мойте руки перед едой».
А теперь, оказывается, в дикой природе нашлись уникумы, решившие, что протаскивать всё через C-интерфейсы сложно, а поэтому давайте закладываться в публичных интерфейсах на недокументированное поведение. Оно же работает сейчас, а значит, очевидно, будет работать всегда.
Казалось бы — да и хрен с ними, да? Естественный отбор же, да?
Нет. Теперь нигде не документированные детали реализации нельзя менять, потому что, как выяснилось, любителей видеть гарантии там, где их нет — легион, а потому сломается много чего и много где.
Казалось бы — а причем здесь вообще стандарт, если сохранение бинарного представления — это забота компилятора?
А при том, что новые фичи не всегда можно впихнуть в старое представление, а заседающим в комитете разработчикам компиляторов проще слать лесом любые пропозалы, «ломающие ABI» (которого нет), чем вызывать на себя гнев пользователей, не читающих документацию. Тормозя развитие языка и прогресс.
Стюарт Баттерфилд, создатель Flickr и Slack, развил эту мысль до самобытной концепции «пирамиды богатства», которая помогает прийти к парадоксальному выводу: даже большие деньги не обязательно улучшат вашу жизнь каким-либо заметным образом.
Кому как.
Ноутбук: устойчиво становится на пузо пользователя, экран остаётся в одном и том же положении без дополнительных усилий, рука лежит на мыши, мышь лежит на диване и перемещается максимум на пару см.
Планшет: надо или держать в руке (затекает) или класть на согнутые колени (затекают), тыкая рукой (затекает) по всему экрану.
Я не хочу тратить усилия на реализацию move-семантики для всех типов, владеющих ресурсами
Для ~95% таких типов можно переиспользовать unique_ptr, реализовав только custom deleter.
Я не хочу иметь во всех своих типах пустое состояние. Часто оно не к месту. Бывает, что его сложно или невозможно добавить. И всегда это лишние усилия на поддержку
«Moved from» это не совсем «пустое состояние». Объект должен уметь получать новое значение и корректно удаляться, обнулять вообще всё нет необходимости.
Даже если move-семантика реализуема, она может быть непозволительна из-за того, что мы хотим раздать указатели на этот объект
Как вы сами отметили, trivially_relocatable тут ничем не поможет. Guaranteed NRVO — это прекрасно само по себе, но раздача указателей на локальный объект, возвращаемый из функции — это как-то очень вычурно.
Даже если перемещение допустимо, будет затрачено время на то, чтобы «занулить» первоначальный объект, и потом удалить его по всем правилам
В общем случае это обнуление одного владеющего указателя. Небесплатно конечно, но вряд ли будет узким местом.
воспринимается мной как пропаганда религии и очень оскорбительна для меня
Шапка на иконке в каком-то редакторе — это такая мелочь.
Вот выходной 25 декабря — настоящее оскорбление.
Я надеюсь, этот пользователь его отрицает и гордо проводит на работе.
Обойти их можно так: попробовать связаться с пользователями по другим каналам и объяснить, как переместить письмо из «Спама» во «Входящие», добавив ваш обратный e-mail в адресную книгу.
Если не подписывать пользователей на рассылку без их ведома, не прятать настойки подписки в дебрях интерфейса и отписывать по первому требованию, сразу и навсегда — возможно, вас перестанут добавлять в спам.
Ясно, спасибо.
Однако, разделение declaration и assignment — в общем случае, дурной тон (в решарпере вроде даже диагностика есть), т.е. в реальном мире там скорее всего будет std::string_view sv = foo(); и dangling reference никуда не денется.
А я бы с интересом посмотрел, зачем вам таскать thread или graph между модулями.
Я внезапно осознал, что был в корне неправ, get out не нужен. Больше легаси — сложнее язык — выше порог входа — меньше конкуренция — работа будет всегда. Ура комитету!
«А у вас негров линчуют»? Я далёк от мнения, что Python идеален и не привожу его в пример, но идеи в Zen вполне здравые. Лучше перенимать у других хорошее, чем плохое, не так ли?
Ну да, the ones people complain about and the ones nobody uses.
Однако, у того же автора есть и другая цитата, про much smaller and clearer language struggling to get out. Рант, в основном, о том, что в языке достаточно легаси на уровне кода, если тянуть за собой еще и бинарное легаси — 'get out' не наступит никогда: в C++23 решили ABI не ломать «с небольшим перевесом», а в 26 решат не ломать единогласно, потому что:
— за 6 лет никто и не почешется подготовиться к этому ломанию
— кода, верующего в ABI, станет тупо вдвое больше.
Речь не столько о calling convention или там virtual table layout (это всё десятилетиями прекрасно работает в том же COM), сколько о структурах данных.
Пример: std::vector можно реализовать как { BlockBeginPointer, DataEndPointer, BlockEndPointer }, а можно и как { BlockBeginPointer, DataSize, BlockSize }. Документ этого не оговаривает, стандарт этого тоже не оговаривает. Ваш пример с COW сюда же.
… и теперь каждые 3 года мы имеем новый стандарт с новыми способами выстрелить себе в ногу, потому что старые расширять нельзя из-за этого вашего ABI, как и баги исправлять.
Пройдет ещё 10 лет и в стандарте появятся какие-нибудь sane_regex, fast_unordeded_map, mutable_initializer_list и т.п. потому что прогресс неизбежен, но то, что есть — священная корова. Не трожь, а то GCC сломается.
А через 20 лет 80% стандартной библиотеки окажется морально устаревшей, но будет висеть мертвым грузом, ибо совместимость.
«There should be one-- and preferably only one --obvious way to do it» — это, увы, не про C++.
Ок, «интерфейсы с Trivial & Standard Layout типами данных». Так понятнее?
Завернуть можно всё, вопрос в желании.
У меня недостаточно слов, чтобы описать весь спектр когнитивного диссонанса, вызванного этой ситуацией.
Я вот всегда считал очевидным и самим собой разумеющимся, что Стандарт описывает интерфейс, а не имплементацию, а потому никакого ABI в C++ нет, не было и не будет.
Если вдруг надо вынести код в библиотеку — используем C-интерфейсы между модулями. Всё. Работает с любой версией любого компилятора.
Выставлять наружу C++ объекты тоже, в принципе, можно, но будет работать только с той же версией того же компилятора и с теми же параметрами сборки, поэтому имеет смысл только в том случае, когда контролируем всю кодовую базу и можем всё пересобрать при необходимости, т.е., в основном, «только для внутреннего потребления».
Банальности уровня «мойте руки перед едой».
А теперь, оказывается, в дикой природе нашлись уникумы, решившие, что протаскивать всё через C-интерфейсы сложно, а поэтому давайте закладываться в публичных интерфейсах на недокументированное поведение. Оно же работает сейчас, а значит, очевидно, будет работать всегда.
Казалось бы — да и хрен с ними, да? Естественный отбор же, да?
Нет. Теперь нигде не документированные детали реализации нельзя менять, потому что, как выяснилось, любителей видеть гарантии там, где их нет — легион, а потому сломается много чего и много где.
Казалось бы — а причем здесь вообще стандарт, если сохранение бинарного представления — это забота компилятора?
А при том, что новые фичи не всегда можно впихнуть в старое представление, а заседающим в комитете разработчикам компиляторов проще слать лесом любые пропозалы, «ломающие ABI» (которого нет), чем вызывать на себя гнев пользователей, не читающих документацию. Тормозя развитие языка и прогресс.
Печаль.
Зачем что-то представлять, KB971033
… поэтому зарплату мы вам повышать не будем.
Кому как.
Ноутбук: устойчиво становится на пузо пользователя, экран остаётся в одном и том же положении без дополнительных усилий, рука лежит на мыши, мышь лежит на диване и перемещается максимум на пару см.
Планшет: надо или держать в руке (затекает) или класть на согнутые колени (затекают), тыкая рукой (затекает) по всему экрану.
Значит писали посимвольно.
Unless sync_with_stdio(false) has been issued, it is safe to concurrently access these objects from multiple threads for both formatted and unformatted output.
Для ~95% таких типов можно переиспользовать unique_ptr, реализовав только custom deleter.
«Moved from» это не совсем «пустое состояние». Объект должен уметь получать новое значение и корректно удаляться, обнулять вообще всё нет необходимости.
Как вы сами отметили, trivially_relocatable тут ничем не поможет. Guaranteed NRVO — это прекрасно само по себе, но раздача указателей на локальный объект, возвращаемый из функции — это как-то очень вычурно.
В общем случае это обнуление одного владеющего указателя. Небесплатно конечно, но вряд ли будет узким местом.
Шапка на иконке в каком-то редакторе — это такая мелочь.
Вот выходной 25 декабря — настоящее оскорбление.
Я надеюсь, этот пользователь его отрицает и гордо проводит на работе.
конячеловека достаточно.Если не подписывать пользователей на рассылку без их ведома, не прятать настойки подписки в дебрях интерфейса и отписывать по первому требованию, сразу и навсегда — возможно, вас перестанут добавлять в спам.
Однако, разделение declaration и assignment — в общем случае, дурной тон (в решарпере вроде даже диагностика есть), т.е. в реальном мире там скорее всего будет std::string_view sv = foo(); и dangling reference никуда не денется.
А заодно вы хотели убить и?
Или как предлагалось это различать?
Строки вам чем не угодили?