June 2010 - Boost - lists.boost.org

boost log: attributes and different loggers
by Dirk Griffioen 11 Jun '10

11 Jun '10

Hi, I am trying to use 2 loggers - 1 severity logger - 1 'normal' logger However, when I add sink->set_filter(flt::attr< severity_level >("Severity") >= level); to the severity logger sink and try to use the second logger I get: terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::log_mt_posix::missing_value> >' what(): Requested attribute value not found The second logger has no formatter: backend->set_formatter(fmt::stream << fmt::message()); Nor has it any attribute. I tried different solutions, but nothing works - what am I missing? Best, Dirk

2 2

boost::asio 1.43 regression (canceling read operation doens't trigger operation_aborted)
by Philippe Vaucher 11 Jun '10

11 Jun '10

Hello, I had working 1.42 code that suddenly stopped working with 1.43. With a bit of investigation I found out that canceling an async_read operation on a serial port when a timer was fired didn't trigger the expected boost::asio::error::operation_aborted like it used to do. Here is a testcase: http://codepad.org/XnLwybDl The idea is to implement a "read with timeout" functionality on a serial port. Btw, is this the correct way to implement this? Is there a simpler way to read from a serial port with a timeout? Thanks, Philippe

2 5

Re: [boost] MSM - 1.44 release
by Christophe Henry 10 Jun '10

10 Jun '10

>> Before the deadline, you'll need to merge your code to the release branch at >> <https://svn.boost.org/svn/boost/branches/release/>. > > Can you wait until we give you the go ahead. If we're slow then that's > our fault, so we're not going to stop you releasing. We need to check > the documentation, inspect report, test results etc. Yes, of course. The library is ready anyway so I can merge fast. If it could happen during the WE, it would be really great. Christophe

1 0

Re: [boost] MSM - 1.44 release
by Christophe Henry 10 Jun '10

10 Jun '10

>>Christophe Henry wrote: >> *Component has been added to Trac >> Not done. How to do? > > > I've done this. > > -- Marshall Thanks a lot Marshall! > Rene Riveira wrote: > You could do it, or you could post what you want in the release > announcement and Daniel will likely do it (or I will eventually). The > file to edit is > <https://svn.boost.org/svn/boost/website/public_html/beta/feed/history/boost…>. Done. It would be nice if you could check I did it ok. > Usually Daniel, or me eventually :-) Again, just post what you want. Or > if you are brave edit the database file yourself > <https://svn.boost.org/svn/boost/website/public_html/beta/doc/libraries.xml>. Done. >> *Component has been added to Trac >> Not done. How to do? > One of the admins will do it.. Which is often me.. Just tell me what > your trac user ID is. I suppose the same as svn: chenry Thanks, Christophe

1 0

MSM - 1.44 release
by Christophe Henry 10 Jun '10

10 Jun '10

Dear release managers, MSM is now almost ready for the 1.44 branch (hear hear, I didn't lie at the BoostCon ;-) ). I need a little help for some of the steps. The current status is: *root/index.html includes the library in its list of new libraries. Not done. How should I proceed? *root/libs/libraries.htm entry is OK, both in the alphabetic list and in the category lists. Done. *root/libs/maintainers.txt entry is OK. Done *website/public_html/beta/feed/history/ entry is OK Not done. Who does this? *The library has been added to the website documentation list Not done. Who does this? *The library's root/libs/xxx directory contains an index.html file with either the main docs or a redirection to the main docs Done *The primary docs pages meet Boost requirements and guidelines. Don't leave this until too late; it has turned up lots of issues in the past I suppose. Any comment on what I could have done wrong? *Component has been added to Trac Not done. How to do? *Trunk inspection report is clean Done (only irrelevant warnings about license in html files left) *Trunk regression tests are reasonably clean or marked up Done How do we proceed further? What do I also need to do to get MSM into the 1.44 branch? Thanks, Christophe

6 6

Bug sprint daily update for Thursday, June 10th
by Marshall Clow 10 Jun '10

10 Jun '10

As of 0800 Pacific time today, we had 854 open trac tickets. That is down by 40 from yesterday, and 135 since the start of the bug sprint! Of the 135 tickets closed, 100 were marked as "bugs". I am very impressed; keep up the great work! Total ticket counts: Saturday 989 Sunday 988 Monday 958 Tuesday 938 Wednesday 894 Thursday 854 Activity summary for yesterday (I'm counting tickets by hand here, here so blame my crummy math if it doesn't add up) New tickets: 6 Modified: 29 Closed: 49 Reopened: 3 If you're looking to help, and don't know what you can do, there are 13 outstanding "Support Requests" You can see them at <https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=re…> Today, rather than the summary totals for yesterday, I have deltas; changes in the totals. If you'ld like to see the totals, they are available online at: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 (All changes are since the start of the bug sprint; 0800 PDT Saturday June 5th) Changed totals by library: thread -35 None -17 website -10 string_algo -9 function -6 iterator -6 concept_check-5 date_time -5 multi_array -5 Getting Started Guide -4 asio -4 random -4 tuple -4 variant -4 lambda -3 units -3 Building Boost -2 foreach -2 fusion -2 mpl -2 tokenizer -2 GIL -1 Regression Testing -1 assign -1 graph -1 io -1 lexical_cast -1 mpi -1 pool -1 regex -1 signals2 -1 spirit -1 trac / subversion -1 circular_buffer 1 program_options 1 serialization 1 utility 1 Documentation 2 property_tree 2 build 4 Changed totals by author: anthonyw -34 <none> -20 dave -13 grafik -9 pavol_droba -9 dgregor -8 jsiek -6 no-maintainer -6 az_sw_dude -5 djowel -5 garcia -5 chris_kohlhoff -4 ebf -4 agurtovoy -2 dlwalker -2 eric_niebler -2 matthiasschabel -2 bschaeling -1 cnewbold -1 danieljames -1 fmhess -1 hkaiser -1 hljin -1 jefffaust -1 johnmaddock -1 nasonov -1 nesotto -1 speedsnail -1 steven_watanabe -1 cornedbee 1 danielw 1 jano_gaspar 1 jewillco 1 matias 1 ramey 1 witt 1 vladimir_prus 7 Changed totals by category: Bugs -100 Patches -16 Feature Requests -11 Tasks -4 Support Requests -2 Library Submissions -1 -- Marshall

1 0

Re: [boost] [msm] Nested submachines and explicit state entry
by Christophe Henry 10 Jun '10

10 Jun '10

>MSM Documentation (section: Explicit Entry): >--------------------------------------------- >You can then use it as target in a transition with State1 as source: >_row < State1, Event2, SubFsm2::direct< SubFsm2_::SubState2> > >The syntax deserves some explanation. SubFsm2_ is a front end. SubState2 >is a nested state, therefore the SubFsm2_::SubState2 syntax. The >containing machine (containing State1 and SubFsm2) refers to the backend >instance (SubFsm2). SubFsm2::direct states that an explicit entry is >desired. --------------------------------------------- >So I think the code snippet has to look like as follows (SubFsm2 instead >of SubFsm2_): >_row < State1, Event2, SubFsm2::direct< SubFsm2::SubState2> > Actually not but I might need to detail a bit. Consider: struct SubFsm2_ ... // front-end { struct SubState2 ... // ---> nested type }; typedef msm::back::state_machine<SubFsm2_> SubFsm2; //back-end SubFsm2_ : front-end SubFsm2: back-end SubFsm2_::SubState2 : the complete name of SubState2. Which means that : _row < State1, Event2, SubFsm2::direct< SubFsm2_::SubState2> > is correct. The back-end(SubFsm2) provides a direct entry type (SubFsm2::direct<>) taking as argument the direct entry state, which name is SubFsm2_::SubState2. Regards, Christophe

1 0

[msm] Choosing initial event in sub machines
by Christophe Henry 10 Jun '10

10 Jun '10

>>> Actually, this is exactly the behaviour what we want >> I'm not sure I get. You'd want the submachine to use its own initial >> event and receive this one instead of the containing machine's? It's >> probably possible but I'm wondering what could be a use case for this. >> Could you please elaborate? >No, sorry for the confusion. The implemented msm behaviour is the one we >want. >So there is no need for a change in the msm code ;). Good because my todo list is getting quite long ;-) >Maybe it would be good to describe it in the documentation. Will be done. Regards, Christophe

1 0

Re: [boost] [endian] endian flip and endian domain
by Dave Handley 10 Jun '10

10 Jun '10

Robert Stewart wrote: > Dave Handley wrote: > > Gottlob Frege wrote: > > > > > I think what I am saying is that, conceptually at least, the > > > endian-types come first, and the straight functions are built on top > > > of that (instead of the other way around as most are suggested). > > > Now, I wouldn't want that to impact performance, which is why I say > > > 'conceptually'. We can specialize the heck out of > > > everything so that > > > performance wins, but I think the conceptual foundation is > > > important. > > > > I disagree. If you have an endian type then I think you are > > coding in from the beginning a need for a copy in order to > > endian swap - even if the endian swap is a no-operation. > > This discussion isn't necessarily intended to account for swap in place, > which all have agreed is necessary. Rather, I at least am > thinking of this discussion as applying to the object-based approach > and to the copy-based conversion functions. The problem is with the initial statement above which says "the endian-types come first, and the straight functions are built on top of that". This is what I fundamentally disagree with. IMHO, you have to write the straight functions (in Tom's terminology, swap and swap_in_place), then implement the endian-types on top of that interface. If you do it the other way around you enforce a copy on the function based interface. At least as far as I can see. I don't disagree that many people want and might well heavily use an object-based interface. Robert Stewart wrote: > > Next, on naming, I think we should be very careful that we > > don't over-think the naming question. I'll ask a general > > question. What term does everyone use when talking about > > endian swapping? Certainly in my programming career I've > > never heard it called anything other than endian swapping. > > Also (and I know this shouldn't be taken as a definitive > > source) Wikipedia refers to the process of changing > > endianness as a byte swap. Shouldn't we use swap because > > that is what everyone knows the process of changing > > endianness as? That's my 2d, but I'm not wholly against > > another naming option. > > While I sympathize with your position, it has been noted that "swap" > is a very bad choice because of std::swap(), boost::swap(), etc. > Those functions have a distinct behavior and purpose that endianness > conversion does not satisfy. Considering that our work could be > standardized in the future, can you imagine the committee > accepting "swap" as the name? I can't. That implies the need to > find another name. I agree that the existence of std::swap() is an issue. In that context I would argue for something more like boost::endian_swap. I think changing the verb used is an obfuscation and not necessarily helpful. Dave

4 5

: Review of a safer memory management approach for C++
by Bartlett, Roscoe A 10 Jun '10

10 Jun '10

A few responses ... > 4. Re: Review of a safer memory management approach for C++ > (Mathias Gaunard) > 5. Re: Review of a safer memory management approach for C++ > (Roland Bock) > 6. Re: Review of a safer memory management approach for C++ > (Fernando Cacciola) > ------------------------------ > > Message: 4 > Date: Mon, 07 Jun 2010 18:07:55 +0100 > From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++ > Message-ID: <huj91v$cem$1(a)dough.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Bartlett, Roscoe A wrote: > > > Tools like valgrind and purify are very helpful but are not nearly > sufficient as described in Section 3.2 (and other sections) in: > > > > http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf > > The limitations you give are simply that you expect valgrind to do more > than tell you about memory errors, but also to tell you about contract > violation of any library as well. > That's not something a generic tool can do. [Bartlett, Roscoe A] Exactly my point. > Contracts are specified by > each library, and can be optionally checked in a special debug mode the > library may provide. [Bartlett, Roscoe A] Exactly. However, rather than doing this haphazardly why not have a consistent built-in approach in your own software to catch such mistakes automatically in a debug-mode build? Enter the Teuchos MM classes and the idioms described in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf > All that valgrind can do (as far as I my usage goes) is tell you if you > access some unallocated memory (relatively to the default global > allocator) or if you read an uninitialized object. [Bartlett, Roscoe A] Valgrind and purify are very useful but they will often only flag there is a problem until much after the original error occurred. As an example, a few months ago I was using std::multimap for the first time in a GCC implementation. The documentation I found for std::multimap on the web was not very detailed and did not really explain behavior in a few important cases (I have had a hard time finding decent standard C++ library documentation). I ran the code and it behaved in strange ways, segfaulted, etc. I turned on the checked STL implementation with -D_GLIBCXX_DEBUG but it did not complain about anything. I ran valgrind on it is it complained there was a problem in a place in the code that made no sense at all. I knew the only "unsafe" code that I had written (that did not exclusively use the Teuchos MM classes and idioms) was the std::multimap code. After more experimentation I figured out that I had guess the behavior of std::multimap incorrectly. Once I figured out what the behavior really was, the program ran fine. Here was a case where the checked STL implementation was not catching a basic user error and valgrind was worthless. I just wish that I would have saved the state of this code in a branch or something so that I could show this to other people. > ------------------------------ > > Message: 5 > Date: Mon, 07 Jun 2010 19:14:33 +0200 > From: Roland Bock <rbock(a)eudoxos.de> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++ > Message-ID: <4C0D28F9.1060301(a)eudoxos.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > Bartlett, Roscoe A wrote: > > Come one, at least some people on this mail list must have had > similar nightmare experiences in trying to track down and diagnose hard > memory misuse errors in C++ that took days of effort to resolve (even > with the help of tools like valgrind and purify). > > > > Hi, > > yes, I had such experiences, but that's years in the past, when I did > not know shared pointers. With shared pointers only very few memory > issues ever occurred. [Bartlett, Roscoe A] I have to admit, that w.r.t. single objects, after I started using smart reference-counted pointers, I experienced very few memory errors. However, I was still having some errors and I was writing a lot of paranoid manual error checking code with all of the raw pointers that remained (and yes, if all you have is an RCP class, you will still need to use raw pointers in many cases). After I developed Teuchos::Ptr, the raw pointers to single objects went away and I ripped out a bunch of manual error checking code (a process that I will likely never finish because of the large amount of code I have written over the years). There are people in my domain that still today will refuse to use a smart pointer class and insist on manipulating raw memory, even in brand-new code. The cycle of undefined behavior, segfault, etc. will continue ... > These days, our memory issues are of a different kind: Memory > fragmenation due to malloc's strategies in multithreading scenarios. > These are even worse, because formally, there is no problem in the > code. > Writing you own allocator and then suddenly not being able to use > valgrind anymore, that's the memory fun today. [Bartlett, Roscoe A] Do people have experience with library allocators from MPI and TBB? These are supposed to place memory more carefully but they mean that you can't use the allocator embedded in std::vector anymore. > ------------------------------ > > Message: 6 > Date: Mon, 07 Jun 2010 14:32:15 -0300 > From: Fernando Cacciola <fernando.cacciola(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++ > Message-ID: <hujad9$ic7$1(a)dough.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Bartlett, > > Just for the record and since your statements below are about general > experiences with large scale C++ projects, let me put my own > experiences in > context: I had been architecting, designing and implementing large- > scaled > projects from the early 90's. The largest of which accounts for 160K > of C++ > code, which in fact I wrote almost entirely myslef. > Again this is just to put the comments based on my experience in > persective. [Bartlett, Roscoe A] The real problem comes when you can't architect all of the code yourself with one consistent style and instead have to glue together code from lots of different sources that had very inconsistent ideas about design and managing memory. Early experience with this type of work lead me to put in the extra_data hack in Teuchos::RCP. It was not pretty but it worked to glue all kinds of software together effectively. > > These types of experiences have > > lead many C++ teams to code C++ with a (justified but unfortunate) > paranoia > > about the use of memory in C++ that has all kinds of bad consequences > > I think that those memory problems are funtamentally rooted at a design > issue. [Bartlett, Roscoe A] The problems are rooted in the raw manipulation of memory with raw pointers and raw calls to new and delete and raw use of arrays as raw pointers. In my opinion that this is the design problem. Others will likely disagree. > In the mid 90's I used to developed best practices and utilities for > sane memory > management (and other sanity requirements), in the same spirit of the > paper you > presented (I did read it btw). I even implemented custom allocators, > based on > class-specific memory pools, and mandated that every object should obey > a strict > allocation-deallocation protocol. > > Simply defining a new class on my system required the use of a macro- > based DSL, > something like "DEFINE_DERIVED_OBJECT(Foo,Base). Likewise, object > graphs had to > be very carefully spelled with my DSL, as in "INCLUDE_SUBOBJECT(Bar)", > and so on.. > > This forced everyone in the team, year after year, to learn a language > on top of > C++. [Bartlett, Roscoe A] Note that the STL absolutely defined a new language in C++ as has been pointed out by Scott Meyers in Item 1 in "Effective C++ 3rd edition". The question is if the new language provides enough benefit to justify having to learn it. I believe that STL has been hugely worth it but it is only a container, algorithm, and data-structure library and does not solve the most fundamental problems with C++ coding; the usage of raw pointers which the STL alone did not eliminate the need for in many programs (others may disagree). > In the long end, however, I realized I was just overengineering the > problem way > too much, putting a big burden on the team and making it difficult for > newcomers. [Bartlett, Roscoe A] That was my opinion also in the late 90s as I was also going down that road and I stopped around 1999 but I have since come to regret that view today for the reasons described in Section 3.2 of: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf As argued in Sections 5.8 and 6.2 of the above document, the Teuchos MM classes and the associated idioms create a fairly thin language above raw pointers that increase the self-documenting nature of the code in a way you can't do with a language like Java or Python. > When C++ evolved I found new, much simpler ways to solve the same > problems, and > in particular, memory problems: using smart pointers (even long before > boost::shared_ptr came alone). Once I started using smart pointers I > never > looked back, and I never again, ever, had to spend a single minute on a > memory leak. [Bartlett, Roscoe A] Smart pointers solve leaks very well but the real problem are other invalid usages of memory that create undefined behavior. In CSE we have to use lots of arrays and we can't mandate that all memory use std::vector or STL allocators to do all of the allocations. The main holes that were filled with the Teuchos MM classes were better safer handling of arrays without mandating (not even at compile-time) how the memory is allocated or deallocated in a consistent system. > > Come one, at least some people on this mail list must have had > similar > > nightmare experiences in trying to track down and diagnose hard > memory misuse > > errors in C++ that took days of effort to resolve (even with the help > of > > tools like valgrind and purify). > > > Before I started using smart pointers, yes. > After that, no.. never again. [Bartlett, Roscoe A] Yes but what currently exists in C++0x and boost for arrays is not sufficient to provide the guarantees. Read the paper, look the classes, and make of you mind for yourself. Also, what did you do in cases where you did not need machinery for persisting associations and could not afford the overhead of reference-counting classes? Did you just use a raw pointer? Did you use a raw C++ reference? Are all of your objects using value semantics (deep or shallow copy) and just copied objects? That was the hole the Teuchos::Ptr class was designed to fill and it still provides full referentially checking in a debug-mode build. > > And again, tools like valgrind and purify will *never* catch semantic > misuse > > of memory (i.e. allocating a big chunk of memory and then breaking it > up to > > be used to construct different objects and array of objects). The > Teuchos MM > > classes will catch most semantic misuse of memory in a way that no > tool like > > valgrind and purify every can (because they don't know the context of > your > > program, they only know that any read/writes in a big block of memory > that > > you allocated look okay). I think this is a big deal in catching > > hard-to-find defects that are not (technically speaking) memory > misuse > > defects but are program defects none the less. > > > I totally fail to see why this design mistakes (wrong allocation > pattern) should > be detected by a framework? These are design issues and should be deal > with at > that stage. Surely any team can be trained not to make such mistakes. [Bartlett, Roscoe A] Telling people to simply stop making mistakes is not a solution to every problem. W. Edwards Deming stated that most mistakes that are made by people are due to a faulty process or faulty support tools. If people keep making mistakes then we need to first look at the processes and tools and not just blame them. We should be able to create the tools so that basic errors in memory usage are automatically detected, even in C++. The Teuchos MM classes and idioms paired with a static analysis tool (if we could find and configure one) to help enforce the idioms would largely solve this problem in C++. Otherwise, most people what currently write CSE software would be better off writing code in a language like C# but that is just not viable for many reasons.

5 6