В то же время, если посмотреть какие списки распространены в разных платформах user-mode, то увидим, что кроме linked есть и array-based, и вторые даже более распространены, чем первые. Пример? Да хоть std::vector из стандартного C++, который используют много чаще, чем std::list (двусвязный список).
И думается, что это не только из-за отсутствия `operator []`, который можно было бы легко добавить самими же авторами стандарта
Как вы считаете — стоит ли написать для драйверов свой array-based list (точнее, адаптировать под NT какую-то уже имеющуюся реализацию)?
Что у них будет с быстродействием? Будет ли выигрыш в каких-то случаях (см. предыдущий вопрос про списки с 2 разными ситуациями)
Здравствуйте, LimyKurn, Вы писали:
LK>Как вы считаете — стоит ли написать для драйверов свой array-based list (точнее, адаптировать под NT какую-то уже имеющуюся реализацию)? LK>Что у них будет с быстродействием? Будет ли выигрыш в каких-то случаях (см. предыдущий вопрос про списки с 2 разными ситуациями)
Здравствуйте, -prus-, Вы писали:
P>Здравствуйте, LimyKurn, Вы писали:
LK>>Как вы считаете — стоит ли написать для драйверов свой array-based list (точнее, адаптировать под NT какую-то уже имеющуюся реализацию)? LK>>Что у них будет с быстродействием? Будет ли выигрыш в каких-то случаях (см. предыдущий вопрос про списки с 2 разными ситуациями)
P>По моему, что-то похожее уже мелькало вроде. C++ RTL for NT kernel-mode drivers P>Сам не смотрел. Исходники тут.
Это уже другой вопрос получается.
И звучит он так: "стоит ли в NT тащить стороннюю библиотеку, которая реализует STL?"
При этом пока даже неизвестно, есть ли там собственно хоть какой-нибудь array-based list
В целом про такие библиотеки могу сказать следующее.
Они тупо копируют STL, а он не нужен. И это я говорю как человек, который ЗНАЕТ плюсы, пишет на них много и тщательно. Где можно обойти эту STL через Boost, Qt, fc, там ее обходят. А на создание фундамента, достаточного для переноса хотя бы Boost в NT, таких библиотек уже вряд ли хватит. Причем, нужно еще определиться, что из Boost нужно в NT, а что нет. А для этого надо очень плотно крутиться в области и очень многое в ней увидеть. Между тем, вряд ли многие поддержат эту затею финансово
Вывод: если и писать библиотеку утилит, то пока она маленькая, не стоит заботиться тем, что она ни с чем не совместима. Гораздо важнее, чтобы она была нужна. Если при этом можно без особого труда обеспечить еще и совместимость — то делаем, а иначе — нет.
По структуре тут есть вообще такая идея: делать классы не в стиле STL, а, внезапно, в стиле .NET.
На первый взгляд — безумие — зачем? Но ответ приходит быстро: если STL и NT связаны через C++, то .NET и NT связаны через Windows. Именно .NET есть основной инструментарий под Windows, тогда как C++ больше удел линуксоидов. К тому же, хоть .NET и более примитивен, но он и более прогрессивен, чем STL уж точно... Наконец, если выбирать между Windows и C++, то разработчик драйверов NT — это скорее человек со стажем в первом, чем втором... Получается, что идея со стилем .NET с какой-то стороны выглядит даже более здравой.
Но в данном случае меня больше интересует, нет ли там все-таки конкретно array-based list'а, и если есть, то не годен ли он — а взять его к себе можно и отдельно от всего, если он того стоит. Все же, не нужно допускать того, чтобы вы создавали свое тогда, когда намного проще задействовать уже готовое.
Здравствуйте, LimyKurn, Вы писали:
LK>то увидим, что там только связные списки.
Такое положение дел диктует модель памяти. Операции выделение/освобождения структуры отделены от операций работы со списком.
Это актуально при работе на разных irql, позволяет мешать с одном и том-же списке динамически и статически выделяемую память и т.д. В минусах больший объем кода, большая сложность.
LK>В то же время, если посмотреть какие списки распространены в разных платформах user-mode, то увидим, что кроме linked есть и array-based, и вторые даже более распространены, чем первые. Пример? Да хоть std::vector из стандартного C++, который используют много чаще, чем std::list (двусвязный список).
Последнее время в user-mode больше распространен GC))
LK>И думается, что это не только из-за отсутствия `operator []`, который можно было бы легко добавить самими же авторами стандарта LK>Как вы считаете — стоит ли написать для драйверов свой array-based list (точнее, адаптировать под NT какую-то уже имеющуюся реализацию)?
Возможность писать драйверы на C++, с перегрузкой операторов и прочим блек-джеком никто не отменял. Не думаю, что адаптация актуальна.
LK>Что у них будет с быстродействием? Будет ли выигрыш в каких-то случаях (см. предыдущий вопрос про списки с 2 разными ситуациями)
Хочу обратить твоё внимание, что списки в ядрах отличаются от std::list по внутреннему устройству. Они сделаны так, чтобы любые операции исключали динамическую работу с памятью. Поэтому сложно представить эквивалентные условия для оценки производительности.
Re[2]: Array-based lists нужны ли на NT или только linked?
Здравствуйте, m2l, Вы писали:
m2l>Возможность писать драйверы на C++, с перегрузкой операторов и прочим блек-джеком никто не отменял. Не думаю, что адаптация актуальна.
Но там же нет STL. Нет того же std::vector.
Более того, я всерьез задаюсь вопросом — а нужна ли она там, или там нужна иная система библиотеки с утилитами.
Дело в том, что чистый STL малополезен, никто не использует его в чистом виде, а предпочитают Boost, Qt, fc и др.; но для того, чтобы их утащить в драйвера, нужна полноценная реализация STL. Городить такой огород — это совсем не задача энтузиастов.
Между тем, у меня есть иная идея: утилиты для NT — писать, собирая их из всяких адаптаций (хотя, конечно, только по мере необходимости), но не пытаться сделать STL, а строить структуру в стиле библиотеки .NET: в названиях классов, методов, самом разбиении на классы стараться придерживаться .NET.
С одной стороны, это выглядит безумием: какое отношение .NET имеет к C/C++, на которых пишутся драйвера NT?
С другой стороны, ряд преимуществ:
— Если STL связан с NT через C++, то .NET связан с NT через Windows. Разработчик под NT — это больше разработчик под Windows, чем разработчик на C++, который, кстати, более любим линуксоидами, чем разработчиками под Windows. Вполне вероятно, что его приложения для user-mode написаны под .NET, так что здесь он встретит знакомые классы.
— .NET хоть и примитивнее, но зато и не так переусложнен, как тот же Boost.
— .NET единообразен, в отличие от связки STL + Boost и даже самого по себе Boost.
— .NET не стандартен. При желании можно разглядеть какие-то стандарты, но о них даже мало кто знает. И, конечно, .NET никогда не покрывал все низкоуровневое API, как это делает STL. Поэтому никто не будет считать мою библиотеку(-и) убогими за то, что я не проделал откровенно ненужной и лишней работы вроде реализации всех методов всех классов .NET. Что хочу — оборачиваю, что считаю и так достаточно простым — то предлагаю юзать непосредственно и сам так делаю.
Здравствуйте, LimyKurn, Вы писали:
LK>Но там же нет STL. Нет того же std::vector.
Чем вам не нравится из ядра прокинуть данные наверх, обработать там при помощи boost, stl, algorithms и тп, и потом вернуть результат обратно?
Также в ядре есть и свои реализации, например, AVL Tree: RtlInitializeGenericTableAvl. Можно найти реализации HashTable ну и тп.
И что это за такой загадочный array-based list для ядра, о котором вы говорите? Можно подробнее?
С уважением,
Евгений
Re[4]: Array-based lists нужны ли на NT или только linked?
Здравствуйте, -prus-, Вы писали:
P>Чем вам не нравится из ядра прокинуть данные наверх, обработать там при помощи boost, stl, algorithms и тп, и потом вернуть результат обратно?
okman говорил, что в моем конкретном случае делать user-mode-сервис не нужно. Хотя уже предлагали несколько раз. Но я не сделал.
А если серьезно, то просто узнайте весь масштаб применения одного только vector в проектах на C++ в user-mode, и вы оцените, насколько реально или нереально кидать данные туда-сюда каждый раз, где хочется применить vector.
Впрочем, я сомневаюсь, что вы захотите что-то там узнавать, поэтому попытаюсь просто сказать словами. Динамических массивов в современных проектах на C++ не бывает. Бывает только вектор. Не только "динамический массив", но и "коллекция" вообще — почти синоним слова "вектор".
P>Также в ядре есть и свои реализации, например, AVL Tree: RtlInitializeGenericTableAvl
Спасибо, посмотрю.
P> Можно найти реализации HashTable ну и тп.
Этот видел. Там еще LinkedList рядом лежит — его посмотрел — не впечатлил. Потокобезопасности нет нигде.
P>И что это за такой загадочный array-based list для ядра, о котором вы говорите? Можно подробнее?
Его пока нету. Есть только сама идея того, что нужен array-list, а не только связный.
Array-list — это список, в котором лежит динамический массив, и именно он непосредственно хранит элементы. Связи — отсутствуют, это и отличает его от связного списка.
Array-list используется гораздо шире, чем связные списки. В user-mode можно взять любой язык программирования, посмотреть какой список там используется шире всего, и наверняка он будет array-listом, а не связным. Тот же вектор — это array-list.
Правда, я не знаю, как, собственно, его реализовать. В частности, как там делают само добавление элементов. Думаю, что выделяют новый буфер, копируют в него старый, добавляют элемент в конец, а старый буфер очищают.
Re[5]: Array-based lists нужны ли на NT или только linked?
Здравствуйте, LimyKurn, Вы писали:
LK>А если серьезно, то просто узнайте весь масштаб применения одного только vector в проектах на C++ в user-mode, и вы оцените, насколько реально или нереально кидать данные туда-сюда каждый раз, где хочется применить vector. LK>Впрочем, я сомневаюсь, что вы захотите что-то там узнавать, поэтому попытаюсь просто сказать словами. Динамических массивов в современных проектах на C++ не бывает. Бывает только вектор. Не только "динамический массив", но и "коллекция" вообще — почти синоним слова "вектор".
Что такое С++ я в курсе. И я не спорю. Может я просто пока не сталкивался с такой задачей, где бы это можно было оценить прям явно. Тогда еще стоить подумать подтянуть в ядро умные указатели, например, чтобы не париться об утечках памяти или boost::multi_index, flat_map и тп. Но имхо есть системное программирование со своей спецификой, архитектурой и нюансами (возьмем KernelMode), где есть все необходимое для разработчика на каждом уровне (оборудование, файловая система, сетевой стек, подсистема процессов и потоков, реестр, память и тд и тп), а есть прикладное направление С++ со всякими очень полезными контейнерами, алгоритмами, STL, Boost и свистелками/перделками, которые уже годами отлажены сообществом для своих нужд, которые в KernelMode могут быть оверхедом по памяти, например, размеру бинарного модуля и даже пагубно сказаться на производительности. Не?
LK>Его пока нету. Есть только сама идея того, что нужен array-list, а не только связный.
Идея — это всегда хорошо
С уважением,
Евгений
Re[6]: Array-based lists нужны ли на NT или только linked?
Здравствуйте, -prus-, Вы писали:
P>подтянуть в ядро умные указатели, например, чтобы не париться об утечках памяти
Даже умные почти не применяются в прикладном C++. Только ссылки.
P> или boost::multi_index, flat_map и тп.
Интуитивно: мапа — да, bmi — нет.
bmi — это "засри консоль непонятными ошибками НАГЛУХО."
И только потом — самый гибкий из контейнеров и прочие плюшки.
Думаю, что если бы было что-то поадекватнее, поновее, то часть бы народу перешло на него.
P> оборудование, файловая система, сетевой стек, подсистема процессов и потоков, реестр, память и тд и тп
Для файловой системы, реестра и потоков тоже можно писать хелперы. К примеру, тот же ZwOpenFile может быть во многих случаях горсткой функций с куда более лаконичными параметрами. Правда, я предлагаю делать это лишь местами, а не тупо ставить цель портировать что-то высокоуровневое под NT, делая лишнюю работу по созданию реально лишних функций и занимая ими место на диске и в памяти.
P> могут быть оверхедом по памяти, например, размеру бинарного модуля и даже пагубно сказаться на производительности. Не?
Размер бинарного модуля — не. Память — не. Это все-таки не микроконтроллеры. К тому же, куда больше дров (каламбур) способна наломать утечка памяти при кривом использовании чего-л., чем нормально реализованная обертка, которая хоть и весит сколько-то сама, но зато снижает риск ошибиться при использовании
Производительность — да. Но насколько знаю, у linked list она в чем-то лучше array list — а в чем-то то и хуже.
Здравствуйте, LimyKurn, Вы писали:
LK>Дело в том, что чистый STL малополезен, никто не использует его в чистом виде, а предпочитают Boost, Qt, fc и др.; но для того, чтобы их утащить в драйвера, нужна полноценная реализация STL. Городить такой огород — это совсем не задача энтузиастов.
Он полезен контейнерами, которые тебе и понадобились. И наличие упомянутых библиотек не отменяет std:: в коде, а дополняет отсутствующий функционал.
LK>Между тем, у меня есть иная идея: утилиты для NT — писать, собирая их из всяких адаптаций (хотя, конечно, только по мере необходимости), но не пытаться сделать STL, а строить структуру в стиле библиотеки .NET: в названиях классов, методов, самом разбиении на классы стараться придерживаться .NET.
Контекст твоих вопросов и раздел форума подразумевает драйверы или штуки вроде chdisk-а, который при загрузке. LK>С одной стороны, это выглядит безумием: какое отношение .NET имеет к C/C++, на которых пишутся драйвера NT? LK>С другой стороны, ряд преимуществ: LK>- Если STL связан с NT через C++, то .NET связан с NT через Windows. Разработчик под NT — это больше разработчик под Windows, чем разработчик на C++, который, кстати, более любим линуксоидами, чем разработчиками под Windows. Вполне вероятно, что его приложения для user-mode написаны под .NET, так что здесь он встретит знакомые классы.
Исходники открыты, можно и весь dotnet внутрь ядра засунуть. CL будет компилироваться и запускаться прямо в ring 0, с доступом почти ко всему богатству стандартной библиотеки.
Только преимущества не перекрывают недостатков. LK>- .NET хоть и примитивнее, но зато и не так переусложнен, как тот же Boost.
Разница в рефлексии, из-за неё воссоздать часть особенностей стандартной библиотеки C# на C++ нельзя. LK>- .NET единообразен, в отличие от связки STL + Boost и даже самого по себе Boost.
Не ясно по какому критерию оценено единообразие. И как он видоизменится при переходе в ядро. LK>- .NET не стандартен. При желании можно разглядеть какие-то стандарты, но о них даже мало кто знает. И, конечно, .NET никогда не покрывал все низкоуровневое API, как это делает STL. Поэтому никто не будет считать мою библиотеку(-и) убогими за то, что я не проделал откровенно ненужной и лишней работы вроде реализации всех методов всех классов .NET. Что хочу — оборачиваю, что считаю и так достаточно простым — то предлагаю юзать непосредственно и сам так делаю.
Это плохой аргумент. Если библиотека будет упрощать работу, то никого не будет волновать её корреляция с какими-либо стандартами.
ЗЫ. Я так вижу ты плотно нацелился повелосипедить. Отговаривать не буду, но предметную область в которой хочешь работать всё-же изучи.
Re[4]: Array-based lists нужны ли на NT или только linked?
Здравствуйте, m2l, Вы писали:
m2l>Контекст твоих вопросов и раздел форума подразумевает драйверы или штуки вроде chdisk-а, который при загрузке.
Под утилитами имелась в виду библиотека для драйверов NT. В этом контексте, утилы и хелперы — это и есть библиотека, только в зачаточном состоянии. А когда все разовьется и объединится, получится фреймворк.
m2l>Если библиотека будет упрощать работу, то никого не будет волновать её корреляция с какими-либо стандартами.
Это совсем не так. В данном конкретном случае — не совсем так. Но "не совсем" только потому, что тут низкоуровневые разработчики и разработчики под Windows. Думается, что для этих двух групп не столь характерна любовь к порядку. И особенно — для вторых.
m2l>ЗЫ. Я так вижу ты плотно нацелился повелосипедить.
Нет. Создание фреймворка (крупной библиотеки) для NT — это не велосипед, потому что здесь нет ни одного хоть немножко общепринятого аналога.
Я еще могу согласиться про списки — для них, действительно, если и нужно что-то, то лишь недостающие функции для стандартных списков. Но, опять же, эти функции стоит написать. А во многих случаях именно надо обернуть конкретную часть функций по какой-то теме, если не все.
Это именно уникальный проект... только на любой проект надо иметь хоть немного сил, и проект делать сообразно им.
