Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 Jul 2012 15:21:30 +0200
From:      Dimitry Andric <dim@FreeBSD.org>
To:        Jung-uk Kim <jkim@FreeBSD.org>
Cc:        freebsd-ports@freebsd.org
Subject:   Re: [FYI] C++ compilers vs. __cplusplus (was Re: SV: Re: make failed for editors/libreoffice)
Message-ID:  <500809DA.1030301@FreeBSD.org>
In-Reply-To: <500747F2.8010900@FreeBSD.org>
References:  <vyh5gfyc7ro596rvdbv95tih.1342623265060@email.android.com> <5006F780.2020004@FreeBSD.org> <44k3y1ndlp.fsf@be-well.ilk.org> <50073701.80205@FreeBSD.org> <500747F2.8010900@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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. :)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?500809DA.1030301>