On May 23, 2010, at 11:24 AM, Douglas Gregor wrote: > > On May 23, 2010, at 10:38 AM, Fariborz Jahanian wrote: > >> >> On May 22, 2010, at 3:18 PM, John McCall wrote: >> >>> On May 22, 2010, at 9:13 AM, Fariborz Jahanian wrote: >>>> Wouldn't removing call to EmitFinalDestCopy change things in this >>>> patch? This routine deals with GC API, as well as copying result to >>>> DestPtr. >>> >>> Ugh, you're right. I believe I've restored the old behavior in a >>> way that doesn't interfere with return-value behavior in C++. >>> >>> I have no idea how to reconcile the GC API with C++; we'll have to >>> talk about this. >> >> Thanks. This was my main concern. This particular API was not being >> invoked for ObjC++ case, my concern was >> changing behavior for ObjC. > > > Perhaps we should use the GC API for a separate copy only when dealing with > POD types? Then we're only missing the GC calls for C++ types w/ interesting > special member functions.
The test I implemented was "a record type with a trivial copy constructor and a trivial destructor and which satisfies hasObjectMember()". The trivial copy constructor check will need to change for C++0x, but so will every call to hasTrivialCopyConstructor(), I think. Is there a document about the GC API anywhere? I'm sure it doesn't really consider ObjC++ at all, but I'd like to review the requirements anyway, just to see whether there's any earthly way we can support them in C++. John. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
