(apologies if you receive this twice; I subscribed to the list in order to flip the needs-moderation bit for my posts).
So it sounds like C++03 (or rather, the version of C++ supported by g++ 4.2) will be fine. Is C++11 a no-go, without breaking libc on non-Clang architectures? (It isn't clear to me if having to use the ports gcc to build was unfortunate or unacceptable from FreeBSD's POV). C++11 would be sort of helpful in the core implementation (we currently have to maintain our own backport of C11 atomics, for instance), but would be really helpful in the test suite (because of how much syntactically simpler it is to, say, spin up a bunch of threads to hammer a local instance of a data structure). On Thu, Oct 5, 2017 at 2:33 PM, Warner Losh <i...@bsdimp.com> wrote: > > > On Thu, Oct 5, 2017 at 2:24 PM, Ian Lepore <i...@freebsd.org> wrote: > >> On Thu, 2017-10-05 at 14:01 -0700, Warner Losh wrote: >> > On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt >> > wrote: >> > >> > > >> > > Hi all, >> > > >> > > The jemalloc developers have wanted to start using C++ for a while, to >> > > enable some targeted refactorings of code we have trouble maintaining >> due >> > > to brittleness or complexity (e.g. moving thousand line macro >> definitions >> > > to templates, changing the build->extract symbols->rebuild mangling >> scheme >> > > for internal symbols to one using C++ namespaces). We'd been holding >> off >> > > because we thought that FreeBSD base all had to compile on GCC 4.2, in >> > > order to support some esoteric architectures. >> > > >> > > The other day though, I noticed that there is some C++ shipping with >> > > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the >> HACKING >> > > document that C++11 is a minimum for FreeBSD 11). This, combined with >> the >> > > fact that ports now points to a modern gcc, makes me think we were >> > > incorrect, and can turn on C++ without breaking FreeBSD builds. >> > > >> > > Am I right? Will anything break if jemalloc needs a C++ compiler to >> build? >> > > We will of course not use exceptions, RTTI, global constructors, the >> C++ >> > > stdlib, or anything else that might affect C source or link >> compatibility. >> > > >> > > Thanks, >> > > David (on behalf of the jemalloc developers >> > > >> > >  That being said, we don't compile or test on those architectures, >> and >> > > so probably don't work there in the first place if I'm being honest. >> But >> > > we'd also like to avoid making that a permanent state of affairs that >> can't >> > > be changed. >> > > >> > For FreeBSD 10 and earlier, this would likely break all architectures >> that >> > aren't x86. Starting in FreeBSD 11, arm and powerpc are supported by >> clang, >> > but not super well. For FreeBSD 12, we're getting close for everything >> > except sparc64 (whose fate has not yet been finally decided). >> > >> > So for the popular architectures, this arrangement might work. For >> building >> > with external toolchains, it might also work. Some of the less popular >> > architectures may be a problem. >> > >> > Does that help? It isn't completely cut and dried, but it should be >> helpful >> > for you making a decision. >> > >> > Warner >> >> Wait a sec... we've been compiling C++ code with gcc 4.2 since like >> 2006. What am I missing here that keeps this answer from being a >> simple "go for it"? >> >> Just stay away from C++11 features and gcc 4.2 should work fine. (DTC >> may require C++11, but that was likely the author's choice given that >> there was no requirement for it to work on pre-clang versions of >> freebsd). >> > > It's the ubiquity of C++11 is why I didn't just say "Go for it". > > Warner > _______________________________________________ email@example.com mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"