[boost] [Fwd: Fw: [Boost-users] Re: Followup to KCC compile error]

From: Geoff Wedig (wedig_at_[hidden])
Date: 2005-04-13 11:07:54

Hi, I'm new to the list, invited by Steve Gross in our pusuit of this 
KCC error.  I did some of the investigation Steve mentioned and David 
Abrahams commented on in his post on Saturday, April 9.  While I wasn't 
on the list then, Steve helpfully forwarded the response to me, so I can 
clarify, since I'm afraid some of what I wrote wasn't very clear, and 
was actually incorrect in a few cases.  Hopefully this will help to make 
the issue a little easier to understand.  I'm pretty sure, at this 
point, that it isn't really solvable, but I'd love to hear any ideas.

----- Original Message -----
From: "David Abrahams" <dave_at_[hidden]>
To: <boost-users_at_[hidden]>
Sent: Saturday, April 09, 2005 6:34 PM
Subject: [Boost-users] Re: Followup to KCC compile error

"Stephen Gross" <sgross_at_[hidden]> writes:
 >
 > > To review:
 > >
 > >> When including "boost/iterator/indirect_iterator.hpp", I get:
 > >>
 > >> 
"/usr/local/sagedev/apis/include/boost_1_32_0/boost/detail/is_incrementable.hpp",
 > >> line 56: error:
 > >>
 > >> expression must have arithmetic, enum, or pointer type
 > >>
 > >> BOOST_STATIC_CONSTANT(
 > >> ^
 > >
 > > Some new thoughts upon investigation:
 > >
 > > It is not in the BOOST_STATIC_CAST.
 >
 > There is no such symbol in use.

This is my mistake.  I meant the BOOST_STATIC_CONSTANT.

 >
 > > Doing manual compiler preprocessing has resulted in the following
 > > code, which is what the compiler is complaining about:
 > >
 > >   template <class T>
 > >   struct impl
 > >   {
 > >       static typename remove_cv<T>::type& x;
 > >
 > >       static const bool value = 
sizeof(is_incrementable_::check(++x,0)) ==
 > > 1;
 >
 >
 > If that's the code it generated, your preprocessor is seriously
 > broken.
 >
 > It should be generating an extra set of parens around "++x,0".

Again, since I was doing this by hand, just to see exactly what was 
going on, this was also my mistake.  You are right, there should be 
additional parentheses around that code.  The preprocessor isn't broken, 
just my dodgy methods of replicating what it does. ;)

 >
 > >   };
 > >
 > > The problem is the ++x, not the static cast.
 >
 > There's no static cast.  How do you know the problem isn't in the
 > use of the comma operator?

Because I tried using various workarounds, including the one for boost 
comma that ignores the second term (which you suggest below).  It 
produces identical errors to the non-modified version.  It is definitely 
in the ++ operation on x.

 >
 > > The problem seems to be a question of that x variable.
 > >
 > > If I replace the typename of x with, say int&, it works with one
 > > additional modification (see below), and if I replace it with a
 > > non-incrementable object, say 'foo', that also works.  My theory was it
 > > might be in the remove_cv, but replacing the type with T& does not
 > > work.  We still get the 'must be of XXX' type message despite T being
 > > known to be a type.
 >
 > I suggest you find the line in is_incrementable.hpp that says:
 >
 > # if BOOST_WORKAROUND(__MWERKS__, BOOST_TESTED_AT(0x3202)) \
 >
 > and change it to:
 >
 > # if 1 || BOOST_WORKAROUND(__MWERKS__, BOOST_TESTED_AT(0x3202)) \
 >
 > > So, it would seem to be something about the templates.
 >
 > Well, _that_ was sort of obvious from the beginning ;-)

What I meant was a bit different. ;)

I meant that the problem seems to be in an incorrect use of templates by 
KCC.  The problem seems to be that the static const statement that is 
generated works, if the type of x is known.  If the code is modified 
something like:

   template <class T>
   struct impl
   {
       static DUMMY& x;

       BOOST_STATIC_CONSTANT(
           bool
         , value = sizeof(is_incrementable_::check(BOOST_comma(++x,0))) == 1
       );
   };

where DUMMY is any known class, incrementable or not (I tried, ints, 
strings, several user defined classes), the code doesn't produce these 
errors.  Once that DUMMY is changed to T& (much less the 
remove_cv<T>::type&), then the code produces the error.  It is only when 
x is of a templatized type that the function evaluates incorrectly.  I'm 
guessing htis is at parse time, since it seems to not care if the code 
is used or not.  If it left this until instantiation, then it could 
evaluate without problem, as the type of x would be known.  It's only 
because it's trying to evaluate some of this too early that we have 
these problems.  Or at least, that's my understanding.

Incidentally, 'fixing' this by labelling everything as incrementable 
(setting the bool to always be true) doesn't work either (not that I 
expected it would).  The compiler crashes.  Somehow, I doubt it is 
boost's fault in this case. ;)

So, I hope that clarifies matters.  We're still looking for workarounds, 
if anyone's got any ideas.