const-ness in libc++ allocator

Hello,

I’ve encountered a compiler error using shared_ptr and allocator from the libc++ header . 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 should be allowed to exist.

A bit of background. This gets triggered when using:
std::shared_ptr ptr(new const int(4));
which also seems like a reasonable thing to do.

Thanks,
Paul O’Neil

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

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

(Howard: Sorry, I hadn’t meant to send that email just yet.)

I’m attempting to get Cinder (libcinder.org) to compile with libc++. It uses things like std::shared_ptr, which is returned const from CFDictionaryCreate(…). There’s no need to modify the resulting Dictionary (and they are immutable anyway?), so it makes sense to keep the value const. Thinking “aloud,” I could have a GUI element that uses a shared_ptr to reference a color from the user’s preferences in order to draw itself, that the GUI element shouldn’t ever modify, so the value should be const. This way, when the GUI dies, the shared_ptr does it thing and cleans up the color.

In terms of fixes, the thing that causes this is that a const type is passed into the shared_ptr. Removing the const where the shared_ptr instantiates the allocator should also fix this. Similarly the const-ness could be removed(cast/type_trait-ed) in the Cinder code, avoiding any changes to the library.

At this point, though, I’m arguing with the standard, so I lose for now. I’ll get you next time, C++!

Thanks,
Paul O’Neil

According to standard n3242 about std::allocator :

17.6.3.5 Allocator requirements [allocator.requirements]

T any non-const, non-reference object type

But, I haven’t seen any similar constness requirement with the faulty constructor template argument Y : shared_ptr::shared_ptr(Y *p).

template explicit shared_ptr(Y* p);
3 Requires: p shall be convertible to T*. Y shall be a complete type. The expression delete p shall be well formed, shall have well defined behavior, and shall not throw exceptions.
4 Effects: Constructs a shared_ptr object that owns the pointer p.
5 Postconditions: use_count() == 1 && get() == p.
6 Throws: bad_alloc, or an implementation-defined exception when a resource other than memory could not be obtained.
7 Exception safety: If an exception is thrown, delete p is called.

Is it acceptable to remove const from template argument ?

This is now looking like a libc++ bug. std::shared_ptr<const __CFDictionary> should work. And it does if you don't use make_shared<const __CFDictionary>(). make_shared<const __CFDictionary>() should also work. I will fix this. As a workaround, try:

   shared_ptr<const __CFDictionary> = make_shared<const __CFDictionary>();

Howard

Fix committed revision 147437.

Howard