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 <[email protected]>wrote: > On Fri, Jan 11, 2013 at 7:05 PM, Lang Hames <[email protected]> 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 [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
