[boost] Re: Re:Re:Re:PlatformNeutrality-withoutreinterpret_cast<>andifdef

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-08-06 11:18:01

At least consider separate headers for the win32 vs posix headers and put
the thread_group in the main thread.hpp that includes the implementation
specific ones. Or... have a _win32_thread_attributes.hpp that contains the
specific attributes of that platform, so they can be modified externally.
The check for which platform to include could be done either inside the
platform specific header, or outside--whichever is decided best. Personally
I think it would be cleaner to be done at the location of the implementation
to make the thread.hpp cleaner.

Current version:
private:
#if defined(BOOST_HAS_WINTHREADS)
    void* m_thread;
    unsigned int m_id;
#elif defined(BOOST_HAS_PTHREADS)
private:
    pthread_t m_thread;
#elif defined(BOOST_HAS_MPTASKS)
    MPQueueID m_pJoinQueueID;
    MPTaskID m_pTaskID;
#endif
    bool m_joinable;
};

In the clutter it apparently wasn't even noticed that an extra "private:"
was there.

----- Original Message -----
From: William E. Kempf
Newsgroups: gmane.comp.lib.boost.devel
Sent: Tuesday, 2002:August:06 10:07 AM
Subject: Re: Re:
Re:Re:Re:PlatformNeutrality-withoutreinterpret_cast<>andifdef

----- Original Message -----
From: "Glen Knowles" <gknowles_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, August 05, 2002 7:45 PM
Subject: RE: [boost] Re: Re:
Re:Re:PlatformNeutrality-withoutreinterpret_cast<>andifdef

> From: William E. Kempf [mailto:williamkempf_at_[hidden]]
> > In Eric's defense, the use of #ifdef's in Boost.Threads is generally not
> > done to "assist... deficient compiler(s)" but to provide platform
specific
> > implementations.  His argument is that there are other ways to do the
same
> > thing with more "clarity", but the problem is that this view is only an
> > opinion, and one that was strongly argued against by the majority of the
> > Boost membership (at least in regards to this specific library).  I have
> > sympathy for his opinion, if not with his presentation and even if I
find
> > the opinion of the majority to be more compelling.
>
> I'm not sure his suggested implementation was addressed. My understanding
is
>
> that he was advocating separate files for the implementations of, at
least,
> the major operating system "families". This would compile only the files
> required for a given platform, with the hope of needing much less #ifdef
> clutter. Not the pimpl idiom, unless you wanted to classify it as a
compile
> time pimpl. :)

It was a PIMPL idiom.  The implementation was entirely hidden from the
interface through the usage of a "pointer to implementation".  This means
dynamic allocation of the implementation class (whether it's a polymorphic
class or not), which is specifically what people disliked.  In fact, the
original code had a simpler variation on exactly what Eric posted.

// thread.hpp
namespace boost
{
class thread
{
// ...
private:
   class impl;
   impl* pimpl;
};
}

// thread_platform.inl
namespace boost
{
class thread::impl
{
// ...
};
}

// thread.cpp
#include <boost/thread.hpp>
#include <thread_platform.inl>

// ...

Even when I switched to conditional compilation I originally retained the
platform specific implementation files, and the main cpp file simply
#included these.  This kept the code a *little* more readable, but at a
large expense in maintainability.  I really don't think the current code has
any problems with clarity as the various implementations are usually clearly
separated into sections of the source file, rather then having the
conditional code in every function.  There are a few exceptions to this, but
when the exceptions occur it's for compelling reasons of maintainability.

Bill Kempf

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost