Possible to pass address of anonymous variable?

Question

I use anonymous variables all the time, when I have no need of a named object hanging around for the entire present scope.

I need to work with a function - outside my control - that takes a pointer as an argument and does not NULL-check. I was hoping to be able to pass the address of an anonymous variable (because I don't care about the value written at the dereferenced address), but get hit with a compile error. The simplified example below...

#include <iostream>

void ptrFunc( const int* p )
{
  if ( p )
  {
    std::cout << "*p == " << *p << std::endl;
  }
}

void refFunc( const int& i )
{
  std::cout << "(ref)i == " << i << std::endl;
}

void valueFunc( int i )
{
  std::cout << "i == " << i << std::endl;
}

int main( int argc, char* argv[] )
{
  valueFunc( int() );   // This is fine.
  refFunc( int() );     // This is also fine.
  ptrFunc( &(int()) );  // This doesn't compile.
}

...generates this compile error:

>g++ -g main.cpp 
main.cpp: In function 'int main(int, char**)':
main.cpp:25:19: error: lvalue required as unary '&' operand
   ptrFunc( &(int()) );  // This doesn't compile.
                   ^
>g++ --version
g++ (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

The compiler error is pretty readable: an lvalue is required to use the address operator. But I'm wondering if the community can help me understand the rationale behind this restriction. It seems to me that my attempted use could reasonably be legal because the anonymous variable's lifetime is up to the semicolon, i.e. it is "alive" during ptrFunc()'s lifetime.

I considered whether it was considered "dangerous" to allow pointers to anonymous variables because of their shortened lifespan. But really any use if pointers - even for lvalues or heap-allocated objects is subject to the same problem: if someone is hanging onto any pointer, there's always the danger it could point to invalidated memory. Use of pointers is inherently dependent on careful coding, and I don't see this attempted use-case as especially different in that regard.

I'm curious to understand the rationale behind this. Thank you.

What else have I tried?

Tried compiling the example code with gcc-4.9.2 online to the same effect; so this issue is not a limitation/bug from an outdated compiler.

Answer 1

Ultimately what you're asking for here doesn't exist for good reason: A value with an address has to be located somewhere, and therefore have some scope/lifetime. The poiner you would be passing to a function is an address. It can be read from multiple times, and, when non-const, written to.

The compiler doesn't know how a calling function will use your parameters, and wants the freedom to put rvalues around, including folding them into constants in the code, or putting them in registers. You can't take an address to that and pass it to a function.

What you're asking for seems to reduce to compiler sugar that creates a local on the stack, takes a reference to it, and passes it to a function, but hides its address from the code so that no other code can use that value. C++ is built on explicit memory management, and thus is opposed to that.

Ok, but I really want to do this

Just for fun, though, I think you can do something like:

#include <memory>
#include <iostream>

void ptrFunc( const int* p )
{
  if ( p )
  {
    std::cout << "*p == " << *p << std::endl;
  }
}

int main()
{
  ptrFunc(std::unique_ptr<int>(new int()).get());
  return 0;
}

How does this work?

Awfully, in that it is very inefficient. Syntactically, it does what you want it to, though:

ptrFunc(                 // 1. call ptrFunc
  std::unique_ptr<int>(  // 2. instantiate a unique_ptr as a temporary
                         //    this takes a pointer to a heap-allocated value
                         //    and assumes ownership of it. it deletes that
                         //    value when it goes out of scope. for a
                         //    temporary, this happens after the expression.
    new int()            // 3. heap-allocate an integer
  ).get()                // 4. returns a raw-pointer to the heap-allocated
                         //    value owned by the unique_ptr. That value
                         //    becomes invalid memory if accessed after the
                         //    unique_ptr destroys it.
);

Answer 2

But I'm wondering if the community can help me understand the rationale behind this restriction. It seems to me that my attempted use could reasonably be legal because the anonymous variable's lifetime is up to the semicolon, i.e. it is "alive" during ptrFunc()'s lifetime.

In this case, yes, it would work. In general, no.

References cause the temporary's lifetime to be extended. Pointers don't. That is, given:

int main() {
    const int & a = 1;
    int && b = 2;
    const int * c = &static_cast<const int &>(3); // don't do this
    return a + b - *c;
}

the references a and b continue to refer to valid objects. The pointer c does not, and there is no reasonable way the lifetime extension rules could work for pointers without a significant fundamental change in what pointers are. It's doable for references because references are a new (compared to C) language feature, and as a new language feature, there was no problem making them immutable. Pointers have a lot of existing code using them that would be invalidated by a change in the rules.

Answer 3

C++11 introduces std::addressof() to get the address of a variable, even if it is a class type that overrides operator&. You could apply a similar technique to get the address of a temporary variable, eg:

template <class T>
const T* addrtemp(const T& arg)     
{    
    return reinterpret_cast<T*>(    
        &const_cast<char&>(    
            reinterpret_cast<const volatile char&>(arg)
        )
    );    
}

ptrFunc( addrtemp(int()) );

Demo