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

M>Шаблоны не могут влиять на размер использованного стека , а на примере std::vector покажете ? это достаточно серьезный шаблон ?
Это не шаблон. Это коллекция, сделанная на шаблонах.

Hi olegkr

M>>Шаблоны не могут влиять на размер использованного стека , а на примере std::vector покажете ? это достаточно серьезный шаблон ?
O>Это не шаблон. Это коллекция, сделанная на шаблонах.

А что тогда шаблон? И как он увеличивает использование стека?

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

EOH>>Уровень ядра — все очень жестко с памятью. В частности, памяти под стэк очень мало. Серьезный шаблон с STL не влезет.

M>Шаблоны не могут влиять на размер использованного стека , а на примере std::vector покажете ? это достаточно серьезный шаблон ?

Легко В реализации вижалки его размер байт 16, а в жёстких условиях хватит 6-8.

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

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

EOH>>>Уровень ядра — все очень жестко с памятью. В частности, памяти под стэк очень мало. Серьезный шаблон с STL не влезет.

M>>Шаблоны не могут влиять на размер использованного стека , а на примере std::vector покажете ? это достаточно серьезный шаблон ?

NBN>Легко В реализации вижалки его размер байт 16, а в жёстких условиях хватит 6-8.

а при чем тут шаблон ? делайте 6-8 ... кто запрещает

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

x64>>>Потому что драйвера на C++ считаю извращением
CC>>Смотря что ты понимаешь под C++.
CC>>Если груду шаблонов вперемешку с STL и исключениями — да, в дровах такому не место.

M>Почему?
потому что как уже сказали — есть ограничения на стек, нет полноценной поддержки RTTI и исключений, STL в полной мере тоже отсутствует и прочие моменты. Если конкретно по шаблонам (да и inlines тут многое касается) говорить, то не надо с ними заигрываться в ядре потому что для начала неизвестно, куда попадет сгенеренный компилятором шаблонный код — в pageable память или нет. А для нас это бывает очень важным когда paging уже недоступен, а pagable кода в памяти еще нет.

К тому же это дело (контроль того, куда лягут конструкторы, таблицы вирт ф-ий и т.п. детали реализации С++ штучек) не регулируется компилятором и прагмами тут тоже не всегда решается.

Короче говоря ликбез на эту тему доступен здесь.

Тем не менее все совсем не так плохо, как возможно считают некоторые адепты С выше по ветке и лично я уверен С++ в ядре — быть! Собственно, он уже там весьма давно и с успехом применяется, в т.ч. ядерными (не всеми) командами в MSFT.

Просто нужно четко понимать что у нас есть и что можно (и когда), а что нельзя и почему.
В этом плане ничего нового, просто цена незнания бывает более суровой, чем в мире куда долетает свет GUI

Здравствуйте, Valery A. Boronin, Вы писали:

VAB>потому что как уже сказали — есть ограничения на стек, нет полноценной поддержки RTTI и исключений, STL в полной мере тоже отсутствует и прочие моменты.
RTTI и исключения, кстати, можно сделать

VAB>Если конкретно по шаблонам (да и inlines тут многое касается) говорить, то не надо с ними заигрываться в ядре потому что для начала неизвестно, куда попадет сгенеренный компилятором шаблонный код — в pageable память или нет. А для нас это бывает очень важным когда paging уже недоступен, а pagable кода в памяти еще нет.
По факту — всё кладётся в non-paged memory.

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

VAB>>потому что как уже сказали — есть ограничения на стек, нет полноценной поддержки RTTI и исключений, STL в полной мере тоже отсутствует и прочие моменты.
C>RTTI и исключения, кстати, можно сделать
прошу записать в протокол, что я не говорил что нельзя. Правда поддержку исключений будет сделать непросто, учитывая "современное развитие печатного дела на Западе". Да и SEH есть. Равно как и необходимость в RTTI часто есть признак неоптимального проектирования. Так что необходимость в этих механизмах за пару десятилетий особо не возникла именно в ядерном мире и пока не вижу подвижек в этом направлении. Ибо есть вещи поважнее

VAB>>Если конкретно по шаблонам (да и inlines тут многое касается) говорить, то не надо с ними заигрываться в ядре потому что для начала неизвестно, куда попадет сгенеренный компилятором шаблонный код — в pageable память или нет. А для нас это бывает очень важным когда paging уже недоступен, а pagable кода в памяти еще нет.
C>По факту — всё кладётся в non-paged memory.
Возможно, только не у всех и не всегда.

иначе бы не было вещей, описанных в документе который можно было бы обозвать вместо "С++ в ядре: за и против" "С++ в ядре: Кровь, пот и слезы", натурально

Здравствуйте, Valery A. Boronin, Вы писали:

C>>RTTI и исключения, кстати, можно сделать
VAB>прошу записать в протокол, что я не говорил что нельзя. Правда поддержку исключений будет сделать непросто, учитывая "современное развитие печатного дела на Западе". Да и SEH есть.
Ну собственно, SEH и используется для этого.

VAB>Равно как и необходимость в RTTI часто есть признак неоптимального проектирования. Так что необходимость в этих механизмах за пару десятилетий особо не возникла именно в ядерном мире и пока не вижу подвижек в этом направлении. Ибо есть вещи поважнее
Ну да, RTTI (как и множественного виртуального наследования) нафиг не нужна в большинстве случаев. Просто я говорю, что и её можно сделать

А вот исключения как раз очень кстати бывают.

C>>По факту — всё кладётся в non-paged memory.
VAB>Возможно, только не у всех и не всегда.
Всегда и у всех пока что. Это скорее как теоретическая угроза, но раз сам MS использует С++ в ядре, то вряд ли они станут это ломатью

Ну и в крайнем случае, можно будет написать пост-процессор .obj-файлов, добавляющий нужные аннотации для сгенерированных блоков.

VAB>иначе бы не было вещей, описанных в документе который можно было бы обозвать вместо "С++ в ядре: за и против" "С++ в ядре: Кровь, пот и слезы", натурально
Нет, почему. Для С++ников там вполне очевидные вещи написаны.