- Boost - lists.preview.boost.org

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

24 Feb '11

(4) Using statically and dynamically bounded intervals in the same compilation unit. 2011/2/23 John Reid <j.reid(a)mail.cryst.bbk.ac.uk>: > On a side note, I don't understand the rationale for having static bounds > configured by #define whilst other aspects of intervals are parameterised > using templates. You can always instantiate ICL interval container templates with the interval type of your choice via the template parameter IntervalT. See e.g. http://www.boost.org/doc/libs/1_46_0/libs/icl/doc/html/boost_icl/interface.… #define BOOST_ICL_USE_STATIC_BOUNDED_INTERVALS switches the default value for this template-parameter from dynamically bounded to statically bounded intervals. Like any other default of a template parameter you can change it via instantiation. The rational behind this is (1) the intention, to minimize the effort for users, that have applications of ITL containers and want to change their code using statically bounded intervals now. In the ITL every interval was dynamically bounded. (2) for applications that only use one kind of intervals, e.g. statically bounded ones, #define BOOST_ICL_USE_STATIC_BOUNDED_INTERVALS can be convenient, because you need only to specify the first one or two template parameter for interval containers most of the time. > I would have liked to have both types of interval in the > same compilation unit. NP > However I guess it must be too late to change this > fundamental design choice. Fortunately it's not too late ;-) This code shows how to use icl sets with variations of interval types. BOOST_AUTO_TEST_CASE(using_vaious_interval_types) { interval_set<int, std::less, discrete_interval<int,std::less> > dyn_int_set; interval_set<int, std::less, right_open_interval<int,std::less> > stat_int_set; interval_set<float, std::less, continuous_interval<float,std::less> > dyn_float_set; dyn_int_set += discrete_interval<int>(1); BOOST_CHECK(( contains(dyn_int_set,1) )); stat_int_set += right_open_interval<int>(1); BOOST_CHECK(( contains(stat_int_set,1) )); dyn_float_set += continuous_interval<float>(1.0); BOOST_CHECK(( contains(dyn_float_set, 1.0) )); } For interval_map this can get a little verbose, because of the greater number of template parameters. Thank you for your questions. They help to clarify a lot of issues around the library (even for the author:) Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

2 1

[ICL]
by Tal Agmon 24 Feb '11

24 Feb '11

Hi Joachim, Please note: Icl's class templates<http://www.boost.org/doc/libs/1_46_0/libs/icl/doc/html/index.html#boost_icl…> *Table 1.1. Interval class templates in *--> the link to left_open_interval<http://www.boost.org/doc/libs/1_46_0/libs/icl/doc/html/boost/icl/right_open…>opens right_open_interval instead. Thanks.

2 1

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

24 Feb '11

(2) Generalization of "find" in the Set view and the STL/iterator view. 2011/2/23 John Reid <j.reid(a)mail.cryst.bbk.ac.uk>: > On 22/02/11 20:03, Joachim Faulhaber wrote: >> >> 2011/2/22 John Reid<j.reid(a)mail.cryst.bbk.ac.uk> >>> >> >> 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)) > > If we cannot find the large interval, isn't the end() iterator a suitable > return value to suggest it was not in the set/map? This is a question of design decisions of course. On the one hand I view intervals as Sets and also interval_set implements Set. (Capital S for concept Set). In this view, it is unusual to ask whether a set is found in a set, because one is not intended to be the element of the other. I this view (the Set view) we can achieve everything we need using predicates contains, intersects and functions add_intersection, &= and & (intersection) http://www.boost.org/doc/libs/1_46_0/libs/icl/doc/html/boost_icl/function_r… On the other hand, but with a lower priority in my design, I am supporting functions using iterators that are common to STL containers and that will be expected by users. 'find' is only defined on element_types, because only element can be "found" in sets. All functionality related to a "generalized find" in the STL/iterator related view can be provided by the member functions lower_bound, upper_bound and equal_range that are common to STL interfaces of associative containers: http://www.boost.org/doc/libs/1_46_0/libs/icl/doc/html/boost_icl/function_r… Here is some code for clarification: BOOST_AUTO_TEST_CASE(generalized_find) { typedef icl::interval_set<int>::iterator int_set_iterator; icl::interval_set<int> int_set; icl::interval<int>::type to_be_found(1,5); int_set += icl::interval<int>::type(0,2); int_set += icl::interval<int>::type(4,7); int_set += icl::interval<int>::type(8,9); int_set_iterator found; found = int_set.lower_bound(to_be_found); cout << *found << endl; // [0,2) found = int_set.upper_bound(to_be_found); cout << *found << endl; // [8,9) std::pair<int_set_iterator,int_set_iterator> exterior; exterior = int_set.equal_range(to_be_found); cout << "[" << *exterior.first << "," << *exterior.second << ")" << endl; // [[0,2),[8,9)) } It's good you brought up this question, so I could clarify the design decisions here. Thanks, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

2 2

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

24 Feb '11

2011/2/24 John Reid <j.reid(a)mail.cryst.bbk.ac.uk>: > On 24/02/11 11:51, Joachim Faulhaber wrote: >> >> (3) More compilability issues >> >> 2011/2/23 John Reid<j.reid(a)mail.cryst.bbk.ac.uk>: >>> >>> I'm interested to hear reasons why the following don't compile when using >>> static bounds: >>> >>> icl::add( icl::interval_set< int>(), 0 ); >>> icl::add( icl::interval_set< int>(), icl::interval< int>::type( 0, 1 ) >>> ); >>> icl::interval_set< int>() += 0; >>> icl::interval_set< int>() += icl::interval< int>::type( 0, 1 ); >>> >>> icl::subtract( icl::interval_set< int>(), 0 ); >>> icl::subtract( icl::interval_set< int>(), icl::interval< int>::type( 0, >>> 1 >>> ) ); >>> icl::interval_set< int>() -= 0; >>> icl::interval_set< int>() -= icl::interval< int>::type( 0, 1 ); >>> >>> icl::interval_set< int>()&= 0; >>> icl::interval_set< int>()&= icl::interval< int>::type( 0, 1 ); >>> >>> icl::interval_set< int>() ^= ( icl::interval< int>::type( 0, 1 ) ); >>> >>> >>> They all seem reasonable operations to me. In particular, for a discrete >>> domain, operations like icl::interval_set< int>() += 0 make sense to me. >>> That is the following are equivalent: >>> icl::interval_set< int>() += 0 >>> icl::interval_set< int>() += icl::interval< int>::type( 0, 1 ); >> >> Yes, you are right! The code you are giving should compile and it >> actually compiles on my machine with different msvc compilers. I guess >> it also compiles for gcc. If the problem persists try to generate a >> minimal code example so I can look again. > > We are still talking about static intervals. You did try setting the #define > for static intervals? Yes. > If you did, then my minimal example consists of > putting the code above in the function f() below: > > #define BOOST_ICL_USE_STATIC_BOUNDED_INTERVALS > #include <boost/icl/interval_set.hpp> > #include <boost/icl/interval_map.hpp> > > void f() { > namespace icl = ::boost::icl; > } > The reason that your code does not compile with gcc but compiles with msvc is, that gcc is pickier when you try to pass a temporary object to a reference parameter. When I pass the non-temporary object 'int_set' to the function calls, the code compiles. #define BOOST_ICL_USE_STATIC_BOUNDED_INTERVALS #include <boost/icl/interval_set.hpp> #include <boost/icl/interval_map.hpp> void f() { namespace icl = ::boost::icl; icl::interval_set<int> int_set; icl::add( int_set, 0 ); icl::add( int_set, icl::interval< int>::type( 0, 1 ) ); int_set += 0; int_set += icl::interval< int>::type( 0, 1 ); icl::subtract( int_set, 0 ); icl::subtract( int_set, icl::interval< int >::type( 0, 1 ) ); int_set -= 0; int_set -= icl::interval< int >::type( 0, 1 ); int_set &= 0; int_set &= icl::interval< int >::type( 0, 1 ); int_set ^= ( icl::interval< int >::type( 0, 1 ) ); } Regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

1 0

[interprocess] file_mapping opening opening unicode path on Windows
by Jeff Flinn 24 Feb '11

24 Feb '11

Is it possible to open a interprocess::file_mapping for a unicode path on windows? Any workarounds? I'm using boost 1.44 but don't see any changes in this respect in the latest boost 1.46 release. Thanks, Jeff

2 2

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

24 Feb '11

(3) More compilability issues 2011/2/23 John Reid <j.reid(a)mail.cryst.bbk.ac.uk>: > I'm interested to hear reasons why the following don't compile when using > static bounds: > > icl::add( icl::interval_set< int >(), 0 ); > icl::add( icl::interval_set< int >(), icl::interval< int >::type( 0, 1 ) ); > icl::interval_set< int >() += 0; > icl::interval_set< int >() += icl::interval< int >::type( 0, 1 ); > > icl::subtract( icl::interval_set< int >(), 0 ); > icl::subtract( icl::interval_set< int >(), icl::interval< int >::type( 0, 1 > ) ); > icl::interval_set< int >() -= 0; > icl::interval_set< int >() -= icl::interval< int >::type( 0, 1 ); > > icl::interval_set< int >() &= 0; > icl::interval_set< int >() &= icl::interval< int >::type( 0, 1 ); > > icl::interval_set< int >() ^= ( icl::interval< int >::type( 0, 1 ) ); > > > They all seem reasonable operations to me. In particular, for a discrete > domain, operations like icl::interval_set< int >() += 0 make sense to me. > That is the following are equivalent: > icl::interval_set< int >() += 0 > icl::interval_set< int >() += icl::interval< int >::type( 0, 1 ); Yes, you are right! The code you are giving should compile and it actually compiles on my machine with different msvc compilers. I guess it also compiles for gcc. If the problem persists try to generate a minimal code example so I can look again. Best regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

1 0

[chrono] patches for Windows CE support
by David Deakins 24 Feb '11

24 Feb '11

Hi Vincente, I went ahead and committed the fixes for VC9 and closed the ticket. Now on to the next item... =) Attached is a collection of patches that allow Boost.Chrono to build correctly for Windows CE / Windows Mobile. Mostly they relate to WinCE lacking functions such as GetSystemTimeAsFileTime or GetProcessTimes. Take a look at the changes and let me know if they seem ok to commit. I opened Trac ticket 5218 for this item. Thanks, -Dave

2 1

[chrono] patch for VC9 duration conversions
by David Deakins 23 Feb '11

23 Feb '11

Currently the enable_if expressions that restrict implicit duration type conversion to only conversions that will not reduce resolution are disabled on VC9 because they trigger a compiler error. I have come up with a slight adjustment to the expression that VC9 appears to be able to digest more favorably. Attached is a patch. I also opened ticket 5214 in Trac with this information. Vincent, if the patch looks good, let me know if you want to apply it or if you would like me to. -Dave

2 3

Inter-domain interaction - Question and bug ?
by Joel Falcou 23 Feb '11

23 Feb '11

Hi, while adding function to my SIMD library built on proto. I stumbled into this problem: http://codepad.org/dd5WB8Xu I have a template grammar/generator/domain that helps me not mixing vector of different type/cardinal. However some functions are designed to take vector of float and turn them into vector of int. I wrote one there (exponenbits) by just forcing the domain to be the one from int. When I call it alone, it works. But if I do exponentbits( some_float ) + some_int doesnt work. The error is just : /Users/joelfalcou/nt2/sandbox/proto.cpp:161:46: error: no match for 'operator+' in 'nt2::simd::exponentbits(((const nt2::simd::pack<float, 4ul>&)((const nt2::simd::pack<float, 4ul>*)(& x)))) + y' With none of the usual 'no proto_grammar in not_a_domain' error I got when I mix element of different grammar with each other. Now, if i turn the grammar into: //////////////////////////////////////////////////////////////////////////////// // the template grammar //////////////////////////////////////////////////////////////////////////////// template<class T, class C> struct grammar : boost::proto ::or_ < boost::proto::terminal< data<T,C> > , boost::proto::unary_expr<exponentbits_, grammar<boost::proto::_,C> > , boost::proto:: and_< boost::proto:: nary_expr < boost::proto::_ , boost::proto::vararg< grammar<T,C> > > , boost::proto:: not_< boost::proto::or_ < boost::proto:: address_of< grammar<T,C> > , boost::proto:: dereference< grammar<T,C> > , boost::proto:: comma < grammar<T,C> , grammar<T,C> > > > > > {}; It works. Alas, I have a potentially high and extensible set of such function (some being binary or ternary or w/e) and so I want some way to accept such constructs without an explicit list of supported function. nt2 currently has something like 17 such cross domain function. My question is why building such an expression: - make an error. Once I wrapped a terminal of domain Foo in domain Bar, it should be composable with other element of Bar domain - if this is an error, why dont I get the usual error of mixing wrong element with each other ? Mixing element from unrelated domain through such domain wrapping is a very valauble techniaues in EDSL in my opinion as it allows efficient operations to be done. nt2 has a vector and covector class in different domain and transposing a vector yields a covector, and vice versa. Being able to just have somehting that wraps the vector terminal and change its semantic this way is very valuable. Thansk for any pointers or discussion on this.

1 0

Small contribution to algorithm library: clamp function
by Тимофей Игнатьич 23 Feb '11

23 Feb '11

I wasn't able to find a clamp function in boost so i submitted my version for discussion and refinement here: http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Algor… (file clamp.hpp) Summary: clamp(a, x, b) Effect: if (x < a) returns a, otherwise if (b < x) returns b, otherwise returns x. clamp(a, x, b, comp) clamp<comp>(a, x, b) Effect: if comp(x, a) returns a, otherwise if comp(b, x) returns b, otherwise returns x. Let me know what you think. Maybe i was wrong and such function does already exist within boost?

3 2

[config] C++0X Compiler doesn't support classes with constructors in unions
by Vicente Botet 23 Feb '11

23 Feb '11

Hi, is there a macro that can be tested to know if a compiler doesn't support classes with constructors in unions? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/config-C-0X-Compiler-doesn-t-support-cla… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 5

[1.46.0][fusion] fusion compare is broken
by MURAKAMI Genya 23 Feb '11

23 Feb '11

I try compiled use Boost.Fusion, but compilation error by include, in VC7.1 and VC8. #include <boost/fusion/sequence/comparison/less_equal.hpp> // error! int main() {} This problem was fixed by rev.68358, but unfortunately was not in 1.46.0 release branch. Therefore, I think that the Boost.Fusion user using a VC7.1 or VC8 cannot introduce 1.46.0.

4 3

[interprocess] sharing memory between 32 bit and 64 bit Windows processes
by Arno Schödl 23 Feb '11

23 Feb '11

Hello Ion, I also need this functionality badly. Is there any chance of you implementing it? Basically, using unsigned int instead of size_t and int instead of ptrdiff_t, so the binary layout of shared memory is always like in 32 bit, would in practice do the trick. If we implement it ourselves, would you support getting this into boost? I cannot promise complete support. I already saw that rbtree_best_fit has a problem because the ring list containing the memory blocks needs to wrap around from the last block to the first. Would porting Doug Lea's allocator be an option? It will be hard to beat something that has been so thoroughly used and improved. Cheers, Arno -- Dr. Arno Schödl | aschoedl(a)think-cell.com Technical Director think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl

2 7

Subject: Formal Review of Proposed Boost.Process library starts tomorrow
by Marshall Clow 23 Feb '11

23 Feb '11

It's my pleasure to announce that the review of Boris Schäling's Process library starts tomorrow, February 7th and lasts until February 20, 2011, unless an extension occurs. What is it? =========== Boost.Process is a library to manage system processes. It can be used to: • create child processes • run shell commands • setup environment variables for child processes • setup standard streams for child processes (and other streams on POSIX platforms) • communicate with child processes through standard streams (synchronously or asynchronously) • wait for processes to exit (synchronously or asynchronously) • terminate processes Getting the library =================== The library is available at: http://www.highscore.de/boost/gsoc2010/process.zip with documentation at: http://www.highscore.de/boost/gsoc2010/ There was a quite involved "informal review" on the mailing list this past summer. That thread is archived here: http://thread.gmane.org/gmane.comp.lib.boost.devel/207594 Writing a review ================ If you feel this is an interesting library, then please submit your review to the developer list (preferably), or to the review manager (me!) Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick - reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. -- Marshall Review Manager for the proposed Boost.Process library

17 63

[1.46] [iostreams] Okay to merge changeset 68779
by Steven Watanabe 22 Feb '11

22 Feb '11

AMDG This fixes a regression in filtering_ostream::flush. It should be safe, as it simply restores the original behavior. I've checked the trunk regression tests and didn't see any issues from this. In Christ, Steven Watanabe

3 2

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