May 2005 - Boost - lists.boost.org

[ios_state] CodeWarrior and many errors because of locale..
by Rene Rivera 02 May '05

02 May '05

As others have pointed out there were a number of "mysterious" errors having to do with multiply defined symbols during link. The problem was in the Boost.Test library which was indirectly relying on std::locale support. The indirect part is that it's using boost/io/ios_state.hpp which *assumes* that std::locale is available. Anyway.. I've checked in changes to make ios_state.hpp compile in the face of missing locale support. Basically I just conditionally remove the part that use std::locale based on the BOOST_NO_STD_LOCALE config macro. I also removed the Boost.Test change that causes the multiple symbols. I don't know how many libraries and compilers this affects. But if you are running incremental tests, expect your next run to be considerably longer as it's going to recompile Boost.Test. Which will likely recompile everything else. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

1 0

[boost.range] cw 8.3 test
by Thorsten Ottosen 02 May '05

02 May '05

Hi, Does anyone know why the output from cw8.3 is so wierd: http://tinyurl.com/77hhw ? Thanks -Thorsten -- Thorsten Ottosen ---------------------------- www.dezide.com http://www.cs.aau.dk/index2.php?content=Research/mi www.boost.org www.open-std.org/JTC1/SC22/WG21/

2 1

[como working with boost.test and more]
by Thorsten Ottosen 02 May '05

02 May '05

Thanks to those responsible for getting como to work again on the cvs with test and type-traits being problematic lately. It saves me a great deal of time when I can ask como to pick up the stupid errors in my source. best regards Thorsten -- Thorsten Ottosen ---------------------------- www.dezide.com http://www.cs.aau.dk/index2.php?content=Research/mi www.boost.org www.open-std.org/JTC1/SC22/WG21/

3 2

building container on stack (var arg)
by Eric Zijlstra 02 May '05

02 May '05

I was looking for a convinient way to have variabele arguments for functions and avoiding the memory allocations and copying that come with std containers. I didn't find such a container so I hacked one together myself. The container builds a linked list by storing pointers to the arguments in temporary node objects (StackArg). The list becomes invalid as soon as the nodes go out of scope. A test showed that this was 5 times faster than using a std::vector. I don't have access to the code ATM, but look below how it looks like (very shortend). Ofcourse, the + operator is misleading (the leading empty StackArg<>() clarifies a lot) but otherwise it's pretty convinient. template<class T> class StackArg { public: StackArg *link; T *data; StackArg() link(0), data(0) {} StackArg(StackArg *prev, T *t) :link(prev), data(t) { } StackArg operator + (T &t) { return StackArg(this, &t); } iterator begin(); iterator end(); }; The first time when begin() or end() is called, the list is reversed because since operator+() is evaluated from left to right, the last element becomes the container handle (s in code below). // usage example: void print(StackArg<const int> s) // outputs 345 { StackArg<const int>::iterator i= s.begin(), e=end(); while(i!=e) cout << *i++; } void test() { print( StackArg<const int>() + 3 + 4 +5 ); }

2 2

Re: range_ex
by Eric Niebler 02 May '05

02 May '05

"Thorsten Ottosen" wrote... > > "Gennadiy Rozental" <gennadiy.rozental(a)thomson.com> wrote... > | > | I believe we should move this discussion into separate thread. > | FOREACH is under review now and range_ex is not even requested yet. > | If we want it to be reviewed the first step in this direction could > | be to request one. > > Then I request a review :-) > > Eric, please just respond privately or in a new thread. > > -Thorsten I don't believe it's ready for that. You may feel you know the answers to those design questions, but I'm less confident, and I would like more feedback. Besides, Dave A. has been working in this space, and if a unified approach to range algorithms can be found, that would be preferable. If no such unified approach can be found, I want to know that it has at least been explored. If you would like to drive the development of range_ex, be my guest. -- Eric Niebler Boost Consulting www.boost-consulting.com

2 1

[ptr_container] missing style sheet in docs.
by John Maddock 02 May '05

02 May '05

The ptr_container docs reference the style sheet libs/ptr_container/doc/style.css, which is not in cvs, is this waiting to be checked in, or should it be using boost.css instead? Thanks, John.

2 1

[MPL] How to Derive from inherit_linearly generated class?
by Rick Sloan 01 May '05

01 May '05

Hello all, Given a mpl::list typedef mpl::list<structA, structB, structC> typeList; and a wrapper struct template <class T> struct wrap { virtual void someFunction(T&) = 0; virtual ~wrap } You can generate a class by mpl::inherit_linearly<typeList, mpl::inherit<wrap<_2>,_1> >:;type generated; This is pretty much straight from "C++ Template Metaprogramming" pg. 193-194. My question is how do you generate the derived concrete class? I can override any particular function by struct Child : public generated { virtual void someFunction(structA&); } but I can't seem to generate an entire class. I apologize if this is a newbie question, but alas I am a newbie to template metaprogramming. Regards, Rick Sloan

1 0

Steps before moving to Subversion
by Beman Dawes 01 May '05

01 May '05

Dave Abrahams, Doug Gregor, Thomas Witt and I talked about moving to Subversion when we got together at the C++ committee meeting last week. (I've been using Subversion on my machine for about a month, and quickly became convinced it is superior to CVS.) Points discussed included the importance of a slow, step-by-step approach, because of the importance to Boost and to individual developers, and the need to build familiarity before diving in head first. Doug Gregor will lead the effort, and will be the contact at IU when issues arise. Hopefully Troy Straszheim can help, given that he has already setup a Boost SVN repository. Some of the possible tasks to be accomplished before a final conversion: * Research any remaining questions from Boosters regarding Subversion. * Decide on the repository directory structure - follow Troy's lead or maybe something else? (One of the advantages of Subversion is that the repository directory structure isn't hard-wired, but that means we have to decide which approach is best.) * Set up a trial repository, like the one Troy set up, but on the actual machine at IU. * Set up write authorization. This might be a good time to prune the write-access list to those still active. * Load test. (Maybe set a time, and have a bunch of Boosters hit the repository at the same time?) * Make final go/no-go decision. This probably involves both discussion on the list and polling the moderators (as the closest thing we have to a steering committee.) * Put change notifications in place. * Verify that backup (tarball or whatever) procedures are in place and functioning. * Update Boost documentation which refers to the source repository. * Schedule and execute the actual changeover. Comments? --Beman PS: The book "Version Control with Subversion" by Collins-Sussman, Fitzpatrick, and Pilato, is worthwhile, either in hard copy (O'Reilly) or download from http://svnbook.red-bean.com/

14 28

Re: [boost] Re: [test][comeau] problem with va_list
by JOAQUIN LOPEZ MU?Z 01 May '05

01 May '05

----- Mensaje original ----- De: Edward Diener <eddielee(a)tropicsoft.com> Fecha: Miércoles, Abril 27, 2005 10:25 pm Asunto: [boost] Re: [test][comeau] problem with va_list > JOAQUIN LOPEZ MU?Z wrote: > > Current tests for Comeau 4.3 show this problem: > > > > "G:\boost\boost/test/impl/test_tools.ipp", line 136: error #135: > > namespace > > "std" has no member "va_list" > > std::va_list args; > > > > Looks like va_list is not properly injected into std:: > > (yet BOOST_NO_STDC_NAMESPACE is *not* defined > > for this platform, and I guess for a good reason.) > > I've googled for this and found some discussions at the > > Boost list on the very same problem, with no definitive > > answer :( > > > > 1. Could anyone take a look at Comeau stdlib <cstdargs> > > and see what's going on? > > It is <cstdarg>, and in libcomo for Comeau 4.3.3 I see: > > #include <stdarg.h> > > namespace std { > > using ::va_list; > > } > > Comeau uses the back end compiler for the C headers, such as > stdarg.h, > although it provides a few of its own for various compilers > evidently to > make up for some compiler deficiences. I do not see any stdarg.h > among > the latter. What is the back end compiler being used for the > failing test ? > VC 7.1. The offending file seems pretty straightfoward (http://tinyurl.com/e27be) so I don't really have a clue what's going on... Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 12

broken links in ublas docs
by John Maddock 01 May '05

01 May '05

Several of the ublas doc pages reference the file: libs/numeric/ublas/doc/c++boost.gif which does not in fact exist, I assume these links should point to boost.png now? Any chance of the authors fixing this up? Thanks, John.

1 0