471,066 Members | 1,349 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,066 software developers and data experts.

volatile

Why need to qualify a member function "volatile"?

Why need to qualify a object "volatile"?

When need to "const_cast" away "volatile" of an object and a member
function?

I also saw some code of a function argument of "volatile" type. What's the
purpose there?
class vClass
{
void foo() volatile {}
void boo(){}
};

int main()
{
volatile vClass v;

v.foo(); //no problem
v.boo(); //compile error
...
}

Thanks for your help!

Jul 19 '05 #1
4 7773
newsock wrote:
Why need to qualify a member function "volatile"?
Volatile is an attribute that precludes the compiler from making false
optimizations.

Consider this code.

int i = 0;

void thead1_func()
{
i = 1;
}

void thread2_func()
{
while ( ! i )
{
// wait for i to change
// oops - compiler optimizes
// reads to i away because ...
// nothing in this loop changes
// memory
}
}
However if we had declared

volatile int i = 0;

.... then the compiler would not be free to make this optimization.

Volatile is also heavily used in drivers because values of memory mapped
registers may change on their own !

Why need to qualify a object "volatile"?
When the state of the object may change when a different thread changes
it's contents.

When need to "const_cast" away "volatile" of an object and a member
function?
When you know that the object's state can't change without the current
thread making the change.

I also saw some code of a function argument of "volatile" type. What's the
purpose there?
class vClass
{
void foo() volatile {}
void boo(){}
};
I remember running into this once and I punted on it so I don't know for
sure but I suspect that it is similar to const in behaviour i.e. member
functions that may cause or depend on volatile behaviour are by
definition volatile and hence the object is volatile. But it's only a
guess.


int main()
{
volatile vClass v;

v.foo(); //no problem
v.boo(); //compile error
...
}

Jul 19 '05 #2
"newsock" <ne*****@hotmail.com> writes:
Why need to qualify a member function "volatile"?
It has a similar effect to declaring a member function "const":
The "this" pointer will point to a "volatile"-qualified equivalent
of the class type.
Why need to qualify a object "volatile"?
It forces the object's value to actually be checked each and
every time it is read. For example, in the following:

int foo = 2;

std::cout << foo;

A compiler would be well within its rights to optimize the second
line to:

std::cout << 2;

Since it knows that foo was not changed from its initial value
before the output. However, if it were declared:

volatile int foo = 2;

std::cout << foo;

The volatile keyword says that foo may be changed by some
mechanism *outside* of the program, so the compiler had better
double-check the value of foo before deciding to output it to
std::cout.

This is mainly useful if the is registered somehow by address
with an external process/thread, or in code such as the
following:

volatile int *foo = reinterpret_cast<int *>( 0x01f0 );
*foo = 2;
std::cout << *foo;

In the above example, foo is now a pointer to volatile int, whose
location is a hard-coded value that perhaps has some special
meaning in the system for which this particular program was
written: it might be that this value is mapped to (say) the
number of milliseconds this process has been running; or maybe
it's a pixel in video memory. Your program doesn't "know" this,
but it does know that this is a "special" int, and it should
assume that its value may have changed while it wasn't paying
attention.
When need to "const_cast" away "volatile" of an object and a member
function?
It's never needed; but provided that you were *sure* that an
object really isn't going to be changed on the sly, you could
cast it away for a potential efficiency boost.
I also saw some code of a function argument of "volatile" type. What's the
purpose there?
Are you sure? It has no purpose there: it is thrown out (as is
const). However, a parameter with a type *derived* from a
volatile type (say, pointer-to-volatile-something-or-other) could
be significant.
class vClass
{
void foo() volatile {}
void boo(){}
};

int main()
{
volatile vClass v;

v.foo(); //no problem
v.boo(); //compile error
Right. Same reason why it would fail if you changed the instances
of "volatile" in this snippet to "const": "this" points to a
volatile vClass, but boo() doesn't "accept" a volatile "this"; a
compiler would typically compile boo() with optimizations that
don't require that members of vClass (had they existed) be
checked for on-the-sly changes, which would not be acceptable for
instances that have been declared with the "volatile" qualifier.
Thanks for your help!


No prob!

--
Micah J. Cowan
mi***@cowan.name
Jul 19 '05 #3

Gianni Mariani wrote: ....

"plonk."

regards,
alexander.
Jul 19 '05 #4
Alexander Terekhov <te******@web.de> writes:
Gianni Mariani wrote: ....

"plonk."
Why? I saw nothing in Gianni's post that merited kill-filing.
regards,


(Did you really mean that? ;-) )

--
Micah J. Cowan
mi***@cowan.name
Jul 19 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

8 posts views Thread by Tim Rentsch | last post: by
14 posts views Thread by Ian Pilcher | last post: by
14 posts views Thread by google-newsgroups | last post: by
17 posts views Thread by dingoatemydonut | last post: by
18 posts views Thread by Mark | last post: by
94 posts views Thread by Samuel R. Neff | last post: by
3 posts views Thread by Rakesh Kumar | last post: by
10 posts views Thread by S James S Stapleton | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.