[boost] Re: What I Hate About How We Abstract System Dependence

From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2005-03-07 03:48:22

> "Aaron W. LaFramboise" <aaronrabiddog51_at_[hidden]> wrote in message
>news:422BAE65.4090608_at_aaronwl.com...
> Over the past few years, the style of our abstract interfaces for
> system-dependent features has bothered me more and more.  Here’s my
> challenge to those happy with the status quo: Find me an interface in
> Boost or the C++ standard that represents an observable inter-program
> interface, such that, for any popular operating system, I can’t find a
> feature of the operating system that is impossible to express using that
> interface without relying on undefined behavior, undocumented behavior,
> or circumventing access specifiers.

[...]

> So here’s my question to the Boost community.  How many people have
> similar concerns and experiences?  How often, in real code, do concrete
> classes prove insufficient?  Who here has to entirely reimplement
> libraries like Boost.Threads for relatively silly reasons?  Are there
> any alternate solutions for the problem I describe?  What unforeseen
> problems might there be with this polymorphic style?  Would you use a
> library such as Boost.Thread if it had been rewritten in this manner?

I'd guess that most people using e.g. Boost.Thread (and have been using 
native threads previously) feel limited by the exposed interface. There's 
still "nothing" you can't do by getting to the current native thread 
handle/id and using the native API to do what you wan't to do - providing 
that you are willing to put in some additional work and/or drop portability 
in your code.

That aside, I've had similar thoughts myself, but I was more into CT 
polymorphism (using policy classes to expose additional functionality). Some 
pseudo-code would be:

template<typename T>
class portable_threading_api {
...
};

template<typename T>
class win32_threading_api {
public:
  bool exit_thread(DWORD errorCode) // make virtual?
  {
    return (FALSE != 
::TerminateThread(static_cast<T*>(this)->native_thread_handle(), 
errorCode));
  }
  int set_thread_priority(...);
};

template<typename T>
class posix_threading_api {
...
};

template<typename ThreadingApi = portable_threading_api>
class thread
 : public ThreadingApi<thread>
{
...
};

---
Using the above, people wanting to write portable code could limit 
themselves to use thread<>, people needing additional Win32-specific 
functionality could use thread<win32_threading_api>, etc. As more features 
were portably implemented, people could move from platform-specific to 
portable implementations (if they would like to).
Just some additional food for thought.
Regards,
Johan