- Boost - lists.preview.boost.org

Re: [boost] Review of a safer memory management approach for C++?
by Bartlett, Roscoe A 07 Jun '10

07 Jun '10

Hello, This is the last email that I will write and respond to on this tread of emails about runtime vs. compile-time polymorphism (we have beet this dead horse about enough I think). I will summarize my arguments and the baulk responses from people. My perspective comes from having developed and maintained a templated package in Trilinos called Thyra that uses only the most basic type of templating; templating runtime abstract interfaces on the single Scalar type (i.e. double, float, complex<float>, complex<double>, etc). This is the most trivial and basic type of templating that you can possibly imagine (and was the type of templating that templates in C++ was supposed to support in the first place). Templating all of this code was not my first choice but in retrospect it was the right thing to do since you would have to duplicate all of the code (source and binary) multiple times (once for each scalar type) in order to support this variety of scalar types in C++ in a single program. However, this has not been easy by any stretch of the imagination. Now Trilinos is redoing is core linear algebra and linear solvers with the advent of the more heavily templated Tpetra package and will have similar issues. Up until recently, I was just having to compile and link Thyra and client code using the implicit template instantiation mechanism on the *wide* variety of compilers that we are contractually obligated to support including several different versions of GCC, Intel, Sun, PGI, IBM, Pathscale, and Visual C++ on a whole bunch of platforms (Linux, various flavors of Unix, Windows, specialty HPC systems, etc.). In many ways, I think that I have been the unfortunate first adopter of heavily templated code on many of these platforms. Eventually, I figured out how to portably and maintainability manage explicit template instantiation (see GCG 28 in http://www.cs.sandia.gov/~rabartl/ThyraCodingGuideLines.pdf) which has allowed me to port this templated code to several platforms where it would otherwise just segfault or crash the compilers (e.g. Sun and PGI). Going to carefully orchestrated explicit template instantiation has allowed me to recover a lot of the positive properties of non-templated code (i.e. fast recompile times, being able to compile just a single source files to work out compile problems, etc.). However, even with this most trivial type of templating (a single template argument), explicit instantiation is not automatic to support and significantly complicates the design and maintenance of the software. For new more heavily templated packages like Tpetra and the next generation of template software based on Tpetra in Trilinos that is being written, it is even more difficult and more complex to support explicit instantiation. If have fought the good fight for the use templated code in this non-ideal HPC environment for many years and I have earned to right to express my experiences and wisdom from the trenches on this topic. In return, the majority of the comments have basically been: a) Common response from list members: If have had trouble with templated code, it is because I don't know how to design or write software (just read some of the comments below and in some of the other email responses). My response: You can't get more simple templated code than a single Scalar template argument that is used in Thyra. I can't imagine a more basic use of templating and I have no clue how to design this "better". The only way to make this portable is to use explicit template instantiation which is not completely trivial to support, even for the most simplistic type of templating (i.e. just one Scalar template argument). b) Common response from list members: I should not bother supporting troublesome compilers like Sun, IBM, and PGI. My response: As I have explained many times, if our code can't support *all* of these platforms, then our customers can't use any of this code and we need to find another job. I don't know how much more direct I can state this. I have fought many battles against our customers who demand to use bad C++ compilers but we are going to have one or two bad compilers that we need to support for many years to come that throws a monkey wrench into the otherwise "perfect design" of the software we would like to write. You should see the emails that I get from people about "being in an ivory tower" when I complain about having to support non-ANSI C++ compilers. If some of my responses have been testy, it is because I am a little warn out with the above two general responses to problems that I have had with heavily templated code. Please don't just dismiss my opinions based on hard fought experience by assuming that I have no idea what I am doing. This entire thread of many emails and responses was sparked by my original request to review the approach described in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf which really has nothing to do with runtime vs. compile-time polymorphism. There has been a lot of responses but has anyone taken the time to even read at least the reduced table of contents described in the Preface? I know this is a long document at over 150 pages in the main text but the reduced table of contents is only something like 45 pages or so. A few selected responses to some other emails below ... > 1. Re: Review of a safer memory management approach for C++? > (Mathias Gaunard) > 3. Re: FW: Boost Digest, Vol 2933, Issue 1 (joel falcou) > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 05 Jun 2010 17:59:24 +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: <hudvpc$76f$1(a)dough.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > ... > > > 2) Current compilers may not even be able to compile large amounts of > template code at all. There are compilers that we have to support > (e.g. Sun and IBM) that will segfault or return "internal compiler > error" when you give them too much template code. These same compilers > have no problem with virtual functions with standard OO. This is > reality. > > It's up to you whether you want to support those compilers or not. > I myself see little compelling reason to support the Sun compiler, > almost likewise for IBM, at least for new C++ projects. > > Balance your support for legacy compilers with your willingness to have > nice code. [Bartlett, Roscoe A] As explained above, I fight the battle all the time to avoid having to support such bad non-ANSI compilers but we will have to live with these problems for many years to come. If we can't support *all* of these platforms, then they can't use *any* of the code that does not port to all of these platforms, period. This is not a joke. I suspect that Trilinos and other HPC projects are not the only software projects that have to live this reality. > > 3) Templated programs can result in massive object-code bloat over > equivalent runtime OO programs. If you are really sloppy with > templates and use it for everything, you can easily double, triple, or > more (10x) the size of the object code and executables (see Item 44 in > "Effective C++, 3ed edition"). > > They can, but they don't have to. > If your template function is not a good inlining candidate, is likely > to > get instantiated with many different types and and if making it > runtime-generic has sufficiently low costs, then you should consider > doing it. [Bartlett, Roscoe A] 99% of Thyra-based code should not ever be inlined (see description of Thyra above or just go look at the Thyra Website). > Note, however, that the size costs are usually grossly exaggerated. > I've > seen people use advanced template C++ code on microcontrollers (the > kind > with a few kilobytes of memory) just fine. [Bartlett, Roscoe A] If you templated the algorithms instead of using Thyra interfaces, you would have new and different object code for every concrete set of operator/vector subclasses. Just in Trilinos this would result in at least a 3x increase in the size of the object code. There is no way around this. > > As long as people keep suggesting that we template all of our codes > for every little reason > > No one is suggesting this. > Make your code only as generic as your algorithms intrinsically are, no > more. > > Algorithms are what lay at the center of generic programming, not > objects. This is quite a different view from OOP. [Bartlett, Roscoe A] Using Thyra as the example, if you throw away the abstract interfaces, then 99% of your algorithmic code would be templated in order to achieve (compile-time) polymorphic behavior. This is a very simple issue to analyze. > > Thinking that we are going to drop runtime polymorphism and use > exclusively compile-time polymorphism for everything is just fantasy > land. > > Compile-time polymorphism is better, and you can build runtime > polymorphism on top of it with type erasure. > > So why avoid compile-time polymorphism when you can do it? [Bartlett, Roscoe A] The only way to manage large amounts of templated code is to explicitly instantiate it which is not trivial to code and maintain (again, see above). > ------------------------------ > > Message: 3 > Date: Sat, 05 Jun 2010 19:08:55 +0200 > From: joel falcou <joel.falcou(a)lri.fr> > To: boost(a)lists.boost.org > Subject: Re: [boost] FW: Boost Digest, Vol 2933, Issue 1 > Message-ID: <4C0A84A7.7060002(a)lri.fr> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > ... > > And I can tell you that, as a consultant and now as an assistant > professor involved in variosu HPC project, the quality of code I saw in > laboratory is usually sub-par. [Bartlett, Roscoe A] What is this supposed to mean? > > The size of object code does have some impact, especially some HPC > machines. Again, please teach us all how to do this because we > apparently don't know what we are doing. > > > You can also learn to reply without actually barking at people. It > helps > having a sane conversation. [Bartlett, Roscoe A] As described at the top, when the common response to problems is that "you don't know how to design software" one has almost no choice but to respond in such a way. Again, the templating in Thyra could not be more simple. > > The compilers segfault or return internal compiler errors or take > hours to compile if they do finish at all in some cases. See above. > Reality!!!!!!! > > > Reality of sucky compilers from 2 century ago. It's lkike blaming > people > using new cars with biofuel whiel comapring them to Ford T. [Bartlett, Roscoe A] As described at the very top, I fight the battle against bad C++ compilers constantly but we are going to have to live with some bad compilers for many years to come. What do you expect us to do? Should I just quit my job as a protest against bad C++ compilers? > > My argument is that current accepted ways of writing OO code in C++ > make it too hard to write correct well designed programs and an > affordable cost. My argument is that the Teuchos MM approach described > in: > > > > http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf > > > > together with static analysis tools to help enforce the idioms (and > keep raw pointers encapsulated) can largely eliminate undefined > behavior in C++ programs due to the usage of memory and also yield > programs that are more self-documenting at the same time. > > > > > Well, you better be writing JAVA or OCaml ... [Bartlett, Roscoe A] Not true. As described in Section 6.1 in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf the idioms using the Teuchos MM classes can yield better self documenting code than you can get with languages like Java and Python. Did you bother to read the document? Yes I know it is very long but I think there is some worthwhile material contained in it that should be given a far shake and not just dismissed by uninformed email responses. (By uninformed, I mean you likely did not ready the document, not that you are fundamentally uninformed). - Ross

2 1

[thread] Customizing barrier for improved performance
by Belcourt, Kenneth 06 Jun '10

06 Jun '10

Hi, I notice that the thread barrier class is fairly large (128 bytes on Darwin with Intel 11.1). private: mutex m_mutex; condition_variable m_cond; unsigned int m_threshold; unsigned int m_count; unsigned int m_generation; and sort of slow for my application (parallel iterative solvers of sparse linear systems). Many iterative algorithms have both serial and parallel sections during a single iteration and, for larger algorithms, this can result in numerous (order 10 or so) rendezvous points during each iteration. During cursory testing I've found that a barrier implemented with atomics is a bit faster than a mutex based barrier (though I recognize that an atomic spin-based implementation can potentially hang if running on a single Intel core with hyper- threading enabled). I've attached a simple atomic based implementation built on Intel tbb atomic though it's easily convertible to boost.atomic when the time comes. This implementation just ping-pongs a counter alternating between incrementing and decrementing the counter each time it's called. Does anyone know if there's plans to extend barrier so that a user could select a different implementation (like an atomic based one)? For some applications this could be a very useful extension. Thanks. -- Noel

1 0

[filesystem] Version 3 of Boost.Filesystem added to trunk
by Beman Dawes 06 Jun '10

06 Jun '10

Because version 3 will break some user code, both v2 and v3 will be shipped for several releases. For 1.44, the default is v2 and the user has to explicitly switch to v3. I'd really appreciate it if some Boosters could give v3 a try on your own code that uses Boost.Filesystem. If you already have trunk on your machine, just run "svn up" on it. Otherwise, checkout a copy: mkdir boost-trunk svn co http://svn.boost.org/svn/boost/trunk boost-trunk If you prefer, "svn export http://svn.boost.org/svn/boost/trunk boost-trunk" should also work. Then read boost-trunk/libs/filesystem/dual_versions.html, and follow the instructions there. Then please let me know your results: * Are the instructions for changing to version 3 sufficient? They are pretty minimal, but I'm assuming those doing this have a high level of background knowledge. * Did you have any problem changing to version 3? * Did you have problems compiling your code against version 3? * If there were compile errors, do you have any ideas about how to mitigate the problem? * Did you have any problems testing or running your code with version 3? * Any other comments or suggestions? Thanks, --Beman

8 28

Bug Sprint daily update for Sunday, June 6th
by Marshall Clow 06 Jun '10

06 Jun '10

As of 0800 Pacific time today, we had 988 open trac tickets. This is down by one from yesterday. However, there was lots of activity on the Trac yesterday: There were 4 tickets added There were modifications to 24 tickets. (ok, some were the same ticket more than once, but still...) There were 5 tickets closed. Daniel James did a lot of cleanup on the Quickbook tickets. Vicente Botet did an analysis of many of the Boost.Thread tickets and posted it to the list. Open tickets by type: Bugs 611 (-2) Feature Requests 239 (+1) Patches 95 Tasks 27 Support Requests 15 Library Submissions 1 Open tickets buy milestone: To Be Determined 186 (-1) Boost 1.43.0 181 (+1) Boost 1.42.0 132 Boost 1.40.0 85 Boost 1.36.0 82 Boost 1.41.0 81 Boost 1.39.0 67 <none> 60 (-1) Boost 1.38.0 45 Boost 1.37.0 37 Boost 1.44.0 20 Website 1.X 10 Boost.Jam 4.0.0 1 Top 10 libraries: thread 76 date_time 54 (-1) Python 48 test 43 interprocess 40 iostreams 37 filesystem 36 mpl 36 quickbook 32 (-1) asio 31 Top 10 owners: anthonyw 75 djowel 66 (-5) dave 58 igaztanaga 58 az_sw_dude 52 (-1) vladimir_prus 49 bemandawes 46 rogeeff 43 agurtovoy 36 turkanis 36 -- Marshall

1 0

[phoenix] Result type & compatibility with result_of
by Andrey Semashev 06 Jun '10

06 Jun '10

Hi, Is there a rationale of Phoenix2 being not compatible with STL functors and result_of? I'm trying to bind an STL functor and it fails to compile.

2 1

[Proto] Can't statement like expression be part of proto
by joel falcou 05 Jun '10

05 Jun '10

after digetsing all the contents of eric boost'con talk i came to the conclusion that epxression-tempalte enabled statement may be part of proto like operators. One can see the ability of having if or for as a real expression geenrator for any EDSL as actaully a feature. What may prevent if_, for_ and such to be first class, EDSL agnostic citizen fo proto ?

2 1

[polygon] tutorial done and library ready for release
by Simonson, Lucanus J 05 Jun '10

05 Jun '10

I have just added a tutorial to the documentation. The tutorial walks the reader through the requirements, design and implementation of a toy layout versus schematic comparision application. I would like feedback from the community on whether this is what you are looking for in a tutorial. Also I'd like to check with my review manager, Fernando, if this tutorial satisfies the acceptance requirement that I add a tutorial to the documentation. The tutorial can be found here: https://svn.boost.org/svn/boost/sandbox/gtl/doc/gtl_tutorial.htm At this stage I think I have satisfied the acceptance requirements from the review and would like to coordinate merging the library onto the trunk and release branch to get into the next release of boost. A little guidance from the release manager would be appreciated. Thanks, Luke

9 28

FW: Boost Digest, Vol 2933, Issue 1
by Bartlett, Roscoe A 05 Jun '10

05 Jun '10

Joel, > 13. Re: Review of a safer memory management approach for C++? > (joel falcou) > ------------------------------ > > Message: 13 > Date: Sat, 05 Jun 2010 16:40:01 +0200 > From: joel falcou <joel.falcou(a)lri.fr> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++? > Message-ID: <4C0A61C1.3020804(a)lri.fr> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Bartlett, Roscoe A wrote: > > 1) Well written OO C++ software builds and (more importantly) > rebuilds *much* faster than heavily templated code. This massively > speeds up the development cycle. The difference can be orders of > magnitude of time savings in recompile/relink times. I have seen cases > where carefully using runtime OO can result in recompile/relink cycles > take less than 20 seconds where using all template code would take 20 > minutes. I am *not* exaggerating here at all. > > > You have the right to write proper, fast to compile template code. > Technics and tools exists for this. And if your tempalte takes 20mn to > compile, your template design is wrong ... [Bartlett, Roscoe A] Nonsense. Apparently myself and no-one else in CSE or any other domain knows the right way to write templated code. Apparently all the books I have read on C++ and template programming (see http://www.cs.sandia.gov/~rabartl/readingList.html#_B%29_C++_Books) have not taught me the *right* way to write template C++ code. If it is that hard to write "correct" template C++ code then C++ should die a slow and painful death because no-one will be able to use it correctly. Oh, would you please teach us? > In our own HPC template base > code, everything compiles under 20s and only some exhaustive unti test > that instanciate all and every type/functiosn took up to 5mn. > > 2) Current compilers may not even be able to compile large amounts of > template code at all. There are compilers that we have to support > (e.g. Sun and IBM) that will segfault or return "internal compiler > error" when you give them too much template code. These same compilers > have no problem with virtual functions with standard OO. This is > reality. > > > Sun and IBM are all but references on the point of tempalte handling > ... > gcc, MSVC, ICC and even clang don't choke on most templated code ... > What about stopping working with compilers from before the industrial > revolution ? [Bartlett, Roscoe A] We don't get to pick the platforms that we have to support. If you supply code to ASC customers you will compile on their platforms, including Sun, IBM, and PGI. In fact, this is one reason why we can't have any mandatory dependencies on boost because there have been portability problems with boost on some of these platforms. Things have gotten a lot better with C++ compilers that we have to use in the last 9 years since I have been at Sandia but it is just not true that implicit instantiation with template code will compile just as fast as non-template code. There are fundamental arguments to refute that. Compilers could be much more crafty with templated code than they currently are but they are not (yet) and never will be with some compilers (i.e. Sun, IBM, PGI, etc.). > > 3) Templated programs can result in massive object-code bloat over > equivalent runtime OO programs. If you are really sloppy with > templates and use it for everything, you can easily double, triple, or > more (10x) the size of the object code and executables (see Item 44 in > "Effective C++, 3ed edition"). > > > > > same than 1/ learn to do it right ... And well, since when gigabyte > started to be costly ? [Bartlett, Roscoe A] The size of object code does have some impact, especially some HPC machines. Again, please teach us all how to do this because we apparently don't know what we are doing. > > 5) Well written OO C++ software allows for significant runtime > flexibility. If you use dynamic libraries, for instance, you can add > new implementations of objects without even having to relink customer > executables. Also, you can fix many types of bugs in updated shared > libraries without having to recompile/relink customer executables. In > a large-scale software setting, this can be very helpful. > > > That's maybe th eonyl poitn where I agree with you. > > > *********************************************************************** > ********************* > > *** You can't portably compile and link large C++ programs that > template everything!!!!! *** > > > *********************************************************************** > ********************* > > > Why ? [Bartlett, Roscoe A] The compilers segfault or return internal compiler errors or take hours to compile if they do finish at all in some cases. See above. Reality!!!!!!! > > As long as people keep suggesting that we template all of our codes > for every little reason, I am going to keep reminding people of the > realities of template code in C++. If you can't respond to the above > points (especially #1 and #2) then there is little point in continuing > the discussion. Thinking that we are going to drop runtime > polymorphism and use exclusively compile-time polymorphism for > everything is just fantasy land. > > > Nobody told you to put template everywhere. Same we don't want to put > dynamic polymorphism everywhere. What about learnign to sue the proper > tool for the proper task ? [Bartlett, Roscoe A] Finally we agree. Runtime polymorphism with OO has its place as does templated code with compile-time polymorphism. I was never arguing that template methods should never be used (because I use them all the time, much more than most C++ programmers) but other people did seem to be arguing to never use runtime OO with virtual functions (which is just bad advice). My argument is that current accepted ways of writing OO code in C++ make it too hard to write correct well designed programs and an affordable cost. My argument is that the Teuchos MM approach described in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf together with static analysis tools to help enforce the idioms (and keep raw pointers encapsulated) can largely eliminate undefined behavior in C++ programs due to the usage of memory and also yield programs that are more self-documenting at the same time. That is it. - Ross

2 1

[Beman's endian] explicit native endianes
by vicente.botet 05 Jun '10

05 Jun '10

Hi Beman, I see that there are specific classes for native endian, endian<endianness::native, ...>. I was wondering if instead of defining a separated class we can not define endianness::native depending on the ENDIAN of the host and remove the explicit definition. # ifdef BOOST_BIG_ENDIAN BOOST_SCOPED_ENUM_START(endianness) { big, little, native=big }; BOOST_SCOPED_ENUM_END #else BOOST_SCOPED_ENUM_START(endianness) { big, little, native=little }; BOOST_SCOPED_ENUM_END #endif Will this break the design? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

4 5

[endian] swap_in_place use case
by vicente.botet 05 Jun '10

05 Jun '10

Hi, I'm looking for a use case where the use of swap_in_place (or whatever is renamed) is not followed/preceded by a copy. When I need to send a message I need to copy the information to send in a buffer. I gues that in this case the use of swap (copy) is the function to use. Can somene help me to identify a real use case on which the swap_in_place can be used to send a message that do not need to be initialized before sending? When I receive a message, I will need to store some of the messages information on application context, store them on local variables or pass them to other functions. All this suppose a copy from the buffer to the different kinds of native storage. I gues that swap (copy) should be used in this case also. The example of Terry reveives a array of ints and makes a swap_in_place, but do nothing with. Someone has proposed to sum all these ints, but in this case, we don't need to swap_in_place and the count. With swap approach, we can count at the same time as we do the conversion, so no need to swap in place. Can somene help me to identify a real use case on which the swap_in_place can be used to reveive a message, without needing to do any additional copy from the swapped buffer to native data? Thanks, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

3 3

Trunk tests broken
by Belcourt, Kenneth 05 Jun '10

05 Jun '10

Hi, Could I suggest that when the trunk tests are completely broken, as they are now, and the report generation is cycling normally (every 1 to 2 hours) as it is now, that the likely source of breakage is a recent commit to the trunk repository. To reproduce the trunk failure, simply checkout out a current version of the trunk, cd to the status directory, and run bjam. If you do this right now, you'll find this error message. error: Unable to find file or target named error: 'test_diamond_complex.cpp' error: referred from project at error: '../libs/serialization/test' This is what's currently killing trunk testing. Since it's quite easy to reproduce the trunk failure, I think it would help Boost if developers would, when they recognize a problem, either revert the offending commit or ping the library author(s) to let them know about the breakage. Unfortunately I am unable to keep on top of when trunk testing is broken (i.e. it could be several days before I notice it) so if other developers could help diagnose breakage and report it, that would be very helpful. [ Robert, can you please address this issue? ] Thanks. -- Noel

8 17

Re: [boost] [endian] swap_in_place use case
by Dave Handley 04 Jun '10

04 Jun '10

Vicente Botet wrote: > Couldn't the filter be adapted to the endianess of the file and work directly on the disk format? Surely this violates the most important principle of endian swapping - that you should always work in native endian and swap on the boundaries. If I specifically wrote the algorithm to work on the disk endianess I would need to adapt the algorithm to cope with both big and little endian situations; the algorithm would change depending on which platform I compiled on; and every person coding on the algorithm would need to code to be endian aware. This would be a maintenance nightmare. I'm not sure I've been totally clear on what I mean by a filter. I mean a filter in the signal processing sense of the word. So let's set up a problem where we are reading a 10000x10000 image with 4 byte integer gray scale at each pixel and uncompressed (so 400Mb file). This is in big endian format. What I then want to do is convolve a number of kernel with the original image to perform various image transformation. The kernels I'm going to use are, say, the following (Sobel kernels): [ 3 10 3 ] [ 0 0 0 ] [ -3 -10 -3 ] [ 3 0 -3 ] [ 10 0 -10 ] [ 3 0 -3 ] And maybe a few more. Each will be convolved with the image, and since I'm using this for feature detection, all I want to do is create a list of points over a given (absolute) threshold. So I'm creating a resulting data object that is much smaller than my input object. Now here, if I swap on use, then if I run this code on a little endian machine I will end up swapping everything 9 times per 3x3 kernel that I convolve. If I swap up front and then convolve, on a big endian machine I will end up using twice the memory (and copying the whole source file). If on the other hand I swap in place, on both little and big endian machines I have an efficient algorithm. My pseudo-code for this is going to be: Swap in place version: 1) Memory map big file 2) Endian swap in place 3) For each filter: Convolve filter with image, and output results Swap and copy version: 1) Memory map big file 2) Copy entire big file whilst endian swapping 3) For each filter: convolve with copy of image, and output results Swap on use version: 1) Memory map big file 2) For each filter: convolve with disk-endian image, hence for each pixel in image swap pixel and 8 surrounding pixels, multiply given 9 pixels by the filter and output if over threshold. End up swapping each pixel 9 times. Terry Golubiewski wrote: > I disagree. I have demonstrated that... > > 1) endian-on-access can be zero cost in the native-case. > 2) swapping in place is not any safer because the C++ type system cannot > help to determine which portions of an object have been swapped, nor > document the endian properties of a data structure. endian<big, double> > can, and should, be defined to provided portable floating-point transfer and > persistent storage. > I, in turn, also disagree. I'm not quite sure what you did demonstrate with your test case. If by "endian-on-access" you mean copying during the endian swap, then I don't think it is ever zero cost since a copy is always required. It is the same cost as the swap/swap-in-place code if and only if your code requires a copy to take place at some point, at which point both cases require the cost of a copy. To be honest, because your test case didn't separate reading data in from performing the swap, I was really unsure what information it actually conveyed. I would agree with another commenter (Robert I think) who asked for some timing code to be placed around the actual endian swapping to properly time how long the swap took on its own. I don't think the issue with endian swapping code is "safety" since you should really be endian swapping at the boundaries (when the data is read into the machine you should be converting to machine endian) and that will always be "safe". Actually, the big problem I have with the endian types is that you require 2 versions of every structure you are reading in for swapping (one version with endian types and one without); and that you are tempted to defer endian swapping until very late in the code, which means that you are no longer endian swapping at the boundaries. I would really dislike debugging a program that carried around data in the wrong endianness and only swapped it when used. I actually suspect the most common use case of endian types would be as a really short lived temporary storage for the wrong endian data from disk/network/elsewhere, and as such I don't see what you gain with a "type-safe" interface. Dave Handley

1 0

Boost Bug Sprint #3 starts tomorrow!
by Marshall Clow 04 Jun '10

04 Jun '10

The bug sprint will run from tomorrow June 5th until Sunday, June 13th. As of 11:00 AM PST today, there are currently have 992 open tickets. The goal is to classify and fix bugs, and to close Trac tickets. For those just joining in, the tickets live at https://svn.boost.org The instructions (mostly repeated here) for the first bug sprint are at https://svn.boost.org/trac/boost/wiki/BugSprintJune2009 As the bug sprint progresses, I will be posting updates to the list and to https://svn.boost.org/trac/boost/wiki/BugSprintStatusJune2010 What can you do? You can fix bugs • If you are a library maintainer, you can commit your fixes. • If you are not a library maintainer, you can fix a problem on your local machine (and test it!!), and then attach your fix as a patch to the Trac ticket for the library maintainer to commit. If you do this, please provide a test case that exercises the problem; i.e, one that fails w/o your patch, and succeeds afterwards. You can characterize bugs • You can attempt to replicate the bug on your system(s), and attach information that you discover to the Trac ticket. This will make it easier for other people to solve the problem, even if you cannot. • You can write test cases demonstrating the problem, and attach them to the Trac ticket. • You can determine if the bug still exists; sometimes they get fixed, and the ticket never gets closed. In this case, try to identify a checkin that addresses the bug; it's always suspicious when bugs go away "by accident." You can test patches • Some of the tickets in the Trac system contain patches - some are quite old. You can install these patches on your system, and determine if they (a) build, and (b) work. If you do this, please provide detail. Don't just say "works for me" - say "I installed this over revision XXX on system YYY with compiler ZZZ. The patch installed and compiled successfully, and passed all the tests." • You can write test cases for the patches, and attach them to the ticket. You can help implement new features • There are a whole set of "feature requests" in the Trac system. If you have an idea about one of these, you can add comments to the Trac system. You can attempt to implement these new features, and attach the patch to the ticket. (Don't forget the test cases!!). There are several Trac reports that I find helpful for looking at the bugs: 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 and, of course, the main report at https://svn.boost.org/trac/boost/report/1 Some things I see while looking at these reports: * There are 82 bugs with a milestone of "Boost 1.36.0", which was released 22 months ago. * There are 24 tickets with no owner, of which 15 are 'bugs'. * There are 63 tickets with no milestone attached; we have the "to be determined" milestone for cases where you're not sure when the fix will go in. -- Marshall

1 0

[system] error_code.hpp - questionable includes
by Christian Holmquist 04 Jun '10

04 Jun '10

Hi, I noticed that system/error_code.hpp caused some unexpected increase in compilation time, and looked trough its includes. The following seems not needed: #include <boost/cstdint.hpp> #include <boost/assert.hpp> #include <boost/operators.hpp> #include <boost/noncopyable.hpp> // 1) #include <stdexcept> #include <functional> // 2) 1) noncopyable is used to tell that a class (error_category) with pure virtual functions cannot be copied. This is implicit in the language, so really not needed. Unless there's a compelling reason to make sure derived classes can't be copyable either, but I didn't see any reason for this? I didn't look very close though, could've missed it. 2) inclusion of <functional> seems only needed to have the following: bool operator<( const error_category & rhs ) const { return std::less<const error_category*>()( this, &rhs ); } I can't guess the reason for using std::less instead of simply writing '<', but surely it can be expressed without std::less, no? And before getting the common Booster's answer when asking to remove #includes: Yes, I am aware of precompiled headers. I use them, too. =) Cheers, Christian P.S. Would it be too much to ask for having a separate header for the error_code's ostream operators?

2 2

[test] patch for test_fp_comparisons.cpp
by Jürgen Hunold 04 Jun '10

04 Jun '10

Hi ! According to http://www.boost.org/development/tests/trunk/developer/test.html nearly all compilers fail compiling test_fp_comparisons.cpp. With gcc-4.4 I get: test_fp_comparisons.cpp: In member function ‘void test_close_at_tolerance::test_method()’: test_fp_comparisons.cpp:165: error: reference to ‘fpc’ is ambiguous test_fp_comparisons.cpp:157: error: candidates are: namespace fpc = boost::math::boost::math::fpc; /home/hunold/src/devel/boost/boost/test/floating_point_comparison.hpp:280: error: namespace boost::test_tools::fpc = boost::math::boost::math::fpc; The attached patch removes the offending namespace alias in the test file. Okay to commit ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

1 0

[test] patch to enable gcc visibility support
by Jürgen Hunold 04 Jun '10

04 Jun '10

Hi ! I've attached a patch which uses the new Boost.Config logic introduced in revision 62140 to enable gcc visibility support. This fixes #2114 for Boost.Test. It is based on the already working patches to Boost.System and testet on gcc-4.4, 4.5 and msvc-9.0 and 10. Okay to commit ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 2

Re: [boost] [endian] swap_in_place use case
by Dave Handley 04 Jun '10

04 Jun '10

Vicente Botet wrote: > I'm looking for a use case where the use of swap_in_place > (or whatever is renamed) is not followed/preceded by a copy. I'm not sure you got an answer to this question. Here is a simple use case. Memory map a network endian file. Swap_in_place. Use. You definitely don't want a copy in this case since your file could easily be very big. Think of the case where your file is huge (say 10Gb), you really don't want to perform a copy and swap since that puts your memory need at 20Gb instead of 10Gb. Dave Handley

2 1

Re: [boost] Review of a safer memory management approach for C++?
by Bartlett, Roscoe A 04 Jun '10

04 Jun '10

Ingo, Mathias, and David, Sorry I missed your responses. It was not sent to me personally and I am only signed up for boost summaries. Is there some forum where I can present the approach described in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf and have an opportunity to discuss the various issues with interested parties and leaders in the C++ community? I am not sure the discussions on this mail list have adequately addressed the issues. My responses are below: > 6. Re: Review of a safer memory management approach for C++? > (Ingo Loehken) > 8. Re: Review of a safer memory management approach for C++? > (Mathias Gaunard) > 10. Re: Review of a safer memory management approach for C++? > (David Abrahams) > Message: 6 > Date: Thu, 27 May 2010 20:02:45 +0200 > From: Ingo Loehken <Ingo.Loehken(a)boc-eu.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++? > Message-ID: > <OF6B67C15A.1605A772-ONC1257730.00627F93-C1257730.00631B78@boc- > eu.com> > Content-Type: text/plain; charset="US-ASCII" > > if I understand "hard to reason about" in the right why : like there is > no > need for shared ownership at all, > this also means that there is no use for COM Programming - and of > course > there is. Raw resp. opaque > pointers have one huge advantage in productive environments : They work > as > perfect isolators, removing > any compile time dependencies. And from my point of view, compile time > is > what matters most, if you go > productive, otherwise you end up waiting for recompiles. Ingo, These are exactly the right points to be made. Many complex programs are going to involve sharing objects. We see this in many programming environments. Trying to "design" our way out of the sharing problem entirely will create more problems that it tries to solve. We need to separate the issues of sharing. One set of issues relates to change prorogation that will happen in any programming language (e.g. if objects A and B share object C and if A changes C what happens to B?). This is where we should be focusing our design attention. The other issue is silly memory management problems in C++ that other more modern languages like C#, Python, and Java don't suffer from so much. Objects stay around as long as they are needed. The goal of the approach described in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf is to as much as possible make the presence of sharing explicit so that we highlight the first type of "essential complexity" in programs but to minimize as much as possible the "accidental complexity" in trying to figure out when we need to actually delete an object and who's responsibility it is to delete the object. This is a very important issues and is discussed some in Section 6.1 in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf Cheers, - Ross > From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> > To: boost(a)lists.boost.org > Date: 27.05.2010 14:59 > Subject: Re: [boost] Review of a safer memory management > approach > for C++? > Sent by: boost-bounces(a)lists.boost.org > > > Bartlett, Roscoe A wrote: > > Hello Boost developers, > > > > I am interested in finding one or more individuals who are > knowledgeable > about memory management in C++ (and especially of the reference- > counting > approach taken by boost::shared_ptr and boost::weak_ptr) to review an > idea > for a comprehensive approach to safer memory management in C++ that > encapsulates all raw C++ pointers in high-level code. > > Never use owning naked pointers and only use RAII (as is required for > exception-safe programming anyway) with exclusive ownership and no > aliasing, and you have no problems. [Bartlett, Roscoe A] Mathias, I agree but using raw pointers in any ubiquitous way is a problem. You can't detect dangling references and there are all of the other loosely typed problems described in Sections 2.1 and 2.2 in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf The issue is that it is easy to make mistakes with raw pointers related to ownership issues and if you use raw pointers, it is very difficult to detect them, even for tools like Valgrind and Purify. If no-one made mistakes, then we would all do well just to use void* and program in C. I want to eliminate undefined behavior in C++ programs in such a way that a properly configured static analysis tool could help to enforce. I believe that the approach described in http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf could be used with some static analysis tool to largely eliminate undefined behavior related to the usage of memory. There are lots of other areas of undefined behavior in C++ that this approach can't address (like bad type conversions of built-in types) but there are other idioms for addressing that. > Usage of shared_ptr should be an exception, not a widely deployed > solution to memory management issues. > Shared ownership is hard to reason about, and even if you use a similar > cycle-aware solution, cycles remain a real problem (they prevent > deterministic ordered destruction of objects, meaning they're only > applicable to certain classes of objects). [Bartlett, Roscoe A] No, if you share an object, you use a shared_ptr (or Teuchos::RCP), period. If sharing is the exception, then fine. Otherwise, don't play games with "I need shared_ptr here but I don't need it there because X, Y, and Z." We are never going to be able to produce programs that eliminate all sharing of objects, and we don't want to. Some types of programs are actually much simpler and more robust if you share some objects. For performance critical applications (e.g. the CSE domains I come from) you can't just willy nilly copy large objects and expect to achieve good performance. This is just not reality. > Message: 10 > Date: Thu, 27 May 2010 14:41:09 -0400 > From: David Abrahams <dave(a)boostpro.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++? > Message-ID: <m24ohtgpbu.wl%dave(a)boostpro.com> > Content-Type: text/plain; charset=US-ASCII > > At Thu, 27 May 2010 20:02:45 +0200, > Ingo Loehken wrote: > > > > if I understand "hard to reason about" in the right why : like there > > is no need for shared ownership at all, this also means that there > > is no use for COM Programming - and of course there is. > > I think you don't understand it the right way. Shared ownership (at > least in the presence of mutation) is hard to reason about because > seemingly-local modifications can have non-local effects. [Bartlett, Roscoe A] Yes, but let's focus on the "essential complexity" of object sharing and not get bogged down in the "accidental complexity" of memory management. The approaches described in http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf make explicit the "essential complexity" of object sharing while trying to eliminate the "accidental complexity" of memory management (see Section 6.1 in http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf) Trying to over design a program to avoid all shared ownership is what make C++ programming so unproductive and has all the negative consequences described in Section 1 in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf Designs with object sharing can be much less complex overall than designs with sharing. You just need decent tools to detect circular reference problems (and that is what the Teuchos::RCP class has). We have found that circular reference problems are fairly rare but when they occur they are a bear to track down. That is why I created all of the RCPNode tracing support in the Teuchos::RCP classes. Actually, we have found that non-deleted RCPNode objects are far more likely to occur due to other types of problems (e.g. calling abort(..), typical memory leaks, etc.) and in this role the RCPNode tracing machinery is a very cheap but effective version of memory checking that is automatically built into every debug-mode program and runs order of magnitude faster than tools like Valgrind and Purify. [Bartlett, Roscoe A] Cheers, - Ross Sorry again for not responding sooner.

3 2

Status of Boost.Atomic?
by Sean Chittenden 03 Jun '10

03 Jun '10

What's the status of Boost.Atomic? http://www.chaoticmind.net/~hcb/projects/boost.atomic/ This looks like some very interesting code that would be of interest to a number of boost users (besides, it would be nice to stop abusing boost/interprocess/detail/atomic.hpp). Thanks in advance for any light that can be shed on this. -sc -- Sean Chittenden sean(a)chittenden.org

1 0

Re: [boost] [msm] Passing constructor arguments to submachine
by Christophe Henry 03 Jun '10

03 Jun '10

>> I didn't think about Parameter and I like the idea (I also see >> somewhere else where it could be useful) but I : >> >> (a) don't have any parameter name to give to BOOST_PARAMETER_NAME >> (parameters being simply forwarded with BOOST_PP_ENUM_PARAMS) >> (b) don't know at preprocessor time in BOOST_PARAMETER_CONSTRUCTOR how >> many parameters the user will pass through the back-end to the >> front-end constructor or how many submachines/substates will be >> default-constructed by user's choice. >> >> Concretely, the user can now do something like: >> player p(/* for the front-end*/ 3, "a"); >> >> And adding states for copy-construction could look like: >> player p(/* for the front-end*/ 3, "a", >> /* some states copy-constructed*/ Paused("something") , >> Playing("more data") ); >> >> Of course I could provide some default names and create more >> constructor overloads with BOOST_PP_ENUM_PARAMS. >> >> I was actually thinking of using a proto expression like: >> player p( (/* data for front-end*/params_ << 3 << "a" ), >> (/* some states copy-constructed*/ states_ << >> Paused("something") << Playing("more data") )); >> >> But I admit having not spent enough thinking time yet so I will look >> into it again. >> >> Thanks for the idea, Dave. It will in any case be pretty cool to use >> Parameter to make back-end policies nicer. > > Please take a close look at Boost.Accumulator; it has to solve > essentially the same problem IIUC, and it does so quite nicely. You > can't use the high-level macros like BOOST_PARAMETER_CONSTRUCTOR in > the template that has to do the forwarding, though. I think it might > even improve readability to do make your life easy and accept a single > argument pack (backend_args in the example below) for forwarding to > submachines > > player p(/* for the front-end*/ 3, "a", > backend_args = ( > init1=Paused("something"), > init2=Playing("more data")) > ); > > or something like that. I like this syntax too. Ok then I will give it a try and have a closer look at Accumulator. Thanks!

1 0

Re: [boost] [boost::endian] Request for comments/interest
by Dave Handley 03 Jun '10

03 Jun '10

I wanted to throw a few things into the discussion: 1) Typed vs untyped. We have had various discussions about whether the network endian object should be a different type to the machine endian. I have a pretty strong opinion on this, and I think you should work with the same type. There are 2 core reasons for this: a. Performance when network endian is the same as machine endian - I'll discuss more on this later. b. When you are reading a complex packet of data off the network, a common use case would be to reinterpret_cast a block of data into a struct. When you are using different types for network and machine endian you end up having 2 structs - one to read the data off the network, and one to copy the data into. This could turn into a pretty severe maintenance burden. c. Given that you tend to convert to machine endian at the boundaries, you can treat the untyped interface in a very similar way to a boost::shared_ptr style interface. You call swap_in_place on the return value from the function that creates the initial struct - and therefore you never have access to the network endian version in anything except your most basic read function. As such, I think the type safety of network endian data is a bit of a red herring. It is no different from creating a raw pointer, then half a dozen lines of code later constructing a boost::shared_ptr from it. It is against the principle of the interface, and would create some evil bugs, but hasn't been formally prohibited by the interface. d. Finally, I would definitely want an endian interface that operated at a high level of abstraction - ie at the struct or container level, not at the built-in type level. 2) To copy or not to copy. I have a very big issue with any interface that enforces a copy. If I'm writing something to live on a memory limited embedded device, I absolutely want to be able to endian swap in place. Secondly, we should definitely not accept an interface that copies just on the grounds that the most common operation is from a big endian network to a little endian machine that does always require mutation. The platforms that boost runs on includes plenty of big-endian machine types; and I have come across numerous cases where (for performance reasons on a largely little endian machine environment) data has been left little-endian on the network. Having a do nothing (not even copy) case for when machine and network endianness match is very important. If you are reading a big stream of data from the network, not copying anything is a very important case, and key for writing high performance production code. 3) A final thought is that I am much more keen to use template arguments to decide on which endian swap to use than explicitly coding them in function template names. It makes endian swapping code in a big code base easier to spot, and makes the interface of the endian swapper itself more logical. When I change from big to little endian, I am tweaking a parameter of the endian swapper, not calling a wholly different function. I think from a design perspective, a template parameter makes most sense. Overall, I like Tom's interface, but I have been using it for quite a while (as a disclaimer). Dave

10 57

Mutexes claim a Windows event handle
by Peters, Richard 03 Jun '10

03 Jun '10

Hi! I have a problem with boost::recursive_mutex "sometimes" keeping a handle to a Windows Event. My application uses a lot of objects, each containing a recursive_mutex. The objects are accessed from different threads using a scoped_lock (see code below). In Boost 1.34 there was no problem, but after we switched to 1.39 it seems that the process collects more and more handles to Windows Events. Only when the objects that contain the recursive_mutex are destroyed, the handles are released again. The problem is that I must support 100,000 objects containg multiple mutexes, so if each mutex can cost one handle the total number of handles in use may become huge. I tried the latest Boost version (1.43) but that makes no difference. The strange thing is that not every object keeps a handle, i.e.: the number of handles collected is less than the number of objects created. When increasing the nrActions the number of handles collected comes closer to the number of objects. I could understand if a recursive_mutex costs a handle, except that in boost 1.34 they didn't so I wonder if this was an accident or a deliberate change. And most important: Is there a way to get the same behavior as in 1.34 where a mutex did not cost me one handle each? Thanks for your advice! Code example: #include <list> #include <boost/bind.hpp> #include <boost/thread.hpp> #include <boost/thread/recursive_mutex.hpp> #include <boost/enable_shared_from_this.hpp> class ActiveObject : public boost::enable_shared_from_this<ActiveObject> { private: boost::recursive_mutex mActionLock; void action() { boost::recursive_mutex::scoped_lock asyncLock(mActionLock); } public: void startAction() { boost::recursive_mutex::scoped_lock syncLock(mActionLock); boost::thread th(boost::bind(&ActiveObject::action, shared_from_this())); } }; int main() { { std::list< boost::shared_ptr<ActiveObject> > jobList; for (int nrObjects = 0; nrObjects < 1000; ++nrObjects) { boost::shared_ptr<ActiveObject> pActiveObject( new ActiveObject() ); jobList.push_back(pActiveObject); for (int nrActions = 0; nrActions < 3; ++nrActions) { pActiveObject->startAction(); } } // At this point, a lot of handles are in use. } // Here, the handles are released again. exit(0); } This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation.

5 9

Maintaining boost.org
by Dean Michael Berris 03 Jun '10

03 Jun '10

Good day everyone! If you were at the BoostCon 2010 panel session, I suggested that maintaining boost.org can be a less painful process and that I was willing to help out in transitioning the current site from the way it is currently set up to maybe use Wordpress to host the site. There are other options that I would like to explore only after looking at many different tools and the current process of maintaining it. I tried sending mail to the Boost-docs list but I haven't gotten any responses yet so I chose to send another email to the developers mailing list. There are a couple of questions I would like to ask and would really appreciated getting an answer about: 1. Is there currently a boost.org web team? If so, who are in the team? 2. What is the current process of building the boost.org site? What is the toolchain used and how are changes managed? Before I go into the detail of a proposal of making boost.org a little more "interactive" and "inclusive" I would first like to know the state of the system and whether there are any low hanging fruit that can be taken care of before I even suggest changing it. FWIW, I volunteer to help manage boost.org to make it more inviting to the community and more dynamic than it currently is. Although the boost.org website does host the web-based library documentation, I would like to be able to see more information on it about the community, the process, and news on what's going on. Pending a "full" proposal I would definitely appreciate thoughts about the matter too. -- Dean Michael Berris deanberris.com

12 40

Re: [boost] [msm] Passing constructor arguments to submachine
by Christophe Henry 02 Jun '10

02 Jun '10

>> > Is it also possible to pass constructor arguments to submachines of a msm >> > state machine? >> >> Unfortunately, not yet. There was a proposal made during the review to >> allow states (including submachines) to be cloned from an existing >> one, but it is not implemented yet. > > The Parameter library can sometimes be used to make this sort of thing > work nicely. See Boost.Accumulators, for example. I didn't think about Parameter and I like the idea (I also see somewhere else where it could be useful) but I : (a) don't have any parameter name to give to BOOST_PARAMETER_NAME (parameters being simply forwarded with BOOST_PP_ENUM_PARAMS) (b) don't know at preprocessor time in BOOST_PARAMETER_CONSTRUCTOR how many parameters the user will pass through the back-end to the front-end constructor or how many submachines/substates will be default-constructed by user's choice. Concretely, the user can now do something like: player p(/* for the front-end*/ 3, "a"); And adding states for copy-construction could look like: player p(/* for the front-end*/ 3, "a", /* some states copy-constructed*/ Paused("something") , Playing("more data") ); Of course I could provide some default names and create more constructor overloads with BOOST_PP_ENUM_PARAMS. I was actually thinking of using a proto expression like: player p( (/* data for front-end*/params_ << 3 << "a" ), (/* some states copy-constructed*/ states_ << Paused("something") << Playing("more data") )); But I admit having not spent enough thinking time yet so I will look into it again. Thanks for the idea, Dave. It will in any case be pretty cool to use Parameter to make back-end policies nicer. Christophe

2 1

[boost::endian] Request for comments/interest
by Tomas Puverle 01 Jun '10

01 Jun '10

I wrote an endian library on the flight back from boostcon but it has taken a little time to clear the submission with the firm. I realize that Beman's endian swapper library is already in the review queue but I hope my approach is different and interesting enough to warrant consideration. It's located here in the vault (Utilities/endian-puverle.zip): http://www.boostpro.com/vault/index.php?action=downloadfile&filename=endian… The highlights of the library are the following: - Very simple interface: swap<machine_to_little/big>(), swap_in_place<machine_to_little/big>() - Support for built-in and user-defined data types and ranges thereof. E.g. you can swap ranges of structs containing/deriving from other structs - endian::iterator, which will iterate across a range swapping values as necessary. It works with any swappable type. The library is described/documented/tested in the file main.cpp at the root of the zip archive. Unfinished items: - Right now, the library only includes the "vanilla" swapper, meaning it doesn't take advantage of special instructions on architectures which natively support endian conversion. I didn't include this in order to prevent cluttering the code with #ifdefs. This functionality would, however, be part of the final library. - Ideally, the metafunction is_mutable_range<> should be moved out of endian::detail and become part of Boost.Range of Boost.TypeTraits. I have donned by bulletproof vest and I'm ready for any feedback you may have. :) Tom

15 55