class variables: scoping

[Alf P. Steinbach]

Re: class variables: scoping

* nzanella@cs.mun .ca (Neil Zanella) schriebt:[color=blue]
> alfps@start.no (Alf P. Steinbach) wrote in message news:<406fde7b. 193238015@news. individual.net> ...[color=green]
> > * nzanella@cs.mun .ca (Neil Zanella) schriebt:[color=darkred]
> > >
> > > Essentially, I would like to have something like the equivalent of:
> > >
> > > class Foo {
> > > /* ... */
> > > private:
> > > /* ... */
> > > int z;
> > > /* ... */
> > > };
> > >
> > > However, I do not want to have all methods inside Foo see z. I only
> > > want method foo to see it, just like I did for x which can only be
> > > seen by foo().
> > >
> > > The value of z should survive different calls from within the same
> > > instance, but should be initialized for each new instance, like above.
> > > But it should have method scope, not class scope.[/color]
> >
> >
> > class Foo;
> >
> > class FooFunctor
> > {
> > private:
> > Foo& myFoo;
> > int myZ;
> > public:
> > FooFunctor( Foo& aFoo ): myFoo( aFoo ), myZ( 0 ) {}
> > int operator()();
> > };
> >
> > class Foo
> > {
> > private:
> > int x;
> > FooFunctor foo;
> > public:
> > Foo(): x(0), foo(*this) {}
> >
> > void bar()
> > {
> > x = foo();
> > }
> > };
> >
> > int FooFunctor::ope rator()(){ ... }[/color]
>
> Thank you for your reply..[/color]

You're welcome..

[color=blue]
> I am not sure how your example would help in the situation I describe.[/color]

Try it.


[color=blue]
> Consider the following code example where having the runFooi variables
> being local to the current function would be of practical use. These
> would then also have to be initialized within that function with
> a scheme similar to that of the initialization of static variables:
> on first call for an instance the variable is constructed,
> subsequent calls within same object ignore the
> construction and use the old value
> for current object.[/color]

That's the same problem again, and it's no more difficult with four
variables than with one.

In addition you have added an irrelevant aspect, namly logical constness.

Look up the keyword 'mutable' for that.

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Neil Zanella]

Re: class variables: scoping

"Siemel Naran" <SiemelNaran@RE MOVE.att.net> wrote in message:
[color=blue]
> Of course, comments are a nice idea too![/color]

I don't understand exactly how usnig functors could
help in this situation. However I have come up with
another solution that solves the problem which I
originally posted. Essentially I achieve the desired
result and feature using an std::map which
associates with each instance the desired variable.
Hence using static local variables associated with
instances achieves the effect of instance specific
local variables, as originally requested. Here we
go. Finally, something that seems to work neatly! I
was getting quite tired of inspecting my class
variables to see whether I don't have some variable
which is not being used by any method. Cluttering
all my function specific methods was simply
unstylish IMHO.

Comments on the solution posted below very welcome!

Regards,

Neil

#include <iostream>
#include <cstdlib>
#include <map>

class Foo {
public:
int foo1() {
static std::map<Foo *, bool> computed;
if (!computed[this]) {
std::cout << "Computing foo1..." << std::endl;
x1 = compute(0, 0);
computed[this] = true;
} else
std::cout << "Reusing computed foo1 result..." << std::endl;
return x1;
}
int foo2() {
static std::map<Foo *, bool> computed;
if (!computed[this]) {
std::cout << "Computing foo2..." << std::endl;
x2 = compute(0, 1);
computed[this] = true;
} else
std::cout << "Reusing computed foo2 result..." << std::endl;
return x2;
}
int foo3() {
static std::map<Foo *, bool> computed;
if (!computed[this]) {
std::cout << "Computing foo3..." << std::endl;
x3 = compute(1, 0);
computed[this] = true;
} else
std::cout << "Reusing computed foo3 result..." << std::endl;
return x3;
}
int foo4() {
static std::map<Foo *, bool> computed;
if (!computed[this]) {
std::cout << "Computing foo4..." << std::endl;
x4 = compute(1, 1);
computed[this] = true;
} else
std::cout << "Reusing computed foo4 result..." << std::endl;
return x4;
}
private:
int compute(int a, int b) {
/* suppose this takes a long time to run */
return rand() + 2 * a + b; /* for simplicity */
}
int x1, x2, x3, x4; /* data to be computed */
};

int main() {

/* run program without waiting for unnecessary computations */
/* available which would unnecessarily initialize class data */

std::cout << "Foo 1 Instance:" << std::endl;

Foo foo1;
std::cout << foo1.foo1() << std::endl;
std::cout << foo1.foo1() << std::endl;
std::cout << foo1.foo2() << std::endl;

/* foo1.foo3(), and foo1.foo4() never called */
/* hence OO program can run as fast as a procedural program */

std::cout << "Foo 2 Instance: " << std::endl;

Foo foo2;
std::cout << foo2.foo2() << std::endl;
std::cout << foo2.foo3() << std::endl;
std::cout << foo2.foo4() << std::endl;
std::cout << foo2.foo4() << std::endl;

/* foo1.foo1() never called */
/* hence OO program can run as fast as a procedural program */

}


Output:

Foo 1 Instance:
Computing foo1...
1804289383
Reusing computed foo1 result...
1804289383
Computing foo2...
846930887
Foo 2 Instance:
Computing foo2...
1681692778
Computing foo3...
1714636917
Computing foo4...
1957747796
Reusing computed foo4 result...
1957747796

[Alf P. Steinbach]

Re: class variables: scoping

* nzanella@cs.mun .ca (Neil Zanella) schriebt:[color=blue]
> alfps@start.no (Alf P. Steinbach) wrote in message news:<406fde7b. 193238015@news. individual.net> ...[color=green]
> > * nzanella@cs.mun .ca (Neil Zanella) schriebt:[color=darkred]
> > >
> > > Essentially, I would like to have something like the equivalent of:
> > >
> > > class Foo {
> > > /* ... */
> > > private:
> > > /* ... */
> > > int z;
> > > /* ... */
> > > };
> > >
> > > However, I do not want to have all methods inside Foo see z. I only
> > > want method foo to see it, just like I did for x which can only be
> > > seen by foo().
> > >
> > > The value of z should survive different calls from within the same
> > > instance, but should be initialized for each new instance, like above.
> > > But it should have method scope, not class scope.[/color]
> >
> >
> > class Foo;
> >
> > class FooFunctor
> > {
> > private:
> > Foo& myFoo;
> > int myZ;
> > public:
> > FooFunctor( Foo& aFoo ): myFoo( aFoo ), myZ( 0 ) {}
> > int operator()();
> > };
> >
> > class Foo
> > {
> > private:
> > int x;
> > FooFunctor foo;
> > public:
> > Foo(): x(0), foo(*this) {}
> >
> > void bar()
> > {
> > x = foo();
> > }
> > };
> >
> > int FooFunctor::ope rator()(){ ... }[/color]
>
> Thank you for your reply..[/color]

You're welcome..

[color=blue]
> I am not sure how your example would help in the situation I describe.[/color]

Try it.


[color=blue]
> Consider the following code example where having the runFooi variables
> being local to the current function would be of practical use. These
> would then also have to be initialized within that function with
> a scheme similar to that of the initialization of static variables:
> on first call for an instance the variable is constructed,
> subsequent calls within same object ignore the
> construction and use the old value
> for current object.[/color]

That's the same problem again, and it's no more difficult with four
variables than with one.

In addition you have added an irrelevant aspect, namly logical constness.

Look up the keyword 'mutable' for that.

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Siemel Naran]

Re: class variables: scoping

"Neil Zanella" <nzanella@cs.mu n.ca> wrote in message
[color=blue]
> I don't understand exactly how usnig functors could
> help in this situation. However I have come up with[/color]

I think I misunderstood your original requirement. Thought you wanted to
make a private variable which is accessible to only 1 member function.


[color=blue]
> #include <iostream>
> #include <cstdlib>
> #include <map>
>
> class Foo {
> public:
> int foo1() {
> static std::map<Foo *, bool> computed;
> if (!computed[this]) {
> std::cout << "Computing foo1..." << std::endl;
> x1 = compute(0, 0);
> computed[this] = true;
> } else
> std::cout << "Reusing computed foo1 result..." << std::endl;
> return x1;
> }
> int foo2() {
> static std::map<Foo *, bool> computed;
> if (!computed[this]) {
> std::cout << "Computing foo2..." << std::endl;
> x2 = compute(0, 1);
> computed[this] = true;
> } else
> std::cout << "Reusing computed foo2 result..." << std::endl;
> return x2;
> }
> int foo3() {
> static std::map<Foo *, bool> computed;
> if (!computed[this]) {
> std::cout << "Computing foo3..." << std::endl;
> x3 = compute(1, 0);
> computed[this] = true;
> } else
> std::cout << "Reusing computed foo3 result..." << std::endl;
> return x3;
> }
> int foo4() {
> static std::map<Foo *, bool> computed;
> if (!computed[this]) {
> std::cout << "Computing foo4..." << std::endl;
> x4 = compute(1, 1);
> computed[this] = true;
> } else
> std::cout << "Reusing computed foo4 result..." << std::endl;
> return x4;
> }
> private:
> int compute(int a, int b) {
> /* suppose this takes a long time to run */
> return rand() + 2 * a + b; /* for simplicity */
> }
> int x1, x2, x3, x4; /* data to be computed */
> };[/color]

Why not just

class Foo {
public:
Foo() : x1(), x1_computed(fal se) { }
private:
int x1;
bool x1_computed;

If you want to get fancy, you can try the recursive derivation idea I posted
in "set/get in c++".

[color=blue]
> int main() {
>
> /* run program without waiting for unnecessary computations */
> /* available which would unnecessarily initialize class data */
>
> std::cout << "Foo 1 Instance:" << std::endl;
>
> Foo foo1;
> std::cout << foo1.foo1() << std::endl;
> std::cout << foo1.foo1() << std::endl;
> std::cout << foo1.foo2() << std::endl;
>
> /* foo1.foo3(), and foo1.foo4() never called */
> /* hence OO program can run as fast as a procedural program */
>
> std::cout << "Foo 2 Instance: " << std::endl;
>
> Foo foo2;
> std::cout << foo2.foo2() << std::endl;
> std::cout << foo2.foo3() << std::endl;
> std::cout << foo2.foo4() << std::endl;
> std::cout << foo2.foo4() << std::endl;
>
> /* foo1.foo1() never called */
> /* hence OO program can run as fast as a procedural program */
>
> }[/color]

[Siemel Naran]

Re: class variables: scoping

"Neil Zanella" <nzanella@cs.mu n.ca> wrote in message
[color=blue]
> I don't understand exactly how usnig functors could
> help in this situation. However I have come up with[/color]

I think I misunderstood your original requirement. Thought you wanted to
make a private variable which is accessible to only 1 member function.


[color=blue]
> #include <iostream>
> #include <cstdlib>
> #include <map>
>
> class Foo {
> public:
> int foo1() {
> static std::map<Foo *, bool> computed;
> if (!computed[this]) {
> std::cout << "Computing foo1..." << std::endl;
> x1 = compute(0, 0);
> computed[this] = true;
> } else
> std::cout << "Reusing computed foo1 result..." << std::endl;
> return x1;
> }
> int foo2() {
> static std::map<Foo *, bool> computed;
> if (!computed[this]) {
> std::cout << "Computing foo2..." << std::endl;
> x2 = compute(0, 1);
> computed[this] = true;
> } else
> std::cout << "Reusing computed foo2 result..." << std::endl;
> return x2;
> }
> int foo3() {
> static std::map<Foo *, bool> computed;
> if (!computed[this]) {
> std::cout << "Computing foo3..." << std::endl;
> x3 = compute(1, 0);
> computed[this] = true;
> } else
> std::cout << "Reusing computed foo3 result..." << std::endl;
> return x3;
> }
> int foo4() {
> static std::map<Foo *, bool> computed;
> if (!computed[this]) {
> std::cout << "Computing foo4..." << std::endl;
> x4 = compute(1, 1);
> computed[this] = true;
> } else
> std::cout << "Reusing computed foo4 result..." << std::endl;
> return x4;
> }
> private:
> int compute(int a, int b) {
> /* suppose this takes a long time to run */
> return rand() + 2 * a + b; /* for simplicity */
> }
> int x1, x2, x3, x4; /* data to be computed */
> };[/color]

Why not just

class Foo {
public:
Foo() : x1(), x1_computed(fal se) { }
private:
int x1;
bool x1_computed;

If you want to get fancy, you can try the recursive derivation idea I posted
in "set/get in c++".

[color=blue]
> int main() {
>
> /* run program without waiting for unnecessary computations */
> /* available which would unnecessarily initialize class data */
>
> std::cout << "Foo 1 Instance:" << std::endl;
>
> Foo foo1;
> std::cout << foo1.foo1() << std::endl;
> std::cout << foo1.foo1() << std::endl;
> std::cout << foo1.foo2() << std::endl;
>
> /* foo1.foo3(), and foo1.foo4() never called */
> /* hence OO program can run as fast as a procedural program */
>
> std::cout << "Foo 2 Instance: " << std::endl;
>
> Foo foo2;
> std::cout << foo2.foo2() << std::endl;
> std::cout << foo2.foo3() << std::endl;
> std::cout << foo2.foo4() << std::endl;
> std::cout << foo2.foo4() << std::endl;
>
> /* foo1.foo1() never called */
> /* hence OO program can run as fast as a procedural program */
>
> }[/color]

[Leor Zolman]

Re: class variables: scoping

On 4 Apr 2004 13:24:10 -0700, nzanella@cs.mun .ca (Neil Zanella) wrote:
[color=blue]
>Leor Zolman <leor@bdsoft.co m> wrote in message:
>[color=green][color=darkred]
>> >Foo::foo() {
>> > static int x;
>> > int y;
>> > /* ... */
>> >}
>> >
>> >Here variable x is shared by all instances of the class,[/color]
>>
>> Not /that/ variable x, if you're referring to the one in Foo:foo(). That's
>> a block-scope static, which means it can only be referred to within that
>> function (and its value persists across multiple calls to it. By the way,
>> it gets initialized to zero the first time the function is called, if you
>> don't give it an initializer.)[/color]
>
>Perhaps my explanation was somewhat inadequate. What you have stated in the
>above paragraph is correct. Indeed, x can only be referred to from within
>member function Foo::foo(). And indeed since it is static the compiler will
>automaticall y arrange for it to be initialized to zero when no initializer
>is present. What I meant to express by saying that x is shared by all
>instances of Foo is exemplified in the following code:
>[/color]
[code snipped]

I think you're confusing yourself by saying that the x above is "shared by
all instances of Foo" because in fact it is shared by all instances of
/everything/, along with all /non-instances/ of everything (non-member
functions), that end up calling Foo::foo(). x behaves just like a
file-scope ("global") variable...that just happens to only be visible
within Foo::foo().
[color=blue]
>
>without changing the contents of main and without changing the contents
>of the class definition (which seems impossible in C++, since it does not
>support the feature I describe).
>[color=green][color=darkred]
>> >The value of z should survive different calls from within the same
>> >instance, but should be initialized for each new instance, like above.
>> >But it should have method scope, not class scope.[/color]
>>
>> I /think/ I see what you want, but there's no primitive way to declare that
>> in C++: You want an instance variable (one copy associated with each
>> instance of an object) that is only in scope within a particular function,[/color]
>
>Correct. That is indeed the feature I was describing. Furthermore I was
>poining out that C++ supports combinations:
>
>(one copy per class, class scope) (static data members in class body)
>(one copy per class, function scope) (static data members in function body)
>(one copy per instance, class scope) (automatic data in class body)
>
>but not the combination:
>
>(one copy per instance, function scope)[/color]

Perhaps it is because Bjarne and everyone else involved in the evolution of
C++ didn't think that last permutation was useful enough, if in fact it
ever occurred to them. I don't know, but the idea sure never occurred to
/me/.

[color=blue]
>[color=green][color=darkred]
>> >I think this feature is missing from C++ and is quite useful. Because
>> >if some class variable is used only in one method, then why should I
>> >have to place it in the class definition.[/color]
>>
>> To indicate to the compiler that it has to make room for it in each object
>> instantiated. At least the way C++ is currently defined ;-)[/color]
>
>Hmmm... but the compiler went and fetched those static variables for
>the BSS segment. I gues they belong to another data segment altogether
>hence that is what makes it possible???[/color]

What's a BSS segment? I'm sorry, I swore off assembly language and as much
as possible pertaining to it a long time ago. But if you understood what I
said above what it means for a variable to be static to a function, I think
you'll probably have the answer to your question.

Cheers,
-leor

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Leor Zolman]

Re: class variables: scoping

On 4 Apr 2004 13:24:10 -0700, nzanella@cs.mun .ca (Neil Zanella) wrote:
[color=blue]
>Leor Zolman <leor@bdsoft.co m> wrote in message:
>[color=green][color=darkred]
>> >Foo::foo() {
>> > static int x;
>> > int y;
>> > /* ... */
>> >}
>> >
>> >Here variable x is shared by all instances of the class,[/color]
>>
>> Not /that/ variable x, if you're referring to the one in Foo:foo(). That's
>> a block-scope static, which means it can only be referred to within that
>> function (and its value persists across multiple calls to it. By the way,
>> it gets initialized to zero the first time the function is called, if you
>> don't give it an initializer.)[/color]
>
>Perhaps my explanation was somewhat inadequate. What you have stated in the
>above paragraph is correct. Indeed, x can only be referred to from within
>member function Foo::foo(). And indeed since it is static the compiler will
>automaticall y arrange for it to be initialized to zero when no initializer
>is present. What I meant to express by saying that x is shared by all
>instances of Foo is exemplified in the following code:
>[/color]
[code snipped]

I think you're confusing yourself by saying that the x above is "shared by
all instances of Foo" because in fact it is shared by all instances of
/everything/, along with all /non-instances/ of everything (non-member
functions), that end up calling Foo::foo(). x behaves just like a
file-scope ("global") variable...that just happens to only be visible
within Foo::foo().
[color=blue]
>
>without changing the contents of main and without changing the contents
>of the class definition (which seems impossible in C++, since it does not
>support the feature I describe).
>[color=green][color=darkred]
>> >The value of z should survive different calls from within the same
>> >instance, but should be initialized for each new instance, like above.
>> >But it should have method scope, not class scope.[/color]
>>
>> I /think/ I see what you want, but there's no primitive way to declare that
>> in C++: You want an instance variable (one copy associated with each
>> instance of an object) that is only in scope within a particular function,[/color]
>
>Correct. That is indeed the feature I was describing. Furthermore I was
>poining out that C++ supports combinations:
>
>(one copy per class, class scope) (static data members in class body)
>(one copy per class, function scope) (static data members in function body)
>(one copy per instance, class scope) (automatic data in class body)
>
>but not the combination:
>
>(one copy per instance, function scope)[/color]

Perhaps it is because Bjarne and everyone else involved in the evolution of
C++ didn't think that last permutation was useful enough, if in fact it
ever occurred to them. I don't know, but the idea sure never occurred to
/me/.

[color=blue]
>[color=green][color=darkred]
>> >I think this feature is missing from C++ and is quite useful. Because
>> >if some class variable is used only in one method, then why should I
>> >have to place it in the class definition.[/color]
>>
>> To indicate to the compiler that it has to make room for it in each object
>> instantiated. At least the way C++ is currently defined ;-)[/color]
>
>Hmmm... but the compiler went and fetched those static variables for
>the BSS segment. I gues they belong to another data segment altogether
>hence that is what makes it possible???[/color]

What's a BSS segment? I'm sorry, I swore off assembly language and as much
as possible pertaining to it a long time ago. But if you understood what I
said above what it means for a variable to be static to a function, I think
you'll probably have the answer to your question.

Cheers,
-leor

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Neil Zanella]

Re: class variables: scoping

"Siemel Naran" <SiemelNaran@RE MOVE.att.net> wrote in message
[color=blue]
> Why not just
>
> class Foo {
> public:
> Foo() : x1(), x1_computed(fal se) { }
> private:
> int x1;
> bool x1_computed;[/color]

What if a single function computes 10 data members. Wouldn't you then
rather associate one boolean variable with the function than have one
for each data member? I am not just considering setters and getters.
There are more complicated functions that manipulate multiple data
members in more complicated classes. On the other hand I would
probably have a boolean variable for each private data member
if it were the case that the functions did not operate on
disjoint data members.

Anyhow, to answer your question, I don't like having all those booleans
and what not linger inside class Foo when they are method specific, which
is what I originally posted about. In any case perhaps something like

template<class t>
struct Data {
T value;
bool computed;
};

could perhaps help reduce the clutter... (yes? no?).
[color=blue]
> If you want to get fancy, you can try the recursive derivation idea I posted
> in "set/get in c++".[/color]

I would like to comment on the "set/get in C++" thread. The idea described
therein is not a new idea. Some C++ toolkits such as Qt implement it already.
For instance see the Q_PROPERTY Qt macro. This takes the following format:

Q_PROPERTY( Priority priority READ priority WRITE setPriority )

You may want to read about it in with the assistant Qt application.

However, if classes were all about setters and getters that returned and
set a single state variable each then OOAD would be quite uninteresting.
Nevertheless for some applictions several short setters and getters may
be all it takes to describe some of the more trivial classes. In general
however we can have more complicated setter implementations , perhaps even
so for the getters, and the internal representation of the data could be
quite different from what appears to be presented by the class interface.

Thanks,

Neil

[Neil Zanella]

Re: class variables: scoping

"Siemel Naran" <SiemelNaran@RE MOVE.att.net> wrote in message
[color=blue]
> Why not just
>
> class Foo {
> public:
> Foo() : x1(), x1_computed(fal se) { }
> private:
> int x1;
> bool x1_computed;[/color]

What if a single function computes 10 data members. Wouldn't you then
rather associate one boolean variable with the function than have one
for each data member? I am not just considering setters and getters.
There are more complicated functions that manipulate multiple data
members in more complicated classes. On the other hand I would
probably have a boolean variable for each private data member
if it were the case that the functions did not operate on
disjoint data members.

Anyhow, to answer your question, I don't like having all those booleans
and what not linger inside class Foo when they are method specific, which
is what I originally posted about. In any case perhaps something like

template<class t>
struct Data {
T value;
bool computed;
};

could perhaps help reduce the clutter... (yes? no?).
[color=blue]
> If you want to get fancy, you can try the recursive derivation idea I posted
> in "set/get in c++".[/color]

I would like to comment on the "set/get in C++" thread. The idea described
therein is not a new idea. Some C++ toolkits such as Qt implement it already.
For instance see the Q_PROPERTY Qt macro. This takes the following format:

Q_PROPERTY( Priority priority READ priority WRITE setPriority )

You may want to read about it in with the assistant Qt application.

However, if classes were all about setters and getters that returned and
set a single state variable each then OOAD would be quite uninteresting.
Nevertheless for some applictions several short setters and getters may
be all it takes to describe some of the more trivial classes. In general
however we can have more complicated setter implementations , perhaps even
so for the getters, and the internal representation of the data could be
quite different from what appears to be presented by the class interface.

Thanks,

Neil

[Siemel Naran]

Re: class variables: scoping

"Neil Zanella" <nzanella@cs.mu n.ca> wrote in message
news:b68d2f19.0 404051918.bc0e9 3c@posting.goog le.com...[color=blue]
> "Siemel Naran" <SiemelNaran@RE MOVE.att.net> wrote in message[/color]
[color=blue][color=green]
> > Why not just
> >
> > class Foo {
> > public:
> > Foo() : x1(), x1_computed(fal se) { }
> > private:
> > int x1;
> > bool x1_computed;[/color]
>
> What if a single function computes 10 data members. Wouldn't you then
> rather associate one boolean variable with the function than have one
> for each data member? I am not just considering setters and getters.
> There are more complicated functions that manipulate multiple data
> members in more complicated classes. On the other hand I would
> probably have a boolean variable for each private data member
> if it were the case that the functions did not operate on
> disjoint data members.[/color]

OK, I understand your question now -- you don't want to clutter the header
file. Initially I thought you wanted to member variable accessible to only
one function (a kind of super-private access mechanism but also an
indication that your class is too big), then I thought you just wanted to
indicate whether a variable was constructed.
[color=blue]
> Anyhow, to answer your question, I don't like having all those booleans
> and what not linger inside class Foo when they are method specific, which
> is what I originally posted about. In any case perhaps something like
>
> template<class t>
> struct Data {
> T value;
> bool computed;
> };
>
> could perhaps help reduce the clutter... (yes? no?).[/color]

It reduces the number of lines in your code, but the clutter is still there
(namely all the boolean variables) once the template code is expanded.
Besides as you point out, if you want one boolean variable for ten data
members which foo() calculates, the Data<T> is overkill as it constructs 10
booleans. I don't have a perfect or good solution, but maybe you could use
a member variable like,

/*mutable*/ std::set<std::s tring> d_constructed;

and in your functions use the __FUNCTION__ macro to indicate that the
variables of this function are constructed. Note that __FUNCTION__ is not
standard, though there are variations you can try.

void Foo::foo() const {
if (d_constructed. find(__FUNCTION __) == d_constructed.e nd()) {
d_constructed.i nsert(__FUNCTIO N__);
d_x = 3;
d_y = 8;
}
}

The static variables idea in your previous post works could easily cause
trouble in multi-threaded environments.


[color=blue][color=green]
> > If you want to get fancy, you can try the recursive derivation idea I[/color][/color]
posted[color=blue][color=green]
> > in "set/get in c++".[/color]
>
> I would like to comment on the "set/get in C++" thread. The idea described
> therein is not a new idea. Some C++ toolkits such as Qt implement it[/color]
already.[color=blue]
> For instance see the Q_PROPERTY Qt macro. This takes the following format:
>
> Q_PROPERTY( Priority priority READ priority WRITE setPriority )
>
> You may want to read about it in with the assistant Qt application.
>
> However, if classes were all about setters and getters that returned and
> set a single state variable each then OOAD would be quite uninteresting.
> Nevertheless for some applictions several short setters and getters may
> be all it takes to describe some of the more trivial classes. In general
> however we can have more complicated setter implementations , perhaps even
> so for the getters, and the internal representation of the data could be
> quite different from what appears to be presented by the class interface.[/color]

Right, the idea is best when the function bodies are more complicated.
Though I did not claim the idea was new, and I first learned about it in
Stroustrup's book.

[Siemel Naran]

Re: class variables: scoping

"Neil Zanella" <nzanella@cs.mu n.ca> wrote in message
news:b68d2f19.0 404051918.bc0e9 3c@posting.goog le.com...[color=blue]
> "Siemel Naran" <SiemelNaran@RE MOVE.att.net> wrote in message[/color]
[color=blue][color=green]
> > Why not just
> >
> > class Foo {
> > public:
> > Foo() : x1(), x1_computed(fal se) { }
> > private:
> > int x1;
> > bool x1_computed;[/color]
>
> What if a single function computes 10 data members. Wouldn't you then
> rather associate one boolean variable with the function than have one
> for each data member? I am not just considering setters and getters.
> There are more complicated functions that manipulate multiple data
> members in more complicated classes. On the other hand I would
> probably have a boolean variable for each private data member
> if it were the case that the functions did not operate on
> disjoint data members.[/color]

OK, I understand your question now -- you don't want to clutter the header
file. Initially I thought you wanted to member variable accessible to only
one function (a kind of super-private access mechanism but also an
indication that your class is too big), then I thought you just wanted to
indicate whether a variable was constructed.
[color=blue]
> Anyhow, to answer your question, I don't like having all those booleans
> and what not linger inside class Foo when they are method specific, which
> is what I originally posted about. In any case perhaps something like
>
> template<class t>
> struct Data {
> T value;
> bool computed;
> };
>
> could perhaps help reduce the clutter... (yes? no?).[/color]

It reduces the number of lines in your code, but the clutter is still there
(namely all the boolean variables) once the template code is expanded.
Besides as you point out, if you want one boolean variable for ten data
members which foo() calculates, the Data<T> is overkill as it constructs 10
booleans. I don't have a perfect or good solution, but maybe you could use
a member variable like,

/*mutable*/ std::set<std::s tring> d_constructed;

and in your functions use the __FUNCTION__ macro to indicate that the
variables of this function are constructed. Note that __FUNCTION__ is not
standard, though there are variations you can try.

void Foo::foo() const {
if (d_constructed. find(__FUNCTION __) == d_constructed.e nd()) {
d_constructed.i nsert(__FUNCTIO N__);
d_x = 3;
d_y = 8;
}
}

The static variables idea in your previous post works could easily cause
trouble in multi-threaded environments.


[color=blue][color=green]
> > If you want to get fancy, you can try the recursive derivation idea I[/color][/color]
posted[color=blue][color=green]
> > in "set/get in c++".[/color]
>
> I would like to comment on the "set/get in C++" thread. The idea described
> therein is not a new idea. Some C++ toolkits such as Qt implement it[/color]
already.[color=blue]
> For instance see the Q_PROPERTY Qt macro. This takes the following format:
>
> Q_PROPERTY( Priority priority READ priority WRITE setPriority )
>
> You may want to read about it in with the assistant Qt application.
>
> However, if classes were all about setters and getters that returned and
> set a single state variable each then OOAD would be quite uninteresting.
> Nevertheless for some applictions several short setters and getters may
> be all it takes to describe some of the more trivial classes. In general
> however we can have more complicated setter implementations , perhaps even
> so for the getters, and the internal representation of the data could be
> quite different from what appears to be presented by the class interface.[/color]

Right, the idea is best when the function bodies are more complicated.
Though I did not claim the idea was new, and I first learned about it in
Stroustrup's book.

[Neil Zanella]

Re: class variables: scoping

"Siemel Naran" <SiemelNaran@RE MOVE.att.net> wrote in message news:<7Orcc.259 11
[color=blue]
> I don't have a perfect or good solution, but maybe you could use
> a member variable like,
>
> /*mutable*/ std::set<std::s tring> d_constructed;
>
> and in your functions use the __FUNCTION__ macro to indicate that the
> variables of this function are constructed. Note that __FUNCTION__ is not
> standard, though there are variations you can try.
>
> void Foo::foo() const {
> if (d_constructed. find(__FUNCTION __) == d_constructed.e nd()) {
> d_constructed.i nsert(__FUNCTIO N__);
> d_x = 3;
> d_y = 8;
> }
> }[/color]

Is the __FUNCTION__ macro specific to the gcc compiler suite or does it work
with other compilers as well. In any case standard behavior could be attained
by using an enumeration with something similar to function names in it.
[color=blue]
> The static variables idea in your previous post works could easily cause
> trouble in multi-threaded environments.[/color]

Perhaps you are referring to the fact that in a multithreaded applications
two objects may have the same virtual address, hence it is not possible to
identify an object on the basis of its virtual address and be certain that
the application will work. Is this what you are referring to when you mention
that problems may arise in multithreaded applications.

Regards,

Neil

[Neil Zanella]

Re: class variables: scoping

"Siemel Naran" <SiemelNaran@RE MOVE.att.net> wrote in message news:<7Orcc.259 11
[color=blue]
> I don't have a perfect or good solution, but maybe you could use
> a member variable like,
>
> /*mutable*/ std::set<std::s tring> d_constructed;
>
> and in your functions use the __FUNCTION__ macro to indicate that the
> variables of this function are constructed. Note that __FUNCTION__ is not
> standard, though there are variations you can try.
>
> void Foo::foo() const {
> if (d_constructed. find(__FUNCTION __) == d_constructed.e nd()) {
> d_constructed.i nsert(__FUNCTIO N__);
> d_x = 3;
> d_y = 8;
> }
> }[/color]

Is the __FUNCTION__ macro specific to the gcc compiler suite or does it work
with other compilers as well. In any case standard behavior could be attained
by using an enumeration with something similar to function names in it.
[color=blue]
> The static variables idea in your previous post works could easily cause
> trouble in multi-threaded environments.[/color]

Perhaps you are referring to the fact that in a multithreaded applications
two objects may have the same virtual address, hence it is not possible to
identify an object on the basis of its virtual address and be certain that
the application will work. Is this what you are referring to when you mention
that problems may arise in multithreaded applications.

Regards,

Neil

[Siemel Naran]

Re: class variables: scoping

"Neil Zanella" <nzanella@cs.mu n.ca> wrote in message[color=blue]
> "Siemel Naran" <SiemelNaran@RE MOVE.att.net> wrote in message[/color]
news:<7Orcc.259 11
[color=blue][color=green]
> > /*mutable*/ std::set<std::s tring> d_constructed;
> >
> > and in your functions use the __FUNCTION__ macro to indicate that the
> > variables of this function are constructed. Note that __FUNCTION__ is[/color][/color]
not[color=blue][color=green]
> > standard, though there are variations you can try.[/color][/color]
[color=blue]
> Is the __FUNCTION__ macro specific to the gcc compiler suite or does it[/color]
work[color=blue]
> with other compilers as well. In any case standard behavior could be[/color]
attained[color=blue]
> by using an enumeration with something similar to function names in it.[/color]

Borland 6 does not support __FUNCTION__. I think Microsoft does, but ask on
a Microsoft group to be sure, or try it on the compiler.

Instead of maintaining an enum, I was thinking of converting the address of
a function to a string, like this,

void * ptr = static_cast<voi d *>(&X::function );
std::cout << ptr;

But you can't convert a pointer to member function into a void*, even
through reinterpret_cas t, because they usually have different sizes. And
typeid(&X::func tion).name() prints the type of the function, so if
X::function1 and X::function2 have the same signature, typeid.name() prints
the same thing.

To avoid cluttering the header file, why not just use the pointer to
implementation idea where you declare the struct in the cpp file? You get
insulation for free, can use reference counted smart pointers if so desired
(though they have multi-threading problems/challenges too), etc.

[color=blue][color=green]
> > The static variables idea in your previous post works could easily cause
> > trouble in multi-threaded environments.[/color]
>
> Perhaps you are referring to the fact that in a multithreaded applications
> two objects may have the same virtual address, hence it is not possible to
> identify an object on the basis of its virtual address and be certain that
> the application will work. Is this what you are referring to when you[/color]
mention[color=blue]
> that problems may arise in multithreaded applications.[/color]

It's the standard one. Two threads call your function X::f(). Both see
that the static variable is not constructed. Then both go ahead and
construct it.

The solution is when one thread sees it is not constructed it blocks the
function memory so the other thread cannot do anything, the the first thread
constructs the object and releases the block, and the other thread then sees
the static variable is constructed. There is no native support for this in
C++. You have to use OS functions like critical section and mutexes. Even
if it works, the use of these OS functions is quite expensive. I'm not an
expert on multi-threading (still learning it myself), but those are the
basics.

[Siemel Naran]

Re: class variables: scoping

"Neil Zanella" <nzanella@cs.mu n.ca> wrote in message[color=blue]
> "Siemel Naran" <SiemelNaran@RE MOVE.att.net> wrote in message[/color]
news:<7Orcc.259 11
[color=blue][color=green]
> > /*mutable*/ std::set<std::s tring> d_constructed;
> >
> > and in your functions use the __FUNCTION__ macro to indicate that the
> > variables of this function are constructed. Note that __FUNCTION__ is[/color][/color]
not[color=blue][color=green]
> > standard, though there are variations you can try.[/color][/color]
[color=blue]
> Is the __FUNCTION__ macro specific to the gcc compiler suite or does it[/color]
work[color=blue]
> with other compilers as well. In any case standard behavior could be[/color]
attained[color=blue]
> by using an enumeration with something similar to function names in it.[/color]

Borland 6 does not support __FUNCTION__. I think Microsoft does, but ask on
a Microsoft group to be sure, or try it on the compiler.

Instead of maintaining an enum, I was thinking of converting the address of
a function to a string, like this,

void * ptr = static_cast<voi d *>(&X::function );
std::cout << ptr;

But you can't convert a pointer to member function into a void*, even
through reinterpret_cas t, because they usually have different sizes. And
typeid(&X::func tion).name() prints the type of the function, so if
X::function1 and X::function2 have the same signature, typeid.name() prints
the same thing.

To avoid cluttering the header file, why not just use the pointer to
implementation idea where you declare the struct in the cpp file? You get
insulation for free, can use reference counted smart pointers if so desired
(though they have multi-threading problems/challenges too), etc.

[color=blue][color=green]
> > The static variables idea in your previous post works could easily cause
> > trouble in multi-threaded environments.[/color]
>
> Perhaps you are referring to the fact that in a multithreaded applications
> two objects may have the same virtual address, hence it is not possible to
> identify an object on the basis of its virtual address and be certain that
> the application will work. Is this what you are referring to when you[/color]
mention[color=blue]
> that problems may arise in multithreaded applications.[/color]

It's the standard one. Two threads call your function X::f(). Both see
that the static variable is not constructed. Then both go ahead and
construct it.

The solution is when one thread sees it is not constructed it blocks the
function memory so the other thread cannot do anything, the the first thread
constructs the object and releases the block, and the other thread then sees
the static variable is constructed. There is no native support for this in
C++. You have to use OS functions like critical section and mutexes. Even
if it works, the use of these OS functions is quite expensive. I'm not an
expert on multi-threading (still learning it myself), but those are the
basics.