From owner-freebsd-ports@FreeBSD.ORG Thu Jul 19 13:21:29 2012 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D8C01065672; Thu, 19 Jul 2012 13:21:29 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id D99CC8FC14; Thu, 19 Jul 2012 13:21:28 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:10e7:52d2:303f:862c] (unknown [IPv6:2001:7b8:3a7:0:10e7:52d2:303f:862c]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 34F885C37; Thu, 19 Jul 2012 15:21:27 +0200 (CEST) Message-ID: <500809DA.1030301@FreeBSD.org> Date: Thu, 19 Jul 2012 15:21:30 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Jung-uk Kim References: <5006F780.2020004@FreeBSD.org> <44k3y1ndlp.fsf@be-well.ilk.org> <50073701.80205@FreeBSD.org> <500747F2.8010900@FreeBSD.org> In-Reply-To: <500747F2.8010900@FreeBSD.org> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org Subject: Re: [FYI] C++ compilers vs. __cplusplus (was Re: SV: Re: make failed for editors/libreoffice) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 13:21:29 -0000 On 2012-07-19 01:34, Jung-uk Kim wrote: > While I was tackling LibreOffice build issues, I found something > interesting about __cplusplus. Basically, different C++ compilers may > have different __cplusplus definitions and it may cause some > strangeness. Clang, for example, used to set it to 1 but now it is > set to C++ standard value since this commit: > > http://llvm.org/viewvc/llvm-project?view=rev&revision=156113 Yes, this is because gcc started doing the same. Otherwise it becomes rather difficult to distinguish C++98, C++0x and C++11 in your C++ library implementation (in the GNU case, libstdc++ most likely). ... > This causes very subtle issues depending on compiler versions and > FreeBSD versions. For example, NULL may be defined differently > because stable/9 and head have this: > > #if __cplusplus >= 201103L > #define NULL nullptr > #elif defined(__GNUG__) && defined(__GNUC__) && __GNUC__ >= 4 > #define NULL __null > #else > #if defined(__LP64__) > #define NULL (0L) > #else > #define NULL 0 > #endif /* __LP64__ */ > #endif /* __GNUG__ */ > > Before that, we had this: > > #if defined(__GNUG__) && defined(__GNUC__) && __GNUC__ >= 4 > #define NULL __null > #else > #if defined(__LP64__) > #define NULL (0L) > #else > #define NULL 0 > #endif /* __LP64__ */ > #endif /* __GNUG__ */ > > What a mess... Well, this is what you get when standards progress to include non-standard features (such as gcc's "__null") that are already in use, but then subtly change them (calling them "nullptr"). However, as long as you can hide the #ifdef ugliness in a header, I don't really see the problem. This won't be the last ugly definition either. :)