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

[redballoon36 at gmail.com]

(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<const __CFDictionary>, 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

On Mon, Jan 2, 2012 at 1:55 AM, Paul O'Neil <redballoon36 at gmail.com> wrote:

>  I'm attempting to get Cinder (libcinder.org) to compile with libc++.  It
> uses a std::shared_ptr<const __CFDictionary>, which is returned from
> CFDictionaryCreate(...).
>
> On Sun, Jan 1, 2012 at 10:35 PM, Howard Hinnant <hhinnant at apple.com>wrote:
>
>> 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
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120102/a1bbde50/attachment.html>