Jump to content
  • Advertisement
Sign in to follow this  
MaulingMonkey

when was const-behavior fixed in GCC?

This topic is 5019 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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]

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!