Re[45]: опять cpp в драйвере... - Низкоуровневое программирование

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

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

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

E>>>Я тебе советовал получить больше практического опыта в разработке драйверов.И для разных типов драйверов.Тогда ты будешь лучше понимать какие проблемы разработчик решает в кернеле.

IID>>Ты меня забавляешь

Здравствуйте, Аноним, Вы писали:

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

А>я не говорю что и на С и на С++ можно такое накодить... лес дров и :%?*:%?: неразбериха
А>но не будем рассматривать этот момент.
Насколько я знаю написанны только некоторые компоненты на С++.Хотя я в Microsoft не работаю и точно не знаю.
Ядро Linux вообще все на С.Неужели Linus Torvalds такой закостенелый что не хочет переписовать все на С++?

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

IID>>Ты меня забавляешь

Нет, ну серъёзно. Отставь в сторонку свой высокомерный тон. gear_nuke специалист, и специалист высокого класса. Чтобы это понять достаточно почитать его посты на РСДНе. А пока твои высказывания напоминают попытку научить курицу нести яйца.
E>Пока я не увидел на его примерах реального применения С++.Я имею ввиду то что нельзя сделать на С в kernel. Если бы у него был достаточный опыт разработки драйверов для железа, которые в основном и разрабатываются для Windows kernel, то он бы не приводил тот пример как преимущества С++ над С.
не вполне согласен с выделенным — скорее наоборот, давайте все вместе позагибаем пальцы:

1) многие драйвера для некоторых вещей (типа USB девайсов) уже давно подходят базовые
2) MSFT давно озаботилось вопросами совместимости в "новых" ОС и постаралось сделать так, чтобы нам не было нужды переписывать свои грамотно сделанные решения, привет адептам "хуков на каждый чих" (с)
3) минифильтры, офрэймворчивание, класс-порт-минипорт-минидрайвер модель проникает во все места, что опять же при определенном уровне понимания (куда и зачем нужно врезаться) значительно уменьшает объем необходимых телодвижений, несмотря на по-прежнему существенную кривизну learning curve
4) KMDF/WMDF/DSF и прочие F активно способствуют тому, чтобы работа в т.ч. и с железом шла в большей степени через код, также написанный MSFT — в т.ч. и для вот этого
5) портированием с 32х бит уже тоже почти все озаботились, кто-то уже даже не строит 32-битные билды, этот рынок тоже сжимается

Разумеется, теперь глядя на образовавшийся кулак — можно понять, что колбасить по образу и подобию понятной сложности драйвера на базе десятилетиями отлаживаемых всем миром драйверов из DDK/WDK — можно (а иногда и нужно) и это разумно. Наверняка можно таким темпом поддерживать и новые семейства уже обкатанных в целом железяк еще не одно десятилетие.

А вот продукты, тесно переплетающиеся с ядром на программном (выше HAL и DMA transfers) уровне (c компонентами типа software drivers в составе) — капитально наращивают сложность. С которой, как тут пытается объяснить gear nuke, и связаны определенные проблемы (с которыми, похоже, просто не так активно сталкиваются именно что разработчики железных драйверов), решаемые в т.ч. и с помощью тех же плюсов. Хотя они (плюсы) и не панацея, конечно, ибо как и любой инструмент — все зависит от того, в чьих он руках. И это есть хорошо для нас — проблемы с job security для многих из нас в этом форуме в обозримом будущем явно не грозят.

Резюмируя, пока драйвера для железа "держат марку" — продукты потихоньку уходят в отрыв. Возможно, это лучше объясняет разрыв в мнениях в топике.

PS почему продукты однозначно наращивают сложность, кто-то может быть спросит? Да потому что есть такой закон — сколько мощи не дай инженерам — они постараются задействовать всю максимально быстро. И уж поверьте мне, это не новый драйвер диска или audio driver будет требовать "в топку" новых ресурсов в таких объемах. Это будут новые релизы продуктов.

PS Кстати, gear nuke — занеси в коллекцию серьезных С++ проектов в ядре изделия от Lumension (более 5 миллионов официально проданных лицензий на endpoint protection решения — данные начала 2009 года) — там на C++ (без фанатизма и дозированно) все делали с начала тысячелетия и это оказалось очень правильным, а также очень удобным (это я уже как разработчик режима ядра со стажем говорю) решением.

... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>

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

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

IVAB>Резюмируя, пока драйвера для железа "держат марку" — продукты потихоньку уходят в отрыв. Возможно, это лучше объясняет разрыв в мнениях в топике.

VAB>PS почему продукты однозначно наращивают сложность, кто-то может быть спросит? Да потому что есть такой закон — сколько мощи не дай инженерам — они постараются задействовать всю максимально быстро. И уж поверьте мне, это не новый драйвер диска или audio driver будет требовать "в топку" новых ресурсов в таких объемах. Это будут новые релизы продуктов.

Valery ты смотрешь со своей точки зрения на проблему.Как специалиста который занимается продуктом.Я смотрю на проблему как специалист который в основном занимается железом.И я не вижу уменьшения работы с железом.Несмотря на усилия Microsoft по унификации разработке драйверов, прежде всего в создании модели Port/Miniport, очень часто возникают решения которые не могут использовать эту модель.Пример — virtual miniport StorPort driver, который позволяет разрабатывать storage driver с нижним интерфейсом отличным от HBA .Твой пример с USB не удачный, так как около четверть вопросов на форуме OSR относяться к USB.
Существует другая проблема использования С++.Многие компании разрабатывают керноловские компоненты не только для Windows но и для других OS прежде всего nix.И наиболее подходящий язык для крос-платформых библиотек это С. Для nix платформ очень трудно компилировать С++ для кернел.По этой причине мы даже не используем *.cpp файлы.

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

GN>Может быть сначала можно посмотреть на мелочи? Стал бы использовать:

GN>std::uint32_t вместо DWORD
GN>std::wstring вместо RtlInitUnicodeString & Co?
GN>std::list<> вместо ExInterlockedInsertHeadList & Co?
GN>std::mutex?
GN>std::atomic<> вместо ReadWriteBarrier и CAS?

В minport StorPort driver я не могу использовать RtlInitUnicodeString, ExInterlockedInsertHeadList и ReadWriteBarrier. Я вообще не могу использовать никакие Windows kernel API функций за исключением
функций StorPortXXXXX, которые включают в себя определенные функции memory allocation. Другой Port, например NDIS, включает в себя дрогой набор функций.Это значит что надо разрабатывать каждую версию STL для каждого Port type.И память в драйверах используется разная.

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

E>Ядро Linux вообще все на С.Неужели Linus Torvalds такой закостенелый что не хочет переписовать все на С++?

Ты не поверишь...

А ещё он отладчики не любит, и считает их пережитком прошлого

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

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

E>В minport StorPort driver я не могу использовать RtlInitUnicodeString, ExInterlockedInsertHeadList и ReadWriteBarrier.

Это — нет, но std:: "аналоги" можно будет. ReadWriteBarrier это встроенная функция компилятора.

E> Я вообще не могу использовать никакие Windows kernel API функций за исключением
E>функций StorPortXXXXX, которые включают в себя определенные функции memory allocation. Другой Port, например NDIS, включает в себя дрогой набор функций.Это значит что надо разрабатывать каждую версию STL для каждого Port type.И память в драйверах используется разная.

Вопрос с памятью должен решаться аллокаторами, остальная часть STL не меняется. И код, использующий STL, тоже не меняется, то есть его можно будет перенести в в другой Port, если он там уместен.

GN>std::uint32_t вместо DWORD
Во первых DWORD это из мира Win32. В ядре больше принято ULONG. И ULONG лучше чем std::uint32_t — печатать меньше и проще

GN>std::mutex?
И что он заменит? KeInitializeMutex, ExInitializeFastMutex, ExInitializeResourceLite?
А ждать он как будет? Как указать Alertable, WaitType, WaitReason, WaitMode?
А дождавшись, как можно будет указать что я вот ща опять буду что-то ждать, дабы шедулер заоптимизировал переключение контекстов?

GN>std::wstring вместо RtlInitUnicodeString & Co?
кстати насчет std::wstring и UNIODE_STRING:
1) чтобы удобно юзать std::wstring в ядре надо чтобы у нее был метод, который возвращает указатель на внутренний буфер в виде UNICODE_STRING. в "стандартовом" basic_string такого нету.
2) UNICODE_STRING может быть не NULL-terminated, кроме того может содержать в строке символы-нули что тоже очень плохо накладывается на std::string с ее c_str

кроме того:
3) концепция stl'ным стримов очень хреново, вернее никак, не ложится на концепцию асинхронного IO
4) стек потока в ядре — 12кб. Так что STLные классы придется делать максимально компактными (и сразу отказаться от "минибуфера" в теле basic_string.
....
имхо глупо натягивать STL на ядро. Правильнее сделать некий KTL — Kernel Templates Library, и не гнаться за совместимость со стандартным STL.

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

E>Здравствуйте, Аноним, Вы писали:

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

А>>я не говорю что и на С и на С++ можно такое накодить... лес дров и :%?*:%?: неразбериха
А>>но не будем рассматривать этот момент.
E>Насколько я знаю написанны только некоторые компоненты на С++.Хотя я в Microsoft не работаю и точно не знаю.
E>Ядро Linux вообще все на С.Неужели Linus Torvalds такой закостенелый что не хочет переписовать все на С++?

торвальдс тот еще ублюдок, но не будем об этом.
да и вопрос, а зачем "ВСЕ" переписывать на С++?
есть определенный круг задач http://rsdn.ru/forum/asm/3725161.1.aspx для которых С++ очень гибок и полезен, и также избавляет от лишнего ненужного кодинга

тот же syser, написан на С и С++
базовые основные функциональные обертки на С
а класс прорисовки и управления оконной системой на С++

безграмотный подход — везде пихать только С или только С++
говоря что этот язык лучше или тот
лучше когда они правильно комбинируються — если это требуеться

ps
меня например злит когда ублюдочные программеры пишут на С

void hand_init(struct hand_t *h)
{
....
}

void hand_deinit(struct hand_t *h)
{
....
}

void hand_up(struct hand_t *h)
{
....
}

void hand_down(struct hand_t *h)
{
....
}

void hand_right(struct hand_t *h)
{
....
}

void hand_left(struct hand_t *h)
{
....
}

ну не ублюдки а?
а внутри каждой функции ХХкуча указателей
спрашиваеться почему не поюзать С++?
потому что они..... дальше думаю смысл понятен

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

O>Во первых DWORD это из мира Win32. В ядре больше принято ULONG.

Вот о том и речь, расплодили заопарк. У *них long вообще 64 бита. А в С обычно принято в так писать МАКРОСЫ. В глазах рябит, лишние пустые строки приходится добавлять, функции не помешаются на 3 экрана

O>И ULONG лучше чем std::uint32_t — печатать меньше и проще

Неймспейс можно не печатать и шифт не надо нажимать

GN>>std::mutex?
O>И что он заменит? KeInitializeMutex, ExInitializeFastMutex, ExInitializeResourceLite? А ждать он как будет? Как указать Alertable, WaitType, WaitReason, WaitMode?

recursive_timed_mutex? А сам как считаешь? Смысл стандартной библиотеки — показать как должен выглядеть интерфейс, не запрещая создавать дополнительные реализации. И использовать совместно с lock_guard (оно даже для аттача к АП процесса пдойдёт).

O>А дождавшись, как можно будет указать что я вот ща опять буду что-то ждать, дабы шедулер заоптимизировал переключение контекстов?

В крайнем случая, ипользуя native_handle(); ограничивать никто не будет.

O>кстати насчет std::wstring и UNIODE_STRING:
O>1) чтобы удобно юзать std::wstring в ядре надо чтобы у нее был метод, который возвращает указатель на внутренний буфер в виде UNICODE_STRING. в "стандартовом" basic_string такого нету.

И не надо

Подойдёт конструктор UNICODE_STRING, можно свободной функцией конвертить, вразу принимать std::wstring в конце концов

O>2) UNICODE_STRING может быть не NULL-terminated, кроме того может содержать в строке символы-нули

аналогично std::wstring

O>что тоже очень плохо накладывается на std::string с ее c_str

Зачем c_str() в ядре

O>кроме того:
O>3) концепция stl'ным стримов очень хреново, вернее никак, не ложится на концепцию асинхронного IO

Угу, особенно strstream

Они ж буферизированы и для другого нужны: конфиг распарсить, в лог или дебагпорт писать. Template Unit Test Framework собрать.

Кстати Asio на эту модель хорошо ложится.

O>4) стек потока в ядре — 12кб. Так что STLные классы придется делать максимально компактными
O>и сразу отказаться от "минибуфера" в теле basic_string.

Это что принципиальная проблема С++?

Я вот думаю о полной бинарной совместимости basic_string с UNIODE_STRING...

O>имхо глупо натягивать STL на ядро. Правильнее сделать некий KTL — Kernel Templates Library, и не гнаться за совместимость со стандартным STL.

Софт ведь не "взял и сделал", надо дизайнить и реализовать. Идею взять готовый, изученный массой людей дизайн — ты называешь глупостью. Правильно задизайнить свой велосипед

Вот только колеса и педали меж самодельных велосипедов плохо стыкуются

да и первые 1-2 версии в мусор пойдут

Кстати первую версию можно обсудить, что там должно быть (в дополнение или вместо STL)?

GN>Зачем c_str() в ядре

Затем что std::wstring без c_str уже не является "стандрартовой" basic_string. А string с c_str а ядре тоже совершенно не нужен.

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

IVAB>>Резюмируя, пока драйвера для железа "держат марку" — продукты потихоньку уходят в отрыв. Возможно, это лучше объясняет разрыв в мнениях в топике.

VAB>>PS почему продукты однозначно наращивают сложность, кто-то может быть спросит? Да потому что есть такой закон — сколько мощи не дай инженерам — они постараются задействовать всю максимально быстро. И уж поверьте мне, это не новый драйвер диска или audio driver будет требовать "в топку" новых ресурсов в таких объемах. Это будут новые релизы продуктов.

E>Valery ты смотрешь со своей точки зрения на проблему.Как специалиста который занимается продуктом. Я смотрю на проблему как специалист который в основном занимается железом.
eagersh, FYI — в свое время мне приходилось заниматься и тем и тем. И на С и на С++ — все возможные комбинации перепробовал на собственной шкуре, поэтому считаю что неплохо представляю себе специфику работы коллег по ремеслу.

E>И я не вижу уменьшения работы с железом.
Открою маленький секрет — работы меньше вообще не становится. Никогда

E>Несмотря на усилия Microsoft по унификации разработке драйверов, прежде всего в создании модели Port/Miniport, очень часто возникают решения которые не могут использовать эту модель.Пример — virtual miniport StorPort driver, который позволяет разрабатывать storage driver с нижним интерфейсом отличным от HBA .
Был уверен, кто-то не согласится, что продукты, а не "железо" уходят в отрыв. У меня речь была о другом немного, не о количестве работы или ее сложности для отдельно взятого индивида (или 3х, не суть).

Представь, что твой драйвер лишь часть моего продукта. Да сложный, да возможно весь продукт на него завязан, но это в лучшем случае. В худшем начинаются решения где уже связки драйверов + активности на стыке KM\UM — как ни крути тут общая сложность и энтропия растут быстрее. И это уже не важно какая модель или какие frameworks используются у тебя в компоненте типа драйвер, это есть подмножество всего решения. И поэтому пока при грамотной, слабосвязанной архитектуре и возможно работать с этой частью по-старому, это нормально.

E>Твой пример с USB не удачный, так как около четверть вопросов на форуме OSR относяться к USB.
кол-во вопросов по теме — это не очень удачный критерий в данном случае, не находишь?

впрочем, соглашусь — может быть USB и не самый удачный пример, уверен ты сам можешь подобрать более удачный пример при желании.

E>Существует другая проблема использования С++.Многие компании разрабатывают керноловские компоненты не только для Windows но и для других OS прежде всего nix.И наиболее подходящий язык для крос-платформых библиотек это С. Для nix платформ очень трудно компилировать С++ для кернел.
Можно уточнить, в чем именно сложность такая? вот MSFT давно вывесили документ по поводу ограничений \ нюансов плюсов в ядре под Windows. А тут какие овраги?

E>По этой причине мы даже не используем *.cpp файлы.
спасибо, это мне интересно — поможешь тут разобрать подетальнее?

У меня нет коммерческого опыта в kernel *nix вещах, хотя кроссплатформенными штучками тоже приходилось немного заниматься. И именно поэтому все равно не очень ясно — вот смотри, C++ компилятор есть же под *nix — почему нельзя использовать С++ как "С с классами", чтобы хотя бы не использовать разные языки?

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

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

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

GN>>Зачем c_str() в ядре

O>Затем что std::wstring без c_str уже не является "стандрартовой" basic_string. А string с c_str а ядре тоже совершенно не нужен.

Не пойму, троллишь, или С++ не знаешь?

Еще раз: basic_string может содержать '\0'. "что тоже очень плохо накладывается на c_str". Поэтому c_str нужно пользоваться с учётом этого, то есть не нужно

С чего ты взял что для этого обязательно менять интерфейс?

Для эжтого достаточно почитать описание basic_string.

И всё это никак не зависит от UNICODE_STRING.

GN>Не пойму, троллишь, или С++ не знаешь?

GN>Еще раз: basic_string может содержать '\0'. "что тоже очень плохо накладывается на c_str". Поэтому c_str нужно пользоваться с учётом этого, то есть не нужно

С чего ты взял что для этого обязательно менять интерфейс?

Для эжтого достаточно почитать описание basic_string.
Если не менять интерфейс то его добрая половина окажется не у дел и будет лишь мозолить глаза.
А вторую половину придется юзать в стиле:

UNICODE_STRING us;
//
std::wstring s;
s.append(us.Buffer, us.Length/sizeof(WCHAR));

что есть большой геморрой и совершенно не юзабельно.
а если добавим в нашу строку перегрузку operator+=(const UNICODE_STRING *us); она уже перестанет соответствовать стандарту.
а имеющийся согласно стандарту operator+=(const wchar_t *psz); будет соблазнять неокрепшие умы писать так:

UNICODE_STRING us;
//
std::wstring s;
s+= us.Buffer;

и получать бсоды от юзеров, а не qa.

Здравствуйте, ononim, Вы писали:
.
O>Если не менять интерфейс то его добрая половина окажется не у дел и будет лишь мозолить глаза.

Так часто смотришь заголовки STL?

O>А вторую половину придется юзать в стиле:
O>

O>UNICODE_STRING us;
O>//
O>std::wstring s;
O>s.append(us.Buffer, us.Length/sizeof(WCHAR));
O>

O>что есть большой геморрой и совершенно не юзабельно.

Ну по крайней мере даже ЭТО проще чем существующий интерфейс к строчкам

Я уже отвечал на этот вопрос, пишется свободная функция:

append(s, us);

Кроме того, хотелось бы взглянуть на use-case. За всё время сущесвования ntl такое не понядобилось, иначе бы наверно добавили.

Скажу даже больше: ради эксперимента делали

s += "\0 ";

без использования strlen, но отказались за ненадобностью, а не из-за расхождений со Стандартом в обработке 0.

Пока все вопросы что ты пишешь — давно пройдённый этап. Во-первых, по Стандарту (новому) basic_string::begin() и data() возвращяет указатель на непрерывный буфер, что решает вопросы с c_str(). Во-вторых, вместо UNICODE_STRING пишется другой класс, позволяющий как минимум делать инициализацию по-человечески:

const_unicode_string cus(L"format c:");

// а вот так можно сконструировать basic_string без strlen, привет Стандарту ;)
std::wstring ws(cus.get_string());

На текущий момент совсем другие проблемы со строками. Из-за поддержки глубокой константности наплодилось много классов: const_unicode_string, unicode_string, в процессе использования стало понятно что это была перестраховка и можно упростить интерфейс. Похоже, можно упростить интерфейс гораздо сильнее и сделать wstring бинарно совместимым с UNICODE_STRING, что избавит от необходимости конверсий, но я когда-то убедил коллегу что так нельзя и теперь он против

Конверсии и в самом деле практически не нужны: UNICODE_STRING требуется только для взяимодействия с АПИ, а там всегда можно (а обычно и нужно) написать обёртки.

O>а если добавим в нашу строку перегрузку operator+=(const UNICODE_STRING *us); она уже перестанет соответствовать стандарту.
O>а имеющийся согласно стандарту operator+=(const wchar_t *psz); будет соблазнять неокрепшие умы писать так:
O>

O>UNICODE_STRING us;
O>//
O>std::wstring s;
O>s+= us.Buffer;
O>

O>и получать бсоды от юзеров, а не qa.

Заметно сильное влияниев С, а в С++ Buffer будет приватным членом

К тому же, ты продемонстировал advanced-технику,

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

s + us;

а свободный operator+() можно реализовать без проблем.

O>>Если не менять интерфейс то его добрая половина окажется не у дел и будет лишь мозолить глаза.
GN>Так часто смотришь заголовки STL?
Откройте для себя Visual Assist.

O>>s.append(us.Buffer, us.Length/sizeof(WCHAR));
O>>что есть большой геморрой и совершенно не юзабельно.
GN>Ну по крайней мере даже ЭТО проще чем существующий интерфейс к строчкам
Нет, не проще.

GN>Я уже отвечал на этот вопрос, пишется свободная функция:
GN>append(s, us);
GN>Кроме того, хотелось бы взглянуть на use-case. За всё время сущесвования ntl такое не понядобилось, иначе бы наверно добавили.
usecase чего? Нуля в строчках? Ну банальнейший юскейс — если вы пишете драйвер фильтр или какой либо перехват (обычное дело в ядре) и ваш драйвер работает с чужими UNICODE_STRING'ами — вы _должны_ поддерживать возможные нули в них, как и возможное отсутствие нулей в их конце.

GN>Скажу даже больше: ради эксперимента делали
GN>s += "\0 ";
GN>без использования strlen, но отказались за ненадобностью, а не из-за расхождений со Стандартом в обработке 0.
Любопытно было бы увидеть как делали. Впрочем это не тот кейс.

GN>Пока все вопросы что ты пишешь — давно пройдённый этап. Во-первых, по Стандарту (новому) basic_string::begin() и data() возвращяет указатель на непрерывный буфер, что решает вопросы с c_str().
Это не имеет отношения к делу.

GN>Во-вторых, вместо UNICODE_STRING пишется другой класс, позволяющий как минимум делать инициализацию по-человечески:
GN>const_unicode_string cus(L"format c:");
const_unicode_string не является частью STL. Собственно я про это и говорил — STL натягивать на ядро глупейшая идея. Идеология стандартных C/RTL и далее идеология С++/STL основана на posix канонах. Ядро винды совершенно иная штука, потому натягивать wstring на UNICODE_STRING и написание кучи вспомогательного геморроя чтобы их скрутить вместе глупейшая идея. А написать специательные хелперы — это конечно дело хорошее и благородное, его многие пытались сделать, мир праху их

GN>// а вот так можно сконструировать basic_string без strlen, привет Стандарту
GN>std::wstring ws(cus.get_string());
GN>На текущий момент совсем другие проблемы со строками. Из-за поддержки глубокой константности наплодилось много классов: const_unicode_string, unicode_string, в процессе использования стало понятно что это была перестраховка и можно упростить интерфейс. Похоже, можно упростить интерфейс гораздо сильнее и сделать wstring бинарно совместимым с UNICODE_STRING, что избавит от необходимости конверсий, но я когда-то убедил коллегу что так нельзя и теперь он против Конверсии и в самом деле практически не нужны: UNICODE_STRING требуется только для взяимодействия с АПИ, а там всегда можно (а обычно и нужно) написать обёртки.
Я вот драйвера всегда делаю так чтобы все что в них было — было по сути хардкорным взаимодействием с апи, а все остальное не относящееся к этому — вытаскиваю в юзермод. И таких проблем воще не встречаю. Стандартные отмазки по поводу перфоманса считаю просто отмазками и ленью разработчиков создать нормальную архитектуру продукта, в которой не было бы узким местом взаимодействие к-мода и ю-мода частей. Впрочем мы это уже обсуждали.

GN>Заметно сильное влияниев С, а в С++ Buffer будет приватным членом
Приватным членом он не будет, так как он часть структуры входящей в состав DDK API. Она _уже_ есть в DDK. Или вы свое DDK заодно напишете? Тогда не забудьте его поддерживать в адекватной форме, а то мс частенько делает изменения знаете ли в своем.

GN>К тому же, ты продемонстировал advanced-технику, неокрепший ум скорее будет использовать
s + us;
а свободный operator+() можно реализовать без проблем.
А за это ваще убивать, ибо лишнее перевыделение памяти.

ЗЫ строка и нулики в ней это лишь одно маленькая деталь. Среди кучи других.

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

O>Нет, не проще.

Аргументы? Строк меньше, нет ручного управления памятью, как минимум поэтому проще.

O>usecase чего?

В этом коде что будет вместо '//'?

UNICODE_STRING us;
//
std::wstring s;
s+= us.Buffer;

что бы я написал как это можно сделать (если будут варианты кроме свобожной функции)

O> Нуля в строчках?

basic_string не имеет проблем с 0, тут вопросов нет.

O> Ну банальнейший юскейс — если вы пишете драйвер фильтр или какой либо перехват (обычное дело в ядре) и ваш драйвер работает с чужими UNICODE_STRING'ами — вы _должны_ поддерживать возможные нули в них, как и возможное отсутствие нулей в их конце.

Только что показывал решение

const_unicode_string cus;//(L"format c:");
// ... берём откудато UNICODE_STRING

// если со строкой из внешнего мира надо как следует поработать, делаем копию. Иначе - <algorithm> не имеет проблем с 0м.
std::wstring ws(cus.get_string());

GN>>Скажу даже больше: ради эксперимента делали
GN>>

s += "\0 ";

без использования strlen, но отказались за ненадобностью, а не из-за расхождений со Стандартом в обработке 0.
O>Любопытно было бы увидеть как делали.

Тут я как бы альтернатив и не знаю:

    template<typename CT>
    basic_string& operator+=(const CT* const& s)
    {
      static_assert((is_same<CT, value_type>::value), "charT must to be value_type");
      return append(s, traits_type::length(s));
    }

    template<size_t Size>
    basic_string& operator+=(const charT(&s)[Size])   { return append(s, Size-1); }

здесь

O>Впрочем это не тот кейс.

Понимаю, потому и попросил показать "тот".

GN>>Пока все вопросы что ты пишешь — давно пройдённый этап. Во-первых, по Стандарту (новому) basic_string::begin() и data() возвращяет указатель на непрерывный буфер, что решает вопросы с c_str().
O>Спасибо, кэп. Но это не имеет отношения к делу.

Чуть выше ты сам пишешь о проблеме с 0.

O>const_unicode_string не является частью STL.

Много что не является, не пойму какие из этого следуют выводы.

При необходимости, строки можно сделать бинарно совместимыми, понимаешь что это значит?

O> Собственно я про это и говорил — STL натягивать на ядро глупейшая идея. Идеология стандартных C/RTL и далее идеология С++/STL основана на posix канонах. Ядро винды совершенно иная штука, потому натягивать wstring на UNICODE_STRING и написание кучи вспомогательного геморроя чтобы их скрутить вместе глупейшая идея.

Беспочвенные обвинения в адрес достаточно большого количества людей. Почитай, к примеру, про C++ threads — есть документ обосновывающий непригодность для них POSIX канонов. А сама Standart Template Library (кстати ошибочно включаешь в неё string & I/O libs) вообще-то к C отношения не имеет абсолютно никакого, скорее к ML языкам.

O> А написать специательные хелперы — это конечно дело хорошее и благородное, его многие пытались сделать, мир праху их

Не рой яму другому. Мы ещё тебя переживём

O>Я вот драйвера всегда делаю так чтобы все что в них было — было по сути хардкорным взаимодействием с апи, а все остальное не относящееся к этому — вытаскиваю в юзермод. И таких проблем воще не встречаю. Стандартные отмазки по поводу перфоманса считаю просто отмазками и ленью разработчиков создать нормальную архитектуру продукта, в которой не было бы узким местом взаимодействие к-мода и ю-мода частей. Впрочем мы это уже обсуждали.

Обсуждали, расскажи это создателям того же IIS.

GN>>Заметно сильное влияниев С, а в С++ Buffer будет приватным членом

O>Приватным членом он не будет, так как он часть структуры входящей в состав DDK API. Она _уже_ есть в DDK.

Про наследование слышал?

O> Или вы свое DDK заодно напишете?

Ну вообще-то с самой первой версии ntl не зависило от WDK

Конечно пока реализовано не в полной мере, но есть и отсутствующие в WDK вещи.

O> Тогда не забудьте его поддерживать в адекватной форме, а то мс частенько делает изменения знаете ли в своем.

Не многим чаще, чем новыя ОС выходит. А изменения мог бы перечислить? Не дополнения, а именно изменения

GN>>К тому же, ты продемонстировал advanced-технику,

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

s + us;

а свободный operator+() можно реализовать без проблем.
O>А за это ваще убивать, ибо лишнее перевыделение памяти.

Ну, нет, это решено в STLPort.

O>ЗЫ строка и нулики в ней это лишь одно маленькая деталь. Среди кучи других.

0-ки не являются проблемой, а других пока не показано.

P.S. это ответ на удалённую версию поста, отличий не заметил.

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

[skip]

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

Здравствуйте, Свиридов Роман, Вы писали:

СР>Не знаю как для вас я для меня С в драйверых это во всяком случае "более" простая отладка при битом стеке

То есть имеются ввиду ошибки 2го (и выше) порядка.

Когда пришлсь писать первый драйвер, я начал с работы с Service Control Manager. Так вот, отработав, приложение падало при выходе из-за того, что забыл (впринципе, умышленно — хотелось быстрее заняться задачей, а не деталями) закрыть хендл от OpenSCManager. Не думал, что это может привести к такому эффекту и потратил часа 2 на поиск бага.

Сам драйвер содержал довольно мало кернел-ориентированного кода, зато слал в разные IOCTL USB устройствам. Необходимо было эксперементировать с последовательностями, то есть менять логику построенную на if/while. Вместе с этим приходилось постоянно помнить про освобождение ресурсов, иначе были лики, невозможность выгрузить драйвер и прочие чудеса, которые приводили к необходимости перегружать виртуалку и терять время. В то время я не понимал С++, а позже узнал что RAII решает эти проблемы в принципе.

СР> и не забываем что данные в памяти тоже могут часто бится соседними драйверами.

Последний "вызванный сторонним компонетном" баг, который мне пришлось править оказался банальным выходом за границы массива в хардкодном С коде, который по сути эмулировал статический полиморфизм реализуемый шаблонами. Не буду утверждать, что С++ исключило бы проблему в принципе, но сделао её более очевидной — ошибка выявилась при рефакторинге.

СР>И для анализа желательно иметь более простую структуру данных и работу с ними.

Хотелось бы примеры, как С++ может усложнить структуру данных, не могу придумать сам, видимо привык

Сам аргумент очень серьёзный, но я сам не смог увидеть преимуществ С в отладке. Вероятно, предвзято к нему отношусь

	От:	Аноним
	Дата:	19.03.10 09:32
	Оценка:

	От:	eagersh
	Дата:	19.03.10 19:21
	Оценка:

От:	Valery A. Boronin	linkedin.com/in/boronin
Дата:	19.03.10 20:16
Оценка:	2 (2)

	От:	eagersh
	Дата:	19.03.10 22:16
	Оценка:

	От:	eagersh
	Дата:	19.03.10 22:30
	Оценка:

	От:	Свиридов Роман
	Дата:	22.03.10 05:56
	Оценка:	1 (1)

	От:	ononim
	Дата:	20.03.10 00:59
	Оценка:	+1

	От:	ononim
	Дата:	20.03.10 10:31
	Оценка:

	От:	ononim
	Дата:	20.03.10 23:24
	Оценка: