c++ - 8.1e - mutable doesn't work!
- Laurentiu Pancescu <plaur crosswinds.net> Sep 28 2001
- Christof Meerwald <NOSPAM_seeMySig fastrun.at> Sep 28 2001
- Laurentiu Pancescu <plaur crosswinds.net> Sep 28 2001
- Christof Meerwald <cmeerw web.de> Sep 28 2001
- Laurentiu Pancescu <plaur crosswinds.net> Sep 28 2001
- "Walter" <walter digitalmars.com> Sep 28 2001
- Laurentiu Pancescu <plaur crosswinds.net> Sep 29 2001
- "Walter" <walter digitalmars.com> Sep 29 2001
- Laurentiu Pancescu <plaur crosswinds.net> Sep 29 2001
- "Walter" <walter digitalmars.com> Sep 29 2001
- Damian <damiandixon netscape.net> Oct 01 2001
- "Walter" <walter digitalmars.com> Oct 01 2001
- Laurentiu Pancescu <plaur crosswinds.net> Oct 01 2001
- Laurentiu Pancescu <plaur crosswinds.net> Sep 28 2001
The "mutable" keyword apparently doesn't work...
class Test
{
public:
void modify() const { c = 1.0; }
private:
mutable double c;
};
I'm getting the error "cannot modify const variable"...
Unfortunaltely, I really need mutable to work in my application -
Walter, what do you mean by "mutable implemented" in 8.1e ChangeLog?
Laurentiu
Sep 28 2001
On Fri, 28 Sep 2001 17:50:50 GMT, Laurentiu Pancescu wrote:The "mutable" keyword apparently doesn't work... class Test { public: void modify() const { c = 1.0; } private: mutable double c; };
Hmm, works for me. Are you sure you are using 8.1e? bye, Christof -- http://cmeerw.cjb.net Jabber: cmeerw jabber.at mailto cmeerw at web.de ICQ: 93773535, Yahoo!: cmeerw ...and what have you contributed to the Net?
Sep 28 2001
Christof Meerwald <NOSPAM_seeMySig fastrun.at> wrote:On Fri, 28 Sep 2001 17:50:50 GMT, Laurentiu Pancescu wrote:The "mutable" keyword apparently doesn't work... class Test { public: void modify() const { c = 1.0; } private: mutable double c; };
Hmm, works for me. Are you sure you are using 8.1e?
Yep, it's 8.1e - I tried to reduce some more complicated code from my application, but didn't try it... It doesn't work in my app, but in simple code yes!! :( I'm using <iostream>, <iomanip> and STLport 4.0, but mutable doesn't seem to be defined in there - I don't get what's going on... I'll try to see if I can reproduce it somehow. Laurentiu
Sep 28 2001
On Fri, 28 Sep 2001 18:08:05 GMT, Laurentiu Pancescu wrote:I'm using <iostream>, <iomanip> and STLport 4.0, but mutable doesn't seem to be defined in there - I don't get what's going
There is a "#define mutable" in stlport/stl/_config.h which is used if __STL_NEED_MUTABLE is defined in the compiler configuration file (just make sure you don't define it there). You could also try to generate a listing of the preprocessed source-code using "-e -lfile.lst" and check if the mutable keyword is still there. bye, Christof -- http://cmeerw.cjb.net Jabber: cmeerw jabber.at mailto cmeerw at web.de ICQ: 93773535, Yahoo!: cmeerw ...and what have you contributed to the Net?
Sep 28 2001
Christof Meerwald <cmeerw web.de> wrote:On Fri, 28 Sep 2001 18:08:05 GMT, Laurentiu Pancescu wrote:I'm using <iostream>, <iomanip> and STLport 4.0, but mutable doesn't seem to be defined in there - I don't get what's going
There is a "#define mutable" in stlport/stl/_config.h which is used if __STL_NEED_MUTABLE is defined in the compiler configuration file (just make sure you don't define it there).
I'm getting: Internal error: cg87 263 Regards, Laurentiu
Sep 28 2001
Laurentiu Pancescu wrote in message <9p2fc2$26em$1 digitaldaemon.com>...I'm getting: Internal error: cg87 263
Any chance of getting a small, reproducible test case of that?
Sep 28 2001
"Walter" <walter digitalmars.com> wrote:Laurentiu Pancescu wrote in message <9p2fc2$26em$1 digitaldaemon.com>...I'm getting: Internal error: cg87 263
Any chance of getting a small, reproducible test case of that?
I'm afraid not... What's strange is that I added a line at the very end of my file, containing '#error READY', and it works: I'm getting the READY error, so I think that this internal error doesn't occur in my code, but after finishing compiling the file (huh?). I wasn't able to reproduce this behavior with any small test example, but, if you want, I can send you (walter digitalmars.com, right?) a ZIP with a part of my program, enough to produce that error (a single cpp file, with some headers). I'm using the latest release of STLport, downloaded from digitalmars.com (you need that for compiling). Regards, Laurentiu
Sep 29 2001
All right. -Walter Laurentiu Pancescu wrote in message <9p3uhd$30ai$1 digitaldaemon.com>..."Walter" <walter digitalmars.com> wrote:Laurentiu Pancescu wrote in message <9p2fc2$26em$1 digitaldaemon.com>...I'm getting: Internal error: cg87 263
Any chance of getting a small, reproducible test case of that?
I'm afraid not... What's strange is that I added a line at the very end of my file, containing '#error READY', and it works: I'm getting the READY error, so I think that this internal error doesn't occur in my code, but after finishing compiling the file (huh?). I wasn't able to reproduce this behavior with any small test example, but, if you want, I can send you (walter digitalmars.com, right?) a ZIP with a part of my program, enough to
that error (a single cpp file, with some headers). I'm using the latest release of STLport, downloaded from digitalmars.com (you need that for compiling). Regards, Laurentiu
Sep 29 2001
"Walter" <walter digitalmars.com> wrote:All right. -Walter Laurentiu Pancescu wrote in message <9p3uhd$30ai$1 digitaldaemon.com>..."Walter" <walter digitalmars.com> wrote:Laurentiu Pancescu wrote in message <9p2fc2$26em$1 digitaldaemon.com>...I'm getting: Internal error: cg87 263
Any chance of getting a small, reproducible test case of that?
I hope you can fix this soon... I'm writing a numerical application for a friend (PhD student), who has a lot of calculations to do. Currently, it takes more than a week for a run (she wrote it in TurboPascal ;), so any speed improvement is more than welcome. I'm currently using DJGPP to generate a DOS extended app, since it's the fastest, but still DMC was about 50% faster than this. It could be about a few saved days at every run... Thanks, Laurentiu
Sep 29 2001
"Walter" <walter digitalmars.com> Laurentiu Pancescu wrote in message <9p52um$l0p$1 digitaldaemon.com>...I hope you can fix this soon... I'm writing a numerical application for a friend (PhD student), who has a lot of calculations to do. Currently, it takes more than a week for a run (she wrote it in TurboPascal ;), so any speed improvement is more than welcome. I'm currently using DJGPP to generate a DOS extended app, since it's the fastest, but still DMC was about 50% faster than this. It could be about a few saved days at every run...
I can get it fixed faster if you can shrink it down ...
Sep 29 2001
Hi, You really need to be looking in the directory stlport/config at the file 'stl_digital_mars.h' for the compiler configuration. I have just got back from doing some consultancy work in Sweden and will be looking at updating STLport 4.0 for the new compiler. I will then be porting STLport 4.5... As such I will see if I can narrow the mutable problem down in the STLport library. Though I can't promise any timescales. Regards Damian Christof Meerwald wrote:On Fri, 28 Sep 2001 18:08:05 GMT, Laurentiu Pancescu wrote:I'm using <iostream>, <iomanip> and STLport 4.0, but mutable doesn't seem to be defined in there - I don't get what's going
There is a "#define mutable" in stlport/stl/_config.h which is used if __STL_NEED_MUTABLE is defined in the compiler configuration file (just make sure you don't define it there). You could also try to generate a listing of the preprocessed source-code using "-e -lfile.lst" and check if the mutable keyword is still there. bye, Christof
Oct 01 2001
Thanks! My current focus is getting the regular STL 3.3 to work, but I'll see if any problems you isolate down can be fixed. -Walter Damian wrote in message <3BB890D5.2080509 netscape.net>...Hi, You really need to be looking in the directory stlport/config at the file 'stl_digital_mars.h' for the compiler configuration. I have just got back from doing some consultancy work in Sweden and will be looking at updating STLport 4.0 for the new compiler. I will then be porting STLport 4.5... As such I will see if I can narrow the mutable problem down in the STLport library. Though I can't promise any timescales. Regards Damian Christof Meerwald wrote:On Fri, 28 Sep 2001 18:08:05 GMT, Laurentiu Pancescu wrote:I'm using <iostream>, <iomanip> and STLport 4.0, but mutable doesn't seem to be defined in there - I don't get what's going
There is a "#define mutable" in stlport/stl/_config.h which is used if __STL_NEED_MUTABLE is defined in the compiler configuration file (just
sure you don't define it there). You could also try to generate a listing of the preprocessed source-code using "-e -lfile.lst" and check if the mutable keyword is still there. bye, Christof
Oct 01 2001
Damian <damiandixon netscape.net> wrote:Hi, You really need to be looking in the directory stlport/config at the file 'stl_digital_mars.h' for the compiler configuration. I have just got back from doing some consultancy work in Sweden and will be looking at updating STLport 4.0 for the new compiler. I will then be porting STLport 4.5... As such I will see if I can narrow the mutable problem down in the STLport library. Though I can't promise any timescales.
Hi, and thanks! There's no mutable problem in STLport, or none that I know of... Everything works fine wrt STL, I initially thought mutable generates that internal error. But it seems to be something not related to STL, but to floating point code generation (that's what cg87 name suggests, maybe I'm wrong). Thanks again, Laurentiu
Oct 01 2001
Christof Meerwald <NOSPAM_seeMySig fastrun.at> wrote:On Fri, 28 Sep 2001 17:50:50 GMT, Laurentiu Pancescu wrote:The "mutable" keyword apparently doesn't work... class Test { public: void modify() const { c = 1.0; } private: mutable double c; };
Hmm, works for me. Are you sure you are using 8.1e?
Okay, it seems that STLport is #defining mutable to nothing... try including <vector> at the top of the file. Probably STLport modifications for DMC need some cleanup. A simple '#undef mutable' solves the error, but I don't want to clutter my code with unnecessay #undefs, eventually depending on the compiler... Laurentiu
Sep 28 2001