SAL Annotations are definitely not used to generate code; I double-checked by
creating a function and passed nullptr to it and it happily (!) crashed. Also
no warnings were thrown nor compiler errors emitted unless Code Analysis was
turned on – and then, only a warning.
For what it’s worth, default parameters are not part of a method or function’s
type. Default parameters are instructions for the call site and not the
method/function. From an academic point of view, this has specific implications
in the case of an ABC because overriding only works on types and, as mentioned,
a default parameter is not part of that. This is particularly relevant for pure
virtual functions because it means overriding does not carry with it the
default parameters. See section 8.3.6.10 of C++11 standard.
From a practical point of view, the impact is that all future overrides have to
carry the correct default parameter value and, in some cases, can even fail to
provide one and the compiler of that class will be ok with that. The default
parameter of the implementing class is chosen over all other possibilities. The
short of it is that there’s no way to validate/verify that a correct default
parameter is chosen nor verify which specific default parameter is chosen in
client code. It won’t cause any issues for now and is probably fine but, if,
say, a 3rd party were to implement the interface then they will definitely have
some weirdness. Long-term, I think the technical term for this is “brittle” –
especially when someone implements the interface in such a way that they get a
“wrong number of arguments” error on an interface they believe they’ve
implemented correctly as most people aren’t familiar with this portion of C++.
There’s a CERT advisory against this specific practice discussed here:
https://www.securecoding.cert.org/confluence/display/cplusplus/OOP04-CPP.+Prefer+not+to+give+virtual+functions+default+argument+initializers
Just some thoughts I figured I would throw out for this :-) Hopefully in the
not-too-distant future I’ll be able to contribute to WiX, but for now all I can
do is lurk on mailing lists.
(had to trim the history to try to get under 40KiB)
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Thursday, February 6, 2014 4:30 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Self update bundles, the detect issue.
My understanding is that the SAL annotation is just for static analysis. The
default argument (“= NULL”) is the important part. I just wasn’t sure it’d work
in the interface but knowing that it does, I guess I’m not completely surprised.
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Thursday, February 6, 2014 9:25 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Self update bundles, the detect issue.
I’m in meetings today so I can’t be in the online meeting. I need to do some
more testing to verify the change, but I don’t think per say it was breaking
since I had the HWND as __in_opt. In fact, even without the interface change
(assigning = 0) it still compiles. I think that’s the wonderful MSVC compiler
doing what it’s told.
(From http://msdn.microsoft.com/en-us/library/ms235402(v=vs.80).aspx)
_opt
The pointer to the buffer might be NULL. It will be checked before being
dereferenced.
NOTICE: This electronic mail message and any files transmitted with it are
intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged
information.
Any unauthorized review, use, printing, saving, copying, disclosure or
distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
