[llvm] r206372 - [Allocator] Make BumpPtrAllocator movable and move assignable.

Duncan P. N. Exon Smith dexonsmith at apple.com
Sun Apr 27 19:23:52 PDT 2014

On 2014 Apr 18, at 13:59, David Blaikie <dblaikie at gmail.com> wrote:

> On Fri, Apr 18, 2014 at 1:43 PM, Chandler Carruth <chandlerc at gmail.com> wrote:
>> On Thu, Apr 17, 2014 at 7:04 AM, Duncan Exon Smith <dexonsmith at apple.com>
>> wrote:
>>> The existence of a move constructor without a corresponding explicit copy
>>> constructor seems sufficiently explicit of a marker for "move only" to me.
>>> I think it looks more like an accident, not a marker.
>>> I prefer Stroustrup's advice [1] on this.  It's not practical to follow
>>> all the time in this project because of MSVC support (no sense explicitly
>>> defining a default definition move constructor by hand if it's not going to
>>> be used anyway), but the style still makes sense to me when it's possible.
>>> It's cheap, and makes it clear that the omission is intentional.
>>> [1]: http://www.stroustrup.com/C++11FAQ.html#default2
>>> Do you disagree strongly?
>> I dunno about strongly, but it feels all wrong to me.
>> It feels like needless boilerplate, and I have a real allergy to
>> boilerplate. I suppose my real fear is that if programmers were to follow
>> this pattern consistently it would become a burden. At that point, they will
>> just stamp out the boiler plate using a macro or a some template in an IDE
>> or whatever, and they still won't think about it so we won't have solved
>> anything.
>> My preference is rule of zero, and minimally adding the routines you need.
>> This trusts the language to always DTRT when you add the subset, but I think
>> the language gets this right here.
>> /me continues to ponder.
> FWIW I agree with Chandler here - by only implementing the minimal set
> of members needed and trusting the language/compiler to do the right
> thing we're in a better place.
> Boilerplate is not not just visual noise for readers but can actually
> hurt us: should a type one day become copyable (when it was previously
> movable) then all types that have it as a member would need to be
> updated.

This is compelling.

Nevertheless, I bet many developers would be surprised that a patch
deleting a move constructor implicitly adds a copy constructor.

> Though I agree that it takes some effort to kick the "Rule of 3(5)"
> habit and trust the compiler - but we can all help each other to get
> there.

We're not just trusting the compiler; we're also trusting the (imperfect)
knowledge of developers.  I think the "rule of 5" is about making the
otherwise murky details of an API clear to current and future developers.

I'll think about this some more though.

More information about the llvm-commits mailing list