On Monday 02 April 2007 17:41, Jeff Garland wrote:
Sohail Somani wrote:
Its just not good practice and I suspect a non-empty subset of new boost users are also new to C++.
5 years ago I believed it was a serious issue too -- I've substantially changed my mind. And not in small part by using asio (and other boost libs) as header only. It's extremely nice to not need to figure out how to build and link. You can get started with so trivially with an all header library -- and I think that frequently it's trouble getting over that first hump that stops people from using libs. So if the barrier is lower more people will use the libs.
I'd just like to second this aspect. I know that my first attempts at getting Boost.Thread to work were fruitless, because the behaviour and complexity of the build-system were so intimidating and frustrating that I simply gave up. I guess that many think so, at least I have had a lot of discussions that went into that direction on the Usenet. Now, what I did here was to create an additional file that can be included as "boost/thread/inplace_link.cpp". All that this file does is #include the sourcefiles from lib/thread/src. Now, in order to use threads, all you need to do is to include this file into exactly one translation unit, that's it. Really, that is all! Apart from static linking, this has an additional advantage: ABI independence. If you have a bunch of C++ compilers on your machine, you need just as many SOs/DLLs, which all have to be built. Using GCC, those don't even have different names, so there is no way to use different ones alongside. Considering STLport, it can at least be distinguished from the native one, but STLport 5.1 is not binary compatible with STLport 5.0, so the problems remain. Note: I haven't tried it on MS Windows yet (only on vanilla Debian/Linux/x86), but I guess that due to the dllexport/dllimport stuff, you might have to set a switch so that static linking takes place, at least for the inplace-linked Boost libs. The reason is that otherwise the symbols get decorated with dllimport attributes which we don't want, since we are linking in place. I don't remember, what was the default link type there? If it is static, we are all set. Also, I used to call this 'inplace-link', but 'inplace-compile' would be more suitable. Further, note that this does not replace the existing mechanisms for dynamic or static linking but enhances them. If you want, you can still use dynamic or static precompiled libs, but otherwise it significantly lowers the entry barrier by skipping any precompilation requirement. Uli