May 2005 - Boost - lists.preview.boost.org

Logging Library over Iostreams? (was Logging Library -- Formal Review Request)
by Brian Braatz 05 May '05

05 May '05

> On Behalf Of Darryl Green > Hi John, > > John Torjo <john.lists <at> torjo.com> writes: > > > > > I've seen that some of you have requested "levels", and yes, I should > > add them. I hope I'll have time to implement them soon (less than a > month). > > However, > it probably isn't general or clean enough an interface, and this could > be addressed by providing a concept something like the following, to > replace the (not customisable at present) logger_impl. > > struct sink > { > void write(const log_types::stream &s); > bool enabled(log_types::level l); > }; > > The rest of the interface (actual type) is log_manager defined. > A sink with the current semantics + level support implemented by extending > the enabled flag to be a level (something you previously talked me out of, > but [Brian Braatz Writes:] This thread is making me contemplate, Why not make this logging library a well designed bolt on to IOSTREAMS? I LOVE IOSTREAMS, and it seems like if the logging library is (DESIGNED TO BE) an add on to that I get the best of both worlds.

2 1

[thread] warnings with CW 8.3
by Bertolt Mildner 05 May '05

05 May '05

when building boost.thread (from public CVS / HEAD) with CW 8.3 i get the following warnings: ... cw-C++-action ..\..\..\bin\boost\libs\thread\build\libboost_thread.lib\cw\debug\ threading-multi\read_write_mutex.obj ### mwcc Compiler: # File: ..\src\read_write_mutex.cpp # ------------------------------------ # 934: } # Warning: ^ # return value expected ### mwcc Compiler: # 1163: } # Warning: ^ # return value expected ### mwcc Compiler: # 1247: if (woken = do_wake_all_readers()) # Warning: ^ # possible unwanted assignment ### mwcc Compiler: # 1253: if (woken = do_wake_writer()) # Warning: ^ # possible unwanted assignment ... Bertolt

2 4

Using tuples::tie with BOOST_FOREACH
by Joe Gottman 04 May '05

04 May '05

I just discovered a very nice interaction between the BOOST_FOREACH and boost::tuples::tie. Suppose we have a container (such as std::map or std::multimap) whose values are pairs or tuples. If we want to iterate through the keys and values of a map, we can predeclare separate variables for the key and value, then use boost::tuples::tie in the first parameter of BOOST_FOREACH to initialize them separately. See the below code: -----begin code #include <iostream> #include <map> #include <string> #include <boost/tuple/tuple.hpp> #include <boost/foreach.hpp> int main() { std::map<int, std::string> theMap; theMap[1] = "hello"; theMap[2] = "world"; int key; std::string value; BOOST_FOREACH(boost::tuples::tie(key, value), theMap) { std::cout << key << " => " << value << "\n"; } return 0; } ------ end code This code produces the following output: 1 => hello 2 => world It would be nice if I could declare key and value inside the loop, but I don't think this is possible. Incidentally, if it's not too late I'd like to vote to ACCEPT BOOST_FOREACH into boost. I use Perl a lot, and use the Perl foreach loop more than twice as often as the C-style for loop. Joe Gottman

2 1

RE: [boost] Factory library new version
by Robert Geiman 04 May '05

04 May '05

---- Original Message ---- From: f.stella(a)flashnet.it To: boost(a)lists.boost.org Subject: RE: [boost] Factory library new version Date: Wed, 4 May 2005 02:57:19 +0200 >I've uploaded a new version for factory library [1] whit these >changes: >o Added some tutorial on library use. >o Ported 3 example from Rob Geiman's object factory. >o More documentation. >o Fixed some bugs. >o Now uses boost directory structure. >o Big architectural changes. >o Boost.Singleton is now optional. > >I've checked the object factory from Rob Geiman and I think the main >differences between implementations are that mine could use an >allocator I actually re-worked my object factory class to allow STL allocators to be used for the allocation policy, but I haven't finished it/posted it to the vault because the initial response I got when I introduced my object factory was very limited. >and call any constructors without limiting to just one. Variable number of constructor parameters is quite nice! However, there is another difference between our two implementations. Mine is specifically made to register classes dynamically during runtime by calling the register() function of the factory object, while yours appears (and please correct me if I'm wrong) to be done via compile time. In other words, to add a derived3 class you must actually edit the boost::factory typedef to specifiy derived3 in the mpl::vector. >Rob's library >has >an allocation policy but it embed even "creation" policy so changing >the >policy requires writing the some same code. Rob am I right? Yep, current implementation does use the creation policy while my unreleased personal version can use STL allocators. >Up to now it lacks: >o test cases. >o some optimizations. >o the documentation is still doxygen generated, but I plan to test > "doxygen autodoc". > >Ideas? Comments? Bugs? Overall I like it! Quite an interesting approach to a problem I spent a lot of time working on. Two things tho: I'm not certain I like the fact that you must create a builder class instance for every class you register. Any way to get rid of this or hide it in the factory class implementation itself? Would it be possible to allow for derived classes to be added dynamically without the need to edit the declaration of the factory object itself? I know many boost users perfer compile-time solutions to run-time solutions, and certainly each of their own uses, but I've always like the ability to allow end-users to modify/extend programs simply by registering their classes with my factory object (IE, the user shouldn't need to recompile my code to do this). Rob > >Fede. > >[1] >http://boost-sandbox.sourceforge.net/vault/index.php?action=downloadf >ile&filename=factory2.zip&directory=& > >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo. >cgi/boost

2 1

[policy_ptr][bug] ref_counted_ ::clone
by Larry Evans 04 May '05

04 May '05

The existing code: stored_param clone(stored_param p) const { ++*count_; return p; } should be changed, AFAICT, to: stored_param clone(stored_param p) const { if(count_) ++*count_; return p; } unless I'm missing something.

1 0

[MPL] "accumulate is a synonym for fold"
by David Abrahams 04 May '05

04 May '05

Shouldn't accumulate at least have some default arguments that make it more like std::accumulate? -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: [boost] Re: Formal Review: FOREACH macro
by brangdon＠cix.compulink.co.uk 04 May '05

04 May '05

In-Reply-To: <42778635.20706(a)boost-consulting.com> eric(a)boost-consulting.com (Eric Niebler) wrote (abridged): > * This isn't an algorithm, so I don't want to evoke std::for_each. What is it that makes std::for_each an algorithm and BOOST_FOREACH not? To me they seem to be doing similar jobs, albeit in different ways. -- Dave Harris, Nottingham, UK.

3 2

Patch for quaternion.hpp
by Janusz Piwowarski 04 May '05

04 May '05

I'm attaching the patch against boost/math/quaternion.hpp regression error (mingw). Regards, Janusz

3 2

Re: Formal Review: FOREACH macro
by Peter J. Schwaller 04 May '05

04 May '05

I find FOREACH very useful. I did find one anomaly. Compiling on MAC OS (Panther) using gcc version 3.3 20030304 (Apple Computer, Inc. build 1671), I had to add the following lines in order to get things to compile. I didn't investigate why it worked, but there you have it. # define BOOST_FOREACH_NO_RVALUE_DETECTION # define BOOST_FOREACH_NO_CONST_RVALUE_DETECTION

1 0

Intrusive containers: second iteration
by Olaf Krzikalla 04 May '05

04 May '05

Hi, the second version of intrusive containers is available. Excerpt from the introduction: ---snip--- Welcome to Boost.Intrusive, a library presenting some intrusive containers to the world of C++. While intrusive containers were and are widely used in C, they became more and more forgotten in the C++-world due to the presence of the standard containers, which don't support intrusive techniques. Boost.Intrusive not only reintroduces this technique to C++, but also encapsulates the implementation in STL-like interfaces. Hence anyone familiar with standard containers can use intrusive containers with ease. ---snap--- You find the file intrusive.zip either in the yahoo file section or here: http://people.freenet.de/turtle++/intrusive.zip I consider this version being rather complete now and quite ready for a formal review (barring islist maybe). Best regards Olaf Krzikalla

8 24