The string class does not need rewritten to be a UNICODE_STRING internally. If such a methodology were a good idea, then std::string would be based on the good old c string internally, but it isnât. Instead there is a way to get to and from a c string and thatâs all that is needed. In the kernel thatâs all we needâjust a way to get to and from the handful of string types we need to deal with, UNICODE_STRING being just one of those. A std::wstring would suit the kernel quite nicely. Tossing out all of that tedious RtlInitUnicodeString and such baloney code would be nice.
Sort of a rant, but I hate LIST_ENTRY. I enjoyed it when it and its manipulation macros were state of the art about 30 years ago, but in the new era they are truly horrid when viewed side by side castless std::list code which also snaps into range based for loops and so forth.
And the new c++11 threads are just killerâthey make multi-threading sinfully easy. Would love that in the kernel asap.
There is really no limit to the practicality of the standard libraries in the kernel.
âEmbedded c++â sounds like being confined to hell and I pray I never have to deal with it. Disallowing much of c++ because someone might not use it correctly is ridiculous. Those kinds of useless chumps are not worth restricting everyone elseâs code down to the lowest common denominator over. Kind of like when they decided to make c arrays pass by reference because someone might pass a big one by value. But never mind you can pass a 1 megabyte structure by value, but never a 4 byte array. This embedded c++ sounds like the same dumb thing all over again. Punish the professionals for the sake of the idiots.