David Abrahams wrote:
> I just discovered that a temporary cannot be bound to a const volatile
> reference (8.5.3/5). IOW,
>
> int f();
> int g(int const&);
> int h(int const volatile&);
>
> int x = g(f()); // ok
> int y = h(f()); // error
>
> I am baffled. It seems to me that holding a volatile reference to anything
> is always safe -- it just means (in the popular interpretation of the
> meaning of volatile, which is implementation-defined) that the compiler
> can't move the referenced value into a temporary and re-use it between
> function calls. In other words, marking the reference volatile places more
> restrictions on the callee, not fewer.
>
> So, does anyone know the reason for this rule?

The problem seems to be that 8.5.3 was written with the assumption that
anytime it's reasonable to allow a reference to be bounds to a temporary
it's also reasonable to allow that temporary to be created by an implicit
conversion.  It's certainly easy to get burned by an implicit conversion,
and that is something we don't want to do for volatile references (whether
const or nor).  For instance, suppose I have:

volatile const unsigned int status; // mapped to read-only hardware register

int f (const int &);
int g (volatile const int &);
int h (volatile const unsigned int &)

f(status);   // one gets a cached version of status w/o volatile semantics
g(status);   // Illegal, and should be -- would require making a copy
h(status);   // OK, bind directly to status w/volatile semantics respected

If I have a volatile reference parameter, I would expect the volatile
("do not copy") semantics to be respected, and allowing an implicit
conversion would defeat that.  So I sure don't want g(status) above to
be allowed.

Previous discussions on this forum have suggested that the rule against
binding temporaries to non-const references is not really what we want.
What we really want is a ban on implicit conversions creating temporaries
in such contexts.  Perhaps the same thing should be true for volatile
references.

heard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

I just discovered that a temporary cannot be bound to a const volatile
reference (8.5.3/5). IOW,

int f();
int g(int const&);
int h(int const volatile&);

int x = g(f()); // ok
int y = h(f()); // error

I am baffled. It seems to me that holding a volatile reference to anything
is always safe -- it just means (in the popular interpretation of the
meaning of volatile, which is implementation-defined) that the compiler
can't move the referenced value into a temporary and re-use it between
function calls. In other words, marking the reference volatile places more
restrictions on the callee, not fewer.

So, does anyone know the reason for this rule?

--
===================================================
  David Abrahams, C++ library designer for hire
 resume: http://users.rcn.com/abrahams/resume.html

        C++ Booster (http://www.boost.org)
          email: david.abrahams@rcn.com
===================================================



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]