- Boost - lists.boost.org

Published books on Boost
by Dave 18 Jan '05

18 Jan '05

Dear Boost Community, I am aware of the books on the graph and template metaprogramming libraries. Are any other books available, or in the works, on Boost libraries? Thank you, Dave

2 1

linker problems, mingw, win2k
by Jacek Pakulski 18 Jan '05

18 Jan '05

Hi; This is my first attempt at using Boost. Thought I'd start with the unit test lib. I tried to make unit_test_framework1.cpp, which compiled but failed to link, producing several errors like the one below: C:/Boost/lib/libboost_unit_test_framework-mgw-s-1_32.lib(test_tools.obj)(.rdata$_ZTISt9exception+0x0):test_tools.cpp: first defined here /mingw/lib/libstdc++.a(vterminate.o)(.text$_ZTSSt9exception+0x0): multiple definition of `typeinfo name for std::exception' I compiled the Boost library using bjam with following options: bjam "-sMINGW_ROOT_DIRECTORY=C:\Dev-Cpp\bin" "-sTOOLS=mingw" "-sBUILD=release <runtime-link>static <threading>single" install Result: ...failed updating 10 targets... ...skipped 3 targets... ...updated 3164 targets... My cmd. to make unit_test_framework1.cpp is: g++ -I"C:\Boost\include\boost-1_32" -L"C:\Boost\lib" C:\Boost\lib\libboost_unit_test_framework-mgw-s-1_32.lib -o boost_test.exe boost_test.o Thank You for Your patience and help Jacek <http://www.boost.org/libs/test/example/unit_test_example1.cpp>

1 1

RE: [boost] Re: Functions as Filters (was Program Reuse...)
by Brian Braatz 18 Jan '05

18 Jan '05

> -----Original Message----- > From: christopher diggins [mailto:cdiggins@videotron.ca] > Cc: Brian Braatz > Subject: Re: [boost] Re: Functions as Filters (was Program Reuse...) > > ----- Original Message ----- > From: "Brian Braatz" <brianb(a)rmtg.com> > > Chris, I suggest to you that you get a copy of the book Modern C++ and > > really give it a good read. It covers a lot of the new techniques now > > available to us because our compilers are now more compliant. We don't > > have to live in the stone ages anymore (applause!). > > > > I really get the sense, that if you were to take the time to understand > > some of the newer ideas on how to write code, you might not feel like > > everyone is disagreeing with you on this list. There are a number of > > mind blowing things that can be done with Generic Programming, but you > > first have to get your head into it and you have to be willing to accept > > new ideas. > > It is hard to not be insulted by your suggestions that I don't understand > the topics, that I am unwilling to accept new ideas, and that I need to > read > more books. I have said it before on this list, and I will say it to you: > I > would suggest that you do not jump to conclusions about my (or anyone > else's) lack of knowledge on a subject. I am far more familiar with > generic > programming than you probably realize. This kind of innuendo accomplishes > little, except aggravation. It also makes the Boost mailing list a very > inhospitable place. > [Brian Braatz] Chris, I was not trying to insult you. From my perspective: You had suggested using a global variable for something that someone else suggested making a template. You had repeatedly said things along the lines of "I Don't understand, why not make it a global". What I saw was a good argument for making things easy, but I did not get the sense that they power of the template was clear. I then suggested the book that I did. Not because I was jumping to conclusions. I suggested it based on the context of the conversation. I believe if you read Andrei's book (Modern C++ design), it will make the perspective of the people who were disagreeing with you more clear. That was neither an insult, or a jump to a conclusion. It was merely a suggestion from someone trying to help you NOT feel like this list is an inhospitable place.

1 0

[config] Single threaded builds with g++ >= 3.4: No longer possible?
by Andreas Huber 18 Jan '05

18 Jan '05

Hi there >From boost/config/stdlib/libstdcpp3.hpp: <quote> #ifdef __GLIBCXX__ // gcc 3.4 and greater: # ifdef _GLIBCXX_HAVE_GTHR_DEFAULT // // If the std lib has thread support turned on, then turn it on in Boost // as well. We do this because some gcc-3.4 std lib headers define _REENTANT // while others do not... // # define BOOST_HAS_THREADS # else # define BOOST_DISABLE_THREADS # endif #endif </quote> I suspect this means that ST builds are no longer possible on some GCC platforms (I'm using MinGW). Could someone please confirm or deny this? Thanks & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

2 2

ill-formed XML in boost::unit_test logger
by Mikhail Gusarov 18 Jan '05

18 Jan '05

Unit testing library creates invalid XML when asked about XML logging output, like this: --------------------------------------- <TestSuite name="TaskQueue tests"> </TestSuite="TaskQueue tests"> --------------------------------------- This is a trivial 'missing braces' bug which can be fixed by the patching libs/test/src/supplied_log_formatters.cpp. Patch is attached. -- Mikhail Gusarov ICQ UIN: 111575219 JID dottedmag(a)jabber.ru --- supplied_log_formatters.cpp.old 2005-01-17 17:29:51.000000000 +0600 +++ supplied_log_formatters.cpp 2005-01-17 17:31:13.000000000 +0600 @@ -203,8 +203,9 @@ output << (in_out ? "<" : "</") << ( tc.p_type ? "TestCase" : "TestSuite" ); - if( in_out ) + if( in_out ) { output << " name"; print_attr_value( output, tc.p_name ); + } output << ">";

2 1

RE: [boost] [Gauge for interest] Minimal perfect hash functiongenerator
by Hurd, Matthew 18 Jan '05

18 Jan '05

> Behalf Of Beman Dawes > >At 04:51 AM 1/17/2005, Matt Hurd wrote: > > >Perfect hashing and statistically reasonable hashing are quite > >different but practically the same ;-) > > Isn't that stretching it a bit? Collision handling code can be eliminated > if you know the hashing is perfect, for example. Although I do understand > your point that for many practical applications, perfect hashing and > statistically reasonable hashing would yield very similar performance. My apologies if I caused confusion. I was being a little facetious and assumed the points you make. > Seems like both could have a place in Boost. Yup. And perhaps a third that maps longer "key" sequence types into unique ids suitable for perfect hashing in an efficient way. For example, finding a minimum set of bytes to rotate and xor into a std::size_t that is unique for all keys via a simple decision tree. The size_t is then used for perfect hashing via a generator such as the MPH. This would efficiently meet the needs of a user with a fixed pool of strings or UUIDs, mentioned elsewhere, looking to map to a suitable index. > Statistically reasonable hashing of particular sets of strings has been a > need that I've often run into. Please feel free to take my hash.hpp code into the BSL as the basis for a real implementation that meets your needs w.r.t. a statistically robust but non-perfect hash. It is based on the solution outlined in Java in the articles previously cited. Regards, Matt Hurd matthurd(a)acm.org IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

3 2

[serialization] MSVC8 warning flood (widened size_t)
by Tobias Schwinger 18 Jan '05

18 Jan '05

Hi, when using the Boost.Serialization library with MSVC8 I get flooded by (about thousand lines of) warning messages due to the fact that size_t has been widened (and there are just very few small classes in my project that use serialization). It's especially annoying because warnings about truncating conversions are quite useful, in general (I wouldn't want to disable them permanently, that is). Boost.Serialization: [ collections_save_impl.hpp:36 ] "possible loss of data converting...". unsigned int <var> = <size_t expression> [ detail/oserializer.hpp:479 ] "possible loss of data converting..". int <var> = <size_t expression> - I guess there are some more but these are the ones the compiler gets to see in my project (that's also why I didn't post a patch). Boost.TypeTraits (used by Boost.Serialization): [ is_abstract.hpp:81 ] BOOST_STATIC_ASSERT(sizeof(expression))" "forcing value to bool" Just in case it isn't on anyone's todo-list, yet... Greetings, Tobias

10 15

[mpl] easy access to inherit_linearly elements
by Larry Evans 18 Jan '05

18 Jan '05

The code in: http://boost-sandbox.sourceforge.net/vault/inherit_linearly_test.cpp provides easy access to the elements of inherit_linearly with: get_tail<inherit_linearly<...>, i>::head_type which returns the i-th element in the inheritance heirarchy. Couldn't this be used to generate member names using templates? For example, the "name" of the i-th value on p. 191 of the _C++ Template Metaprogramming_ book would be: r.get_tail<inherit_linearly<...>, i>::head_type::value where r is an instance of: inherit_linearly<types, inherit_head_tail<wrap<_2>,_1> >::type

2 12

[PATCH] ill-formed XML in boost::unit_test result
by Mikhail Gusarov 18 Jan '05

18 Jan '05

Another XML well-formedness fix, this time in libs/test/src/unit_test_result.cpp (missing quotes around attribute values). -- Mikhail Gusarov ICQ UIN: 111575219 JID dottedmag(a)jabber.ru Index: unit_test_result.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/test/src/unit_test_result.cpp,v retrieving revision 1.31 diff -u -b -r1.31 unit_test_result.cpp --- unit_test_result.cpp 17 Sep 2004 12:34:13 -0000 1.31 +++ unit_test_result.cpp 18 Jan 2005 05:22:19 -0000 @@ -215,8 +215,8 @@ << " result"; print_attr_value( where_to, failed ? "failed" : "passed" ); if( failed ) - where_to << " num_of_failures=" << num_failed - << " expected_failures=" << num_expected; + where_to << " num_of_failures=\"" << num_failed << '"' << + << " expected_failures=\"" << num_expected << '"'; where_to << ">\n"; }

1 0

Functions as Filters (was Program Reuse ...)
by christopher diggins 17 Jan '05

17 Jan '05

Thank you very much to everyone who has been helping me out, and have made some suggestions. It took me a bit to realize the implications of what some people were suggesting, so I apologize if I am a bit slow to catch up. I now have code which allows two arbitrary functions ( which have no parameters and return void ) to be chained together from cout of one to the cin of the other: void HelloWorld() { cout << "hello world" << endl; } void CountChars() { string s; s = cin.getline(); cout << static_cast<int>(s.size()) << endl; } int main() { filter(HelloWorld) | filter(CountChars); return 0; } This is done by redirecting cout for the first function to a temporary stringstream buffer, and then redirecting the output of the second stream. The code to accomplish this is trivial, but potentially interesting for the community: #include <iostream> #include <sstream> using namespace std; typedef void(*procedure)(); class filter { public: filter(procedure x) : proc(x) { } void operator()(istream& in, ostream& out) { streambuf* inbuf = cin.rdbuf(); streambuf* outbuf = cout.rdbuf(); cin.rdbuf(in.rdbuf()); cout.rdbuf(out.rdbuf()); proc(); cin.rdbuf(inbuf); cout.rdbuf(outbuf); } private: procedure proc; }; void operator|(filter f1, filter f2) { stringstream s; f1(cin, s); s.seekg(0); f2(s, cout); } Many good suggestions have been made so far. Some possibilities for more features are: 1) create wrapper objects around the filters, this would allow the passing of data to functions, like a command line string 2) chain arbitrarily long sequences by creating a pipeline object, and doing the piping in its destructor 3) allow the chaining of streams 4) allow the chaining of the various iostreams concepts 5) allow the chaining of FILE* (i.e. popen, etc.) 6) allow the chaining of processes 7) allow threading of functions Any comments or suggestions? Is this a direction people would like to see continued? Also is anyone interested in collaborating? Christopher Diggins http://www.cdiggins.com http://www.heron-language.com

14 46