[cfe-commits] [PATCH] Smarter implicit copy-construction/copy-assignment.

Richard Smith richard at metafoo.co.uk
Thu Jan 24 17:27:20 PST 2013


Some style issues:
 * use ' &', not '& '.
 * for new code, please consistently start function names in lowercase

Generally, this needs more testcases, including both positive and
negative tests (for ObjC types, atomic types, volatile, ...).

On Thu, Jan 24, 2013 at 5:18 PM, Lang Hames <lhames at gmail.com> wrote:
> Ping.
>
>
> On Mon, Jan 14, 2013 at 10:35 AM, Lang Hames <lhames at gmail.com> wrote:
>>
>> I think this applies equally to default move operators, I just hadn't done
>> enough homework to be sure yet.
>>
>> - Lang.
>>
>>
>> On Fri, Jan 11, 2013 at 7:20 PM, Richard Smith <richard at metafoo.co.uk>
>> wrote:
>>>
>>> On Fri, Jan 11, 2013 at 7:05 PM, Lang Hames <lhames at gmail.com> wrote:
>>>>
>>>> At present, if a class contains any Non-POD members we perform
>>>> element-wise copies for each field when generating the implicit
>>>> copy-constructor and implicit copy-assignment operator (with an optimization
>>>> for array members).
>>>>
>>>> This patch changes this behavior - adjacent POD members will be
>>>> memcpy'd, with Non-POD members output as usual.
>>>>
>>>> This is an initial implementation that I'd like to get in tree. Obvious
>>>> deficiencies are:
>>>>
>>>> It punts entirely when LangOpts.getGC != None.
>>>> It doesn't handle inner classes/unions.
>>>> It doesn't attach any TBAA info, even when all members are the same
>>>> type.
>>>> It isn't particularly smart about when it falls back on element-wise
>>>> copies (at the moment it emits a memcpy any time it finds more than one POD
>>>> field).
>>>>
>>>> These should all be easy to test and remedy once the code's in tree
>>>> though.
>>>>
>>>> Does anybody see any problems with this?
>>>> Style comments?
>>>>
>>>> Feedback much appreciated.
>>>
>>>
>>> This generally seems reasonable to me, but I've not looked at the patch
>>> in detail. Any reason not to apply this to move assignment operators too?
>>>
>>> Do you handle bitfields? See r151963 for an example of that.
>>
>>
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>



More information about the cfe-commits mailing list