April 2008 - Boost - lists.preview.boost.org

[1.35] range::end(const char *) no longer supported?
by Mat Marcus 04 Apr '08

04 Apr '08

In 1.34.1 we rely on boost::range::begin/end for const char* . That is we can invoke something like: const char* range= "foo"; std::copy(boost::begin(range), boost::end(range), result); In 1.35.0, under MSVC 9.0, code similar to the above. Are there known issues with range::end(const char*) in 1.35.0 (e.g. no longer supported), or do I need to explore further? Thanks, Mat

4 6

[1.36.0] Release management team
by Beman Dawes 04 Apr '08

04 Apr '08

To eliminate any delay in starting work on 1.36.0, I propose that the 1.35.0 release management team remain in place for 1.36.0. Roughly, that's: * Beman Dawes, acting as overall release manager, * Rene Rivera, working on web site and build and/or test scripting, * Daniel James, working documentation issues, * John Maddock, helping with miscellaneous issues, * Marshall Chow, running periodic trac reports. And, of course, there are a whole bunch of other Boosters running tests and working on individual libraries. The release management process is getting smoother, so I hope the time demands on the release management team will stay light enough that we can keep the team intact for several releases. The one other position I'd like to see added to the team is someone to concentrate on regression testing results. The basic task is to keep an eye on the regression reports, and intervene whenever any deterioration seems to be occurring without anyone else apparently taking any action to correct the problem. "Intervene" mostly means pestering the problem's owner, but sometimes might be to suggest and/or implement procedural improvements to attack global problems. Anyone care to volunteer? Comments? --Beman

3 2

Giving names to formal parameters of lambda expressions: a named placeholder trick.
by Giovanni Piero Deretta 04 Apr '08

04 Apr '08

One thing that has always bothered me of the various boost lambda abstractions (be them compile time lambdas a-la mpl or runtime lambdas a-la Boost.Lambda, phoenix or plain bind) is that you must use non descriptive names for your argument paceholders. What I would like is to be able to declare the names of the formal parameters of my lambdas. Sure, in mpl you can have your placeholder names by typedef-ing the standard placeholders to a new name; with runtime lambdas, you can create custom objects with the same type of standard placeholders. In all those cases you still need to declare them outside of the lambda expression. While reading the Proto example "Vector: Adapting a New Terminal Type", I discovered something new about C++: you can forward declare class names inside a template parameter declaration. That is, something like this is actually possible: void foo () { int i = lambda // introduce formal parameter names [ _<class left>(), _<class right>() ] // now use them! [_<left>() + _<right>()] // actual parameters values ( 10, 20 ); } The _<...>() looks a bit clumsy, but it might be actually usable. I think that such a trick might really shine with the so called "round lambda"s; in the past I have toyed with a template class 'compose' that used the round lambda syntax for functional composition: Assume you have two polymorphic function objects types that work on ranges called 'fold' and 'reverse' (which do the obvious thing implied by their names): struct reverse_fold { template<typename Sig> struct result; template<class Range, class Init, class Op> struct result<reverse_fold(Range, Init, Op)> { private: typedef typename boost::result_of<reverse(Range)>::type reversed; public: typedef typename boost::resuld_of<fold(reversed, Init, Op)>::type type; }; template<class Range, class Init, class Op> typedef typename result<reverse_fold(Range, Init, Op)>::type operator()(Range const& range, Init i, Op op) const { return fold()(reverse()(range), i, op); } }; could be rewritten, using 'compose', as: typedef compose<fold(reverse(_1), _2, _3> reverse_fold; Which saves quite a bit of typing! (of course it works only with stateless function objects). Still the non-descriptive _N placeholders bother me. Using the named placeholder trick it would become: typedef compose< // introduce formal args names args< class range , class init , class op > // expression , fold(reverse(range), init, op) // function name > reverse_fold; With complex expressions, this could be quite a readability improvement. Except for confirming that the above expression does actually compile (at least with gcc), I have yet to try to implement it, but I think it should be fairly easy. Comments? -- gpd

5 32

Re: [boost] [1.36.0] High priority compilers for this release?
by Boris Gubenko 03 Apr '08

03 Apr '08

Beman Dawes wrote: > Good! Let me know which GCC version you settle on. Will do. > I'd like a Linux/ia64 release tester. Whichever version makes the most > sense. If you could handle the release testing for that. Yes, I can. Again, I'll see if we can upgrade to a more recent version of GCC on this Linux machine. Thanks, Boris

1 0

new macro request
by Eames, Andrew 03 Apr '08

03 Apr '08

Hi, In shared_ptr.hpp, line 560 there is code that reads #if defined(__GNUC__) && (__GNUC__ < 3) template<class Y> std::ostream & operator<< (std::ostream & os, shared_ptr<Y> const & p) { blah blah blah Can we have a boost macro for this that says whether we have old style iostreams (or is there one I missed? - the closest I could find was BOOST_NO_STRINGSTREAM) so I can compile this on my cheesy compiler without having to edit the boost source? (This was the only compilation error I got on upgrade to 1.35 with my unsupported embedded compiler) Thanks Andrew

2 2

Re: [boost] [1.36.0] High priority compilers for this release?
by Boris Gubenko 03 Apr '08

03 Apr '08

Beman Dawes wrote: > Boris, which HP compiler/platform combinations would you like to support > for 1.36.0? HP-UX/aC++ (toolset acc) and HP-UX/gcc (toolset 4.2.1_hpux_ia64). As the name suggests, for now, I'm using GCC 4.2.1, but I'll see if we can upgrade to GCC 4.3.0. I also run tests on Linux/ia64/GCC 3.4.6, but since other people test this combination also, I'm not sure if it makes sense for me to continue to run tests on this platform and/or ask to make it a supported platform in 1.36. What do you think? And yes, I can run both trunk and release tests. Thanks, Boris

2 1

XML Attributes issue
by Lakshmi Narasaiah 03 Apr '08

03 Apr '08

Hi, We are using boost library to serialize C++ object to XML format. Though the boost library does a good job in converting the class variables to name value pair we do not know how to add attributes to the nodes. Also we do not know for instance if an XML file already exists how to insert child nodes. Any help here would be appreciated. Regards, Lakshmi --------------------------------- Now you can chat without downloading messenger. Click here to know how.

2 1

Re: [boost] [1.36.0] High priority compilers for this release?
by Boris Gubenko 03 Apr '08

03 Apr '08

John Maddock wrote: > [...] Incidently, it's good to have at least one > EDG based front end in our official support list, even if it does > emulate > the MSVC bugs ;-) HP aC++ (toolset acc) is EDG based compiler. So is cxx on Tru64, but the latter is not an officially supported compiler in 1.35 (it is in 1.34). Boris

2 1

[iostreams] Online docs have lost the menu contents on the left
by eg 03 Apr '08

03 Apr '08

Is it my imagination, or id the 1.35 online documentation for iostreams lose the navigation menu in the left side frame window. When I view http://www.boost.org/doc/libs/1_35_0/libs/iostreams/doc/index.html It shows a frame on the left which only contains the boost logo, the heading Boost.iostreams and a horizontal line underneath and nothing else. My local copy of 1_34_1 of this library shows a full contents menu on the left hand frame underneath the horizontal line for navigation. Without this contents menu, it is very difficult to navigate through these documents. I have tried viewing this in firefox 2.0x, IE 6, and IE 7 and the results are the same.

3 4

shared_ptr 1.35.0 problem on SPARC
by Peter Dimov 03 Apr '08

03 Apr '08

Joe Gottman reports in: http://svn.boost.org/trac/boost/ticket/1758 that 1.35.0 fails to build with gcc 3.4 on SPARC Solaris. The problem is that there is no way to autodetect whether the V9 instruction set has been selected in 32 bit mode, because GCC only defines __sparcv8 for compatibility reasons. Since most (all?) SPARCs where Boost runs are UltraSPARCs, which do support V9, we can fix this by making the V9 instruction set default. I see in gcc.jam the following lines: cpu-flags gcc OPTIONS : sparc : c3 : -mcpu=c3 : default ; cpu-flags gcc OPTIONS : sparc : v7 : -mcpu=v7 ; cpu-flags gcc OPTIONS : sparc : cypress : -mcpu=cypress ; cpu-flags gcc OPTIONS : sparc : v8 : -mcpu=v8 ; cpu-flags gcc OPTIONS : sparc : supersparc : -mcpu=supersparc ; cpu-flags gcc OPTIONS : sparc : sparclite : -mcpu=sparclite ; cpu-flags gcc OPTIONS : sparc : hypersparc : -mcpu=hypersparc ; cpu-flags gcc OPTIONS : sparc : sparclite86x : -mcpu=sparclite86x ; cpu-flags gcc OPTIONS : sparc : f930 : -mcpu=f930 ; cpu-flags gcc OPTIONS : sparc : f934 : -mcpu=f934 ; cpu-flags gcc OPTIONS : sparc : sparclet : -mcpu=sparclet ; cpu-flags gcc OPTIONS : sparc : tsc701 : -mcpu=tsc701 ; cpu-flags gcc OPTIONS : sparc : v9 : -mcpu=v9 ; cpu-flags gcc OPTIONS : sparc : ultrasparc : -mcpu=ultrasparc ; cpu-flags gcc OPTIONS : sparc : ultrasparc3 : -mcpu=ultrasparc3 ; The default instruction set seems to be "c3", which results in -mcpu=c3. What is -mcpu=c3? It's not documented anywhere. Can we move the "default" to the v9 line?

2 1