Re: C++ in jemalloc

Today C++11 is a no-go generally due to the lagging architectures needing
gcc 4.2.

However, that answer might change soon. Would it be easy for you to avoid
C++11, or would that cause you significant pain? And what's the timeline
you'd be releasing a new jemalloc requiring this stuff? The answers might
change the 'no-go' to 'ok'.

Warner


On Thu, Oct 5, 2017 at 3:00 PM, David Goldblatt <davidtgoldblatt_at_gmail.com>
wrote:

> 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).
>
> - David
>
> On Thu, Oct 5, 2017 at 2:33 PM, Warner Losh <imp_at_bsdimp.com> wrote:
>
>>
>>
>> On Thu, Oct 5, 2017 at 2:24 PM, Ian Lepore <ian_at_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[1].
>>> > >
>>> > > 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
>>> > >
>>> > > [1] 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
>>
>
>