Указали выше. Аугментация есть только у интерфейсов.
То есть когда у нас есть interface A{} это позволяет добавить к нему функционал которого не было изначально .
Этим пользуются когда у нас есть стандартные типы из JS , а наш проводник скажем умеет больше и с помощью интерфейсов легко добавить дополнительные свойства и методы.
А такой вопрос как телевизор будет знать какую именно рекламу показывать?
Видимо придётся слушать всё, что говорят, смотреть всё, что смотрят, сканировать все устройства и трафик и делится этим всем с производителем в надежде, что только с ним.
А ещё если у нас конструктор перемещения объявлен noexcept , то мы получаем дополнительное быстродействие от коллекций так как можем избавиться от копирования.
Кстати, я был неправ, что всегда было 6ит. Тут староверы говорят раньше 80бит поддерживалось, но решено было убрать.
Ну тут пример как раз плохого дизайна API. Мало того, что не сделали как все возврат HRESULT с out параметром, так ещё и генерировали это своей утилитой. Ну и наткнулись на неожиданное поведение компилятора. Моглм бы конечно решить, но видимо мало нуждающихся в C API.
Можно попросить, чтобы вернули если очень надо.
Пользуясь случаем , а зачем вам именно C, в не C++?
У некоторых перечисленных уже есть precommit hook.
А ещё можно использовать git обёртку во многих случаях.
Zip архив ведь как-то создавался с системой контроля версий. Вот там и добавить.
При сборке конечно можно форматировать, только это не на каждую сборку стоит делать, а только на финальную иначе сборка будет занимать приличное время когда файлов будет много.
Как же статья без упоминания Necromancer’s DOS Navigator?
https://ndn.muxe.com
Можно только это создаёт другой тип.
А в случае с интерфейсом добавление свойств в интерфейс не создаёт нового типа..
Указали выше. Аугментация есть только у интерфейсов.
То есть когда у нас есть interface A{} это позволяет добавить к нему функционал которого не было изначально .
Этим пользуются когда у нас есть стандартные типы из JS , а наш проводник скажем умеет больше и с помощью интерфейсов легко добавить дополнительные свойства и методы.
А такой вопрос как телевизор будет знать какую именно рекламу показывать?
Видимо придётся слушать всё, что говорят, смотреть всё, что смотрят, сканировать все устройства и трафик и делится этим всем с производителем в надежде, что только с ним.
Что-то упустил ? ;)
А ещё если у нас конструктор перемещения объявлен noexcept , то мы получаем дополнительное быстродействие от коллекций так как можем избавиться от копирования.
В Rust просто нет конструкторов, вот и проще :)
В C++ решается приватным конструктором и фабричным методом как в Rust.
Интересно, что ограничили начало жизни объекта определёнными функциями хотя обычно в C++ стараются делать такое расширяемым.
Было бы уместней ввести атрибут и тогда пользовательские функции как скажем HeapAlloc могли бы работать также как и malloc.
Есть несколько пакетных менеджеров.
Может они не все достаточно нормальные, но мне и другим в команде хватает.
WinGet
Chocolatey
Scoop
Не скажу за Амазон, но скажу за другую большую компанию.
Во первых очень разнится внутри той же компании, отделов, даже команд.
Кто-то реально работает с новыми технологиями , а кто-то со страшным легаси.
У одних можно пробовать новые фишки , а у других даже починить что-то несущественное это нереальная бюрократия.
На правах шутки: https://www.instagram.com/reel/C7y93VkoXuO/
Если уже есть желание научиться чему-то новому, я бы посоветовал тогда взять переписывание на Rust .
При чём можно писать даже в стиле C для начала. Ничего зазорного в этом нет, не нужно слушать догматиков.
https://cliffle.com/p/dangerust/
Кстати, я был неправ, что всегда было 6ит. Тут староверы говорят раньше 80бит поддерживалось, но решено было убрать.
Ну тут пример как раз плохого дизайна API. Мало того, что не сделали как все возврат HRESULT с out параметром, так ещё и генерировали это своей утилитой. Ну и наткнулись на неожиданное поведение компилятора. Моглм бы конечно решить, но видимо мало нуждающихся в C API.
Можно попросить, чтобы вернули если очень надо.
Пользуясь случаем , а зачем вам именно C, в не C++?
Да, с C11 комплексные числа являются опциональными. Полагаю это связано с тем, что не все реализовали их в C99.
VLA также опционально не реализован в MSVC, некоторые считают что и в GCC не нужно было реализовывать.
В MSVC Long Double всегда был 64 бит, но это также не является отклонением от стандарта.
Можно реализовать 80-битное число вручную с вызовом ассемблернвх инструкций. Такие реализации уже есть.
И проголосовать: https://developercommunity.visualstudio.com/t/Add-80-bit-or-more-long-double-in-Visual/1533848?entry=myfeedback&space=8
Это особенно смешно когда читаешь проблемы пуска 95 упомянутых в статье: «Высокое потребление ресурсов памяти».
Ждём очередное революционное решение в Windows 12.
Как раз проконтролировать запись при intent(out) это возможно , аннотации кода уже умеют это делать.
А вот то что старый код останется , это так.
MSVC давно поддерживает C99, и даже C17:
https://learn.microsoft.com/en-us/cpp/overview/visual-cpp-language-conformance?view=msvc-170
Увы нет. Более того было можно пока и эту лавочку не прикрыли.
Только жаловаться через Win+F (Feedback) и уповать на снисхождение до простого народа.
Пуск можно вернуть влево. Старое меню в проводнике открывается если держать Shift.
Ну или не пользоваться проводником, а другим как Double Commander. Тогда всё по старому.
У некоторых перечисленных уже есть precommit hook.
А ещё можно использовать git обёртку во многих случаях.
Zip архив ведь как-то создавался с системой контроля версий. Вот там и добавить.
При сборке конечно можно форматировать, только это не на каждую сборку стоит делать, а только на финальную иначе сборка будет занимать приличное время когда файлов будет много.
Дополню ответ утилитой pre-commit или ручной pre commit hook чтобы не забыть отформатировать перед комитом в случае правки в другом редакторе.
IoT LTSC
https://habr.com/ru/articles/828670/