- Boost - lists.boost.org

Boost.Polygon issues
by Barend Gehrels 07 Mar '11

07 Mar '11

Hi Luke, You asked me on the GGL mailing list ( http://bit.ly/hCwdJx ) to verify tests using Boost.Polygon to check Boost.Geometry's behaviour at some points. I cannot reach that point. I ported a test that I already had (recursive polygons) to Boost.Polygon. I'm using the Polygon Set Concept with integer coordinates. Actually all input is in the 90/45 degree range. If I run the program, it often gives me the wrong results, even in the simpler cases. And often it just crashes, in the line 1748 of file polygon_arbitrary_formation.hpp (called from the area function) I extracted two (wrong but not crashing) cases. Source code here: http://bit.ly/fCYRWL Summary of second case: area p: 45000 area q: 55000 area intersection: 0 area union: 60000 The last one, area of union, should be 100000, if the intersection is zero, the union contains everything and its area therefore should sum to 100000 Regards, Barend

2 2

[Polygon] Unqualified name lookup of 'gtlsort' in templates
by Doug Gregor 07 Mar '11

07 Mar '11

The Polygon library has a minor C++ standards-conformance issue w.r.t. unqualified name lookup in templates for 'gtlsort' operator. In particular, the header <boost/polygon/polygon.hpp> includes a number of source files that make unqualified calls to 'gtlsort'. 'gtlsort' itself is not defined until much later, when <boost/polygon/detail/scan_arbitrary.hpp> pulls in <boost/detail/polygon_sort_adaptor.hpp>. At least in the cases used in the Boost.Polygon test, 'gtlsort' isn't found by ADL at instantiation time, either. Clang detects this conformance problem, which is described here: http://clang.llvm.org/compatibility.html#dep_lookup The solution is to provide forward declarations of the two 'gtlsort' overloads in a header that all users of 'gtlsort' depend on. For example, introducing a forward header containing namespace boost { namespace polygon { template <typename iter_type> void gtlsort(iter_type _b_, iter_type _e_); template <typename iter_type, typename pred_type> void gtlsort(iter_type _b_, iter_type _e_, const pred_type& _pred_); } } and including it before the users of 'gtlsort' would work fine. - Doug

2 1

Re: [boost] [xint] Boost.XInt formal review (concrete complaint)
by Ivan Le Lann 07 Mar '11

07 Mar '11

----- "Peter Dimov" <pdimov(a)pdimov.com> a écrit : > Ivan Le Lann wrote: > > > Useless sarcasm aside, isn't that an abuse of atomics? > > Reference counting an abuse of atomics? It's one of the primary use > cases for them. > I was not challenging the fact to use atomics to refcount. I was challenging the "Let's refcount since it can be atomic!". Atomics are a heavy dependency, and they're not free. In the end, that's still about challenging COW. Point is I'd hate to hear in a few years that C++ is "that language where you have to do atomics to add two 512bits integers". But I'm probably wrong about all this, Ivan

1 0

[xint] Utility question, how to implement...
by Rene Rivera 07 Mar '11

07 Mar '11

Chad, Unfortunately I don't have time to do a review of your library (even a quick one). But I do have one question... In my general code library I have an implementation of a one-way-accumulator based on the facilities provided by the Botan library. It's an algorithmically efficient implementation using Barrett reducers for modulo exponentiation with small bases and large exponents. My question is: How would I go about implementing the equivalent in your library? NOTE: I can post my code if need be to make this a clearer question. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

3 7

Re: [boost] [xint] Boost.XInt formal review
by Dick Bridges 07 Mar '11

07 Mar '11

This is not a review, simply a question with regard to the default_random_generator constructor. If I'm reading random.hpp correctly, there is no way for a user to provide the seed value - a useful feature for folks like myself that use PRNGs to model stochastic processes. We frequently need to repeat a particular sequence of 'random numbers'. Any chance the seed could be passed as a parameter defaulted to the existing hard coded time/clock? As long as I'm asking, perhaps the ability to provide a special-purpose generator of our own design? I'd also like to express my appreciation for the effort you've obviously expended on this project. Thank you. Dick Bridges Western Digital Technologies, Inc. The opinions and data in this missive are my own and do not necessarily represent Western Digital positions, strategies, or opinions.

3 7

Re: [boost] [xint] Boost.XInt formal review
by Ivan Le Lann 07 Mar '11

07 Mar '11

----- "DE" <satan66613(a)yandex.ru> a écrit : > on 07.03.2011 at 9:17 > Jeffrey Lee Hellrung, Jr. wrote : > > Another concern with COW in general is iterator invalidation. Either > > your iterator gets "fatter" and slower (e.g., by being implemented as a > > pointer to the object + offset), or you expand the class of operations > > that invalidate iterators beyond just resizing operations to *any* > > modification operation (compared to a class which does not use COW). > > been the cow atomically ref counted you will NEVER notice it's there I can't wait for the day "atomic free" will be a marketing point, just like "lock free" is today. > think of it: if an operation requires reallocation of the storage > then anyway iterators are invalidated Without COW, the iterators used in another thread are not invalidated, since no data is shared. Anyway, this whole thing sums up to: let me choose the container that suits my needs. Ivan

3 2

[Filesystem V3] path and ostream
by Juraj Ivančić 07 Mar '11

07 Mar '11

During the switch from Filesystem V2 to V3 I was bit by the new operator<<( basic_ostream<...> ) behaviour. The problem is that in V3 the path gets quoted when being output to the stream (and '&' is used as an escape character). This breaks the invariant which used to hold until now: std::stringstream stream; stream << path; assert( stream.str() == path.string() ); I have made the adjustments to my code, but I find this behaviour a bit surprising and was interested in the rationale for this decision. I could not find it on the Boost Filesystem home page. The only reason I could fathom is so that one can do this: std::stringstream stream; stream << path1 << path2; stream >> path3 >> path4; assert( path1 == path3 ); assert( path2 == path4 ); If so - I know several platforms where this will generally fail, as both & and " are legal characters in file names. Thank you for your response.

1 0

what tasktracker do you use?
by DE 07 Mar '11

07 Mar '11

hi all i recently began to use a task tracking and issue tracking system for the work project and i'm interested if anyone use some sort of such tools so the question: what task tracking and/or issue tracking system do you use for your own projects? let me know if this mailing list is the wrong place for this topic -- Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out

4 5

[context][fiber] implementation comments
by Charlls Quarra 07 Mar '11

07 Mar '11

Hi Oliver, I have a couple of comments on implementation context: i noticed you migrate out of the context::create idiom and now context is noncopyable, so it seems right now the only way to have a recyclable context as a member is hold a pointer/ref and allocate on the heap. This might be good for most use cases (which is probably the boost design principles) but i think it leaves out cases where, due to performance constraints, one either wants to recycle a context without touching the heap. Which leaves me to my other comment; could you add an template parameter for a allocator class so all new/delete operations are delegated to it? fiber: this applies here too; can you make the fiber take template parameters for the stack type and possibly use an allocator parameter to delegate all new/delete operations? currently fiber is couple to boost::context::protected_stack again, thanks for your work on the context and fiber libraries Charles J. Quarra

5 20

[range] transform surprise
by Neal Becker 07 Mar '11

07 Mar '11

I'm surprised that boost::range::transform args are template< class SinglePassRange1, class OutputIterator, class UnaryOperation > OutputIterator transform(const SinglePassRange1& rng, OutputIterator out, UnaryOperation fun); I would have expected: template< class SinglePassRange1, class SinglePassRange2, class UnaryOperation > OutputIterator transform(const SinglePassRange1& rng, SinglePassRange2& out, UnaryOperation fun); Why the asymmetry?

3 2