[cfe-dev] libstdc++ Windows port

[Matthew Faithfull]

Yes I do mean,

libc++ (http://libcxx.llvm.org/)?

I got pinged for calling it libstdcxx in a previous post due to 
confusion with the old Apache project. I'll get it right eventually :-)

I agree that a Windows implementation relying on pthreads does not look 
like a good idea so we need an implementation of C++11 <thread> etc on 
top of the Windows API.
How would you see this sitting within the libc++ project structure. It 
would be a rather large lump of platform specific code, without a 
current precedent. Would a seperate Windows C++11 concurrency library be 
preferable?

Matthew F.

On 08/03/2012 15:00, Howard Hinnant wrote:
> On Mar 8, 2012, at 9:28 AM, Matthew Faithfull wrote:
>
>> Can anyone fill me in on the status of pthreads dependency in stdc++. As
>> far as I can tell the current situation is as follows:-
>> The libstdc++ Windows port uses MinGW, MinGW doesn't have pthreads
>> support out of the box, so do we need a special MinGW?
>> The obvious alternative, installing 'pthreads for Windows', doesn't work
>> due to that project being out of date (2006) and the fundamental types
>> being incompatible. for example pthread_t is a struct under ptw32 and a
>> pointer under OSX.
>> Using the OSX pthreads header(s) may enable compilation to complete ( I
>> haven't tried it ) but would then need a new OSX ABI compatible port of
>> pthreads to Windows in order to work. Is this in the works or are there
>> other plans afoot to get around the issue?
>> A full new Windows port of pthreads is by my very approximate reckoning
>> a minimum 3 months full time work so I'm not about to jump in if it
>> isn't going to be useful.
> Do you mean libc++ (http://libcxx.llvm.org/)?
>
> My recommendation would be to map the C++11<thread>/<condition_variable>/<mutex>  to the native Windows API as closely as possible, rather than go through the additional pthreads abstraction layer.
>
> Howard
>
>