470,849 Members | 681 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,849 developers. It's quick & easy.

const methodes and lazy calculation

Hi,
I would like to know whether a certain coding pattern exist to handle
the following problem.
I am using a const methode to get and value a from the class. In case
the value was not calculated yet, I want to start the calculation
(which is not a const methode) and return the value. But since the
calculation is not const, I can't call it within the getter. Any ideas?

Thanks in advance,
Thomas Kowalski

Jun 8 '06 #1
7 2064
th***@gmx.de wrote, On 8.6.2006 11:07:
Hi,
I would like to know whether a certain coding pattern exist to handle
the following problem.
I am using a const methode to get and value a from the class. In case
the value was not calculated yet, I want to start the calculation
(which is not a const methode) and return the value. But since the
calculation is not const, I can't call it within the getter. Any ideas?

Thanks in advance,
Thomas Kowalski

You can use keyword "mutable" on member variables so that you can change
them in const methods.

--
wilx
Jun 8 '06 #2
> You can use keyword "mutable" on member variables so that you can change
them in const methods.


means
1) make the getter const
2) make the value a mutable
3) create a private const methode to make the calculation

I guess this is already the cleanest way. Thanks. Is there something
like mutable for methodes, too? Or does just a const_cast of this help
there?

Thanks,
Thomas

Jun 8 '06 #3

th***@gmx.de wrote:
Thanks. Is there something
like mutable for methodes, too? Or does just a const_cast of this help
there?

Thanks,
Thomas


There is no such thing as:

class X
{
public:
void getY() mutable;
};

presumably getY() would be a method that can be called from const
functions even though it is not itself a const method (i.e. it may
modify anything).

Doesn't seem to make sense to have it there though as if it could
modify anything, your const methods shouldn't be calling it.

The only time it is useful to const_cast in such a situation is when
you have 2 overloads that use the same method to return an address or
reference to some class member, one of them const and one non-const.
Then you would normally implement one to call the other, and then it is
legitimate to use const_cast because it is YOUR implementation and you
know what you are doing (that you are not actually breaking any
contracts).

There are workarounds to that, eg having some external template method
that does the calculations where the template parameter can be T or
const T. Those who love to stick to coding standards and have a coding
standard that says "never const cast" would probably do it that way.
Practical programmers will often find the const_cast method the
clearest option for the situation.

Jun 8 '06 #4
Hi Thomas,

th***@gmx.de schrieb:
Hi,
I would like to know whether a certain coding pattern exist to handle
the following problem.
I am using a const methode to get and value a from the class. In case
the value was not calculated yet, I want to start the calculation
(which is not a const methode) and return the value. But since the
calculation is not const, I can't call it within the getter. Any ideas?

Thanks in advance,
Thomas Kowalski


One way to implement that lazy calculation in const getter-methods is to
declare the calculation method const and the member that should be
calculated mutable. This allows to change the value of that member in
const methods.

Ciao,
Marco
Jun 8 '06 #5

<th***@gmx.de> wrote in message
news:11*********************@y43g2000cwc.googlegro ups.com...
Hi,
I would like to know whether a certain coding pattern exist to handle
the following problem.
I am using a const methode to get and value a from the class. In case
the value was not calculated yet, I want to start the calculation
(which is not a const methode) and return the value. But since the
calculation is not const, I can't call it within the getter. Any ideas?

Thanks in advance,
Thomas Kowalski


How about not making the get method const? If it changes the value of a
member (even if just once, when first called), then it's not following the
promise to NOT change any members, right? You can return a const result,
but that doesn't mean you have to declare the method itself as const.

-Howard
Jun 8 '06 #6
Hi,
first thanks for all the answers. They have been very helpfull to order
my thoughts :)
How about not making the get method const? If it changes the value of a
member (even if just once, when first called), then it's not following the
promise to NOT change any members, right?


Thats true, actually I thought about that, too. But if you just see the
interface, there is no change visible for the user of the class (class
A). Just the calculation might be a bit faster. Besides I want the
class to be part of another one (class B). And I want B to have a
getter that returns a const reference to class A so that the user can't
do "stupid things".

Thomas

Jun 9 '06 #7
th***@gmx.de wrote:
...
How about not making the get method const? If it changes the value of a
member (even if just once, when first called), then it's not following the
promise to NOT change any members, right?


Thats true, actually I thought about that, too. But if you just see the
interface, there is no change visible for the user of the class (class
A). Just the calculation might be a bit faster. Besides I want the
class to be part of another one (class B). And I want B to have a
getter that returns a const reference to class A so that the user can't
do "stupid things".

Thomas


Wouldn't it be clearer to just check if the value was computed and if
not throw exception?

Jun 11 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

11 posts views Thread by John D. Goulden | last post: by
3 posts views Thread by arut | last post: by
2 posts views Thread by joegen | last post: by
5 posts views Thread by Bit Byter | last post: by
12 posts views Thread by Philip Potter | last post: by
15 posts views Thread by Jiří Paleček | last post: by
2 posts views Thread by Andrew Chalk | last post: by
11 posts views Thread by Szabolcs Nagy | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.