On Tuesday 24 February 2015 10:54:16 Keane, Erich wrote: > The idea of the extra layer of abstraction would be to make for an extremely > simple implementation, rather than trying to re-invent the wheel (making > ANOTHER custom mutex wrapper).
I understand the concern of reinventing the wheel. However, there's a reason everyone does it and we have that reason affecting us. If you can find a simple, existing implementation of this wrapper we could use by including into our source code, we should go for it. But I'd rather avoid linking to another library (GLib, APR, etc.) for it if that's all we need from that library. If we're going to use GLib, then we should also consider using gslice, its data structures, etc. On ALL platforms. > As far as dropping support for the C++11 Standard Library, I'm not sure I > agree. It provides some really great functionality, is available on all of > our listed target systems (QNX is not on that list AFAIK), and are well > performing. QNX is not on that list, but it's a reasonable target. I'm being realistic: if we want to broaden our support base, we should consider those targets. We're already discarding the widely deployed QNX 6.5 because the GCC it uses is too old (4.4). We're restricting to QNX 6.6. Another device that should be on our target list is Windows Embedded Compact 7, for which the only compiler available is Visual Studio 2008, which supports no C++11 at all. Think also of Red Hat Enterprise Linux 6 systems in the cloud. They come with GCC 4.4.7. All those systems will have to restrict themselves to the C SDK only. Therefore, std::mutex is out of the question for the C SDK. > Additionally, the clang C++ Standard Library has better licensing if an OEM > cares enough. It's not an acceptable solution if they have existing C++ libraries they need to interface with and cannot recompile. My position remains: we should reduce our dependency on the C++11 Standard Library, not increase it. > The alternative is to either A: write our own versions (very error prone and > a waste of time), or B: use Boost's versions, which come with additional > concerns. For this kind of functionality -- simple wrappers -- I doubt that error-prone is going to be a problem. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
