- Boost - lists.preview.boost.org

boost::program_options question - enabling multiple usage of the same switch
by Khaikin, Sergey 11 Oct '08

11 Oct '08

Hi, This question was originally brought up here: http://lists.boost.org/boost-users/2006/08/21633.php but unfortunately was not answered. What I basically want to do is to enable something like running $ myprog -v -v -v Where -v is some Boolean switch. Thanks, -Sergey --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

2 2

Re: [boost] [Review] Phoenix review results
by dan marsden 11 Oct '08

11 Oct '08

Joel de Guzman wrote: >Eric Niebler wrote: >> >> Joel de Guzman wrote: >>> Now it's time to grab a beer and celebrate :-) >> >> And to get (back) to work on Phoenix v3! ;-) Congrats. > >Part of Phoenix' success is due to the easy extension mechanism. >It would be super awesome if you can find some ways to simplify >V3 extension to something as easy as V2's. I intend to apply >whatever technique you can come up with to Spirit2. Yeah, I'm >not happy with its extension mechanism too. Nevertheless, I >am starting a Spirit 2.1 using Phoenix V3 as the model. I think the problem with the v2 extension mechanism is that we exposed how the expression templates were implemented. That left us with no choice but to make a breaking change in the extension mechanism between v2 and v3. IMO ideally any extension mechanism for v3 would not expose directly that proto is the underlying ET engine. I'm not sure how practical this will be to do though, as we may need a mass of indirection to avoid exposing proto directly? Cheers Dan

1 0

Re: [boost] [Review] Phoenix review results
by Eric Niebler 11 Oct '08

11 Oct '08

Joel de Guzman wrote: > Now it's time to grab a beer and celebrate :-) And to get (back) to work on Phoenix v3! ;-) Congrats. -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 1

[1.37.0][Test] Release branch Boost.Test failures?
by Beman Dawes 11 Oct '08

11 Oct '08

Boost.Test continues to fail ifstream_line_iterator_test on all platforms except Windows. http://beta.boost.org/development/tests/release/developer/test.html What's up? When will this be fixed or marked up as an expected failure? --Beman Running 2 test cases... ../libs/test/test/ifstream_line_iterator_test.cpp(35): error in "test_default_delimeter": check *it == "acv ffg" failed [acv ffg != acv ffg] ../libs/test/test/ifstream_line_iterator_test.cpp(38): error in "test_default_delimeter": check *it == "" failed [ != ] ../libs/test/test/ifstream_line_iterator_test.cpp(41): error in "test_default_delimeter": check *it == " " failed [ != ] ../libs/test/test/ifstream_line_iterator_test.cpp(63): error in "test_custom_delimeter": check *it == "\n{ d \n dsfg\n" failed [ { d dsfg != { d dsfg ] ../libs/test/test/ifstream_line_iterator_test.cpp(66): error in "test_custom_delimeter": check *it == "\n" failed [ != ] *** 5 failures detected in test suite "Master Test Suite"

2 2

Coroutines and Output Iterators
by Mathias Gaunard 11 Oct '08

11 Oct '08

When one wants to generate some range of data, the usual approach is to write the data to some output iterator passed as an argument. However, that approach has a few drawbacks: it is necessary to provide a range (often of a non-known size) to write the data on, and it will be possible to consider that data only once all elements have been copied to the output. An alternative approach is returning a smart range which will generate the elements as it is being iterated. It is somewhat what the Boost.Range update in the review queue does. This approach has many advantages, since storage may not be needed and transformations can be combined on top, avoiding unnecessary iterations. Writing smart iterators/ranges that generate data, though, is much more difficult than writing generators using the previous solution, especially in recursive scenarios where the iterators will need to maintain a stack themselves. Another solution is coroutines, which allows to return data then reenter later in the same context and keep going. The results of a coroutine can then be iterated as they come, giving the advantages of smart iterator/ranges while keeping the syntax of output iterators. It is however at the cost of some stack allocation at the beginning (which can be improved using pools) and context switches at each iteration. What I propose is thus to make an output iterator that will yield the data within a coroutine context. With that solution, one writes generators as functions writing to output iterators, but those iterators might as well be writing to containers than actually yielding the result, which means the person designing the generator does not have the overhead of coroutines forced upon him. The syntax would be generate(boost::bind(&boost::transform, range, _1, f)) which would return a range similar to that of boost::make_transform_range(range, f). (boost::transform being just std::transform for ranges) The coroutine GSoC library from 2006 does offer that kind of thing, but not as non-intrusive output iterators. (I don't even get why it needs to call self.__self_exit__() at the end). I thus propose a simple output iterator that yields on iteration be made. By the way, what is the status of that library? I haven't heard of it for quite a while.

4 5

[multi_array] Slices, views and sub_arrays
by Robert Jones 10 Oct '08

10 Oct '08

Hi All I'm still plugging away at trying to make use of multi_array, but I seem to be having a few problems! I suspect my understanding of the basic paradigm is flawed. I'm bit confused about views and slices. If I start with a rectangular, 2 dimensional grid, take a view of the whole grid, and then use a single subscript to index into that view, then I expected the result to be a view of one less dimension then the original view. However, it seems to be a "sub_array". #include "boost/multi_array.hpp" struct Cell { int i; }; int main( ) { typedef boost :: multi_array_types :: index_range range; boost :: multi_array< Cell, 2 > grid( boost :: extents[ 9 ][ 9 ] ); boost :: multi_array< Cell, 2 > :: const_array_view< 2 > :: type const_grid_view = grid[ boost :: indices[ range( ) ][ range( ) ] ]; boost :: multi_array< Cell, 2 > :: const_array_view< 1 > :: type const_row_view = const_grid_view[ 5 ]; return 0; } The error message from the last assignment is this sample.cpp: In function `int main()': sample.cpp:13: error: conversion from `boost::detail::multi_array::const_sub_array<Cell, 1u, const Cell*>' to non-scalar type `boost::detail::multi_array::const_multi_array_view<Cell, 1u, const Cell*>' requested which seems to confirm I've got all my consts and dimensions correct. So, why is this wrong? Also, does the return type of sub_array, rather than array_view, mean that the contents of the relevant cells have been copied? Thanks - Rob.

2 1

[website] libs/* --> doc/libs/BOOST_VERSION/libs/* rewriting rule
by joaquin＠tid.es 10 Oct '08

10 Oct '08

Hello, The website PHP is devised in such a way that documentation URLs are automatically rewritten to point to the specific Boost version most recently shipped. For instance, if I type the following in my browser: http://www.boost.org/libs/smart_ptr/smart_ptr.htm I get the following redirection: http://www.boost.org/doc/libs/1_36_0/libs/smart_ptr/smart_ptr.htm This is fine in that it allows us to keep a historic record of documentation across Boost versions. My little complain is that the automatic redirection makes it all too easy to inadvertently use version-specific URLs when referring to Boost docs in external contexts (blogs, forums, etc.) This is in my opinion unfortunate because such URLs are stuck in time and do not reflect the evolution of the library. Of course it's easy to get to the most recent info, but untrained eyes might miss the detail and take the version-specific URL for the most updated reference. A simple Google search (http://tinyurl.com/42ufrn ) reveals that these version-specific URLs are beginning to proliferate. Maybe is it a good idea to not apply this redirection and instead serve the most updated docs for non-version-labeled URLs? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Getting the types of arguments for a bind.
by Michael Marcin 10 Oct '08

10 Oct '08

I want to take a boost::bind functor and get the type of its arguments. I can't find any sort of introspection api documented. I tried using mpl but what I came up with doesn't seem to work. Is there a way to do this? A distilled version of my failed attempt follows #include <boost/bind.hpp> #include <boost/mpl/find.hpp> #include <boost/type_traits/function_traits.hpp> template< typename Function, int N > struct arg_n; template< typename Function > struct arg_n< Function, 1 > { typedef typename boost::function_traits< Function >::arg1_type type; }; template< typename Callback, int ArgN > struct arg_type; template< typename Return, typename Signature, typename Args, int ArgN > struct arg_type< boost::_bi::bind_t<Return,Signature,Args>, ArgN > { typedef typename boost::mpl::find< Args, boost::arg<ArgN> >::type iter; // +1 for 0 based find vs 1 based arguments typedef typename arg_n<Signature,iter::pos::value + 1>::type type; }; void foo( int a ) {} template< typename Callback > void bar( Callback cb ) { // trivial usage typedef typename arg_type< Callback, 1 >::type ArgType; cb( ArgType() ); } int main() { bar( boost::bind(&foo,_1) ); } Thanks, -- Michael Marcin

2 1

[shared_ptr] Why operator< uses internal_less?
by dariomt＠gmail.com 10 Oct '08

10 Oct '08

I see that operator== and operator!= are implemented comparing the pointer inside the shared_ptr's using get(), but operator< uses _internal_less, that does a different thing. I thought that operator< would also be implemented using get(), so please, can you share the rationale behind the need for _internal_less? TIA

7 6

[1.37] Trivial but Boost wide patch?
by John Maddock 10 Oct '08

10 Oct '08

There's a problem in 1.37 as it stands in that: * If Boost.TR1 is in the include path, and, * A Boost header is included that includes <cmath>. Then the TR1 version of <cmath> gets included. This is relatively harmless on *nix platforms - except for somewhat longer compile times - but for windows compilers that support auto-linking then the headers want to link to the math TR1 libraries even if the user is actually using a header only library like spirit for example. This is the subject of bug report: http://svn.boost.org/trac/boost/ticket/2392. There is a trivial fix, which is to replace #includes of <cmath> with <boost/config/no_tr1/cmath.hpp>: I've just applied this to Trunk (so you know who to blame if this causes any issues!), but should this be applied to the release branch as well? Changeset here: http://svn.boost.org/trac/boost/changeset/49254/trunk Regards, John.

2 1

[graph] compilation broken when mpi enabled
by Juergen Hunold 10 Oct '08

10 Oct '08

Hi ! It seems that change 49178 http://svn.boost.org/trac/boost/changeset/49178 broke compilation of Boost.Graph when mpi is configured. That might be the reason the regression tests are still green. (Would be nice if the Graphiz Loader had some UnitTests, too ;-)) This commit changed libs/graph/build/Jamfile.v2 to contain: > + > +############################################################ > +# Distributed-memory parallel graph library (Parallel BGL) # > +############################################################ > +use-project /boost/mpi : ../../mpi/build ; > +import mpi ; > +if [ mpi.configured ] > +{ It seems that Doug committed some local changes by accident. Please add either the missing files or revert libs/graph/build/Jamfile.v2. 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 1

[1.37][mpl] Merge gcc 4.4 fix.
by Daniel James 10 Oct '08

10 Oct '08

Hi, It it okay to merge the mpl part of this change to release? http://svn.boost.org/trac/boost/changeset/48960/ It fixes a preprocessor error in gcc 4.4 which stops a lot of libraries from working with that compiler. The python part of the patch isn't required, the error is due to mpl's preprocessed headers not including the boost preprocessor headers and doesn't occur in other libraries that use iteration, as they always include the headers. I've had a look through the test results and everything seems to be working. Daniel

2 1

[accumulators] Dependent and sliding accumulatos_set
by vicente.botet 10 Oct '08

10 Oct '08

Hi, The acuumulator library allows to determine dependency between accumulator, but not between accumulator_sets. I would like to define an accumulator_set c so when we cumulate in two others c1 and c2 accumulator_set we cumulate also in c, some thing like typedef dependable_acumulator_set <double, ...> dependable_acc_type; dependable_acc_type c1, c2; dependable_acc_type c=c1+c2 dependable_acc_type c3; c+=c3; c1(1); c2(1); c3(2); assert(count(c)==3); assert(sum(c)==4); How dependable_acumulator_set can be defined? Here follows the interfaces of such a class and the pseudo code, I've named the class dependable_acumulator_set, sorry but I have not found a shorter and better name (may be observed/listened?) template <typename T, typename F, typename W> class dependable_acumulator_set : public acumulator_set<T,F,W> { public: dependable_acumulator_set(); void add_dependent(dependable_acumulator_set&); void remove_dependent(dependable_acumulator_set&); template<typename A1> void operator ()(A1 const &a1) { for (acc in dependents) { acc(a1); } this->acumulator_set_type::operator()(a1); } dependable_acumulator_set<T,F,W>& operator+=(dependable_acumulator_set<T,F,W>); dependable_acumulator_set<T,F,W>& operator-=(dependable_acumulator_set<T,F,W>); }; template <typename T, typename F, typename W> dependable_acumulator_set<T,F,W> operator+()(dependable_acumulator_set<T,F,W>,dependable_acumulator_set<T,F,W>); In addition I would like to be able to cummulate on a sliding window, e.g. on the last N cummulated values. I have see the tail accumulator, but I dont know how to define a min_tail accumulator with the current framework. I would like a class that behaves like: typedef sliding_acumulator_set <double, ...> sliding_acc_type; sliding_acc_type c(window=2); c(1); c(5); c(2); assert(count(c)==3); assert(sum(c)==7); assert(min(c)==2); We can state the sliding window at compile (template parameter) or run time (constructor parameter). template <std::size Window, typename T, typename F, typename W> class static_sliding_acumulator_set; template <typename T, typename F, typename W> class sliding_acumulator_set; Of course the complexities of the sliding accumulators operations is increased. Of course it will be interesting to have a sliding dependable accumulater set. It would be great to integrate these features on a unique class (accumulator_set?) in a clean way. template <typename T, typename F, typename W, typename DependablePolicy, typename SlicingPolicy> class acumulator_set; Please let me know if this can be done in a better way. Is there any interest on these features? Eric, what do you think? Best, Vicente

1 0

[wave] disabling msvc warnings
by Jürgen Hunold 09 Oct '08

09 Oct '08

Hi ! The current Jamfile for building Wave disables MS "secure" STL and C-Runtime warnings only for msvc-8.0. Please find a patch attached which removes the toolset version and thus eliminates the warnings for 9.0 (and above too). Rationale: Those "features" are not likely to disappear and mvsc version less than 8.0 are slowly dying out. Okay to commit ? And merge to release ? Or use an extra check for 9.0 ? 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 !

3 7

1.37 release schedule?
by John Maddock 09 Oct '08

09 Oct '08

Are we on time for the 1.37 release? I notice that the deadline for routine changes passed without any comment (or most of us noticing I suspect). Just checking up on where we are, Cheers, John.

11 20

is_range metafunction
by Neal Becker 09 Oct '08

09 Oct '08

I could use one to enable a range constructor only where appropriate: class X { template<typename range_t> X (range_t const&, enable_if<is_range<range_t> >::type *dummy=0) Question is, what might 'is_range' look like?

7 26

Math Toolkit Distribution Explorer - Windows program now available for download from SourceForge
by Paul A Bristow 09 Oct '08

09 Oct '08

Although the source is included in the Math Toolkit in Boost release, it may be helpful to know that a pre-built package is now available for download from Sourceforge, so I trust it is in order to announce it here. http://sourceforge.net/projects/distexplorer/ Distribution Explorer is a mixed C++ and C# application that allows you to explore the properties of various statistical distributions, and calculate the Cumulative Distribution Function CDF, Probability distribution Function PDF, or quantiles/percentiles. Written using open-source C++ from the http://www.boost.org Boost Math Toolkit library. Some sample screenshots are available which will allow to you to decide if it will cover the statistical distribution you are interested in. There are no pretty pictures :-( but the numbers are rather accurate :-) Download Instructions The Distribution Explorer is distributed as a single Windows Installer package Setupdistex.msi zipped to distexplorer.zip. Download this file and unzip to a temporary location of your choice, for example your desktop, and run setupdistex.msi. This will install a program executable, boost_math.dll and an icon to your Program files/Boost/Distex/ folder (unless you chose another location) and add a shortcut to your Start, Programs menu. If you are updating, you must remove the previous version first using Control Panel. Add/Remove programs. (Note that Microsoft .NET Framework 2.0 and VCredist are requirements for this program. Most recent and updated Windows environments will already have these, but they are quickly, easily and safely installed from the Microsoft site if required.) Enjoy. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow(a)hetp.u-net.com

1 0

[multi_array] Access a view's index_range
by Robert Jones 09 Oct '08

09 Oct '08

How do I access the index_range of an array_view? ie., typedef boost::multi_array<Cell,2 > Grid; Grid grid( boost::extents[9][9]); Grid::array_view<2> view = grid[indices[range(), range()]]; for (Grid::index i = view.?????.start(); i != view.?????.finish(); ++i) {....} where I'm expecting i to take values 0..8 inclusive. Thanks - Rob.

1 0

Autolinking not working in Windows x64 cross-compile environment
by Dave Barnett 09 Oct '08

09 Oct '08

All: I have taken the Boost 1.33.1 distribution [we have to stay with this for consistency with our Linux build...], along with the extra information here ( http://en.allexperts.com/q/C-1040/Building-boost-libraries-64.htm ) and been able to generate the Boost libraries using the X64 compiler on a machine running Windows XP Pro 64. I have taken the compiled libraries and copied them to our 32-bit XP Pro build machine for use in an X64 cross-compile environment. [We working on setting up a native X64 build machine, but it is a work in progress....] When I try to link, I get the list of unresolved symbols below. We use a command-line tool to do our builds, which calls "cl", "lib", "mt", and "link" directly. If I modify the link file passed to "link" such that it adds "s:\....\libboost_thread-vc80-mt-1_33_1.lib [which is the one dumpbin shows our object wants....], our DLL (omega_runtime) will link successfully. So, to my untrained eye [I'm new to building on Windows....] it looks like there is something wrong with the autolink magic. During the compilation, we do have "/DBOOST_ALL_DYN_LINK" set. Adding "/DBOOST_THREAD_USE_DLL" doesn't change anything. Does anyone have any suggestions for me on why this might be the case, or how to track it down? I have added the lib directory to both LIB and LIBPATH but that doesn't appear to change the situation. Thanks in advance. Cheers, Dave Creating library com\westerngeco\omega\runtime\omega_runtime.lib and object com\westerngeco\omega\runtime\omega_runtime.exp Thread.obj : error LNK2019: unresolved external symbol "public: __cdecl boost::mutex::mutex(void)" (??0mutex@boost@@QEAA@XZ) referenced in f unction "void __cdecl com::westerngeco::omega::runtime::`anonymous namespace'::classInit(void)" (?classInit@?A0xe5577335@runtime@omega@weste rngeco@com@@YAXXZ) ResourceUsage.obj : error LNK2001: unresolved external symbol "public: __cdecl boost::mutex::mutex(void)" (??0mutex@boost@@QEAA@XZ) Thread.obj : error LNK2019: unresolved external symbol "void __cdecl boost::call_once(void (__cdecl*)(void),long &)" (?call_once@boost@@YAXP 6AXXZAEAJ@Z) referenced in function "public: static int __cdecl com::westerngeco::omega::runtime::Thread::currentGroup(void)" (?currentGroup @Thread@runtime@omega@westerngeco@com@@SAHXZ) Thread.obj : error LNK2019: unresolved external symbol "public: void * __cdecl boost::detail::tss::get(void)const " (?get@tss@detail@boost@@ QEBAPEAXXZ) referenced in function "public: class com::westerngeco::omega::runtime::ThreadHandle * __cdecl boost::thread_specific_ptr<class com::westerngeco::omega::runtime::ThreadHandle>::get(void)const " (?get@?$thread_specific_ptr@VThreadHandle@runtime@omega@westerngeco@com@@@ boost@@QEBAPEAVThreadHandle@runtime@omega@westerngeco@com@@XZ) Thread.obj : error LNK2019: unresolved external symbol "public: void __cdecl boost::detail::tss::cleanup(void *)" (?cleanup@tss@detail@boost @@QEAAXPEAX@Z) referenced in function "public: void __cdecl boost::thread_specific_ptr<class com::westerngeco::omega::runtime::ThreadHandle> ::reset(class com::westerngeco::omega::runtime::ThreadHandle *)" (?reset@?$thread_specific_ptr@VThreadHandle@runtime@omega@westerngeco@com@@ @boost@@QEAAXPEAVThreadHandle@runtime@omega@westerngeco@com@@@Z) Thread.obj : error LNK2019: unresolved external symbol "public: void __cdecl boost::detail::tss::set(void *)" (?set@tss@detail@boost@@QEAAXP EAX@Z) referenced in function "public: void __cdecl boost::thread_specific_ptr<class com::westerngeco::omega::runtime::ThreadHandle>::reset( class com::westerngeco::omega::runtime::ThreadHandle *)" (?reset@?$thread_specific_ptr@VThreadHandle@runtime@omega@westerngeco@com@@@boost@@ QEAAXPEAVThreadHandle@runtime@omega@westerngeco@com@@@Z) Thread.obj : error LNK2019: unresolved external symbol "public: __cdecl boost::lock_error::lock_error(void)" (??0lock_error@boost@@QEAA@XZ) referenced in function "public: void __cdecl boost::detail::thread::scoped_lock<class boost::mutex>::lock(void)" (?lock@?$scoped_lock@Vmutex @boost@@@thread@detail@boost@@QEAAXXZ) ResourceUsage.obj : error LNK2001: unresolved external symbol "public: __cdecl boost::lock_error::lock_error(void)" (??0lock_error@boost@@QE AA@XZ) Thread.obj : error LNK2001: unresolved external symbol "public: virtual __cdecl boost::lock_error::~lock_error(void)" (??1lock_error@boost@@ UEAA@XZ) ResourceUsage.obj : error LNK2001: unresolved external symbol "public: virtual __cdecl boost::lock_error::~lock_error(void)" (??1lock_error@ boost@@UEAA@XZ) Thread.obj : error LNK2019: unresolved external symbol "public: virtual __cdecl boost::thread_exception::~thread_exception(void)" (??1thread _exception@boost@@UEAA@XZ) referenced in function "public: virtual void * __cdecl boost::thread_exception::`scalar deleting destructor'(unsi gned int)" (??_Gthread_exception@boost@@UEAAPEAXI@Z) ResourceUsage.obj : error LNK2001: unresolved external symbol "public: virtual __cdecl boost::thread_exception::~thread_exception(void)" (?? 1thread_exception@boost@@UEAA@XZ) Thread.obj : error LNK2001: unresolved external symbol "public: virtual char const * __cdecl boost::lock_error::what(void)const " (?what@loc k_error@boost@@UEBAPEBDXZ) ResourceUsage.obj : error LNK2001: unresolved external symbol "public: virtual char const * __cdecl boost::lock_error::what(void)const " (?w hat@lock_error@boost@@UEBAPEBDXZ) Thread.obj : error LNK2019: unresolved external symbol "private: void __cdecl boost::mutex::do_lock(void)" (?do_lock@mutex@boost@@AEAAXXZ) r eferenced in function "public: static void __cdecl boost::detail::thread::lock_ops<class boost::mutex>::lock(class boost::mutex &)" (?lock@? $lock_ops@Vmutex@boost@@@thread@detail@boost@@SAXAEAVmutex@4@@Z) ResourceUsage.obj : error LNK2001: unresolved external symbol "private: void __cdecl boost::mutex::do_lock(void)" (?do_lock@mutex@boost@@AEA AXXZ) Thread.obj : error LNK2019: unresolved external symbol "private: void __cdecl boost::mutex::do_unlock(void)" (?do_unlock@mutex@boost@@AEAAXX Z) referenced in function "public: static void __cdecl boost::detail::thread::lock_ops<class boost::mutex>::unlock(class boost::mutex &)" (? unlock@?$lock_ops@Vmutex@boost@@@thread@detail@boost@@SAXAEAVmutex@4@@Z) ResourceUsage.obj : error LNK2001: unresolved external symbol "private: void __cdecl boost::mutex::do_unlock(void)" (?do_unlock@mutex@boost@ @AEAAXXZ) Thread.obj : error LNK2019: unresolved external symbol "private: void __cdecl boost::detail::tss::init(class boost::function1<void,void *,cl ass std::allocator<class boost::function_base> > *)" (?init@tss@detail@boost@@AEAAXPEAV?$function1@XPEAXV?$allocator@Vfunction_base@boost@@@ std@@@3@@Z) referenced in function "public: __cdecl boost::detail::tss::tss(class boost::function1<void,void *,class std::allocator<class bo ost::function_base> > *)" (??0tss@detail@boost@@QEAA@PEAV?$function1@XPEAXV?$allocator@Vfunction_base@boost@@@std@@@2@@Z) Thread.obj : error LNK2019: unresolved external symbol "public: __cdecl boost::thread_resource_error::thread_resource_error(void)" (??0threa d_resource_error@boost@@QEAA@XZ) referenced in function "public: __cdecl boost::detail::tss::tss(class boost::function1<void,void *,class st d::allocator<class boost::function_base> > *)" (??0tss@detail@boost@@QEAA@PEAV?$function1@XPEAXV?$allocator@Vfunction_base@boost@@@std@@@2@@ Z) Thread.obj : error LNK2001: unresolved external symbol "public: virtual __cdecl boost::thread_resource_error::~thread_resource_error(void)" (??1thread_resource_error@boost@@UEAA@XZ) Thread.obj : error LNK2001: unresolved external symbol "public: virtual char const * __cdecl boost::thread_resource_error::what(void)const " (?what@thread_resource_error@boost@@UEBAPEBDXZ) lib\omega_runtime.dll : fatal error LNK1120: 15 unresolved externals Error status returned = 1120

2 1

[1.37.0] Release schedule added to Development page
by Beman Dawes 09 Oct '08

09 Oct '08

The calendar with the release schedule appears on the web site's Community page, but that isn't the first place a developer is likely to look. So I've added a copy on the Development page. See http://www.boost.org/development/index.html. The "Month" or "Agenda" tabs provide useful views. The time zone shown is US Central Time. I guess that's because its Rene's time zone, and he created the calendar. It might be better if it were UTC, but I'll leave that up to Rene. --Beman

2 1

1.37: Boost.Pool fixes to be merged to release?
by Chris Newbold 08 Oct '08

08 Oct '08

I've fixed a couple of minor issues in Boost.Pool over the course of the last week and submitted to trunk. Can/should I go ahead and merge these to release? -Chris

2 1

Known 1.36 bugs
by Johan Torp 08 Oct '08

08 Oct '08

Is there a list of known 1.36 bugs? Or can someone please point me to the most serious ones? Best Regards, Johan Torp www.johantorp.com -- View this message in context: http://www.nabble.com/Known-1.36-bugs-tp19878713p19878713.html Sent from the Boost - Dev mailing list archive at Nabble.com.

3 2

[multi_array] Finding array bounds.
by Robert Jones 08 Oct '08

08 Oct '08

I'm trying to write this piece of code struct Cell { .... }; typedef boost :: multi_array< Cell, 2 > Grid; void f( Grid & grid ) { for ( Grid::index i=grid.?????(); i!=grid.????(); ++i ) { ..... } } where the intention is to iterate over the first subscript of the multi_array. I can see that index_range has start() and finish() methods, but I can't see how to extract the first index_range from the multi_array. Thanks - Rob.

1 0

[phoenix] Phoenix & 1.37
by Robert Jones 08 Oct '08

08 Oct '08

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? - Rob.

2 1

config.hpp
by Joel Falcou 08 Oct '08

08 Oct '08

I'm digging up a previous topic of mine : http://article.gmane.org/gmane.comp.lib.boost.user/39236/match=config Basically, is it possible to consolidate the boost/config headers so they provide a macro usable in #ifdef and such so we can use Boost comprehensive platform/compiler tests in library ? I know some are already usable (like testing for BOOST_MSVC and such) but it lacks in some area like platform. My proposal is the following : For platform, stdlib and compiler config flag, add a macro called respectively : BOOST_ACTIVE_PLATFORM_CONFIG BOOST_ACTIVE_STDLIB_CONFIG BOOST_ACTIVE_COMPILER_CONFIG That contains a numeric value that identify the current chosen configuration. For each type of configuration, files called boost/config/platform_list.hpp,boost/config/stdlib_list.hpp and boost/config/compiler_list.hpp are provided. Those files contains the global list of possible active configuration and give them proper usable symbol. eg : platform_list.hpp #ifndef __BOOST_CONFIG_PLATFORM_LIST_HPP__INCLUDED__ #define __BOOST_CONFIG_PLATFORM_LIST_HPP__INCLUDED__ #define BOOST_AIX_PLATFORM_CONFIG 100 #define BOOST_AMIGAOS_PLATFORM_CONFIG 101 /// and so on ... #define BOOST_WIN32_PLATFORM_CONFIG 111 #define BOOST_UNKNOWN_PLATFORM_CONFIG 999 #endif Then in win32.hpp, the following definition is provided : #define BOOST_ACTIVE_PLATFORM_CONFIG BOOST_WIN32_PLATFORM_CONFIG In user code, it can be checked like this : #if (BOOST_ACTIVE_PLATFORM_CONFIG == BOOST_WIN32_PLATFORM_CONFIG) // Some Win32 code #else // some other code for non-win32 #endif Does this sound useful or am I overlooking some already existing boost system that may already do this ?

1 0