Frank Schönheit - Sun Microsystems Germany wrote:
Hi Stephan,
So, not sure if we are talking about premature optimization or premature
pessimization. For what it's worth, I used this NULL-check issue quite
often and never worried about performance...
Admittedly, I don't have data to backup my performance assumption. Even
worse, I don't even think that I could come up with a scenario in
existing code where I believe there currently is a performance issue.
It's just that UNO_QUERY_THROW is a very good construct (IMO) for
assuring the contracts, but this small difference to the "set/if.is()"
pattern leaves some small rest of inconvenience for me.
I'm not sure I understand your last sentence. "UNO_QUERY_THROW" does
more than "set/if.is()" (namely, doing a queryInterface call), and this
extra activity is inconvenient for you? In how far is it inconvenient?
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
