[cfe-commits] r59502 - in /cfe/trunk: Driver/ include/clang/Analysis/ include/clang/Analysis/PathSensitive/ include/clang/Basic/ include/clang/Driver/ lib/Analysis/ lib/Basic/ lib/CodeGen/ lib/Driver/ lib/Lex/ lib/Parse/ lib/Sema/
Sebastian Redl
sebastian.redl at getdesigned.at
Tue Nov 18 00:46:15 PST 2008
Chris Lattner wrote:
> This is a somewhat tricky dance, but it means that the
> accumulated DiagnosticInfo is allowed to keep pointers to other expression
> temporaries without those pointers getting invalidated.
>
Are you sure? If the DiagnosticInfo is constructed earlier than the
other temporaries, wouldn't it be destroyed *after* them?
Look at this short example I've written, which is similar in mechanism
to your code:
#include <iostream>
struct Sink
{
bool hadInput;
Sink() : hadInput(false) {}
~Sink() { if(hadInput) std::cerr << "Sink with input
destructing\n"; }
template <typename T>
Sink& operator << (const T&) { hadInput = true; return *this; }
};
struct Sentry
{
~Sentry() { std::cerr << "Sentry destructing\n"; }
};
Sink makeSink()
{
return Sink();
}
int main()
{
makeSink() << Sentry();
}
It does the right thing on my compiler, but is this guaranteed? It also
creates the Sentry object before calling makeSink, and that's not
something to be relied on if Sentry is a heavy object.
> We will soon be able to just do:
>
> Diag(BuiltinLoc, diag::err_overload_no_match)
> << typeNames << SourceRange(BuiltinLoc, RParenLoc));
>
> This scales better to support arbitrary types being passed in (not just
> strings) in a type-safe way. Go operator overloading?!
>
This is great.
Sebastian
More information about the cfe-commits
mailing list