- Boost - lists.boost.org

[interfaces] would the following work?
by Joaquín Mª López Muñoz 11 May '05

11 May '05

Is (the proposed) Boost.Interfaces lib able to handle the following scenario? template<typename T> interface IIterator { T& operator*()const; ... }; template<typename T> interface IContainer { IIterator<T> begin(); IIterator<T> end(); ... }; It is not the issue of specifying an operator as part of the interface IIterator (this'll be taken care of in the future according to the docs), but the fact that IContainer::begin is required to return an object implicitly convertible to IIterator<T>. Can Boost.Interfaces do that? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo PS: Just for motivation, I' thinkthi s idiom could be taken advantage of in a possible implementation of a dynamic multi-index container.

1 0

Re: [mpl] Math sublibrary: new version.
by Cromwell Enage 11 May '05

11 May '05

--- Andy Little wrote: > > There may be an implementation of gcd<> that is > > more efficient even if it works solely on > > big_integral<> numbers. > > Surely it would make sense to specialise this for > big_integral. Yes. > > Or there may not, but for now, I shouldn't rule out > > anything that promises to make big_integral<> > > operations less expensive. > > But these operations will now be unneccessarily > expensive for small_int types. Then there should be a gcd specialization for them, too, right? One that doesn't require recursive apply2<> calls? > Your version of gcd looks is obviously optimised > for big_integral. Really? I haven't even taken advantage of anything that's specific to big_integral<>, but okay... ...if I ever get big_integral<> to work. > However my requirements on rational would be for a > large number of smallint types. I hope you will take > this into account in the design and favour the > implementation more towards small_int types as well. Okay. > OK maybe that would be quicker, and give better error > messages. But you will need a tag dispatch mechanism > anyway wont you?, to avoid a large number of > specialisations. Yes. Like I said, I'll do that. Cromwell D. Enage Discover Yahoo! Find restaurants, movies, travel and more fun for the weekend. Check it out! http://discover.yahoo.com/weekend.html

1 0

[patch, boost.regex] Kill warning when compiling without exceptions
by larsbj＠gullik.net 11 May '05

11 May '05

This is the only warning I get when compiling the subset of boost that is included in LyX. Would be nice to see this in 1.33. This is with gcc 3.3.3. diff -ru --exclude=CVS boost/boost/regex/v4/basic_regex_parser.hpp lyx-upboost/boost/boost/regex/v4/basic_regex_parser.hpp --- boost/boost/regex/v4/basic_regex_parser.hpp 2005-05-09 10:35:34.000000000 +0200 +++ lyx-upboost/boost/boost/regex/v4/basic_regex_parser.hpp 2005-05-10 22:27:37.124642889 +0200 @@ -147,6 +147,8 @@ template <class charT, class traits> void basic_regex_parser<charT, traits>::fail(regex_constants::error_type error_code, std::ptrdiff_t position) { + // Avoid warnings when compilinging without exceptions. + (void)position; if(0 == this->m_pdata->m_status) // update the error code if not already set this->m_pdata->m_status = error_code; m_position = m_end; // don't bother parsing anything else -- Lgb

2 1

[mpl] Math sublibrary: new version.
by Cromwell Enage 11 May '05

11 May '05

--- Dan Perry wrote: > I need some sort of compile time float type that > supports multiplication and division. I found your > comments on the gmane.comp.lib.boost.devel newsgroup > via google but I can't access your mpl_math.zip > file. Could you send me your source? Thanks. The file has a new home. Go to <http://boost-sandbox.sourceforge.net/vault/>, look under the subdirectory "expaler", and download from there. Major issues: 1. The big_integral<> numeric "metatype" is still a compiler resource hog. If I could use list<> instead of vector<>, I may be able to make it more efficient. To do so, I would need to know how to iterate through two lists "concurrently" instead of one list at a time. Aleksey Gurtovoy, any pointers? 2. The most recently added numeric metafunctions, which are square_root<>, exponent<>, sine<>, cosine<>, arctangent<>, hypersine<>, and hypercosine<>, are either insufficiently tested or not tested at all. 3. The numeric_caster_rt facility probably needs a more appropriate name. It is untested with wrt boost::rational as the ResultType. It is also non-functional wrt complex_number<>, at least until I figure out how to use std::complex. 4. Documentation should be available in the next version. For now, the source code, examples, and test programs will have to suffice. Andy Little wrote: > Why not call this one mixed_number? Okay, your suggested name changes have been applied. Also, except for big_integral<>, the NumberSign parameter is now removed. Examples: rational<int_<11>,integral_c<long,16> > rational_c<long,-9,5> mixed_number<long_<2>,int_<54>,integral_c<int,100> > mixed_number_c<int,0,-2,5> The following expressions are currently illegal: rational<int_<1>,int_<0> > rational_c<long,9,-5> mixed_number<long_<3>,int_<-1>,integral_c<int,2> > mixed_number_c<int,0,6,5> I'm currently debating with myself about whether to make aux::rational2mixed_number<> part of the public interface; and if so, whether to rename it to something more legible; or if not, whether mixed_number<> and mixed_number_c<> should take default parameters. > IMO the rational Concept should hold independent of > the exact parameters. The types used for the > parameters are a trade off between using small_ints > and having a relatively quick compile with the > possibility of everflow, as against big_integers with > long compile (and posibly run) times. Actually only the relationship between the concept and the implementation models was dependent on the parameter "metatypes". But I know what you meant, so don't worry about it. > However in a large number of cases a rational has > known bounds, so an inbuilt int has ample range. Yeah. It's when you try things like the square_root<> example program (included in the zip file) that the inbuilt range becomes not enough. > I am wondering if the more lazy implementation > possible by moving away from integral constant > expansion might improve matters. OTOH perhaps it > will make matters worse. (I am no expert on 'lazy' > programming...but it must have some benefit?) I'll try to implement some lazy versions of both big_integral<> and the new numeric metafunctions in the next version. > It is merely one among several possible compile time > types that Might be useful as parameters. Other > possibilities are the aforementioned big_int and a > complex, should One not try to make the thing generic > as possible? I dont think anything is lost by it. > Even if the helper functions like gcd and abs are not > useful for this they may come in useful somewhere > else. I've reimplemented rational<> so that it accepts any numeric constants M and N for which modulus<M,N> is a valid expression. That should improve its genericity. Cromwell D. Enage __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

2 3

[serialization] gcc 3.4.3 / ld / serialization issue?
by Christoph Ludwig 10 May '05

10 May '05

Hi, this post belongs to the thread <url:http://lists.boost.org/MailArchives/boost/msg76063.php> but I don't have that thread in my local archive anymore. I face the same problem as Curtis Spencer did. Linking an application built with g++ 3.4.3 against boost_serialization-gcc-mt produces warnings from the linker: g++ -pthread -g -O2 -pthread -o testsuite-LaRed testsuite-LaRed.o ReductionTestdata.o testcase-Testdata.o testcase-Matrix.o testcase-GS.o testcase-LLL.o testcase-BKZ.o testcase-RSR.o -L/home/cludwig/Cxx/gcc3.4/LaRed-0.1-BUILD/src /home/cludwig/Cxx/gcc3.4/LaRed-0.1-BUILD/src/.libs/liblared_ntl.a /home/cludwig/Cxx/gcc3.4/LaRed-0.1-BUILD/src/.libs/liblared.a -lboost_unit_test_framework-gcc-mt -lboost_serialization-gcc-mt -lboost_filesystem-gcc-mt -L/home/cludwig/Cxx/gcc3.4/usr/lib/ -lntl /usr/lib/libgmp.a `.gnu.linkonce.t._ZNK5boost7archive17archive_exception4whatEv' referenced in section `.rodata' of /home/cludwig/Cxx/gcc3.4/usr/lib//libboost_serialization-gcc-mt.a(basic_iarchive.o): defined in discarded section `.gnu.linkonce.t._ZNK5boost7archive17archive_exception4whatEv' of /home/cludwig/Cxx/gcc3.4/usr/lib//libboost_serialization-gcc-mt.a(basic_iarchive.o) (There are similar warnings from basic_text_iprimitive.o and xml_grammar.o. The compiler / Boost configuration are reported at the bottom of this post.) The linker generates an executable anyway and it _seems_ to work. However, I observe infrequent crashes of the application that I don't observe on a machine where I built Boost and the application (without any warnings) with gcc 3.4.2 / ld 2.14.90.0.5. Thus I suspect that the warning is there for a reason and points to the problem causing the crashes. Has anyone an idea what to do about this? I am not sure the problem is caused by the serialization library, but Googling araound I found that it is often exposed by boost_serialization-gcc-mt. There is already a gcc bugreport (PR #16625) w.r.t a similar problem but it seems neither specific to gcc 3.4.3 nor do I see a resolution. Thanks Christoph I built both Boost and my application with gcc 3.4.3: cludwig@cdcNT56:~/Cxx/gcc3.4/LaRed-0.1-BUILD> LC_ALL=C g++ -v Reading specs from /opt/gcc/gcc-3.4.3/lib/gcc/i686-pc-linux-gnu/3.4.3/specs Configured with: ../gcc-3.4.3/configure --prefix=/opt/gcc/gcc-3.4.3 --enable-threads=posix --enable-version-specific-runtime-libs --enable-languages=c,c++ --enable-__cxa_atexit --enable-c-mbchar --enable-libstdcxx-debug --enable-c99 --enable-libstdcxx-pch Thread model: posix gcc version 3.4.3 The linker is: cludwig@cdcNT56:~/Cxx/gcc3.4/LaRed-0.1-BUILD> ld -v GNU ld version 2.15.91.0.2 20040727 (SuSE Linux) Boost was built using the following script: cludwig@cdcNT56:~/Cxx/gcc3.4/LaRed-0.1-BUILD> cat ~/Cxx/boost_1_32_0/build-boost_gcc34.sh #!/bin/bash bjam -d2 --with-pydebug \ --prefix=$HOME/Cxx/gcc3.4/usr \ --builddir=$HOME/Cxx/gcc3.4/boost-1.32.0-build \ -sTOOLS=gcc \ -sBUILD="debug release <threading>multi" \ install bjam -d2 --without-python \ --prefix=$HOME/Cxx/gcc3.4/usr \ --builddir=$HOME/Cxx/gcc3.4/boost-1.32.0-build \ -sTOOLS=gcc \ -sBUILD="debug release <define>BOOST_DISABLE_THREADS <threading>single" \ install -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

2 2

Re: [dynamic_bitset] Stream extraction failures on CodeWarrior 9.4
by Gennaro Prota 10 May '05

10 May '05

--- Doug Gregor <dgregor(a)cs.indiana.edu> wrote: > The stream extraction operators for dynamic_bitset are failing on > CodeWarrior 9.4. See: http://tinyurl.com/addko > Is anyone familiar enough with the quirks of Metrowerks' iostreams to > fix this issue? Hi Doug, Jeremy and Howard unfortunately, due to a series of vicissitudes that would be too long to tell, I have no home connection at the moment (a situation that lasts from several months) and thus I can't work on CVS. Howard Hinnant is probably the person who knows Metrowerks compiler and library best. Howard? -- Genny. Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html

2 2

[1.33.0] We're moving in the right direction...
by Doug Gregor 10 May '05

10 May '05

Since the last time I sent out status information, we've cleared up about 500 failures. Way to go! Let's keep on chipping away at those failures. Doug

1 0

[sandbox cvs][fsm] Rename from fsm -> statechart pending
by Andreas Huber 10 May '05

10 May '05

FYI: A few hours ago I've submitted a request to have the fsm directories in the sandbox renamed to statechart. After that has happened, checkouts of these modules will not compile until I've had the chance to apply the necessary changes. I'll let you know as soon as everything is in order again. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 1

Re: [boost] Re: FOREACH / C++ "for" proposal
by brangdon＠cix.compulink.co.uk 10 May '05

10 May '05

In-Reply-To: <loom.20050509T200130-152(a)post.gmane.org> nesotto(a)cs.aau.dk (Thorsten Ottosen) wrote (abridged): > > Also it requires users to #include <iterator> in order to use the new > > looping construct. There's precedent for that, though, because users > > must #include <typeinfo> to use typeid. I can't decide how I feel > > > about that. Perhaps there's another way. > > I spoke with several implementers and they all said that we need to > include some special header...otherwise it is very problematic to let > the compiler and standard library work together. Could you include a very specific header, eg called <for>, with just whatever it is "for" needs, and require that header to be #included by <iterator> and <vector> and the other containers? Or some similar mechanism... obviously there needs to be a way for end users to get the support for their own containers, and although I suppose just #including <iterator> would do, a smaller header might be better for the same reason that <vector> doesn't #include <iterator>. I appreciate that having standard headers document what other headers they include is a new thing. Would it be a problem in this case? -- Dave Harris, Nottingham, UK.

2 1

Re: [boost] FOREACH / C++ "for" proposal
by brangdon＠cix.compulink.co.uk 10 May '05

10 May '05

In-Reply-To: <427FB7C9.9030708(a)systemhaus-gruppe.de> sstrasser(a)systemhaus-gruppe.de (Stefan Strasser) wrote (abridged): > > Although it doesn't seem to say whether "vec" is hoisted, and the > > given translation suggests that it isn't. > > maybe "hoisting" was not the right word, I only know it from a post by > eric. "Hoisting" is fine for the purposes of this thread. > what I meant was copy-the-value-of-end()-at-the-start-of-the-loop. > and the proposal does that, see 3. It says end(vec) is hoisted, but doesn't say whether vec itself is hoisted. In "for (int i: vec )" is vec evaluated once or twice? I believe BOOST_FOR evaluates it exactly once. The translation given in the proposal is: using std::begin; // enable ADL using std::end; // ditto for( auto __begin = begin(vec), __end = end(vec); __begin != __end; ++__begin ) { int i = *__begin; std::cout << i; } which apparently evaluates vec twice. A variable __end is introduced explicitly for end(vec), but there is no analogous variable __vec. I guess we ought to find out for sure which it will be, and then make BOOST_FOR do the same. -- Dave Harris, Nottingham, UK.

2 1