[cfe-dev] const-ness in libc++ allocator

[redballoon36 at gmail.com]

Thanks for the response.

Yes, that compiles.  Is there a reason that keeping the const doesn't work?
 Given that you say this isn't allowed, why is it a bad idea?  The
shared_ptr provided by boost takes this.

I did some more digging in the Buzilla (I had only searched open bugs
before), and found this one: http://llvm.org/bugs/show_bug.cgi?id=8421 .
 It looks like the same thing, but in std::map instead. Also since emailing
the list, I tried it in Visual Studio 2010 and it compiled without errors.
 However, I have no idea how to work Visual Studio, so some the settings
may have been very different.

Thanks again,
Paul O'Neil

On Sun, Jan 1, 2012 at 8:12 PM, David Keller <david.keller at litchis.fr>wrote:

> Hi,
>
> You may write:
>
> std::shared_ptr<const int> ptr(new int(4));
>
>
> Regards
>
> On Dec 30, 2011, at 1:29 AM, redballoon36 at gmail.com wrote:
>
> Hello,
>
> I've encountered a compiler error using shared_ptr and allocator from the
> libc++ header <memory>.  I'm running OS X 10.7.2, and I first noticed this
> while using the libc++ implementation with Xcode 4.2.1, though I believe
> this still exists in svn 147357.
>
> The problem is caused by instantiating std::allocator<> (in the memory
> header) with a const type.  This causes the pointer and const_pointer types
> to be the same, which results in methods using these to have the same
> signatures, which gives a compiler error (as it should, given that methods
> are colliding).  Is this supposed to happen? I haven't read the standard,
> but it seems like it should work, that is, that std::allocator<const int>
> should be allowed to exist.
>
> A bit of background. This gets triggered when using:
> std::shared_ptr<const int> ptr(new const int(4));
> which also seems like a reasonable thing to do.
>
> Thanks,
> Paul O'Neil
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120101/7d2abd90/attachment.html>