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

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

[mpl] int_<INT_MIN> fails to compile under gcc 4.6
by Stirling Westrup 06 Mar '11

06 Mar '11

I'm not actually sure if this is a gcc regression, or a bug in mpl, but the following code, which compiles under gcc 4.5, doesn't do so under gcc 4.6: #include <climits> #include <boost/mpl/int.hpp> typedef boost::mpl::int_<INT_MIN> Foo; Foo f; It produces the errors: /usr/local/include/boost/mpl/aux_/integral_wrapper.hpp: In instantiation of ‘mpl_::int_<-0x00000000080000000>’: test_test.cpp:8:27: instantiated from here /usr/local/include/boost/mpl/aux_/integral_wrapper.hpp:73:96: error: ‘2147483647’ is not a valid template argument for type ‘int’ because it is a non-constant expression /usr/local/include/boost/mpl/aux_/integral_wrapper.hpp:73:96: error: overflow in constant expression [-fpermissive] I've already created a trak ticket for this (#5268), but was wondering if anyone had any insights as to its cause and/or any workarounds. My guess is that its related to gcc rewriting parts of its constant folding code to support constexpr. -- Stirling Westrup Programmer, Entrepreneur. https://www.linkedin.com/e/fpf/77228 http://www.linkedin.com/in/swestrup http://technaut.livejournal.com http://sourceforge.net/users/stirlingwestrup

4 6

TR1 and BOOST_HAS_GCC_TR1
by Mathias Gaunard 06 Mar '11

06 Mar '11

With GCC, TR1 only calls the native TR1 implementation if BOOST_HAS_GCC_TR1 is defined. Isn't it time we get rid of this macro?

2 3

[regex] embed string/char in regex w/o escaping?
by Arno Schödl 06 Mar '11

06 Mar '11

As far as I can see, there is no way to embed a plain string into a regex, without escaping the string. Same with characters. Isn't that a bad omission for a library that becomes the new C++ standard? Escaping something just to unescape it on the other end of the function call seems unnecessary, and it opens up the possibility of ills like regex code injection if someone forgets to escape or does it wrong. I know about Boost.Xpressive, but that won't be the new standard. This is not a lobbying effort for Boost.Xpressive. I have never used it precisely because I wanted to stick to the standard. Now I am a bit worried about pouring something into C++ standard concrete that has a pretty obvious omission in it. 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

4 5