- Boost - lists.preview.boost.org

[Iostreams] code_converter from boost::iostreams fails with bidirection device
by Ferdinand Prantl 09 Jul '08

09 Jul '08

Hello, I would like to wrap an input/output stream buffer (std::streambuf) with boost::iostreams::code_converter to be able to use it both raw and with ont-the-fly encoding by the boost::iostreams::default_facet. namespace io = boost::iostreams; xxxstream stream; stream << "raw "; io::stream<io::code_converter<xxxiodevice> > wrapper(*stream.rdbuf()); wrapper << L"and converted"; I created a device wrapping std::streambuf. Pure input device (using io::source_tag) and pure output device (using io::sink_tag) were working. Combined device (using io::bidirectional_device_tag) failed with access violation in destructor (flushing and closing) of the io::code_converter in code_converter.hpp: template<typename Device, typename Codevt, typename Alloc> std::streamsize code_converter<Device, Codevt, Alloc>::write (const char_type* s, std::streamsize n) { buffer_type& buf = out(); ... std::codecvt_base::result result = // buf.eptr() was null here cvt().out( buf.state(), s + total, s + n, nint, buf.eptr(), buf.end(), next ); ... } I wondered how it is possible that the output buffer was not initialized. I learnt that the buffer was intentionally skipped in code_converter.hpp: template<typename Device, typename Codecvt, typename Alloc> struct code_converter_impl { ... void open(const Device& dev, int buffer_size) { ... // following condition is false for bidirectional if (can_write::value && !is_double::value) { buf_.second().resize(buffer_size); buf_.second().set(0, 0); } ... } ... }; The reason is the definition of a bidirectional device in categories.hpp: struct bidirectional : virtual input, virtual output, detail::two_sequence {}; It is detected in the io::code_converter turning off the initialization: typedef is_convertible<device_category, two_sequence> is_double; It means that I cannot use io::code_converter with io::bidirectional combining both io::input and io::output tags. Unfortunately I was not able to use these both explicitely: // original: typedef io::bidirectional_device_tag category; struct category : io::device_tag, io::input, io::output {}; The compiler complained about it with a message I was not able to fix: error C2784: 'std::basic_ostream<_Elem,_Traits> &boost::operator <<( std::basic_ostream<_Elem,_Traits> &,const boost::shared_ptr<Y> &)' : could not deduce template argument for 'std::basic_ostream< _Elem,_Traits> &' from 'boost::iostreams::stream<Device>' So far, I found just one working solution without changing boost sources - using two objects; one for reading, another one for writing: xxxstream stream; stream << "raw "; io::stream<io::code_converter<xxxidevice> > inwrapper(*stream.rdbuf()); io::stream<io::code_converter<xxxodevice> > outwrapper(*stream.rdbuf()); outwrapper << L"and converted"; However, I would like to use one object if it was possible. In my case, all writing is always finished before reading and vice versa. Encoding states in std::codecvt would not overlap. What would you suggest as a solution for input/output devices in io::code_converter? 1. Stick with the two objects - one for input, one for output. 2. Fix io::code_converter to accept devices with io::bidirectional tag. Either initialize both buffers or reuse the input one. 3. Use different tag than io::bidirectional. Which one? 4. Maybe I am wrapping std::streambuf in a wrong way. Is there another? I am attaching a simple example of a stripped source demonstrating the issue on std::stringstream. Thank you, Ferda

1 0

[Boost.Log1]: Bug in boost/log/detail/ts_posix.hpp
by Jens Seidel 09 Jul '08

09 Jul '08

Hi, I know that version 1 of John's logging library was never accepted and is probably not wildly used anymore nevertheless I found a nasty bug in it. It's strange but even after applying valgrind I found initially not the reason (probably I just assumed John's code is OK and it's something else) and it took some time until I resolved it. OK, for all users of this lib here is the patch: boost/log/detail/ts_posix.hpp: @@ -51,7 +51,7 @@ mutex & operator = ( const mutex & Not_Implemented); mutex( const mutex & From); public: - mutex() : m_mutex() { + mutex() : m_mutex(), m_count(0) { pthread_mutexattr_t attr; int res = pthread_mutexattr_init(&attr); assert(res == 0); I haven't checked whether this occurs in version 2 as well. Jens

3 3

Fusion Question
by Tom Brinkman 09 Jul '08

09 Jul '08

Heres a link to a simple unit test that demonstrates the layout library. http://www.reportbase.com/unit_test.hello.html

2 1

Re: [boost] How do you make MPL-compatible template meta-functions?
by joaquin＠tid.es 09 Jul '08

09 Jul '08

Daryle Walker escribió: > On Jul 9, 2008, at 3:02 AM, joaquin(a)tid.es wrote: > [...] >> You can use boost::mpl::equal to test this: >> >> BOOST_STATIC_ASSERT >> ( (boost::mpl::equal<distinct_integral_bit_counts, >> boost::mpl::list_c<int, 8, 16, 32> >::value) ); >> } >> >> Other than that, your type_to_digit_count is perfectly lambda- >> cabable AFAICS. HTH, >> > > Thanks. I switched to mpl::equal and it compiled. I later switched > to BOOST_MPL_ASSERT. (Remember to take _out_ the "::value" part!) I > originally had the "integral_c" part of "type_to_digit_count" as a > member called "type," instead of as a base class, then I switched > back and forth. Both ways work. Why is that? Because integral_c (and all other integral constant types in Boost.MPL) evaluates to itself, that is, it has the form: template<typename T, T N>struct integral_c { typedef integral_c<T,N> type; ... }; > And which way is best > (if they're not equally good, and without a better third alternative)? > I don't think it makes any difference in compile times or otherwise, but deriving from integral_c is terser and more MPL-idiomatic. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

How do you make MPL-compatible template meta-functions?
by Daryle Walker 09 Jul '08

09 Jul '08

Here's what I'm trying (to redo integer_test.cpp): //============================== #include <boost/config.hpp> #include <boost/limits.hpp> #include <boost/integral_c.hpp> #include <boost/mpl/list.hpp> #include <boost/mpl/transform.hpp> #include <boost/static_assert.hpp> #include <boost/type_traits.hpp> #include <climits> namespace { // List all the conventional integral types, without the ones that are like // a strong-typedef of a lower type typedef boost::mpl::list<unsigned char #if USHRT_MAX > UCHAR_MAX , unsigned short #endif #if UINT_MAX > USHRT_MAX , unsigned int #endif #if ULONG_MAX > UINT_MAX , unsigned long #endif #if defined(BOOST_HAS_LONG_LONG) && ((ULLONG_MAX > ULONG_MAX) || (ULONGLONG_MAX > ULONG_MAX)) , boost::ulong_long_type #elif defined(BOOST_HAS_MS_INT64) && (0xFFFFFFFFFFFFFFFFui64 > ULONG_MAX) , unsigned __int64 #endif > distinct_unsigned_types; typedef boost::mpl::transform<distinct_unsigned_types, boost::make_signed<boost::mpl::_1> >::type distinct_signed_types; // New type list: integral type -> (wrapped) number of bits template < typename T > struct type_to_digit_count : boost::mpl::integral_c<int, std::numeric_limits<T>::digits> { }; typedef boost::mpl::transform<distinct_unsigned_types, type_to_digit_count<boost::mpl::_1> >::type distinct_integral_bit_counts; BOOST_STATIC_ASSERT ( (boost::is_same<distinct_integral_bit_counts, boost::mpl::list_c<int, 8, 16, 32, 64> >) ); } //============================== I originally did not have that last line there with the "BOOST_STATIC_ASSERT," but I put it in after some errors when doing a compiler-sanity check while coding. I cleaned up the other errors, but the compiler complains that the first argument of "is_same," i.e. "distinct_integral_bit_counts," is an invalid template argument. I don't think my definition of "type_to_digit_count" is lambda-safe, like "make_signed" is. How do I get it that way? (Or is the problem in the definition of "distinct_integral_bit_counts"?) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

[test][gcc] return value support broken with "-pedantic"
by Juergen Hunold 09 Jul '08

09 Jul '08

Hi ! The latest changes to Boost.Test broke compilation with gcc in "pedantic" mode. This seems to be: http://svn.boost.org/trac/boost/changeset/47153 Just add "<toolset>gcc:<cxxflags>-pedantic" to libs/test/test/Jamfile.v2 and recompile. This will bail out with: gcc.compile.c++ /build/bjam/boost_1.36.0/libs/test/test/output_test_stream_test.test/gcc-4.2/debug/output_test_stream_test.o output_test_stream_test.cpp: In member function 'void test_constructor::test_method()': output_test_stream_test.cpp:30: error: ISO C++ forbids braced-groups within expressions I've disabled "return value support" locally (by commenting out test_tools.hpp line 86) but would like to have a conformant solution. Should we rise the warning level by _always_ activating "-pedantic" at least for the test suite ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

4 6

[test] Serious breakage - please fix or revert immediately
by Beman Dawes 09 Jul '08

09 Jul '08

Yesterday's changes to Boost.Tests appear to be breaking many libraries on gcc compiles. Please fix or revert immediately. --Beman Examples: ../boost/test/impl/test_main.ipp(40): error: destructible entities are not allowed inside of a statement expression BOOST_CHECK( test_main_result == 0 || test_main_result == boost::exit_success ); In file included from ../boost/test/minimal.hpp:37, from ../libs/crc/test/crc_test.cpp:23: ../boost/test/impl/execution_monitor.ipp:60:1: error: unterminated #if ../boost/test/impl/execution_monitor.ipp:24:1: error: unterminated #ifndef

2 2

Fusion Question
by Tom Brinkman 09 Jul '08

09 Jul '08

>> Have you looked into Adobe's Eve library, described in >> http://lambda-the-ultimate.org/node/563 Oh, yes. definately; and if its as good as Adobe's GIL library, I'm sure it would be a most welcome addition to boost. An Adobe sponsered layout engine would be very welcome, I'm sure. As you know, I use GIL extensively in my own graphics layout library. I think that it represents many of the best-practices that can be found on boost. As far as my own boost::layout library, I'd be happy to merge it with adobe's or just add extensions to it. I'll let you and others guide me on that.

3 3

[extension] Concatenating factory_map objects
by Robert Dailey 09 Jul '08

09 Jul '08

Hi, I'm developing a plugin system and I will be loading several DLLs. Basically, as far as I know, this means having one factory_map per DLL (on Windows). I need to concatenate either the factory_map objects or their maps so that I can do lookups in one map instead of several maps. Is there a recommended way of doing this? Right now this requires keeping all of the factory_map objects around (for cleanup purposes only) and having my additional global std::map, that contains the concatenated std::map's from the factory_map objects (it's essentially one large copy).

2 7

[extension] factory::create() constness
by Robert Dailey 09 Jul '08

09 Jul '08

Hi, Would it be possible to make boost::extension::factory::create() a const member function? I haven't taken the time to look at the implementation of create() myself, but if there's a possibility of that function becoming const I can make my wrapper interfaces const as well. I just have a feeling that a create method should not mutate the factory object at all, but I could be mistaken.

2 1

[gil] new opencv extension
by Christian Henning 08 Jul '08

08 Jul '08

Hi there, over the past few weeks I have rewritten the current opencv extension. Now there is a lot more functionality available as it was before. The following topics are covered: * converting colorspaces ( gray, rgb, rgba, xyz, hsv, hls, and lab ) * drawing primitives ( line, rectangles, circle, polyline, and text ) * edge detection ( sobel, laplace, canny, ... ) * resizing images( nearest neighbor, linear, area, and cubic ) * smoothing ( blur, gaussian, median, and bilateral ) As usual this extension is header only, but a user would need to make the opencv headers and libs available for compiling and linking. You can download the extension here using subversion: http://gil-contributions.googlecode.com/svn/trunk/gil_2 The folder structure is the same as with all boost libraries. There are some tests that can be used for testing and for learning the rather simple interface. Only the vc8 compiler has been used so far and though I would like ask for some assistance for making the extension compilable with gcc, for instance. Please give me some insight of what you think and about what functionality you might miss. I started to toy around with Tom Brinkman's idea of stacking up operations to batch process them which you can see in the drawing_test.cpp. Regards, Christian BTW: OpenCV is distributed with the BSD license and if I understand wikipedia correctly there isn't any objection using it in commercial applications. "The BSD License allows proprietary commercial use, and for the software released under the license to be incorporated into proprietary commercial products. Works based on the material may even be released under a proprietary license (but still must maintain the license requirements)."[wikipedia]

1 0

[date_time] Constructor copy-paste bug?
by Chris Newbold 08 Jul '08

08 Jul '08

While cleaning up GCC -Wshadow warnings in the date_time library, we've found what appears to be a copy-paste error in a date_generator_formatter constructor. The following constructor... //! Constructor that allows for a custom set of phrase elements date_generator_formatter(const string_type& first, const string_type& second, const string_type& third, const string_type& fourth, const string_type& fifth, const string_type& last, const string_type& before, const string_type& after, const string_type& of) { phrase_strings.push_back(string_type(first_string)); phrase_strings.push_back(string_type(second_string)); phrase_strings.push_back(string_type(third_string)); phrase_strings.push_back(string_type(fourth_string)); phrase_strings.push_back(string_type(fifth_string)); phrase_strings.push_back(string_type(last_string)); phrase_strings.push_back(string_type(before_string)); phrase_strings.push_back(string_type(after_string)); phrase_strings.push_back(string_type(of_string)); } ...takes a whole series of arguments, which it summarily ignores as the constructor body is an exact duplicate of that for the default constructor. Presumably the right fix is to push all of the given arguments into phrase_strings. -Chris

1 0

Newbie Trying to Build Boost Libraries on 64-bit MS Windows Vista
by Beverly Pope 08 Jul '08

08 Jul '08

Hi, I am a complete newbie at boost, who must compile several Boost 1.33.1 Libraries on 64-bit MS Windows Vista, using MS VS2005. I downloaded the 64-bit version of Python (python-2.5.2.amd64.msi) as well as bjam (boost-jam-3.1.16-1-ntx86.zip) and Boost 1.33.1 (boost_1_33_1.zip); I then installed Python and extracted the other two files, placing bjam in the PATH. I tried various things to build the libraries. I finally got some (not all) of them to build by setting MSVCDir, which makes the builds bypass running msvcvars32.bat. I am currently using the following to do the build (I've also tried --toolset=msvc, but that does not do any better): bjam ^ -sTools=8_0-amd64 ^ --prefix=%myBoostDir%\newboost ^ --builddir=%myBoostDir%\newboost ^ --debug-configuration ^ --with-python-root=%myPythonDir% ^ --with-python-version=2.5 ^ --with-pydebug ^ stage ^ > %myBoostDir%\logfile.txt 2>&1 1) I see numerous (21360) warnings like the following -- I don't know whether that is something that can be ignored? D:\work\intersect\boost_1_33_1\boost/config/abi_prefix.hpp(19) : warning C4103: 'd:\work\intersect\boost_1_33_1\boost\config\abi_prefix.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) 2) When building the libraries, I get the following errors when it tries to build object_protocol.cpp (three times) : vc-C++ d:\work\intersect\boost_1_33_1\newboost\bin\boost\libs\python\build\boost_python.dll\vc-7_1\debug\threading-multi\object_protocol.obj cl : Command line warning D9002 : ignoring unknown option '/Op' object_protocol.cpp D:\work\intersect\boost_1_33_1\libs\python\build\../src/object_protocol.cpp(110) : error C2664: '_PyEval_SliceIndex' : cannot convert parame ter 2 from 'int *' to 'Py_ssize_t *' Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast D:\work\intersect\boost_1_33_1\libs\python\build\../src/object_protocol.cpp(112) : error C2664: '_PyEval_SliceIndex' : cannot convert parame ter 2 from 'int *' to 'Py_ssize_t *' Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast D:\work\intersect\boost_1_33_1\libs\python\build\../src/object_protocol.cpp(137) : error C2664: '_PyEval_SliceIndex' : cannot convert parame ter 2 from 'int *' to 'Py_ssize_t *' Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast D:\work\intersect\boost_1_33_1\libs\python\build\../src/object_protocol.cpp(139) : error C2664: '_PyEval_SliceIndex' : cannot convert parame ter 2 from 'int *' to 'Py_ssize_t *' Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast Do I just need to change the cast or is something else going on? Thanks for your time. Bev

2 1

[release] merging doc changes?
by joaquin＠tid.es 08 Jul '08

08 Jul '08

Is it OK to merge documentation changes to the release branch? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

[fusion] fusion sequence of non-copy-constructible types
by Oliver Mueller 08 Jul '08

08 Jul '08

hello, at the last boostcon i had the chance to be introduced to fusion by dan and joel. i appreciate the idea of fusion a lot and the library amazingly detailed. since we have already had great exposure to the mpl the fusion concepts present ample opportunity for new ideas. still, some little things sometimes make it hard for me to keep rolling with fusion: i need to have a vector/list of non-copy-constructible types. using e.g. a standard fusion::vector that does not seem to be possible since objects are constructed first, then copied. of course, i could provide a public copy-constructor but that would in other places remove the compiler enforced contract that those objects are not copied under any circumstances. i also cannot think of a good reason why it is nesseccary to copy in that case. so is there a way of having a fusion sequence that does work on non-copy-constructible types? thanks for any suggestions, oliver

6 13

Re: [boost] [1.36.0] Libraries with unmerged changes?
by Jan Gaspar 08 Jul '08

08 Jul '08

Hi Thorsten, I've just found your emails in the spam folder. ?? Will merge the changes into the release branch. Jan ----- Original Message ---- From: Thorsten Ottosen <thorsten.ottosen(a)dezide.com> To: boost(a)lists.boost.org; Jan Gaspar <jano_gaspar(a)yahoo.com> Sent: Tuesday, 8 July, 2008 10:45:01 AM Subject: Re: [1.36.0] Libraries with unmerged changes? Beman Dawes skrev: > Below is a list of libraries whose header files appear to differ between > the trunk and branches/release. > circular_buffer I have had diffuculties reaching Jan regarding this library. There are some quite imortant changes here, especially for the default constructor. If we can't reach Jan soon, I wonder if I could just patch the constructor in the release branch for him? -Thorsten __________________________________________________________ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

1 0

Fusion Question
by Tom Brinkman 08 Jul '08

08 Jul '08

Joel de Guzman, I'd like to enhance my future boost::layout library proposal to use your boost::fusion. Here is a simple example of the boost::layout framework, that uses boost::gill as the view parameter. A boost::layout functor takes the following form: struct layer { template <typename view_t> void operator()(view_t& view) {} }; Examples of layers could be: fill_layer<> fill; border_layer<> border; text_layer<> text; Lets say I want to combine three layers into a single drawing operation. Currently, I do it like this: typedef boost::function<void (view_t&) > layer_t; layer_t layers[] = { fill_layer<>, border_layer<>, text_layer<> } draw_layers draw(layers,sizeof(layers)/sizeof(layer_t)); boost::gil::rgb8view_t view; draw(view); This works fine, but I would like to improve it by using boost fusion. Any suggestions or hints to get me started?

2 1

patch for NetBSD support
by brook＠biology.nmsu.edu 07 Jul '08

07 Jul '08

I tried to build boost-trunk on a NetBSD system. The following patch is required to get most of the way through (the math lib has additional errors). Because these changes are completely dependent on identifiers of NetBSD, I cannot see how they might negatively affect anything else. What is the procedure for getting this patch applied? Thanks for your help. Cheers, Brook =========================================================================== --- ./boost/config/platform/bsd.hpp.orig 2008-07-05 12:13:48.000000000 -0600 +++ ./boost/config/platform/bsd.hpp 2008-07-05 15:58:45.000000000 -0600 @@ -43,7 +43,7 @@ // // No wide character support in the BSD header files: // -#if !(defined(__FreeBSD__) && (__FreeBSD__ >= 5)) +#if !(defined(__FreeBSD__) && (__FreeBSD__ >= 5) || defined(__NetBSD__)) # define BOOST_NO_CWCHAR #endif // --- ./tools/build/v2/tools/python.jam.orig 2008-07-05 12:37:43.000000000 -0600 +++ ./tools/build/v2/tools/python.jam 2008-07-05 16:03:18.000000000 -0600 @@ -647,6 +647,8 @@ case darwin : return ; case windows : return ; + case netbsd : return <library>pthread <toolset>gcc:<library>util ; + case hpux : return <library>rt ; case aix : return <library>pthread <library>dl ;

2 2

Request for comments on changes to the dynamic_bitset docs
by Gennaro Prota 07 Jul '08

07 Jul '08

Hi, I just fixed the dynamic_bitset docs for issue #1591; the problem is with a couple of duplication of sentences of this kind: Note that the expression b1 & b2 is equivalent to creating a temporary copy of b1, using operator&=, and returning the temporary copy. I think such sentences are almost without meaning and should simply be dropped. The only concern is for "breaking a contract" in this case, though frankly I don't see what the user could sensibly rely upon. And "equivalent" is so generic, anyway. In case you agree with removing the sentences, would you note that in the section "Changes from previous version(s)"? -- Genny

1 0

[bimap] Excessive Compilation Memory Usage with VC8 - 1.35.0
by Bryan Petty 07 Jul '08

07 Jul '08

Hi, I've run into some serious problems getting my application to build after adding some usage of boost::bimap. In my application's case, a single bimap of any type causes the VC8 compiler to use more than 1GB of extra ram than it does normally (which is around 1GB). It compiles without errors, and runs flawlessly, but if I add a second bimap of any type elsewhere in my code, the additional ram usage becomes a problem and the build fails due to lack of sufficient memory to finish the compilation. These bimaps are declared and defined in a static library linked to my application which is setup with pre-compiled headers for that library. The compilation generally takes the most ram during compilation of the pre-compiled headers, and that's where this fails. This seems especially weird since from what I can tell, bimap is simply an implementation of boost::multi_index for a specific purpose, and we already make use of 4 different multi_index containers throughout our application without any memory consumption issues. I've taken the time to test this with a new skeleton Win32 project, and used the simple bimap example included with Boost. Without bimap, cl.exe only peaks at 3.25MB committed (measured with Process Monitor) in debug mode, but when I copy in the simple bimap example it peaks at 325MB committed in debug, and 148MB committed in release. I don't see anywhere near these kind of numbers with GCC on x86 linux, g++ stays around 3MB. System: Windows XP, VC8, 2GB RAM, Boost 1.35.0 One user on #boost experienced similar numbers when compiling with VC9 as well. When I add more bimaps in the simple example, it doesn't add as much of a jump as the first does, but it's still fairly significant (from 325MB to 360MB in debug with the second bimap). I have no idea how to go about debugging this. Regards, Bryan Petty

1 0

Reassigning tickets #1531 and #1591 to me?
by Gennaro Prota 07 Jul '08

07 Jul '08

Hi guys, I sent the same request yesterday, to the Moderators address, but didn't get any reply (sorry if this duplication causes any inconvenience): could someone with sufficient privileges reassign tickets #1531 and #1591 to me, so that I can close them? Or should I ask Jeremy? Thanks, -- Genny

2 2

How do I configure MPI?
by Daryle Walker 07 Jul '08

07 Jul '08

I'm trying out Boost.Build. I used to get warnings like: //=================================== warning: Graph library does not contain optional GraphML reader. note: to enable GraphML support, set EXPAT_INCLUDE and EXPAT_LIBPATH to the note: directories containing the Expat headers and libraries, respectively. warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (don't panic: this is a strictly optional feature). //=================================== I added a "using mpi ;" line, and now I'm getting errors like: //=================================== MPI auto-detection failed: unknown wrapper compiler mpic++ Please report this error to the Boost mailing list: http://www.boost.org You will need to manually configure MPI support. //=================================== So, how do I configure MPI support? Do I have to set up GraphML support first? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

determining if an object is faster to pass by value or const reference
by Michael Marcin 07 Jul '08

07 Jul '08

In general noone would write a function that took an int by const reference because doing so doesn't make sense from a performance standpoint. However often times we pass these trivial types to functions generically written to take const T&. It seems like type traits would make it simple to overload based on this convention. However I don't see a type trait that is fit for this use case. The has_trivial_copy trait would seem promising but it could return true for large pod objects that you wouldn't want to copy. The is_scalar trait seems promising but it will return false for lightweight user defined types and be suboptimal. Using has_trivial_copy together with some sizeof limit seems promising but a bit hand wavy. Is there a trait designed for this use case I'm overlooking? Thanks, Michael Marcin

5 10

Boost.Process 0.2 released
by Boris 07 Jul '08

07 Jul '08

I stumbled over Boost.Process some months ago. The library was created as a Google Summer of Code project in 2006 (see http://www.netbsd.org/~jmmv/process/) As I needed the functionality provided by this library and didn't manage to contact the author I went through the code myself to tidy it up, fix various bugs, convert the documentation to DocBook etc. I also added one minor but important improvement: With Boost.Asio 1.1 it's now possible to use asynchronous I/O (on Windows the macro BOOST_PROCESS_WINDOWS_USE_NAMED_PIPE must be defined as on Windows only named pipes support asynchronous I/O). I've been using the library myself only on Windows so far where it seems to work fine. I didn't make any tests yet on a POSIX platform. I didn't update the documentation yet much either. And I have no idea how to integrate the samples and test programs into Boost.Build (there are two Jamfiles but don't be surprised if they don't work :). As this library wasn't touched for nearly 2 years I don't know if there is any interest at all. As I had tidied up the code now anyway for my own purposes I provide a new snapshot for the community. You can find everything (including a link to download version 0.2) here: http://www.highscore.de/boost/process/ Boris

6 13

[test] test_tools.hpp: gcc-warnings patch
by Juergen Hunold 07 Jul '08

07 Jul '08

Hi ! The attached patch fixes two gcc warnings about unused parameters in BOOST_TEST_DONT_PRINT_LOG_VALUE. Okay to commit to trunk ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 2