- Boost-users - lists.boost.org

[boost][VS2005]
by Arpitha Inderjith (RBEI/EMT1) 22 Sep '08

22 Sep '08

I am using the VS2005 with BOOST.... my application is building but i am not able to run the application b'coz of this error :- "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix the problem."... i m using boost_1_35_0 libraries... can anyone help please?? thanks,

3 2

Merge Iterator
by Roland Bock 22 Sep '08

22 Sep '08

Hi, before I put it in the vault, I would like to hear from you guys what you think about the attached code. What is it about? A few days back, I asked for support for writing an iterator which merges sorted iterators. Andrew Bromage came up with some very good hints, asking me to publish my variant if I should come up with something nice. Well, attached is what I came up with (including a very simple usage example). Any feedback would be appreciated (including on how and where exactly to put it in the vault and if it would be welcome there :-) ). Thanks and regards, Roland

1 0

[serialization] serializing int*
by jens weller 22 Sep '08

22 Sep '08

Hello, Simple example: class A { int x; }; class B { int *px; }; There exists a list of B for each A, which points to x. When now serializing B: ar & px; I get an compiletime error, that t is of non classtype 'int'. :: === consoletests, Release === ..\..\code\boost_1_35_0\boost\serialization\serialization.hpp:74: instantiated from `void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::text_iarchive, T = int]' ..\..\code\boost_1_35_0\boost\serialization\serialization.hpp:133: instantiated from `void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::text_iarchive, T = int]' ..\..\code\boost_1_35_0\boost\archive\detail\iserializer.hpp:152: instantiated from `void boost::archive::detail::iserializer<Archive, T>::load_object_data(boost::archive::detail::basic_iarchive&, void*, unsigned int) const [with Archive = boost::archive::text_iarchive, T = int]' L:\project\consoletests\main.cpp:238: instantiated from here ..\..\code\boost_1_35_0\boost\serialization\access.hpp:109: error: request for member `serialize' in `t', which is of non-class type `int' ..\..\code\boost_1_35_0\boost\serialization\serialization.hpp:74: instantiated from `void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::text_oarchive, T = int]' ..\..\code\boost_1_35_0\boost\serialization\serialization.hpp:133: instantiated from `void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::text_oarchive, T = int]' ..\..\code\boost_1_35_0\boost\archive\detail\oserializer.hpp:144: instantiated from `void boost::archive::detail::oserializer<Archive, T>::save_object_data(boost::archive::detail::basic_oarchive&, const void*) const [with Archive = boost::archive::text_oarchive, T = int]' L:\project\consoletests\main.cpp:238: instantiated from here ..\..\code\boost_1_35_0\boost\serialization\access.hpp:109: error: request for member `serialize' in `t', which is of non-class type `int' :: === Build finished: 10 errors, 18 warnings === This error does not refer to the class it self, but it only occurs, when serializing int* in my application. Is this a bug? Or is this a thing serialization can't do right now? I've got a workaround, so I don't need to save the px variable, but I'd like to know if this is an error or not. regards, Jens Weller

2 2

[boost-users][logging] dymamic creation of multiple loggers?
by Igor R 22 Sep '08

22 Sep '08

Hello, In my project I have to create loggers dynamically and spread logging info over sevral files (each logger writes to its own file, each file covers some "thread" of activity). However, all the examples show global log definitions only, so probably dynamic creation of multiple loggers is a missuse of the library? Is it possible to route messages to different files by means of one single logger? Thanks.

1 0

assert (crc2.checksum() == crc1) failed in sample of Augmented-CRC Functions
by Alexander Vinokur 22 Sep '08

22 Sep '08

Hi, I run the sample of Augmented-CRC Functions on Microsoft Visual C++ 2005 But assert(crc2.checksum() == crc1) failed. http://www.boost.org/doc/libs/1_36_0/libs/crc/crc.html#crc_basic Augmented-CRC Functions // Main function int main () { using boost::uint16_t; using boost::augmented_crc; uint16_t data[6] = { 2, 4, 31, 67, 98, 0 }; uint16_t const init_rem = 0x123; uint16_t crc1 = augmented_crc<16, 0x8005>( data, sizeof(data), init_rem ); uint16_t const zero = 0; uint16_t const new_init_rem = augmented_crc<16, 0x8005>( &zero, sizeof(zero) ); boost::crc_basic<16> crc2( 0x8005, new_init_rem ); crc2.process_block( data, &data[5] ); // don't include CRC assert( crc2.checksum() == crc1 ); std::cout << "All tests passed." << std::endl; return 0; } Alex Vinokur This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp

1 0

[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