- Boost - lists.boost.org

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 01 May '05

01 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 01 May '05

01 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

Boost.Test and gcc-2.95
by John Maddock 01 May '05

01 May '05

I don't know if the following are fixable or not, but there are a few regex lib tests failing on gcc-2.95 with: In file included from /boost/head-regression/boost/boost/test/included/test_exec_monitor.hpp:27, from ../libs/regex/test/object_cache/object_cache_test.cpp:19: /boost/head-regression/boost/boost/test/impl/unit_test_log.ipp: At top level: /boost/head-regression/boost/boost/test/impl/unit_test_log.ipp:37: redefinition of `struct io_saver_type' /boost/head-regression/boost/boost/test/impl/results_reporter.ipp:35: previous definition here /boost/head-regression/boost/boost/test/impl/unit_test_log.ipp:40: confused by earlier errors, bailing out Given that this is an old compiler can these be fixed without undue heroics? Thanks, John.

2 2

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

30 Apr '05

----- Mensaje original ----- De: Bronek Kozicki <brok(a)rubikon.pl> Fecha: Viernes, Abril 29, 2005 6:36 pm Asunto: Re: [boost] Re: [test][comeau] problem with va_list > Quoting Edward Diener <eddielee(a)tropicsoft.com>: > > For whatever reason, although #include <cstdarg> is in the > source file, > > when the Comeau compiler is executed it never actually includes the > > file. This must be a bug in the Comeau compiler but perhaps Greg > Comeau> has a fix for it. > > Do you have libcomo31 properly installed and built? Did you try > "Hello world" > using iostreams? > > Broneck, if I'm not wrong you have access to a properly setup Comeau environment. It'd be great if you could apply a patch to your local version of boost/test/impl/test_tools.ipp and see what happens. The patch reduces to issuing a namespace std{using ::va_list;} for the Comeau compiler. If this works, a lot of tests that are currently failing because of this single problem could clear up (or at least progress to some further error.) If the patch works, there's still the issue of tuning the workaround: is it a problem with all versions of stdlibcomo, under any backend? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 5

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

30 Apr '05

----- Mensaje original ----- De: Gennadiy Rozental <gennadiy.rozental(a)thomson.com> Fecha: Sábado, Abril 30, 2005 8:32 pm Asunto: [boost] Re: Re: [test][comeau] problem with va_list > > 1. Replace <cstdarg> with <stdarg.h> > > 2. Remove std:: qualifications for all entities belonging > > to <cstdarg> > > Done. Committed in cvs. > > Gennadiy Thank you! Let's see if this improves regression results on the next turnaround. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0