- Boost - lists.boost.org

[context] future design
by Oliver Kowalke 07 Apr '11

07 Apr '11

Hello, modifications I've made: - context: - stack unwinding: bool context::finished() const indicating that the called function has finished -> stack already unwinded boid context::unwind_stack() jump back into context and throw a special exception -> stack will be unwinded (requires that no try/catch(...) was used) - context is now moveable - is not a template == the stack type is only passed/known in the templated ctor - the function to be called by the context is not saved on top of the stack - exceptions replaced by assertions / exceptions.hpp removed - fcontext_t used as default implementation; ucontext_t only fallback for platforms not supported by fcontext_t - on Windows Win Fiber API is used as default - protected stack: - keyword explicit added to ctor - public static members min_stacksize, max_stacksize, default_stacksize - fcontext_t renamed to boost_fcontext_t, boost_fcontext_get(), boost_fcontext_set(), boost_fcontext_jump(), boost_fcontext_make() - i386 ASM preserves SSE2 control/status word - x86 ASM uses indirect jump for boost_fcontext_set() and boost_fcontext_jump() code is available at git://git.gitorious.org/boost-dev/boost-dev.git branch context-dev. @Vicente: could you check your SPAM filter , please (I've send several eMails to you). best regards, Oliver

1 0

Re: [boost] [range] for_each and std::map of std::list
by Thorsten Ottosen 07 Apr '11

07 Apr '11

Den 07-04-2011 11:37, Mathias Gaunard skrev: > On 06/04/2011 19:55, Thorsten Ottosen wrote: >> I suggest the syntax >> >> rngOfContainers | boost::adaptors::flattened >> >> and the underlying iterator should be up to bidirectional (if the >> underlying two container types support it). >> >> Anyone interested in implementing this? > > I have an implementation of this somewhere. > > One annoying thing is that you cannot detect that a type is a range > reliably. Well, that is only a problem if you want to avoid manually applying the adaptor twice (or more), right? If so, I think that is a limitation we can live with. A simple solution covers most cases IMO. -Thorsten

1 0

mismatched versions of Boost.Build engine and core
by Paul A. Bristow 07 Apr '11

07 Apr '11

I've got this message after running a bjam warning: mismatched versions of Boost.Build engine and core warning: Boost.Build engine (bjam) is 03.1.19 warning: Boost.Build core (at I:/boost-trunk/tools/build/v2) is 2011.04-svn Should I worry about this? I've tried to re-build using I:\boost-trunk\tools\build\v2\engine>bjam --toolset=msvc >build_bat.log but it still complains ### No toolset specified. Please use --toolset option. Is this supposed to be --toolset=msvc or --toolset msvc Suggestions? Thanks Paul PS This bit of the doc didn't seem right be me "For the Boost.Jam source included with the Boost distribution the jam source location is BOOST_ROOT/tools/jam/src." and was suggesting running build.bat I:\boost_1_46_0\tools\build\v2\engine\src contained build.bat and build.jam --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

4 4

Re: [boost] [shifted_ptr] Review Request
by Olaf van der Spek 07 Apr '11

07 Apr '11

On Wed, Apr 6, 2011 at 7:22 PM, Phil Bouchard <phil(a)fornux.com> wrote: > > > On 4/6/2011 9:58 AM, Olaf van der Spek wrote: >> >> What version of Boost was used? > > 1.34.1 > >> Does it use make_shared? > > No. Not very meaningful either, I'm afraid.

3 2

[shifted_ptr] Review Request
by Phil Bouchard 06 Apr '11

06 Apr '11

Greetings, For those who are not aware in 2008 I wrote a memory manager running in real-time so that heap objects are being destructed instantly. A quick introduction can be found here: https://svn.boost.org/svn/boost/sandbox/shifted_ptr/libs/smart_ptr/doc/Shif… The library still needs more documentation but we can see the simplicity of its usage in its examples found in the sandbox. Here's a quick copy & paste compilation of the examples: $ svn co http://svn.boost.org/svn/boost/sandbox/shifted_ptr $ cd shifted_ptr/libs/smart_ptr/example $ make shifted_ptr_test1 $ make t100_test1 $ ./shifted_ptr_test1 $ ./t100_test1 "shifted_ptr_test1" shows its versatility and simplicity while "t100_test1" shows a more complicated application on a neural network. I would like to request a review while I add the necessary documentation for a better support. Thanks, -Phil

8 30

Re: [boost] Python 3.2: convert convert PyObject* to PyUnicodeObject*?
by Ralf W. Grosse-Kunstleve 06 Apr '11

06 Apr '11

Thanks for the patch and the pointer. I just checked in the fix and closed the ticket. Ralf ----- Original Message ----- > From:Matthew Bradbury <matt-bradbury(a)live.co.uk> > To:boost@lists.boost.org > Cc: > Sent:Wednesday, April 6, 2011 3:43 AM > Subject:Re: [boost] Python 3.2: convert convert PyObject* to PyUnicodeObject*? > > Steve M. Robbins <steve <at> sumost.ca> writes: > > > > > Hi, > > > > Boost 1.46.1 fails to build with Python 3.2 on linux (Debian). The > > build fails with: > > > > error: cannot convert -F�PyObject*� to �PyUnicodeObject*� for argument �1� > to > �Py_ssize_t > > PyUnicodeUCS4_AsWideChar(PyUnicodeObject*, wchar_t*, Py_ssize_t)�-A > > > > at this code: > snip > > > > Is there an easy fix? > > > > Thanks, > > -Steve > > > Yes, I submitted a bug and a patch some time ago. > > https://svn.boost.org/trac/boost/ticket/4994 > > Matt > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] [range] for_each and std::map of std::list
by Thorsten Ottosen 06 Apr '11

06 Apr '11

Den 06-04-2011 16:03, Mark Snelling skrev: > Hi, > > Consider a map defined as... > > std::map< int, std::list< std::string > > my_map; > > I'm wondering if/how it's possible to use Boost.Range to call a function > on each std::string in each of the lists contained in the map. I have an > implementation below which works using a C++0x lambda function but am > curious if this can be done purely using Boost.Range? > > boost::for_each( > boost::adaptors::values( my_map), > []( const std::list< std::string >& my_list ) { boost::for_each( > my_list, some_func ); } ); > > ideas anyone? What we need is a generic range adaptor that can make a container of containers look like a "flat" sequence. I suggest the syntax rngOfContainers | boost::adaptors::flattened and the underlying iterator should be up to bidirectional (if the underlying two container types support it). Anyone interested in implementing this? -Thorsten

2 2

Python 3.2: convert convert PyObject* to PyUnicodeObject*?
by Steve M. Robbins 06 Apr '11

06 Apr '11

Hi, Boost 1.46.1 fails to build with Python 3.2 on linux (Debian). The build fails with: error: cannot convert -F�PyObject*� to �PyUnicodeObject*� for argument �1� to �Py_ssize_t PyUnicodeUCS4_AsWideChar(PyUnicodeObject*, wchar_t*, Py_ssize_t)�-A at this code: static std::wstring extract(PyObject* intermediate) { std::wstring result(::PyObject_Length(intermediate), L' '); if (!result.empty()) { int err = PyUnicode_AsWideChar( intermediate , &result[0] , result.size()); if (err == -1) throw_error_already_set(); } return result; } Is there an easy fix? Thanks, -Steve

3 2

[config] Boost PP and variadic macros
by Edward Diener 06 Apr '11

06 Apr '11

This is largely directed to John Maddock, the maintainer of config, but of course anyone else can respond who is interested. I have been working to integrate my VMD library, and essentially variadic macro support, into Boost PP, with help and discussion offline of Paul Mensonides. I am now at the testing phase and all is now going well. This is currently being done in a separate library but when Paul and I are satisfied we intend to update the trunk with our changes. The library is at https://svn.boost.org/svn/boost/branches/pplib/variadics. One problem that I have can be explained by the fact that Boost PP currently does not depend on any other Boost library, not even Boost config. The reason for this is that Boost PP has been designed to work with C compilers ( or C++ compilers in C mode ) as well as C++ compilers. This means that the code to detect variadic macro support in Boost is duplicated in two places, both in config, which I basically started with the blessing of John Maddock with the BOOST_NO_VARIADIC_MACROS macro, and in Boost PP in a configuration file which I have coded and essentially duplicates the code in config for variadic macro support. I do not like this. Duplicating functionality in two different places, even as simple as determining variadic macro support for compilers, is error prone and a maintenance problem. Changes in one place have to be done in the other, and this would need to constantly be tracked. My initial thought was to see if config could work with C compilers, but all investigation there has led me to believe that it would be too many unnecessary changes to config, would complicate config greatly, would need extensive testing against all compilers, and that since config is central to all of Boost such a potential massive change to it it is a bad idea. So my current thought is to remove the code in config which tests for variadic macro support for a given compiler, to determine if BOOST_NO_VARIADIC_MACROS should be set, into a separate header file for each compiler which might set BOOST_NO_VARIADIC_MACROS, and then #include that header file in the compiler's header file, at the place where currently the setting of BOOST_NO_VARIADIC_MACROS exists ( or possible at the end ). The separate header file itself for testing variadic macro support is easily C compatible and I could use it in my Boost PP configuration file. This would eliminate duplication of the code to test for variadic macro support in config and Boost PP while keeping the goal of allowing Boost PP to still work with C compilers. Is this possible/desirable as far as config goes ? It would only affect the current code for setting BOOST_NO_VARIADIC_MACROS, hardly a Boost world-shaking event, and can easily be done by me and tested in regression tests. If it is, one further consideration is that the code in the Boost PP configuration file still would have to internally duplicate the checking and order of each compiler in the 'select_compiler_config.h' in config, but this is at least much better, and much less of a maintenance problem for Boost PP, than having to duplicate the code for checking for variadic macro support itself. Even this could be worked around, with a probably undesirable change to 'select_compiler_config.h', which I will proceed to suggest nonetheless. If we could add to that file another set of #defines for the corresponding variadic macro checking header file for each compiler that needs it. Something like: #define BOOST_COMPILER_CONFIG_NVM "boost/config/compiler/somecompiler_nvm.hpp" then in my Boost PP config header file I could go: #include <boost/config/select_compiler_config.hpp> #ifdef BOOST_COMPILER_CONFIG_NVM #include BOOST_COMPILER_CONFIG_NVM #endif and I could then check BOOST_NO_VARIADIC_MACROS and this will work for C compilers ( 'select_compiler_config.hpp' itself has nothing related to C++ and should work with any C compiler AFAICS ). But I would understand that littering 'select_compiler_config.hpp' with another set of #defines just to satisfy my need in Boost PP may not be acceptable to the clean design of that file, even if it would eliminate my need to reduplicate its logic in the Boost PP configuration file for variadic macro support in Boost PP which I have created.

5 17

archive_exception causes Link failure serialization
by Paul A. Bristow 06 Apr '11

06 Apr '11

I am trying to rebuild an existing demo program for Johan Rade's nonfinite facets from François Mauger The program was previously tested with Boost 1.44, gcc 4.4.1, Linux/i686 (32bits) Using MSVC 10, it compiles OK, but fails to link. Can anyone gives me any clues what I am doing wrong? Thanks! Paul ------ Rebuild All started: Project: nonfinite_num_serialization, Configuration: Release Win32 ------ nonfinite_num_facet_serialization.cpp Searching libraries Searching C:\Program Files\Microsoft SDKs\Windows\v7.0A\lib\kernel32.lib: <snip> Searching C:\Program Files\Microsoft Visual Studio 10.0\VC\lib\libcpmt.lib: Searching I:\boost-trunk\stage\lib\libboost_serialization-vc100-mt-s-1_47.lib: Finished searching libraries Creating library J:\Cpp\MathToolkit\test\Math_test\Release\nonfinite_num_serialization.lib and object J:\Cpp\MathToolkit\test\Math_test\Release\nonfinite_num_serialization.exp Searching libraries Searching C:\Program Files\Microsoft SDKs\Windows\v7.0A\lib\kernel32.lib: <snip> Searching C:\Program Files\Microsoft Visual Studio 10.0\VC\lib\libcpmt.lib: Searching I:\boost-trunk\stage\lib\libboost_serialization-vc100-mt-s-1_47.lib: Searching C:\Program Files\Microsoft Visual Studio 10.0\VC\lib\LIBCMT.lib: Searching C:\Program Files\Microsoft Visual Studio 10.0\VC\lib\OLDNAMES.lib: Finished searching libraries nonfinite_num_facet_serialization.obj : error LNK2001: unresolved external symbol "public: __thiscall boost::archive::archive_exception::archive_exception( enum boost::archive::archive_exception::exception_code,char const *,char const *)" (??0archive_exception@archive@boost@@QAE@W4exception_code@012@PBD1@Z) J:\Cpp\MathToolkit\test\Math_test\Release\nonfinite_num_serialization.exe : fatal error LNK1120: 1 unresolved externals I have just rebuilt this library I:\boost-trunk\stage\lib\libboost_serialization-vc100-mt-s-1_47.lib. Library directory is I:\boost-trunk\stage\lib;$(LibraryPath) and appears to searching in the right lib file. Runtime library is /MT for release (I have also tried debug with similar results). The following includes are used in the demo program #include <boost/cstdint.hpp> #include <boost/serialization/nvp.hpp> #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/xml_iarchive.hpp> #include <boost/archive/codecvt_null.hpp> Is there anywhere I should have told serialization/archive not to use exceptions?

1 0