- Boost - lists.preview.boost.org

[proto] small breaking change
by Eric Niebler 15 Jun '10

15 Jun '10

I just made a change to proto in the effort to reduce compile times. There's a new expression type, proto::basic_expr, that is lighter weight than proto::expr in that it doesn't define the operator=, operator[] and operator() member functions. It's ideal as a base when extending expressions with proto::extends or BOOST_PROTO_EXTENDS. You'll get basic_expr instead of expr automatically if you use either of proto::generator or proto::pod_generator. That could surprise you if you were expecting to get an expr, so beware. Most normal uses of Proto will just work with this change, though, and if you measure you should see a modest improvement in your compile times. Please let me know if this breaks your code. -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 22

[trac] more spam
by Steven Watanabe 15 Jun '10

15 Jun '10

AMDG Here: https://svn.boost.org/trac/boost/ticket/1633 In Christ, Steven Watanabe

2 1

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

config with cygwin
by Robert Ramey 14 Jun '10

14 Jun '10

I've recently upgraded to the lastest version of Cygwin and found that this current version supports wchar_t, wstring, etc This section from config/platform/cygwin is now creating problems. // cygwin specific config options: #define BOOST_PLATFORM "Cygwin" #define BOOST_NO_CWCHAR #define BOOST_NO_CWCTYPE #define BOOST_NO_SWPRINTF #define BOOST_HAS_DIRENT_H #define BOOST_HAS_LOG1P #define BOOST_HAS_EXPM1 as it conflits with the following from config/stdlib/libstdcp3 #if !defined(_GLIBCPP_USE_WCHAR_T) && !defined(_GLIBCXX_USE_WCHAR_T) # define BOOST_NO_CWCHAR # define BOOST_NO_CWCTYPE # define BOOST_NO_STD_WSTRING # define BOOST_NO_STD_WSTREAMBUF #endif I've found that BOOST_NO_STD_WSTRING is NOT defined while BOOST_NO_CWCHAR IS defined. This is incorrect for the latest version of cygwin - version 1.7.5 and likely previous versions. I believe that config/platform/cygwin should be updated so that it looks like: #define BOOST_PLATFORM "Cygwin" #define BOOST_NO_SWPRINTF // ? don't know about the rest of these #define BOOST_HAS_DIRENT_H #define BOOST_HAS_LOG1P #define BOOST_HAS_EXPM1 according to the cygwin documentation - there is no place to retrieve a version # for cygwin itself - only for specific packages. So it would seem that that's all we can/should do. Robert Ramey

3 3

[program_options] Proposed feature to provide option namespace prefixing
by Monty Taylor 14 Jun '10

14 Jun '10

Hi! I'm a developer on the Drizzle project, and we're currently replacing the home-grown getopt wrapper we inherited from the MySQL codebase with Boost.Program_options. So far, we're thrilled and it's going great, so thanks! We've focused on the client utilities to start, but as we're coming up on the server, we have an issue that we have an internal solution for, but which seems like it might be something that could be more generally useful, so I thought I'd mention it here, and if there is any interest, I can work up a proper code submission. The situation has to do with plugin modules and option names. In our current system, we enforce an option name prefix that matches the module name. For instance, if you are the InnoDB plugin author, you would declare an option named "buffer_pool_size" which would be presented to the user as "--innodb_buffer_pool_size", and the server/plugin registration handles prepending the module name to the option name for you. (you cannot choose to not do this) For those following along at home, you'll notice the _ we're using for the concatenation - we're happy changing that to be a "." so that the program_options config file sections will work in a sensible way. Our approach to doing this with Boost.Program_options at the moment is to wrap options_description_easy_init in a class. Something like: class DRIZZLED_API options_context { const std::string &module_name; po::options_description_easy_init &po_options; std::string prepend_name(const char *name); public: options_context(const std::string &module_name_in, po::options_description_easy_init &po_options_in); options_context& operator()(const char* name, const char* description) { std::string new_name(module_name); new_name.push_back('.'); new_name.append(name); po_options(new_name.c_str(), description); return *this; } ... }; Then in server plugin registration, a context is created around the real program_options and is is handed to the plugin module: module.register_options(options_context(module.get_name(), commandline_options.add_options()); It seems like a possibly nicer or more integrated approach would be something that would look like this: module.register_options(commandline_options.add_options(module.get_name()); And given the mapping of config file sections to name-dotted prefixes, it seems like it wouldn't be a ridiculous addition. Is anybody interested in me reworking what we end up with to be usable or applicable back to the Boost core? Thanks! Monty

3 3

[GSoC][Phoenix3] Regarding mutability of arguments passed to phoenix expressions
by Thomas Heller 14 Jun '10

14 Jun '10

Regarding arguments to phoenix expressions there are two possibilities. The first is: Arguments are mutable. The current phoenix is implemented to be able to this. Example: int i( 1 ); ( ++phoenix::arg_names::arg1 )( i ); The result of ++phoenix::arg_names::arg1 will be 2, i will have the value 2 after the expression is evaluated. The other approach would follow a more functional programming style as the data will not be mutable int i( 1 ); [1] ( ++phoenix::arg_names::arg1 )( i ); [2] ( ++phoenix::arg_names::arg1 + phoenix::arg_names::arg1 )( i ); The result of [1] will be 2, however i does not get changed (it remains to be 1). The result of [2] will be 3. i still unchanged. This example would be working "out-of-the-box" with the current prototypes. To get the mutability back into phoenix i propose the use of phoenix::ref. I favor the second approach. However, this would break API compatibility between the existing implementation. The question i want to ask the current and prospective users if it feasible to break your existing code? Is there a lot of existing code depending on this behaviour? Does it make sense to break code in such a way? Regards, Thomas

10 28

[property_tree] handling of filesystem::path
by Johan Råde 13 Jun '10

13 Jun '10

property_tree::ptree does not handle filesystem::path values correctly if the path contains spaces. Here is a proposed fix and a test. The test succeeds, but if you comment out the patch, then the test fails. ---------------------------------------------------------------------------------- #include <boost/property_tree/ptree.hpp> // patch that fixes the problem namespace boost { namespace filesystem { template<class String, class PathTraits> class basic_path; }}; namespace boost { namespace property_tree { template<typename String, typename PathTraits> struct path_translator { typedef boost::filesystem::basic_path<String, PathTraits> Path; typedef String internal_type; typedef Path external_type; boost::optional<Path> get_value(const String& s) { return Path(s); } boost::optional<String> put_value(const Path &p) { return p.string(); } }; template <typename Char, typename StringTraits, typename Alloc, typename PathTraits> struct translator_between< std::basic_string<Char, StringTraits, Alloc>, boost::filesystem::basic_path<std::basic_string<Char, StringTraits, Alloc>, PathTraits> > { typedef std::basic_string<Char, StringTraits, Alloc> String; typedef path_translator<String, PathTraits> type; }; }} // a simple test #include <boost/filesystem/path.hpp> #include <boost/optional.hpp> using boost::filesystem::path; using boost::optional; using boost::property_tree::ptree; int main() { path p1("a b"); ptree t; t.put_value(p1); optional<path> p2 = t.get_value_optional<path>(); assert(p2); assert(p1 == *p2); }

3 3

Bug sprint daily update for Sunday, June 13th
by Marshall Clow 13 Jun '10

13 Jun '10

We're almost done! As of 0645 Pacific time today, we had 789 open trac tickets. That is down by 17 from yesterday, and 200 since the start of the bug sprint! <louder> Let me say that again: We have closed 200 tickets since the start of the bug sprint. </louder> Congratulations to everyone who has been helping. Today is the last day of the bug sprint. If you've been working on something, today is the day to finish it! Total ticket counts: Saturday 989 Sunday 988 Monday 958 Tuesday 938 Wednesday 894 Thursday 854 Friday 824 Saturday 806 Sunday 789 Activity summary for yesterday (I'm counting tickets by hand here, here so blame my crummy math if it doesn't add up) New tickets: 4 Modified: 7 Closed: 21 Reopened: 0 Today, rather than the summary totals for yesterday, I have deltas; changes in the totals. If you would like to see the totals, they are available online at: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 (All changes are since the start of the bug sprint; 0800 PDT Saturday June 5th) Changed totals by library: thread -39 test -27 None -17 fusion -14 website -10 string_algo -9 filesystem -8 variant -7 date_time -6 function -6 iterator -6 concept_check -5 multi_array -5 Getting Started Guide -4 Python -4 mpl -4 random -4 tuple -4 asio -3 lambda -3 units -3 Building Boost -2 dynamic_bitset-2 foreach -2 lexical_cast -2 tokenizer -2 GIL -1 Regression Testing -1 assign -1 function_types -1 graph -1 io -1 iostreams -1 mpi -1 parameter -1 pool -1 regex -1 signals2 -1 trac / subversion -1 circular_buffer 1 program_options 1 serialization 1 utility 1 Documentation 2 property_tree 2 build 4 Changed totals by author: anthonyw -38 rogeeff -27 <none> -20 djowel -17 dave -16 grafik -10 pavol_droba -9 bemandawew -8 dgregor -8 ebf -7 az_sw_dude -6 jsiek -6 no-maintainer -6 garcia -5 agurtovoy -4 chris_kohlhoff -3 dlwalker -2 eric_niebler -2 gennaro_prota -2 matthiasschabel -2 nasonov -2 bschaeling -1 cnewbold -1 danieljames -1 emildotchevski -1 fmhess -1 hljin -1 jefffaust -1 johnmaddock -1 nesotto -1 speedsnail -1 steven_watanabe -1 t_schwinger -1 turkanis -1 cornedbee 1 jano_gaspar 1 jewillco 1 matias 1 niels_dekker 1 ramey 1 witt 1 vladimir_prus 7 Changed totals by category: Bugs -147 Patches -27 Feature Requests -17 Tasks -5 Support Requests -2 Library Submissions -1 -- Marshall

2 1

[vault] Malware in the Boost Vault!
by Chad Nelson 13 Jun '10

13 Jun '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "Sexy Live.zip", uploaded to the Vault on March 31st by "gr7ne2009", is apparently some kind of Trojan masquerading as a Windows screen saver, according to various antivirus programs (checked with both virusscan.jotti.org and www.virustotal.com) Who has access to remove it? - -- 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/ iEYEARECAAYFAkwUA0YACgkQp9x9jeZ9/wRLTACg7MglGcYo8kHUW0542YvJexf6 N8cAoPgBzbA3zhZB064rsFMHLf/s8c9f =KL39 -----END PGP SIGNATURE-----

2 7

[spirit2] How to get encoding-specific parsers by character type
by Andrey Semashev 12 Jun '10

12 Jun '10

I was wondering if it was possible to get encoding-specific parsers by character type? Something like that: template< typename CharT > struct encoding_specific { ... }; typedef encoding_specific< char > narrow; narrow::char_; // equivalent to spirit::standard::char_ typedef encoding_specific< wchar_t > wide; wide::char_; // equivalent to spirit::standard_wide::char_ This would help a lot in generic programming, when the character type is not known. Is there a tool like that already? If not, could it be added?

4 9

Bug sprint daily update for Saturday, June 12th
by Marshall Clow 12 Jun '10

12 Jun '10

Another good day in the code mines! As of 0800 Pacific time today, we had 806 open trac tickets. That is down by 18 from yesterday, and 183 since the start of the bug sprint! There's only two days left in the bug sprint (Friday, Saturday, Sunday) Keep up the great work! Total ticket counts: Saturday 989 Sunday 988 Monday 958 Tuesday 938 Wednesday 894 Thursday 854 Friday 824 Saturday 806 Activity summary for yesterday (I'm counting tickets by hand here, here so blame my crummy math if it doesn't add up) New tickets: 1 Modified: 10 Closed: 20 Reopened: 1 Today, rather than the summary totals for yesterday, I have deltas; changes in the totals. If you'ld like to see the totals, they are available online at: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 (All changes are since the start of the bug sprint; 0800 PDT Saturday June 5th) Changed totals by library: thread -39 test -27 None -17 website -10 string_algo -9 variant -7 date_time -6 function -6 iterator -6 concept_check -5 filesystem -5 fusion -5 multi_array -5 Getting Started Guide -4 asio -4 mpl -4 random -4 tuple -4 lambda -3 units -3 Building Boost -2 foreach -2 lexical_cast -2 tokenizer -2 GIL -1 Python -1 Regression Testing -1 assign -1 function_types -1 graph -1 io -1 mpi -1 pool -1 regex -1 signals2 -1 spirit -1 trac / subversion -1 circular_buffer 1 program_options 1 serialization 1 utility 1 Documentation 2 property_tree 2 build 4 Changed totals by author: anthonyw -38 rogeeff -27 <none> -20 dave -14 grafik -9 pavol_droba -9 dgregor -8 djowel -8 ebf -7 az_sw_dude -6 jsiek -6 no-maintainer -6 bemandawes -5 garcia -5 agurtovoy -4 chris_kohlhoff -4 dlwalker -2 eric_niebler -2 matthiasschabel -2 nasonov -2 bschaeling -1 cnewbold -1 danieljames -1 emildotchevski -1 fmhess -1 hkaiser -1 hljin -1 jefffaust -1 johnmaddock -1 nesotto -1 speedsnail -1 steven_watanabe -1 t_schwinger -1 cornedbee 1 danielw 1 jano_gaspar 1 jewillco 1 matias 1 niels_dekker 1 ramey 1 witt 1 vladimir_prus 7 Changed totals by category: Bugs -134 Patches -24 Feature Requests -16 Tasks -5 Support Requests -2 Library Submissions -1 -- Marshall

2 1

Re: [boost] [msm] Problems with no_message_queue and pseudo exit states
by Christophe Henry 12 Jun '10

12 Jun '10

> I know your are quiet bussy releasing msm but we found something and we do > not know whether it is the intended behaviour or a bug. > > We implemented a little state machine with a submachine. The submachine > has an pseudo exit state. > If we use "typedef no_message_queue" in the state machine as well as in > the submachine, then the state machines get somehow mixed up and do not > act normally once you leave the submachine via the pseudo exit state. > In that case msm does not exit the pseudo exit state. > > We followed almost your example that you provide in the documentation. > > Is that known to you? Does it make sense to fix that or are there serious > reasons why msm behaves like that? It's clearly a doc bug, I thought I had written it, but looks like I didn't :( Pseudo exit states are implemented by generating a new event (convertible from the original one) upon entering the pseudo entry, in order to get the UML priority right (deepest-level transitions tried first for a given event). This effectively makes pseudo exit states and no_message_queue incompatible, at least for the containing machine. I'm not completely happy with this implementation so this one also is on my radar. Thanks for reporting this. I wanted to add during the WE the points you already reported into the doc so I will add this restriction too. If I forget nothing: - pseudo exit points / no_message_queue - no explicit entry to submachines at the moment - references in the forwarding constructor with ref/cref - add some explanations for the entry state / explicit entry syntax If I forgot something, we still have some time before the release. Regards, Christophe

1 0

[iterator adaptor] requires default constructor?
by Neal Becker 12 Jun '10

12 Jun '10

It seems an iterator requires a default constructor in order to be adapted by iterator adaptor. This is due to (iterator_adaptor.hpp):279 iterator_adaptor() {} Is this really necessary?

4 6

Bug sprint daily update for Friday, June 11th
by Marshall Clow 11 Jun '10

11 Jun '10

As of 0730 Pacific time today, we had 824 open trac tickets. That is down by 30 from yesterday, and 165 since the start of the bug sprint! There's only three days left in the bug sprint (Friday, Saturday, Sunday) Keep up the great work! Total ticket counts: Saturday 989 Sunday 988 Monday 958 Tuesday 938 Wednesday 894 Thursday 854 Friday 824 Thanks especially to Steven Watanabe, who has been a "bug fixing machine" this week ;-) (and thanks also to the rest of you who have been fixing bugs) Activity summary for yesterday (I'm counting tickets by hand here, here so blame my crummy math if it doesn't add up) New tickets: 2 Modified: 14 Closed: 33 Reopened: 1 Today, rather than the summary totals for yesterday, I have deltas; changes in the totals. If you'ld like to see the totals, they are available online at: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 (All changes are since the start of the bug sprint; 0800 PDT Saturday June 5th) Changed totals by library: thread -38 test -24 None -17 website -10 string_algo -9 variant -7 date_time -6 function -6 iterator -6 concept_check -5 multi_array -5 Getting Started Guide -4 asio -4 random -4 tuple -4 lambda -3 units -3 Building Boost -2 foreach -2 fusion -2 mpl -2 tokenizer -2 GIL -1 Regression Testing -1 assign -1 graph -1 io -1 lexical_cast -1 mpi -1 pool -1 regex -1 signals2 -1 spirit -1 trac / subversion -1 circular_buffer 1 exception 1 program_options 1 serialization 1 utility 1 Documentation 2 property_tree 2 build 4 Changed totals by author: anthonyw -37 rogeeff -24 <none> -20 dave -13 grafik -9 pavol_droba -9 dgregor -8 ebf -7 az_sw_dude -6 jsiek -6 no-maintainer -6 djowel -5 garcia -5 chris_kohlhoff -4 agurtovoy -2 dlwalker -2 eric_niebler -2 matthiasschabel -2 bschaeling -1 cnewbold -1 danieljames -1 fmhess -1 hkaiser -1 hljin -1 jefffaust -1 johnmaddock -1 nasonov -1 nesotto -1 speedsnail -1 steven_watanabe -1 cornedbee 1 danielw 1 jano_gaspar 1 jewillco 1 matias 1 niels_dekker 1 ramey 1 witt 1 vladimir_prus 7 Changed totals by category: Bugs -124 Patches -19 Feature Requests -14 Tasks -4 Support Requests -2 Library Submissions -1 -- Marshall

2 1

[gsoc] heaps
by Tim Blechmann 11 Jun '10

11 Jun '10

hi all, since the heaps/queues project is likely to be used by multiple people, i think it may be a good idea to share some ideas on the list ... for now, i have been implementing a (non-intrusive) d-ary heap, which was very useful to do some prototyping of the actual interface. all data structures support the following template arguments: typename T // value type bool stable // stability class Cmp // compare object class Alloc // allocator for internal data structures the interface matches the forward container requirement, except that it does not support iterators (only const_iterators) and container comparison. at the moment, i distinguish between immutable and mutable heaps. the interface for immutable heaps would look like this: class immutable_heap { public: // priority queue support value_type const & top(void) const; void push(value_type const & v); void pop(void); // merge support void merge (immutable_heap const & rhs); void merge_and_clear (immutable_heap & rhs); // moves all elements from rhs to *this }; for mutable heaps, i have been using a `handle' to refer to specific elements: class mutable_heap { public: typedef handle_type; // priority queue support value_type const & top(void) const; handle_type push(value_type const & v); void pop(void); // update via function void update(handle_type const & node, value_type const & v); void increase(handle_type const & node, value_type const & v); void decrease(handle_type const & node, value_type const & v); // force update after element has been changed via the handle void update(handle_type const & node); void increase(handle_type const & node); void decrease(handle_type const & node); // merge support void merge (mutable_heap const & rhs); void merge_and_clear (mutable_heap & rhs); }; the forced update api is rather dangerous, since the heap would enter an undefined state, of the node is changed, but the heap is not updated. otoh, it would help to update values using a different api than the assignment operator. also, i am unsure, whether by default the heaps should be min-heaps (like in most textbooks on data structures) or max-heaps (like std::priority_queue). so i'd be curious, what people think about it ... the code is available from my public git repository. i would be curious to hear some thoughts! http://tim.klingt.org/git?p=boost_heap.git cheers, tim -- tim(a)klingt.org http://tim.klingt.org A year ago, six months ago, I thought that I was an artist. I no longer think about it, I am. Henry Miller

3 5

[Filesystem] Dual V2 + V3 support progress report
by Beman Dawes 11 Jun '10

11 Jun '10

I've created a branch to develop dual V2 + V3 support via namespace hoisting, as suggested by Scott McMurray, Andrey Semashev, and others. See https://svn.boost.org/svn/boost/branches/filesystem3 Seems to work well, and is lots easier to use that the switching approach currently in trunk. I've tested only on Windows, but will give Linux and Mac OS X a try later today or tomorrow. Namespace hoisting will break some existing V2 code: * User specializations in namespace filesystem. This is presumably very unusual, breaks noisily, and the fix is trivial, so I don't see it as a show stopper. * Possible ADL problems. I don't fully understand when this might be a problem, but neither V2 or V3 hit it in any of the tests, so I doubt it is very serious. --Beman

1 0