- Boost - lists.preview.boost.org

[Boost.Build] boost.python tutorial is not compiling
by Sandeep Gupta 05 Nov '08

05 Nov '08

Hi, I am reasonably sure that this is due to omission in the configuration file. I checkout from the trunk and all compilation went without problem. But the hello world example within the boost.python is failing with error: LINK : fatal error LNK1104: cannot open file 'boost_python-vc80-mt-gd-1_38. lib' call "f:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat" x86 >nul link /NOLOGO /INCREMENTAL:NO /DLL /DEBUG /subsystem:console /out:"bin\msvc-8.0\debug\hello_ext.pyd" /IMPLIB:"bin\msvc-8.0\debug\hello_ext.lib" /LIBPATH:"F:\CodeBase\Libs\Python-2.5.2\PCbuild8\win32release" @"bin\msvc-8.0\debug\hello_ext.pyd.rsp" .... .... >From what I can make that LIBPATH doesn't have path to boost_python-vc80-mt-gd-1_38.lib. The lib in question is build at its requisite place. Appreciate any help. Thanks sandeep

1 0

[uuid] width
by Kenneth Laskoski 05 Nov '08

05 Nov '08

Hello, I was reading/using/copying your code when I spotted a possible bug in the inserter operator<<. The standard result for built-in types is to align the output and set the ostream width property back to zero, which does not happen when I use your class. For example: int main() { uuid x; cout << 'a' << setw(40) << x << 'a' << endl; } output is a00000000-0000-0000-0000-000000000000 a but should be a 00000000-0000-0000-0000-000000000000a If this is the intended behavior, please document it. If not, maybe the attached patch will help put things back on rail. Regards, Kenneth

2 1

[thread] hardware_concurrency() not working on all platforms?
by Oliver Kowalke 05 Nov '08

05 Nov '08

Hello, boost::thread::hardware_concurrency() seams not to work on all platforms (xBSD, OpenSolaris). Is there some ongoing work to provide this functionaly on the other platforms too? regards, Oliver -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

2 1

Boost.Build changes for 1.38
by Vladimir Prus 04 Nov '08

04 Nov '08

As we're nearing 1.37, and the time for big changes that follows after, I wanted to discuss one Boost.Build change I want to make. Right now, we have two ways to build Boost -- using bjam directly, and using configure and make (which are wrappers over boost.build). The first approach may be a bit hard, and the second is very nice when it works, but it leads to other problems: - users start to assume it's "real" configure, and get upset when various variables that CXXFLAGS have no effect - if users want to do anything custom, like mingw cross compilation, they have to go back to direct use of bjam anyway. So, I'd like to suggest a solution where building of boost involves three steps: 1. ./bootstrap.sh or ./bootstrap.bat This step just builds bjam and puts it into boost root 2. ./bjam [--build-type=complete] [--layout=xxx] [properties] configure This step: - Tries to detect what compilers you have - Figures which optional libraries you have, and which you don't (e.g. ICU) - Writes a file project-config.jam with all the discovered information. 3. ./bjam This step can be usually invoked with no parameters, reads the configuration information from project-config.jam, and builds everything. For new users, this solution is only marginally more complex that configure/make, and does not create the false impression it's autoconf. For power users, the file produced in (2) can be tweaked and extra options can be specified in (3). For all users, this means that various properties can be specified only once in (2) and need not be repeated on every build, which is clearly a convenient thing. Anybody has comments about this plan? - Volodya -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2

11 20

Documentation and directory structure
by Robert Ramey 04 Nov '08

04 Nov '08

I've just downloaded the 1.37 release. I have the svn tree, but I wanted the pre-built documentation. I was very disappointed that I found the documentation in different places depending on how it was generated. So for some libraries its in ../doc/html and for others its in libs/<library_name>/doc. This is really confusing. It also suggests that the documentation build is some humungous script which builds all the documentation at once. I realise that boost likes to do things like this way - but never the less its very inconvenient for those of us who just want to use a small portion of boost in any given project. Can't we rationalize the documentation build in to something like the following? a) directory structure .../libs/<library_name>/doc Jamfile.v2 (optional) html .... docbook ... quickbook ... whatever. b) ability to build documentation for one library at a time by invoking bjam or whatever Advantages a) consistent directory structure b) release could but would necessarily have to include the prebuilt documentation c) easier for developers to fiddle with documentation of one library at a time d) easier to extract one library from boost e) easier to understand and use the documentation build process Robert Ramey

2 1

CMake build system is Merged into Trunk
by Michael Jackson 04 Nov '08

04 Nov '08

With the encouragement of Doug Gregor and the support of other Boost moderators I have merged the work from the CMake branch into trunk. The CMake branch was a branch to develop a new build system for boost based on the opensource CMake build system (www.cmake.org) The current state of the build system is unstable and still has work to be done. Compiling of the static libraries on at least one system (OS X 10.5.5 Intel) was completed and the installation of the libraries and headers was performed. There is still much work to be done but we are hoping to quickly improve the state of the cmake build system so that it becomes usable. NOTHING has been done to compromise the current build system based on BJam. For more information on getting started with CMake and boost please take a look at this page: <https://svn.boost.org/trac/boost/wiki/CMake> I will be adding to the CMake documentation on the wiki as soon as I can. For those familiar with CMake here is the 2 second how to (For Unix/ line command): Install CMake 2.6.2 from www.cmake.org Update your Boost trunk. Open boost/CMakeLists.txt and comment out the following line: message(FATAL_ERROR "") Create a build directory for boost (I suggest 'Build' within the boost directory) cd into Build cmake ../ .. Let that go for a little while make modularize .. Let that go for a while. This WILL change the layout of the boost working directory so WATCH OUT for this. Once this is complete there is NO 'undo' so the only way to get your working directory back the way it was is to do a revert from svn. Once this runs the bjam system WILL break. So ONLY do this if you want to either work on the CMake system or try it out. And finally run make Windows Users: Run the 'cmake-gui.exe' app and point it to your working directory. Tell the app where to put its build files (Binary directory) and hit configure. Pick what type of build files you want generated, and then let it "configure" After it is done configuring click the "Generate" button. Your project files, makefiles, or Visual Studio files should now be created. Testing is NOT complete as of yet. I am still getting all the cmake files updated. If you have comments, feedback or anything else either file a bug in the trac system or come join us on the boost-cmake mailing list <http://lists.boost.org/mailman/listinfo.cgi/boost-cmake > Again, I would like to stress that NOTHING has been done to change the current bjam based build system. If it DID break let me know ASAP and I will fix it. Thanks _________________________________________________________ Mike Jackson mike.jackson(a)bluequartz.net BlueQuartz Software www.bluequartz.net Principal Software Engineer Dayton, Ohio

3 3

Serialization - basic_text_iprimitive destructor throws
by John Salmon 04 Nov '08

04 Nov '08

I tried turning on exceptions on the input stream that I use for a text_iarchive, hoping to catch user-level errors such as an attempt to treat a non-archive file as an archive. It seems that when exceptions are enabled on the underlying stream, the basic_text_iprimitive destructor throws a second(?) basic_ios::failure exception, during stack unwinding, which lands me unhappily in the terminate handler. Can the basic_text_iprimitive destructor be protected against accidentally throwing? Here's an demonstration. This is on a Linux system with gcc/4.1.2. John Salmon salmonj(a)drdblogin6.en.desres$ cat ser.cpp #include <boost/archive/text_iarchive.hpp> #include <boost/serialization/serialization.hpp> #include <stdexcept> #include <fstream> struct Foo{ int i, j; private: friend class boost::serialization::access; template <class Archive> void serialize(Archive & ar, const unsigned int version) { ar & i & j; } }; int main(){ Foo foo; std::ifstream ifs("/dev/null"); ifs.exceptions(std::istream::failbit | std::istream::badbit); try{ boost::archive::text_iarchive tia(ifs); tia >> foo; }catch(std::ios_base::failure &e){ std::cerr << "Caught std::ios_base::failure. What: " << e.what() << "\n"; }catch(std::exception &e){ std::cerr << "Caught exception. What: " << e.what() << "\n"; } return 0; } salmonj(a)drdblogin6.en.desres$ xmk g++ -I/proj/desres/root/Linux/x86_64/boost/1_37_0-13/Release/include -g -L/proj/desres/root/Linux/x86_64/boost/1_37_0-13/Release/lib -Wl,-rpath,/proj/desres/root/Linux/x86_64/boost/1_37_0-13/Release/lib ser.cpp -lboost_serialization -o ser salmonj(a)drdblogin6.en.desres$ ser terminate called after throwing an instance of 'std::ios_base::failure' what(): basic_ios::clear Aborted (core dumped) salmonj(a)drdblogin6.en.desres$ gdb -c drdblogin6.en.desres.deshaw.com-6718.core ser GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu"... Reading symbols from /proj/desrad-c/root/Linux/x86_64/boost/1_37_0-13/Release/lib/libboost_serialization.so...done. Loaded symbols for /proj/desres/root/Linux/x86_64/boost/1_37_0-13/Release/lib/libboost_serialization.so Reading symbols from /proj/desrad-c/root/Linux/x86_64/gcc/4.1.2-10/lib64/libstdc++.so.6...done. Loaded symbols for /proj/desres/root/Linux/x86_64/gcc/4.1.2-10/lib64/libstdc++.so.6 Reading symbols from /lib64/tls/libm.so.6...done. Loaded symbols for /lib64/tls/libm.so.6 Reading symbols from /proj/desrad-c/root/Linux/x86_64/gcc/4.1.2-10/lib64/libgcc_s.so.1...done. Loaded symbols for /proj/desres/root/Linux/x86_64/gcc/4.1.2-10/lib64/libgcc_s.so.1 Reading symbols from /lib64/tls/libc.so.6...done. Loaded symbols for /lib64/tls/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Core was generated by `ser'. Program terminated with signal 6, Aborted. [New process 6718] #0 0x0000003f72a2e25d in raise () from /lib64/tls/libc.so.6 (gdb) where #0 0x0000003f72a2e25d in raise () from /lib64/tls/libc.so.6 #1 0x0000003f72a2fa5e in abort () from /lib64/tls/libc.so.6 #2 0x00002b5ab82f5f84 in __gnu_cxx::__verbose_terminate_handler () at /state/partition1/tmp/tmpXcQw4O/gcc-4.1.2-10/gcc-4.1.2/libstdc++-v3/libsupc++/vterminate.cc:97 #3 0x00002b5ab82f4106 in __cxxabiv1::__terminate (handler=0x1a3e) at /state/partition1/tmp/tmpXcQw4O/gcc-4.1.2-10/gcc-4.1.2/libstdc++-v3/libsupc++/eh_terminate.cc:43 #4 0x00002b5ab82f350b in __cxa_call_terminate (ue_header=0x50b730) at /state/partition1/tmp/tmpXcQw4O/gcc-4.1.2-10/gcc-4.1.2/libstdc++-v3/libsupc++/eh_call.cc:60 #5 0x00002b5ab82f3fa7 in __gxx_personality_v0 ( version=<value optimized out>, actions=6, exception_class=<value optimized out>, ue_header=0x50b730, context=0x7ffff29e5610) at /state/partition1/tmp/tmpXcQw4O/gcc-4.1.2-10/gcc-4.1.2/libstdc++-v3/libsupc++/eh_personality.cc:637 #6 0x00002b5ab846a068 in _Unwind_RaiseException_Phase2 (exc=0x50b730, context=0x7ffff29e5610) at /state/partition1/tmp/tmpXcQw4O/gcc-4.1.2-10/gcc-4.1.2/gcc/unwind.inc:66 #7 0x00002b5ab846a2db in _Unwind_Resume (exc=0x50b730) at /state/partition1/tmp/tmpXcQw4O/gcc-4.1.2-10/gcc-4.1.2/gcc/unwind.inc:234 #8 0x00002b5ab80fd790 in boost::archive::basic_text_iprimitive<std::istream>::~basic_text_iprimitive () from /proj/desres/root/Linux/x86_64/boost/1_37_0-13/Release/lib/libboost_serialization.so #9 0x00002b5ab8109e0c in boost::archive::text_iarchive_impl<boost::archive::text_iarchive>::text_iarchive_impl () from /proj/desres/root/Linux/x86_64/boost/1_37_0-13/Release/lib/libboost_serialization.so #10 0x00000000004045ab in text_iarchive (this=0x7ffff29e5ae0, is=@0x7ffff29e58d0, flags=0) at /proj/desres/root/Linux/x86_64/boost/1_37_0-13/Release/include/boost/archive/text_iarchive.hpp:110 #11 0x0000000000402c84 in main () at ser.cpp:24 (gdb) quit salmonj(a)drdblogin6.en.desres$

1 0

boost::integer library request
by Jorge Lodos Vigil 04 Nov '08

04 Nov '08

Hi Is there any chance the code below could be added to the integer library? More specifically, to the integer_mask.hpp header? If there is, I would be happy to provide tests and documentation. We use it to get significant parts of unsigned integer values, it is a superset of LOBYTE, HIBYTE, LOWORD and HIWORD windows macros and generates no binary code in optimized compilations. Thanks in advance. template < std::size_t Bits, typename Unsigned > inline typename uint_t<Bits>::least lobits(Unsigned n) { n &= low_bits_mask_t<Bits>::sig_bits; return (uint_t<Bits>::least)n; } template < std::size_t Bits, typename Unsigned > inline typename uint_t<Bits>::least hibits(Unsigned n) { n >>= (std::numeric_limits<Unsigned>::digits - low_bits_mask_t<Bits>::bit_count); return (uint_t<Bits>::least)n; } template <typename Unsigned> inline uint8_t lobyte(Unsigned n) { return lobits<8, Unsigned>(n); } template <typename Unsigned> inline uint8_t hibyte(Unsigned n) { return hibits<8, Unsigned>(n); } template <typename Unsigned> inline uint16_t loword16(Unsigned n) { return lobits<16, Unsigned>(n); } template <typename Unsigned> inline uint16_t hiword16(Unsigned n) { return hibits<16, Unsigned>(n); } template <typename Unsigned> inline uint32_t loword32(Unsigned n) { return lobits<32, Unsigned>(n); } template <typename Unsigned> inline uint32_t hiword32(Unsigned n) { return hibits<32, Unsigned>(n); } Best regards Jorge

1 0

[threadpool] new version v12
by k-oli＠gmx.de 04 Nov '08

04 Nov '08

Hello, the new version of Boost.Threadpool depends on Boost.Fiber. regards, Oliver

10 54

Default build
by Vladimir Prus 04 Nov '08

04 Nov '08

Hi, I'd like to have a small poll: 1. Do you use the 'default build' project attribute. 2. Can you tell what properties are set there? 3. Do you use that to specify multiple property sets? Thanks, Volodya P.S. Anybody who uses default build and fails to reply may get their projects broken without warning :-)

3 2

[BGL] got stuck at "error_type_must_be_a_signed_integer_type" error
by Sandeep Gupta 04 Nov '08

04 Nov '08

Hi, Not sure how much interest is in leda wrapper of BGL. But the new version of leda broke the leda wrapper. I have made some quick fixes. However i got stuck at this error: boost_1_36_0/boost/concept_check.hpp:91: error: request for member 'error_type_must_be_a_signed_integer_type' in '((boost::SignedInteger<leda::edge_struct* const*>*)this)->boost::SignedInteger<leda::edge_struct* const*>::x', which is of non-class type 'leda::edge_struct* const*' Hopefully its the last one. After this technically the wrapper should compile. I have briefly tested it with connecte components routines. If there is interest i will happy to post the changes.. thanks sandeep

1 0

Yet another shot at reflection/introspection
by Jean-Louis Leroy 04 Nov '08

04 Nov '08

I have committed a new library to the sandbox. It's called "introspection". It's another shot at implementing reflection. I am aware that similar work already exists, like Jeremy Pack's reflection library and Boost.Mirror (although this one currently supports only compile-time reflection). It's a work in progress - the testsuite is the doc at this point ;-) - and maybe it will never be completed/submitted. My primary goal is not to implement reflection per se, I'd be happy to leave the honor to Jeremy but currently it's not clear that his work can serve as a basis for my future developments (multimethods, generic object manipulation). Jean-Louis

1 0

[1.37.0][date-time] Breaking the log jam
by Beman Dawes 04 Nov '08

04 Nov '08

Andrey Semashev has pulled together a number of patches to address backed-up date-time tickets. He has tested them on Linux and Windows. The arrangement was that Jeff Garland would look them over, but Jeff just isn't finding the time to do that. I've taken a look at a few of the proposed fixes. Without knowing anything about date-time, these seem like problems that really should have been fixed some time ago.The proposed patches I looked at seemed fine. So I think it is important we break the log jam. Proposal: * We give Andrey write permission. * He starts moving these fixes into trunk right away. * Anyone who cares about data-time watch the commits carefully, and discuss any issues with Andrey. * Once Andrey is satisfied with trunk test results, he asks permission to merge to release. * Unless there has been undue delay or issues have come up, we will give permission for this release. * I'm willing to hold the release a few days; in aggregate this is an important set of overdue fixes to a major library so I'd like to see them go in this release. Comments? --Beman

7 15

Boost 1.37.0 Release Notice
by Beman Dawes 03 Nov '08

03 Nov '08

Boost 1.37.0 has been released and is available from SourceForge. See http://sourceforge.net/projects/boost/ This release includes one new library: Proto: Expression template library and compiler construction toolkit for domain-specific embedded languages, from Eric Niebler. Updated libraries include Asio, Circular Buffer, Dynamic Bitset, Hash, Interprocess, Intrusive, Math Type, Traits, and Unordered. The release managers were Beman Dawes, Daniel James, Eric Niebler, and Rene Rivera. The web site should be updated soon to reflect the new release. If you can't wait, see http://beta.boost.org now! --Beman Dawes

6 5

[signals2][review] Fwd: Signals2 Review
by Stjepan Rajko 03 Nov '08

03 Nov '08

I am forwarding the following review submitted by Jesse Williamson: ---------- Forwarded message ---------- From: Jesse Williamson <jesse(a)mind.net> Date: Sun, Nov 2, 2008 at 5:09 PM Subject: Signals2 Review To: Stjepan Rajko <stjepan.rajko(a)gmail.com> * Do you think the library should be accepted as a Boost library? Yes. * What is your evaluation of the design? Note: I only read the tutorial, and wrote my own examples as I followed along. I think this is a very nicely designed library! I like the collector interface, and the general library behavior. Note: I was going to suggest some syntactic sugar with operator overloading, but when I tried it I quickly discovered that there's a problem in determining the proper return type for something like + or +=. It isn't really needed anyway-- and, I also have since discovered that the documentation already addresses this! * What is your evaluation of the implementation? I did not examine the implementation. For the most part, things worked as I expected after reading the tutorial examples. * What is your evaluation of the documentation? Good! The tutorials are on the whole very good, and I came through them feeling like I had a good working understanding of the library. I have a few suggestions and perhaps issues, which I discuss below in more detail. I would like to see more explit examples in a few of the tutorial examples, especially those concerning connection management. * What is your evaluation of the potential usefulness of the library? Event patterns show up in many applications, and a thread-safe version of the long-standing Boost::Signals library would surely greatly extend its usefulness. * Did you try to use the library? With what compiler? Did you have any problems? gcc 4.2.1 on AMD x86-64, I had no problems using the library, although I did run into a compiler issue with the examples as written in the tutorial, it was fixed in the packaged example file. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent a day reading the tutorial and working through the examples. I had few problems writing my own versions of the tutorial programs, and feel like I came out of them with a good working understanding of the library's use. I believe I worked through all of them. * Are you knowledgeable about the problem domain? Kinda. I've used a fair number of event-driven frameworks, but beyond peeking at it, I've never used the Signals library before. My review is from evaluating the tutorial only. --------------- Some comments and thoughts, mostly written as I went through the tutorial. Documentation: ------------- * Perhaps you should point out the location of the FAQ earlier in the synopsis. I found it at the end, but may not have if I'd been in a hurry. * ToC and main page: The first thing that I notice is that I can infer from the original copyright notice that Douglas Gregor's library appears to have been stable for a really long time! Nice work!! * Introduction: Is it really important that we know Signals2 was formerly known as thread_safe_signals? You might consider pointing this out in the introduction text itself, instead, since it becomes redundant and is more-or-less superfluous information. The introduction gave me a clear idea of what the library is for, and the general abstraction it presents. I've worked with a fair number of event-based systems, and so it already sounds like familiar territory and I felt like I got a good sense of what Signals2 is for. Tutorial: -------- * Do we need "beginner", "intermediate", and "advanced"? I'm not sure why I'm cautioned that the tutorial is not meant to be read linearly, especially since the tutorials typically (and expectedly) progressed from basic to advanced material. Readers tend to pick and choose what they need anyway, and it seemed more visually cluttering than anything. I just followed everything linerally, and did not seem to have many problems. On the other hand, if this is essentially how the documentation has been structured for years, it's unlikely there's any need to change it. * Compiler versions and preferred-form table: I wonder if, instead of maintaining a list of which compilers do support the preferred syntax, it would not be easier to just maintain a list of those which do not support it, especially since it looks to be that only broken compilers don't. * Slot ordering examples: In the intermediate example of ordering slots, I wasn't able to change the order my signal was displayed after reading the material a few times. It always came last, no matter what order I added it in. I was able to do it, but it was by using the numeric ordering I'd learned in the beginner section. In my own test program, I tried: // ... GoodMorning gm; HelloWorld hello; Newline nl; sig.connect(gm); // confused as to why this always comes last sig.connect(2, nl); sig.connect(1, hello); sig.connect(0, gm); // ok, clear why this goes first // ... ...after playing around a while, I understood what the intermediate example was explaining, and it made sense. Maybe it's a pitfall of reading the tutorial out of the recommended order, but the beginner section didn't really seem to explain to me clearly that sig.connect() is actually adding groups and not "individual" signals. (Or, perhaps I'm still confused about how it works? :>) The section where we deal with return values just feels to me like a logical extension of the behavior the beginner tutorial has just discussed, rather than as a seperate tutorial with significantly more advanced behavior-- it seemed natural to want to return values next. * Blocking tutorial: I got a suprise playing with the blocking section when an assertion was triggered: // ... boost::signals2::signal<string (string a, string b)> sig; boost::signals2::connection c = sig.connect(&revcatgoat2); if(c.connected()) cout << *sig("a", "b") << endl; // ... { boost::signals2::shared_connection_block block(c); if(!c.blocked()) { cerr << "something is wrong\n"; throw; } cout << "You shouldn't see this: "; cout << *sig("a", "b"); // SUPRISE abort()! cout << endl; } // ...continue, expecting output when block goes out of scope... ...The tutorial didn't say anything about that happening. Perhaps I was misusing the library..? It worked fine when I checked for c.blocked() again before trying to call sig(). * "Disconnecting Equivilent Slots" example: I didn't feel that the example program for "disconnecting equivilent slots" fully illustrated the library concept. Perhaps that should be made more clear in the example by disconnecting via a pointer to the same function, instead of by using the same identifier that was used to connect(), something like: // ... boost::signals2::signal<int (int a, int b), aggregate_values< vector<int> > > sig; sig.connect(&add); sig.connect(&half); // results of half() seen: { vector<int> results(sig(5, 5)); dump(results); } // Disconnect half() by using an equivilent slot: int (*ptr_to_half)(int a, int b) = half; sig.disconnect(ptr_to_half); // results of half() not seen: { vector<int> results(sig(5, 5)); dump(results); } // ... * Connection Management example: I got a small (but pleasant) suprise when I tried out the connection management: { messageSignal deliver; messageReciever *mr = new messageReciever("message reciever one"); deliver.connect(boost::bind(&messageReciever::show, mr, _1)); { messageReciever *mr2 = new messageReciever("message reciever two"); deliver.connect(boost::bind(&messageReciever::show, mr2, _1)); deliver("message"); } deliver("message"); // SUPRISE: no problem } ...after reading the tutorial section, I had expected the second deliver() call to segfault, but instead it worked nicely. I'm not really going to complain about this, but I'd expected something differently from the tutorial's explanation that it was expected to segfault. It seems reasonable to expect this behavior, given the explaination about shared_ptr<>. Indeed, calling delete explicitly produced mangled output. Perhaps extending the example to show an explosion and how track() gets around it would be worthwhile. Also, maybe it would be nice if the signal_type typedef could be included closer to its actual use in the example? * Automatic Connection Example Problem: There seems to be no get() for NewsMessageArea in the automatic connection management example, and the signature with the application operator appears to probably not be correct. I had to use: // Note second parameter to slot_type ctor: deliver.connect(messageSignal::slot_type(&messageReciever::show, mr2, _1).track(mr2)); * Compiler complaint in "Document-View" example: button.doOnClick(&printCoordinates); ...requires: button.doOnClick(&Button::printCoordinates); ...the example included in the package did not have this issue. (I implemented my own in working through the tutorial.) * Comment on "Passing Slots" example: In the "passing slots" example, Button::f() never appears to get bound. A complete example would be nice. ...on the whole, I enjoyed this tutorial and feel like I can star working with the Slots2 libray! Thanks.

1 0

[1.38.0] Open for merging
by Beman Dawes 03 Nov '08

03 Nov '08

The release branch (https://svn.boost.org/svn/boost/branches/release) is open for merging all stable changes from trunk, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, except for new libraries, merging changes *does not* need permission from a release manager. I.e. just do it! The release schedule: * November 3, 2008: branches/release opens for merging all stable changes, including bug fixes, and major upgrades to existing libraries. Breaking changes should be coordinated with libraries affected. New libraries may be added with permission of a release manager. * December 20, 2008: branches/release closed for new libraries and breaking changes to existing libraries. Still open for bug fixes and other routine changes to all libraries. * January 3, 2009: branches/release closed for major code changes. Still open for serious problem fixes and docs changes. * January 10, 2009: branches/release closed for all library changes except when specific permission given by release manager(s). * January 17, 2009: Beta release target date. Further betas and/or release candidates as feedback dictates . * January 31, 2009: Release ship date. Links relating to this release: * Google Calendar with the release schedule: <http://www.boost.org/development/index.html>. * Release schedule explanation: <http://svn.boost.org/trac/boost/wiki/ReleaseSchedule>. * Release practices for developers: <http://svn.boost.org/trac/boost/wiki/ImprovingPractices>. --Beman Dawes, Daniel James, Eric Niebler, Rene Rivera

1 0

history/version_1_37_0 link broken
by Neal Becker 03 Nov '08

03 Nov '08

The 'release history' link on the top-level boost/index.html is broken (404): http://www.boost.org/users/history/version_1_37_0

2 2

Boost C++ Library Patches (1.36.0) (from C++ Soup! blog)
by Dean Michael Berris 03 Nov '08

03 Nov '08

Hi Guys, I've recently posted some issues to the Boost Trac system. What follows is the content of my post to my blog (http://blog.cplusplus-soup.com/) regarding patches I've submitted. I hope this helps! ---->8--- For those who have been having some trouble getting some libraries to compile nicely in Boost 1.36 using GCC 4.3.2, I have posted some issues (and associatively some patches) to Boost.Date_Time, Boost.Asio, and Boost.System to the Boost Trac installation. I've listed them down here with a short description of what the issue is and what the solution is (and where you can get the patch for Boost 1.36.0). GCC 4.3.2 and stricter identifier restrictions In the past versions of GCC, the following code would pose no problems: namespace ns { template <class T> struct name { }; name<int> name; // error here! } Now however, you'll get an error saying "declaration of 'name' changes the meaning of identifier 'name'". Apparently the fix is trivial which is to give the namespace qualified name: namespace ns { template <class T> struct name { }; ns::name<int> name; // no error anymore } There is some code in Boost.Date_Time (release 1.36.0) which has this problem. The issue is reported as Boost Trac issue #2465. GCC 4.3.2 and stricter member construction requirements Apparently GCC 4.3.2 has a more strict requirement on when a particular member variable is actually initialized or not -- especially when they are used as temporaries in a static function. I'm not sure if this is a compiler bug/feature, but nonetheless Boost.Date_Time's contrained_value template does not explicitly initialize the member 'value_' variable. The trivial fix (which is to default-construct the member variable in the constructor) is available attached to issue #2463. Boost.System's Missing 'get_posix_category' In Boost 1.36.0, Boost.System's get_posix_category function had been removed. For strict backwards compatibility, it has to be put in to let older versions of libraries that use the function to link properly. This has been submitted as issue (with patches attached) #2461. Boost.Asio's 'pipe_select_interrupter' warning Still with GCC 4.3.2, discarded return values turn out to be warned against. There is a function in Boost.Asio's detail implementations that calls '::write(...)' and then ignores the return value -- which throws a warning and causes builds with -Werror to fail. The trivial patch is attached to the submitted issue #2462. Caveats These patches are submitted to the Boost community through the Trac Issue Trackings system. They have not yet been accepted by authors/maintainers at the time of this writing. Like the saying goes, use at your own risk. Just as a reminder, these patches are to be applied to the Boost 1.36.0 release -- Boost 1.37.0 may have some of these issues addressed. If you find have questions about the patches (and don't want to post comments to the blog entry) please contact me directly through dean.berris(a)cplusplus-soup.com. -- Posted By Dean Michael to C++ Soup! at 11/03/2008 05:27:00 AM ---->8--- -- Dean Michael C. Berris Software Engineer, Friendster, Inc.

1 0

Boost C++ Library Patches (1.36.0) (from C++ Soup Blog)
by Dean Michael Berris 03 Nov '08

03 Nov '08

Hi Guys, I've recently posted some issues to the Boost Trac system. What follows is the content of my post to my blog (http://blog.cplusplus-soup.com/) regarding patches I've submitted. I hope this helps! ---->8--- For those who have been having some trouble getting some libraries to compile nicely in Boost 1.36 using GCC 4.3.2, I have posted some issues (and associatively some patches) to Boost.Date_Time, Boost.Asio, and Boost.System to the Boost Trac installation. I've listed them down here with a short description of what the issue is and what the solution is (and where you can get the patch for Boost 1.36.0). GCC 4.3.2 and stricter identifier restrictions In the past versions of GCC, the following code would pose no problems: namespace ns { template <class T> struct name { }; name<int> name; // error here! } Now however, you'll get an error saying "declaration of 'name' changes the meaning of identifier 'name'". Apparently the fix is trivial which is to give the namespace qualified name: namespace ns { template <class T> struct name { }; ns::name<int> name; // no error anymore } There is some code in Boost.Date_Time (release 1.36.0) which has this problem. The issue is reported as Boost Trac issue #2465. GCC 4.3.2 and stricter member construction requirements Apparently GCC 4.3.2 has a more strict requirement on when a particular member variable is actually initialized or not -- especially when they are used as temporaries in a static function. I'm not sure if this is a compiler bug/feature, but nonetheless Boost.Date_Time's contrained_value template does not explicitly initialize the member 'value_' variable. The trivial fix (which is to default-construct the member variable in the constructor) is available attached to issue #2463. Boost.System's Missing 'get_posix_category' In Boost 1.36.0, Boost.System's get_posix_category function had been removed. For strict backwards compatibility, it has to be put in to let older versions of libraries that use the function to link properly. This has been submitted as issue (with patches attached) #2461. Boost.Asio's 'pipe_select_interrupter' warning Still with GCC 4.3.2, discarded return values turn out to be warned against. There is a function in Boost.Asio's detail implementations that calls '::write(...)' and then ignores the return value -- which throws a warning and causes builds with -Werror to fail. The trivial patch is attached to the submitted issue #2462. Caveats These patches are submitted to the Boost community through the Trac Issue Trackings system. They have not yet been accepted by authors/maintainers at the time of this writing. Like the saying goes, use at your own risk. Just as a reminder, these patches are to be applied to the Boost 1.36.0 release -- Boost 1.37.0 may have some of these issues addressed. If you find have questions about the patches (and don't want to post comments to the blog entry) please contact me directly through dean.berris(a)cplusplus-soup.com. -- Posted By Dean Michael to C++ Soup! at 11/03/2008 05:27:00 AM ---->8--- -- Dean Michael C. Berris Software Engineer, Friendster, Inc.

1 0

[timer_scheduler] is there any interest on a timer scheduler library?
by vicente.botet 03 Nov '08

03 Nov '08

Hi, I would like to be able to submit/schedule tasks at a given time (callouts) which could be oneshot or periodics. Something like the_timer_scheduler::schedule_at(t1_, now()+seconds(10)); Is there any interest on this feature? I have started to scketch the interface of the library. Note: I have used timeout because timer already exists in the boost namespace. callout could be also used if this is more clear. Note. This interface do not allow arbitrary callbacks functions. struct timeout; typedef void (*timeout_callback)(timeout&); struct timeout_type { timeout_type(timeout_callback callback); timeout_callback operator()(timeout&); }; struct timeout { timeout(const timeout_type& type); const timeout_type& type; // ... }; // template class that store in addition a context template <typename CTX, timeout_type& TYPE> struct timeout_ctx : timeout { timeout_ctx(CTX* ctx) : timeout(TYPE) , context_(ctx) {} CTX* context() {return context_;} CTX* operator CTX*() {return context_;} protected: CTX* context_; }; // there is a single timer scheduler namespace the_timer_scheduler { void schedule_at(timeout& handle, system_time& absolute_time); void reschedule_at(timeout& handle, system_time& absolute_time); void schedule_at_periodicaly(timeout& handle, system_time& absolute_time, duration_type period); void reschedule_at_periodicaly(timeout& handle, system_time& absolute_time, duration_type period); void cancel(timeout& handle); } Example: static const timeout_type t1_type; struct my_ctx, typedef timeout_ctx<my_ctx, t1_type> t1; struct my_ctx { my_ctx() : t1_(this) {} t1 t1_; void on_t1(); static void on_t1(timer* p) { static_cast<t1*>(p)->context()->on_t1(); } void funct() { the_timer_scheduler::schedule_at(t1_, now()+seconds(10)); // ... the_timer_scheduler::cancel(t1_); } }; timeout_type t1_type(ctx::on_t1); The implementation of the timeouts scheduler could be based on "Redesigning the BSD Callout and Timer Facilities" by Adam M. Costello, George Varghese http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=B5202FC949FF3EDB0E… Vicente

2 2

[threads] adopt_lock_t question
by Jens Finkhäuser 03 Nov '08

03 Nov '08

Hi! I've come across something that puzzles me. I've got code that, condensed to relevant parts, looks like this: recursive_mutex m; lock_guard<recursive_mutex> l1(m); lock_guard<recursive_mutex> l2(m, adopt_lock_t()); What happens is that if -DNDEBUG is set, the code passes. But if -DDEBUG is set, l1's destructor aborts. Further investigation shows that the destructor calls the mutexe's unlock() function (as expected), which in turn tries to unlock it's internal mutex object - in my case a pthread mutex. The difference between the compilation modes is that the return value of that unlocking function is wrapped in a BOOST_VERIFY(), i.e. assert() call. As I understand the documentation, my code is perfectly valid. It may not make a large amount of sense to use adopt_lock_t as the nature of recursive_mutex should be to not block in l2's constructor - but that's a different matter. Now according to the documentation, lock_guard expects a Lockable, recursive_mutex is a Lockable, and Lockable's unlock() specifies very clearly what sort of conditions need to be met for the function to work: Precondition: The current thread owns *this. Effects: Releases ownership by the current thread. Postcondition: The current thread no longer owns *this. Throws: Nothing So there you have it, in my case the current thread does not own *this after l2's destructor ran - in fact, no thread does. Now there are a two inconsistencies here: 1. The code works fine with other Lockable implementations, such as non-recursive boost mutexes. 2. The behaviour is different depending on compilation mode. Yes, that's the idea behind asserts, but parts of the documentation suggest one behaviour is to be expected, other parts suggest the other is. From that I must draw the conclusion that either recursive_mutex and the unlock() documentation is broken, or the non-recursive mutexes are. Now conceptually, I'd expect unlock() to always succeed. That is, if it's postcondition can be fulfilled, it should always, regardless of compilation mode, exit cleanly. In that case the precondition docs should read something like "*this is either owned by the current thread, or by no thread at all.". I find that to be the case especially for recursive mutexes, as they're intended to be locked/unlocked multiple times in the same thread (though, technically, the calls should always be balanced). All of this is with version 1.35.0, but the docs for 1.36.0 don't seem to be different in the relevant areas. Maybe I'm missing something vital here. If so, I'd greatly appreciate any insight you guys might have. (Incidentally, I find it very hard to disable BOOST_VERIFY with a BOOST_DISABLE_ASSERTS define. I'll have to dig deeper where the re-enabling of asserts sneaks in, but on some machines that has no effect, on others it solves my particular problem, regardless of how correct or incorrect it might be.) Thanks, Jens

2 4

new libaray Boost.Fiber in vault
by k-oli＠gmx.de 03 Nov '08

03 Nov '08

Hello, I've added Boost.Fiber to the boost vault. The library implements lightweight threads of execution (context swapping; fibers on Windows). regards, Oliver

5 14

[1.37.0] Release package final QA
by Beman Dawes 03 Nov '08

03 Nov '08

The 1.37.0 release packages are up at http://boost.cowic.de/rc/ There will be a hold of several hours for last minute QA checks before these get pushed out to SourceForge. In the meantime, if anyone spots any showstoppers, please let us know right away! Thanks, --Beman

3 3

[MultiIndex] "Compatible Sorting Criterion"
by David Abrahams 02 Nov '08

02 Nov '08

The docs mention that the definition is cumbersome. I think you could probably do much better with a formulation that relies on the concept of being partitioned with respect to a predicate function. See www.open-std.org/jtc1/sc22/wg21/docs/papers/2001/n1313.html and the wording changes (now in the standard) at: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#270 -- Dave Abrahams BoostPro Computing http://www.boostpro.com

2 2

Negative Cycle Detection Code
by Paul De La Musica 02 Nov '08

02 Nov '08

Hi, Is there any negative cycle detection code in the public domain? We would prefer BGL based code but LEDA is fine too. Thanks, Paul

2 1