- Boost - lists.preview.boost.org

[parameter] Redefining BOOST_PARAMETER_MAX_ARITY
by Jamie Allsop 16 Oct '08

16 Oct '08

Should I expect to be able to redefine BOOST_PARAMETER_MAX_ARITY and be able to compile? <http://www.boost.org/doc/libs/1_36_0/libs/parameter/doc/html/reference.html…> For example using, #define BOOST_PARAMETER_MAX_ARITY 6 #include <boost/parameter/name.hpp> #include <boost/parameter/preprocessor.hpp> // ... code here ... does not compile. Before I spend time digging into the source to figure out the problem I thought I'd post in case the answer was 'no'. Also I wonder if there is some theoretical or practical upper limit? Thanks, Jamie

4 7

Re: [boost] New library in Vault: Msm (Meta State Machine)
by christophe henry 15 Oct '08

15 Oct '08

Ah yes. The link to the Vault Msm Directory: http://www.boostpro.com/vault/index.php?direction=0&order=&directory=Msm& _________________________________________________________________ Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=…

2 1

Support for Cell processor
by Joel Falcou 15 Oct '08

15 Oct '08

Several boost libraries compile without any problem on the cell BE processor in PPU and SPU mode like most of the preprocessor or meta-programming one. However, it's impossible to use any C++ code that include *any* part of std cause it makes the resulting binary too big for the spu linker. For some boost libraries, the std include is merely used for some optionnal display. For others, large parts of functionnalities is made useless. As I've been toying with this architecture for quite a bit now, I'm on the verge to patch my local boost with a way to detect compilation on Cell SPU and to remove inadequate include from some libraries. Considering the potential interest in supporting this architecture, would libraries developpers mind if I submit ticket with patches for this support integration when the actual pacthes is aimed at making the core of the libraries to be used on Cell BE SPU and to add things like #error or #warning that explicitely states that this library or features is disabled ? What's the current stance on adding new architectural support into boost ? Regards -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

7 12

[1.37] Merge permission sought (not a repost :-)
by Nicola Musatti 15 Oct '08

15 Oct '08

Hallo, I'd like to merge the attached patch to release. May I proceed? Thanks! Nicola -- Nicola.Musatti <at> gmail <dot> com Home: http://nicola.musatti.googlepages.com/home Blog: http://wthwdik.wordpress.com/ Index: float_functions.hpp =================================================================== --- float_functions.hpp (revision 49317) +++ float_functions.hpp (working copy) @@ -60,7 +60,7 @@ # endif // Dinkumware. -#elif (defined(_YVALS) && !defined(__IBMCPP__)) || defined(_CPPLIB_VER) +#elif ((defined(_YVALS) && !defined(__IBMCPP__)) || defined(_CPPLIB_VER)) && !defined(__BORLANDC__) // Some versions of Visual C++ don't seem to have the C++ overloads but they // all seem to have the c99 float overloads # if defined(BOOST_MSVC)

3 5

[1.37] Merge permission sought (the last one, promise!)
by Nicola Musatti 15 Oct '08

15 Oct '08

Hallo, Much to my dismay I realized this morning that I left the following patch behind: http://svn.boost.org/trac/boost/attachment/ticket/2346/boost_type_traits.pa… I'm fully aware that it is rather extensive to be applied this late in the cycle. However it is specific to Borland/CodeGear and has gone through a few test cycles on trunk without causing problems. Unfortunately due to the fundamental role that the type_traits library plays in the implementation of many other libraries, without this patch most of the other Borland/CodeGear related ones have no effect. I discussed this with John Maddock and he agreed to perform the merge if I obtained your permission. Cheers, Nicola -- Nicola.Musatti <at> gmail <dot> com Home: http://nicola.musatti.googlepages.com/home Blog: http://wthwdik.wordpress.com/

3 3

[GIL] compile time concerning apply_operation and explicit instantiation
by Philipp Reh 15 Oct '08

15 Oct '08

Hi, I'm using GIL's dynamic image extension, namely any_image_views in certain places. However on every occasion where an any_image_view is used I have to include apply_operation.hpp so the operations can be instantiated. On gcc-4.3.2 the inclusion of this header raises the compilation time at least tenfold. Somewhere on this list I found the claim that gil::variant is supposed to reduce compilation time over boost::variant but for at least gcc-4.3.2 this is untrue. There are several places in which I use boost::variant and even with binary visitation the compilation time is barely unnoticable. To work around this problem, I tried to explicitly instantiate the functions generated for my any_image_view. Trying this technique with apply_operation and detail::destructor_op failed. Looking at nm's output told me that what I explicitly instantiated and what the binary needs had at least its mpl::vector elements reversed. So, I basically have two questions: 1) Wouldn't it be nicer to use boost::variant for gil, too? As far as I can see it does everything that is needed plus it compiles a lot faster (at least on gcc). 2) Is it possible to explicitly instantiate the apply_operation function with the needed operations and if how so? If someone needs the code I tried and the error messages, I can post them. Philipp -- View this message in context: http://www.nabble.com/-GIL--compile-time-concerning-apply_operation-and-exp… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[function] Thread-safety regression in 1.36.0?
by Aleksey Gurtovoy 15 Oct '08

15 Oct '08

Doug, Emil, It seems that the problematic code discussed in http://thread.gmane.org/gmane.comp.lib.boost.devel/164902/, filed as a bug (http://svn.boost.org/trac/boost/ticket/1260) and consequently fixed in the trunk has been (inadvertently?) reverted by changeset 43884, "Change Boost.Function allocator behavior, from Emil Dotchevski" (http://svn.boost.org/trac/boost/changeset/43884) Am I missing something obvious? -- Aleksey Gurtovoy MetaCommunications

2 3

[python] borrowed
by Robert Dailey 14 Oct '08

14 Oct '08

What is the purpose of boost::python::borrowed? The documentation has no description for this member that I can see.

3 4

[release mgt] Eric Niebler joining release management team
by Beman Dawes 14 Oct '08

14 Oct '08

Eric Niebler is joining the release management team. Eric will be helping out with general release management and quality control. Like Rene Rivera and Daniel James, he will backup Beman so that release management isn't dependent on any single person. Thanks to Eric for agreeing to help out! --Beman

4 3

Ticket #2115 Avoid bad Apple macros
by Beman Dawes 14 Oct '08

14 Oct '08

> Apple has a header called <AssertMacros.h> that #defines both “check” > and “check_error.” These macros naturally collide with the same names > in Boost. We should consider a global change. What global change? That Boost not use these names? What about the other horrid macros in that header? Here is a list from Marshall: debug_string, check, ncheck, check_string, ncheck_string, check_noerr, check_noerr_string, verify, nverify, verify_string, nverify_string, verify_noerr, verify_noerr_string, verify_action, require, nrequire, require_action, nrequire_action, require_quiet, nrequire_quiet, require_action_quiet, nrequire_action_quiet, require_string, nrequire_string, requireaction_string, nrequireaction_string, require_noerr, require_noerr_action, require_noerr_quiet, require_noerr_action_quiet, require_noerr_string, require_noerr_action_string. Marshall comments: IMHO, the really nasty ones are: check, verify, require and check_error. > That would also > probably require a global policy change for checkins. > > Assigning to Beman, Cc'ing John M, component "inspection script" > assigned to John although I might be wrong about that, but obviously > we need to discuss this. Maybe we'll decide to make it "wontfix" I really don't want to start a policy of avoiding every name that is defined in any vendor header. I forget the details, but at least one vendor has shipped a header defining "read" and "write" macros! The fix for this one is to complain to Apple. They need to provide a new new header that supplies the functionality but using macro naming discipline, deprecate the old header, and add a warning to the old header suggesting that users migrate to the new header. If they wanted to be really helpful, they could provide a script to automatically change the old names to the new names. And if they have any other headers that fail to apply macro naming discipline, they should do the same for those headers too. By "naming discipline", I mean something like the Boost policy for macro names always being all uppercase and beginning with BOOST_. --Beman

8 14

New library in Vault: Msm (Meta State Machine)
by christophe henry 14 Oct '08

14 Oct '08

Hi, Following advice from Dave Abrahams and Aleksey Gurtovoy who were nice enough to have a look at the doc, I just uploaded to the Vault the first version of Msm and would be delighted to have as many people as possible have a look at it and give their opinion before I dare request a formal review. Msm offers an alternative to Boost.Statechart by implementing a relatively big subset of the UML State machine specification at high run speed and staying as close as possible to the beautiful Domain-Specific-Language described in the "C++ template metaprogramming" book. Tutorials and features can be found in doc/index.html. In doc you will also find the tutorials' code. Christophe _________________________________________________________________ Discover the new Windows Vista http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE

2 1

[parameter] error in BOOST_PARAMETER_NAME reference docs
by Ryan Gallagher 14 Oct '08

14 Oct '08

There appears to be an error in the BOOST_PARAMETER_NAME reference docs. See: http://tinyurl.com/4my48e This lists that the macro parameter "name" can be of the form: "(tag-name, namespace-name) object-name" Where "tag-name" is a structure defined in namespace "namespace-name" and "object-name" is an instance of: "::boost::parameter::keyword<tag-namespace::tag-name>::instance" (Also note that "tag-namespace" should be "namespace-name" here.) However, the implementation appears to actually be "(object-name, namespace-name) tag-name" However, this information is repeated under the "Fine-Grained Name Control" section, in which it appears to be correct. -Ryan

1 0

[1.37.0][Spirit] Spirit branches/release regression test failures
by Beman Dawes 14 Oct '08

14 Oct '08

See http://beta.boost.org/development/tests/release/developer/spirit.html Note that many of these tests were run after the revision 49310 branches/release commits. Please resolve these failures as soon as possible. Thanks, --Beman

2 1

[date_time] Patch for ticket #1740: date_time includes <windows.h>
by Emil Mieilica 14 Oct '08

14 Oct '08

Hello, date_time on Windows needs windows.h in order to have the definitions for FILETIME and GetSystemTimeAsFileTime and friends and does not use the same technique as other boost headers : if BOOST_USE_WINDOWS_H is defined include <windows.h> otherwise forward define functions as needed. In date_time is more difficult because it is a header_only library. Please find attached a patch to solve this issue and the test report of the library on the compiler I have at my disposal. I have taken precautions in order to ensure it will work on x64 Windows (please see comments related to the conversion between FILETIME and __int64) and I see no reason it should have changed for other platforms, but only testing will tell. Thank you, -- Emil Mieilica __________ Information from ESET NOD32 Antivirus, version of virus signature database 3506 (20081009) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

6 7

Identifying members
by coppro 14 Oct '08

14 Oct '08

In C++ it is possible to determine whether there exists a member of a class of a specified type (including member functions) with a given name. As far as I know, there exists no such functionality in Boost. Why is this? It can easily be implemented as a traits class for a specific identifier/signature, which can then be made into a macro.

7 8

Merge permission sought
by Nicola Musatti 13 Oct '08

13 Oct '08

Hallo, I would like to merge the following changes from trunk to the release branch: http://svn.boost.org/trac/boost/attachment/ticket/2341/call_traits.patch http://svn.boost.org/trac/boost/attachment/ticket/2342/sp_convertible.patch http://svn.boost.org/trac/boost/attachment/ticket/2352/boost_filesystem.pat… http://svn.boost.org/trac/boost/attachment/ticket/2344/boost_iterator.patch They all relate to supporting the latest CodeGear (ex Borland) compiler and all went through at least one successful test cycle on trunk. May I go ahead? Is the merge procedure outlined here: http://svn.boost.org/trac/boost/wiki/ImprovingPractices#Mergingchangesfromd… still considered the correct one? Cheers, Nicola -- Nicola.Musatti <at> gmail <dot> com Home: http://nicola.musatti.googlepages.com/home Blog: http://wthwdik.wordpress.com/

3 5

[filesystem]Setting permissions/chmod
by Johan Torp 13 Oct '08

13 Oct '08

After looking through boost.filesystem's documentation and code, I can't find anything about permissions. I assume boost.filesystem has not implemented this because it aims to be portable and POSIX style permissions isn't applicable on all operating systems. Am I correct? Best Regards, Johan Torp www.johantorp.com -- View this message in context: http://www.nabble.com/-filesystem-Setting-permissions-chmod-tp19950894p1995… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 4

Geometry and spatial indexes, my opinion
by Mathias Gaunard 13 Oct '08

13 Oct '08

Hi, Wanting to code a simple 3D virtual world, I looked into the recent spatial indexes SOC work, which depends on the proposed geometry library. I have to admit I was fairly disappointed. So I'm going to put some critics, some quite harsh maybe, along with some ramblings about what I would have liked to have. Note that I am no geometry or space indexing expert, so what I say may be perfectly silly. For starters, I think those libraries should be dimension agnostic and generic. Geometry not only has a strong 2D bias, but the documentation also says geometry::box only works with point_xy (and point_ll). Since it is used everywhere in spatial index, that means it's unusable on 3D. The geometry documentation doesn't clearly state what a geometry::box is. Is it (assuming 2D) any rectangle or only axis-aligned rectangles? In case it is just any rectangle, it mind be interesting to introduce a new type for axis-aligned ones, which can always be defined from two points whatever the dimension (well, at least it seems enough for 3D, I'm not good at projecting in other dimensions to see if that'd work). I suppose the spatial index interface expects axis-aligned boxes, so it's fairly important to clarify what we're talking about. Apart from that, there is also lots of point_xy-dependent code in spatial indexes. Also the quadtree implementation isn't dimension agnostic in particular (it should have 2^n children nodes, and not 4). I don't really get why it uses shared_ptr everywhere either (is it supposed to support COW or something?) I don't really get what boost::spatial_index::spatial_index is for. It does nothing but forward everything to the last template parameter. Instead of writing boost::spatial_index::spatial_index< point_type, value_type, boost::spatial_index::rtree<point_type, value_type> > index(args...); I might as well write boost::spatial_index::rtree<point_type, value_type> index(args...); Also, I think the spatial indexes do not provide enough operations. The only things they allow is putting point => value pairs, retrieving the value associated to a point in O(log n) time (I assume, complexity is not documented), and finding all values within a certain box (in O(log n) too?). Many things one typically wants to do with spatial indexes are not possible: - Iterate all (points, value) pairs in the index - Find the element closest (or k-closest) to some point in space or other element. - Find all elements within a certain range of some point in space or other element - Find the elements that intersect with a given object (ray tracing, for example, searches for an element that intersects with a ray and that is the closest to its source) - Consider only a part of the indexed space (e.g. an area delimited by a range/sphere or box) - Being able to index arbitrary objects and not just points - Traverse the spatial index as a tree I believe there is no need to clutter the interface with a lot of functions, most algorithms can be implemented generically as free functions. Giving a read-only tree interface to all spatial indexes ought to be enough to implement all algorithms. A spatial index, after all (correct me if I'm wrong), is nothing else but a tree that partitions space, where every node defines a partition of space that includes all of its children (which might overlap or not). Subtrees should be full-fledged spatial indexes (so that I can perform a search in a subtree), albeit read-only. Apart from that they should allow insertion and removal of object => value pairs. Quadtrees and r-trees should be fairly easy to work with: they both partition space into axis-aligned boxes (which are even cubes in quadtrees). As for allowing all kinds of objects to be stored instead of just points, that should be possible by using generic distance and intersection functions. The real difference is that the same object could eventually be in multiple places in the tree, because it spans over multiple space partitions. Whenever you put an object in the tree or split a partition, however, it would be necessary to calculate in which partitions to put the object, whereas with points you only have to find the one partition. Of course, some cases can be specialized and optimized, like axis-aligned boxes in a R-tree, which can directly be used as partitions and thus never span across multiple ones. I find it weird having a different interface for R-trees and Quadtrees. Indeed, one can only put points in a quadtree while in a r-tree you can put boxes as well. A generic approach allowing to put any object with boxes specialized seems like a better approach to me. About geometry, I think there should be more basic objects. While it is true polygons and multipolygons (polyhedrons) are enough to represent everything in 3D space, having rays, segments, triangles, quads, circles, spheres, squares, rectangles, cubes, cuboids (boxes), planes, half-planes and more, with ability to compute all intersections and distances, would be the most practical thing for 3D development. I do not know how to organize this in a really dimension-agnostic manner, however. In a nutshell, I think the spatial indexes design and how geometry can help it ought to be discussed.

16 61

[1.37.0] Release branch closed except by permission, beta one week from today
by Beman Dawes 13 Oct '08

13 Oct '08

The release branch is now closed for all changes except by permission from one of the release managers. The beta release is planned for one week from today. That's a three day schedule to provide a bit more time for QA reviews, and because it seems to work a bit better if target dates fall at the end of weekends rather than Fridays. --Beman

1 0

[trac] add component "proto"
by Eric Niebler 13 Oct '08

13 Oct '08

If I'm able to add a component to Boost's trac, I don't know how. We need a component for Proto. Owner: eric_niebler/Eric Niebler. Description is below: "Expression template library and compiler construction toolkit for domain-specific embedded languages." Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 1

Re: [boost] [phoenix] Phoenix & 1.37
by Alp Mestan 12 Oct '08

12 Oct '08

Need some help for Phoenix ? On 10/8/08, Joel de Guzman <joel(a)boost-consulting.com> wrote: >> >> Robert Jones wrote: >> >>> I see the 1.37 release is gathering momentum. >>> >>> We will see any development of Phoenix in 1.37, following on from >>> all the input of the recent review? >>> >> >> There will be development, yes. But we're still a long way >> to go. There's no chance we can make it in time for 1.37. >> I don't think so. Sorry. There's a lot to do still and it's >> impossible to do them all in a short period of time. 1.38 >> (or 1.39?) is ~probably~ a good target. >> >> Regards, >> -- >> Joel de Guzman >> http://www.boostpro.com >> http://spirit.sf.net >> >> _______________________________________________ >> Unsubscribe & other changes: >> http://lists.boost.org/mailman/listinfo.cgi/boost >> > > > > -- > Alp Mestan > --- http://blog.mestan.fr/ > --- http://alp.developpez.com/ > --- In charge of the Qt, Algorithms and Artificial Intelligence sections on > Developpez -- Alp Mestan --- http://blog.mestan.fr/ --- http://alp.developpez.com/ --- In charge of the Qt, Algorithms and Artificial Intelligence sections on Developpez

3 5

ARM thumb support in spinlock_gcc_arm.hpp
by Jerry Napoli 12 Oct '08

12 Oct '08

Hi, I'm trying to compile using boost 1_36_0 for ARMv6 Thumb for iPhone development. The compiler used is gcc 4.0.x supplied with the iphone sdk. I run into issues with the inline assembly inside boost/detail/spinlock_gcc_arm.hpp. It generates a SWP instruction which (AFAIK) is not supported in thumb mode. The gnu arm assembler gives me a 'bad instruction ...' error. I'm able to work around it by modifying spinlock.hpp to include spinlock_sp.hpp instead. But has anyone addressed spinlock support for armv6 thumb? Thanks, Jerry

8 13

[iostreams] gzip.hpp has impl in header file: multiple definition errors
by troy d. straszheim 12 Oct '08

12 Oct '08

On the trunk, gzip.hpp contains definitions for gzip_footer and gzip_header. If you use these in more than one compilation unit you get multiple definition errors at link time. I have the fix ready to commit... -t

1 0

[shared_ptr] Ticket 2126 status?
by Andrey Semashev 11 Oct '08

11 Oct '08

Hi, Is the ticket 2126: http://svn.boost.org/trac/boost/ticket/2126 actually fixed in trunk? The ticket is still open, but my code that uses enable_shared_from_this and make_shared runs fine on trunk. However, the issue is still present in the release branch. If the problem is actually fixed, and the fixture doesn't break anything else I'd like to ask to merge the change to the release branch. Thanks.

2 3

[threadpool] bugfix release
by k-oli＠gmx.de 11 Oct '08

11 Oct '08

Hello, I've released a new version of threadpool - it fiexes the broken pool::shutdown_now() and resets the scann counterin work_stealing after sleep or channel::take(). regards, Oliver

1 0