[cfe-dev] Parser Stmt/Expr Owning Pointer

[Sebastian Redl]

Chris Lattner wrote:
>
> On Dec 8, 2008, at 3:42 PM, Sebastian Redl wrote:
>
>> Chris Lattner wrote:
>>>
>>> On Dec 7, 2008, at 8:29 AM, Sebastian Redl wrote:
>>>
>>>> The move emulation of this pointer is specialized to support 
>>>> backwards compatibility. The ASTMove class, core of the move 
>>>> emulation, cannot only be implicitly converted to a new ASTOwner 
>>>> (which will take ownership), but also to an ActionResult or a void 
>>>> pointer, which also have ownership. This allows the use of move() 
>>>> in many contexts, such as returning an ASTOwner where an 
>>>> ActionResult is expected, or passing a void* to the Action by 
>>>> calling move(). This is a significant advantage in making the use 
>>>> of the smart pointer intuitive: move() is used whenever you give up 
>>>> ownership, no matter what receives it.
>>>
>>> In terms of API, can we have a better name than .move() ?  From the 
>>> API perspective, seeing:
>>> +      return Idx.move();
>>> is really strange.
>>>
>>> How about .take(), as in "take ownership"?
>> I prefer move() over take() for two reasons:
>> 1) It is more consistent with the name std::move(), which is what 
>> moving will inevitably be called in C++0x.
>> 2) take() is loaded with the semantics of llvm::OwningPtr; although 
>> the function in question has equivalent semantics in general, there 
>> are some subtle differences.
>
> The similarity with owningptr was why I liked it :), what subtle 
> differences do you see?
The main difference is what Howard pointed out: move() doesn't 
immediately give up ownership, but only when someone subsequently takes it.
>
>> I personally don't find move() strange at all, but then I've been 
>> preoccupied with move semantics and their emulation since I learned 
>> of the concept two years ago. (Note: with proper C++0x moving, 
>> there'll be no need to call move() anymore. However, due to the 
>> reference binding rules of C++03, the only way to achieve this is to 
>> allow the highly unsafe practice of moving from const references.)
>
> Yep yep, rvalue refs are very nice.  Unfortunately we probably can't 
> actually *use* them in llvm/clang until they are widely deployed in 
> vendor compilers.  :(  It sucks to have to write portable code.
Fortunately, rvalue references are the first thing any compiler 
implements from C++0x, apparently. GCC 4.3+ supports them, CodeWarrior 
supports them, Visual Studio 2010 supports them. They will definitely be 
the first thing that can be used portably.
>
> Ok, just give a head's up when you commit and someone else can test 
> before/after your change.  If C++ support were farther along, you 
> could just #include <iostream> or something, which is a somewhat 
> decent metric.
I'm not so sure about that. I think the parser time might well be 
drowned out by the template instantiation time. <iostream> instantiates 
a lot of templates: the iostream hierarchy (3 classes, plus members), 
the streambuf hierarchy (2 classes), locales (lots of facet templates), 
and who knows what else. We'd need the extern template extension, anyway.

I'm on a Linux system. Surely there must be some huge system headers out 
there. But in my search, I can't find anything. A combination of gtk.h, 
ncurses.h and WINE's windows.h merely yields 2.6 MB.
>
> +#include "AstGuard.h"
>
> Is "AstGuard.h" going to be renamed at some point?
Yes. In fact, it's probably going to be removed, because the smart 
pointers will move out of Parser-private into Parser-interface.

Sebastian