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@boost-consulting.com> To: <boost-users@lists.boost.org> Sent: Saturday, April 09, 2005 6:34 PM Subject: [Boost-users] Re: Followup to KCC compile error "Stephen Gross" <sgross@darwin.epbi.cwru.edu> 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.