- Boost - lists.boost.org

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

05 May '05

In-Reply-To: <ufyx36ixl.fsf(a)boost-consulting.com> dave(a)boost-consulting.com (David Abrahams) 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? > > You might consider just answering the first part of that question for > yourself: "what is it that makes std::for_each an algorithm?" It's a finite series of well-defined steps. As is BOOST_FOREACH. In any case, we use underlines in keywords and macros, too. For example, "dynamic_cast" or "BOOST_STATIC_ASSERT". -- Dave Harris, Nottingham, UK.

1 0

[Range] issues
by David Abrahams 05 May '05

05 May '05

I was just looking at using Boost.Range in my new Sequence library and noticed the following: 1. The documentation of requirements uses names like range_iterator without qualification. You need to add the boost:: prefix or make it very clear that all names are implicitly boost:: prefixed (as opposed to, say, boost::range:: prefixed). I prefer the former; people may land on the documentation for reference without reading all the introductory material. 2. Names like range_iterator in the requirements tables should be hyperlinked to some documentation for them. 3. The documentation you land on should clearly state in which header those names can be found. 4. Having a pile of names prefixed by "range_" (like boost::range_const_iterator) just seems wrong to me when we have namespaces. Is there a good reason we're not using boost::range::const_iterator or boost::ranges::const_iterator? -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 13

range_result_iterator
by David Abrahams 05 May '05

05 May '05

What is the rationale behind this name? It seems unintuitive to me, and what's more, unneccessary. Shouldn't range_iterator<T const>::type just be range_const_iterator<T>::type? If not, why not? -- Dave Abrahams Boost Consulting www.boost-consulting.com

4 10

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