- Boost - lists.boost.org

Features list for v1.34
by Balasubramanyam, Shivakumar 16 Mar '08

16 Mar '08

Hi, Could someone point me to a link that provides features added or major bugs fixed for a major boost release. Currently we are using 1.32 and I would like to know if we need to upgrade to 1.34 releases. I tried in the boost.org but could not find a link. Thanks, Shiva

3 2

Attention: all authors of new libraries for 1.35.
by John Maddock 16 Mar '08

16 Mar '08

Could you please check that the descriptions here: http://beta.boost.org/users/news/version_1_35_0 are correct. If you would like to expand on the descriptions given then now is the time to do so! Thanks, John.

4 5

Review Request: Dataflow.Signals
by Stjepan Rajko 16 Mar '08

16 Mar '08

Hello, I would like to request a formal review of the Dataflow.Signals layer of the Dataflow library. The Dataflow.Signals layer provides dataflow functionality based on function calls (using Boost.Signals), and is a result of the Signal Networks GSoC project from 2007. (The other layers of the Dataflow library are not quite ready, so for now I'd like to keep them as implementation details and/or examples of the Dataflow.Signals layer, and submit them for review at a later point.) The documentation for the Dataflow library is located at: http://dancinghacker.com/code/dataflow/ Version 0.9.0 has been uploaded to the vault, in the Dataflow directory. There are a few more things I plan to add before the library comes up for review, especially regarding the documentation and motivating examples. Description: The Dataflow library is a generic library for dataflow programming. Dataflow programs can typically be expressed as a graph in which vertices represent components that process data, and edges represent the flow of data between the components. As such, dataflow programs can be easily reconfigured by changing the components and/or the connections. The Dataflow.Signals layer provides dataflow functionality based on function calls - which is one of the fundamental ways of dataflow in C++. For its data transport mechanism, Dataflow.Signals uses Boost.Signals which can be used to make lasting dataflow connections based on function calls. Dataflow.Signals provides the following to facilitate signals-based dataflow networks: * A number of useful general-purpose components, and building blocks for implementing new components. * Various free functions and operators for connecting and using components. Kind regards, Stjepan

5 20

[fusion] Instantiating elements of nested sequences
by Carlos Rafael Giani 16 Mar '08

16 Mar '08

Hi, I want to store boost signals in fusion sequences. This does not work directly, since signals are noncopyable. I figured I could use shared_ptr's of the signals, and all that needs to be done is to iterate through the sequences, instantiate objects, and assign them to the shared_ptr's. These are the structures for the signals: template < typename Element > struct element_signals { typedef boost::signal < void(model const &, Element const &) > event_signal_t; typedef boost::signal < void(model const &, Element const &, std::vector < std::string > const &) > modified_signal_t; typedef boost::fusion::vector < std::tr1::shared_ptr < event_signal_t >, // add std::tr1::shared_ptr < event_signal_t >, // remove std::tr1::shared_ptr < modified_signal_t > // modified > signals_t; typedef boost::fusion::pair < Element, signals_t > signals_pair_t; }; typedef boost::fusion::map < element_signals < vertex_iterator > ::signals_pair_t, element_signals < edge_iterator > ::signals_pair_t > signals_t; Now, I am trying to do something like this pseudo-code: signals_t signals; for_each(signals, for_each(_1, _1 = typeof(_1)(new typeof(_1)::element_type) ) ); Problems: 1) How do I get the type of the current element in the for_each loop without resorting to functors? 2) I tried to use a MPL placeholder for the _1 in the outer for_each loop, but it didn't seem to work. Does Fusion have its own placeholders, or what am I missing? Regards,

1 0

[1.35][GIL] No copyright/license on docs?
by John Maddock 16 Mar '08

16 Mar '08

Currently the biggest single group of failures in the inspection report comes from GIL: http://mysite.verizon.net/beman/inspect.html#gil Is there any easy way we can regenerate this documentation with an appropriate license declaration? John.

2 1

[proto] comments on documentation #2
by Markus Werle 15 Mar '08

15 Mar '08

Hi! <anecdote> This morning (6:45 CET) I was sitting at the breakfast table and was reading the printed PDF of proto docs. My little son (6 years old) entered the scene and the first question he asked was: "What kind of puzzle are you trying to solve?". Kids always have a keen sense of what's really going on ... </anecdote> Before I start nagging, I should say that a large subset of the docs are well-done, near perfect. The setup of the first chapters makes it easy to approach proto. But I got lost in the middle with transforms and that is a BadThing (TM), because those are the beasts everybody needs in order to get the maximum out of proto. The transform chapter leaves me with the same feeling I had 1998, 2 weeks after my decision to learn C++, when I was reading Stroustrup's TCPPL chapter about templates. I wish Vandevoorde/Josuttis would have written their book _before_ I had to use templates (and gcc). Same here: I beg for some step-by-step-by-example introduction right now. Nothing of this part of the docs reached my heart and mind. Without tiny little examples I am totally lost here. This serves well as reference documentation, but not as main entry point to a feature of a library. I will try to work through the examples now, but any introductory material appreciated here. Keep me informed about updates in that section, please. Minor issues: First of all: Expression Extensions can go a long way without transforms. So I would recommend to put this chapter in front of the one about transforms. Then introduce transforms later for those with the sword of metaprogramming knowledge and the will to survive. extends<> is useful even without transforms and so why not give it a chance before readers are drawn away by the more advanced, but horrible-to-catch features. Also it might make sense to show an example which uses std::algorithms like the original std::transform example in order to show the power of proto here. AFAICS _make_terminal drops in from heaven without introduction - right? Do we need that one? is terminal<>::type not equivalent? if yes, remove _make_terminal. ------------------------------------- The decltype stuff distracts from the key points. Unaware readers get into panik when seeing static references to types and a keyword yet not in C++. How about typedef ...implementation defined ... result_type; Then move the decltype stuff to the comment paragraph below the code as extra information. Also: why ::result_type and not ::type? Is this consistent with mpl? ----------- Could you provide a full (compilable) example for increment_ints? That would help education (though I feel like I got that one) Maybe even extend the example to an initialization action based on operator new ... ----------- sed -es,no temporaries!,no temporary vectors!,g Maybe state that there are no temporary vectors, but of course the integer 2 in stored as temporary in [2]. Also state that every modern compiler since intel's 8.1 is capable of optimizing that one away, so nobody should care, and then: Look ma! no template code on-board after optimization -> the abstraction penalty is zero! ----------------------------------------------------------- Now it is time to share some time with the kids. Read you later in this group ... Markus

2 4

[1.35][ASIO] Broken index.html
by John Maddock 15 Mar '08

15 Mar '08

The links to the ASIO docs from the main documentation index page is broken, likewise the forwarding HTML file in libs/asio also forwards to a non-existent file. So.... where have the docs moved to... or were they not committed? Thanks, John.

5 6

[proto] comments on documentation #1
by Markus Werle 15 Mar '08

15 Mar '08

Hi! This is a proposal for extra text which might have helped me to catch some things right from the beginning: Section "Accessing Children Nodes": Subsection "Expression Nodes as fusion sequnces" After "... arguments in order" please insert an improved version of the following paragraph (intended for first-contact-to-proto people like me) --- Note that in C++ operators are nothing else but special syntax for operations that can be written as function calls, e.g. a+b is equivalent to binary_plus(a, b). Proto "thinks" of operators in this way and - as introduced above - uses a type representation of the form expr<tag::binary_plus, typeA, typeB> This is why function calls are nothing special to proto and and are handled in analogy to operators: For function calls the type representation has a tag tag::function and the type of function is stored as extra template argument, so you obtain type representations of the form expr<tag::function, typeFunction, typeA, typeB> for a function call Function(A, B). So if a compile time algorithm in proto needs only access to the types of the arguments and not to the type of the function, the first argument has to be removed from the sequence. We will come back to this in a second: [Then show the example and then in the explanation add:] What happens during compilation with "fun(1, 2, 3, 4)"? The type of fun is in namespace proto, so it is "tainted" with Proto-ness exactly like _1 in the examples above. Similar to _1 + 2, which has a return type of expr<tag::binary_plus, ....> ;-) \footnote{Once in a time binary operator+ was tagged tag::plus, which led to trouble for the tag name of unary operator+. A lot of crazy proposals for the tag name were made, now we simply use tag::binary_plus and tag::unary_plus, no further discussions needed} ;-) the call fun(...) has a return type of expr<tag::function, PUT_SOME_CODE_HERE, ....> The integers are automatically wrapped in terminal<int>s. That's why proto is so cool. Since we are only interested in the arguments of the function call and already know that expression nodes are valid Fusion sequences and know that the first element in the fusion sequence is the function type, namely terminal<fun_t>::type alias expr<tag::terminal, bla bla>, we use a compile time algorithm which drops the first element from the list before pushing the result through other very useful algorithms of boost::fusion - in this example for_each and transform (Did we already mention that you are lost with proto if you do not know fusion?) ----------------------------- Markus

2 1

[proto] docs: Calc2 improvement proposal
by Markus Werle 15 Mar '08

15 Mar '08

Hi! First of all: This is a very nice example. Fantastic idea to introduce index information stored in the terminals at this place in the docs - perfect. If you define arg as template<int I> struct arg {}; and change the code accordingly the reader is not in need to know anything about mpl::int_ and IMHO the code template <int I> double operator ()(proto::tag::terminal, arg<I>) const { return d[ I - 1 ]; } is easier to read than template<typename I> double operator ()(proto::tag::terminal, arg<I>) const { return d[ I() - 1 ]; } Note that this should be written for beginners like me, so one catches the idea immediately without taking the extra path to mpl here. Markus

2 1

[filesystem] wpath_traits missing BOOST_FILESYSTEM_DECL
by Alexei Alexandrov 15 Mar '08

15 Mar '08

Hi, In Boost 1.34.1 the wpath_traits class misses BOOST_FILESYSTEM_DECL declaration and thus cannot be used with boost::filesystem is dynamically linked on Windows. Is this a bug or it's me who misses something? -- Alexei Alexandrov

1 0