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

Re: [boost] [Boost-users] [boost-users][ICL] ICL Compilation errors. Ticket #5207
by Joachim Faulhaber 22 Feb '11

22 Feb '11

2011/2/22 John Reid <j.reid(a)mail.cryst.bbk.ac.uk> > > I have started to use statically bounded intervals > and am finding more compilation issues. For example > with finding elements in a map: > > #define BOOST_ICL_USE_STATIC_BOUNDED_INTERVALS > #include <boost/icl/interval_map.hpp> > > void f() { > namespace icl = ::boost::icl; > icl::interval_map< float, int >().find( 0 ); > } > > This compiles without the #define but fails on static intervals. This is on purpose. The reason is that we can not represent a single element x using a right-open interval [x,?) of continuous values. right_open_interval is the default for statically bounded intervals, if BOOST_ICL_USE_STATIC_BOUNDED_INTERVALS is defined. In order to use find on an interval_map we have to construct an interval that represents a single element (internally). This is not possible in the logic of the ICL so this code won't compile. interval_map::find is a pretty late addition to ITL/ICL, because using find in the STL way makes little sense on interval containers most of the time. We can not "find" an large interval in an icl::interval_set of small intervals. {[0,2),[5,7)}.find([0,9)) The generalization of find is intersection. And the following function calls compile for statically bounded right-open intervals of continuous types: #define BOOST_ICL_USE_STATIC_BOUNDED_INTERVALS #include <boost/icl/interval_map.hpp> { icl::interval_map< float, int> iclmap; icl::interval_map< float, int> found; add_intersection(found, iclmap, right_open_interval<float>(0,1)); add_intersection(found, icl::interval_map< float, int>(), right_open_interval<float>(0,1)); found = iclmap & right_open_interval<float>(0,1); found = icl::interval_map< float, int>() & right_open_interval<float>(0,1); } > This makes me think it might be worth having tests for > every possible combination that is listed in the function > synopsis for both static and for dynamic intervals: > http://www.boost.org/doc/libs/1_46_0/libs/icl/doc/html/boost_icl/interface/… I am working on it. But as you see from this example, not every function overload works for dynamically bounded and statically bounded intervals in the same way. I think the documentation can be improved here. > I can keep you up-to-date with any further problems I find please do. > but I'm just wondering whether it would be easier to fix them all in one go. Currently it's no problem for me to fix them as they are detected. Cheers, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

1 0

[Log] fileystem V3 support
by Kenny Riddile 22 Feb '11

22 Feb '11

I'm wondering if the maintainer of the accepted Log library has plans to update it to use version 3 of the filesystem library. As it stands, the Log library will not build against Boost 1.46 without defining BOOST_FILESYSTEM_VERSION=2 (must also be defined in client code that includes certain Log headers apparently).

2 1

Re :Re: Boost release 1.46.0 available
by loic.actarus.joly＠numericable.fr 22 Feb '11

22 Feb '11

> > then it probably also means that the build and jam > > documentation on the site are out of date. > > At which URL specifically? I think all documentation for Boost.Build > is up to date. Also, there should be no documentation for Boost.Jam now. [1]http://www.boost.org/doc/libs/1_46_0/more/getting_started/windows.html#ge t-bjam -- Loïc References 1. http://www.boost.org/doc/libs/1_46_0/more/getting_started/windows.html#get-…

1 0

[Interprocess] Loosing shared memory when exiting scope
by supplier 22 Feb '11

22 Feb '11

Hi there, at the moment I'm working on a Windows application, which uses Boost.Interprocess library to share data between two processes. The general approach is as follows: - start application A - start application B - create shared memory in A using 'wmanaged_windows_shared_memory'. The line of code would look like this: > sharedMemory = new wmanaged_windows_shared_memory(create_only, mName.c_str(), mSize); - connect B to shared memory using the 'open_only' argument for the line above (size is not needed when connecting) - then B creates data objects in the shard memory using offset pointers and when finished removes his references to the shared memory by deleting the 'wmanaged_windows_shared_memory' object - application A will then read these objects and when finished it will also delete his 'wmanaged_windows_shared_memory' object to remove all references and allow windows to free the allocated shared memory To enable Windows to free the shared memory I had to ensure that all references to this were removed. This was a little work, because at first not all references to the shared memory were freed by application B. In order to do so I replaced the existing Singleton with RII objects [1] to ensure all references are deleted when a well defined scope of application B is left. Using the RII objects some passages of the code look like the following example: 1 > [...] 2 > // We are in class B of application B, which does work with the shared memory 3 > // Connecting to the existing shared memory 4 > SharedMemoryRiiConnector shmem("Some Name"); 5 > 6 > // Do some stuff here, for example calling a function creating objects 7 > TypeR* instance = createObjectInSharedMemory(); 8 > 9 > // Call a member function of TypeR 10 > instance->doSomething(); 11 > [...] 12 > } 13 > 14 > TypeR* classB::createObjectInSharedMemory() 15 > { 16 > // Connect to the shared memory again to allow working in this 17 > SharedMemoryRiiConnector shmem("Some Name"); 18 > 19 > // Create an object in the shared memory using the interface of the 20 > // RII object, which uses the Boost.Interprocess functions to handle allocation 21 > TypeR* instance = shmem.createObject<TypeR>("Example Object"); 22 > return instance; 23 > } 24 > There is one thing I do not understand so far: When returning from 'createObjectInSharedMemory()' there are cases when the pointer to 'instance' is valid within 'createObjectInSharedMemory()' but gets invalid as far as returned to the caller function in line 7. In this case the application would crash in line 10, although a connection was build up in line 4. This issue seems somehow to be connected to the destruction of the 'shmem' object in line 22, which deletes his instance of the 'wmanaged_windows_shared_memory' and with this seems to invalidate the shared memory context of the caller, too. On the opposite using one RII object as member in classB would work as expected. Why is this? I would expect the call in line 10 to succeed. My feeling tells me that this is due to the mechanism mapping the data of the shared memory into local address space. Although I did not found any information regarding my issue. Please explain this behavior to me. Best regards, Sören Kewenig [1] http://www.hackcraft.net/raii/

2 1

Re: [boost] [1.46.0] Release candidates available
by Tom Kent 22 Feb '11

22 Feb '11

>On 20 February 2011 08:19, Beman Dawes <bdawes_at_[hidden]> wrote: > >> Release candidate files for the 1.46.0 are available at >> http://boost.cowic.de/rc/ >> >> >OS: Windows XP 64bit >Compiler: MSVC-8 (Visual Studio 2005). >Std-Lib: Native >Command line: bjam release stage > >'Failed updating 2 targets'. > >Attached bjam output from the second run (which should only try to build the >libraries that failed, right?). I've got the log from the first run as well. > >- Christian I'd like to confirm this. I see it in MSVC-8 (VS 2005) in 32 and 64 bit builds (so far only on a 32-bit machine). It happens for all permutations of bjam.exe toolset=msvc-8.0 [address-model=64] variant=(debug|release) threading=(multi|single) link=(shared|static) runtime-link=(shared|static) stage when I run bjam.exe --build-type=complete toolset=msvc-8.0 stage or bjam.exe --build-type=complete toolset=msvc-8.0 address-model=64 stage I get 16 failed targets. The crucial errors are: compile-c-c++-pch bin.v2\libs\math\build\msvc-8.0\debug\address-model-64\link-static\runtime-link-static\pch.pch pch.pch.cpp .\boost/fusion/sequence/comparison/less_equal.hpp(49) : error C2039: 'is_native_fusion_sequence' : is not a member of 'boost::fusion::detail' .\boost/fusion/sequence/comparison/less_equal.hpp(49) : error C2065: 'is_native_fusion_sequence' : undeclared identifier .\boost/fusion/sequence/comparison/less_equal.hpp(49) : error C2974: 'boost::disable_if' : invalid template argument for 'Cond', type expected .\boost/utility/enable_if.hpp(59) : see declaration of 'boost::disable_if' .\boost/fusion/sequence/comparison/less_equal.hpp(49) : error C2988: unrecognizable template declaration/definition .\boost/fusion/sequence/comparison/less_equal.hpp(49) : error C2059: syntax error : ',' .\boost/fusion/sequence/comparison/less_equal.hpp(49) : error C2039: 'type' : is not a member of '`global namespace'' .\boost/fusion/sequence/comparison/less_equal.hpp(56) : error C2039: 'is_native_fusion_sequence' : is not a member of 'boost::fusion::detail' .\boost/fusion/sequence/comparison/less_equal.hpp(56) : error C2974: 'boost::disable_if' : invalid template argument for 'Cond', type expected .\boost/utility/enable_if.hpp(59) : see declaration of 'boost::disable_if' .\boost/fusion/sequence/comparison/less_equal.hpp(57) : error C2039: 'type' : is not a member of '`global namespace'' .\boost/fusion/sequence/comparison/less_equal.hpp(58) : error C2143: syntax error : missing ';' before '{' .\boost/fusion/sequence/comparison/less_equal.hpp(58) : error C2447: '{' : missing function header (old-style formal list?) call "C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat" x86_amd64 >nul cl /Zm800 -nologo @"bin.v2\libs\math\build\msvc-8.0\debug\address-model-64\link-static\runtime-link-static\pch.pch.rsp" "bin.v2\libs\math\build\msvc-8.0\debug\address-model-64\link-static\runtime-link-static\pch.pch.cpp" ...failed compile-c-c++-pch bin.v2\libs\math\build\msvc-8.0\debug\address-model-64\link-static\runtime-link-static\pch.pch bin.v2\libs\math\build\msvc-8.0\debug\address-model-64\link-static\runtime-link-static\pch.obj... You can find the errors from bjam.exe toolset=msvc-8.0 address-model=64 variant=debug threading=multi link=shared runtime-link=shared stage at: /http://boost.teeks99.com/temp/64errors-VS8-AM64-dbg-shared-shared.txt You can find the complete 32-bit & 64-bit build logs (VC 8,9,10) at: http://boost.teeks99.com/temp/32bitlog.txt http://boost.teeks99.com/temp/64bitlog.txt Built with the 1.46.0 RC, VC 8.0 SP1. Tom Kent

1 0

Re: [boost] [config] request for BOOST_NO_FWD_STD_DECLARATION
by Ivan Le Lann 22 Feb '11

22 Feb '11

----- "Robert Stewart" <Robert.Stewart(a)sig.com> a écrit : > Ivan Le Lann wrote: > > Le samedi 19 février 2011 à 19:37 +0100, Ion Gaztañaga a écrit : > > > having to include a lot of std headers to declare a function > > > with a std::string const reference as input parameter is a > > > bit too much > > > > For a function declaration, even when you pass/return by value, > > you only need to declare types. > > That's true unless, as is the subject of this thread, the type you > would like to forward declare is in namespace std. Then you get into > the world of "as if." The implementer may declare std types with > template parameters beyond those named in the standard, provided the > extras are defaulted so the types work as if they didn't have the > extra template parameters. If a type does have extra template > parameters, however, forward declaring it without them means > mismatching the declarations while including them means requires that > they be defaulted correctly. Unfortunately, defaults can be specified > only once. > > Only std types that don't make use of defaulted template parameters > could be forward declared and, even then, are nonportable, even among > versions of the same standard library. > I think you missed my point. I was basically replying: s/const reference// to Ion, and no more than that. I did not intend to fix the std forwarding problem, as there is obviously no clean way to fix it, until <stdfwd> appears. Ivan

1 0

Interested in a generic safe n-dimensional matrix/vector library?
by Тимофей Игнатьич 22 Feb '11

22 Feb '11

c++0x features allow us to implement some nice stuff: - Safe variadic functions with parameter count checking. For example consider a constructor of the N dimensional vector of T takes only N farameters that are convertable to T and fails othervise: vector<T, N> v(/*...N parameters convertable to T...*/); vector<float, 3> v(1,2,3); // good vector<float, 4> v(1.f,2.f); //fails vector<int, 3> v(1,2,3,4); //fails vector<int, 4> v(1,2,3,4); //good or an N dimensional cross product function that takes exactly N-1 vectors of dimension N: cross(v1,v2,v3,/*...*/, vn-1); Please note that N is arbitrary positive integer and is only restricted by compiler's template recursion depth. - Same type comversion as for fundamental types. This means that char multiplied by int gives int result and int multiplied by float gives float result. vectors work exactly the same: vector<float, 3> vf; vector<int, 3> vl; vector<short, 3> vs; vector<double, 3> vd; vi*vf; //returns vector<float, 3> vf*vd; //returns vector<double, 3> vs*vi; //returns vector<int, 3> Among other notable features are matrix matrix and vector matrix multiplications, component vise addition/substraction/multiplication/division, dot product, matrix inversion, matrix determinant calculation, etc. I want to know if there is any interest in such a library in boost community, and if so to make it available for public inspecion and criticism.

8 12

[boost-users][ICL] ICL Compilation errors. Ticket #5207
by Joachim Faulhaber 22 Feb '11

22 Feb '11

Hi John, lists, I am replying to your ticket #5207 on the lists because I am afraid that you walked into a trap that others can fall into as well. In the ITL, the precursor of Boost.ICL there was a single polymorphic interval class template: itl::interval. Due to input from the list during the review I split up this "one size fit's all" template in smaller classes according to static and dynamic interval concepts. In order to help ITL users to have a simple transition from ITL to ICL I wrote a template icl::interval. icl::interval is a meta function that yields the right interval type dependent on the instance type e.g. : BOOST_STATIC_ASSERT(( boost::is_same< interval<int>::type , discrete_interval<int> >::value )); So ITL users could move from ITL to ICL just by appending a '::type' to all occurrences of 'interval<T>' So please note that interval<myType> myInterval; can not be used as an interval type in ICL functions. Please use interval<myType>::type myInterval; or one of the specific interval types discrete_interval, continuous_interval, (dynamic borders) closed_interval, right_open_interval, left_open_interval, open_interval (static borders) e.g. discrete_interval<int> myInterval; See examples http://www.joachim-faulhaber.de/boost_icl/doc/libs/icl/doc/html/boost_icl/e… http://www.joachim-faulhaber.de/boost_icl/doc/libs/icl/doc/html/boost_icl/e… http://www.joachim-faulhaber.de/boost_icl/doc/libs/icl/doc/html/boost_icl/e… and docs http://www.joachim-faulhaber.de/boost_icl/doc/libs/icl/doc/html/boost_icl/i… for more detail. This reduces John's non compilable ICL statements in the following way: BOOST_AUTO_TEST_CASE(ticket_5207) { icl::interval< int >::type int_interval; icl::interval_set< int > int_set; icl::interval_map< int, int > int_map; icl::interval_map< int, int >::element_type int_element; icl::interval_map< int, int >::segment_type int_segment; // The next 4 lines compile icl::lower( int_interval ); icl::upper( int_interval ); icl::first( int_interval ); icl::last( int_interval ); // The next 4 lines are *not* supposed to compile // according to the docs: icl::add( int_set, int_set ); icl::add( int_map, int_map ); icl::subtract( int_set, int_set ); icl::subtract( int_map, int_map ); int_set += int_interval; // compiles // Here you are right, John: // The next 4 lines should compile according // to the docs, but don't icl::disjoint( int_map, int_element ); icl::disjoint( int_map, int_segment ); icl::intersects( int_map, int_segment ); icl::intersects( int_map, int_element ); // Those four are pretty special. I doubt anyone will // use them. But I will complete the library here. } Thanks for using my library and helping to improve it. Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

1 1

Review Request: Variadic Macro Data library
by Edward Diener 22 Feb '11

22 Feb '11

I am requesting that my library, the Variadic Macro Data library, which is in the sandbox in the variadic_macro_data directory, be reviewed for inclusion into Boost. The variadic_macro_data library adds support and functionality for variadic macros to Boost as well as integrating variadic macros with the Boost PP library without changing the latter library in any way. I believe others have used my library, can attest to its quality and that it does what it is supposed to do. and have found it useful when using variadic macros with Boost PP. I myself have used its functionality in my own TTI library in the sandbox. Support for variadic macros is implemented in nearly all modern C++ compilers and the syntax is natural for an end-user. The library is finalized as far as functionality is concerned and I would like to see it in Boost and am willing to maintain it as a Boost library. Edward Diener

10 70

Which libraries on the review schedule are ready for review?
by vicente.botet 21 Feb '11

21 Feb '11

Hi, I would like the authors of the libraries on the review schedule state clearly if his libraries are ready for review. Lexer Ben Hanson - Eric Niebler - Shifted Pointer Phil Bouchard - Needed - Logging John Torjo - Gennadiy Rozental - Join Yigong Liu - Needed - Pimpl Vladimir Batov - Needed - Task Oliver Kowalke - Vicente Botet - Endian Beman Dawes - Needed - Conversion Vicente Botet - Needed - Sorting Steven Ross - Needed - AutoBuffer Thorsten Ottosen - Robert Stewart - String Convert Vladimir Batov - Needed - Containers Ion Gaztañaga - Needed - Type Traits Extensions Frédéric Bron - Joel Falcou - Interthreads Vicente Botet - Needed - Bitfield Vicente Botet - Needed - Lockfree Tim Blechmann - Needed - Fiber Oliver Kowalke - Needed - Creasing (Sequence Properties) Grant Erickson - Needed - Static Size Linear Algebra Emil Dotchevski - Needed - Locale Artyom Beilis - Needed - XInt Chad Nelson - Needed - Context Oliver Kowalke - Needed - Stopwatches Vicente Botet - Anthony Williams - Please could you replay to this mail for each one of your libraries? Thanks, Vicente

13 36