[cfe-dev] GCC's "Temporaries May Vanish Before You Expect"

[Jordan Rose]

On Sep 12, 2012, at 16:27 , David Blaikie <dblaikie at gmail.com> wrote:

> On Wed, Sep 12, 2012 at 4:10 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>> The thing that keeps me from removing it is that it IS more convenient and it CAN be made safe. The first way is to use C++11 to forbid the use of this function on rvalues; that looks like this:
>> 
>>  template<class T> const T *getAs() const && = delete;
>>  template<class T> const T *getAs() const & {
>>    return dyn_cast<T>(this);
>>  }
> 
> Indeed, my thoughts precisely. [I wonder at what point it'll be worth
> moving default development to C++11 and just keeping some bots around
> for C++98 back compat testing.]
> 
>> This could be hidden behind a compatibility macro:
>> 
>>  template<class T> const T *getAs() const LLVM_RVALUE_DELETE;
>>  template<class T> const T *getAs() const LLVM_LVALUE {
>>    return dyn_cast<T>(this);
>>  }
> 
> What do you envision those macros being defined to in C++98? Wouldn't
> you end up with errors relating to redeclaration of class members if
> they expanded to nothing in C++98 builds.

I guess I should have tried it first. I forgot you can't redeclare class members. :-(


> Seems to me, unfortunately, like we'd have to #ifdef the extra
> declaration entirely, or put the declaration inside a function-like
> macro if possible, etc)

Yes, that leaves something ugly like this:

LLVM_LVALUE_ONLY(template<class T> const T *getAs() const) {
}

…and I don't even know how that would handle multiple template arguments. Bleah.


>> The second way is if -fcatch-undefined-behavior could be augmented to handle this case. I have no idea how to do this, though -- perhaps it requires something ASan-ish to poison the temporary memory once its lifetime ends.
>> 
>> Any chance of either of these happening on trunk?
> 
> +Richard Smith for the undefined behavior checking possibilities.