[PATCH] allocateCopy() util for BumpPtrAllocator

[Nick Kledzik]

Good point.  I conditionalized (enable_if_c<>) the templates to only work with POD types.  Updated patch:



-Nick

On Jan 15, 2014, at 11:46 AM, dblaikie at gmail.com wrote:
> I don't know enough about BumpPtrAllocator's design/intended use to know how well these new APIs fit - but both the templated forms are unsafe for non-trivial types (ArrayRef<std::string> for argument's sake) which is a bit scary - at least they could have some static assert/SFINAE/something to limit their use to safe cases if they aren't going to be generalized.
> 
> On Tue Jan 14 2014 at 1:32:28 PM, Nick Kledzik <kledzik at apple.com> wrote:
> It is easy to use BumPtrAllocator with placement-new to allocate and initialize a C++ object, but it is harder to allocate and copy other types with BumpPtrAllocator, such as StringRef.  I did not see any helper utils to do that, so I wrote this patch.  I added a few variations of allocateCopy() which each make allocating and copying different types easier.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140115/70b2b730/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BumpPtrAllocator2.patch
Type: application/octet-stream
Size: 1732 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140115/70b2b730/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140115/70b2b730/attachment-0001.html>