January 2011 - Boost - lists.preview.boost.org

[function_types] Determining whether a type is a function_types tag type
by Edward Diener 26 Jan '11

26 Jan '11

Is there any way to determine at compile-time whether a type is a function_types tag type ? It seems that there are too many possibilities, both the single named tag types and the combination 'tag' template.

1 0

Re: [boost] [string] proposal
by Ivan Le Lann 26 Jan '11

26 Jan '11

----- "Nevin Liber" <nevin(a)eviloverlord.com> wrote : > On 21 January 2011 11:56, Dean Michael Berris > <mikhailberis(a)gmail.com>wrote: > > > No changing arbitrary content in the string. Concatenation is a > > process of creating new strings. > > > > Ultimately the underlying string should be efficient > > > Please describe how you are going to make this efficient, if > concatenation > effectively requires an allocation (once past the small string > optimization) > and a copy. > Isn't rope worth a try here ? Ivan.

4 5

Review request: auto-index tool
by John Maddock 26 Jan '11

26 Jan '11

I'm not sure if we're doing reviews of tools - we haven't in the past - but I thought it would be good to get feedback anyway... Auto-index is a tool for semi-automating the task of adding an index to quickbook/boostbook/doxygen/docbook documentation. Auto-index acts at the docbook level to scan for terms in a concordance script-file, but can also scan headers for classes, typedefs, functions and macros to index and a lot more besides. Auto-index supports multiple indexes (for example class, function, macro and typedef indexes out of the box), and can either delegate the actual index formatting to the XSL stylesheets, or produce the index itself (faster, also better looking for HTML indexes). Code is in the sandbox under tools/auto_index, documentation can be viewed online at: http://svn.boost.org/svn/boost/sandbox/tools/auto_index/doc/html/index.html Currently the math, type_traits and spirit libraries are using this tool in trunk to produce indexes - take a look at those libraries to see the sort of indexes produced. Cheers, John.

10 23

[mpi] Naming of Python extension
by Vladimir Prus 26 Jan '11

26 Jan '11

At present, when both mpi and python are configured/detected, Boost.MPI tries to build a python extension which is named, on Linux, mpi.so. When building with --build-type=complete, an attempt to build that file with several properties is made, which Boost.Build detects and complains about. This was the case for several releases, and nobody seemed to care, but it's still not good. So, could Boost.MPI maintainers express their preference for either: - Building one variant of mpi.so, no matter what, in which case what variable (debug/release, single/multi threaded)? - Building several, differently named or installed in different places, variants of mpi.so Thanks, Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40

2 2

Intel on Win32 and C++0x support?
by John Maddock 25 Jan '11

25 Jan '11

Can anyone with Intel on Win32 let me know whether the compiler supports any C++0x features in default MSVC compatibility mode, in case it helps the Linux compiler appears to have: static_asserts v11 and later rvalue refs and delctype v12 and later but only when -std=c++0x is set. Thanks, John.

2 1

[process] Arguments and Context concepts
by Vicente Botet 25 Jan '11

25 Jan '11

Hi, Where can I find the concept behind the template parameters Arguments and Context in template<typename Arguments, typename Context> child create_child(const std::string & executable, Arguments args, Context ctx); Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/process-Arguments-and-Context-concepts-t… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 9

[V1.46][Spirit] request for late minute changes to release branch
by Hartmut Kaiser 25 Jan '11

25 Jan '11

Hey release managers, With the upcoming Boost release, we were planning to release a new feature in Spirit (a dynamic data structure called utree) and everything seemed to be fine. Unfortunately, we now discovered a flaw in the design of the new code, which shows up under certain circumstances. The fix for that problem changes the semantics of the utree/Spirit integration considerably. Releasing utree now without being fixed means breaking its semantics with the next release. That is something we would like to avoid. We have two options: a) fix it now, possibly delaying the release for a couple of days (until the tests have cycled), or b) pull utree from the release branch, which mainly means removing files and adapting the test Jamfiles Neither a) nor b) would have any consequences for other Boost code and both are purely local to Spirit. What would you suggest? Regards Hartmut --------------- http://boost-spirit.com

7 24

[1.46.0] Beta status
by Beman Dawes 25 Jan '11

25 Jan '11

We are holding for a Boost Build merge. As soon as that's done, and tests cycled, AFAIK we are ready for the beta. If anyone is aware of any other showstoppers, please let us know right away. Thanks, --Beman

2 1

[config][pathscale] Configurations for older versions
by Daniel James 25 Jan '11

25 Jan '11

Looking at the failures for patchscale, they seem to be happening because the configuration is only set for '__PATHCC__ >= 4' and tests are run using Pathscale 3.2. This is a new configuration file so I think we should revert it on the release branch and try to fix it on trunk for 1.47. I don't know anything about the compiler, but for a start I think we should at least set the 'BOOST_NO_' macros for all versions. Does that sound reasonable? Daniel

4 8

GSoC 2011 - Do we need to starting thinking about it?
by Paul A. Bristow 25 Jan '11

25 Jan '11

I recall that last year, Boost didn't start thinking about possible projects to suggest to potential GsoCoders until rather late. Perhaps we should *start* thinking reasonably soon? Is someone going to take on the task of setting up a Google Group to solicit and discuss ideas? Paul PS I'm not volunteering! PPS But I do have an idea ;-) --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

9 21