- Boost - lists.preview.boost.org

RE process (prospective from a retired FreeBSD committer)...
by Sean Chittenden 27 Jan '11

27 Jan '11

I originally sent this to Eric but am cleaning it up and reposting here per his suggestion. From an outsider's perspective it appears as though the lack of branching/merging tied to release management is the biggest issue for Boost at present. I'm a retired FreeBSD committer, I wanted to point out how the FreeBSD community deals with release engineering and see if there are a few nugget policies that could be cherry picked for boost. FreeBSD's process has been in place and refined for the last 15 years and comes with already written documentation as a starting point. It's not perfect, but there's a pound of prevention that comes via policy that no tool can replicate. head/trunk/tip is known as the -CURRENT branch. Released versions for production used (or are in prep for being released) are known as -STABLE branches. When FreeBSD 8 was being developed, people committed to HEAD (aka -CURRENT). When the re@ team called for a freeze for release and -CURRENT was in sufficiently good condition, they branched HEAD in to RELENG_8_STABLE. Everything in RELENG_8_* is expected to be production quality (or nearing it). Upon release of 8.0, RELENG_8 was branched again to RELEASE_8_0. 8.1, 8.2, etc were all created from RELENG_8_STABLE. Fixes for things in stable go to -CURRENT first, then are back patched to the appropriate stable releases, colloquially known as MFC's or Merge From -CURRENT. -CURRENT is the wild west of OS development and repo trash. Use at your own risk. Stability and likelihood of all tests passing is marginal, at best. Towards the end of a given major version -CURRENT becomes more stable, but once -STABLE has been branched it quickly degenerates some as people implement the impetus to checkin new features. -STABLE should always be passing 100% of the regression tests present in the branch at all times. A quick doc on merging between branches: http://wiki.freebsd.org/SVN_Merging I don't know how wide spread it is and despite svk having gone in to maintenance mode, use of svk has merit (partial checkouts): http://svk.bestpractical.com/view/HomePage http://www.freebsd.org/releng/ Anyway, the way that FreeBSD handles its permissions and merging from one branch to the next is via the commit message and commit hooks and approvals from different people wearing different hats. A few examples: http://lists.freebsd.org/pipermail/svn-src-stable/2011-January/008657.html has an MFC line in there to denote the changes included. The commit handler verifies that the diffed files largely match (at least it used to back in the day when I was committing via CVS). http://lists.freebsd.org/pipermail/svn-src-stable/2011-January/008683.html Reviewed by commit header. This gives greater latitude in terms of what can be included in the commit. http://lists.freebsd.org/pipermail/svn-src-stable/2011-January/008808.html And the 'Approved by' commit header. Once a release is frozen, all commits need to have this tag. The commit will fail without it and if someone commit with that line and didn't have permission to do so, as a policy, the commit is always reverted 100% of the time as a matter of principle. Frequently it's re-committed, but it's a big slap to the back of the hands to have to go through the process again. Needless to say, the commit mailing list is the most active and widely read list as a result. And tons of code gets reviewed with many eyes viewing it as a result. There are other bits worth noting, acls apply to different parts of the tree (doc-re vs src-re), but I don't know how many people actually follow boost's commit log on a per commit basis, but given 100% of all commits go to a single mailing list, it seems like the current list infrastructure makes that kind of review process unsustainable for Joe Reviewer (vs. the shorter abridged commit messages w/ a link to the actual diff). Lots of people fork FreeBSD to do experimental work out of the tree via git and hg, but the monolithic and serialized commit/review process seems to be working quite well from my perspective. A little bureaucratic but very stable and democratic without reliance on any one person to push the release forward. Anyway, food for thought. Hopefully there's something there that you can pick out of value. If you have questions, feel free to ask. -sc -- Sean Chittenden sean(a)chittenden.org

1 0

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

27 Jan '11

----- "Robert Stewart" <Robert.Stewart(a)sig.com> wrote : > > That's a bad analogy. std::auto_ptr was deprecated, but not in favor > of another std::auto_ptr but rather by std::shared_ptr. That's off-topic but I think you meant unique_ptr instead of shared_ptr. Ivan.

2 1

[V1.46] [Iterator] Ask for release notes modification
by Michel MORIN 27 Jan '11

27 Jan '11

Hi, I have some comments on the Boost 1.46 release notes for Boost.Iterator. (http://svn.boost.org/svn/boost/website/public_html/beta/feed/history/boost_…) Here are the release notes for Boost.Iterator: * fixed problem with `implicit_cast` ([@https://svn.boost.org/trac/boost/ticket/3645 #3645]) * added `function_input_iterator` ([@https://svn.boost.org/trac/boost/ticket/2893 #2893]) * `transform_iterator` now uses `boost::result_of` to determine functor result type ([@https://svn.boost.org/trac/boost/ticket/1427 #1427]) The first item seems OK :) The second item needs to be deleted, since `function_input_iterator` is not merged into release branch. The third item also needs to be changed. As the release notes say, `transform_iterator` now uses `boost::result_of` to determine functor result type (in prior versions, it uses `result_type`). But there is a bug: it should use `boost::result_of<Iterator::reference>` as the documentation says, but it uses `boost::result_of<Iterator::value_type>`. (This was fixed in trunk a week ago, but it was too late to merged to release.) This bug makes subtle errors and confuses the users. Is it better to mention the bug in the release notes explicitly? Something like: * BUG: `transform_iterator` uses `boost::result_of<Iterator::value_type>` to determine functor result type instead of `boost::result_of<Iterator::reference>` ([@https://svn.boost.org/trac/boost/ticket/1427 #1427]) Or simply delete this item? Regards, Michel

6 11

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

27 Jan '11

Artyom wrote : > > > > So you do not consider the fact the following code compiles (and > runs!) > > cleanly as a painful problem? > > > > std::string s = get_utf8_string(); > > s[42] = '?'; > > > > It is fine code. Why? Because if you assign s[42] you probably > know why you are do it and you most likely know that there is > a some ASCII character there. > I want more safety. And opacity is one way to it. I consider that stating "The code is OK because you know what you're doing" is an offense to all safety efforts put into C++ and its standard library. Sorry for the tone, but I failed to express my views in another way. Non throwing failures somewhat disturb me. Especially if you can design a failsafe interface. > > > I consider that std::string is cool as an internal for a > Boost.Locale > > implementor, not as a standard API for encoded strings that should > be > > used by all C++ developpers. > > > > Seems to me you hadn't seen Boost.Locale code and what does it > does. > I've seen it and toyed with it, and it's great. I have no problem with Boost.Locale, I have a problem with all the mess than can be done with the string type it has to publicly use today. And by the way, you're the one who stated that encoded string processing should be done by a domain expert library. I'm only exspecting you to translate this into : we need a more opaque string. Ivan

1 0

[threads] namespace & externs
by scot shinderman 27 Jan '11

27 Jan '11

Boosters, In boost/thread/src/pthread/thread.cpp we see extern "C" {} around code such as tls_destructor. Is this needed so it interfaces w/ native pthread local storage? When a vendor program is built against a specific version of boost it usually becomes necessary to isolate other users via a namespace. However, anything with extern "C" style defeats this. Aside from explicit linking to native c api's are there reasons for this; also what's considered the best style to isolate different versions -- currently we modify every header with a version-ed namespace wrapper. thanks! -s-

3 3

[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

[smart_ptr] Patch submitted for #1113
by Nathan Crookston 25 Jan '11

25 Jan '11

All, I submitted a patch for ticket #1113 [1] which allows statements like the following: boost::shared_array<int> pNonConst; boost::shared_array<const int> pConst = pNonConst; while preventing treating arrays polymophically. It has been tested on windows with VC8, VC10, g++3.X and g++4.X. Additionally it has been tested on solaris with g++3.4. I didn't modify the tests, but running them seems to produce the correct output. I'd appreciate it if someone could take a look at it, perhaps applying it if it looks good. Thanks, Nate [1] <https://svn.boost.org/trac/boost/ticket/1113>

1 0

Re: [boost] What's happened to Ryppl?
by Dave Abrahams 25 Jan '11

25 Jan '11

[Redirecting replies to the boost developers' list; we should have been there nearly from the beginning. Anyone who wants to see the earlier parts of the thread should look to http://groups.google.com/group/boostusers/browse_thread/thread/6d0d01eb3cac…] Hi Robert, Could you please use standard quoting? I am having trouble separating the parts you wrote below from what Eric wrote. Thanks, Dave At Tue, 25 Jan 2011 09:06:19 -0800, Robert Ramey wrote: > > Eric Niebler wrote: > > A lot of work remains --- that is, if it's also our intention to > modularize boost and have a functioning cmake build system, too. > > At least, modularization seems like it would be a good thing to do at the > same time. And nobody is working on a bjam system for modularized boost. > > *** I don't believe there is any reason to couple modularization of boost to > any particular build system. > I use bjam to build and test the serialization library on my local machine. > I just set the current directory to libs/serialization/test and run bjam > with some switches. This builds/updates the prerequisites to the > serialization library, builds the serialization library, then builds and > runs the tests. (and in my case builds a table of test results since i use > library status.sh). I'm would expect that I could the same with CTest. > > The key issue is that the build system permit the building of just one > "module" (and its necessary prerequisites). Bjam (and hopefully ctest) does > this now. Building of "all" of boost is just the building of each module. > Building of some alternative "distribution" is just the building of each of > the component modules (and their prequisites). There isn't even any reason > why each module has to use the same build system. > > <idle speculation> > Is it feasible to have both git and svn development going on > simultaneously? Two-way synchronization from non-modularized svn boost > to modularized git boost? Is that pure insanity? > </idle speculation> > > *** By the same token, a "modularized" boost needn't require that all > modules use the same source control system. Ideally, the build for each > module would use checkout/update the local copy of the module according to > the "configuration file" (...v2 or ctest.?). > > Once the procedure for for building a module is moved to the module rather > than invoked "from the top", modularization can proceed incrementally. > > Robert Ramey > > -- > > > _______________________________________________ > > Boost-users mailing list > > Boost-users(a)lists.boost.org > > http://lists.boost.org/mailman/listinfo.cgi/boost-users > > > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 0

[context] new version with stack-allocator
by Oliver Kowalke 25 Jan '11

25 Jan '11

boost vault contains a new version (0.4.0) where the user can provide its own stack allocator (the lib comes with a protected-stack allocator). Oliver

2 3

[context] build issue with context-0.3.5
by Charlls Quarra 25 Jan '11

25 Jan '11

Hi Oliver, First of all, thanks for updating your context library. I might be wrong, but i think yours is currently the only supported coroutine library for c++ which is a candidate for boost. So kudos to you for that effort that you are doing. I'm having a build error on the 0.3.5; (this is on ubuntu linux x86 platform) $ bjam -a -toolset=gcc cxxflags=-std=c++0x architecture=x86 instruction-set=i686 --with-context nBuilding the Boost C++ Libraries.nn ...patience... ...found 230 targets... ...updating 8 targets... gcc.compile.c++ bin.v2/libs/context/build/gcc-4.4.5/release/architecture-x86/instruction-set-i686/threading-multi/context_uc_posix.o In file included from libs/context/src/context_uc_posix.cpp:9: ./boost/context/context.hpp:24: error: variable ‘boost::contexts::BOOST_SYMBOL_EXPORT boost::contexts::context’ has initializer but incomplete type ./boost/context/context.hpp:26: error: expected primary-expression before ‘private’ ./boost/context/context.hpp:26: error: expected ‘}’ before ‘private’ ./boost/context/context.hpp:26: error: expected ‘,’ or ‘;’ before ‘private’ ./boost/context/context.hpp:27: error: expected unqualified-id before ‘private’ ./boost/context/context.hpp:27: error: expected constructor, destructor, or type conversion before ‘&’ token ./boost/context/context.hpp:32: error: expected constructor, destructor, or type conversion before ‘;’ token ./boost/context/context.hpp:34: error: expected unqualified-id before ‘public’ ./boost/context/context.hpp:41: error: typedef ‘boost::contexts::unspecified_bool_type’ is initialized (use decltype instead) ./boost/context/context.hpp:41: error: expected primary-expression before ‘)’ token ./boost/context/context.hpp:45: error: variable or field ‘unspecified_bool’ declared void ./boost/context/context.hpp:45: error: expected primary-expression before ‘)’ token ./boost/context/context.hpp:47: error: ‘context’ does not name a type ./boost/context/context.hpp:49: error: ‘context’ does not name a type ./boost/context/context.hpp:52: error: ‘context’ does not name a type ./boost/context/context.hpp:55: error: expected constructor, destructor, or type conversion before ‘;’ token ./boost/context/context.hpp:57: error: expected class-name before ‘(’ token ./boost/context/context.hpp:59: error: expected constructor, destructor, or type conversion before ‘(’ token ./boost/context/context.hpp:61: error: expected constructor, destructor, or type conversion before ‘&’ token ./boost/context/context.hpp:63: error: variable or field ‘jump_to’ declared void ./boost/context/context.hpp:63: error: ‘other’ was not declared in this scope ./boost/context/context.hpp:65: error: variable or field ‘swap’ declared void ./boost/context/context.hpp:65: error: ‘other’ was not declared in this scope ./boost/context/context.hpp:67: error: non-member function ‘bool boost::contexts::operator!()’ cannot have cv-qualifier ./boost/context/context.hpp:67: error: ‘bool boost::contexts::operator!()’ must have an argument of class or enumerated type ./boost/context/context.hpp:69: error: expected type-specifier before ‘unspecified_bool_type’ ./boost/context/context.hpp:73: error: variable or field ‘swap’ declared void ./boost/context/context.hpp:73: error: ‘context’ was not declared in this scope ./boost/context/context.hpp:73: error: ‘l’ was not declared in this scope ./boost/context/context.hpp:73: error: ‘context’ was not declared in this scope ./boost/context/context.hpp:73: error: ‘r’ was not declared in this scope ./boost/context/context.hpp:78: error: ‘contexts’ has not been declared ./boost/context/context.hpp:80: error: expected declaration before ‘}’ token ./boost/context/context.hpp:43: warning: ‘boost::contexts::default_stacksize’ defined but not used "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -march=i686 -pthread -fPIC -std=c++0x -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTEXT_DYN_LINK=1 -DNDEBUG -I"." -c -o "bin.v2/libs/context/build/gcc-4.4.5/release/architecture-x86/instruction-set-i686/threading-multi/context_uc_posix.o" "libs/context/src/context_uc_posix.cpp" ...failed gcc.compile.c++ bin.v2/libs/context/build/gcc-4.4.5/release/architecture-x86/instruction-set-i686/threading-multi/context_uc_posix.o... ...skipped <pbin.v2/libs/context/build/gcc-4.4.5/release/architecture-x86/instruction-set-i686/threading-multi>libboost_context.so.1.43.0 for lack of <pbin.v2/libs/context/build/gcc-4.4.5/release/architecture-x86/instruction-set-i686/threading-multi>context_uc_posix.o... ...skipped <pstage/lib>libboost_context.so.1.43.0 for lack of <pbin.v2/libs/context/build/gcc-4.4.5/release/architecture-x86/instruction-set-i686/threading-multi>libboost_context.so.1.43.0... ...skipped <pstage/lib>libboost_context.so for lack of <pstage/lib>libboost_context.so.1.43.0... gcc.compile.c++ bin.v2/libs/context/build/gcc-4.4.5/release/architecture-x86/instruction-set-i686/link-static/threading-multi/context_uc_posix.o gcc.archive bin.v2/libs/context/build/gcc-4.4.5/release/architecture-x86/instruction-set-i686/link-static/threading-multi/libboost_context.a common.copy stage/lib/libboost_context.a ...failed updating 1 target... ...skipped 3 targets... ...updated 4 targets... - Charles Quarra

2 2

[SQL-Connectivity] Is Boost interested in CppDB?
by Artyom 25 Jan '11

25 Jan '11

Hello, I have recently released a new SQL Connectivity library: General ------- Documentation : http://art-blog.no-ip.info/sql/cppdb/ Mirror Docs. : http://cppcms.sourceforge.net/sql/cppdb/ Download : https://sourceforge.net/projects/cppcms/files/cppdb/ Features -------- - Performance is the primary goal - make fastest possible SQL connectivity as possible - Transparent connection pooling support - Transparent prepared statements caching - Dynamic DB modules loading and optional static linking - Full and high priority support of FOSS RDBMS: MySQL, PostgreSQL, Sqlite3 - Support as many RDBMSs as possible via cppdb-odbc bridge - Simplicity in use - Locale safety - Support of both explicit verbose API and brief and nice syntactic sugar What it is not: --------------- This is not ORM library and not supposed to be so. This is something similar to what JDBC gives to JDK and QtSql gives to Qt and more. Boost Interest -------------- Currently I'm think whether should I boostify it, release it under BSL (currently it is LGPLv3) and submit it for formal review in boost or shouldn't I? Why do I ask, not because I'm thinking it is not good enough but rather because I feel that the "boostification" effort would be wasted at this point. For about half a year ago I had submitted a Boost.Locale for formal review, I use it under other namespace as part of CppCMS project all the time and in fact I receive most request and bug reports for Boost.Locale via CppCMS project and not via CppCMS.Locale so basically I have to handle two projects and synchronize between them all the time, and Boost.Locale is still stuck in review queue. So does it worth the effort? So before I do any steps forward may be it is better to make sure it gets (or even passes the review) and then boostify the library (which can be done very easily). Regards, Artyom

22 53

[assert][lightweight_test] Quick review of proposed changes
by Beman Dawes 24 Jan '11

24 Jan '11

In reviewing the "[assert] static_assert envy" thread, I agreed with Steven Watanabe: > MHO, the last thing we need is lots of minor variations that > don't add any real utility. KISS was also a factor, as I wanted to add only features that I would personally use right away, or that were needed for BOOST_ASSERT compatibility. It boiled down to the following: [assert] * Added BOOST_ASSERT_MSG(expr, msg) macro. If expr is false, outputs msg, then calls std::abort(). BOOST_DISABLE_ASSERTS behaves the same as in BOOST_ASSERT. BOOST_ENABLE_ASSERT_MSG_HANDLER enables a separate error handler. BOOST_ASSERT_MSG_OSTREAM defaults to std::cerr. User may define to specify a different output stream. * Added BOOST_ASSERT_MSG test cases to libs/utility/assert_test.cpp * Added BOOST_ASSERT_MSG docs to libs/utility/assert_test.cpp <boost/detail/lightweight_test.hpp> has the same Visual Studio output interleaving problem, so it makes sense to apply a similar fix at the same time. * Messages are now sent do BOOST_LIGHTWEIGHT_TEST_OSTREAM * BOOST_LIGHTWEIGHT_TEST_OSTREAM defaults to std::cerr. User may define to specify the output stream for messages. Updated files: http://mysite.verizon.net/beman/assert.hpp http://mysite.verizon.net/beman/assert.html http://mysite.verizon.net/beman/assert_test.cpp http://mysite.verizon.net/beman/lightweight_test.hpp Let's do a quick review before these get committed to trunk. Say until Monday morning. (They won't go in 1.46.0; far too late for that.) Comments welcome! --Beman

2 6

Boost.Graph Metagraph project
by Fernando J. Iglesias García 24 Jan '11

24 Jan '11

Hi all, I am new in Boost libraries and have heard about Boost.Graph and metaprograms. I think there is an ongoing project related called Metagraph. How can I get in collaboration with the people working on it? Regards, Fernando.

7 13

[container] documentation
by Gordon Woodhull 24 Jan '11

24 Jan '11

Hi Ion, I read over the documentation for Container. Looks like a neat library. I like the idea of a next gen STL in Boost. In the documentation, I think the recursive containers section could spell out what's going on here - I didn't catch it at first. It could just say "Recursive data structures contain elements of their own type." Perhaps with a link to http://en.wikipedia.org/wiki/Recursive_data_type. Pretty cool. Didn't this grow out of Interprocess? I'm wondering if it has somehow an improved contract with the allocator to support shared memory - or is that worth talking about? Cheers, Gordon

2 4

Re: [boost] [1.45][Serialization] fails to cross-compile usingarm-linux-uclibc toolchain
by Alex Potapenko 24 Jan '11

24 Jan '11

Robert Ramey wrote: > BOOST_STATIC_ASSERT(sizeof(class_id_type) == sizeof(int_least16_t)); > BOOST_STATIC_ASSERT(sizeof(class_id_reference_type) == > sizeof(int_least16_t)); These should be investigated. before commenting out. It could be detecting something unexpected in a pre-requisite library. I'm afraid I haven't neither got the knowledge, nor the skills to investigate it myself :( In case you (or someone else) are willing to investigate it for me, here's a relatively simple way to trigger these errors: 1. Checkout the optware trunk: $ svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware 2. Build the toolchain: $ cd optware; make mbwe-bluering-target $ cd mbwe-bluering; make directories toolchain ipkg-utils 3. Replace make/boost.mk from the svn with the one attached to this letter 4. Cross-compile: $ make boost # while remaining in the mbwe-bluering directory Thanks in advance, Alex

1 0

Re: [boost] [Boost-bugs] [Boost C++ Libraries] #5111: BOOST_TR1_STD_HEADER bad on Solaris 11/stdcxx4
by Bryce Lelbach 23 Jan '11

23 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 23 Jan 2011 20:39:12 -0000 "Boost C++ Libraries" <noreply(a)lists.boost.org> wrote: > #5111: BOOST_TR1_STD_HEADER bad on Solaris 11/stdcxx4 > > this is likely because stdcxx4 resides in > /usr/include/stdcxx4/ > /usr/include/stdcxx4/ansi > there, which the config_all.hpp does not take into account and sets > BOOST_TR1_STD_HEADER inappropriately This was fixed for Pathscale - John, could you please modify the fix I made for Pathscale to apply to any toolchain using the apache/rw stdlib? - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk08lxcACgkQ9cB/V3/s9EzcHwCdGCinVPCvyKbGDPs7LHa1DoIQ c3wAn1OO39wYkj1F5BmCSmjR7zW0oaGD =WQvl -----END PGP SIGNATURE-----

2 1