Я с Вами по сути согласен, я был тоже очень воодушевлён, когда много лет назад Саттер рисовал красивые картины светлого будущего, где в стандарте C++ будет много библиотек и потом как заживём... Но затем я увидел, с какой скоростью происходит реализация библиотек в MSVC/gcc/clang, и мой оптимизм полностью сошёл на нет. Вплоть до того, что я предпочитаю {fmt} std::format, потому что так мне нужно бодаться с одной библиотекой, вместо трёх, если что-то пойдёт не так.
Возможно ли, что ситуация изменится? Да, но для этого нужны хорошие вливания в MSVC/gcc/clang, а после фортеля от White House про «безопасные языки» ждать этого не приходится. По крайней мере от США. Так что фантазировать можно сколько угодно, но реальность на данный момент STL описал очень хорошо.
Но хорошо, что необходимости тащить библиотеки в стандарт всё-таки нет, т. к. туда зачастую хотят тащить уже имеющиеся, проверенные временем решения, которые можно использовать уже сейчас.
Этот, как Вы выразились, ноунейм имеет имя: Stephan T. Lavavej. Он единственный мейнтейнер стандартной библиотеки от Microsoft. И я бы рекомендовал прислушаться к тому, что говорит этот человек, когда речь идёт о стандартной библиотеке. Он знает, о чём говорит.
О чём свидетельствует, кстати, скорость реализации std::format, std::ranges и прочих «простых» библиотек. Лично я уже давно пришёл к выводу, что C++ не в состоянии вывезти сложные библиотеки через стандарт, потому что минимум 3 реализации, которые, как я понимаю, друг у друга брать не могут, это слишком много.
Воу-воу, вот с этим полегче. Если стандарт не запрещает такую оптимизацию, то тот факт, что компиляторы сейчас это не делают, вовсе не означает, что так делать можно, потому что нет никаких гарантий что они не начнут делать это в любой момент будущем.
Многим людям тяжело читать стандарт, поэтому наличие такой реализации было бы хорошим стартом, потому что такие оптимизации просто так не делают. Если такая реализация есть, то весьма вероятно, она разрешена стандартом. Отсюда и запрос: предоставить хоть какие-то доказательства слов.
Очередная статья, которая обещает сорвать все покровы с std::launder, но не делает этого.
Почему нужен launder в destroy? Если клиент сохранил старый указатель и потом плэйсмент‑конструировал новый объект тем же типом поверх него, у компилятора возникнет соблазн оптимизировать повторный деструктор как dead store.
Что это вообще значит? Какой соблазн? Какая строка в стандарте позволяет эту оптимизацию? Где ассемблер, показывающий, что какой-то компилятор это делает? Поймите меня правильно, я не утверждаю, что этот абзац некорректен — я не знаю, — но в нём, на мой взгляд, содержится недостаточно информации; просто «trust me, bro».
И цитату я эту взял просто в пример: вся статья такая. На мой взгляд, std::launder в большинстве примеров вообще не нужен. Прав я? Не уверен, но статья меня совершенно не убедила в том, что написанное в ней соответствует действительности. В конце концов, можно посмотреть реализацию std::variant/`optional` в libc++/libstdc++, и там не будет launder. Совпадение? Не думаю.
Ну я вроде обратного и не утверждал? Последовательность патчей это вообще не про git, а pack files я привёл только из-за упоминания патчей в Вашем комментарии. Т. к. они хранят дельту, они ближе всего к понятию патчей, но это всего лишь деталь реализации, связанная с оптимизацией. Можно легко представить git без оптимизации, где вообще дельты не хранятся ни в каком виде.
Если заменить cmd на WT в системе, то console-приложения из MSVC будут открываться, как вкладки в WT. В Win11 это работает из коробки, на счёт предыдущих версий не в курсе.
Мы не знаем условий задачи. А раз не знаем, то почему мы должны ограничиваться стандартом? SEH на Windows, и сигналы на Linux должны дать требуемый результат. В реальных проектах такого использовать, конечно же, нельзя, но почему на идиотскую задачу нельзя дать соответствующий ответ?
С метаклассами стандарт C++ имеет все шансы из трудночитаемого нечто, превратиться в хорошо описанный документ, где трудных мест будет куда меньше, чем сейчас. Кроме того, это позволит реализовывать общие паттерны единообразно и легко. Позволит уменьшить количество кода-повторений (boilerplate). Ума не приложу, как можно воспринимать метаклассы как что-то отрицательное…
И да, на любом языке можно писать в режиме write-only, только не всегда дело в языке. В C++ нет каких-то «врождённых» проблем, который выдают write-only любым программистом. Точнее есть, но их немного, и они постепенно решаются, в том числе всё большим обузданием SFINAE нормальными инструментами. Т.е. язык явно движется в сторону большей выразительности, а не наоборот.
Неоднократно сталкивался с подобными историями (не лично). Почти всегда результат от доведение сведений до рогоносца выливался в проблемы для доводящего. Был и личный случай, когда я хорошему знакомому сообщил сведения касательно его пассии. Но пассия была обелена, а я был предан анафеме за «клевету».
Поэтому, на мой взгляд, совет не лезть в чужие отношения является наиболее правильным. Если человек не видит, что творит его партнёр, то это его проблема. Влезть туда третьему это почти всегда ошибка.
Вот ещё один вариант, и кто так читает? Кроме Вас, естественно. Потому что видя фиксацию, люди обычно соотносят текст именно с ней, а не с изменениями. Именно поэтому чаще всего в природе встречаются два варианта: «[This commit] fixes blah blah» и «[This comment] fixed blah blah».
Ну и просто как добавка-придирка: git-commit это не набор изменений, чтобы говорить о них в тексте. git-commit это состояние репозитория, т.е. куда логичнее говорить о том, что в этой фиксации что-то было исправлено, либо же, что эта фиксация что-то исправляет.
Если же взять Ваш вариант, то получается:
Исправляют бла бла
Разве это не выглядит странно? Так в русском языке это ещё понять можно, что имеется в виду какое-то множественное число. Видя такой комментарий на английском, у меня закрадывается подозрение, что у человека просто плохо с языком. Только потом узнаешь, что это адепты какого-то нового стиля, который непонятно зачем и кому нужен.
Коммит это именно что зафиксированная история, которую нельзя изменить. Можно сделать другой коммит зафиксировав другие изменения, переписав историю. Но от этого изначальный коммит не изменится.
Язык заголовков новостных статей не имеет ничего общего с тем, что написано в статье. Ни по применимости, ни по причинности. Сколько раз я встречаю попытку навязывания повелительного наклонения, столько раз вижу одно и то же невнятное объяснение про «The commit message describes what the commit will do if published». Обычно, если какой-то метод удобен, то его не нужно объяснять какими-то абсурдными вещами. Лично для меня очевидно, что этот метод написания неудобен, т.к. он абсолютно неинтуитивен и к нему нужно привыкать. С чего я должен к нему привыкать?
Та ссылка, что Вы привели, описывает вещи, которые очевидны: заголовок должен быть броским и коротким, именно поэтому там применяются вышеозначенные правила. Эти правила ясны и понятны (и не применяются в примерах хороших заголовков фиксаций в этой статье, кстати), правило повелительного наклонение непонятно и притянуто за уши.
Я с Вами по сути согласен, я был тоже очень воодушевлён, когда много лет назад Саттер рисовал красивые картины светлого будущего, где в стандарте C++ будет много библиотек и потом как заживём... Но затем я увидел, с какой скоростью происходит реализация библиотек в MSVC/gcc/clang, и мой оптимизм полностью сошёл на нет. Вплоть до того, что я предпочитаю {fmt}
std::format, потому что так мне нужно бодаться с одной библиотекой, вместо трёх, если что-то пойдёт не так.Возможно ли, что ситуация изменится? Да, но для этого нужны хорошие вливания в MSVC/gcc/clang, а после фортеля от White House про «безопасные языки» ждать этого не приходится. По крайней мере от США. Так что фантазировать можно сколько угодно, но реальность на данный момент STL описал очень хорошо.
Но хорошо, что необходимости тащить библиотеки в стандарт всё-таки нет, т. к. туда зачастую хотят тащить уже имеющиеся, проверенные временем решения, которые можно использовать уже сейчас.
Этот, как Вы выразились, ноунейм имеет имя: Stephan T. Lavavej. Он единственный мейнтейнер стандартной библиотеки от Microsoft. И я бы рекомендовал прислушаться к тому, что говорит этот человек, когда речь идёт о стандартной библиотеке. Он знает, о чём говорит.
О чём свидетельствует, кстати, скорость реализации
std::format,std::rangesи прочих «простых» библиотек. Лично я уже давно пришёл к выводу, что C++ не в состоянии вывезти сложные библиотеки через стандарт, потому что минимум 3 реализации, которые, как я понимаю, друг у друга брать не могут, это слишком много.Вот хороший ответ про сеть в стандарте.
Многим людям тяжело читать стандарт, поэтому наличие такой реализации было бы хорошим стартом, потому что такие оптимизации просто так не делают. Если такая реализация есть, то весьма вероятно, она разрешена стандартом. Отсюда и запрос: предоставить хоть какие-то доказательства слов.
Очередная статья, которая обещает сорвать все покровы с
std::launder, но не делает этого.Что это вообще значит? Какой соблазн? Какая строка в стандарте позволяет эту оптимизацию? Где ассемблер, показывающий, что какой-то компилятор это делает? Поймите меня правильно, я не утверждаю, что этот абзац некорректен — я не знаю, — но в нём, на мой взгляд, содержится недостаточно информации; просто «trust me, bro».
И цитату я эту взял просто в пример: вся статья такая. На мой взгляд,
std::launderв большинстве примеров вообще не нужен. Прав я? Не уверен, но статья меня совершенно не убедила в том, что написанное в ней соответствует действительности. В конце концов, можно посмотреть реализациюstd::variant/`optional` в libc++/libstdc++, и там не будетlaunder. Совпадение? Не думаю.Ну я вроде обратного и не утверждал? Последовательность патчей это вообще не про git, а pack files я привёл только из-за упоминания патчей в Вашем комментарии. Т. к. они хранят дельту, они ближе всего к понятию патчей, но это всего лишь деталь реализации, связанная с оптимизацией. Можно легко представить git без оптимизации, где вообще дельты не хранятся ни в каком виде.
Всё с точностью до наоборот: логически git представляет собой граф снапшотов (деревьев), а вот реализация использует pack files.
Если заменить cmd на WT в системе, то console-приложения из MSVC будут открываться, как вкладки в WT. В Win11 это работает из коробки, на счёт предыдущих версий не в курсе.
Это работает из коробки в Windows 11; скорее всего, оттуда скрины и видели.
Что значит это слово?
И да, на любом языке можно писать в режиме write-only, только не всегда дело в языке. В C++ нет каких-то «врождённых» проблем, который выдают write-only любым программистом. Точнее есть, но их немного, и они постепенно решаются, в том числе всё большим обузданием SFINAE нормальными инструментами. Т.е. язык явно движется в сторону большей выразительности, а не наоборот.
Поэтому, на мой взгляд, совет не лезть в чужие отношения является наиболее правильным. Если человек не видит, что творит его партнёр, то это его проблема. Влезть туда третьему это почти всегда ошибка.
Ну и просто как добавка-придирка: git-commit это не набор изменений, чтобы говорить о них в тексте. git-commit это состояние репозитория, т.е. куда логичнее говорить о том, что в этой фиксации что-то было исправлено, либо же, что эта фиксация что-то исправляет.
Если же взять Ваш вариант, то получается:
Разве это не выглядит странно? Так в русском языке это ещё понять можно, что имеется в виду какое-то множественное число. Видя такой комментарий на английском, у меня закрадывается подозрение, что у человека просто плохо с языком. Только потом узнаешь, что это адепты какого-то нового стиля, который непонятно зачем и кому нужен.
Та ссылка, что Вы привели, описывает вещи, которые очевидны: заголовок должен быть броским и коротким, именно поэтому там применяются вышеозначенные правила. Эти правила ясны и понятны (и не применяются в примерах хороших заголовков фиксаций в этой статье, кстати), правило повелительного наклонение непонятно и притянуто за уши.