"Aaron W. LaFramboise" <aaronrabiddog51@aaronwl.com> wrote in message news:422BAE65.4090608@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