Re: Are clang++ and libc++ compatible?

From: Shane Ambler <FreeBSD_at_ShaneWare.Biz>
Date: Wed, 13 Nov 2013 17:59:39 +1030
On 13/11/2013 07:49, Tijl Coosemans wrote:
> On Tue, 12 Nov 2013 12:19:22 -0800 Steve Kargl wrote:
>> On Tue, Nov 12, 2013 at 09:55:56AM -0800, Steve Kargl wrote:
>>> On Tue, Nov 12, 2013 at 06:37:39PM +0100, Dimitry Andric wrote:
>>>> On 12 Nov 2013, at 17:54, Steve Kargl <sgk_at_troutmask.apl.washington.edu> wrote:
>>>>>
>>>>>      struct Entry {
>>>>>        time_t date;
>>>>>        Severity severity;
>>>>>        std::deque<Entry> messages;
>>>>>        std::string message;
>>>>>        bool is_child;
>>>>>        Entry() : is_child(false) { }
>>>>>      };
>>>>
>>>> I think the problem is that the code tries to use std::deque<Entry> as a
>>>> member of struct Entry, before it is completely defined.  This is not
>>>> allowed by the standard, although some libraries (e.g. GNU libstdc++)
>>>> apparently permit it for some container types.

> There's a similar problem with graphics/blender.  There's a class
> TreeElement which links to its parent TreeElement like this:
> 
> std::map<std::string, TreeElement>::const_iterator parent;
> 
> Works with libstdc++, fails with libc++.  If the standard doesn't
> specify this it would still be a very convenient extension.
> 

A possible solution I found looking into this is to wrap the Entry
reference in a std::unique_ptr - so changing -
std::deque<Entry> messages;
to -
std::deque<std::unique_ptr<Entry>> messages;

This turns messages into a pointer so you need to change
messages.date into messages->date

This got blender compiling past that issue but I haven't got the rest
of it compiling to test that it runs.
Received on Wed Nov 13 2013 - 06:29:43 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:44 UTC