September 2008 - Boost-users - lists.preview.boost.org

[Review] Phoenix review starts today, September 21st
by Hartmut Kaiser 21 Sep '08

21 Sep '08

Hi all, The review of Joel de Guzmans and Dan Marsdens Phoenix V2 library starts today, September 21st 2008, and will end on September 30th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists! --------------------------------------------------- About the library: The Phoenix library enables FP techniques such as higher order functions, lambda (unnamed functions), currying (partial function application) and lazy evaluation in C++. The focus is more on usefulness and practicality than purity, elegance and strict adherence to FP principles. History: Phoenix is a mature library from years of use as a sub-project under Spirit where it serves its purpose for semantic action handling. Phoenix predates Lambda's acceptance into Boost, but not Lambda itself. When Lambda was reviewed, it was concluded that both libraries were to be merged, and work on it began, culminating in Phoenix V2, what you are seeing now (an interesting offshoot of this effort is Boost.Fusion. We needed a powerful tuple facility with algorithms to get the design right). Recently, Eric Niebler did a (fully compatible) port to proto making use of boost.typeof for result type deduction. Eric's port, while significant, will not be the subject of the review, but can be regarded as the future of Phoenix (Phoenix V3). Phoenix V2 is currently a utility library included with Spirit V2 and therefore is already available from the latest Boost distributions (headers: $BOOST_ROOT/boost/spirit/home/phoenix, docs: $BOOST_ROOT/libs/spirit/phoenix, or http://www.boost.org/doc/libs/1_36_0/libs/spirit/phoenix/index.html) Phoenix V2 is a very important infrastructure library, IHMO. It has been used for several other library writing efforts already, most notably, Spirit V2. --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager

1 0

boost::filesystem exception not caught on MacOS X
by Lothar May 21 Sep '08

21 Sep '08

Hi, I have a strange problem that an exception thrown by a boost::filesystem directory_iterator is not caugth on MacOS X. Please consider the following code: ("const string &dir" is a parameter) bool retVal = true; try { directory_iterator i(dir); directory_iterator end; while (i != end) { // do something ++i; } } catch (...) { retVal = false; } While this works perfectly on Windows and Linux (the exception is caught fine), on MacOS I get the following: terminate called after throwing an instance of 'boost::filesystem::basic_filesystem_error<boost::filesystem::basic_path<std::string, boost::filesystem::path_traits> >' what(): boost::filesystem::basic_directory_iterator constructor Abort trap The program runs fine (withouth the trap) if I comment out the upper lines. I use the boost 1.34.0 lib built as universal binary on MacOS 10.5, according to the instructions at http://svn.boost.org/trac/boost/wiki/CMakeConfigAndBuild I link to the static non-debug mt version of boost_filesystem. Exceptions within my program are caught fine, just this boost exception is not caught. The program is also compiled as non-debug. Any help would be very much appreciated. Regards, Lothar

6 11

linking to boost thread exposes static initialisation order fiasco in ublas?
by David Philp 21 Sep '08

21 Sep '08

Hi This is a weird issue, and I'm by no means sure that my description is correct. It might be a newbie misunderstanding, but it is weird behaviour and I would appreciate any help in getting to the bottom of it. Here is a minimal example that exhibits the issue: ("zeromain.cpp") #include <boost/numeric/ublas/matrix_sparse.hpp> #include <boost/thread.hpp> int main (int argc, char * argv[]) { boost::numeric::ublas::coordinate_matrix<double> cm; cm.resize(3,3, false); return 0; } When compiled [with bjam release] and linked to libboost_thread it gives a "bus error". The backtrace is appended to this email. It works fine in debug mode. You can see that I have introduced boost.thread but not yet actually used the thread library in any way. If I take out either the include, or don't link to the lib, the bug goes away. Thanks in advance for any help or suggestions! Details below. David Mac OS X 1.5.5, boost 1.36. Intel CPU. The boost libraries are in $DYLD_LIBRARY_PATH. Jamroot contains exe zm : zeromain.cpp /sage//boost_thread : <include>boost ; ("sage" is a separate project whose Jamroot contains lib boost_thread : : <file>local/lib/boost/libboost_thread-xgcc40- mt-1_36.a ; It is a regular build of the boost libraries.) Backtrace: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 0x00001f24 in boost::numeric::ublas::coordinate_matrix<double, boost::numeric::ublas::basic_row_major<unsigned long, int>, 0ul, boost::numeric::ublas::unbounded_array<unsigned long, std::allocator<unsigned long> >, boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >::coordinate_matrix () (gdb) bt #0 0x00001f24 in boost::numeric::ublas::coordinate_matrix<double, boost::numeric::ublas::basic_row_major<unsigned long, int>, 0ul, boost::numeric::ublas::unbounded_array<unsigned long, std::allocator<unsigned long> >, boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >::coordinate_matrix () #1 0x8fe12e76 in __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE () #2 0x8fe0e723 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj () #3 0x8fe0e809 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE () #4 0x8fe04102 in __dyld__ZN4dyld24initializeMainExecutableEv () #5 0x8fe07b5f in __dyld__ZN4dyld5_mainEPK11mach_headermiPPKcS5_S5_ () #6 0x8fe01872 in __dyld__ZN13dyldbootstrap5startEPK11mach_headeriPPKcl () #7 0x8fe01037 in __dyld__dyld_start ()

4 7

Re: [Boost-users] Boost.Function - boost::function2 - too few template arguments
by Roma 21 Sep '08

21 Sep '08

> Hi! Trying to use Boost.Function - boost::function2 ... Sorry for stupid question ( . Please ignore it.

1 0

Bug: serialization of STL collections on Linux x86-64.
by Ivan Godard 21 Sep '08

21 Sep '08

In boost 1.35 on Linux on x86-64 an attempt to serialize any of the STL collections produces multiple definitions of implementation_level. Eventually I tracked these to the int64_t handling in collection_traits.hpp, where the following code appears: // determine if its necessary to handle (u)int64_t specifically // i.e. that its not a synonym for (unsigned) long // if there is no 64 bit int or if its the same as a long // we shouldn't define separate functions for int64 data types. #if defined(BOOST_NO_INT64_T) \ || (ULONG_MAX != 0xffffffff && ULONG_MAX == 18446744073709551615u) // 2**64 - 1 # define BOOST_NO_INTRINSIC_INT64_T #endif The bug is that the lengthy constant is just "u", and so will be compiler-truncated to unsigned int, 4 bytes on this platform, and so will fail to be equal to the 8-byte ULONG_MAX. Changing the "u" to "ul" fixes the bug. I don't know if this has already been fixed in 1.36; I don't have a copy handy. Ivan Godard

3 2

[DateTime]: Parsing RSS publishing dates
by Roland Bock 20 Sep '08

20 Sep '08

Hi, when parsing RSS, there are many date formats. For example: Fri, 19 Sep 2008 16:49:00 EDT Sat, 20 Sep 2008 11:25:00 +0100 I would like to write a single function which takes care of parsing this stuff and returns a GMT time. The attached code can take care of the format with the exception of the time zone. From what I read in the documentation and various other sources I take it that time zones like EDT cannot be automatically handled by BoostTime. But I would assume that it is not a big deal to take care of something like +0100? Sadly, I have no idea how to do that? Thanks and regards, Roland

2 2

a memory output stream
by Lloyd 20 Sep '08

20 Sep '08

Hi, I am a newbie and new to boost. In my program there is loop and in this loop it is reading a buffer full of data in each iteration, i want to append this data to a buffer. How can I do this with boost? sample code =========== int l=0; char* buff=new char[1024]; while(1) { //Here it is reading from a gziped buffer l = boost::iostreams::read(in,buff,1024); if(l != 1024) break; //how can I append this buff to a memory buffer thus to get a fully uncompressed data in another buffer?. } Thank you very much, Lloyd ______________________________________ Scanned and protected by Email scanner

1 0

Re: [Boost-users] Why something like #ifndef BOOST_MPI_HPP is alwayscapitalized?
by Peng Yu 19 Sep '08

19 Sep '08

Hi, I'm wondering how you would handle the following case. Suppose I have a set of mathematical formulas that has both bigger case and lower case variables (such as both 'X' and 'x'). This situation is pretty common. In order to implement them in C++, I could either write bigger cases as well as lower cases in C++, which is not in consistence with the convention that you mention. Or I have to convert bigger cases to lower cases, which is also not easy to read, as it is different from the original mathematical form. Which approach would you prefer? I would prefer the former one. Therefore, the convention is not followed. Thanks, Peng On Fri, Sep 19, 2008 at 3:06 PM, Peter McGill <petermcgill(a)goco.net> wrote: > It is a standard C++ convention to capitalize #defines and constants like > that. > There is no technical reason, it just makes them easy to identify. > Following common practice makes boost more accessible to many people. > > You should never have two header files which only differ in case. > Some file systems (ie. dos/windows) do not allow files which only differ in > case. > Technical reasons aside, having two files which only differed in case would > be > potentially hard to understand. It is much clearer to give them different > names. > > In both cases it is important to write understandable code, it is easier to > maintain. > > Peter McGill > IT Systems Analyst > Gra Ham Energy Limited > > > -----Original Message----- > > From: boost-users-bounces(a)lists.boost.org > > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Peng Yu > > Sent: September 19, 2008 3:47 PM > > To: boost-users(a)lists.boost.org > > Subject: [Boost-users] Why something like #ifndef > > BOOST_MPI_HPP is alwayscapitalized? > > > > Hi, > > > > In most of the C++ header files I've seem, a macro like the > > following is used to guard repetitive inclusion of the file. > > I'm wondering why it is always in upper case. Why not make it > > the same case as the file name? > > > > What if there are two header files on is in lower case, the > > other is in upper case? > > > > Thanks, > > Peng > > > > #ifndef BOOST_MPI_HPP > > > > > > > >

3 2

Why something like #ifndef BOOST_MPI_HPP is always capitalized?
by Peng Yu 19 Sep '08

19 Sep '08

Hi, In most of the C++ header files I've seem, a macro like the following is used to guard repetitive inclusion of the file. I'm wondering why it is always in upper case. Why not make it the same case as the file name? What if there are two header files on is in lower case, the other is in upper case? Thanks, Peng #ifndef BOOST_MPI_HPP

2 1

Re: [Boost-users] [test] memory access violation by calling <<-operator
by trashing＠gmx.net 19 Sep '08

19 Sep '08

> Why don;t you try to use output_test_stream instead. It's specifically > designed for this purpose. 'Cause, i don't know of them. But now I'm using output_test_stream . FYI: The stream wasn't the problem. I've testing a library and my test code and the library weren't compiled with the same compile flags. greetz, Manuel

1 0