- Boost - lists.boost.org

[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

[network] 0.9-devel and BOOST_NETWORK_NO_LIB
by Dean Michael Berris 07 Mar '11

07 Mar '11

Hi Everyone, I just recently finished a consulting project that tied me up good the past three months. Now that I'm pretty much free again to work on cpp-netlib, I went for the things that have been brought up most recently on the list (and the Boost developers mailing list): 1. The server tests that used a different port each, configurable at the command-line with a default. This is already in 0.9-devel. 2. An option to turn off the required external library to be linked with a macro (BOOST_NETWORK_NO_LIB). With this macro defined before any cpp-netlib headers are included (or on the command line) the functions that were made extern or just free functions at namespace level are marked 'inline' and have their definitions pulled in accordingly in each translation unit. This addresses Jeff Garland's and others' concern of the need for an external library when using cpp-netlib when it's always been header-only until 0.9. I'm still wrestling with the thought of making the header-only behavior a default, but I'm not married to the "external library as default" decision either. 3. A consistent look/view between server-side request/response objects and client-side request/response objects. Now they can be dealt with using the same directives and modifiers. 4. Starting to change the library name to Boost.Network (after the suggestions). #2 is still undocumented, but I am going to be including a Doxygen-Sphinx bridge that would allow us to write documentation in-line on the types and have Doxygen invoked when the Sphinx documentation is built. I found a Sphinx extension to do that and it looks like it can be bundled with cpp-netlib as well (because it's under a BSD license) -- it's called "breathe" and can be found here: http://michaeljones.github.com/breathe/ #3 has been in the branch for a while already and it should be doable to back-port some of the things to the 0.8 line. #4 is largely a documentation matter. I have decided that in order for the development of the network library to scale, that I would spear-head a mini-community effort that would be called "The C++ Network Library Project" taking in a diplomatic and consensus-building approach. This way those willing to contribute to the effort can help with setting the direction of the library, the design decisions, etc. with me starting as the "benevolent dictator" and letting more people jump into the fray and becoming co-maintainers and regular contributors. There are already a couple of people (Oleg Malashenko and Emre Turkay) who have recently contributing to the project that I would like to thank, and also give the chance to get a bigger role in the development of the library going forward. So for now the focus is still to get a review-ready library for inclusion in Boost that would be called Boost.Network. I think 0.9 will be ready in a couple of days and will be a the pre-1.0 snapshot that will be submitted for review, getting all the required documentation in place. At this time I'm still looking for able and willing review managers. Feedback would be most definitely appreciated. -- Dean Michael Berris http://about.me/deanberris

1 0