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

Mon Jan 2 06:00:34 PST 2012

According to standard n3242 about std::allocator<T> :

> 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<T>::shared_ptr(Y *p).

> template<class Y> 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 ?

> template<class _Tp> 
> template<class _Yp> 
> shared_ptr<_Tp>::shared_ptr(_Yp* __p) 
>     : __ptr_(__p)
> {
>     typedef std::remove_const<_Yp>::type _Ypi;
>     unique_ptr<_Ypi> __hold(__p);
>     typedef __shared_ptr_pointer<_Ypi*, default_delete<_Ypi>, allocator<_Ypi> > _CntrlBlk;
>     __cntrl_ = new _CntrlBlk(__p, default_delete<_Ypi>(), allocator<_Ypi>());
>     __hold.release();
>     __enable_weak_this(__p);
> }

On Jan 2, 2012, at 8:21 AM, redballoon36 at gmail.com wrote:

> (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
> 
> 
> 
> 
> _______________________________________________
> 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/279267ff/attachment.html>