- Boost - lists.boost.org

tcmalloc and boost::diagnostic_information
by Daniel Larimer 14 Jun '10

14 Jun '10

I have some code that works fine on Mac OS X. I then switched it to use tcmalloc and it crashes when I attempt to use boost::diagnostic_information to print out information about an exception. #0 0x00007fff81298886 in __kill () #1 0x00007fff81338eae in abort () #2 0x000000010076ece3 in TCMalloc_CRASH_internal () at spinlock.h:104 #3 0x000000010076ee4b in TCMalloc_CrashReporter::PrintfAndDie () at spinlock.h:104 #4 0x000000010076c586 in (anonymous namespace)::InvalidFree (ptr=<value temporarily unavailable, due to optimizations>) at src/tcmalloc.cc:372 #5 0x000000010004171a in boost::units::detail::demangle (name=0x100258ac0 "N5boost16exception_detail10clone_implIN2fl5error14future_timeoutEEE") at utility.hpp:48 #6 0x0000000100046456 in boost::exception_detail::diagnostic_information_impl (be=0x101b00080, se=0x101b00070, with_what=true) at diagnostic_information.hpp:140 #7 0x00000001000466b9 in boost::diagnostic_information<boost::exception> (e=@0x101b00080) at diagnostic_information.hpp:156 Has anyone here seen this problem? I do not know whether this is a bug with tcmalloc or boost, but I would really like to use tcmalloc because it gives me a 10-50% performance increase when I am not throwing exceptions.

4 6

Re: [boost] [endain_ext] Beman's Integer.Endian extensions to work with endian unaware data
by Dave Handley 14 Jun '10

14 Jun '10

Vicente Botet wrote: > Tom's swap_in_place force to interpret all the fields of the structure with the same endianness. Do you have a use case for the situation where fields of a structure have different endianness? It seems a lot of complexity to add if there isn't a strong use case. Dave

2 1

[contract] non-public subcontracting (N1962)
by Lorenzo Caminiti 14 Jun '10

14 Jun '10

Hello all (and N1962 authors especially), How should subcontracting work for non-public base classes? I have listed a few examples below. Assume contracts were written for all these example classes (invariants) and their functions (pre/post conditions). My questions are: A) `c::p()` should subcontract; but what about any of the other member functions of `c`, should any of them subcontract also? B) Am I missing any other combination of member/inheritance access level significant for deciding when to subcontract? class bp { public: virtual void p(void) { std::cout << "bp called" << std::endl; } }; class bf { protected: virtual void f(void) { std::cout << "bg called" << std::endl; } }; class bg { public: virtual void g(void) { std::cout << "bg called" << std::endl; } }; class bh { public: virtual void h(void) { std::cout << "bh called" << std::endl; } }; class c: public bp, public bf, protected bg, private bh { public: // This should subcontract. virtual void p(void) { bp::p(); } // Should any of the following subcontract also? virtual void f(void) { bf::f(); } virtual void g(void) { bg::g(); } virtual void h(void) { bh::h(); } // Am I missing any other relevant combination? }; (I do not think multiple inheritance is relevant for my questions. I am using multiple inheritance in this example just so to have only one derived class `c` which exercises all the use cases.) My notes and questions: 1) All member functions of `c` are public so they will check their pre/post conditions as in `c` and `c` class invariants. 2) But shall any `c` member functions also check their base class invariants and/or base function pre/post conditions? 3) `c::p()` should subcontract `bp::p` pre/post and `bp` inv because it is a public function publicly inheriting from a base public function. ** 4) Maybe `c::f()` should subcontract `bf::f()` pre/post but not `bf` invariant... (because `bf::f` is protected thus it does not have to check `bf` invariant). ** ** 5) Should `c::g()` and `c::h()` subcontract given that their inheritance is not public? ** Thank you very much. -- Lorenzo

2 5

[boost::endian] Summary of discussion #1
by Tomas Puverle 14 Jun '10

14 Jun '10

Thank you everyone for your contributions. It seems the activity is dying down a little and some consensus has been reached, so I decided to summarize the thread here for my and other people's benefit. Unanswered question: One question which I posed in the original thread and didn't get picked up by anyone was to do with the metafunction is_mutable_range<T>. I use it to determine whether T is a range as opposed to just a value. I was suggesting is_mutable_range<> and is_const_range<> could be added to Boost.Range but nobody had any opinions. Basic interface: There were many suggestions for changes/improvements but in the end, it seemed that the proposed functional interface was generally ok. Beside the two functions swap<>() and swap_in_place<>(), there was a desire for two simpler alternatives, to<>() and from<>(), which would imply the "host" portion, i.e. swap<host_to_{little/big}>() would be equivalent to to<{little/big}>() and swap<{little/big}_to_host>() would be equivalent to from<{little/big}>(). The idea of "network" being a synonym for "big" was raised but ultimately rejected, due to the fact that the library shouldn't be tied to any particular device/protocol. Floating point values: There is a potential issue with swapping floating point values. This will be resolved by limiting the contexts in which swap<>, from<> and to<> can be used. Typed vs untyped: One of the most contentious issues of the whole thread, I think both sides have accepted that there is value in the other side's approach (or, at the very least, I don't see how my library is going to make it through the review unless I implement it :) Having said that, as the typed interface ultimately relies on copying of data, there may have to be some limitations on floating point values. Bitfields: There was some desire for generic bit swapping/bit fields. I have some ideas on this but for now I would prefer to concentrate on the byte-swapping issues and revisit this in the future. This seems like a reasonable plan for implementation. Thanks again for all the input. Tom

10 68

[xint] Fourth release, requesting preliminary review again
by Chad Nelson 14 Jun '10

14 Jun '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The next, and hopefully final, iteration of the Extended Integer library (a arbitrary-length integer math library) is now available in the sandbox (at <https://svn.boost.org/svn/boost/sandbox/xint>) and the Vault (at <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=xint.z…>). It incorporates almost all of the suggestions offered on this list. The highlights of this release are: * It's now a header-only library. It can still be compiled if you wish (I use the compiled version for most of my testing), but that's no longer required. * The user-visible classes (integer, nothrow_integer, and fixed_integer) are all now templates, with parameters for an allocator, thread-safe operation, and "secure mode" (zeroing all memory before releasing it). * Thread-safe operation is now the default. It's slightly slower that way, but not much, because the library still uses a copy-on-write system for internal functions (where it's safe because variables allocated there can never be seen across thread boundaries). Every object is given its own storage before it's returned to the non-library caller. I've included my testing projects as well, for CodeLite under Linux and Visual Studio under Windows, for convenience. It includes a slightly older version of Ion Gaztañaga's preliminary Move library too. I haven't tested it with the current version, but it should work with that as well. The Move library is not used by default, and makes only a slight difference to the speed when thread-safety is enabled. I plan to add a few more examples, but what's there should be sufficient to get people started. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwFDsoACgkQp9x9jeZ9/wR4GwCfQ3LMFyQZIuNZC71qEgDQR1fG uLwAoKR3cMA3Be859DxYgz56GsGlCqE9 =o62S -----END PGP SIGNATURE-----

16 71

[msm] Message queue and copy constructed events
by Michael.Herchel＠rohde-schwarz.com 14 Jun '10

14 Jun '10

Hi Christopher, in case we use message queueing in our state machines (which we actually have to because otherwise the pseudo exit state behaviour will not work correctly) our events have to implement a copy constructor because there is a possibility that some of them are queued. We do not want that events get copied because they are very big and it certainly decreases our performance. Could you not just store pointers to events so that the events do not get copy constructed again? Our understanding of the queuing implementation is that the event instance is valid as long as the outer most process_event() is not returned to the caller. In that case it is not a problem to just store those pointers. We also could use shared pointers as events and so only the shared pointers get copy constructed. But this would mean that we have to put all our events into shared pointers which also decreases performance and it would look like strange passing shared pointer as reference to the process_event() method. Do you have another idea in order to overcome this? At the moment, we can not think of a proper solution for deferred events. In that case there would be no other solution than copy deferred events. Anyway, we would like to have a mechanism in order to influence the queue implentation and change it to a user definied implementation. Would it be possible to pass the queue type as an optional template argument to the state machine? This would the make state machine even more flexible and one does not have to use std::queue. Regards, Michael

1 0

[endain_ext] Beman's Integer.Endian extensions to work with endian unaware data
by vicente.botet 14 Jun '10

14 Jun '10

Hi, I have a implemented a prototype that allows to make endian conversions in place respect to an endian point of view (domain) of endian unaware data. The point of view is represented by a map from the native data types to an endian tree, which have mpl sequences as nodes and the leaves are the endianess of the integer types. namespace endian { struct big {}; struct little {}; # ifdef BOOST_BIG_ENDIAN typedef big native ; # elsif BOOST_LITTLE_ENDIAN typedef little native ; # error "Endian not detected." # endif } Two functions to convert any data in place are provided: template <typename Domain, typename T> void convert_from(T& r); template <typename Domain, typename T> void convert_to(T& r); The default implementation works for fusion sequences. So the user will need to adapt the structures so them are viewed as fusion sequences or overload the functions. Next follows an example that defines 3 structures, and a point of view (domain) that see one of then as big, the second as little and the third as a mix of big and little. using namespace boost; // native structs definition namespace X { struct big_c { uint32_t a; uint16_t b; }; struct little_c { int32_t a; int16_t b; }; struct mixed_c { big_c a; little_c b; }; } // definition of a point of view (domain) struct network {}; // mapping of native types to an endian tree for the network point of view (domain) namespace boost { namespace endian { template <> struct domain_map <network, X::big_c> { typedef mpl::vector<big,big> type; }; template <> struct domain_map <network, X::little_c> { typedef mpl::vector<little,little> type; }; }} // view of the structures as fusion sequences BOOST_FUSION_ADAPT_STRUCT(X::big_c, (uint32_t, a) (uint16_t, b) ) BOOST_FUSION_ADAPT_STRUCT(X::little_c, (int32_t, a) (int16_t, b) ) BOOST_FUSION_ADAPT_STRUCT(X::mixed_c, (X::big_c, a) (X::little_c, b) ) int main( int argc, char * argv[] ) { X::mixed_c m; // fill with data from the 'network' domain (emulating the reception from the domain 'network') m.a.a=0x01020304; m.a.b=0x0A0B; m.b.a=0x04030201; m.b.b=0x0B0A; std::cout << std::hex << m.a.a << std::endl; std::cout << std::hex << m.a.b << std::endl; std::cout << std::hex << m.b.a << std::endl; std::cout << std::hex << m.b.b << std::endl; // convert from the network to the native domain endian::convert_from<network>(m); std::cout << std::hex << m.a.a << std::endl; std::cout << std::hex << m.a.b << std::endl; std::cout << std::hex << m.b.a << std::endl; std::cout << std::hex << m.b.b << std::endl; // work with the native variable // ... // convert from the native to the network domain endian::convert_from<network>(m); std::cout << std::hex << m.a.a << std::endl; std::cout << std::hex << m.a.b << std::endl; std::cout << std::hex << m.b.a << std::endl; std::cout << std::hex << m.b.b << std::endl; return 0; } The result is: 1020304 a0b 4030201 b0a 1020304 a0b 4030201 b0a 1020304 a0b 4030201 b0a The library could define three predefined maps for the domain endian::native, endian::big, endian::little, which maps every leaf to the corresponding endian type. I have not see the assembler generated, but the design is there to do nothing when the in place conversion concerns the same endianness. The library is based on the one from Beman's. * I have split the the endian class on two levels: - endian_pack - endian. * replaced the enum class endianness by a endianness tag (see above) * I have added an endian_view class that is a reference to a native type viewed with a specific endianess (a kind of endian_cast). * An last I have added on top the requested 'in place conversion' functions. The last two features work with endian anaware data. I could add pure conversions if needed on endian anaware data. The used names for functions and classes and under what namespace put them should yet be determined. All the sources can be found in the sandbox under http://svn.boost.org/svn/boost/sandbox/endian_ext. Documentation will come later :(. As always, comments are welcome :) _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

2 4

Re: [boost] [Boost-users] [mini-review] Update of Boost.Assign (13th-19th of June)
by Christopher Jefferson 14 Jun '10

14 Jun '10

On 14 Jun 2010, at 14:57, er wrote: > Christopher, thanks for inquiring. > >> and: >> make<std::vector>(1,2,3,4,5); // Makes a std::vector<int> containing 1,2,3,4,5 >> make_list(1,2,3,4,5); // Makes a list which can be assigned to any standard container, filling it with 1,2,3,4,5. > > Something similar is already possible before the proposed extension e.g. > > list_of(1)(2)(3)(4)(5).convert_to_container<std::vector<int> >(); > std::vector<int> vec = list_of(1)(2)(3)(4)(5); Certainly this doesn't add anything new. Personally I prefer the look of (1,2,3,4,5) over (1)(2)(3)(4)(5), now that the core language supports it efficiently. Chris

1 0

Final results of the June 2009 bug sprint
by Marshall Clow 14 Jun '10

14 Jun '10

The bug sprint is now over. Yesterday's activity: New tickets: 3 Modified: 7 Closed: 12 Reopened: 1 The final ticket counts by day were: Saturday 989 Sunday 988 Monday 958 Tuesday 938 Wednesday 894 Thursday 854 Friday 824 Saturday 806 Sunday 789 Monday 781 We closed 208 open tickets in a single week. That's more than 20% of all the open tickets. Thank you to everyone who helped! [ Channeling the release managers: Please don't forget to merge your changes to the release branch after the tests have cycled ] Here's the breakdown by type of ticket: Ticket Type Start Finish Change ------------------------------------------ Bugs 613 454 -159 Feature Requests 238 221 - 17 Patches 95 71 - 24 Tasks 27 22 - 5 Support Requests 15 13 - 2 Library Submissions 1 0 - 1 Top 10 libraries (counted by number of tickets at the start of the bug sprint): Library Start Finish Change -------------------------------------- thread 76 37 -39 date_time 55 47 -8 Python 48 43 -5 test 43 16 -27 interprocess 40 40 0 iostreams 37 34 -3 filesystem 36 21 -15 mpl 36 32 -4 quickbook 33 30 -3 asio 31 26 -5 Top 10 bug owners (counted by number of tickets at the start of the bug sprint): User Start Finish Change ---------------------------------- anthonyw 75 38 -37 djowel 71 47 -24 dave 58 41 -17 igaztanaga 58 58 0 az_sw_dude 53 45 -8 vladimir_prus 49 56 +7 bemandawes 46 36 -10 rogeeff 43 16 -27 agurtovoy 36 32 -4 turkanis 36 33 -3 Useful reports: https://svn.boost.org/trac/boost/report/1 -- full list of tickets https://svn.boost.org/trac/boost/report/18 -- ticket counts by owner https://svn.boost.org/trac/boost/report/19 -- ticket counts by component https://svn.boost.org/trac/boost/report/20 -- ticket counts by ticket type https://svn.boost.org/trac/boost/report/21 -- ticket counts by milestone I'll be playing with some generating some graphs in the next couple days, and when I get them, I'll put them up on the Wiki. Thanks again, everyone! -- Marshall

2 1

1.43 build broken on MSVC 8.0
by Stephan Menzel 14 Jun '10

14 Jun '10

Hi there, I was just trying to compile 1.43 on Windows 64 bit for some hours now and unfortunately from my perspective it looks like the modified build system may be a bit broken. First of all, bootstrap.bat didn't work anymore. As usual I was using it to create bjam.exe but this time it just went into causing heavy load and after about 15 minutes it returns telling me the command line is too long. As always, I just did this: ./bootstrap.sh This used to work but not anymore. So I downloaded a precompiled bjam.exe (3.18) and went with that instead. Alas, it created a 32 bit build just fine but failed to produce a 64 bit build. It appears like it is compiling all objects for 64 bit but then tries to link with /MACHINE:X86 , causing the linker to complain: ... common.mkdir bin.v2\libs\math\config\msvc-8.0\debug\threading-multi compile-c-c++ bin.v2\libs\math\config\msvc-8.0\debug\threading-multi\has_long_double_support.obj has_long_double_support.cpp compile-c-c++ bin.v2\libs\math\build\msvc-8.0\debug\threading-multi\sph_neumannf.obj sph_neumannf.cpp msvc.link.dll bin.v2\libs\math\build\msvc-8.0\debug\threading-multi\boost_math_tr1f-vc80-mt-gd-1_43.dll bin.v2\libs\math\build\msvc-8.0\debug\threading-multi\assoc_laguerref.obj : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86' call "C:\Program Files (x86)\Microsoft Visual Studio 8\VC\BIN\amd64\vcvarsamd64.bat" x86 >nul link /NOLOGO /INCREMENTAL:NO /DLL /DEBUG /MACHINE:X86 /subsystem:console /out:"bin.v2\libs\math\build\msvc-8.0\debug\thr eading-multi\boost_math_tr1f-vc80-mt-gd-1_43.dll" /IMPLIB:"bin.v2\libs\math\build\msvc-8.0\debug\threading-multi\boost_m ath_tr1f-vc80-mt-gd-1_43.lib" @"bin.v2\libs\math\build\msvc-8.0\debug\threading-multi\boost_math_tr1f-vc80-mt-gd-1_43 .dll.rsp" if %ERRORLEVEL% NEQ 0 EXIT %ERRORLEVEL% ...failed msvc.link.dll bin.v2\libs\math\build\msvc-8.0\debug\threading-multi\boost_math_tr1f-vc80-mt-gd-1_43.dll bin.v2 \libs\math\build\msvc-8.0\debug\threading-multi\boost_math_tr1f-vc80-mt-gd-1_43.lib bin.v2\libs\math\build\msvc-8.0\debu g\threading-multi\boost_math_tr1f-vc80-mt-gd-1_43.pdb... ... I've tried all sorts of command lines and user-config.jam I could think of, but no effect. Here's what I usually do: ./bjam.exe --architecture=amd64 --address-model=64 -j2 link=shared threading=multi variant=debug,release stage Please let me add that I've been doing this since 1.34 and somehow always managed to get the job done so I have reason to assume there's something that must have changed in this release that broke it. I also tried the switch ---architechture=amd64 and many others I thought might help. I also delete everything already compiled before retrying. The system is Windows XP, current SP and MSVC 8, also current SP. Here's my user-config.jam: ...... using msvc : 8.0 : "C:\\Program Files (x86)\\Microsoft Visual Studio 8\\VC\\BIN\\amd64\\cl.exe" : <setup>"C:\\Program Files (x86)\\Microsoft Visual Studio 8\\VC\\BIN\\amd64\\vcvarsamd64.bat" ; using python : 2.5 ; # Make both versions of Python available using python : 2.5 : "C:\\Program Files\\Python25_64\\python.exe" : "C:\\Program Files\\Python25_64\\include" : "C:\\Program Files\\Python25_64\\libs" : <toolset>msvc ; ....... I also tried to copy the 'tools' folder from 1.42 where it used to work and also the Jamroot and project-config.jam but it still produced the same error. Can anyone give me a hint if there's an issue with the build system in this release? Cheers, Stephan

7 16