May 2011 - Boost - lists.preview.boost.org

Delimiting protocol messages (was [asio] read_some() splits data)
by Marsh Ray 12 May '11

12 May '11

On 05/11/2011 09:36 AM, Andrew Holden wrote: > On Wednesday, May 11, 2011 9:57 AM, Slav wrote: >> Then messages of length not multiple of 128 (BUFFER_SIZE) >> will not be read - tested it, anyway, after >> last socket::read_some() (with readBytes> 0&& < >> BUFFER_SIZE) next socket::read_some() never ends. > > It would probably help to understand that TCP has no concept of a > "message". Anything you write to a socket is appended to a stream of > *bytes*. Alternatively, we could say that TCP, in fact, does have a well-defined concept of messages: they are all exactly one byte long. > Several subsystems on both the sending and receiving computers ... and sometimes boxes in the middle ... > will have the option of splitting and combining adjacent buffers with no > consideration to how big each individual write was. I've done a little protocol stuff with ASIO now and I must say it's a lot of fun and I can't go back to doing it any other way. > On further thought, I think I see the problem (and I apologize for the > bad recommendation in my last email). Your sender somehow needs to > communicate the message size or flag the end of the message. A partial > list of options includes: The pattern I encounter over and over again (often at multiple levels in a protocol) is: class protocol_layer_context { vector<uint8> buffer; void on_received_data(vector<uint8> & rx_bytes) { buffer.append(rx_bytes); // perhaps a virtual override. size_t msg_len = this->parse_len_from_start_of_buffer(); if (buffer.size() <= msg_len) { vector<uint8> msg_buf = consume_data_from_front_of_buffer(buffer, msg_len); // perhaps a virtual override this->process_complete_message(msg_buf); } // post another ASIO read request this->request_more_data(); } ... But there are some important issues with this naive pseudocode: 1. It can result in recopying the data a bunch of times for every protocol layer, killing performance. 2. It's susceptible to a denial-of-service (DoS). Bad guy can send trick you into allocating all your memory. 3. Sometimes the length of a message is stated at the beginning of the message, sometimes it isn't known until the end. 4. No processing happens on the message until it's completely read, but some protocols really need the receiving endpoint to process it incrementally. 5. Error handling 6. Optimal threading 7. Etc. We find bugs in exactly this logic all the darn time. Often the data being received is untrusted and possibly malicious. Real-world protocol implementations will commonly crash under fragmentation fuzzing, sometimes resulting in exploitable security holes. In a sense, this is the general refactoring problem of 'incrementalizing' a parsing function by moving all its state from stack variables into a longer-lived context object. We've seen it done successfully with coroutines, but that's not a commonly accepted solution because, frankly, the native C/C++ runtimes have not yet given coroutines the love (i.e., portability and performance guarantees) they really deserved. If someone figured out how to leverage generic techniques to handle just the unidirectional message delimiting problem in a bulletproof way I think it would make a really great boost library. - Marsh

1 0

Free BoostCon Registration
by Dave Abrahams 12 May '11

12 May '11

Unfortunately, two of our registrants had to cancel after the refund deadline. Fortunately, they have offered their registrations to anyone who might have not registered because of the cost. If you would like to claim these available registrations, please send email to our registrar, Marshall Clow (mclow AT gmail.com) Thanks, and see you in Aspen! -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 1

[spirit][qi] Dynamically combine Boost.Spirit.Qi rules at runtime
by Daniel F. 11 May '11

11 May '11

Hi, I recently tried to combine an arbitrary number of rules as alternatives in Boost.Spirit.Qi. Since rules are implemented as objects it seemed feasible to me. My motivation was to make certain parts of my grammar easily extensible. Unfortunately, I ran into some problems, so I wrote a simple program (see attachment for the complete code) demonstrating the unexpected behavior. Here's the key part: // "Dynamic" version - Does not compile! :( /* std::vector<rule_t> rules; rules.push_back(qi::char_('a')[qi::_r1 = px::val(0)]); rules.push_back(qi::char_('b')[qi::_r1 = px::val(1)]); rules.push_back(qi::char_('c')[qi::_r1 = px::val(2)]); std::vector<rule_t>::iterator i(rules.begin()), last(rules.end()); rule_t grammar; grammar = (*i)(qi::_r1); //[no_op] for(++i; i!=last; ++i) { grammar = grammar.copy() | (*i)(qi::_r1); //[no_op] } */ // "Dynamic" version - Kind of works! :-/ std::vector<rule_t> rules; rules.push_back(qi::char_('a')[qi::_r1 = px::val(0)]); rules.push_back(qi::char_('b')[qi::_r1 = px::val(1)]); rules.push_back(qi::char_('c')[qi::_r1 = px::val(2)]); std::vector<rule_t>::iterator i(rules.begin()), last(rules.end()); qi::rule<iterator_t, int()> temp; temp = (*i)(qi::_val); //[no_op] for(++i; i!=last; ++i) { temp = temp.copy() | (*i)(qi::_val); //[no_op] } rule_t grammar; grammar = temp[qi::_r1 = qi::_1]; Now, I suppose that the first version (commented out) doesn't compile, because I'm not passing the inherited attribute down to grammar.copy(). I would love to know if there's a better way of doing this than the workaround that is the second version. The second version actually compiles and it seems to do the right thing. However, once I attach a simple semantic action as indicated in the code using comments (see "[no_op]"), the behavior becomes really weird. Rather than printing 0,1,2 as before, the program prints 0,0,2. So I'm wondering, is what I'm trying to accomplish resulting in undefined behavior? Is this a bug? Or, quite possibly, am I just using something (e.g. semantic actions?) the wrong way? Thanks for reading, Daniel

4 7

[convert] no-throw and fallback feature
by Vicente BOTET 11 May '11

11 May '11

Hi, I was thinking on the fallback feature a little bit more and I've the impression that we can get it for free. If we accept that we need a no-throw function such as try_convert_to that returns an optional Target we can have the fallback using the optional::get_value_or function auto r = try_convert_to(*int*)(s); int i = r.get_value_or(fallback); or just int i = try_convert_to(*int*)(s).get_value_or(fallback); or int i = get_value_or(try_convert_to(*int*)(s), fallback); I don't know if it is worth adding a function that does all in one int i = convert_to_or(*int*)(s, fallback); Best, Vicente

5 25

[autoindex] Review
by Edward Diener 11 May '11

11 May '11

This is my review of autoindex. - What is your evaluation of the design? Very clean and easy to understand. - What is your evaluation of the implementation? Did not look at the internals. - What is your evaluation of the documentation? Generally good. Here is a list of mostly grammatical errors: 1) Overview: "the HTML indexes look a lot less good" -> "the HTML indexes look a lot worse" Step 1: Build the AutoIndex tool: "Finally note that tools/auto_index/auto-index.jam gets copied into the same directory as the rest of the Boost.Build tools." -> I am not sure if this means that building AutoIndex does this automatically or the end-user must do it but the sentence grammar suggests the former, which does not happen for me. If the end-user should do it, the line should read "Finally note that tools/auto_index/auto-index.jam should be copied into the same directory as the rest of the Boost.Build tools." 2) Step 2: Configure Boost.Build jamfile to use AutoIndex "Always send the output to a log file. It will contain of lot of stuff, but is invaluable to check if all has gone right, and else diagnose what has gone wrong. -> ..."and also diagnose what has gone wrong." ..."or else diagnose what has gone wrong." 3) Available Indexing Options: For Document Type 'library', Available Index Types says 'See Chapter'. I am guessing this means it is the same as Document Type 'chapter' but it should be made clearer in the remark. 4) Step 7: Iterate - to refine your index: "You can restrict which sections are indexed for a particular term. So assuming that the docbook document has the usual hierarchical names for section ID's hierarchical names for section IDs(as Quickbook generates, for example), you can easily place a constraint on which sections are examined for a particular term. " ' -> remove the second repeated "hierarchical names for section IDs". "This would avoid an index entry every time ° kelvin is found, something the user is unlikely to find helpful. " -> "This would avoid an index entry every time 'Kelvin' is found, something the user is unlikely to find helpful. " 5) Script File (.idx) Reference: "Blank lines consisting of only whitespace are ignored, so are lines that start with a #. (But, of course, you can't append # comments onto the end of a line!). " -> I am guessing this should be: "...(But, of course, you can append # comments onto the end of a line!)." "recurse An optional boolean value - either "true" or "false" - that indicates whether to recurse into subdirectories. This defaults to "false" -> Needs a period at the end. "type The type to which items found using this rule will assigned, index terms created from the source file and then found in the XML, will have the type attribute set to this value, and may then appear in a specialized index with the same type attribute " -> Needs a period at the end. The only other issue in the documentation is that while there is very good documentation about what type of XML container wraps an internally generated index, I am not sure what this actually means to a Quickbook author. No doubt somewhere there is probably a discussion in Docbook of what these XML containers mean and do but, aside from experimentation, the user of AutoIndex is not likely to understand what it means to put the Index in a specific XML container and how this affects the final layout of the documentation. Perhaps some further explanation of what this actually means for an AutoIndex user, especially for a Quickbook document, would be appropriate. - What is your evaluation of the potential usefulness of AutoIndex? Immense. Searching through documentation of even mildly complex libraries which have little or no index is very frustrating. - Did you try to use it? With what compiler? Did you have any problems? I have used it for the documentation of my VMD and TTI libraries with both gcc and vc++ under Windows. Any problems were of my own making and the author of AutoIndex answered my questions when I was stuck. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A pretty deep study, although I have not tried to add anything to the index file other than 'scan' statements. - Are you knowledgeable about the problem domain? Yes. I vote for the library to be accepted into Boost. Edward Diener

2 1

inquiry about proposing a new Boost library for a tree template container class
by Erik Erlandson 11 May '11

11 May '11

Hello, I recently completed an STL-compliant template container class for storing data in an arbitrary tree structure. It seemed like it might be a useful component of Boost, and I wanted to ask about how new projects are submitted for consideration. The current incarnation of the project is called 'st_tree', and resides here: https://github.com/erikerlandson/st_tree/wiki Regards, Erik Erlandson

7 27

[type_factory] new utility/class proposal
by Vlad Lazarenko 11 May '11

11 May '11

Dear Boost developers, How many times in your experience you needed to associate a type with some identifier known at run-time only? It’s like having an associative container with numeric key and type as a value. Not object, but type. This is a concept similar to object factory pattern but with no objects, only their types. I call it a type factory. There might be a solution for this in Boost already but I haven’t seen it. Please forgive me if I am just being blind. Just to give you a little taste of what I mean – imagine that you have a stream of bytes where objects of different types and sizes are stored (serialized), and one byte identifying a type is preceding every such serialized object, and you need to parse it. One approach is to have a switch statement, for example, where all type identifiers are cased, and parse data depending on a type. But then, as list of types grows and/or shrinks, maintenance of this switch becomes unpleasant. And if this logic is in some base library, where user specifies list of types, it becomes even worse. There might be another way, I thought, and came up with sort of hybrid between compile-time types and run-time identifiers – a type factory. I am wondering if anyone else will find it useful. Perhaps we can have it as part of boost utility classes. Here is a very simple example of usage: https://github.com/Yocto/type_factory/blob/master/test/simple_example.cpp It gets a number from “argc”, and then, depending on its value, invokes “speak” method of either “cow”, “dog” or “alligator” classes. More functionality is covered in unit test. Basically, the type factory, given a list of types as “MPL vector“ is enumerating them from 0 to N. Later, for any given instantiation of “create” method, it generates a dispatch table for invoking of one of template methods (with no arguments) on a supplied “visitor” class. The source code of the class is here - https://github.com/Yocto/type_factory/blob/master/include/yocto/type_factor…. There are a lot of details, but the main class exposed to the user-land API is “type_factory”. Please let me know if you are interested in such a concept. Thank you, Vlad

2 1

Review manager needed for TTI library
by Edward Diener 10 May '11

10 May '11

I am looking for a review manager for my TTI library in the review queue. The TTI library, which is an abbreviation for the 'Type Traits Introspection' library, allows a programmer to introspect at compile time the inner elements of a C++ type. The introspection process depends on specifying the name of the inner element by different macros for different types of elements, and then using a generated metafunction to determine whether that element exists within the enclosing type. The inner elements which can be introspected are type, class template, member data, member function, static member data, and static member function. The TTI library is based on the type_traits_ext portion of the Concept Traits Library, with improvements and additions, and also reproduces functionality ( without changing existing code ), for the purposes of completeness, from Boost.MPL regarding introspection of types and templates. The purpose of the library is to provide a consistent set of interfaces for doing compile-time introspection of a type, which other template metaprogrammers can use in their code. Since I have acted as a review manager for another library, and have expressed my willingness to do so for some other libraries, I would appreciate it if someone, who understands Boost MPL well and the compile-time introspection problems my library solves, would be a review manager for my own library.

3 6

Re: [boost] [trolling] Alexander's crusade (was: [provocative] Whom did the SFC pay to list boostdevelopers as a whole in "Current Member Projects"?)
by Matt Chambers 10 May '11

10 May '11

> ... pointless quoted legal jargon... What's your point? -Matt

10 17

[container_bptree] first version of submitted library
by Vadim Stadnik 09 May '11

09 May '11

Hi all, The first version of submitted library container_bptree http://www.boostpro.com/vault/index.php?action=downloadfile&filename=contai… offers a number of STL variants of containers based on B+ trees. These powerful data structures enable the implementation of various useful extensions of STL containers and iterators. One of the most interesting improvements is the efficient algorithm accumulate(), which has computational cost *O(log N)* in the worst case. This algorithm can increase performance of solutions in numerous application areas, including traveling salesman problem. Please read the documentation and try the included test code. The current implementation has been developed for Visual Studio compilers (2008 and 2010). Portability of this library has not yet been tested. I would really appreciate if someone could compile and run the test code using other compilers and let me know if there are any technical issues. Any suggestions concerning improvements of the current version of this library will be carefully analyzed and implemented if possible. The potential of B+ trees has not yet been used to its full capacity. There are a number of options for further extensions of this library. The community interest and feedback will have an effect on the priority of the development of new features and efficient algorithms in future versions of this library. Thank you, Vadim Stadnik

2 2

[phoenix] not playing nice with other libs
by Eric Niebler 09 May '11

09 May '11

The following trivial program fails to compile: #include <boost/phoenix/core/limits.hpp> #include <boost/numeric/conversion/converter.hpp> It generates the following: In file included from ../../../../branches/release/boost/numeric/conversion/detail/is_subranged.hpp:17, from ../../../../branches/release/boost/numeric/conversion/detail/conversion_traits.hpp:21, from ../../../../branches/release/boost/numeric/conversion/conversion_traits.hpp:13, from ../../../../branches/release/boost/numeric/conversion/converter.hpp:13, from main.cpp:2: ../../../../branches/release/boost/mpl/multiplies.hpp:38: error: wrong number of template arguments (12, should be 5) ../../../../branches/release/boost/mpl/aux_/preprocessed/gcc/times.hpp:68: error: provided for ‘temp late<class N1, class N2, class N3, class N4, class N5> struct boost::mpl::times’ Phoenix is changing the following fundamental constants: BOOST_PROTO_MAX_ARITY BOOST_MPL_LIMIT_METAFUNCTION_ARITY BOOST_PROTO_MAX_LOGICAL_ARITY BOOST_RESULT_OF_NUM_ARGS IMO, Phoenix shouldn't be touching these. It should work as best it can with the default values. Users who are so inclined can change them. -- Eric Niebler BoostPro Consulting www.boostpro.com

13 40

Re: [boost] [tree] Reviving the tree library
by Cromwell Enage 09 May '11

09 May '11

--- On Fri, 5/6/11, Rene Rivera wrote: > On 5/6/2011 4:22 PM, Cromwell Enage wrote: > > What are your thoughts on a generalized depth-first > > iterator that also indicates whether it's currently > > in pre-order traversal mode, post-order traversal mode, > > or neither? I've found it useful for implementing > > scene graphs, for example. > > The goal was to make it possible to have any kind of > iteration. The ones in the TR are the simple common > ones. So yes, other iterations would be good to add. > I'm all for generalization. Are you thinking of the > static kind, as in traits, etc.? Or are you thinking > of something run-time? I was originally thinking of run-time generalization, i.e. the depth-first iterator being a functional superset of pre-order, post-order, and in-order iteration. But now that I look at the implementation, it might not necessarily be so. For a simple illustration, consider this ASCII rendition of the following tree: ___B +--+--+ A_____C If this were stored in a sorted binary tree, one might expect binary_tree::iterator to output the elements in this order: A B C However, if we expect an unsorted nary_tree::iterator to behave the same way (in-order, in this case), then what is the correct output for the following tree? _________I +-----+--+--+-----+ A_____E_____O_____U My current depth-first iterator would output the following: I pre_order A pre_order A post_order E pre_order E post_order O pre_order O post_order U pre_order U post_order I post_order One could filter by pre_order or post_order to obtain the corresponding output, so in that respect my depth-first iterator would be a functional superset. However, it traverses every node exactly twice, and definitely not in the same way as a sorted binary_tree::iterator. Therefore, while I agree that my depth-first iterator could make a fine addition, it may not necessarily serve well as an nary_tree::iterator. Thoughts? Cromwell D. Enage

1 0

[lexical-cast] New maintainer
by Antony Polukhin 09 May '11

09 May '11

Alexander Nasonov and Kevlin Henney gave me their permissions to become a new maintainer of Boost.LexicalCast library. Plans for the nearest future: 1) fix inspection program warnings (missing licenses, copyrights, non ascii chars ...) 2) contact with bug reporters, and fix bugs if they still exist 3) add unit tests and performance optimizations If somebody has some advices, comments or wishes, I would be glad to hear them. 2011/5/9 Kevlin Henney <kevlin(a)curbralan.com>: > Antony Polukhin <antoshkka(a)gmail.com: >> There are some bug fixes in trunk and performance optimizations, that >> can not make their way to release. And there is no accepted >> Boost.Convert library, that can do better than lexical_cast. >> >> Alexander Nasonov, the current maintainer of lexical_cast, wrote that >> he has no time for maintaining lexical_cast and that he has no >> objections against new maintainer.( That was in thread '[boost] >> [lexical-cast] version of lexical_cast in 1.46.1 is quite older than >> in trunk'). >> >> If you don`t mind, I`d like to become a new maintainer of >> lexical_cast. I`ve already talked with Alexander, he gave me a short >> introduction of how to maintain and what changes can be accepted into >> the library. He also advised to talk to you. > > Yes, I would be happy for you to do this, if you want to run initial changes > by me and/or Alexander. > > Antony Polukhin <antoshkka(a)gmail.com: >> Would you be so kind to give me some advises and tell more, about the >> official procedure of becoming a maintainer? > > I don't think there is an official process for becoming maintainer, other > than the original author and/or the current maintainer saying "You are now > the maintainer!" :-) > > And please feel free to ask me any questions about the requirements or > design intent. > > Antony Polukhin <antoshkka(a)gmail.com: >> Is there some requirements, not described in N1973 that the library >> must follow to? > > No, we had no plans for any additional features, only fixes to bugs and > improvements in performance. The functionality is at a point where it is > stable. > > So, congratulations: You are now the maintainer! > > Regards, > > Kevlin

1 0

Re: [boost] howto: boost.lambda + stl on VS 2010 (SP1) ?
by Mathias Gaunard 09 May '11

09 May '11

On 05/05/2011 01:37, Raffi Enficiaud wrote: > Hi all, > > Sorry for bothering with this. I recently encountered some problems in using > boost.lambda with Visual 2010 Express, and need some clues for solving the > issue (there are many ways around of course). > I simply want to accumulate the values of a std::map, and I thought using > lambda to access the second member of the map iterator was appropriate. Here > is the piece of code: > > typedef std::map<T1, unsigned short> m_t; > m_t m ; // fill m > double acc(0); > std::for_each(m.begin(), m.end(), var(acc) +=& _1->*& > m_t::value_type::second); > > The last line does not compile on Visual (it does on GCC), I have to add a > typedef: > > typedef typename m_t::value_type aa; > std::for_each(m.begin(), m.end(), var(acc) +=& _1->*& aa::second); > > Which one is "more correct" ? It's one of the annoying MSVC bugs. MSVC doesn't like it when you chain nested names in template contexts.

1 0

[release] Adding more documentation to the release process
by Daniel James 08 May '11

08 May '11

Hi Beman, At the moment the release doesn't include the geometry documentation which is at libs/geometry/doc/html. I've being creating a new file, boost-release-docs.7z which includes both the main documentation and the geometry documentation (it's a new file because it's zipped from the root, rather than from the doc directory). The attached patch should change the script to use that, and fix copying the documentation - this will also allow us to easily add other documentation at a later date. It's copying to the boost root directory. If you'd rather keep things contained it could use repeated calls to xcopy for the relevant directories, although that would require changing the scripts every time some new documentation is added. Does it look okay to you? Daniel

2 1

[multi_index] feature proposal: member keys and typeless specification of keys
by JOAQUIN M. LOPEZ MUÑOZ 08 May '11

08 May '11

Hi all, This is a proposal for inclusion of two new features into Boost.MultiIndex, mem_key and BOOST_MULTI_INDEX_AUTO_KEY. Consider the following: struct foo { int x; int bar(); int baz()const; }; typedef multi_index_container< foo, indexed_by< ordered_unique<member<foo,int,&foo::x> >, ordered_unique<mem_fun<foo,int,&foo::bar> >, ordered_unique<const_mem_fun<foo,int,&foo::baz> > > > multi_t; Note that we have to use member, mem_fun or const_mem_fun depending on the kind of key used. mem_key allows for a uniform specification syntax: typedef multi_index_container< foo, indexed_by< ordered_unique<mem_key<int foo::*,&foo::x> >, ordered_unique<mem_key<int (foo::*)(),&foo::bar> >, ordered_unique<mem_key<int (foo::*)()const,&foo::baz> > > > multi_t; This in itself gains us relatively little; but if we have a C++11 compiler with decltype, BOOST_MULTI_INDEX_AUTO_KEY can use mem_key in a way that dispenses with the need for specifying the type of the key! typedef multi_index_container< foo, indexed_by< ordered_unique<BOOST_MULTI_INDEX_AUTO_KEY(&foo::x)>, ordered_unique<BOOST_MULTI_INDEX_AUTO_KEY(&foo::bar)>, ordered_unique<BOOST_MULTI_INDEX_AUTO_KEY(&foo::baz)> > > multi_t; Some requests and questions: 1. If you're interested in these features, please download the attached mem_key.hpp file, play with it and report on successful/problematic usage. 2. Do you think this is worth including in Boost.MultiIndex? 3. Proposals on the naming scheme? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx

3 6

[provocative] Whom did the SFC pay to list boost developers as a whole in "Current Member Projects"?
by Alexander Terekhov 08 May '11

08 May '11

http://sfconservancy.org/members/current/ (Current Member Projects) "Boost provides free peer-reviewed portable C++ source libraries. Boost emphasizes libraries that work well with the C++ Standard Library. Boost libraries are intended to be widely useful, and usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. Boost aims to establish existing practice and provide reference implementations so that Boost libraries are suitable for eventual standardization. Ten Boost libraries are already included in the C++ Standards Committee's Library Technical Report ( TR1) as a step toward becoming part of a future C++ Standard. More Boost libraries are proposed for the upcoming TR2." The context: (pacer) 03/23/2011 192 ENDORSED LETTER addressed to Judge Shira A. Scheindlin from David Leichtman dated 3/23/2011 re: Requesting that the Reply and Kuhn Declaration be stricken, or in the alternative, that the Court consider Best Buy's responses to these new theories and arguments. ENDORSEMENT: Defendant's request is granted. The Court will consider Best Buy's response to the new issues raised in Plaintiffs' Reply, as set forth in this letter. So Ordered. (Signed by Judge Shira A. Scheindlin on 3/23/2011) (jpo) (Entered: 03/23/2011) 04/14/2011 193 OPINION AND ORDER. For the reasons in this opinion and order, plaintiffs' motion to join WD is denied. The Clerk of the Court is directed to close this motion (Docket No. 133). (Signed by Judge Shira A. Scheindlin on 4/14/2011) (rjm) (Entered: 04/15/2011) 04/26/2011 194 ENDORSED LETTER addressed to Judge Shira A. Scheindlin from Emmett J. McMahon, dated 4/25/2011, re: Counsel for the defendant Best Buy Co., writes to request a pre-motion conference regarding a motion to strike Plaintiffs' claim for "actual damages and any additional profits of [Best Buy] incurred as the result of infringement." ENDORSEMENT: Request granted. A premotion conference will be held on May 6 at 2:30. So Ordered. (Pre-Motion Conference set for 5/6/2011 at 02:30 PM before Judge Shira A. Scheindlin) (Signed by Judge Shira A. Scheindlin on 4/25/2011) (lnl) (Entered: 04/26/2011) (details) http://www.terekhov.de/192.pdf http://www.terekhov.de/194.pdf Suggestion: Please remove boost from http://sfconservancy.org/members TIA. regards, alexander.

9 22

[GSoC] Getting started
by Andrew Sutton 07 May '11

07 May '11

Hello GSoC students and mentors, Students, if you haven't contacted your mentor, now would be the time do so. Mentors, if you haven't heard from your students, you need to try to get in touch with them. If anybody is having trouble getting a hold of their student or mentor, please let me know. During the "Getting to Know You Phase", you should be doing two things: 1. Defining goals and expectations for the summer and 2. Starting to get up to speed with Boost's development environment Remember, that there is a midterm review. It is usually a good idea to set concrete midterm goals in order to ensure that your project is moving forward. Also, the source code of your project MUST be available for review by both your mentor and the community at large. Basically, this means you need to have it publicly hosted. The obvious solution is to house the project in the Boost Sandbox (http://svn.boost.org/svn/boost/sandbox/SOC/2011/) You will probably need to request write access from the Boost owners (boost-owner(a)lists.boost.org) Send them an email. If your project is already hosted online (independently or as part of another project), then we need to know where it is. Please send an email to the list describing how we can check out the source code of your work. I will add the addresses of these projects to the Boost-GSoC wiki page so other interested parties can find them. That's it for now. Good luck! Andrew

3 2

[Review] Boost.Convert, review manager analysis
by Edward Diener 07 May '11

07 May '11

As previously stated Vladimir Batov decided to withdraw his library at the end of the review period from consideration for inclusion into Boost and I had announced this and the fact that because of this the library would not be accepted. Nonetheless I want to give my analysis of the reviews and the issues both pro and con of the reviewers. I also want to give some of my own thinking on these issues. There were few reviews of the library but much late discussion in the final day of the review period and just afterward. There were 2 reviews which voted to accept Convert ( Artyom Bellis, Alfredo Correa ), 3 reviews which voted not to accept Convert ( Jeroen Habraken, Thomas Heller, Hartmut Kaiser ), 1 review which would have accepted Convert but qualified that only if lexical_cast could not be extended instead ( Rob Stewart ), 1 review which would have accepted Convert with large scale changes ( Gordon Woodhull ), and one mention, not a formal review, of acceptance until something else came along but with perhaps a later change of mind ( Paul Bristow ). There was also one review sent to me personally by Barend Gehrels, after Vladimir Batov withdrew his library, which voted not to accept Convert. There were also a number of people who raised doubts and objections to Convert in various ways without giving a formal review. It is all these issues raised by reviewers and commenters I want to discuss next. Vladimir Batov was responsive to nearly all of those issues but I want to enumerate them and give my own thoughts about them as I read reviews and comments. A number of people wanted lexical_cast to be extended instead of a new library. This certainly is a valid viewpoint. But I believe that the lexical_cast library is set as it is until someone takes it over from its original author and is willing to change it. I think it is better to review the library under discussion rather than to hope that something else can be changed in the future. There was an issue of the basic syntax which many people did not like. Instead of the syntax of 'convert<dest>::from(source)' there were a number of people who wanted to see 'convert<dest>(source)' instead, largely becaused it matched the 'lexical_cast<dest>(source)' syntax. Vladimir Batov explained why he used the syntax he did. I think in this case it is reasonable. Again this is an issue in relation to lexical_cast, and I saw no real significant difference between the syntaxes on a basis of practical use. The main issue brought out by many people is whether a single function can encompass successfully all of the functionality which Convert wished to encompass and whether this functionality both worked smoothly with everything others wished to do with the functionality. Here there were many valid objections and I will attempt to enumerate them: 1) The return value of the convert function is really many different returns, and this is done through implicit conversions of the actual return type. This was mentioned most eloquently by Thomas Heller. It is quite natural to assume that the return value of a successful call to 'convert<dest>::from(source)' would be a 'dest' object but instead it is a value which has an implicit conversion to 'dest'. This works when passing the value to ordinary functions but does not when passing the value to template functions. As Vladimir Batov mentioned one can use the 'value()' member function of the return value, and presumably also one can use a 'static_cast<dest>' also, to force the exact 'dest' object to be passed, but I also viewed this as a negative way to work, and a very valid objection to the way Convert was designed. To me it was not just a matter of confusion to the end-user but of a naturalness of use. A convert-type interface should have some function where, if the convert is successful, the actual result of the conversion is returned, and not some intermediate value with an implicit conversion. 2) The Convert library uses a stream-based method to do conversions but wanted to leave the door open for other methods. Part of the extended syntax of the library works with stream manipulators and locales. A very valid point was brought up, again by Thomas Heller, that it is not clear how the extended syntax is supposed to work with and affect non-stream based specializations of the basic convert template. Even the method of extending the library in this way, rather than just providing stream-based operators for a given type, is open to much doubt as valid C++ and largely left unexplained in the documentation. 3) The syntax for the stream-based and locale additions to the library's functionality was found odd by many people. The term 'wacky' was often used and Vladimir Batov did defend his choice about it well. Nonetheless it is a valid issue to consider whether the extended syntax is easy for a person to use. I found the syntax for using iostream manipulators quite natural, and the syntax for locales and other functionality such as throwing behavior less natural. Again I do not want to get too caught up in syntactical issues but I did understand the issues brought up by others regarding this. 4) The method of using the convert function in algorithms was criticized. Some people expressed their wish that a placeholder syntax, as used by other Boost libraries, be used. I actually found the way Convert does this as pretty elegant, there were two syntaxes which worked, but could understand others liking for the placeholder syntax. 5) The use of a default value, the issue of a default constructor, and the differing results when a conversion fails or not, received much discussion, especially at the official end of the review period and afterward, and I appreciate reading all of the discussions. I do not want to specifically go into each one, other than to say that I think this has basically to do with the issue of having a single function do everything which could not easily cover all the different scenarios mentioned for actual use. There were other valid concerns which are related to just a need for more complete documentation. Vladimir Batov responded to most of them. Here I will enumerate them: 1) Rob Stewart in his review mentioned many documentation corrections related to grammar, spelling etc. 2) What locale is being used by default is not explained. 3) The reference is very incomplete. 4) The section for extending the library is unclear and incomplete. Finally there were valid concerns relating to getting Convert to work properly. Some of these related Convert and lexical_cast and noted the differences. A few others mentioned things which just did not work properly in the actual conversion and again Vladimir Batov said he would look at these issues. Barend Gehrels sent me a late review, which he did not want to post to the mailing list because Vladimir Batov had already withdrawn is library, in which he said that he had some technical problems adapting a Boost.Geometry type to work with Convert. I think these are all technical issues which can be resolved. Many other people had specific incisive remarks during the review period but I can not list them all. That does not mean those remarks were ignored by me in any way, as I read and attempted to digest what everyone had to say. Final remarks: I would like to bring some clarity to the issues which may have forced Vladimir Batov to essentially withdraw his library at the end of the review period from consideration and which led to much comment and criticism about the library. This is my purely personal take on the library, but it is based on my technical understanding of the issues involved. The main issue with the library is that the 'single function fits all scenarios' works much less well in practical use than the author supposed, even as I understood the reason for simplicity which caused him to pursue this path. There really needs to be a function that simple returns the converted value upon success. Overloaded versions of that function, or differently named functions, can return other specific things. Where there is a great attraction to a return value which can be implicitly converted to other values, I think this attraction given practical use is somewhat illusory. While I did not enjoy some of the harsher remarks made by Thomas Heller in his review of the library about the design of Convert ( and I do not think he really meant them as harshly as they may have sounded ) he did rightly point out that the 'overloaded' return value is an impediment to a cleaner design which would allow one to use the right convert function given the possibilities which the library wants to accomplish. I know there has been many subsequent discussions about a set of functions that can replace the single function in Convert depending on how Convert can be used, and I do not myself want to get in the middle of this debate, but once there is an understanding of what needs to be done, I really think the library can be designed to appeal to end-users in a better way. The second issue in my mind is that the library attempts to do too much given the way it was designed. If the focus is simply a library which does stream-based conversion between strings and objects ( both ways ) I personally think it would be much better. Once you look for non-stream based conversions you have to consider more carefully how the stream-based syntax and locales should be integrated with the library. Once you look for type to type conversions rather than string to type and type to string conversions you have to design a good general facility for specifying how this is done within the functions you provide. This is a much bigger job of thinking about design, unless you are simply providing a very generalized shell with little real functionality built-in. I am not saying the author of the library has not thought about these issues, but my impression is that they have not been addressed carefully. Just in case anyone wanted to know, and also so that Vladimir Batov does not feel so bad about withdrawing the library from consideration at the end of the review period, I would have rejected the library for inclusion into Boost given the reviews and comments of others and my own perceptions of the issues involved. But I think the author has still done a fine job and is close to having a library which could be included as a part of Boost. Although it is hard work, it has been a pleasure to be a review manager of this library and I thank everyone involved and especially the author of the Convert library himself. Edward Diener

2 1

[Block Pointer] Docs
by Phil Bouchard 06 May '11

06 May '11

Hi, Sorry for the repetitive emails and thanks to Gregory Crosswhite regarding it but I have improved the user-friendliness of the utility: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/overvi… Please let me know if there's anything unclear. Thanks, -Phil

2 6

[PBGL] Distributed adyacency_list memory allocation
by Cosimo Calabrese 06 May '11

06 May '11

Hi to all, I'm working on WinXP, VS2010, boost 1.46.1. I've writed this short program: //---------------------------------- #include <boost/graph/use_mpi.hpp> #include <boost/graph/distributed/mpi_process_group.hpp> #include <boost/graph/distributed/adjacency_list.hpp> using boost::graph::distributed::mpi_process_group; typedef boost::property<boost::vertex_distance_t, long, boost::property<boost::vertex_name_t, std::string > > vertex_prop; typedef boost::property<boost::edge_weight_t, long > edge_prop; typedef boost::adjacency_list< boost::vecS, boost::distributedS<mpi_process_group, boost::vecS>, boost::directedS, vertex_prop, edge_prop > Graph; typedef boost::graph_traits<Graph>::edge_descriptor EdgeDescriptor; typedef boost::graph_traits<Graph>::vertex_descriptor VertexDescriptor; int main(int argc, char* argv[]) { boost::mpi::environment env(argc,argv); Graph g( 10 ); return 0; } //---------------------------------- When I launch it, every process allocates about 1 GB of memory. Why it allocates all that memory? Is it normal? Is there any tuning to the PBGL framework that I must made? I use it on a 2-core machine, and the command that I use is: mpiexec -n 2 .\test.exe I've tried with openMPI 1.4.3 and Microsoft HPC Pack 2008, but it seems irrilevant. Thanks in advance, Cosimo Calabrese.

2 1

Extending multi_index_container hash tables
by Vladimir Voznesensky 06 May '11

06 May '11

Hello there. Current implementation of hashed index has, at least, two issues, preventing me from re-using it in some places. First, the time for unlink operation in multi_index/detail/hash_index_node.hpp is O(m) where m is a occupancy of the given bucket. I'ts usually ok for unique index, but seems to hit performance of removing item in a non-unique index. It's all because of using single-linked list instead of double-linked one. Second, there is no possibility to use internal order of the records in the bucket, i.e. operations like popping the last element in the bucket's list. Such feature could be useful for, for example, priority queues. It could be realized by using such double-linked (or extra pointers in a bucket structure). Sure, I could get the current realization and write my own index, but it seems wiser to extend the current implementation to support custom bucket container or custom node as a template parameter. Thanks in advance. VV

2 1

Re: [boost] [review] string convert
by Vicente BOTET 06 May '11

06 May '11

Hi, are we discussing here a generic interface from type-to-type or one that uses an intermediary stream to make the conversion? If it is the first I could accept names as convert_cast or convert_to. If it is the second, I don't think it is appropriated to use this generic form and something in the name must recall this feature. lexical_cast is used for exactly this purpose and the name is appropriated. How could we rename the Boost.Convert library? Boost.StreamConvert? and the operations? Best, vicente

4 9

[autoindex] Rationale Question
by Artyom 06 May '11

06 May '11

Hello, It is not a review but rather questions about this tool rationale. Form the very brief look into AutoIndex documentation I see. > ... AutoIndex will automatically scan one or > more C/C++ header files and extract all the > function, class, macro and typedef names that > are defined by those headers, and then insert > the <indexterm>s into the Docbook XML document for you. > However, there is a tool Doxygen that already does this. Doxygen is fully capable system for indexing source files and providing references for them. For example: http://cppcms.sourceforge.net/boost_locale/html/namespacemembers.html http://cppcms.sourceforge.net/boost_locale/html/namespacemembers_func.html So there is a well debugged, tested, supported indexing tool (Doxygen) that as far as I know works fine and is already used by Boost. So the question are 1. How does it differs from Doxygen indexing? I'm not talking about the integration with various pars of Boost documentation toolchain but rather what it does differently. 2. Why have you decided to develop entirely new tool instead of using existing one. I probably miss some points but I rather see a great tool Doxygen that already does many things and does them well but still Boost creates its own tools (and this does not happen first time) Thanks, Artyom

3 2

[xint] Formal Review Result
by Vladimir Prus 06 May '11

06 May '11

I apologize for the delay in producing the final summary and result of the Boost.Xint review, but here it is. Votes ===== YES: - Christian Henning - Steven Watanabe - Jarrad Waterloo - Edward Diener - Paul A. Bristow NO : - Mathias Gaunard - Joel Falcou - Anders Dalvander - Joachim Faulhaber - Phil Endecott - Domagoj Saric - Gordon Woodhull ("fraction of a vote") I might have missed somebody inside the 454 messages I have as result of the review, but the overall picture is clear -- the votes are split. High-level issues ================= - The claim that the library is "fast" is not necessary true. Phil has did some checking against hand-written assembler that don't look too good. - It is not clear whether the design allows for improving performance of fixed-size integers using specialization (again, see Phil's comments) - There were concerns about COW. In particular, it was very clearly stated that if COW is used, it should work fine in multi-threaded programs. - It was suggested to use ET. - Some folks suggested better separation between algorithms and data representation. Specific issues =============== - It was pointed out that "a + b + c" creates a pile of temporaries, and this can be improved without using ET. - Joachim's review raised a lot of valid points. Section 3 of his reviews in something that should be addressed, more or less entirely. Note that while we normally don't force specific coding style, some of formatting pointed out is simply unacceptable if this code is to be read by anybody. - 'Secure' flag is probably not so much of it. Future directions ================= I think that reviews by Phil and Joachim are most important in specying evolutionary directions for Boost.XInt. Chad made several comments about what he plans to do, in particular: - http://article.gmane.org/gmane.comp.lib.boost.devel/216935 Conclusion ========== I think there's no doubt that (i) this domain is important and (ii) Chad has put a lot of work into this library, producing several iterations. It was pointed out that we have many arbitrary-precision libraries skeletons all around Boost, and providing such a solid offering for review is a significant accomplishment. And it everybody learned a lot during the review. There was a couple of important meta-points raised during review -- whether review should focus on external interface only, and what is the scope of the library. Some reviewers argued that only external interface matters. However, it seems to me (as review manager), that concerns about internal design are valid, and may not be rejected offhand. After all, external interface of an integer library is more or less defined by mathematics, and internal design plays a key role in successfull evolution of the library. There was also heated discussion about the scope of the library, in particular support for fixed-width integers. I think that it's abstractly OK for this library to treat fixed-width integers as second-class citizens. However, I am having hard time determining the intended scope of the library. If I'm doing cryptography, would I really want to implement cryptography algorithms from the books with Boost.XInt, only to introduce bugs that are probably fixed in existing implementations (often, included in the OS). And if I'm really intent on doing that, I probably want raw performance, including a way to plug in optimized backends using SSE 2011, CUDA, and whatever fancy technology is there. If I'm doing general programming, then I'm most likely interested in not too big integers. They might be fixed-width 128-bit integers, or they might be something larger-than-64, but not necessary fixed. However, such integers are not the scope of the library, and they were found to have suboptimal performance. It is certainly possible to refine/define the scope, optimize everything for that scope, accomodate the proposals made during review, and obtain an excellent Boost library. However, there are some many suggestions, and so many planned redesigns and changes, that we need a second look at the library. Further, because of the global nature of the changes, it would be very hard to identify a specific subset that must be improved and then go through mini-review. For that reason, I've arrived at the the following result: Boost.Xint library is not accepted at this time. We'll be happy to have another full review of the library when the next version is ready. Thanks to Chad for the submission and for everybody who participated in the review! - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40

10 17