Re: [boost] static_assert and MWCW8.3

From: Joel de Guzman (joel_at_[hidden])
Date: 2003-12-21 18:31:07

Giovanni Bajo wrote:

> Beman Dawes wrote:
> 
> 
>>Does that mean that there is or is not a bug in MWCW 8.3?
> 
> 
> I didn't find any bug. The old approach used to implement static_assert in MWCW
> has a limitation, which we hit in Spirit. It seems that it was there just as a
> workaround. I can't speak for previous versions, but in 8.3 this is no longer
> needed, and we can use the default implementation.

We did however find some other bugs. One, related to CRTP, was hard to
track. I'll quote Giovanni (with some of my annotations):

<quote>

Hello,

when using CRTP, it's normal to access stuff in the derived class from the base
template. If it's a const member function, you could probably write code like
this (in the base class):

static_cast<const DerivedT&>(*this).func()

This seemingly-innocous code triggers a silent compilation bug in MWCW 8.3,
because it creates a temporary variable of type DerivedT,

<<<Joel: I think this happens when DerivedT has a templated constructor.>>>

copy the contents
there, and calls func() on the temporary. This is of course wrong because
DerivedT is derived from the base class, so it should simply cast down the
reference.

Since this code was used in a pretty basic part of Spirit (namely,
rule_base::parse_main), it was the cause of many of the failures we had with
MWCW. I analyzed this with Joel and the fix we went for is simply to cast
through pointers instead of references:

static_cast<const DerivedT*>(this)->func()

I'm writing this message just to make everyone aware of this issue. A
miscompilation like this is quite hard to debug and trace down, so it could
cause many problems. And CRTP is pretty common. Other compilers may have a
similar problem as well. I quickly checked the Spirit codebase and I didn't
find other cases where this kind of bug could be triggered.

(Let me add that MWCW error reports *SUCK* bigtime. They don't report file/line
information when logging the instantiation stack, making it almost useless.
Plus, if a line of code is causing a flow of template instantiations, any error
that can be caused by these instantiations is reported on the original line of
code. This makes *HARD* to find out what's going on, because you don't know
where the error is in the first place).

</quote>

 > They are running a beta right now for their next release, and I'd like
 > to report it to them if they still have a bug.

I hope that helps.

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net