The use of 8-bit strings for exception messages in the STL is profoundly
offensive. There might be a worse way to do it, but I’m not sure I can
think of one.
There are at least two better ways: (1) each exception has an integer
code, and that is the only representation of an exception. If you want to
turn it into a message, you can have a component that does this, or you
can provide your own with localization (2) each exception is a subclass
(perhaps through several levels) of a base class “exception”. This is how
MFC does it; I can derive CSyntaxException from CException, and
CMissingSemicolon from CSyntaxException, and I can catch a
CSyntaxException and get all my exceptions. Then CSyntaxException has
some virtual methods, such as Report(), that return a string, and I can
modify this to allow for localization. This is vastly more elegant than
the horror I find in STL.
Getting an 8-bit string in the kernel is all-but-useless. And for
container classes, you need to distinguish between
STATUS_INSUFFICIENT_RESOURCES and STATUS_BAD_PARAMETER (such as “index out
of range”) types of cases. So even if C++ exceptions are supported in
the kernel (and what happens if an exception occurs and no suitable
“catch” exists? BSOD?), the STL is not really well-matched to the needs
of “embedded” programming (which drivers strongly resemble).
> My understanding is that C++ exceptions are not supported in the kernel.
This is exact. But the kernel provides facilities almost the same as for
user-mode applications for the C++ support is to be developed. The only
cruel restriction is the stack size available for a kernel executing
entity. Inspite of this the current RTL realisation is highly limited
while handling the nested exceptions. You can see the tests included with
the sources.
> Does it allow the standard libraries to be utilized like vectors and
> streams?
> But the standard libraries will raise exceptions under a variety of
> conditions, and as such, the standard C++ implementations are not viable
> in the kernel.
The current RTL includes almost nothing concerned with the ‘C++ standard
library’ - no STL, no strings, no iostreams, no localisation facilities.
It just provides a compiler- and environment-specific run-time support for
some basic C++ features.
But as far as known the STL’s containers, iterators and algoritms are
widely using exceptions and memory allocations than the STL becomes
probably the most simple part of the standard library to be ported for
using in the kernel (e.g. taken from the STLPort) in conjunction with RTL.
The strings are too, but maybe it worth to be rewritten as internally
based on UNICODE_STRING/ANSI_STRING for the best compatibility with the
kernel interface. And the iostreams and localisation is the most unclear
part of the standard library.
> I think the authors claim support of exceptions for the kernel.
You are exactly right.
But if exceptions are not supported, then this seems to suggest that
exceptions are supported. You seem to have confirmed both “yes” and “no”
in the same email, so I remain confused as to what is true.
joe
> Good thing, BTW. std::vector and std::string are the things which we
> miss in
> the kernel
It seems not to be a good idea to use C++ in the kernel because of at the
time it adds much more problems than resolves. But it’s just very
interesting for some kinds of experimenting -)
> BTW - what about Apple Darwin OS? do they support STL in their IOKit? or
> IOKit is too limited in terms on C++ to have it, so they only have Core
> Foundation there?
The Darwin IOKit uses not a true C++. It uses Embedded C++ - a highly
restricted subset - without exceptions, rtti, only the single inheritance
is allowed, no namespaces, no templates using is allowed, etc. The
standard library is certainly restricted too in view of above
restrictions. And the hand-made rtti-substitution is used in ‘IOKit’.
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer