March 2009 - Boost - lists.preview.boost.org

[config] A question about BOOST_NO_NESTED_FRIENDSHIP
by Andrey Semashev 26 Mar '09

26 Mar '09

Hi, I've been merging my recent additions to the release branch and came across the BOOST_NO_NESTED_FRIENDSHIP macro, which hasn't been merged. Looking at its description and test, I'm not certain whether this macro actually flags a compiler deficiency, rather than valid behavior. Here's the description: If the compiler fails to support access to private members from nested classes And the test: class A { static int b; class B { int f() { return b; } }; }; To my understanding, 11.8 says that it shouldn't compile, as B doesn't have any privileged access to A::b. Am I missing something?

2 2

BOOST_NO_INTRINSIC_INT64_T
by Robert Ramey 26 Mar '09

26 Mar '09

boost config includes BOOST_NO_INTRINSIC_WCHAR_T. boost Is there any chance we might see BOOST_NO_INTRINSIC_INT64_T appear in the near future? Robert Ramey

3 7

best way to serialize a GIL image
by Kenny Riddile 26 Mar '09

26 Mar '09

I have a class which contains a boost::gil::rgba8_image_t instance that I'd like to serialize via boost.serialization. I'm just wondering what the optimal way to do this would be. I have a couple naive ideas, but they involve additional copies of pixel data that aren't conceptually necessary.

2 1

[asio] need help with timer crash please
by bnv＠nc.rr.com 26 Mar '09

26 Mar '09

I'm seeing two distinct crashes (gdb output below) on expiration of a deadline timer, and could use some help identifying possible reasons. The timer has not been deleted. The timer expired once before and was later rescheduled using expires_from_now() and async_wait(). The timer is only accessed by threads in io_service::run(), and is protected by a mutex. Form the gdb output, I'm guessing the timer is being removed on expiration and the internal structures have somehow been trashed. Any pointers to possible explanations would be appreciated. crash 1... Program received signal SIGSEGV, Segmentation fault. [Switching to thread 3500.0x83c] 0x5ae9a800 in ?? () (gdb) bt full #0 0x5ae9a800 in ?? () No symbol table info available. #1 0x005ae5f7 in boost::asio::detail::timer_queue<boost::asio::time_traits<boos t::posix_time::ptime> >::complete_timers (this=0x5387f74) at /usr/local/include/boost-1_38/boost/asio/detail/timer_queue.hpp:205 this = ( timer_queue<boost::asio::time_traits<boost::posix_time::ptime> > * const) 0x 5387f74 this_timer = ( timer_queue<boost::asio::time_traits<boost::posix_time::ptime> >::timer_base *) 0x53a4faf #2 0x053a4fb7 in ?? () No symbol table info available. #3 0x1dcdcb20 in ?? () No symbol table info available. #4 0x005bf1c0 in boost::asio::detail::select_reactor<false>::complete_operation s_and_timers (this=0x658, lock=@0x1dcd9498) at /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_vector.h:462 this = (class select_reactor< false> * const) 0x658 this = (scoped_lock<boost::asio::detail::posix_mutex> * const) 0xa i = 500011328 #5 0x00000000 in ?? () No symbol table info available. (gdb) crash 2... Program received signal SIGSEGV, Segmentation fault. [Switching to thread 1320.0xa08] 0x005adff1 in boost::asio::detail::timer_queue<boost::asio::time_traits<boost::p osix_time::ptime> >::remove_timer (this=0x5387f74, t=0x53aac70) at /usr/local/include/boost-1_38/boost/asio/detail/timer_queue.hpp:399 399 t->prev_->next_ = t->next_; (gdb) bt full #0 0x005adff1 in boost::asio::detail::timer_queue<boost::asio::time_traits<boos t::posix_time::ptime> >::remove_timer (this=0x5387f74, t=0x53aac70) at /usr/local/include/boost-1_38/boost/asio/detail/timer_queue.hpp:399 this = ( timer_queue<boost::asio::time_traits<boost::posix_time::ptime> > * const) 0x 5387f74 index = 87735592 it = {_M_node = 0x53aad20} #1 0x00000002 in ?? () No symbol table info available. #2 0x00000000 in ?? () No symbol table info available. (gdb) Thanks, Brian

1 0

Function Input Iterator Implementation (Interest Check, Submission)
by Dean Michael Berris 26 Mar '09

26 Mar '09

Hi Everyone, Let's say I have a function object that I wrap in a generator iterator and I want it to signal that it's done generating values or that there's nothing more to generate. In the current version of the Generator Iterator, there's no way to create an iterator that has a bound. This is great if you want an infinite input iterator, but there are cases where you might want one that is bounded (or at least, create a pair of iterators representing a range gotten from an infinite source). I've attached the implementation of a proposed 'function_input_iterator' which allows the creation of bounded input ranges from a nullary function object which models the Generator concept. This doesn't aim to replace the generator_iterator implementation, but rather is an implementation that allows for the following use case: ---->8-- #include <boost/function_input_iterator.hpp> #include <iostream> #include <iterator> #include <algorithm> struct generator { typedef int result_type; generator() { srand(time(0)); } result_type operator() () const { return rand(); } }; using namespace std; using namespace boost; int main(int argc, char * argv[]) { generator f; copy( make_function_input_iterator(f, infinite()), make_function_input_iterator(f, infinite()), ostream_iterator<int>(cout, " ") ); return 0; } ---->8-- In the attached implementation, I've implemented a simple 'infinite' class that supports the post- and pre-increment operator and comparison between two infinite instances always result to false. This allows the use of infinite() as a dummy state variable internal to the function_input_iterator to make sure that the created range resulting from the iterator is infinite. Another use case enabled is given below: ---->8-- copy( make_function_input_iterator(f, 0), make_function_input_iterator(f, 10), ostream_iterator<int>(cout, " ") ); ---->8-- This creates a range of 10 random numbers. If we were going to populate an STL container using the range constructors, we can do: vector<int> random_ints( make_function_input_iterator(f, 0), make_function_input_iterator(f, 10) ); I'm currently in the process of writing documentation in RST format. I'm submitting this implementation to Boost in case there's interest for inclusion. Question: Does a library like this qualify for a fast-track review? What is the criteria for inclusion to an existing library like Boost.Iterators? Thanks in advance and I hope this helps! -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

1 1

best way to serialize a GIL image
by Tom Brinkman 26 Mar '09

26 Mar '09

int width = 200; int height = 200; rgb8_image_t img(width,height); unsigned char* buffer = interleaved_view_get_raw_data(view(img)); FILE* fd = fopen(path,"wb"); fprintf(fd, "P6\n# CREATOR: unknown\n%d %d\n255\n",width,height); fwrite(buffer,1,width*height*3,fd); fclose(fd); GIL is just a wrapper around your buffer. No direct serialization support is provided nor needed.

4 4

[proto] switch_ with a policy
by troy d. straszheim 25 Mar '09

25 Mar '09

In some situations you're limited by the fact that proto::switch_ matches on tag type. For instance, if you have a bunch of these things: namespace tag { struct exp {}; struct log {}; // lots more, say 50 of them } Expression<terminal<tag::exp>::type> const exp = {{}}; Expression<terminal<tag::log>::type> const log = {{}}; // 50 more And you try to write a transform with switch_ that handles theses, you're stymied by the fact that switch_ will only tell you the tag of what has matched. Here's an attempt at the switch: struct UnaryFunctionCases { template <typename Tag, int i=0> struct case_ : not_<_> { }; template <int i> struct case_<VEY, i> : when<proto::function<...>, DoSomethingClever(...)> { }; }; struct UnaryFunctionSwitch : proto::switch_<UnaryFunctionCases> { }; the VEY above is going to be proto::tag::function for all of these terminals if you're trying to transform an expression like exp(7); (If I remember correctly... I havent looked at this code in a while). You can add a policy to the stock switch_ that makes this easy to handle (sorry if my mailer borks some newlines here): namespace boost { namespace proto { template<typename Cases, template <class> class Policy = boost::proto::tag_of> struct switch_ : proto::transform<switch_<Cases, Policy> > { typedef switch_<Cases, Policy> proto_base_expr; template<typename Expr, typename State, typename Data> struct impl : Cases::template case_< typename Policy<Expr>::type >::template impl<Expr, State, Data> { }; template<typename Expr, typename State, typename Data> struct impl<Expr &, State, Data> : Cases::template case_< typename Policy<Expr>::type >::template impl<Expr &, State, Data> { }; }; namespace detail { template<typename Expr, typename Cases, template <class> class Policy> struct matches_<Expr, switch_<Cases, Policy> > : matches_< Expr , typename Cases::template case_< typename Policy<Expr>::type >::proto_base_expr > { }; } } } Which I believe behaves identically to the stock switch_, and you can handle the example scenario like this: namespace detail { // metafunction extracts the thing we want to match on template <typename Expr> struct fncall2fntag { typedef typename Expr::proto_child0 child0; typedef typename proto::result_of::value<child0>::type value; typedef typename boost::remove_reference<value>::type noref; typedef typename boost::remove_const<noref>::type noconst; typedef noconst type; }; } struct UnaryFunctionCases { template <typename Tag, int _=0> struct case_ : proto::not_<proto::_> { }; template <int _> struct case_<tag::exp,_> : proto::when< proto::function<proto::terminal<tag::exp>, Array>, UnaryFunctionDispatch(tag::exp(), ...) > { }; // etc }; struct UnaryFunctionSwitch : proto::switch_<UnaryFunctionCases, detail::fncall2fntag> { }; Thoughts? -t

3 4

[fusion][map] default construction semantics
by Rutger ter Borg 25 Mar '09

25 Mar '09

Please see attached an example of constructing a fusion map, of which I would expect to give identical results. Or, does fusion deviate from the common expression for default construction in this case? Kind regards, Rutger ter Borg

2 2

"[gsoc] Thread scheduler support for boost"
by Indradip Ghosh 25 Mar '09

25 Mar '09

Hi Phil and Mathias, I completely appreciate the portability issues involved in making such an extension in which case it has to come with a portability clause and disclaimer which would become a deterrent in including such a facility in the library. However, I thought of your suggested extension of threadpool class exploiting processor affinity techniques and it sounds very interesting as well but I guess we would run into the same portability issues with regard to availability of the lower level API exposing the hooks to be able to develop such a facility. Another issue would be to qualify and justify how much improvement would this type of parallelism enable on top of the instruction level parallelism already in place for all modern processors. Although, I would still like to find out if you have any concrete lead in mind. I know for sure that there are those hard engineering problems in high performance computing domain to ensure QOS guarantees to distributed real-time embedded systems. They look into processor utilization optimizations in the face of uncertainty of computational load on the system. These usually require some kind of mathematical validation of the scheme for the system under construction. I guess that would be beyond the scope of the GSOC project, given the time frame. M:N type of models would also have the same portability issue as it requires changing kernel code as well as the userland code in thread library. Please let me know if you can think of a any non trivial portable addition that you can think of an I can work on it. In fact, I don't mind doing a big project even if it goes beyond the time frame of GSOC if we can see value in it. Please let me know. Thanks, Indradip. ____________________________________________________________________________ > From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> > Subject: Re: [boost] "[gsoc] Thread scheduler support for boost" > To: boost(a)lists.boost.org > Message-ID: <gq97h5$dbk$1(a)ger.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Indradip Ghosh wrote: > >> I would like to get suggestions on developing a thread scheduler API for >> supporting users having specific needs in prioritizing threads >> running on SMP / Multi-Core processors. Please let me know the >> viability of including such an API in generic boost distribution and >> whether anyone would volunteer to mentor this effort as a GSOC >> project. > > Are you suggesting a N:M threading model where you can specify the > userland scheduler? > > > Hi Indradip, I have previously looked at passing POSIX thread attributes (i.e. priority and policy) and it's not much work; presumably it could now be done using the native handle in the proposed std::thread and new version of boost::thread. How close to the POSIX semantics does Windows come? Boost generally prefers to implement portable stuff (although that's not something I need!) and choosing to work in an area where the different platforms have little common ground will make things more difficult for you, unless you're already familiar with how this stuff works on both POSIX and Windows systems. Beyond that there's the area of processor affinity, where as far as I know POSIX has nothing to say. Linux has some APIs for this but I doubt they have much in common with any other platforms. Maybe the Intel TBB library has already solved all of this? I'm wondering how something like a thread pool would be extended to exploit processor affinity, if the lower-level API offered it. Do you have a motivating application? Phil. On Tue, Mar 24, 2009 at 5:09 AM, <boost-request(a)lists.boost.org> wrote: > Send Boost mailing list submissions to > boost(a)lists.boost.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.boost.org/mailman/listinfo.cgi/boost > or, via email, send a message with subject or body 'help' to > boost-request(a)lists.boost.org > > You can reach the person managing the list at > boost-owner(a)lists.boost.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Boost digest..." > > > The boost archives may be found at: http://lists.boost.org/MailArchives/boost/ > > Today's Topics: > > 1. Re: Re quest interest in Bloom filters (Phil Endecott) > 2. [asio] basic_datagram_socket::send_to (Miroslav Berani? ml.) > 3. Re: Can a Boost library use a component like GMP and mfpr > that have a LGPL license ? (Simonson, Lucanus J) > 4. Re: Can a Boost library use a component like GMP and mfpr > that have a LGPL license ? (Sebastian Redl) > 5. Re: Can a Boost library use a component like GMP and mfpr > that have a LGPL license ? (Simonson, Lucanus J) > 6. Re: Can a Boost library use a component like GMP and mfpr > that have a LGPL license ? (Sebastian Redl) > 7. Re: Can a Boost library use a component like GMP and mfpr > that have a LGPL license ? (Simonson, Lucanus J) > 8. Re: Can a Boost library use a component like GMP and mfpr > that have a LGPL license ? (Schrader, Glenn) > 9. Re: Can a Boost library use a component like GMP and mfpr > that have a LGPL license ? (Mathias Gaunard) > 10. [GSOC] 10 Day student application period begins today > (troy d. straszheim) > 11. Re: How to build 32 bits boost library on a 64 bits platform > (Qihong Wang) > 12. Re: "[gsoc] Thread scheduler support for boost" (Phil Endecott) > 13. [interprocess] locked mutex and process killed (vicente.botet) > 14. Re: "[gsoc] Thread scheduler support for boost" (Mathias Gaunard) > 15. has_operator_new (Robert Ramey) > 16. BOOST_NO_INTRINSIC_INT64_T (Robert Ramey) > 17. Re: Can a Boost library use a component like GMP and mfpr > that have a LGPL license ? (Barend Gehrels) > 18. Boost with ICU on AIX - Patch (solar(a)rootdirectory.de) > 19. Re: has_operator_new (John Maddock) > 20. Re: [interprocess] locked mutex and process killed (Edouard A.) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 23 Mar 2009 16:15:01 +0000 > From: "Phil Endecott" <spam_from_boost_dev(a)chezphil.org> > Subject: Re: [boost] Re quest interest in Bloom filters > To: <boost(a)lists.boost.org> > Message-ID: <1237824901397(a)dmwebmail.dmwebmail.chezphil.org> > Content-Type: text/plain; format="flowed" > > Vicente Botet Escriba wrote: >> Phil Endecott-48 wrote: >>> >>> vicente.botet wrote: >>>> I need for my application bloom filters. Do you know of a good boostified >>>> generic implementation? >>>> Is there any interest in such a generic bloom filters library in Boost? >>> >>> Hi Vicente, >>> >>> I have a simple generic Bloom filter here: >>> >>> http://svn.chezphil.org/libpbe/trunk/include/bloom_filter.hh > >>> I seem to have lost the example code > > Now found and checked in here: > > http://svn.chezphil.org/libpbe/trunk/examples/spellcheck.cc > >> The hard part (the hash functions) is left out quite elegantly. I was >> thinking about defining some hash traits wich will allow the user to set the >> hash functions in a independent way. Something like >> >> template <template T, size_t N> struct hash_traits; >> >> template <> hash_traits<SpecificUserType,0> { >> static unsigned hash(T& value) { >> // specific code >> } >> } >> >> BTW, besides the tr1::hash function, are there other hash generic functions >> in Boost? > > You can use Boost.CRC. What sort of key do you have? I once did some > investigation of hash functions for strings for use with unordered > containers; I was considering using a degenerate hash that only looks > at the first N characters. > > Something I didn't mention before is that if you need, say, 10-bit hash > values then a 32-bit CRC could give you three of them. In this case > your hash_traits would presumably compute the same CRC three times and > extract different portions each time, which is not ideal. > >> I would need also the union and intersection functions. I'm wondering if >> replacing the tr1::array by a boost::dynamic_bitset should make eassier >> this. > > Well it's not exactly difficult with the array. I've never used > dynamic_bitset and being dynamic is not a requirement here. I was > concerned (as normal) about getting a fast implementation and the > simple bit manipulation in my code is probably about as fast as you can get. > > > Cheers, Phil. > > > > > > ------------------------------ > > Message: 2 > Date: Mon, 23 Mar 2009 17:54:14 +0100 > From: Miroslav Berani? ml. <miroslav.beranic(a)mibesis.si> > Subject: [boost] [asio] basic_datagram_socket::send_to > To: boost(a)lists.boost.org > Message-ID: > <c62cccb70903230954g7020c4c0w30664ae62556b6f(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Greetings, > > will method basic_datagram_socket::send_to flush data immediately to > the endpoint or will first fill its internal buffer and than flush > data to endpoint? I would like to make sure, data gets flushed to > endpoint when this method is called. > > Is there any other way to flush data to endpoint? > Does any socket::set_option(option); makes difference to behaviour of > send_to method ? > Why isn't it possible to set buffer size lower than 1024 (low-level > restriction?), with method (basic_datagram_socket::send_buffer_size()) > > > There is no documentation about this. > > > Best regards, > ----- > Miroslav Berani? ml. > > > ------------------------------ > > Message: 3 > Date: Mon, 23 Mar 2009 09:58:20 -0700 > From: "Simonson, Lucanus J" <lucanus.j.simonson(a)intel.com> > Subject: Re: [boost] Can a Boost library use a component like GMP and > mfpr that have a LGPL license ? > To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> > Message-ID: > <26E9B811E137AB4B95200FD4C950886B25DDF48C(a)orsmsx507.amr.corp.intel.com> > > Content-Type: text/plain; charset="us-ascii" > > Sebastian Redl wrote: >>>> >>>> AFAICT, in the case of LPGPled libs such as GMP and MPFR, there is >>>> no problem in using them in commercial products, even closed source >>>> applications (provided a copy of the license is distributed with >>>> said product), so I don't think there should be any restriction on >>>> allowing Boost libs to depend on LPGL libs. >>> >>> The LGPL requires you to construct your code in such a way that you >>> can relink with a new library. It also requires you to allow users >>> to reverse engineer the code for debugging. Commercial users of >>> Boost may not like those terms. >> >> My company, for example, would be interested in the BGL, but quite >> unable >> to include an LGPL library, since our copy protection mechanism kills >> the application if it detects a debugger. This would be a license >> violation. (We probably wouldn't need bignum functionality. As long >> as the BGL can be used without the bignum libraries, we'd probably be >> happy.) >> > > Huh, they basically exclude copy protection in the terms of their license? I didn't trust the LGPL when I read it because it was obviously written by a lawyer. Did you mean GTL and type BGL by mistake? > > Ideally I'd like to eliminate dependence on big-num for robustness, for performance reasons if not license concerns, but this requires some fancy programming. For instance, the degree-2 predicate of slope comparison requires 65 bits when the input is 32 bit coordinates. That can be performed with 64 bit unsigned integer if you keep track of the sign seperately. The only other places where I need high precision are the computation of the sweep-line intercept for comparing the y coordinates of segments that intersect the sweep-line and the actual computation of intersection points. Instead of using mp rational I could provide robust calculations "by hand" if I implement enough of what is in a multi-precision rational to get by or come up with some tricks. Long double only barely fails in my pseudo-exhasutive testing of line intersection computation. Since its result is only off by a small margin I could potentially detect these errors and handle them specially. The impor > tant aspect of the intersection computation is that when it snaps to the the integer grid both line segments must intersect that integer grid box. This check can be performed with point on-above-or-below line segment based degree-2 predicates (on-above-or-below can be implemented with slope comparison) that don't need multi-precision or rationals and then I can search adjacent grid boxes for one that meets the criteria for correctness if the check fails for the one computed by floating point approximation. Happily I have the ability to validate such fancy (read error-prone) code against the known correct big-num reliant implementation I already have. > > Luke > > ------------------------------ > > Message: 4 > Date: Mon, 23 Mar 2009 19:01:29 +0100 > From: Sebastian Redl <sebastian.redl(a)getdesigned.at> > Subject: Re: [boost] Can a Boost library use a component like GMP and > mfpr that have a LGPL license ? > To: boost(a)lists.boost.org > Message-ID: <49C7CE79.10607(a)getdesigned.at> > Content-Type: text/plain; charset=ISO-8859-1 > > Simonson, Lucanus J wrote: >> Sebastian Redl wrote: >> >>> My company, for example, would be interested in the BGL, but quite >>> unable >>> to include an LGPL library, since our copy protection mechanism kills >>> the application if it detects a debugger. This would be a license >>> violation. (We probably wouldn't need bignum functionality. As long >>> as the BGL can be used without the bignum libraries, we'd probably be >>> happy.) >>> >>> >> >> Huh, they basically exclude copy protection in the terms of their license? > They require that it is still possible to debug the LGPLed library in > the context of the combined work. If there's a debugger killer as part > of the copy protection (and every effective CP needs one), that's > obviously not possible. >> I didn't trust the LGPL when I read it because it was obviously written by a lawyer. Did you mean GTL and type BGL by mistake? >> > Yes. I typed BGL for Boost Geometry Library. Isn't one of the geometry > libraries called that? >> Ideally I'd like to eliminate dependence on big-num for robustness, for performance reasons if not license concerns, but this requires some fancy programming. For instance, the degree-2 predicate of slope comparison requires 65 bits when the input is 32 bit coordinates. > I'm fairly certain that I don't need that. So it's a question of how > modular the library is. > > Sebastian > > > ------------------------------ > > Message: 5 > Date: Mon, 23 Mar 2009 11:16:01 -0700 > From: "Simonson, Lucanus J" <lucanus.j.simonson(a)intel.com> > Subject: Re: [boost] Can a Boost library use a component like GMP and > mfpr that have a LGPL license ? > To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> > Message-ID: > <26E9B811E137AB4B95200FD4C950886B262115D3(a)orsmsx507.amr.corp.intel.com> > > Content-Type: text/plain; charset="us-ascii" > > Sebastian Redl wrote: >> Simonson, Lucanus J wrote: >>> Sebastian Redl wrote: >>> >>>> My company, for example, would be interested in the BGL, but quite >>>> unable to include an LGPL library, since our copy protection >>>> mechanism kills the application if it detects a debugger. This >>>> would be a license violation. (We probably wouldn't need bignum >>>> functionality. As long as the BGL can be used without the bignum >>>> libraries, we'd probably be happy.) >>>> >>>> >>> >>> Huh, they basically exclude copy protection in the terms of their >>> license? >> They require that it is still possible to debug the LGPLed library in >> the context of the combined work. If there's a debugger killer as part >> of the copy protection (and every effective CP needs one), that's >> obviously not possible. >>> I didn't trust the LGPL when I read it because it was obviously >>> written by a lawyer. Did you mean GTL and type BGL by mistake? >>> >> Yes. I typed BGL for Boost Geometry Library. Isn't one of the geometry >> libraries called that? > > I think it's called ggl, generic geometry library. Boost geometry library would be confusing. > >>> Ideally I'd like to eliminate dependence on big-num for robustness, >>> for performance reasons if not license concerns, but this requires >>> some fancy programming. For instance, the degree-2 predicate of >>> slope comparison requires 65 bits when the input is 32 bit >>> coordinates. >> I'm fairly certain that I don't need that. So it's a question of how >> modular the library is. >> > Well, I have no explicit dependency on big num, just provide the ability to override non-robust arithmetic by specifying a big num data type. I have no direct code dependency on any external library, only the stl. > > What features of a geometry library do you need? I'm always interested to know so that I can focus on the pieces that are (will be) used the most. You can tell me off list if you prefer not to advertise this information. > > Thanks, > Luke > > ------------------------------ > > Message: 6 > Date: Mon, 23 Mar 2009 19:23:06 +0100 > From: Sebastian Redl <sebastian.redl(a)getdesigned.at> > Subject: Re: [boost] Can a Boost library use a component like GMP and > mfpr that have a LGPL license ? > To: boost(a)lists.boost.org > Message-ID: <49C7D38A.8080506(a)getdesigned.at> > Content-Type: text/plain; charset=ISO-8859-1 > > Simonson, Lucanus J wrote: >> What features of a geometry library do you need? I'm always interested to know so that I can focus on the pieces that are (will be) used the most. You can tell me off list if you prefer not to advertise this information. >> > It's pretty vague at this time. We've been doing without, and looking at > it to optimize some algorithms that currently work on rasters. We're > mostly looking for quickly doing many, many polygon intersections in a > huge floating point coordinate system. (Transformed to integer rasters > at a given resolution.) The whole thing is about geographic data. > > Sebastian > > > ------------------------------ > > Message: 7 > Date: Mon, 23 Mar 2009 11:30:38 -0700 > From: "Simonson, Lucanus J" <lucanus.j.simonson(a)intel.com> > Subject: Re: [boost] Can a Boost library use a component like GMP and > mfpr that have a LGPL license ? > To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> > Message-ID: > <26E9B811E137AB4B95200FD4C950886B262115F7(a)orsmsx507.amr.corp.intel.com> > > Content-Type: text/plain; charset="us-ascii" > > Sebastian Redl wrote: >> It's pretty vague at this time. We've been doing without, and looking >> at >> it to optimize some algorithms that currently work on rasters. We're >> mostly looking for quickly doing many, many polygon intersections in a >> huge floating point coordinate system. (Transformed to integer rasters >> at a given resolution.) The whole thing is about geographic data. >> > Do you need map overlay, or is polygon intersection enough? I have both, but most other libraries only provide intersection. > > Luke > > ------------------------------ > > Message: 8 > Date: Mon, 23 Mar 2009 14:38:15 -0400 > From: "Schrader, Glenn" <gschrad(a)ll.mit.edu> > Subject: Re: [boost] Can a Boost library use a component like GMP and > mfpr that have a LGPL license ? > To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> > Message-ID: > <57F5948627B03042A29E70F4AABB446A9311073C9D(a)LLE2K7-BE01.mitll.ad.local> > > Content-Type: text/plain; charset="us-ascii" > > > >> -----Original Message----- >> From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] >> On Behalf Of Sebastian Redl >> Sent: Monday, March 23, 2009 2:01 PM >> To: boost(a)lists.boost.org >> Subject: Re: [boost] Can a Boost library use a component like GMP and mfpr >> that have a LGPL license ? > >> > >> > Huh, they basically exclude copy protection in the terms of their >> license? >> They require that it is still possible to debug the LGPLed library in >> the context of the combined work. If there's a debugger killer as part >> of the copy protection (and every effective CP needs one), that's >> obviously not possible. > > I assume you are referring to the "Combined Works" section of the LPGL. This is the only paragraph I can find containing the string "debug". > > * > * 4. Combined Works. > * You may convey a Combined Work under terms of your choice that, > * taken together, effectively do not restrict modification of the > * portions of the Library contained in the Combined Work and > * reverse engineering for debugging such modifications, if you > * also do each of the following: > * > > The term "Library" means "the library that is licensed under the LGPL". Note that the wording says >debugging< and NOT a >debugger<. Debugging can be carried out in different ways. For instance, the library can be instrumented using printf/cout. While the ability to run a debugger is certainly convenient, I fail to see how this mandates it. Some may object to the reverse engineering clause but its only an issue if reverse engineering is actually needed. If you say up front how you use the library then there should be no need to reverse engineer anything. > >> >> Sebastian >> _______________________________________________ >> Unsubscribe & other changes: >> http://lists.boost.org/mailman/listinfo.cgi/boost > > > ------------------------------ > > Message: 9 > Date: Mon, 23 Mar 2009 19:51:31 +0100 > From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> > Subject: Re: [boost] Can a Boost library use a component like GMP and > mfpr that have a LGPL license ? > To: boost(a)lists.boost.org > Message-ID: <gq8lnj$ii0$1(a)ger.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Sebastian Redl wrpte: > >>> Huh, they basically exclude copy protection in the terms of their license? >> They require that it is still possible to debug the LGPLed library in >> the context of the combined work. If there's a debugger killer as part >> of the copy protection (and every effective CP needs one), that's >> obviously not possible. > > In the case of DRM, the law in some countries requires to provide > information for interoperability on demand anyway, so what the LGPL > requires is actually required for any software in those countries. > > > > ------------------------------ > > Message: 10 > Date: Mon, 23 Mar 2009 15:48:17 -0400 > From: "troy d. straszheim" <troy(a)resophonic.com> > Subject: [boost] [GSOC] 10 Day student application period begins today > To: boost(a)lists.boost.org > Message-ID: <49C7E781.1070600(a)resophonic.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > The window is open another week and a half or so. Deadline: April 3. > > Our first student proposal (py3k support for boost python) arrived > within moments of the start of the application period. > > Don't be shy, keep discussing your ideas, and make some proposals. You > can't get accepted if you don't apply. > > -t > > > > ------------------------------ > > Message: 11 > Date: Mon, 23 Mar 2009 16:48:04 -0400 > From: Qihong Wang <qihongwang(a)gmail.com> > Subject: Re: [boost] How to build 32 bits boost library on a 64 bits > platform > To: boost(a)lists.boost.org > Message-ID: > <cf7fc54c0903231348n7bb3b585k8ac4a71aabbb84d0(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > It works for me. If I just specify address-mode, the library is still 64 > bits. I have to specify both. Before I tried this, I also tried to specify > gcc version and compileFlag and linkFlag as -m32 according to document. That > doesn't work either. > > Thanks Fr?d?ric and Alexander. > > On Mon, Mar 23, 2009 at 4:16 AM, Alexander Arhipenko <arhipjan(a)gmail.com>wrote: > >> On Sat, Mar 21, 2009 at 10:58 PM, Qihong Wang <qihongwang(a)gmail.com> >> wrote: >> > Hello, >> > >> > My platform is a 64 bits Linux with gcc. My program needs to link a 32 >> bits >> > library without source code and other >> > libraries with source code. I wrote a script to build those libraries >> with >> > source code by >> > >> > ./configure --prefix=$install_prefix CFLAGS="-g -O2 -Wall -m32" >> > CPPFLAGS=-m32 CXXFLAGS="-g -O2 -m32" >> > make install >> > >> > Then start to build my executable through Makefile with -m32 flag either. >> > The configure and make install work for other libraries but not work for >> > boost. The boost libraries were compiled and >> > installed but still 64 bits. Linker refused to link it. Is there any >> simple >> > approach to build 32 bits boost on 64 bits Linux? >> > >> > Thanks, >> > >> > Qihong >> > >> >> Passing 'address-model=32 architecture=x86' arguments to bjam works fine >> for me. >> >> Regards >> _______________________________________________ >> Unsubscribe & other changes: >> http://lists.boost.org/mailman/listinfo.cgi/boost >> > > > ------------------------------ > > Message: 12 > Date: Mon, 23 Mar 2009 21:05:06 +0000 > From: "Phil Endecott" <spam_from_boost_dev(a)chezphil.org> > Subject: Re: [boost] "[gsoc] Thread scheduler support for boost" > To: <boost(a)lists.boost.org> > Message-ID: <1237842306073(a)dmwebmail.dmwebmail.chezphil.org> > Content-Type: text/plain; format="flowed" > > Indradip Ghosh wrote: >> I would like to get suggestions on developing a thread scheduler API for >> supporting users having specific needs in prioritizing threads >> running on SMP / Multi-Core processors. Please let me know the >> viability of including such an API in generic boost distribution and >> whether anyone would volunteer to mentor this effort as a GSOC >> project. > > Hi Indradip, > > I have previously looked at passing POSIX thread attributes (i.e. > priority and policy) and it's not much work; presumably it could now be > done using the native handle in the proposed std::thread and new > version of boost::thread. How close to the POSIX semantics does > Windows come? Boost generally prefers to implement portable stuff > (although that's not something I need!) and choosing to work in an area > where the different platforms have little common ground will make > things more difficult for you, unless you're already familiar with how > this stuff works on both POSIX and Windows systems. > > Beyond that there's the area of processor affinity, where as far as I > know POSIX has nothing to say. Linux has some APIs for this but I > doubt they have much in common with any other platforms. Maybe the > Intel TBB library has already solved all of this? > > I'm wondering how something like a thread pool would be extended to > exploit processor affinity, if the lower-level API offered it. > > Do you have a motivating application? > > > Phil. > > > > > > ------------------------------ > > Message: 13 > Date: Mon, 23 Mar 2009 23:57:19 +0100 > From: "vicente.botet" <vicente.botet(a)wanadoo.fr> > Subject: [boost] [interprocess] locked mutex and process killed > To: <boost(a)lists.boost.org> > Message-ID: <D12CA6DE6C6E4902B1170C7ED7F2AD8D@viboes1> > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > > what happens when a process owning interprocess::mutex is killed? is the mutex unlocked before the process dies? > > Thanks, > Vicente > > ------------------------------ > > Message: 14 > Date: Tue, 24 Mar 2009 00:55:18 +0100 > From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> > Subject: Re: [boost] "[gsoc] Thread scheduler support for boost" > To: boost(a)lists.boost.org > Message-ID: <gq97h5$dbk$1(a)ger.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Indradip Ghosh wrote: > >> I would like to get suggestions on developing a thread scheduler API for >> supporting users having specific needs in prioritizing threads >> running on SMP / Multi-Core processors. Please let me know the >> viability of including such an API in generic boost distribution and >> whether anyone would volunteer to mentor this effort as a GSOC >> project. > > Are you suggesting a N:M threading model where you can specify the > userland scheduler? > > > > ------------------------------ > > Message: 15 > Date: Mon, 23 Mar 2009 21:22:06 -0800 > From: "Robert Ramey" <ramey(a)rrsd.com> > Subject: [boost] has_operator_new > To: boost(a)lists.boost.org > Message-ID: <gq9n29$dr4$1(a)ger.gmane.org> > > I've made a TRAK item to request a new type traits feature - > has_operator_new. I've included an implementation and a test - both > type_traitsified. Hope you can see fit to check it out, and if it's OK, > check it in. Let me know when you do this. Once this is in, I can clear a > dependent feature request TRAK item from the serialization library. > > Robert Ramey > > > > > > ------------------------------ > > Message: 16 > Date: Mon, 23 Mar 2009 21:38:54 -0800 > From: "Robert Ramey" <ramey(a)rrsd.com> > Subject: [boost] BOOST_NO_INTRINSIC_INT64_T > To: boost(a)lists.boost.org > Message-ID: <gq9o1p$fkm$1(a)ger.gmane.org> > > boost config includes BOOST_NO_INTRINSIC_WCHAR_T. > > boost Is there any chance we might see BOOST_NO_INTRINSIC_INT64_T > appear in the near future? > > Robert Ramey > > > > > > ------------------------------ > > Message: 17 > Date: Tue, 24 Mar 2009 10:18:25 +0100 > From: Barend Gehrels <barend(a)geodan.nl> > Subject: Re: [boost] Can a Boost library use a component like GMP and > mfpr that have a LGPL license ? > To: boost(a)lists.boost.org > Message-ID: <49C8A561.7010709(a)geodan.nl> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi, > > Fernando Cacciola wrote: >> >> A different and much less ambitious goal could be to come up with a >> good C++ *interface* to *those* libraries. That is, C++ number types >> specifically designed to be implementable on top of a C API like that >> of GMP and MPFR. > This is the approach we planned to take. In our geometry library (GGL) > we want to optionally calculate with large number types as GMP or CLN. > The GGL (or other geometry libraries who might take the same approach) > is completely independant from GMP and from their license. It can just > work together. > > We will work this out in the upcoming preview of GGL. We realize that it > is not applicable for geometry alone, so we make it independant from it > and might submit it as a separate, small, header-only library. The > sample (link below) shows a numeric_adaptor, having a policy of either > gmp, or just ieee types, or other big number types as cln (not worked > out). Other policies might elaborate adaptive precision. > > See > http://geometrylibrary.geodan.nl/num/numeric_adaptor.html > > Details might change of course, such as the place of the member variable > in either adaptor or policy, but the sample will give the general idea. > > Regards, > Barend Gehrels, Amsterdam > Bruno Lalande, Paris > > > > > > > ------------------------------ > > Message: 18 > Date: Tue, 24 Mar 2009 09:08:19 +0100 (CET) > From: solar(a)rootdirectory.de > Subject: [boost] Boost with ICU on AIX - Patch > To: boost(a)lists.boost.org > Message-ID: <20090324080819.1361134C4B8(a)mail.lcube.de> > Content-Type: text/plain; charset="ISO-8859-1" > > Hi there, > > while trying to get Boost 1.34.1 to work on an AIX machine, I > found a bug that still persists in 1.38.0. You might want to fix > this... > > In boost/regex/icu.hpp: > > 314c314 > < typedef std::vector<UCHAR32> vector_type; > --- >> typedef std::vector<UChar32> vector_type; > 318,319c318,319 > < v.push_back((UCHAR32)(*i)); > < ++a; > --- >> v.push_back((UChar32)(*i)); >> ++i; > > It should be obvious once you look at the source environment - > the UCHAR32 is probably a typo, and the ++a is copy-and-paste > work. This has obviously never been test-compiled on a real > machine. Surprising that this has not been caught earlier (since > it's been in there since 1.33)... > > Anyway, with that patch (and a backport of another one on > vacpp.jam that's been included in later versions of Boost), v1.34.1 > compiles cleanly with ICU-support on AIX. > > Regards, > > Martin Baute > > > > > > ------------------------------ > > Message: 19 > Date: Tue, 24 Mar 2009 09:52:36 -0000 > From: "John Maddock" <john(a)johnmaddock.co.uk> > Subject: Re: [boost] has_operator_new > To: <boost(a)lists.boost.org> > Message-ID: <0993906E24C64887BD216A8DA04492EC@acerlaptop> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=response > >> I've made a TRAK item to request a new type traits feature - >> has_operator_new. I've included an implementation and a test - both >> type_traitsified. Hope you can see fit to check it out, and if it's OK, >> check it in. Let me know when you do this. Once this is in, I can clear >> a dependent feature request TRAK item from the serialization library. > > I'll look into it: did you test out the is_virtual_base in SVN type_traits > Trunk BTW? > > John. > > > > ------------------------------ > > Message: 20 > Date: Tue, 24 Mar 2009 11:08:59 +0100 > From: "Edouard A." <edouard(a)fausse.info> > Subject: Re: [boost] [interprocess] locked mutex and process killed > To: boost(a)lists.boost.org > Message-ID: <04ab3291f101326aab20f6b7c4b7253b(a)127.0.0.1> > Content-Type: text/plain; charset="UTF-8" > > On Mon, 23 Mar 2009 23:57:19 +0100, "vicente.botet" > <vicente.botet(a)wanadoo.fr> wrote: >> Hi, >> >> what happens when a process owning interprocess::mutex is killed? is the >> mutex unlocked before the process dies? > > After a quick look at the source code: > > inline void interprocess_mutex::lock() > { > if (pthread_mutex_lock(&m_mut) != 0) > throw lock_exception(); > } > > The answer to your question is "an exception will be thrown" since the call > will return "EOWNERDEAD". > > Generally speaking when a thread terminates while holding a mutex, the > mutex is considered abandoned and shared resources protected by the mutex > are in an undetermined state. Hope you like quantum physics. ;) > > -- > > EA > > > ------------------------------ > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > > End of Boost Digest, Vol 2497, Issue 1 > ************************************** >

2 1

[graph] how to enable GraphML support on Cygwin
by Peter 25 Mar '09

25 Mar '09

Hi When compiling boost 1.38, I get the warning: Graph library does not contain optional GraphML reader I know that I can ignore that warning, but I would like to use the GraphML reader. What do I have to do to install and use it ? Thanks for your help Peter

1 0