- Boost - lists.preview.boost.org

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

FW: Registration Available
by Hartmut Kaiser 06 May '11

06 May '11

FYI... Regards Hartmut --------------- http://boost-spirit.com > -----Original Message----- > From: boostcon-plan(a)googlegroups.com [mailto:boostcon- > plan(a)googlegroups.com] On Behalf Of Marshall Clow > Sent: Friday, May 06, 2011 11:25 AM > To: boostcon-plan(a)googlegroups.com > Subject: Registration Available > > Oliver Mueller <oliver.mueller(a)gmail.com> has discovered that he will not > be able to attend BoostCon. > Unfortunately for him, it is well past the refund deadline (which was > 4./14), so he's looking for someone to use his registration. > > If you know someone who could take advantage of a deal on admission, they > should get in touch with Oliver and work something out. > > -- Marshall > > Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> > > A.D. 1517: Martin Luther nails his 95 Theses to the church door and is > promptly moderated down to (-1, Flamebait). > -- Yu Suzuki

1 0

Re: [boost] [Boost-users] [Boost.Spirit] RFC: bin_float parser
by Vitaly Budovski 06 May '11

06 May '11

On 6 May 2011 10:33, Joel de Guzman <joel(a)boost-consulting.com> wrote: > On 5/5/2011 9:08 PM, Vitaly Budovski wrote: >> Greetings, >> >> On 28 April 2011 12:09, Hartmut Kaiser <hartmut.kaiser(a)gmail.com> wrote: >>> Thanks for this! >> >> Apologies for the long delay in replying. >> >>> >>> A couple of comments: >>> >>> 1) Is there a reason why you created separate components instead of simply extending the existing set of binary parsers/generators? >> >> It seemed like it would be a lot more work. I'm guessing I would need >> to add a new template parameter or maybe use the preprocessor, since >> the classes have a few integer<> types inside. Can you suggest a >> better way? >> >>> >>> 2) What's the rationale for not using/extending the endian classes in Spirit, but providing your own set of independent endian types? >> >> See response above :) Another thing I wasn't too happy with was the >> fact that they are in the integer namespace. Perhaps they should be >> moved out of there, since endianness doesn't apply only to integers. >> >>> >>> 3) If this is to be included into Spirit we'd need the corresponding docs as well. >> >> A few more test cases couldn't hurt either. I discovered I missed an >> asterisk in the generate_to line of bin_float_generator. >> Is there a guide for adding docs to boost? > > Boost Spirit uses quickbook. Please check out the Spirit docs. > Here's a link to quickbook: > http://www.boost.org/doc/libs/1_46_1/doc/html/quickbook.html > > Vitaly, the proper forum for this is the Spirit general or devel mailing list: > See Boost.Spirit lists here: http://www.boost.org/community/groups.html > Can we please move the discussions there? > > Regards, > -- > Joel de Guzman > http://www.boostpro.com > http://boost-spirit.com > Thanks Joel. Moving conversation to more appropriate location. Cheers, Vitaly

1 0

next version dates
by Andy Tompkins 05 May '11

05 May '11

Hi, Has it been decided the dates relevant to the next version? I have only looked here (http://www.boost.org/development/index.html) and didn't see anything. I'm not trying to change / hurry or delay anything. I just want to start moving some changes from trunk to release, but I work slowly and want to start closer to the beginning of a release, not closer to the end of one. Regards, Andy Tompkins.

6 12

[foreach] Warning with gcc-4.6.0 and -Wconversion
by Philipp Reh 05 May '11

05 May '11

gcc-4.6.0 made Boost.foreach unusable in 1.46.1 because the rvalue detection no longer works. Now, there is a fix in trunk for it but it has a nasty side effect, namely a warning that is emitted whenever foreach is used with an rvalue and -Wconversion is turned on. Sadly, this warning cannot be ignored by including Boost with -isystem because the code is generated by a macro, obviously. Here is a simple program to reprdouce this: #include <boost/foreach.hpp> #include <iostream> #include <ostream> #include <vector> typedef std::vector< int > int_vector; int_vector const test() { int_vector ret(2, 2); return ret; } int main() { BOOST_FOREACH( int_vector::const_reference ref, test() ) std::cout << ref << '\n'; } This prints the following warning: test.cpp:21:2: warning: choosing ‘boost::foreach_detail_::rvalue_probe<T>::operator boost::foreach_detail_::rvalue_probe<T>::value_type() [with T = const std::vector<int>, boost::foreach_detail_::rvalue_probe<T>::value_type = const std::vector<int>]’ over ‘boost::foreach_detail_::rvalue_probe<T>::operator T&() const [with T = const std::vector<int>]’ [-Wconversion] test.cpp:21:2: warning: for conversion from ‘boost::foreach_detail_::rvalue_probe<const std::vector<int> >’ to ‘const int_vector’ [-Wconversion] test.cpp:21:2: note: because conversion sequence for the argument is better I would be glad if this could be fixed somehow because -Wconversion is a crucial warning option to me.

3 3

Boost.Locale and the standard "message" facet
by Vicente BOTET 05 May '11

05 May '11

Hi, I was wondering how Boost.Locale is related to the standard message facet which is used to translate messages. Note that the facet interface work with integer identifiers avoiding all the issues raised by the get_text/translate functions provided by Boost.Locale. Is there any reason Boost.Locale could not follow the standard design? What are the advantages of the Boost.Locale design? Best, Vicente

4 6

[config] Macro BOOST_NO_NOEXCEPT is required
by Takaya Saito (SubaruG) 05 May '11

05 May '11

http://thread.gmane.org/gmane.comp.lib.boost.devel/214978 I think the macro BOOST_NO_NOEXCEPT ( or BOOST_NO_0X_NOEXCEPT ) is required soon. How's the status now?

5 7

result_of overloaded member function?
by Arno Schödl 05 May '11

05 May '11

Hello, is there a way to get the result type of an overloaded member function? Something like: template< class T, class A > typename boost::result_of< T::func(A) >::type invoke( T& t, A& a ) { return t.func(a); } Thanks for help, Arno -- Dr. Arno Schödl | aschoedl(a)think-cell.com Technical Director think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl

3 3

[Convert] Not a review
by Phil Endecott 05 May '11

05 May '11

Dear All, I've not looked at this library in anything like enough detail to write a proper review, though I have followed a fair amount of the discussion both during the review and during previous discussions of a "better lexical_cast". My view comes down to this: there are zillions of different ways of doing this (both syntax and semantics) and no solution can keep everyone happy (as evidenced particularly by the previous discussions). But that doesn't matter, because every single C++ programmer is capable of writing their own conversion functions that work exactly how they want them to work, if they have the right building blocks. The building blocks are things like C's strto*(), etc. Personally, I prefer thin wrappers like these ones: template <typename ITER> long int strtol(ITER begin, ITER end) { ... } template <int N> long int strtol(const char (&s) [N]) { return strtol(&s[0],&s[N]); } inline long int strtol(std::string s) { return strtol(s.begin(),s.end()); } For variations on error policy I add words like "try", "must" or "maybe" to the function name; similarly for hex and other variations. But I don't suggest that these are going to suit other people. Why should we try to find a "one size fits all" solution to this problem? In my humble opinion, Boost does not need this functionality. Perhaps some of the lower-level "building blocks" would be useful, though - if things like strto*() are deficient. Regards, Phil.

3 4

Re: [boost] howto: boost.lambda + stl on VS 2010 (SP1) ?
by Peter Dimov 05 May '11

05 May '11

Raffi Enficiaud wrote: > To this point, I thought that using accumulate would be cleaner: > std::accumulate(m.begin(), m.end(), double(0), & _1->*&aa::second); std::accumulate takes a binary function. It doesn't do s += f(*i) as you seem to think, it does s = f(s, *i). So you should probably pass _1 + &_2->*&aa::second to it.

1 0

howto: boost.lambda + stl on VS 2010 (SP1) ?
by Raffi Enficiaud 04 May '11

04 May '11

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" ? To this point, I thought that using accumulate would be cleaner: std::accumulate(m.begin(), m.end(), double(0), & _1->*&aa::second); But I have several compilation errors, and on the top of it: 1>(..)/boost-1_46_1\boost/lambda/detail/member_ptr.hpp(512): error C2296: '->*' : illegal, left operand has type 'const rt0 ' 1> boost/lambda/detail/member_ptr.hpp(622) : see reference to function template instantiation 'RET boost::lambda::detail::member_pointer_action_helper<true,false>::apply<RET,A ,B>(A &,B &)' being compiled 1> with 1> [ 1> RET=unsigned short &, 1> A=rt0, 1> B=rt1 1> ] I do not really understand what rt0/rt1 are. The former should be the iterator::value_type and the latter the pointer to member. Most of all, the call with accumulate looks very similar to the for_each one to me. So, is the problem between the keyboard and the chair ? Best, Raffi

1 0

[Block Pointer] make_block
by Phil Bouchard 04 May '11

04 May '11

Hi, I just disabled the constructor and the assignment operator having a raw pointers as a parameter and I added the make_block factory function. We can see it in action in the following example: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/example/bl… Is it time for a review? -Phil

7 23

[Spirit Karma] Mutable references formed by pass_container in Karma "repeat" tests
by Doug Gregor 04 May '11

04 May '11

There are a few Karma failures using the latest Clang due to the pass_container detail class forming mutable references: http://www.boost.org/development/tests/release/developer/output/dgregor2-bo… I know that at least some compilers (e.g., GCC) don't diagnose mutable references, but this code is ill-formed account to the standard. Someone want to take a shot at eliminating or factoring out the mutability to avoid these mutable references? - Doug

2 1

[Review] Boost.Convert library, last day
by Edward Diener 04 May '11

04 May '11

This is a reminder that formal review of the Boost.Convert library by Vladimir Batov ends today, May 2. There have only been a few reviews of the library so the library welcomes reviews. If you are one of the people who have been dissatisfied by the perceived limitations of Boost lexical_cast, or have discussed such limitations on Boost mailing lists in the past, please look at the library and give a review of it, as its intent is to offer a greatly enhanced version of lexical_cast as a new library. *************** * Its Purpose * *************** The library builds on the past boost::lexical_cast experience, then takes those conversion-related ideas further to suit better today's applications and programing needs. It still offers simple, minimal interface, familiar conversion behavior and additionally provides: * throwing and non-throwing conversion-failure behavior; * support for the default/fallback value to be returned when conversion fails; * two types of the conversion-failure check - basic/simple and better/safe; * formatting support based on the standard std::streams and std::stream-based manipulators (like std::hex, std::scientific, etc.); * support for different locales; * support for boost::range-compliant char and wchar_t-based containers; * no DefaultConstructibility requirement for the Target/Destination type; * consistent framework to uniformly incorporate any type-to-type conversions, extensibility and additional room to grow. With its present support for string-to-type and type-to-string conversions it is an essential tool for applications making extensive use of configuration or MS-Windows-Registry-style files or having to process/prepare considerable amounts of data in, say, XML, etc. More so, it is easily extendable to accommodate, specialize and uniformly deploy new user-defined type-to-type conversions. ******************* * Where to get it * ******************* The Boost Vault is accesible again after being down for most of the week, so you can get the library from the Boost Vault at http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost-… You can also get the library, using Subversion, from https://svn.boost.org/svn/boost/sandbox/convert. The HTML documentation is part of the distribution and can be found at libs/convert/index.html in the distribution above. ******************** * Writing a review * ******************** The reviews and all comments should be submitted to the developers list, and the email should have "[convert] Review" at the beginning of the subject line to make sure it's not missed. Please explicitly state in your review whether the library should be accepted. The general review checklist: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Edward Diener, Review Manager

10 17