Kai Backman wrote:
Ok, my bad Stephan. On second reading my first reply comes across as
confrontational, I was just making sure this isn't something we -need-
to do. I had a bit more time to think about this:
No problem.
- We can write a script that detects symbol definitions that change
header files on a global scale. Assuming we can identify these cases,
is it OK to remove/rewrite them from the codebase. Ie. do we ever
legitimately need to do the following (that can't be replaced by
constants and templates):
sample1.cxx:
#define FOO
#include "foo.hxx" // Now foo.hxx behaves in one way
sample2.cxx:
#define BAR
#include "foo.hxx // Now foo.hxx behaves differently
The boost preproc stuff comes to mind. I think we use that somewhere,
maybe dbo knows more.
- We can also run something similar to LXR and try to identify
potential cases of the problem Stephan shows. Is writing this tool
worth the trouble?
Probably not...
Any other problematic cases?
Hard to tell up front with something as messy as C/C++ plus preproc.
Time will tell...
-Stephan
Kai
On 1/16/07, Stephan Bergmann <[EMAIL PROTECTED]> wrote:
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
