Stephan writes: > I vaguely remember having discussed this before with Daniel Bölzle, > but neither of us can remember whether there were any serious problems > with it. > Well, will of course try this on a full build ;-)
> Whether or not the constructor should be explicit might be a > question of style, however. > Don't think so. To match behaviour of plain ptrs (for the implicit conversion), the copy constructor needs to be non-explicit. After all, having that taking place automatically is my whole point here. Frank writes: > As much as I appreciate convenience while writing code, I never felt > too bother with using the .get()-workaround. > Granted. My point was that the workaround is non-obvious, to the best of my knowledge nowhere documented, and it breaks the abstraction of uno::Reference being a ptr-like object. > On the other hand, I somewhat fear the zillion lines of output > probably emitted by the compiler when it comes to an assigment "xFoo > = xBar" where XBar is *not* a base class of XFoo, but the compiler > nonetheless tries to match the several hundred potential assignment > instantiations. Which makes me reluctant to this change ... > Well, that's only 'your' Windows compiler stupidness - and it does that nevertheless, with that stdexcept spillage... ;-) No, seriously, in this case there's no trying-out of template instantiations. The types of xFoo and xBar completely and sufficiently determine the member template instantiation - the place that fails is the ptr assignment inside that template. So, if there are no hard objections, I'd implement the change, do a full build on my favorite platform, and report back with a complete patch here. Cheers, -- Thorsten If you're not failing some of the time, you're not trying hard enough. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
