[cfe-dev] Parser Stmt/Expr Owning Pointer

[Chris Lattner]

On Dec 9, 2008, at 1:53 AM, Sebastian Redl wrote:
>> 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.

Ok!

>>> 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.

Excellent, they are one of my favorite features of '0x.

>
>>
>> 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.

Fair enough.  C headers don't have this problem.
> 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.

Gosh you guys have anemic headers :).  Here's a dump of carbon.h on a  
leopard system with -E -P, it should work for you as a C parser test:

http://nondot.org/sabre/carbon.i.gz
and here's cocoa.h, an objc testcase:
http://nondot.org/sabre/Cocoa.mi.gz

>> +#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.

Ok!

Thanks again Sebastian!

-Chris