when was const-behavior fixed in GCC (or was it never broken)? From posts here in GameDev awhile back, I had thought that this was legal C++:

struct foo
{
    int bar;
    void call( void ) const { ++bar; }
};

Apparently this is not the case (as I found out in my line-number incrementing function, which needs to be const for boost to bind to it without pages of compile errors). I believe it may have compiled on G++ 3.3.1, but after automatic updates on my debian box, and an accidental update on my cygwin box messing with the freetype installation (3.3.3 on my windows machine, 3.3.4 on my debain box), this generates an error! I'd like to make sure that I'm not hallucinating or something, so, can someone tell me what version of G++ this code became non-compiling? If it was recent, for those who are curious as to the solution to this dilemma, simply add the keyword mutable to bar:

mutable int bar;

(however, since boost passes around by value (as I frogot when designing this code), I need to use static or a reference anyways) I found this out in a GCC 3.5 bugreport I found on [google], where the keyword was only being applied to the first variable in a multi-decleration line ala:

mutable int foo,bar; //mutable only applied to foo although it should be applied to both

(That might be fixable via typedef or typeof(mutable int) - I didn't read too far into it after I found my solution). [Edited by - MaulingMonkey on October 24, 2004 10:00:18 AM]

Quote:Original post by MaulingMonkey
I believe it may have compiled on G++ 3.3.1, but after automatic updates on my debian box, and an accidental update on my cygwin box messing with the freetype installation (3.3.3 on my windows machine, 3.3.4 on my debain box), this generates an error! I'd like to make sure that I'm not hallucinating or something, so, can someone tell me what version of G++ this code became non-compiling?

I can't tell you when it was fixed or if it has been broken at all, but I do remember it working (as in that code not compiling) on 3.2... It's been a while since I used anything older than that so I can't remember the older versions.

I don't know either, but gcc has very specific changelogs that tell you exactly what aspects of all the different compilers etc were changed, and how. I don't know about 3.5.x, but I know 3.4.x introduced a lot of ISO-compliance changes that break a lot of old code.

How is that valid? You're method is clearly changing a data member of the struct while claiming to be const.

Quote:Original post by outRider
How is that valid? You're method is clearly changing a data member of the struct while claiming to be const.

Quote:Original post by MaulingMonkey
I had thought that this was legal C++:
...
Apparently this is not the case

I think I had read about this in coding practice info probably predating whenever GCC fixed this behavior or added the mutable keyword. The const keyword when applied to functions allows them to be called when you have only a const handle to an object - and there are instances when there's an internal member you wish to modify even in a const sense (case in point: reference counting on COW (copy on write) strings) that do not (or at least should not) modify the "external" image.

Quote:Original post by Anonymous Poster
but I do remember it working (as in that code not compiling) on 3.2...

Well, apparently I've started hallucinating then. Odd, I havn't been taking any hallogens... nor have I been sniffing paint or glue or anything like that... XD

Quote:Original post by hplus0603
Making "bar" mutable is the easiest solution.

For my example yes. Unfortunately I had frogoten that boost::spirit passes functors around by value (which I was reminded of whien my mutable line number stayed the same - and then I accidentally put logging information into the dtor - which of course got called around 50 times with my current grammar).

For my case, I could have gone with static, but I decided against that on the premisis that I wanted to be able to make my compiler multi-threaded and able to handle parsing multiple files at the same time - and thus went with giving the grammar a single reference to it's "parsing info" structure, allowing for fast copies (1 register), variables that work (incrementing line number), and re-entrant (I can have two seperate threads parse using the grammar without weird behavior).

[Edited by - MaulingMonkey on October 25, 2004 3:44:51 AM]