- Boost - lists.boost.org

Boost filesystem documentation
by James Gregory 05 May '05

05 May '05

http://www.boost.org/libs/filesystem/doc/exception.htm begins by saying: "The header provides class filesystem_error, publicly derived from std::runtime_error" I think this is wrong, isn't it publically derived from std::exception? Thanks, James

2 1

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

05 May '05

In-Reply-To: <4277C3E9.60407(a)boost-consulting.com> eric(a)boost-consulting.com (Eric Niebler) wrote (abridged): > Is do/while an algorithm? for (iterator i = c.begin(); i != c.end(); ++i) is an algorithm. Do/while would be if it included the code to step through a container. > You probably don't think of it that way. It's certainly not an > algorithm in the STL sense like std::for_each is. Again, a for-loop is. > The most effective way to think of BOOST_FOREACH (in my experience) > is as a new looping construct -- a foreach keyword. It's not a keyword. It's a macro which encapsulates an algorithm - roughly the same algorithm as std::for_each. > To encourage people to think of it as an algorithm in the STL sense > would be a mistake. It is range-based, not iterator-based. An algorithm does not need to be iterator-based to be an algorithm. > You can break and continue and return from the loop body. You can't > do any of those things from an STL algorithm. That's because the STL algorithms encapsulate differently, not because they are not algorithms. In any case, the question of whether FOREACH is an algorithm is a red herring, because the use of underlines as word separators does not just apply to algorithms. It also applies to macros (eg "BOOST_STATIC_ASSERT") and keywords (eg "static_cast"). Although there are some C++ keywords that don't have underlines, eg "sizeof", these are mostly inherited from C. The modern trend is for underlines unless there is a compelling reason otherwise. You've not offered a compelling reason. It sounds like you are mimicking the "foreach" of some other language. I think a C++ library should use C++ conventions, not the conventions of whatever it is you are copying. Consistency is important. Also, program text is easier to read if words don't all run together. -- Dave Harris, Nottingham, UK.

3 2

BOOST_FOREACH review results
by Gennadiy Rozental 05 May '05

05 May '05

Hi, everybody BOOST_FOREACH macro by Eric Niebler is accepted into boost. The library was received pretty good by boost community (I counted at least 13 positive reviews). The only two negative reviews based their rejection on principle: "Macros are evil and so should not be used". While this maybe interesting point in itself, as I see things now, boost practice supports using macros where necessary and macro nature of the tool could not be a compelling enough reason to reject the submission. Would this trend be ever changed in a future we could change a policy for future submissions. While there were not so many specific issues discovered during review, I would like to list couple: * documentation should contain more examples and special pitfalls section * testing should be split by compatibility sections * it would be good to make this facility work on more compilers Congratulation Eric for the excellent work and thanks to all the reviewers for participation. Gennadiy Rozental BOOST_FOREACH review manager

5 5

[bug] using boost::range and boost::array in MSVC 6.0
by Joe Gottman 05 May '05

05 May '05

MSVC 6.0 gives an internal compiler error when I include the following headers in the order below: #include <boost/array.hpp> #include <boost/range.hpp> The reason for this ICE (besides MSVC 6.0 being a non-conformant compiler) is the fact that several files in the boost/range/ subdirectory declare functions having a parameter called "array". It seems that MSVC has problems realizing that this is the name of a new variable, not an already existing class. When I renamed these parameters everything compiled fine. Would it be possible to change these parameters to a name that isn't the name of a boost class, something like c_array maybe? Thank you, Joe Gottman

2 1

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