- Boost - lists.boost.org

[SoC] BGL project idea
by Gautam Sewani 03 Jan '11

03 Jan '11

Hi, I am a Computer Science student hoping to contribute to Boost for this year's summer of code. I had a few questions regarding the BGL project idea (https://svn.boost.org/trac/boost/wiki/SoC2010#Boost.Graph) for SOC 2010. 1. I can think of only a few places where the suggested algorithms will be used. Does the community think that these algorithms are used frequently enough to put them in a library? How important does the community consider this project? 2. Will the project proposal be expected to include the API design? Thanks and Regards Gautam

5 29

[BGL] Get properties from an out_edge_iterator efficiently
by Shaun Jackman 03 Jan '11

03 Jan '11

Hi, I have a graph implementation where get(tag, graph, out_edge_iterator) is much more efficient than get(tag, graph, edge_descriptor) which is probably not an usual case. Would it make sense for BGL to provide a default implementation of the former that dereferences the iterator and calls the latter? Graphs for which the former is more efficient could then specialize this function template. Cheers, Shaun

2 3

IDL to C++0x mapping
by Johnny Willemsen 03 Jan '11

03 Jan '11

Hi all, Last summer I asked some questions about a possible IDL to C++0x mapping. The OMG now has issues a RFP (request for proposal) for a new IDL to C++0x mapping. This RFP solicits proposals for a totally new mapping for IDL to C++0x. It is not a solicitation to modify the existing IDL to C++ mapping. The existing mapping is kept intact and unmodified. I am searching for some people that have some background in CORBA and that are willing to give me ideas, prototype some code, give feedback, on the creation of this new IDL to C++0x mapping. If you are interested to assist, contact me directly. The RFP is publicly available at http://www.omg.org/rfp-rfi/cvl.htm The RFP work in progress page is available for OMG members at http://www.omg.org/techprocess/meetings/schedule/IDL_to_C++0x_Language_Mapp… Regards, Johnny Willemsen Remedy IT http://www.theaceorb.nl http://nl.linkedin.com/in/johnnywillemsen

1 0

Re: [boost] [msm] triggering of a transition on a subclass event does not work on sub state machines in case of favor_compile_time policy is used.
by Christophe Henry 02 Jan '11

02 Jan '11

> Hi All > > I have run it to a problem that feature : Event Hierarchy see doc : > http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/ch03s02.html#d0e1108 > > Does not work in case of sub state machine with favor_compile_time > policy. No trans get called on the sub state machine even it has a row > with event type to the event base class. > > This now hit me badly because compiler runs out of heap if > favor_compile_time policy is not used but when it is used I can not > dispatch based on base type and I have about 150 different event so > declare a transition for it is a no go. > > Is there any workaround for this problem ?. Hi Richard, This is a documented limitation of the favor_compile_time policy. See: http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/ch03s05.html#d0e2360. As written there, The current solution can only any_cast to the exact type. And no, at the moment, I unfortunately have no solution. I'll see if I can imagine a workaround. Regards, Christophe

1 0

Re: [boost] [MSM] constructor arguments for sub state/machines
by Christophe Henry 02 Jan '11

02 Jan '11

Hi Richard, > I have tried out the new feature of msm : using constructor arguments > for substate/machines : > namely : > > player p( back::states_ << Playing(back::states_ << Song1(some_Song1_data)) , > boost::ref(data),3); > > > see doc : http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/ch03s05.html#d0e2320 > > I have some problem with it :(. > > this case state Playing and Song1 will be constructed first with > default constructor in back end constructor than the internally > constructed Playing and Song1 will be assigned to the newly construed > Playing / Song1 copy which got copied by value. Copied by reference actually (unless I have a bug) and then assigned. > The only reason to use this feature is to able to use reference > members in the substates Actually not, I must have explained incorrectly because I see it purely as syntactic sugar as a replacement for most uses of fsm.get_state<Song1&>() or worse fsm.get_state<Playing&>().get_state<Song1&>(). > but for that reference members must be > initialised in the member initialisation list of the constructor of > the substates in order to provide the references constructor arguments > must be used. Ok you'll have to use pointers. > Since subsates must provide default constructors it is not possible to > always initialise reference members from outside. > Furthermore substate must be copyable and must implement assignment > which brings more harm than good :(. > > Is there a way to resolve these problems ? This seems to me at least slightly exagerated. Assignable is a requirement for types inside a STL container and the STL clearly brings more good than harm ;-) Joking aside, there is no easy solution. To avoid assignment we will need move semantics. I'm waiting for Boost.Move to be officially part of boost to support this. OTOH the solution hardly qualifies as simplier than an assignment operator, only faster. For the default constructor, the situation is not better. I'm using a fusion::set to hold the states and the doc doesn't mention the possibility to copy-construct a set from a smaller one (in our case). I tried it and it doesn't work. So for the moment, it seems I'll have to live with the current solution (default-construct the set, then assign the provided states) and you might have to resort to pointers. In any case, a solution will at least include copy/move-construction. I actually think there might be a way to patch fusion to avoid default-construction, but I have little wish to try this at the moment. I have limited development time (my nights) and it seems to me like a poor usage of this limited resource seeing the amount of features I still want to add into MSM (there will be a whole pack for the 1.46 and I have more in my plan). However, I am working by iterating so I will probably come back to it at a later time. > PS: > Looking to the test: > http://svn.boost.org/svn/boost/trunk/libs/msm/test/Constructor.cpp > > I think there is a bug : at with line : fsm.context_ = 20; Probably. It should be fsm.context_.bla = 20; Thanks, Christophe

1 0

[thread] boost::this_thread::sleep broken?
by Jamie Allsop 02 Jan '11

02 Jan '11

From the docs I'd expect to be able to write this: std::cout << "Time Before Sleep: " << boost::posix_time::microsec_clock::local_time() << std::endl; boost::this_thread::sleep( boost::posix_time::seconds(10) ); std::cout << "Time After Sleep : " << boost::posix_time::microsec_clock::local_time() << std::endl; and have the 'this' thread sleep for approximately 10 seconds. Instead sleep returns instantaneously: Time Before Sleep: 2010-Dec-25 01:38:50.949160000 Time After Sleep : 2010-Dec-25 01:38:50.949436000 I've tried this with boost 1.45 and boost 1.43 using gcc 4.4 on debian x86_64. Am I missing something obvious? Jamie

2 2

Respecting a projects toolchain decisions (was Re: [context] new version - support for Win64)
by Lars Viklund 02 Jan '11

02 Jan '11

>>> On Fri, Dec 17, 2010 at 9:34 PM, Lars Viklund<zao(a)acc.umu.se> wrote: >>>> Maybe you can adapt to the conventions of the real world, or use >>>> git-svn? >> On Fri, Dec 17, 2010 at 22:19, Dean Michael Berris >> <mikhailberis(a)gmail.com> wrote: >>> Which real world are you talking about, the one that I live in where >>> nobody uses SVN anymore and instead use Git for large open source >>> development projects? :) >Am 18.12.2010 09:47, schrieb Scott McMurray: >> Probably the "large commercial software company" world where the >> source control is so bad that branches get merged once every two weeks >> at best, and all checkins are blocked for over 24 hours when they do, >> so multiple releases get worked on in the same branch just to avoid >> the merging headaches. On Sat, Dec 18, 2010 at 03:46:30PM +0100, Oliver Kowalke wrote: >I think we should stop this talk - if desired you can start a new thread >with this topic. I apologise if the term "real world" was misunderstood, but I'm rather tired of when people come in from the outside, implying or demanding that a project should change their version control, build system or favourite bikeshed colour, just because they are used to something else (possibly "better") from elsewhere. As for version control, what does it matter if Boost uses Subversion, when you as a DVCS user can trivially use git-svn [1] to interop against the repository (in this case, the sandbox). You get to use your favourite toy, without affecting the existing infrastructure in any way. In the end, the version control you choose is rather tangential. As long as it's sufficiently competent (which Subversion in my eyes is), you'll survive. Of course, you may propose constructive criticism and suggest migration plans to other toolchains, with good arguments for why this is a good thing. See the mythical 'Ryppl' project, which aims to componentise Boost into a pile of Git repositories and some magical combination of scripts and CMake, aimed at letting you track exactly the versions of components you need. Remember that no tool is isolated. Changing from Subversion to <whatever> would result in many changes propagating to how test runners are set up, rewriting of commit hooks, modifying Trac (if possible) (although the SVN functionality is disabled there for now), requiring adaptation of any entity out there that use Boost's repositories in any way, including externals, build scripts, CI environments, etc. And of course, having to have the mirrored Subversion repositories up for years, as you can't really 'flag day' such things. -- Lars Viklund | zao(a)acc.umu.se

28 102

[netlib] Preparing for 0.9 and 0.8.1 Release, Help Wanted; Readying for Boost Submission
by Dean Michael Berris 01 Jan '11

01 Jan '11

Hi Guys! (Apologies in advance for the cross-post) I've just pushed the master, 0.8-devel, and 0.9-devel branch onto the cpp-netlib repository -- please take the time to test all these branches as I work on getting the documentation up to speed on the 0.9-devel branch preparing for the release and submission for review on the Boost developers mailing list. I'm also welcoming contributions in the form of: * Website help, the current documentation look is OK, but if you have time to fix up some of the issues like the fonts, adding anchors and maybe reformatting the API pages so that it's easier indexed, that would be *sweet*. Also, we need a landing page on cpp-netlib.github.com which introduces the library, hosts stats, and maybe has other goodies that are specifically for a website and not necessarily for documentation. * Documentation -- please, if you have example use cases that you want to contribute, now is the time to contribute them. If you have real world use cases where you're actually using cpp-netlib, now would be a good time to have your use case highlighted in the documentation. * More string implementations -- currently I need help with supporting Qt strings, MS CString, and wide strings in the implementation of the HTTP Clients. Those who are using wide strings and unicode strings natively and who have more experience with them (I only ever deal with the "C" locale) would be most welcome to contribute to getting the HTTP client to either do conversions or natively support different string implementations. I can help with the integration part by introducing the extension points that may not be obvious from the design (as it is still largely undocumented). * Examples -- the current set of examples are a little trivial, and if you have some interesting examples you want to build on (or would like to implement some of the examples highlighted here: https://github.com/cpp-netlib/cpp-netlib/issues/labels/Examples) your contribution would be most welcome. There are some things that I've pushed out for later releases, as I would like to concentrate at the moment to making the HTTP implementations more robust and support a wider range of use-cases. I'm looking for people with experience with ESMTP 1.0 who would like to contribute to implementing a simple client implementation that we can build along the same design as the HTTP client implementation. There's already a MIME parser/generator library in cpp-netlib thanks to Marshall Clow (which he presented in BoostCon 2010) also being developed for inclusion into Boost -- hopefully we can get that baked into the ESMTP client implementation early on to make it more immediately useful. At any rate, please expect a slightly delayed release of 0.9 which would be the first release which defaults to non-header-only, while 0.8.1 will be the first patch update version for 0.8. Appropriate changelogs to follow as soon as the releases are ready. In the meantime, please feel free to test out the code already in GitHub: http://github.com/cpp-netlib/cpp-netlib/ -- the stabilization effort for 0.9 and 0.8.1 will happen on this repository. Feedback would be most appreciated. Thanks everyone! -- Dean Michael Berris about.me/deanberris

1 0

[Review][Ratio] Boost.Ratio has been ACCEPTED
by Anthony Williams 01 Jan '11

01 Jan '11

Hi, I am pleased to announce that Boost.Ratio has been ACCEPTED into Boost. There were not as many reviews for Boost.Ratio as for some libraries, but they were overwhelmingly positive. Boost.Ratio is an important building block for other upcoming submissions, and provides an implementation of the C++0x rational arithmetic facilities. A few changes were requested by the reviewers, which I will list below. I know that Vicente has already started working on some of these. These changes should be addressed before the library appears in a Boost release. * Some of the macros had names with RATIO_RATIO in. These should be changed to just RATIO * The ratio_add, ratio_sub, ratio_multiply and ratio_divide templates should derive from the resulting ratio type as well as providing the nested ::type member, in order to closely emulate the template alias facility from C++0x * The typos in the documentation should be fixed, and the documentation reviewed for correctness and clarity (though several of the reviewers made positive comments on the quality of the documentation). * The library needs more tests under the Boost Software License. * All references to names from the boost namespace should be qualified with boost:: to avoid potential name clashes and ambiguity with names from the global namespace. * Sections commented out with #if 0 should be removed * The extensions beyond the facilities required by the C++0x draft should be able to be enabled or disabled through use of a configuration macro. * References to the tests, examples and documentation from within the code should be checked for correctness. I would like to thank Vicente for submitting the library and those that took the time to write a review. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

2 2

[fiber] new version
by Oliver Kowalke 01 Jan '11

01 Jan '11

boost.fiber has been refactored - most of the code has moved to another lib. The new version allows directly to run and yield the fiber. class jumpable is an example how a fiber can be used.

2 3