An Introduction to Boost

12:31 7 Jul '03

Thanks. Just wondering do you plan any more articles on this subject? I have been looking for an intro for BOOST for over a year because I can not understand the provided documentation. John
Sign In·View Thread·PermaLink

16:03 7 Jul '03

I'm more than willing to add to this article or write additional material, I don't claim to be a Boost expert, but I've been working with it for a little while. I think that most of the documentation is OK, but sometimes it can be a bit hard to find what you're looking for - the standard of documentation varies significantly across components.

What type of things were you looking for in particular? Any particular components?

5.00/5 (1 vote)

10:20 8 Jul '03

I was generally looking for more examples on how and where to use the library. I have looked into using boost code for a long time but when I read the examples I either don't understand what is happening or where someone would use it in a real world example. When I look at the pointers stuff. WOW there are so many types! I am not sure where to start. I use the smart pointer from the following article http://www.codeproject.com/cpp/smartptr.asp[^]

Does boost offer a better solution?

Also, is there any use for the threads library in a win32 application? To me it looks like you sacrifice performance and functionality for portability.

Thanks in advance,

John

5.00/5 (1 vote)

17:04 8 Jul '03

John M. Drescher wrote:
I use the smart pointer from the following article http://www.codeproject.com/cpp/smartptr.asp

Stefan Chekanov's SmartPointer that you've been using is just different to the Boost Smart Pointers.

boost::shared_ptr and boost::shared_array offer reference counting, similar to Chekanov's 'RefCountPtr', the boost approach to thread safety varies away from the design in Chekanov's work.

The number of classes involved with the Boost smart pointers is probably less than you would expect, they are just spread around in lots of header files.

I haven't worked with Chekanov's classes so the following comments are from the short look that I've just had.

1/ It is likely that the class will not be able to uphold an exception safety guarantee. I'm not going to cite a specific example, nothing was glaring obvious, but proving exception guarantees is hard, very hard.

2/ The constructor which accepts a SmartPtrBase, which can be used to convert pointer types is likely to be risky if used inappropriately to convert the types of pointers (threaded -> non-threaded), which could allow incorrect access to a resource.

3/ The Boost Smart pointers reference counts will be safe in the presence of threads, however they do not aquire criticle sections (see the CSyncAccessRep class) so the contained object will not be safeguarded in multiple threads. This is perhaps the biggest difference, if you decide to change Smart Pointer implementations.

4/ Parameterization: Chekanov states that to avoid having to supply additional template parameters he provides the additional classes. All of the boost smart pointers have been designed to only take a single parameter (the type of the pointer).
But Greg Colvin and Jerry Schwarz argued that "parameterization will discourage users", and in the end we choose to supply only the direct implementation
See: http://www.boost.org/libs/smart_ptr/smart_ptr.htm[^] for more information.
If you are looking for a full blown parameterization capable smart pointer, Loki (from 'Modern C++ Design' fame) has now received a large ammount of testing, and may be appropriate.

My personal opinion on smart pointers is that they are a must-have tool, but I'm only going to use something I know isn't going to fail in unexpected ways. Also, if I decide to change platforms, my code should require as little work as possible to port. Smart pointer code is one of the areas where I know that tiny changes can have a massive effect in the presence of exceptions, and proving that a solution is exception safe is a time consuming job. I'm willing to cede to the known experts in the field, Colvin, Abrahams, Dawes and Dimov along with all the other users and library writers that the boost smart pointers will 'just work' - no matter what.

17:10 8 Jul '03

Thanks for taking the time to write a very detailed reply... John
Sign In·View Thread·PermaLink

17:25 8 Jul '03

John M. Drescher wrote:
Also, is there any use for the threads library in a win32 application? To me it looks like you sacrifice performance and functionality for portability.

I'm not sure where functionality and performance losses could come from, but my knowledge of threading isn't the greatest. To me it looks like all the overhead is at construction / destruction of a thread object. I'm more than willing to trade that for being able to pass parameters into my function in a typesafe way (using function objects and binders), rather than attempting to cast void pointers.

I guess it's another example of 'adding an extra level of indirection' to solve a problem. If you can work easily with win32 threads then use that, it's the beauty of boost, you can pick and choose which bits you want,

8:02 25 Jul '03

How about Boost.function? Recently a article http://www.codeproject.com/cpp/CallbackDemo.asp[^] there was a suggestion to use Boost.function instead. I looked at the documentation and examples and have absolutly no idea about the usefulness of Boost.function and how I could use it to replace a callback mechanism. John
Sign In·View Thread·PermaLink

Boost Function (long)

Re: Boost Function (long)

19:47 25 Jul '03

John M. Drescher wrote:
Recently a article http://www.codeproject.com/cpp/CallbackDemo.asp

Just a couple of comments on that particular article:
- The way the sample app is written makes it relatively hard to see what callbacks are doing
- Big chunks of the code aren't type safe (void pointers) - big mental alarm bells start ringing in my head, getting all the louder when I see C-style casts.
- Some of the functions should really be using standard library elements, without even considering boost.

In the cases where you're writing the code, it's generally easiest to specify that anything with function call semantics is acceptable. The simplest way to do that is to templatize all of the functions. STL does this, that's why all the STL algorithms are templatized. Function objects in the standard are meant to be light-weight, so the types shouldn't really be significant. The consequence of that is that it's hard to exchange global functions for member function pointers.

The following code, which is a rewrite of the mentioned article's sample code uses boost::bind. If the callback does not support a conversion to a string type, the build will fail.

The basic idea to remember is that a callback (for a member function) needs to have two things: first an object pointer (or reference) and second the member function pointer. Binding like this allows you to attach the object to the member function pointer, in this case most if not all of this should be possible without using boost, by just using standard library elements (the second part of my response isn't). What makes boost bind/function/mem_fn outstanding in this area is that you can have any number of arguments.

#include <iostream>
#include <sstream>
#include <boost/bind.hpp>

using namespace std;

template<class T>
void globalCallback(T callback)
{
    ostringstream oss;
    oss << "From a global callback" << endl;
    callback(oss.str());
}

class Add
{
public:
    // generated ctor & dtor ok.

    template<class T>
    bool addNumbers(int num1, int num2, T callback)
    {
        ostringstream oss;
        oss << "Adding    " << num1 << " + " << num2 << " = " << (num1+num2) << endl;
        callback(oss.str());
        return true;
    }
};

class Multiply
{
public:
    // generated ctor & dtor ok.

    template<class T>
    bool multiplyNumbers(int num1, int num2, T callback)
    {
        ostringstream oss;
        oss << "Adding    " << num1 << " * " << num2 << " = " << (num1*num2) << endl;
        callback(oss.str());
        return true;
    }
};

class Test  
{
public:

    // generated ctor & dtor ok.

    void testStart()
    {
        cout << "Start" << endl;

        Add add;   // local instances
        Multiply multi;

        // -------------- Demo 1 : normal callback ----------------------
        cout << "\n> Setting CallbackOutputStars !\n";
        add.addNumbers       (120, 30, boost::bind(&Test::callbackOutputStars,this,_1));
	    multi.multiplyNumbers(3,   22, boost::bind(&Test::callbackOutputStars,this,_1));

        // -------------- Demo 2 : changing the callback ----------------
        cout << "\n> Setting CallbackOutputDollar !\n";
        add.addNumbers       (33, 66, boost::bind(&Test::callbackOutputStars,this,_1));
        multi.multiplyNumbers(5,  10, boost::bind(&Test::callbackOutputStars,this,_1));

        // -------------- Demo 3 : global callback ----------------------

        cout << ("\n> Finally the callback from a global function :\n");
        globalCallback(boost::bind(&Test::callbackOutputStars,this,_1));

        cout << "Done" << endl;
    }

private:
    void callbackOutputStars(const std::string& str)
    {
        ostringstream oss;
        oss << "  ***** Some stars *****  " << str << endl;
        cout << oss.str();
    }

    void callbackOutputDollar(const std::string& str)
    {
        ostringstream oss;
        oss << "  $$$ Now with Dollar $$$ " << str << endl;
        cout << oss.str();
    }
};

int main()
{
    Test t;
    t.testStart();
    return 0;
}

However, if you need a callback facility are you going to know the types involved? Most of the time the answer to that question is yes. [Slightly OT: As a student, that one concept took me months to get my head around, especially with so many templates whizzing around].

boost::function does this by letting you restrict the incoming types a bit better. Think of it as a flag to other programmers about what you are doing.


#include <boost/function.hpp> // added from the last sample
// changed from last sample
void globalCallback(boost::function1<void,std::string> callback)
{
    ostringstream oss;
    oss << "From a global callback" << endl;
    callback(oss.str());
}
// changed from last sample
class Add
{
public:
    // generated ctor & dtor ok.

    bool addNumbers(int num1, int num2, boost::function1<void,std::string> callback)
    {
        ostringstream oss;
        oss << "Adding    " << num1 << " + " << num2 << " = " << (num1+num2) << endl;
        callback(oss.str());
        return true;
    }
};
// changed from last sample
class Multiply
{
public:
    // generated ctor & dtor ok.

    bool multiplyNumbers(int num1, int num2, boost::function1<void,std::string> callback)
    {
        ostringstream oss;
        oss << "Adding    " << num1 << " * " << num2 << " = " << (num1*num2) << endl;
        callback(oss.str());
        return true;
    }
};

I built both samples under MSVC6, and noticed a degradation in compile time performance using boost::function.

19:53 25 Jul '03

Thank You very much for your time to write such a long and informative answer... John
Sign In·View Thread·PermaLink