Emil Dotchevski <emildotchevski@hotmail.com> writes:
OK. But that doesn't really address my initial point: implementing call_once> in terms of the POSIX pthread_once is a bit pointless if you need to implement> pthread_once separately anyway. If you don't have pthread_once, I would write> call_once (or, equivalently pthread_once2_np), and implement pthread_once in> terms of that.
Pthread is a C interface that has been implemented on many platforms already and I don't see why you think anyone would implement it over std::thread. It just won't happen.
****If you don't have Pthreads available*** it might make more sense to implement it in terms of the (more feature-rich) C++ API than vice-versa, if you need to write both.
On the other hand, if a particular platform implements pthread (virtually all do, and we have Windows port of pthread which is a proof of concept at least), implementing the C++ portion of N2178 is a breeze.
Yes.
Pthread is there, standardized, proven in practice, so why not make use of it? In addition, there is a lot of legacy pthread code which N2178 makes compatible with future C++ <thread> based code. I consider both to be Good Things.
If Pthreads is not available, then you can't make use of it. Having an implementation of <thread> based on <pthread.h> is a Good Thing. Being able to implement <thread> without <pthread.h> is also a Good Thing. If you don't have <pthread.h>, being able to implement <pthread.h> in terms of <thread> might also be a Good Thing --- if you want it, you have to write it somehow. Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL