Ping.
On Mon, Jan 14, 2013 at 10:35 AM, Lang Hames <lha...@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 <rich...@metafoo.co.uk>wrote: > >> On Fri, Jan 11, 2013 at 7:05 PM, Lang Hames <lha...@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@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
