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 <s...@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.

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to