Re: [boost] Re: Re: Singleton

From: Martin Slater (mslater_at_[hidden])
Date: 2005-01-13 07:02:19

> To mirror another message I sent regarding aligned_storage, I like the 
> idea of making this library a part of boost, but I don't like the idea 
> of having countless dependencies upon boost.  

Just going to jump out from lurk mode for a second here, hope you don't 
mind me butting in;)  I really don't get what the problem with 
dependencies on boost is. The whole point of boost as I see it is a big 
repository of well developed and proven portable code, subverting this 
just brings all the associated maintenence problems of having 
effectively duplicated code. If someone installs the boost libraries 
they have no problems with dependencies as they have all the applicable 
code. If you want fine grained control for people who really do not want 
/ have space for additional boost libraries being linked in then 
specifying a preprocessor directive at build time would seem 
appropriate.  I would expect a boost library to support the other boost 
libraries as well out of the box if natural to do so, I would not like 
at all having to write extra code to get a multi-thread safe singleton.

I don't know about gcc but I do know the vc dead code optimiser is very 
good and aggressive (far too much so under certain circumstances, just 
to check at the end is a small test) so linking to a library where most 
code is unused just doesn't bother me, maybe someone else can say how 
good gcc and metrowerks are in this respect.  And anyway whats few k 
between friends these days for good solid and reliable code;)  Maybe I'm 
missing some other reason to avoid the dependancy?

Anyhow just my 2 aussie cents, thanks for the work your putting in, I 
would love to see this enter boost.

cheers

martin

------------------------------------------------------------------

Code is at bottom, the difference with vc is only 12k from a 923k 
library on disk using the boost policy and nothing at all if the policy 
isn't used but the library is still linked. It just doesn't seem worth 
putting any effort into avoiding boost (threads at least) if executable 
size is a problem.

Results
--------
(vc7.1)
thread lib size                    : 923kb
no boost at all                    : 76kb
boost policy defined but not used  : 76kb
boost policy defined and used      : 88kb

(mingw-1.32.0rc1 - gcc 3.4.2)
thread lib size                    : 335kb
no boost at all                    : 474,875kb
boost policy defined but not used  : 474,875kb
boost policy defined and used      : 527,569kb

-------------------------------------------------------------------
#define BOOST_LIB_DIAGNOSTIC
#define USE_BOOST
#define DEFINE_BOOST_BUT_DONT_USE

#include <iostream>

#ifdef USE_BOOST
#include <boost/thread/mutex.hpp>
#endif

template<class LockType, class LockerType>
struct LockerTraits {
    typedef LockType   Lock;
    typedef LockerType Locker;
};

struct NullLocker { NullLocker(int) {} };

typedef LockerTraits<int, NullLocker> NullLockPolicy;

#if defined(USE_BOOST) && !defined(DEFINE_BOOST_BUT_DONT_USE)
typedef LockerTraits<boost::mutex, boost::mutex::scoped_lock> 
BoostLockPolicy;
#endif

template<class Locker>
struct Fish {
    void print()
    {
        typename Locker::Locker lock(m_lock);

        std::cout << "hello" << std::endl;
    }

    typename Locker::Lock m_lock;
};

int main(int argc, char* argv[])
{
#if defined(USE_BOOST) && !defined(DEFINE_BOOST_BUT_DONT_USE)
    Fish<BoostLockPolicy> fishy;
#else
    Fish<NullLockPolicy>  fishy;
#endif

    fishy.print();

    return 0;
}