Использование ООП в драйверах ядра

Где-то читал, что нельзя использовать классы и прочую объекто-ориентированную лабудень в драйверах режима ядра.
Решил вот проверить ( доверяй, но проверяй )
Прекрасно работают классы, виртуальные функции и прочие прелести.
А если определить операторы new и delete:

Код (Text):

1. void* __cdecl operator new(unsigned int nBytes)
2. {
3.     return ExAllocatePoolWithTag( NonPagedPool, nBytes, 'wen<' );
4. }
5.  
6. void __cdecl operator delete(void* Object)
7. {
8.     ExFreePool( Object );
9. }

то можно и динамически создавать объект и компилятор автоматом вставит вызов конструктора и деструктора.

Так вот вопрос теперь. Действительно ли какие-то прелести объектно-ориентированного С++ не прокатят в ring0, или же меня нагло обманули?

 

"Можно, если осторожно". У Cоmpuware целый ООП фреймворк.

 

Ну вот я и спрашиваю, какие осторожности надо соблюдать) Потому что я пока что ничего странного не выявил.

 

Great

Человеку свойственно бояться того, что он не понимает )

 

Ну почему же ты решил, что я не понимаю? =)

 

Great

Да я не о тебе - я об авторе мнения что

 

лоол я это кажется прочитал в мсдн =)))))))))))))))00

ну вообщем какие есть мысли насчет того, что нельзя использовать?

 

Наверное нельзя использовать потому, что неизвестно что пользователь поподключает, и чему это приведет (в смысле инициализации). А если это твои объекты написанные с нуля - то можно (хотя тоже неизвестно во что компилятор это все превратит).

 

Great

Если серьезно, то все это полный бред. ООП ничем не хуже процедур для написания драйверов, т.к. классы и объекты это всего лишь концептуальные понятия, не имеющие никакого отношения к особенностям генерации кода.

 

ООП в драйверах... зачем? С точки зрения удобства, ну это кому как. С точки зрения того, что будет сгенерировано - мусора только больше, имхо супер баян.

 

EP_X0FF
это скорее проверялось из любопытства, чем для реального использования..

 

Обманули. К сожалению, давно уже вся ООП-хрень работает и в ядре.

Насчет нельзя мыслей нет. MS сказала можно и нужно и выпустила KMDF. Ну а юзать или нет - это кто какому богу поклоняется.

 

EP_X0FF

Бред. Какого еще мусора?

 

Хе. Как какого? Связанного с ООП. Таблицы методов классов хотя бы те же.

 

n0name
мм насколько я помню создается только _vftable для виртуальных методов..

 

n0name

Для обеспечения динамического полиморфизма необходима таблица виртуальных функций, и это не мусор а естественный элемент. Во-первых, никто не заставляет пользоваться динамикой - суть ООП далеко не в этом. Во-вторых, приведи-ка примеры еще какого-нить "мусора", кроме таблиц виртуальных функций.

 

_DEN_

Бред =) А ты скомплируй два драйвера и сравни

 

EP_X0FF

Заняться мне больше нечем. "Мусор" в исполняемом коде всецело зависит от компилятора. Используй нормальные компиллеры с правильными опциями. Концепция практически любого языка не имеет жестких завязок на правила генерации машинного кода, поэтому выражения типа "С точки зрения того, что будет сгенерировано - мусора только больше" говорят о поверхностном знании предметной области и излишней самоуверенности. Ничего личного.

 

а плюсовые ексепшины интересно корректно работают в ядре? проверял кто-нибудь?
ООП без ексепшинов - это уже не ООП

 

z0mailbox
Надо проверить..