From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 21:32:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA8837D1 for ; Tue, 12 Nov 2013 21:32:50 +0000 (UTC) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6909628B0 for ; Tue, 12 Nov 2013 21:32:50 +0000 (UTC) Received: by mail-qe0-f46.google.com with SMTP id s14so5960972qeb.5 for ; Tue, 12 Nov 2013 13:32:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=El4LoUFXBqqSPBtbStDcqZQFU6B2NvbjDol9vbOdyBs=; b=rUg4cAzpV2Gu/BYD/ZuMT1IEqFeb50bm/FO4+PoCO56sdPJhnIYm25C1teDkIL1Xs2 wm8KdGfQFCccturDcOr4qkPAIVl6Zs8JoqdsqlzdsE9UVG0LDtXtfKzxAc9vFRkHszEY fcS3cfPqmLxeArrQz1IFx3cPtgTvbyuCfrsyQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=El4LoUFXBqqSPBtbStDcqZQFU6B2NvbjDol9vbOdyBs=; b=ECqB8AGQzlkApZuEWN5wbpf6TUtHVvge/vGUH8r3WvZZ/b6ePJl76DZ+quziCKcM7n 7gTapph9KOhyo79ZQew7uIijKrDtPozPKT6QJtWSG4hnmzvXnLYtGAtAfGhiIBcceazC Lpm7JUWHuaWru3qDX5P1EWWourvc22Z8iO+69q98aYnbYROUfyb6xObBtzvmu4wb6E0+ iJZVZhbdvQfotZQqMHHiqBZH7dmIAxQlLvyG51N0YwcHo9Ay+RXHrGoLm+qxiRghUGYj YTpCkLI1nfEDsC38UNCwPovXL7kwkIvOBCqNawOwLCWniFBqYwppX/xCqeZ7b+v6qcE0 6OiQ== X-Gm-Message-State: ALoCoQlHxrnHaRTvuibF42y1O6e+xNbMcy/IL1u6N9r8ZsNG5Hxktpor36o2LXoxraT16Qviy0KG X-Received: by 10.229.41.130 with SMTP id o2mr17184098qce.20.1384291969594; Tue, 12 Nov 2013 13:32:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.63.101 with HTTP; Tue, 12 Nov 2013 13:32:19 -0800 (PST) In-Reply-To: <201311121321.07330.jhb@freebsd.org> References: <20131112163219.GA2834@troutmask.apl.washington.edu> <20131112165422.GA2939@troutmask.apl.washington.edu> <201311121321.07330.jhb@freebsd.org> From: Eitan Adler Date: Tue, 12 Nov 2013 16:32:19 -0500 Message-ID: Subject: Re: Are clang++ and libc++ compatible? To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current Current , David Chisnall , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 21:32:50 -0000 On Tue, Nov 12, 2013 at 1:21 PM, John Baldwin wrote: > On Tuesday, November 12, 2013 1:11:04 pm Eitan Adler wrote: >> On Tue, Nov 12, 2013 at 11:54 AM, Steve Kargl >> wrote: >> > On Tue, Nov 12, 2013 at 04:38:17PM +0000, David Chisnall wrote: >> >> On 12 Nov 2013, at 16:32, Steve Kargl > wrote: >> >> >> >>> Trying to build news/pan with clang++ dies with >> >>> >> >>> gmake[3]: Entering directory > `/usr/ports/news/pan/work/pan-0.139/pan/general' >> >>> CXX file-util.o >> >>> In file included from file-util.cc:38: >> >>> In file included from ./log.h:26: >> >>> /usr/include/c++/v1/deque:907:49: error: invalid application of 'sizeof' > to an >> >>> incomplete type 'value_type' (aka 'pan::Log::Entry') >> >>> static const difference_type __block_size = sizeof(value_type) < 256 > ? 4... >> >>> >> >>> Anyone know how to fix either clang++ or libc++? >> >> >> >> The error here does not appear to be in clang or libc++, but in the >> >> use by the thing that you are compiling. >> >> This is saying that you have tried to create a > std::dequeu, >> >> but pan::Log::Entry is a forward declaration and so the template >> >> instantiation fails. >> >> The fix is to move the definition of pan::Log::Entry such that it >> >> is visible at the time of its use. >> >> >> > >> > I don't know C++, but it is at all like C, then the header files >> > are normally placed at the top of a file before one's code. In >> > this case, the code in news/pan/work/pan-0.139/pan/general/log.h >> > looks like (where I've striped comment to keep it short) >> > >> > #ifndef __Log_h__ >> > #define __Log_h__ >> > >> > #include >> > #include >> > #include >> > #include >> > >> > namespace pan >> > { >> > class Log >> > { >> > public: >> > enum Severity { >> > PAN_SEVERITY_INFO = 1, >> > PAN_SEVERITY_ERROR = 2, >> > PAN_SEVERITY_URGENT = (1<<10) >> > }; >> > >> > struct Entry { >> > time_t date; >> > Severity severity; >> > std::deque messages; >> > std::string message; >> > bool is_child; >> > Entry() : is_child(false) { } >> > }; >> > >> > void add_entry(Entry& e, std::deque& list); >> > >> > >> > Are you saying that I need to move '#include ' to >> > the location above the 'void add_entry(...)' line? >> >> The problem here is that the code is trying to make a std::deque of >> the type Entry before Entry is fully defined. >> This is nearly identical to the problem in the simplified C code below: >> >> struct foo { >> struct foo bar; >> } > > Except it isn't. It's declaring the head of a container. This is more > like: > > struct foo { > TAILQ_HEAD(, foo) messages; > }; > > The problem is that unlike the queue macros (which are broken out into > chunks), the compiler has to instantiate all of std::deque<> even though > it will only use a portion of its definition. I understand why this is > a limitation of C++, but it's not quite as brain damaged as your > example. Yes, I'm aware of this difference. -- Eitan Adler