- Boost - lists.boost.org

[Report] 0 regressions on RC_1_34_0 (2007-06-18)
by Douglas Gregor 18 Jun '07

18 Jun '07

Boost Regression test failures Report time: 2007-06-18T04:07:26Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… No failures! Yay!

1 0

Resolution of operator decision. [Was "Progress of Boost.SVG_Plot"]
by Jake Voytko 18 Jun '07

18 Jun '07

All, After a lengthy discussion on the pros/cons of the operator<<() overloading, this has become a sore spot for a lot of people. My vision for this library is, above all, for people to use it and enjoy using it. That being said, I converted the library to using .set___() methods that allow chaining, which I feel is a good compromise. Some contributors were against even this, but you can't please all the people all the time. If you want to see how the new syntax looks, there is an example on the project wiki: http://svn.boost.org/trac/boost/wiki/soc/2007/VisualizationOfContainers Or if you want to see how the output of the project progressed in a week (major architectural changes nonwithstanding), please see this page (now with IE7 w/ plugin support): http://www.tcnj.edu/~voytko2/svg.htm I'd like to thank everybody who took the time to make suggestions/contributions. I'd rather issues come up now than during a review :) Jake

2 2

Tracking Review Requests and RM Applications
by João Abecasis 18 Jun '07

18 Jun '07

Hi! For those who missed it, I suggested on the "Languishing review requests" thread that we keep track of Review Requests and Applications for Review Managers in the ticketing system. The goal being to avoid the "silent rejection" problem. A bonus side-effect is that each proposed library gets a unique place where it's progress along the Boost process can be tracked. Comments on library review requests would include links to relevant discussion on the list and rationale for decisions made. Each ticket would be closed upon final acceptance and merging of the code in the trunk, or rejection of the library. Below I offer some suggestions on how this could work, just to get the discussion rolling. * Ticket Type: we could use one or two more ticket types: (Library) Review Requests and a Review Manager Application. Perhaps a single generic "Review Request" would work just as well, to begin with. We could also reuse one of the existing ticket types (e.g. Tasks?), but I think a clearer separation would work better. * Reporter: The person submitting the review request or RM application * Status: Assigned would be used when a Review Manager has been assigned. He is responsible for "closing" the review ticket. * Owner: per above, this would be the Review Manager for a library submission and the Review Wizard for other types of requests. * Milestone: Perhaps a bit far-fetched, but this could be used to follow the library library submission process (http://boost.org/more/submission_process.htm) This allows one to check at a glance libraries in each stage. It could also clutter the Roadmap page. None of these Milestone Steps would advance: tickets would progress from one to another. * Version: Version of Boost with which the library was tested? Version for inclusion after acceptance? * Component: "Boost Process" And if you've got this far... Do you think this is a good idea in general? Do you think something like this adds more "process" with no or little gain? Is it any friendlier to potential submitters? How about potential review managers? ... All comments welcome. Best regards, João

4 4

[graph] managed vertex indexing
by Andrew Sutton 18 Jun '07

18 Jun '07

All Interested, For my Summer of Code proposal, I have been working on the usability of the Boost.Graph library, basically adding a couple wrappers to make it easier to work with undirected and directed graphs. One aspect of these classes is that they do not use the typical vector storage for vertices, edges, or the out edge list. In this case, list storage provides more iterator and descriptor stability so we (mentor Jeremy Siek and myself) decided go that direction. This decision has some interesting fallout since almost every example for Boost.Graph, including that in the documentation is written using vecS for most of the storage facilities. This lead some interesting discoveries like, for example, that num_vertices(g) is O(n) with listS vertex storage under GCC - who knew?. also that most graphs declared using `listS` will fail to run correctly with default parameters on just about every algorithm. And finally, that most of the examples given in the documentation and libs directory will also fail if you stick this line of code just before a call to any core algorithm: remove_vertex(*vertices(g).first, g); Except for the linear time num_vertices(g) call, these problems are caused by indiscriminate use of vertex descriptors as indices - in fact, that's exactly the reason that the above line of code will cause most examples to fail. I've written down a solution to this and added it to the documentation I've been working for my project. It essentially involves three functions that can be used to help manage vertex indices. Essentially they are: get_vertex_index(v, g) max_vertex_index(g) renumber_vertex_indidces(g) Correct use of these functions will solve a number of problems. The more complete proposal is in subversion at: http://svn.boost.org/trac/boost/browser/sandbox/SOC/2007/graphs/libs/ graph/doc/quickbook/indexing.qbk Part the related implementation is here: http://svn.boost.org/trac/boost/browser/sandbox/SOC/2007/graphs/boost/ graph/undirected_graph.hpp The three functions in question are the last in the file, although they do call some member functions of the graph class itself. I'd be grateful to some suggestions for improvement or other comments. Andrew Sutton asutton(a)cs.kent.edu

2 2

Re: [boost] Request for consideration for my weak_ptr class
by me22 18 Jun '07

18 Jun '07

On 08/06/07, Alex Burton <alexibu(a)mac.com> wrote: > I understand there would be a collision with boost::weak_ptr, which is used for special scenarios with shared_ptr as I understand. > weak_ptr is essential for breaking cyclic references. > A fair comment would be that this class actually does nothing, that a normal pointer would do and this is true. > raw_ptr might be a better name, then. It's less than weak, since weak pointers are actually quite intelligent, knowing whether or not they're dangling. > It allows my code to be free of the * pointer notation. > All pointers look the same, ie shared_ptr<Foo>, scoped_ptr<Foo>, weak_ptr<Foo> > Those smart pointers are all well-behaved, though. raw pointers are not. > It can be used in many places a reference would be used. > You can't get the address of temporaries, so I don't understand where you'd use it in place of references... > In the above code, if vector<Foo> foos was changed to vector< shared_ptr<Foo> > the code will still work perfectly with out change. > > I find this really useful because often small structs become polymorphic classes (requiring shared_ptr) as code evolves. > > The vector example is the best, but even when returning a pointer to something like this it is good: > > if Bar mBar becomes scoped_ptr<Bar> mBar, the accessor still compiles. > For your vector example, have you considered starting with vector<Foo>, then changing to ptr_vector<IFoo> later? I think that'll get you the same effect, but it's much safer. That constructor from a reference also looks like it'd be far too easy to mistakenly return a pointer to a local variable. I'm not convinced that your method is much superior to returning a reference and, if the member does become a pointer, just adding the * to dereference it in the accessor. Probably not quite following just yet, ~ Scott

1 0

Re: [boost] Tracking Review Requests and RM Applications
by Tom Brinkman 17 Jun '07

17 Jun '07

>> Once I start the pages I'll be sure to explicitly mention that >> this is not yet the approved submission process, but still a work in >> progress. All the ideas I posted were meant to get the discussion >> started so I'm not attached to them in any way. While we're defining >> this, all can be changed. In the end, I'd like the process itself to be >> as streamlined as possible for everyone involved. We're all here for the >> code... ehm... and the docs, of course ;-) All sounds good to me. I'm shur your on to something with these ideas. Thats the way to get agreement around here, you've got to get something up and going, at least a prototype, so people can see and evaluate it. Integrating the review process with the svn tracking makes more sense to me every time I think about it.

1 0

[Fusion] Notice of breaking change
by dan marsden 17 Jun '07

17 Jun '07

The definition of Fusion polymorphic function object will be changed shortly to be consistent with boost.resultof. Instead of requiring a nested result metafunction of the form: template<typename T0, typename T1, ... typename TN> struct result { typedef xxx type; }; A polymorphic function object will instead simply be required to suppport boost::result_of<F(A,B,...Z)>::type as a valid expression. This will break some Fusion client code, specifically, if you are using fold, accumulate, transform, or a lot of the components in the functional section of the library, you may need to make changes to support this change. The change should be entered into CVS head over the forthcoming weekend. Apologies to anyone whos code this breaks, but this should make things more consistent with the rest of boost going forwards. Cheers Dan ___________________________________________________________ Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.ht…

2 2

a new release of "Join" asynchronous concurrency library
by Yigong Liu 17 Jun '07

17 Jun '07

Hello fellow boosters, I just uploaded to boost vault (under "concurrent programming") a new release of "Join" asynchronous concurrency library with changes based on initial feedback from the list. For people who are not familiar with "Join", a short description is as following: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. The major changes from last release are code related to chord_override and chord_remove. Also two tutorials are added to explore the usage of Join: 1> implementing thread safe event dispatching using Join and 2> implementing data parallel algorithms (parallel loop and map-reduce) using Join, which is helpful for programming today's multi-core machines. More info can be found: Source code: http://sourceforge.net/project/showfiles.php?group_id=157583 Documentation: http://channel.sourceforge.net/boost_join/libs/join/doc/boost_join_design.h… Website: http://channel.sourceforge.net I need some advice with a specific implementation question with Join. The semantics of async / synch methods and actor base classes require them to be noncopyable and nonassignable, since they contain state info about on-going messaging. Normally letting them inherit from boost::noncopyable can solve it. However one important feature of Boost.Join is to allow applications to create a vector of async / synch methods which will be prohibited by noncopyable. Any suggestions? Thanks Yigong

5 17

[1.33.1][thread] bug with attached_thread_count assertion on Ctrl+Break on windows?
by Valentin Samko 17 Jun '07

17 Jun '07

I noticed that if I use boost::thread_specific_ptr (thread local storage) and terminate my console application (on windows) with Ctrl+Break, I always get a message box and assertion error from the boost thread library: Assertion failed: attached_thread_count == 0, file .......\msvc71\libs\thread\build\..\src\tss_hooks.cpp, line 131 Is this a known problem and are there any fixes? The test case is #include <boost/thread/tss.hpp> #include <iostream> #include <windows.h> int main() { boost::thread_specific_ptr<int> tl_int; tl_int.reset(new int); std::cout << "Sleeping for 10 seconds ..." << std::endl ; ::Sleep(10000); std::cout << "Woke up" << std::endl ; } compiled with /DBOOST_THREAD_USE_DLL . If you press Ctrl+Break while it's sleeping you get that assertion. Valentin

1 0

Re: [boost] [rfc] I/O Library Design
by Sebastian Redl 17 Jun '07

17 Jun '07

Cédric Venet wrote: > Seems iteresting. > Thank you, and thank you for the comments. > There is a small problem on this line (main page): > Noteworthy readers/writers are StringReader/Writer, *for in-memory I/O*, and > InputStreamReader and OutputStreamWriter, which wrap binary streams and do > on-the-fly character conversion. > > The for in-memory I/O seems to be a copy paste error. > Not really. StringReader is passed a java.lang.String at construction and offers the text therein as the data to be read. StringWriter accumulates everything written to it in a StringBuffer (StringBuilder in 1.5? No idea.), so that the accumulated string can then be accessed. > Others than this, I don't have much to says. Just a word on formatting: we > need a better way than iostream for specifying formatting option. When I > need to print number, I often go back to printf. The actual system is to > clumsy. > I agree. > Regards, // I am supposed to put this on the bottom of a mail? > // seems like some do other put Best regards (and others nothings) > // I suppose it is the equivalent of 'Cordialement' in French > My French is extremely limited, but yes, it seems to be something like that. Of course, I rarely close my mails to mailing lists in this way. Sebastian Redl

1 0