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

[Howard Hinnant]

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.

Howard

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:
> 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
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev