June 2011 - Boost - lists.boost.org

[review][assign] Formal review of Assign v2 ongoing
by John Bytheway 23 Jun '11

23 Jun '11

A reminder that the formal review of the Assign v2 library upgrade by Erwann Rogard is ongoing, and is scheduled to continue until June 24th. Please consider looking at the library and submitting a review. About Assign v2 =============== Assign v2 is an upgrade of Boost.Assign (1.0) that redefines its functionality, with optional C++0x support and new features. It is a compact interface for executing the repetitive tasks of assigning or inserting container elements. For example, std::map<std::string, int> map; // Inserts each pair ("jan", 31),...,("may", 31) in map: csv_put<2>(map, "jan", 31, "feb", 28, "mar", 31, "apr", 30, "may", 31); Please see the change log (linked below) for more detail on the motivation for this library and pointers for navigating the documentation. Where to get it =============== The documentation is online at: <http://svn.boost.org/svn/boost/sandbox/assign_v2/libs/assign/v2/doc/html/in…> With the change log at: <http://svn.boost.org/svn/boost/sandbox/assign_v2/libs/assign/v2/doc/html/bo…> The Assign v2 source can be found in the Boost sandbox at: <http://svn.boost.org/svn/boost/sandbox/assign_v2/> or downloaded from: <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=assign…> Review guidelines ================= Reviews should be submitted to the developer list (boost(a)lists.boost.org) with '[assign]' in the subject. Or if you don't wish to for some reason, you can send them privately to me. If so, please let me know whether or not you'd like your review to be forwarded to the list. All reviews are appreciated, even if you don't have time for an in-depth study. The Assign v2 library consists of several largely independent components: Reference containers and chaining, container modification and generation, and conversion of ranges to containers. If you wish, feel free to review and even vote on these separately. For your review you may wish to consider the following questions: - 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. More detail on the review process is available at: http://www.boost.org/community/reviews.html John Bytheway Review Manager

7 17

[accumuators][1.47] docs build
by John Maddock 22 Jun '11

22 Jun '11

I'm not sure if this is likely to cause issues or not, but the accumulators docs, generate some file names in ALL_UPPER_CASE.hpp which is against our filename policy. Cheers, John.

2 1

[interprocess] Possible bug in offset_ptr
by Lars Hagstrom 22 Jun '11

22 Jun '11

Hi, I reported a problem to the clang project about a problem I had with some release-compiled boost code. They're claiming it is a problem in offset_ptr, where the pointer arithmetic causes undefined behaviour according to the C++ standard. See: http://llvm.org/bugs/show_bug.cgi?id=10119 This seems like a fairly major thing, if it is true. Cheers Lars

2 2

[quickbook][phoenix] Can't build Phoenix as a PDF.
by John Maddock 22 Jun '11

22 Jun '11

Just a heads up that I'm currently unable to build the Phoenix docs (in libs/phoenix/doc) as a PDF for 1.47. The issue is that there are a few anchors: phoenix.preface phoenix.description phoenix.how_to_use_this_manual phoenix._emphasis_role__bold___emphasis____to_joel_s_dear_daughter__phoenix__emphasis___emphasis_ which are placed at <chapter> scope in the Docbook XML - this is legal according to the Docbook DTD, but produces invalid FO when using the latest Docbook XSL stylesheets (results in an <fo:inline> at <fo:flow> scope which isn't legal. Although this is probably a Docbook bug, it's not entirely unreasonable: anchors at <chapter> or <book> scope appear outside any logical page sequence in the FO, hence the error. Am I correct in thinking that these anchors are created by quickbook? Thanks, John.

2 1

[Phoenix] Two sets of docs?
by John Maddock 22 Jun '11

22 Jun '11

Currently Phoenix has it's own docs under libs/phoenix/doc, but there are also docs under libs/spirit/phoenix/doc. Should the latter have been removed now? Trying to work out what to build as PDF's yours, John.

3 3

[release] Release notes
by Daniel James 21 Jun '11

21 Jun '11

Hi, If you haven't done so already, it's a good time to write your release notes. You can either email them to me, or make the changes yourself in subversion. The file is at: http://svn.boost.org/svn/boost/website/public_html/beta/feed/history/boost_… thanks, Daniel

8 9

[BGL] Graph union
by Shaun Jackman 21 Jun '11

21 Jun '11

Hi, Is there a graph adapter that presents a view of the union of two graphs? The union graph would not be modifiable. graph_union<G1, G2> unionGraph(g1, g2); If not, any tips on how to go about implementing this? Cheers, Shaun

2 1

Re: [boost] [GSoC] Request for Feedback on Boost.Bloom Filter Project
by Alejandro Cabrera 21 Jun '11

21 Jun '11

> On 6/21/2011 12:21 AM, Alejandro Cabrera wrote: >> Hello all, >> >> I'm writing to request feedback, suggestions, and advice from the Boost >> community. I've been working on a Bloom filter data structure for about >> a month and a half now. At this point, the following is complete and >> available in the Boost Sandbox: >> - working, basic prototype (insert& query operations, union& intersect) >> - a test suite covering the public interface >> - five examples >> - documentation covering many aspects of the project (tested on Chrome >> 12 and 13, Firefox 4 and 6) > I would suggest to you that you briefly explain what a Bloom filter > entails, and why it might be important, when sending your message to > this list. > Thank you for the suggestion. The data structure is introduced below. Briefly, a Bloom filter is a probabilistic data structure that represents a set of elements compactly. Two operations are supported in the most basic variant: insert, contains. An element is inserted by computing k hash values and setting the bits at the locations given by the hash values to 1. Checking whether an element is contained in the Bloom filter is achieved by hashing the element and checking that the bits at those locations are all 1. A Bloom filter may incorrectly tell you that an element is in the set (false positive). If false positives are acceptable, Bloom filters are a powerful data structure to avoid expensive look ups. There exist variants that also support element removal at the cost of an increase in storage requirements and the danger of false negatives - these are not covered by Boost.BloomFilter just yet. Bloom filters have seen use in file systems (avoiding duplicate writes, deduplication), network caches (determining whether to attempt to fetch from cache), databases (does a row/column exist on disk?) and hardware design. Where the primary interest is to compactly represent a potentially very large universe of elements to mitigate latency differences, Bloom filters are a great choice. Further details can be found in the project documentation files.

1 0

[type traits] Strange behaviour of comparison operators with pointers
by Frédéric Bron 21 Jun '11

21 Jun '11

The following code gives a compile time error (g++ and msvc): int const lhs=1; int* rhs=0; lhs == rhs; But the following code gives no error: int const lhs=0; int* rhs=0; lhs == rhs; because a const int with 0 value is a valid null pointer! Then there is no way to predict if it is possible to compare lhs and rhs based only on their types. The general rule is that it is not possible so that this is what I propose to use for the type trait extension detecting the possibility to call comparison operators on given types. Frédéric

4 7

Re: [boost] [gui] Help with a little experiment.
by Artyom Beilis 21 Jun '11

21 Jun '11

----- Original Message ---- > From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> > To: boost(a)lists.boost.org > Sent: Mon, June 20, 2011 12:09:50 PM > Subject: Re: [boost] [gui] Help with a little experiment. > > On 18/06/2011 16:55, Artyom Beilis wrote: > > > Making a GUI library is not about providing > > nice syntactic sugar for building layout. > > > > Syntactic sugar is the last thing that should interest you. > > Having a short and concise declarative definition of your GUI has several >advantages. > It's easier to validate it, it allows to avoid bugs, and you can really >materialize > the intent of what you want instead of coding its logic directly. > > Moreover, writing GUIs is very tedious and uninteresting. It would be nice > if it were possible to automate more things. Few points. If you want an easy and fast declare GUI there are many RAD tools like QtCreator or Glade that do this job well. On the other hand. When I was programming some GUI tools the **easiest** part was to write a code that makes the layout and connects widgets... The hard part was to write the actions that should be done behind the widgets. Today when I write production code I think about users who are going to maintain it. And readability and clearness is very big concern. See: http://developer.qt.nokia.com/wiki/API_Design_Principles There are 6 primary points: * Be minimal * Be complete * Have clear and simple semantics * Be intuitive * Be easy to memorize * Lead to readable code Especially this one: An API is intuitive if a semi-experienced user gets away without reading the documentation, and if a programmer who doesn’t know the API can understand code written using it. IMHO The proposed API does not helps with all this and makes things very obscure for a programmer that is not fully familiar with the toolkit. If I show this code to average C++ programmer the vast majority of them would not know what happens there... The fact that you and 1 percentile of C++ programmers (that write Boost Libraries) understand the proposed code does not mean it is understandable to other. Consider: This > auto gui_definition = > Window(title="Hello, world!") << > VBox(expand=true) << > HBox(expand=true) << > Label(text="Name:") && Entry[SLOT(onEntryChanged)]) > << End(HBox); > << Button(text="hello")[SLOT(onButtonClick)]; > << End(VBox) > << End(Window); Or this? class MyWindow : public Window { MyWindow { setTitle(tr("Hello, World!")); base_layout = new VBoxLayout(); setLayout(base_layout); base_layout->sizePolicy(Expand); top_layout = new HBoxLayout(); base_layout->addItem(top_layout); top_layout->sizePolicy(Expand); top_layout->addWdiget(new Label(tr("Name:"))); text = new TextEdit(); top_layour->addWidget(text); button = new PushBotton(tr("Hello")); layout->addWidget(button); connect(text,SIGNAL(valueChanged()),this,SLOT(onEntryChanged()); connect(button,SIGNAL(pressed()),this,SLOT(onButtonClick()); } void onEntryChanged() { std::cout <<text->getText() << std::endl; } void onButtonClick() { std::cout << "Button Pressed" << std::endl; } } The second is more verbose but it is much readable, clear, intuitive code for an average C++ programmer. My $0.02 Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

5 4