- Boost - lists.boost.org

program_options: compilation fixes
by Graham Bennett 12 Jan '05

12 Jan '05

Hi, parsers.cpp and value_semantic.cpp in 1.32.0 both use 'tolower' without including <cctype>, which on my platform is not included as a side-effect of one of the other headers. I have attached patches which make it compile cleanly for me. Thanks, Graham. -- Graham Bennett

2 1

[serialization] and filesystem::path
by Russell Hind 12 Jan '05

12 Jan '05

Are there plans to add serialization support to filesystem::path? Thannks Russell

1 0

lambda problem (VC7.0 and GNU Dev-C++)
by Sergey Pisarchik 12 Jan '05

12 Jan '05

Hello All, Problem is: what the difference between "type" in such cases? 1) class type{}; and 2) class type1{}; typedef type1 type; I think, they are equal. But... look code. ///////////////////////////////////// //// Begin of code ///////////////////////////////////// #include <boost\mpl\apply.hpp> #include <boost\mpl\lambda.hpp> #include <boost\mpl\placeholders.hpp> namespace mpl = boost::mpl; struct CClass{ void Init(int& i){i--;};}; namespace impl { template<typename TBase> struct CClass0:public TBase { public: void Init(int& i){i--; TBase::Init(i);}; }; template<typename TBase> struct CClass1:public TBase { public: void Init(int& i){i--; TBase::Init(i);} ;}; } typedef mpl::lambda<impl::CClass0<mpl::_> >::type CClass0; typedef mpl::lambda<impl::CClass1<mpl::_> >::type CClass1; template <typename T1, typename T2> struct CMetaFunction1 { struct type1: public mpl::apply<T1, T2>::type{}; typedef type1 type; }; template <typename T1, typename T2> struct CMetaFunction2 { struct type: public mpl::apply<T1, T2>::type{}; }; class CBase { CBase(void) { { CMetaFunction1<CClass1, CMetaFunction1<CClass0, CClass>::type >::type g; int i=5; g.Init(i); } { CMetaFunction2<CClass1, CMetaFunction2<CClass0, CClass>::type >::type g; int i=5; g.Init(i); } } }; /////////////////////////////////////////////// end of code ////////////////////////////////////////////// Explanation: Want impl::CClass1<impl::CClass0<CClass> >; and running g.Init(); CClass1::Init(); CClass0::Init(); CClass::Init(); using CMetaFunction1 everything is OK. but CMetaFunction2 gives CClass0::Init(); CClass::Init(); WHY ??? Tested on VC++7.0 and GNU Dev-C++ P.S. when use my own lamda function Both variants works OK. /////////////////////////////////////////////// template <template <typename> class TBase> struct lambda { template <typename T> struct apply { typedef TBase<T> type; }; }; typedef lambda<impl::CClass0> CClass0; typedef lambda<impl::CClass1> CClass1; /////////////////////////////////////////////// --Sincerely Yours,-- --\ SergeY /-- --<>\\\ PisarchiK ///<>-- --<>()<>--Never surrendeR--<>()<>-- mailto:Sergey_pisarchiK@tut.by

2 1

Re:Singleton
by Dave Handley 12 Jan '05

12 Jan '05

Jody Hagins wrote: > Umm... not trying to start a war or anything, but please do not do > that. Personally, I do not like the threading policy of shared_ptr. I > use it, but I really do not like it. In general, the Boost preference > seems to be compiled code is either multithread enabled or not (i.e., > object are different sizes based on compile time macros). > > In my experience, I have found making the thread policy an actual policy > (similar to how ACE does it) better. It allows me to compile/link > different policies, depending on how they are used. > > For example, if I have a multi-threaded application, Boost classes > require me to use all multithreaded support. However, my main thread > may be tight, and use shared_ptr objects that do not span multiple > threads. In that case, I'd like to use something like shared_ptr< Foo, > Noop_Lock_Policy > for stuff I know is OK without locking... > This is precisely what I was describing for the way that Loki does it. Basically every class can support threading or not via its policy. I agree that this is more flexible and preferable in many circumstances to the boost.shared_ptr method. Dave Handley

1 0

improved version of compiler_status.cpp uploaded to the new vault
by Robert Ramey 12 Jan '05

12 Jan '05

I've added to the vault an enhanced versionof the Boost compiler_status.cpp file. It is named compiler_status2.cpp. The original version creates a table showing one row for each test and one column for each compiler. When there are several results for each compiler such as debug, release, different variants, etc, the only the "first" set of results is displayed. This version displays ALL results for each compiler. The included example shows part of the testing done for the serialization library. In all other respects it is identical to the orginal program. Robert Ramey

1 0

Re: boost.test covered in testing frameworks rundown
by Noel Llopis 12 Jan '05

12 Jan '05

Gennadiy Rozental wrote: > Boost.Test does support fixtures. At least in a sense author using this > term. Noel found proper thread in mailing list to refer, but made > completely wrong conclusion from it. To implement fixtures one needs to > use constructor and destructor *for fixture*. Thanks for pointing that out, Gennadiy. After so many years of using NUnit setup/teardown, I was missing the obvious way of doing the same thing in C++. I've updated the article to reflect that fixtures are perfectly possible with Boost.Test. http://www.gamesfromwithin.com/articles/0412/000061.html With that, Boot.Test definitely makes it to my list of finalists. The only two drawbacks I see are the reliance of some of the other Boost libraries (it would be ideal if something this low level could be fully self-contained), and the verbosity needed to create suites. Cheers. --Noel Games from Within http://www.gamesfromwithin.com

5 11

Wike hacked again
by Robert Ramey 12 Jan '05

12 Jan '05

The wiki has been hacked again. Robert Ramey

3 2

Boost Thread - Read Write Mutex Problem
by David Brownell 11 Jan '05

11 Jan '05

When running the simple program listed below, the scoped_read_lock appears to never acquire a read lock on the mutex and, as a result, the program never finishes. In looking through the documentation, I don't think there is anything additional I need to do and was a bit surprised that this didn't work. Here is the code: boost::read_write_mutex m(static_cast<boost::read_write_scheduling_policy::read_write_scheduling_pol icy_enum>(alternating_many_reads)); std::cout << "Before\n"; { boost::read_write_mutex::scoped_write_lock l(m); } std::cout << "Middle\n"; { boost::read_write_mutex::scoped_read_lock l(m); } std::cout << "After\n"; And some more details: - Windows XP SP2 - Microsoft Visual Studio 2003 - I am compiling with the Multithreaded DLL version of the CRT, so boost_thread-vc71-mt-gd-1_32.lib is being used - test_read_write_mutex.cpp completed without problems - writer_priority and reader_priority completed without problems. Only alternating_many_reads and alternating_single_read seem to have problems. Thanks for your help! David Brownell

3 2

Fxns as io::filters
by christopher diggins 11 Jan '05

11 Jan '05

I mentioned in an earlier response to JT that I have written a function to filter adapter. The entire code is now online at http://www.cdiggins.com/iostreams_fxn_filters.hpp I can't help but wonder if the syntax for chaining streams to filters shouldn't be cin >> fxn_filter(fxn) >> cout; instead of cin | fxn_filter(fxn) | cout; Anyone have any thoughts on the subject? Would anyone else, other than me, like to see this functionality added to iostreams? - Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

3 2

Singleton
by CHAOS 11 Jan '05

11 Jan '05

This post refers to the following code: http://www.ezequal.com/chaos/libs/singleton.h I have developed a templated singleton class which enforces almost every rule of the singleton pattern at compile time. This library provides a very clean, flexible format for client code to implement its own singleton classes which may have dependencies on each other. I have three questions. Does it make any sense to use a template allocator parameter, like the standard container types, to control creation and destruction of my instance, or are new and delete sufficient? Is there any other functionality that should be added? Specifically, is it sufficient to enforce that singletons are created in a specific order before main and destroyed in the reverse order after main (using dependency instances), or should I provide some way to support alternate lifetimes (ex: create on first reference to instance)? Is there any interest in adding this library to Boost?

5 7