June 2010 - Boost - lists.boost.org

[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