> > I am compiling Xapian in a non-GNU/GCC environment
> (windows, that is),
> > and run into one minor problem.
>
> What's the compiler?
Compiler is from Microsoft Visual Studio 2003.
> > The problematic line of code is in backends\quartz\btree.h
> >
> > 549: static const string::size_type max_key_len =
> BTREE_MAX_KEY_LEN;
> >
> > Seems that the gnu compiler is happy with that, although I
> doubt that
> > this is legal C++ syntax.
>
> I'm not familiar enough with the standard to say, but it's
> also accepted by Sun's, SGI's, and HP's compilers.
I checked with my Stoustrup, and after a bit of guessing I found the
grammar rule for that thing. So it is valid C++ syntax, but Microsofts
compiler doesn't handle this correct. I am still wondering how this
should work anyway. When btree.h is included several times, how does the
compiler at compile-time know that it should create the one instance of
max_key_len that is needed? There must be some magic involved at linking
time that the Microsoft compiler does not do....
> > This line of code causes a linker error because
> Btree:max_key_len gets
> > created multiple times. Proposed
> > solution:
> >
> > backends\quartz\btree.h:
> > 549: static const string::size_type max_key_len;
> >
> > backends\quartz\btree.cc:
> > 91 : const string::size_type Btree::max_key_len =
> BTREE_MAX_KEY_LEN;
>
> I think just dropping the "static" from btree.h would be
> preferable if that works.
Well, that would work, too. But in that case things would have to be
initialized in the constructor:
Btree {
....
public:
Btree(...)
: max_key_len(BTREE_MAX_KEY_LEN)
{
}
private:
string::size_type Btree::max_key_len;
};
Dunno if that looks better, though. The advantage of the first proposed
solution is that max_key_len gets only initialized once at program
startup whereas in the second case it must be initialized for each Btree
class instance. So, from a performance point I would go for the first
solution.
> > The rest of those parts that I need compile with lots of
> warnings, but
> > only because some typedefs are a bit different on the windows side.
>
> If we can fix warnings without making the code worse, I'm all for it.
> Unfortunately some compilers have a few rather stupid
> warnings which you can't sensible avoid, except by disabling them.
I am going to try 0.8.5, today if possible, and will compile a list to
discuss about this further.
Regards,
Bernhard