
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 16 Oct 2014, at 16:43, Adriaan van Os wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Monaco; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="font-family: monospace; ">Jonas Maebe wrote:<br><br><blockquote type="cite">No, it won't:<br></blockquote><blockquote type="cite">1) if the external code expects it to be "out" and you declare it as "var": the caller will decrease the reference count and the ppEvent that you get will have as initial value "nil". You can just assign to it like normal.<br></blockquote><blockquote type="cite">2) if the external code expects it to be "var" and you declare it as "out": the caller will not do anything and hence the ppEvent will not be nil. However, assignments to the "out" parameter still cause its reference count to be decreased. After all, you can assign multiple times to an "out" parameter, so the compiler cannot assume it's already nil. The only problem that could happen here is if you would explicitly write your code in a way that behaves differently depending on whether the initial value is nil (e.g., assigning something to it only in one branch of an if-statement, and then later checking whether it's "still" nil to determine whether you have to assign something else to it).<br></blockquote><br>Sorry, but the above explanation flabberghasts me.<br></span></span></blockquote></div><br><div>I explained the opposite scenario as you: calling a method implemented in Pascal from external Windows code (with mismatched var/out modifiers). Rereading your message, that's indeed not what you were talking about.</div><div><br></div><div>In general, using wrong/mismatched modifiers when importing routines virtually always causes problems though (and often much worse than just a memory leak), there's nothing special about reference counted types here.</div><div><br></div><div><br></div><div>Jonas</div></body></html>