[cfe-dev] libstdc++ Windows port

[Howard Hinnant]

We currently have both include/support/win32 and src/support/win32.  I would imagine a continuation of that strategy.  I would also recommend porting <chrono> first (the clocks) so that the pieces of threading that depend on timing fall into place.

Howard

On Mar 8, 2012, at 10:14 AM, Matthew Faithfull wrote:

> 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
>> 
>>