Kai Backman wrote:
[...]
On 1/5/07, Stephan Bergmann <[EMAIL PROTECTED]> wrote:
> a very simple result is that developers using pch will break the build
> of those not using pch without being able to notice if new includes are
> required that already reside in the precompiled file. any c/c++ expert
> may be able to construct more elaborate error cases caused by this...
What is worse, there can be cases where both versions build fine but
behave differently (e.g., h1.hxx declares f(Base*), h2.hxx declares
f(Derived*), u.cxx calls f with a Derived* and without pch only sees
h1.hxx but with pch sees both h1.hxx and h2.hxx).
Ok. Setting aside the fact that this will happen without pch
(someone could still include h2.hxx), I don't know C++ well enough to
say if it's even legal C++ or just plain bad?
Anyway, where is such a construct used in OOo and am I being totally
naive with my gut feeling to publicly mock the author? ;-)
I mean, if you know you want to call f(Base*) why no say:
f(static_cast<Base*> derived)
That is all not to the point. I agree that code like that is probably
bad code. I do not know whether OOo currently contains such code. And
of course such bad code can also hit us in scenarios other than pch.
However, what concerns me (a little, at least) is that the pch option
leads to two different instances of OOo that may both compile but behave
differently. One more dimension of variance to take care of. That is all.
-Stephan
Kai
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
