Судя по последним сообщениям на форуме, C++ в ядре Windows уже не редкость.
Если кто-то пропустил, Microsoft анонсировала часть STL для использования в ядре:

The header structure of the STL was changed to allow use of a subset of the library in conditions where the user can’t link with msvcp140.dll, such as driver development. (Previously the hard dependency on msvcp and pragma detect mismatch were injected by our base configuration header included by everything.) The following headers are now considered “core” and don’t inject our runtime dependencies (though we do still assume some form of CRT headers are present):

• <cstddef>
  
• <cstdlib>
  
• <initializer_list>
  
• <ratio>
  
• <type_traits>

We aren’t actually driver developers ourselves and are interested in feedback in this area if there are things we can do to make these more usable in constrained environments.

Это, конечно, не shared_ptr, но уже хоть что-то.

Здравствуйте, EreTIk, Вы писали:

ETI>Судя по последним сообщениям на форуме, C++ в ядре Windows уже не редкость.

Он и десять лет назад не был редкостью.

ETI>Microsoft анонсировала часть STL для использования в ядре

Главное, чтоб они не притащили туда весь STL вместе с прочими плюшками, а то колхозно слепленных (и оттого дико тормозящих) драйверов все больше и больше.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Он и десять лет назад не был редкостью.
Да, но 10 лет назад любое публичное упоминание C++ в контексте Windows Kernel начинало холивар

ЕМ>Главное, чтоб они не притащили туда весь STL вместе с прочими плюшками, а то колхозно слепленных (и оттого дико тормозящих) драйверов все больше и больше.
ИМХО: пусть лучше плюшки от MS, чем велосипеды от начинающих.

Здравствуйте, EreTIk, Вы писали:

ETI>10 лет назад любое публичное упоминание C++ в контексте Windows Kernel начинало холивар

Лично я и двадцать лет назад делал драйверы (и под NT, и под Win9x) исключительно на C++. Чистый C бросил еще в середине 90-х. А упоминание C++ в контексте программирования микроконтроллеров (особенно мелких вроде ATTiny13) до сих пор вызывает холивар.

Здравствуйте, EreTIk, Вы писали:

ETI>Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>>Он и десять лет назад не был редкостью.
ETI>Да, но 10 лет назад любое публичное упоминание C++ в контексте Windows Kernel начинало холивар

ну не все так трагично. Был же NuMega DriverStudio например, на нем много чего писалось

ЕМ>>Главное, чтоб они не притащили туда весь STL вместе с прочими плюшками, а то колхозно слепленных (и оттого дико тормозящих) драйверов все больше и больше.
ETI>ИМХО: пусть лучше плюшки от MS, чем велосипеды от начинающих.

+1

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>А упоминание C++ в контексте программирования микроконтроллеров (особенно мелких вроде ATTiny13) до сих пор вызывает холивар.
только потому, что для кучи мелких железок до сих пор нет плюсовых компиляторов. И правильно.

Здравствуйте, mike_rs, Вы писали:

_>для кучи мелких железок до сих пор нет плюсовых компиляторов.

Сколь велика та куча? Для 8-разрядных AVR/PIC они есть давным-давно, а какие другие MC имеют сравнимую распространенность?

а может кто расшарить это чудо для посмотреть ?
качать всякие wdk ddk и прочее как то накладно

наверное там где код сразу в байт коде пишут ))

Здравствуйте, reversecode, Вы писали:

R>а может кто расшарить это чудо для посмотреть ?
Содержимое %ProgramFiles(x86)%\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>А упоминание C++ в контексте программирования микроконтроллеров (особенно мелких вроде ATTiny13) до сих пор вызывает холивар.

Давно уже есть подобные либы, достаточно попробовать: практически нет накладных расходов, надо намного реже лазать по даташитам, можно писать сразу под семейство МК, без всяких #ifdef

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Для 8-разрядных AVR/PIC они есть давным-давно, а какие другие MC имеют сравнимую распространенность?
STM32, не?

Здравствуйте, LimyKurn, Вы писали:

ЕМ>>какие другие MC имеют сравнимую распространенность?

LK>STM32, не?

Что за проблема с компиляторами C++ для STM32?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, LimyKurn, Вы писали:

ЕМ>>>какие другие MC имеют сравнимую распространенность?

LK>>STM32, не?

ЕМ>Что за проблема с компиляторами C++ для STM32?

Да не знаю. Я совсем мало под него писал. Еще не дошел до того, когда уже хочется STL.
Просто ты спросил: "какие другие MC имеют сравнимую распространенность", а я ответил.

Здравствуйте, LimyKurn, Вы писали:

LK>Я совсем мало под него писал. Еще не дошел до того, когда уже хочется STL.

STL в C++ — чисто внешняя (по отношению к языку) библиотека, дополнительная плюшка. C++ по сравнению с C удобен (на любой платформе) прежде всего тем, что позволяет яснее выразить замысел кодом, избавляет от части рутинного текста, облегчает контроль типов, значений и отладку, и т.п.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, LimyKurn, Вы писали:

LK>>Я совсем мало под него писал. Еще не дошел до того, когда уже хочется STL.

ЕМ>STL в C++ — чисто внешняя (по отношению к языку) библиотека, дополнительная плюшка. C++ по сравнению с C удобен (на любой платформе) прежде всего тем, что позволяет яснее выразить замысел кодом, избавляет от части рутинного текста, облегчает контроль типов, значений и отладку, и т.п.

Ни о чем это не может идти речь на этапе "дрыгания ногами" или освоения USB (которое на STM32 заняло 2 вечера, притом, что у меня не один, не два и не три года стажа в целом, и нового освоил много). В том числе, для отладки прежде всего нужно настроить отладку, чтобы была хоть какая возможность отладки, а уже потом упрощать.

И то, что C++ удобен прежде всего синтаксисом и т.п., — чушь. Библиотеки — STL, Boost, Qt, fc — гораздо важнее в целом. Но везде, где низкий уровень, они в пролете.

Здравствуйте, LimyKurn, Вы писали:

LK>Ни о чем это не может идти речь на этапе "дрыгания ногами" или освоения USB

С чего бы вдруг речь не могла об этом идти?

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

Угу. Только когда отладка удобно встраивается в любой объект с неизвестным наперед поведением, и отладочые вызовы выглядят компактно и изящно, это очень стимулирует добавлять отладочные выводы по мере разработки, а не в крайнем случае.

LK>И то, что C++ удобен прежде всего синтаксисом и т.п., — чушь.

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

LK>Библиотеки — STL, Boost, Qt, fc — гораздо важнее в целом.

Подобных библиотек есть 100500 под каждый язык, они полностью независимы от реализации самого языка. В С++, на мой взгляд, совершенно зря добавили STL в стандарт языка. Представьте, что версия MFC была бы жестко привязана к версии винды, и невозможно было бы использовать более свежий MFC без обновления всей винды. На язык (как способ записи алгоритма и представления данных) должен быть свой стандарт, на сопровождающие его библиотеки — свой.