Closed ariccio closed 9 years ago
The Modern C++ language projection is unlike COM in that there’s no void \ pointers to initialize, no HRESULTs to check, etc. SAL is less useful in this case.
The Modern libraries work with the Visual C++ 2015 compiler as well as the latest version of Clang. Visual C++ 2013 is not supported.
SAL is less useful in this case.
Yes, slightly less useful. However, I can easily find parts of the API/projection - well, I think its part of the API/projection - that could benefit.
StringReference( wchar_t const* const value, unsigned length )
for example, uses the tricky-looking WindowsCreateStringReference
function. I don't have the declaration in front of me, but I expect that the first two parameters are well annotated.
Similarly: String(wchar_t const * value, unsigned const length)
and everything that accepts a C-style null-terminated string.
Yes some of those functions do provide SAL annotations but wrappers are provided by the base library to shield you from calling them directly. Classes like StringReference are meant for internal use and may eventually be pushed into an “impl” namespace. I agree that there are definitely a handful of places where SAL could help but overall it has little value in this case. My preference is to push more of the “dangerous” APIs into an internal namespace and just provide a “safe” library to the app developer with as few pointers as possible.
I've noticed (at least, in part of the code) that there's very little SAL in
modern
.... what's up with that?Especially in
COM
-related code, I never cease to be amazed by how powerful SAL is, and I believe that it's indescribably valuable for any library code!Side note: Does
modern
support VS2013? I haven't yet got my hands on 2015, and'd happily add the SAL myself.