12:18 < sbahra> how about you kick off an e-mail to me and we discuss over
e-mail?
12:18 < sbahra> Well, the real limitation is that testing overhead is high.
12:19 < sbahra> I was thinking, if we invest some time to automate a lot of
the testing then it would be feasible.
12:20 < sbahra> Right now on x86*, I test with clang, GCC and ICC. Then, I
test on the non-x86 targets across clang and gcc on the GCC compile farm.
12:20 < sbahra> If we add some simple glue to select the target hosts and
automate the run to also include g++ and augment regressions/ to include
some C++ test programs, it
should be manageable.
12:21 < sbahra> I just currently don’t have the time for this boilerplate
and I can’t justify my time on it because I don’t need C++ support.
However, with the above, it should
hopefully be a one-time cost for both of us and I can still
continue to support it as well.
12:23 < sbahra> Then what we can do is also specialize some facilities. So,
under C++, we can specialize things like ck_ring / etc… on a one-by-one
basis. ck_pr is fine to stay
(and there are still advantages to it over stdatomic).
12:25 < sbahra> It’s mostly opaque void pointer.
12:25 < sbahra> Flexible array members can be replaced by GNU extensions
such as 0-sized arrays, which will be supported by C++ compilers.
