[cfe-dev] Doubts about constructor calls (and functional casts).

[Anders Carlsson]

On Mar 12, 2010, at 10:55 AM, John McCall wrote:

> 
> On Feb 27, 2010, at 12:06 AM, Enea Zaffanella wrote:
>> 
>> But then I get to the following case
>>    S s3 = S(3);
>> for which I get the following AST:
>> =============
>>  (DeclStmt 0x1d5f430 <line:8:3, col:14>
>>    0x1d5f1f0 "struct S s3 =
>>      (ImplicitCastExpr 0x1d5f3f0 <col:10, col:13> 'struct S' 
>> <ConstructorConversion>
>>        (CXXConstructExpr 0x1d5f380 <col:10, col:13> 'struct S''void 
>> (struct S const &)' elidable
>>          (ImplicitCastExpr 0x1d5f340 <col:10, col:13> 'struct S const' 
>> <NoOp>
>>            (CXXFunctionalCastExpr 0x1d5f300 <col:10, col:13> 'struct 
>> S' functional cast to struct S
>>              (CXXConstructExpr 0x1d5f290 <col:10, col:12> 'struct 
>> S''void (int)'
>>                (IntegerLiteral 0x1d5f250 <col:12> 'int' 3))))))"
>> =============
>> 
>> Here there are two things that I do not understand.
>> 
>> First, I cannot see why the result of the inner CXXConstructorExpr call 
>> should be fed to a CXXFunctionalCastExpr. I may agree that the 
>> initializer of s3 is a functional cast expression ... but then I would 
>> expect that the argument of this functional cast is the integer literal, 
>> not the struct S object returned by the constructor.
>> In other words, to my eyes, the presence of the functional cast should 
>> exclude the presence of the inner constructor call, or vice versa.
>> Is my reasoning missing some important point?
> 
> This is a strange representation, and it looks even stranger when the functional cast is actually invoking a user-defined conversion.  CodeGen aggressively elides the constructor calls (in most cases; I don't enough about that corner of the standard to know if it's missing legal elisions), so it's just an internal-representation issue rather than also being a performance issue.  Still, it's not a good representation, and if the elision optimization is disabled (which is a supported configuration, I think) it might mean we make too many copies.
> 

Actually, it's not that strange :)

The CXXFunctionalCastExpr is just the syntactical representation, and the inner CXXConstructExpr has all the constructor information - which constructor to call, default arguments etc.

Anders
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100312/014bbcb2/attachment.html>