[PATCH] allocateCopy() util for BumpPtrAllocator

[David Blaikie]

yep SFINAE'll do, I think - though I believe you can use "enable_if<x"
wherever you use "enable_if_c<x::value" as a minor convenience/shortening


On Mon, Jan 20, 2014 at 5:54 PM, Nick Kledzik <kledzik at apple.com> wrote:

> ping?
>
> On Jan 15, 2014, at 12:53 PM, Nick Kledzik <kledzik at apple.com> wrote:
>
> 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.
>>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140121/b52e83b4/attachment.html>