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

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?

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

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

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?

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 commented out __STL_NEED_MUTABLE in stl_digital_mars.h, and I'm getting:

Internal error: cg87 263

Regards,
  Laurentiu

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?

"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

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
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
>

"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