[cfe-dev] const-ness in libc++ allocator
hhinnant at apple.com
Sun Jan 1 19:35:52 PST 2012
The C11++ std says that std::allocator<T> contains both of these members:
pointer address(reference x) const noexcept;
const_pointer address(const_reference x) const noexcept;
And when T is const, these two members result in a double declaration of the same member. So according to the standard, std::allocator<const T> isn't supposed to work.
But let's explore beyond that.
What is your use case for needing to do so? Perhaps if it is motivating, and there is no easy workaround, libc++ could support it as an extension.
On Jan 1, 2012, at 10:01 PM, redballoon36 at gmail.com wrote:
> 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:
> You may write:
>> std::shared_ptr<const int> ptr(new int(4));
> On Dec 30, 2011, at 1:29 AM, redballoon36 at gmail.com wrote:
>> 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.
>> Paul O'Neil
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
More information about the cfe-dev