Ну я вроде обратного и не утверждал? Последовательность патчей это вообще не про 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». Обычно, если какой-то метод удобен, то его не нужно объяснять какими-то абсурдными вещами. Лично для меня очевидно, что этот метод написания неудобен, т.к. он абсолютно неинтуитивен и к нему нужно привыкать. С чего я должен к нему привыкать?
Та ссылка, что Вы привели, описывает вещи, которые очевидны: заголовок должен быть броским и коротким, именно поэтому там применяются вышеозначенные правила. Эти правила ясны и понятны (и не применяются в примерах хороших заголовков фиксаций в этой статье, кстати), правило повелительного наклонение непонятно и притянуто за уши.
Вы знаете, я со своей Lumia 920 тоже ждал, когда выйдет новый телефон, но так и не дождался. Хотя терпеть не могу iOS и Android, я всё же купил себе новую Nokia и скажу только одно: Excel и Skype на Android гораздо лучше тех Excel и Skype, которые были у меня на Windows Phone. Чтобы MS не говорило, и как бы она не сетовала на слабую популярность их ОС у разработчиков, они сами плюнули на собственную ОС. Поэтому, я полагаю, ждать от них больше ничего не стоит. По крайней мере с текущим руководителем.
О чём я Вас и прошу: процитируйте стандарт и докажите, что пример в статье содержит UB. Я утверждаю, что он его не содержит (по крайней мере для C++11, 03 под рукой нет), и ваш анализатор ошибся. Мне кажется, это в интересах компании найти ошибку, или нет?
P.S. Документация к диагностике V567 устарела и содержит примеры UB, которые больше им не являются (X[i]=++i и т.д.). Собственно там документация говорит о точках следования, которых уже 6 лет как нет.
1. Не находите ли Вы, что в 2017 году ошибка вида «The 'p' variable is modified while being used twice between sequence points» несколько устарела? Не лучше ли использовать что-то типа «The multiple modifications of the 'p' variable are unsequenced» (тоже мне не нравится, но смысл должен быть ясен).
2. Я считаю, что PVS нашёл UB там, где его нет. Этот код, насколько я понимаю, является корректным, а предупреждение PVS — нет. Можете доказать обратное?
Всё верно, bool-переменная может иметь только два значения: true, false. Никакого третьего значения там быть не может. Undefined behavior, по определению, означает, что программа может вести себя как угодно, и никакую логику к ней применить уже нельзя.
Ну я вроде обратного и не утверждал? Последовательность патчей это вообще не про 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 это состояние репозитория, т.е. куда логичнее говорить о том, что в этой фиксации что-то было исправлено, либо же, что эта фиксация что-то исправляет.
Если же взять Ваш вариант, то получается:
Разве это не выглядит странно? Так в русском языке это ещё понять можно, что имеется в виду какое-то множественное число. Видя такой комментарий на английском, у меня закрадывается подозрение, что у человека просто плохо с языком. Только потом узнаешь, что это адепты какого-то нового стиля, который непонятно зачем и кому нужен.
Та ссылка, что Вы привели, описывает вещи, которые очевидны: заголовок должен быть броским и коротким, именно поэтому там применяются вышеозначенные правила. Эти правила ясны и понятны (и не применяются в примерах хороших заголовков фиксаций в этой статье, кстати), правило повелительного наклонение непонятно и притянуто за уши.
P.S. Документация к диагностике V567 устарела и содержит примеры UB, которые больше им не являются (X[i]=++i и т.д.). Собственно там документация говорит о точках следования, которых уже 6 лет как нет.
1. Не находите ли Вы, что в 2017 году ошибка вида «The 'p' variable is modified while being used twice between sequence points» несколько устарела? Не лучше ли использовать что-то типа «The multiple modifications of the 'p' variable are unsequenced» (тоже мне не нравится, но смысл должен быть ясен).
2. Я считаю, что PVS нашёл UB там, где его нет. Этот код, насколько я понимаю, является корректным, а предупреждение PVS — нет. Можете доказать обратное?