Здравствуйте, 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. Разработчик под драйвера — это больше разработчик под Windows, чем разработчик на C++, который, кстати, более любим линуксоидами. Вероятно, его приложения для user-mode написаны под .NET, так что здесь он встретит знакомые классы.
— .NET хоть и примитивнее, но зато и не так переусложнен, как тот же Boost.
— .NET единообразен, в отличие от связки STL + Boost и даже самого по себе Boost.
— .NET не стандартен. При желании можно разглядеть какие-то стандарты, но о них даже мало кто знает. И, конечно, .NET никогда не покрывал все низкоуровневое API, как это делает STL. Поэтому никто не будет считать мою библиотеку(-и) убогими за то, что я не проделал откровенно ненужной и лишней работы вроде реализации всех методов всех классов .NET. Что хочу — оборачиваю, что не вижу смысла оборачивать — то не оборачиваю.

Здравствуйте, 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. Что хочу — оборачиваю, что не вижу смысла оборачивать — то не оборачиваю.