strange grammar about volatile and operator overload
George
The following code,
[Code]
operator const Outer::Inner * volatile & ();
[/Code]
1.
I think it means an operator &, which returns const Inner* type and takes no
arguments, right?
2.
Adding volatile to return value means?
(I previously only used volatile to qualify variable)
thanks in advance,
George
Kenneth Porter
news:6BA301AE-0A31-449D...@microsoft.com:
> Adding volatile to return value means?
That the resulting pointer must be dereferenced each time it is used, and
the result can't be assumed to remain the same over time. Something outside
the program (eg. an interrupt or another process) is changing its value. So
the dereference can't be moved out of a loop by the optimizer.
Ulrich Eckhardt
> The following code,
>
> [Code]
> operator const Outer::Inner * volatile & ();
> [/Code]
>
> 1.
>
> I think it means an operator &, which returns const Inner* type and takes
> no arguments, right?
No, this is a conversion operator. Everything between the 'operator' and
the '()' is the type that the class in who's context this stands can be
implicitly converted to.
The '&' operator is always a binary operator, so either it is written as
return_type operator&( param_type p1);
in the context of a class (plus possible const or volatile overloads) or as
return_type operator&( param_type1 p1, param_type2 p2);
as a free function. Obviously, in both cases it can be overloaded for
different types and the parameters can be references, too.
Uli
Igor Tandetnik
news:qvi375-...@satorlaser.homedns.org
> The '&' operator is always a binary operator
No. '&' could also mean address-of, which is a unary operator. You can
overload this one, too. E.g. ATL does on a few occasions.
Of course, the name of such a function would still be operator&, not
operator blah blah &. The latter can only possibly be a conversion
operator (assuming "blah blah" names a type).
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
Igor Tandetnik
news:6BA301AE-0A31-449D...@microsoft.com
> [Code]
> operator const Outer::Inner * volatile & ();
> [/Code]
>
> takes no arguments, right?
No, it's a user-defined conversion operator, converting an instance of a
class it's a member of to the type
const Outer::Inner * volatile &
The latter is a reference to a volatile pointer to const Outer::Inner
> Adding volatile to return value means?
Note that here, it's not the return value itself that's volatile. The
return value is a reference, and what it refers to is what's volatile.
Erik Wikström
Hello again George, I do not know if it is deliberate but you are still
posting your questions in comp.langa.c++ and microsoft.public.win32.
programmer.kernel as well as in this group. What I do know is that you
never rely in any of those other groups which leads me to think that you
do not read them.You said last time that you would update some bookmarks
in IE, have you done so yet?
Do not get me wrong, we do not mind your questions as long as they are
topical (though sometimes they are not) but it feels kind of wasteful to
write a reply if you are not even reading it.
--
Erik Wikström
George
> > Adding volatile to return value means?
>
> Note that here, it's not the return value itself that's volatile. The
> return value is a reference, and what it refers to is what's volatile.
A little confusion here. I can understand what means the binded object of
the reference is volatile.
But I am not sure whether volatile is consistent to the reference binded
object. For example, the operator conversion function returns reference to
some global object and it is marked as volatile now, but actually in the
definition/declaration of the global object, it is not marked as volatile. I
am not sure about whether I have made myself understood about the volatile
consistent issue.
Any comments? Is it an issue or just make the global variable in my sample
more restrictive (volatile is more restrictive than non-volatile)?
regards,
George
George
> No. '&' could also mean address-of, which is a unary operator. You can
> overload this one, too. E.g. ATL does on a few occasions.
>
> Of course, the name of such a function would still be operator&, not
> operator blah blah &. The latter can only possibly be a conversion
> operator (assuming "blah blah" names a type).
I have the same confusion before.
regards,
George
George
> That the resulting pointer must be dereferenced each time it is used, and
> the result can't be assumed to remain the same over time. Something outside
> the program (eg. an interrupt or another process) is changing its value. So
> the dereference can't be moved out of a loop by the optimizer.
You mean the content pointed by the pointer is treated as volatile, not the
pointer itself -- from grammar point of view, the pointer itself is marked as
volatile.
regards,
George
George
Thanks for your reminder. For a couple of weeks, I either post to here or
post to kernel forum (like working set issue) -- but not both. Because I have
been told cross posting is not good.
regards,
George
Igor Tandetnik
> But I am not sure whether volatile is consistent to the reference
> binded object. For example, the operator conversion function returns
> reference to some global object and it is marked as volatile now, but
> actually in the definition/declaration of the global object, it is
> not marked as volatile.
That's perfectly OK. Just as you can have a reference-to-const bound to
an object that wasn't declared const:
int x;
const int& cr = x; // OK
volatile int& vr = x; // also OK
When x is accessed directly, it's not treated as volatile or const. When
x is accessed via vr reference, it's treated as volatile (meaning
certain compiler optimizations are suppressed). When x is accessed via
cr reference, it's treated as const (meaning you can read the value but
can't change it).
> I am not sure about whether I have made
> myself understood about the volatile consistent issue.
No, not really.
> Any comments? Is it an issue
Is what an issue?
> or just make the global variable in my
> sample more restrictive (volatile is more restrictive than
> non-volatile)?
Yes, volatile is more restrictive.
George
My question is answered.
regards,
George
Kenneth Porter
news:8B4162B6-D549-40C0...@microsoft.com:
> You mean the content pointed by the pointer is treated as volatile,
> not the pointer itself -- from grammar point of view, the pointer
> itself is marked as volatile.
Sounds reasonable. I didn't analyze the return type, and tend to use chains
of typedefs for complicated type expressions like that to make clear which
part of the expression a given qualifier applies to.
Kenneth Porter
news:55E71E3E-8B44-4E35...@microsoft.com:
> Thanks for your reminder. For a couple of weeks, I either post to here
> or post to kernel forum (like working set issue) -- but not both.
> Because I have been told cross posting is not good.
http://en.wikipedia.org/wiki/Crossposting
http://oakroadsystems.com/genl/unice.htm#xpost
Crossposting is not bad, and in fact serves an important purpose, but it
can be abused. Multiposting is bad, but that's something different.
Alas, there are some who use brain-damaged newsgroup readers that re-show a
crossposted message in every group it was posted to, instead of only
presenting it once, and these people object to crossposting based on the
limitations of their client.
George
> and tend to use chains
> of typedefs for complicated type expressions like that to make clear which
> part of the expression a given qualifier applies to.
Sounds interesting. But I do not quite catch the exact trick you showed
here. Could you provide more information about how to use your trick here or
post some pseudo code please?
regards,
George
Bo Persson
> Hi Kenneth,
>
>
>> and tend to use chains
>> of typedefs for complicated type expressions like that to make
>> clear which part of the expression a given qualifier applies to.
>
> Sounds interesting. But I do not quite catch the exact trick you
> showed here. Could you provide more information about how to use
> your trick here or post some pseudo code please?
>
The thing is that in real code, you never end up with anything even
close to
>> [Code]
>> operator const Outer::Inner * volatile & ();
>> [/Code]
It will be
operator sometype&();
where sometype is defined in a typedef. Possibly using something else
from an earlier typedef.
Now we just have to figure out what use we can possibly have for a
volatile pointer to a const object of a nested class. And why the heck
we need some object implicitly convertible to a reference to such an
animal? Never happens!
Bo Persson
Erik Wikström
> "Erik Wikström" wrote:
>
>> OT:
>>
>> Hello again George, I do not know if it is deliberate but you are still
>> posting your questions in comp.langa.c++ and microsoft.public.win32.
>> programmer.kernel as well as in this group. What I do know is that you
>> never rely in any of those other groups which leads me to think that you
>> do not read them.You said last time that you would update some bookmarks
>> in IE, have you done so yet?
>>
>> Do not get me wrong, we do not mind your questions as long as they are
>> topical (though sometimes they are not) but it feels kind of wasteful to
>> write a reply if you are not even reading it.
>
>
> Thanks for your reminder. For a couple of weeks, I either post to
> here or post to kernel forum (like working set issue) -- but not
> both. Because I have been told cross posting is not good.
I guess you have a dedicated fan then, who posts all topics you start in
c.l.c++ too. A quick check shows that all new topics you have started in
either ms.p.vc.language or ms.p.w.p.kernel are also posted in c.l.c++,
though this time from a google groups account.
--
Erik Wikström
George
Generally speaking, what is the function of return a volatile reference?
Each time we need to re-read the reference binded object or?
regards,
George
Igor Tandetnik
> Generally speaking, what is the function of return a volatile
> reference?
There ain't no such thing as a volatile reference. The reference itself
is implicitly const - once bound, it cannot be rebound, it always refers
to the same object.
The object the reference is bound to may be volatile though. As usual,
it means the compiler cannot, say, cache its value in the register but
has to read the value of the object from memory every time the program
accesses it; other similar optimizations are also suppressed.
George
Cool! My question is answered.
regards,
George