- Boost - lists.boost.org

mpl help needed - doing the impossible?
by Manfred Doudar 16 Nov '05

16 Nov '05

I'm Re-posting ... sorry for the noise, but this seemingly, earlier went against the unit lib thread .. (don't quite know how). Boosters: I'm hoping someone here might be of help, and enlighten me with some more MPL trickery ... What I'm doing: Have a class MyArray derived from blitz::Array, and among other things, I'm trying to add the operator[] to slice through a multi-dim array ... pretty much have it, with one exception - once I get to applying [] on a 1-dimensional (linear) array, I of course expect a scalar, but therein lies the problem - the compiler also "sees" a 0-dimensional array (not good!), and that's where I run into problems... Brief snippets of code: Please ignore the return by value for the moment - I can clean that up later, not to mention the Boost PP extensions I can add. Below is a cut-down class definition, and method implementation follows. Class Declaration: ------------------ template <typename T, int Rank = 1> class MyArray : public blitz::Array<T, boost::mpl::int_<Rank>::value> { public: // ... methods }; (Partial Listing) Implementation: --------------------------------- template <typename T, int Rank> MyArray<T, Rank> :: Array(const blitz::Array<T, boost::mpl::int_<Rank>::value>& btz ) throw() : blitz::Array<T, boost::mpl::int_<Rank>::value> (const_cast<T *> (btz.data()) , btz.shape() , blitz::duplicateData ) { // Copy Ctor } template <typename T, int Rank> void MyArray<T, Rank> :: getParamList(blitz::TinyVector< boost::variant< blitz::Range , blitz::nilArraySection > , 2 >& plist ) { // Aides us in setting up the parameter list for slicing plist(boost::mpl::int_<0>::value) = blitz::Range::all(); plist(boost::mpl::int_<1>::value) = blitz::nilArraySection(); } /* Now, how do I get T out when Rank == 1, ... compiler complains about seeing a MyArray/blitz::Array of <T, Rank = 0> (, which is not defined for blitz Arrays) */ template <typename T, int Rank> typename boost::mpl::if_ < typename boost::mpl::equal_to < boost::mpl::int_<Rank> , boost::mpl::int_<1> >::type , T , MyArray<T, boost::mpl::int_<Rank>::prior::value> >::type MyArray<T, Rank> :: operator[] (const int& index) throw(); { // Slicing // this bit of indirection is useful blitz::TinyVector<boost::variant<blitz::Range, blitz::nilArraySection>, 2> plist; this->getParamList(plist); /* pseudocode: (kind of) **************** return // cast for return type static_cast< (Rank == 1 ? T : MyArray<T, Rank - 1>) > ( // cast _this_ ptr * static_cast<const blitz::Array<T, Rank> *> (this) // the blitz Array parameter list (index, //the param list *boost::get<blitz::Range *or* blitz::nilArraySection>(&plist(0 *or* 1), ... ) ) Sample usage: MyArray<float, 3> arr(btzArray); arr[10]; // gives MyArray<float, 2> out arr[10][2] // gives MyArray<float, 1> out arr[10][2][7] // expect a float to be output ********************/ return static_cast< typename boost::mpl::if_< typename boost::mpl::equal_to< boost::mpl::int_<Rank> , boost::mpl::int_<1> >::type , T , MyArray<T, boost::mpl::int_<Rank>::prior::value> >::type > ((* static_cast<const blitz::Array<T, boost::mpl::int_<Rank>::value> *> (this)) /* the parameter list */ (index, *boost::get< typename boost::mpl::if_< typename boost::mpl::less< boost::mpl::int_<1> , boost::mpl::int_<Rank> >::type , blitz::Range , blitz::nilArraySection >::type > (&plist(boost::mpl::if_< typename boost::mpl::less< boost::mpl::int_<1> , boost::mpl::int_<Rank> >::type , boost::mpl::int_<0> , boost::mpl::int_<1> >::type::value ) ) /* , ... we can extend the parameter list with Boost.PP */ ); ************* (Partial) Compiler Error Messages: --------------------------------- `boost::mpl::algo_::if_<boost::mpl::equal_to<boost::mpl::int_<Rank>, boost::mpl::int_<1> >::type, T, blitz::Array<T, typename boost::mpl::int_<Rank>::prior::value> >::type moe::Array<T, Rank>::operator[](const S&) [with S = int, T = int, int Rank = 1]': arr.cc:172: instantiated from here arr.cc:666: invalid static_cast from type `blitz::Array<int, 0>' to type `int' /usr/local/include/blitz/array/storage.h: In constructor `blitz::GeneralArrayStorage<N_rank>::GeneralArrayStorage() [with int N_rank = 0]': <snip ... more messages> /usr/local/include/blitz/array/storage.h:60: no match for call to `( blitz::TinyVector<int, 0>) (int&)' <snip ... more messages> ******************* So ... can anyone tell me if what I'm trying to do is possible ? Is there some MPL trickery to do it ? The above does work up until I apply the operator[] on a 1-d linear array. Help and ideas would be appreciated. Ah yes, using gcc 3.2.2, and Boost version 1.31 (maybe 1.32) .. downloaded in August 2004 (yes, I know that's ancient - but managment can be a real pain sometimes) P.S. tried to format this message as best I could, hope it's readable. With Thanks, -- Manfred Doudar MetOcean Engineers www.metoceanengineers.com

1 0

Weak_ptr and operator==
by Dan Day 15 Nov '05

15 Nov '05

Why was operator== never added to weak_ptr? Couldn't the operator easily be implemented in terms of operator<? -- ------------------------------------------- Dan Day http://razzerblog.blogspot.com

3 2

Re: [boost] Too many library variants
by Rene Rivera 15 Nov '05

15 Nov '05

Taking this to the devel list... Jeff Garland wrote: > On Mon, 14 Nov 2005 20:17:00 -0500, David Abrahams wrote > >>Rene Rivera <grafik.list(a)redshift-software.com> writes: >> >> >>>Merrill Cornish wrote: >>> >>>>When I built Boost 1.33.0 for MinGW, I just specified the toolset. >>>>As a result I got 28! variants on the set of Boost libraries. >>>> >>>> >>>>>From the various file names, I can figure out most of the variants: >>>>> >>>> >>>>d = debug mt = multi-threaded s = static but there are other variants >>>>which aren't as obvious. >>> >>>It's all explained in >>><http://www.boost.org/more/getting_started.html#Results>. >> >>Rene, I get the impression that 28 variants is a lot more than most >>people want, at least at first. Maybe we shouldn't build all of them >>by default, and just supply enough to "get started?" > > I think at one point Doug suggested that a single variant is the most common > case, and I agree. OK, but which ever variant one picks, dynamic, static, etc., will mean that some subset of the libraries will not get built as not all libraries support building in any variant. What was the variant that Doug suggested? By the way it's only 16 variants that get built. The rest are the result of not having the version tag so those are just either copies or symlinks. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

2 1

Proposal: property_tree rev.2 uploaded to vault and sandbox cvs
by Marcin Kalicinski 15 Nov '05

15 Nov '05

Hi All, Thanks to everybody who took time to look at the library, and especially to those who sent me feedback. Second revision of property_tree is now in the vault as property_tree_rev2.zip (it is now also in boost-sandbox cvs). Outline of the changes: - new methods get_o, get_own_o, get_child_o, which return boost::optional (suggested by Pavel Vozenilek) - added locales support to get and put methods (suggested by Martin) - pointer to bool removed from get_d (suggested by Daniel Wesslen) - ptree/wptree are now case sensitive by default. Added iptree/wiptree which are case-insensitive (suggested by Daniel Wesslen) - fixed multiple definitions bug when including some of the headers in more than one translation unit (spotted by Daniel Wesslen) - added more examples - updated docs and regressions to match current state of library (that was the biggest job actually :-) - hopefully kept the quality high Outstanding work: - XPath-like syntax for retrieving XML attributes (suggested by Caleb Epstein) - ptree mathematical relations (difference, union, intersection) - nice e.g. for tracking config file changes, or combining configs Original message (posted with revision 1): Property tree is a data structure - a tree of (key, value) pairs. It differs from its cousin, "usual" PropertyMap, because it is hierarchical, not linear. Thus, it is more like a minimalistic Document Object Model, but not bound to any specific file format. It can store contents of XML files, windows registry, INI files, even command line parameters. The library contains parsers for all these formats, and more. I tried to make the library as high quality as possible before posting here, so it contains a (hopefully) full documentation, and a comprehensive set of regression tests - more than 300 test cases. By any chance it is not a substitute for (upcoming?) boost XML library - it only supports a fairly narrow subset of XML, and focuses rather on being format-independent. For more curious, excerpt from the doc: Property tree is a recursive data structure that stores a single data string, and an ordered list of (key, value) pairs, where value is a property tree itself. It therefore forms a tree, hence the name. It is a versatile structure that can store in uniform way data coming from various sources, such as XML or INI files, as well as windows registry, program command line etc. Property tree interface is similar to the interface of a standard C++ container. It supports iterators, insertion, erasing, searching etc. One can think of it as a sort of Document Object Model, which is minimalistic, not bound to any specific file format, designed to be easy to use, and comes as Boost-compatible, headers only C++ library. Many software projects develop a similar tool at some point of their lifetime, and property tree long ago originated the same way. I hope the library can save many from reinventing the wheel. cheers, Marcin Kalicinski

1 0

Re: [boost] Boost.Logging hex dumps (Was: Boost.Logging: formalre view)
by Martin Bonner 15 Nov '05

15 Nov '05

----Original Message---- From: Pavel Antokolsky aka Zigmar [mailto:zigmar@gmail.com] Sent: 15 November 2005 14:55 To: boost(a)lists.boost.org Subject: Re: [boost] Boost.Logging hex dumps (Was: Boost.Logging: formalreview) > On 11/15/05, Caleb Epstein <caleb.epstein(a)gmail.com> wrote: >> On 11/15/05, Darryl Green <darryl.green(a)unitab.com.au> wrote: >>> >>>>>>>> Ok, will do. >>>>>>> >>>>>>> But note that will can bloat the library. Showing hex data is a >>>>>>> much harder >>> >>> Hex data formatting (or any data formatting) shouldn't be part of >>> the library. Or if it should, it probably means the lib shouldn't >>> be dragging in all that std streams stuff that is supposed to be >>> responsible for formatting... >> >> >> The proposed Boost.Log library already depends (rightly, IMHO) on >> iostreams for message formatting and buffering of >> partially-formatted messages. I can't see why or how this dependency >> could be reasonably eliminated without major sacrifices to the >> usefulness of the library. >> >> The necessary code to do hex dumps on an iostream should hardly be >> considered bloat. I agree with Gennadiy's assesment that 50 lines of >> code should be more than adequate to do it. These can be in a >> separate header file that is included only by the user. What >> possible harm could this be? > > It would not hard of course, but I think this code does not belong to > the logging library. It's such a common requirement that I think it does. > For example, in some cases I do not want to print non-ascii > characters in hex dump, in others I do. ? How does a hex dump contain anything other than hex digits and space (to separate bytes). You might want a way of controlling whether to use upper or lower case letters (but I wouldn't bother). > The grouping depends on length > of the data worlds I'm working with, and also should be configured, > and so on. > My point is that the simple solution is not even worth implementing, > and general solution is definitely out of scope of logging library. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

3 4

[string_algo] error in example code
by Caleb Epstein 15 Nov '05

15 Nov '05

In: *http://tinyurl.com/b9tjl *Example code shows: typedef split_iterator<string::iterator> string_split_iterator; for( string_find_iterator It= make_split_iterator(str1, first_finder("-*-", is_iequal())); It!=string_find_iterator (); ++It) { cout << copy_range<std::string>(*It) << endl; } string_find_iterator should be string_split_iterator here. -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

Boost regression notification (2005-11-15 [RC_1_33_0])
by Douglas Gregor 15 Nov '05

15 Nov '05

Boost regression test failures ------------------------------ Report time: 2005-11-15T14:29:09Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 0 failure in 0 library:

1 0

Boost regression notification (2005-11-15 [HEAD])
by Douglas Gregor 15 Nov '05

15 Nov '05

Boost regression test failures ------------------------------ Report time: 2005-11-15T06:00:10Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. io Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 141 failures in 13 libraries: concept_check (12) date_time (2) graph (2) io (1) math (6) mpl (1) serialization (30) spirit (8) thread (4) tr1 (51) tuple (1) typeof (18) xpressive (5) |concept_check| stl_concept_covering: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 vc-7_1 |date_time| testwcustom_time_zone: mingw-3_4_2 testwposix_time_zone: mingw-3_4_2 |graph| graphviz_test: vc-7_1 layout_test: intel-win32-9_0 |io| ios_state_unit_test: intel-win32-9_0 |math| complex_test: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin intel-win32-9_0 mingw-3_4_2 vc-7_1 |mpl| size_t: gcc-4_0-darwin |serialization| test_class_info_load_binary_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin |spirit| action_tests_debug: gcc-3_4_3-sunos distinct_tests_debug: gcc-3_4_3-sunos escape_char_parser_tests_debug: gcc-3_4_3-sunos grammar_def_test_debug: gcc-3_4_3-sunos switch_problem_debug: gcc-3_4_3-sunos switch_tests_single_debug: gcc-3_4_3-sunos traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |thread| test_condition: gcc-3_4_3-sunos test_mutex: gcc-3_4_3-sunos test_tss: gcc-3_4_3-sunos gcc-3_4_3-sunos |tr1| run_complex_overloads: gcc-2.95.3-linux std_run_complex_overloads: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_run_random: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_boost: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_complex: gcc-2.95.3-linux std_test_hash: gcc-2.95.3-linux std_test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 std_test_result_of: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_tr1_include: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 std_test_tuple: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_type_traits: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test_algorithm: gcc-2.95.3-stlport-4.6.2-linux test_complex: gcc-2.95.3-linux test_exception: gcc-2.95.3-stlport-4.6.2-linux test_hash: gcc-2.95.3-linux test_ios: gcc-2.95.3-linux test_istream: gcc-2.95.3-linux test_iterator: gcc-2.95.3-linux test_limits: gcc-2.95.3-linux test_locale: gcc-2.95.3-linux test_new: gcc-2.95.3-stlport-4.6.2-linux test_ostream: gcc-2.95.3-linux test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 test_result_of: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_streambuf: gcc-2.95.3-linux test_tr1_include: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 test_tuple: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_type_traits: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test_utility: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |tuple| tuple_test_bench: gcc-3_4_3-sunos |typeof| data_member_native: cw-9_4 function_native: cw-9_4 function_ptr_native: cw-9_4 function_ref_native: cw-9_4 lvalue_native: cw-9_4 member_function_native: cw-9_4 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 noncopyable_native: cw-9_4 std_emulation: cw-9_4 std_native: cw-9_4 template_dependent_native: cw-9_4 template_enum_native: cw-9_4 template_int_native: cw-9_4 template_multiword_native: cw-9_4 template_tpl_native: cw-9_4 template_type_native: cw-9_4 type_native: cw-9_4 |xpressive| test3u: gcc-3_3-darwin test4u: gcc-3_3-darwin test5u: gcc-3_3-darwin test6u: gcc-3_3-darwin test9u: gcc-3_3-darwin

1 0

"Re: serialization performance"
by bwood 15 Nov '05

15 Nov '05

Martin Slater wrote: >> //build oArch. >> Ebenezer: >> msgs.Send(buffer, lst); // where I didn't remove anything >> // from Send's implementation. >> >> I think as you say, whether a flush gets embedded in the Send >> function should be configurable, but right now it just is. >> I'll admit it would be better if I didn't have to remove (#if 0) >> the end of the Send function, but I don't think that invalidates >> anything. > >This I humbly disagree with, from a user point of view I would not >want to patch either library to get optimal performance, If it is >there and required then tests need to be done with it in. It would >be simple to speed up boost.serialization by #if 0'ing out per class >meta information lookups (versioning etc) but would still be >extremely artificial. Either way, with or without the embedded flush code, Boost serialization is less efficient than Ebenezer's Send in both tests. Today I timed how long it takes to build the two testcases mentioned in the original post on Nov. 8th. I used the date command so the numbers are only in seconds. list<int> list<int> and deque<int> ----------------------------------------------------------- Boost 42 61 ----------------------------------------------------------- Ebenezer 12 20 >>>It would be interesting to see what the results are with a vanilla >>>version of your library as well as a feature by feature comparision to >>>see if you really are comparing apples to apples. >>> >> Both Boost and s11n.net support things like XML that Ebenezer doesn't. >> Boost in my opinion mistakenly tries to support "versioning." We >> don't and I don't think s11n does either. > >Well since I use versioning heavily with boost.serialization this is >a must have feature for me. What happens if you want to change the type of an existing data member between releases - say from char to short? Brian www.webEbenezer.net

3 3

[multi_index][rfc] random access indices preview
by Joaquín Mª López Muñoz 15 Nov '05

15 Nov '05

Hello, Some months ago I prompted for interest in a new type of indices for Boost.MultiIndex featuring random access facilities, and received a couple of expressions of itnerest. The preliminary specification was published at: http://195.235.93.150/rnd_indices_spec.html I've just uploaded a preview version of random access indices at FileVault -> Containers (http://tinyurl.com/9zlmj) This preview follows the previous specification save for one point: reserve/capacity is provided for control of an internal array of pointers to the nodes, as explained in http://195.235.93.150/rnd_indices_spec.html#interface. There's no docs yet on this type of indices, but the usage should be straightforward from the preliminay specification notes. Random access indices act as a functional drop-in replacement of sequenced indices, so you can start playing with them very easily. My requests: * Do you find these indices worth including in Boost.MultiIndex? * If so, do you have comments on the specification? Things you'd change/add? There's a list of concrete issues at the end of the specification page, * Do you envision any interesting use case for random access indices? Have you experimented with them? Thank you very much for your feddback, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 6