i strongly diagree with you i think one should strive to make his library open to as many users as it is possible, not only pro developers that is the scourge of modern software engineering (as i understand it) modern tools are so complicated that only very experienced programmers can handle it please don't make things worse than they are!
A lot of professional developers (and corporations) refuse to use boost because of the increased compile times in client code. Focusing on people who are not comfortable linking against other libraries (a pretty fundamental part of C/C++ development) to me focuses on the entirely wrong set of developers. Boost.Thread is a great example where there's no reason for it to be header only. Compare: #include <boost/thread/mutex.hpp> int main(int argc, char** argv) { } time /usr/bin/g++ -O3 test_thread_compile_time.cpp -o test_thread_compile_time real 0m0.492s user 0m0.420s sys 0m0.020s to the pthread equivalent (whose header includes far more than just mutices): #include <pthread.h> int main(int argc, char** argv) { } time /usr/bin/g++ -O3 test_pthread_compile_time.cpp -o test_pthread_compile_time real 0m0.091s user 0m0.020s sys 0m0.020s This is without even *using* anything from Boost.Thread, just including that one header -- it pulls in 227 other boost headers, 322 total. Changing that header to boost/thread/thread.hpp increases that time to ~0.9 seconds. The actual method of separation (pimpl, implementation in a library, etc.) doesn't matter, and in some cases it doesn't make sense, but it would be nice if there were a policy to try and keep compilation times for clients as low as is reasonably possible. Josh