RE: [boost] Re: como toolset failures

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-04-26 16:12:25

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of John Maddock

> Actually it's defining BOOST_DISABLE_THREADS and 
> BOOST_DISABLE_WIN32 already, so scrub that request.  I 
> understand what you're saying about putting threading in the 
> another TU, but the point is that the code we're compiling 
> right now (this TU) can't include any threading API's (as far 
> as Boost is concerned anyway).

Is there any reason why we can't change all direct calls to Windows API
functions to calling convention thunks in another translation unit?  E.g.

// shared_ptr.hpp
#include "boost/windows/ccthunk.hpp"

windows::interlocked_increment(p);

// ccthunk.hpp
namespace windows {
    long interlocked_increment(long* volatile p);
}

// ccthunk.cpp
#include "windows.h"

namespace windows {
    long interlocked_increment(long* volatile p) {
        return InterlockedIncrement(p);
    }
}

We wouldn't to do this for the entire Win32 API, and it seems like an inversion
of principles to disable functionality on a compiler because it rejects
non-standard syntax (calling convention keywords).  Calling convention keywords
don't even fit into the C++ grammar (such information should properly be handled
by pragmas--whose explicit purpose is to pass extra-linguistic information or
instructions to the compiler).

Regards,
Paul Mensonides