- Boost - lists.boost.org

patch to kill warnings on boost-cvs
by Rodolfo Schulz de Lima 27 Aug '04

27 Aug '04

Hi, here's a patch to shut up the gcc-3.4.1 compiler with all warnings enable (-Wextra -Wall). That'll be nice if this was put in the main package. My projects usually have -Werror and those ones below doesn't help. It's all about harmless unused function parameters. I must point that I didn't check other libraries, just the ones I usually use. Thanks, rod diff -ur boost/date_time/date_names_put.hpp /usr/include/boost-1_32/boost/date_time/date_names_put.hpp --- boost/date_time/date_names_put.hpp 2004-07-17 19:20:18.000000000 -0300 +++ /usr/include/boost-1_32/boost/date_time/date_names_put.hpp 2004-08-23 17:35:05.000000000 -0300 @@ -142,10 +142,10 @@ default: {} //quiet compilers that want all cases covered here (eg: gcc 3.1) } } - virtual void do_put_weekday_short(iter_type& oitr, weekday_enum wd) const + virtual void do_put_weekday_short(iter_type&, weekday_enum) const { } - virtual void do_put_weekday_long(iter_type& oitr, weekday_enum wd) const + virtual void do_put_weekday_long(iter_type&, weekday_enum) const { } virtual bool do_has_date_sep_chars() const diff -ur boost/date_time/gregorian/greg_month.hpp /usr/include/boost-1_32/boost/date_time/gregorian/greg_month.hpp --- boost/date_time/gregorian/greg_month.hpp 2004-07-18 15:36:16.000000000 -0300 +++ /usr/include/boost-1_32/boost/date_time/gregorian/greg_month.hpp 2004-08-23 16:29:25.000000000 -0300 @@ -78,20 +78,20 @@ /* parameterized as_*_string functions are intended to be called * from a template function: "... as_short_string(charT c='\0');" */ - const char* as_short_string(char c) const + const char* as_short_string(char) const { return as_short_string(); } - const char* as_long_string(char c) const + const char* as_long_string(char) const { return as_long_string(); } #ifndef BOOST_NO_STD_WSTRING - const wchar_t* as_short_string(wchar_t c) const + const wchar_t* as_short_string(wchar_t) const { return as_short_wstring(); } - const wchar_t* as_long_string(wchar_t c) const + const wchar_t* as_long_string(wchar_t) const { return as_long_wstring(); } diff -ur boost/token_functions.hpp /usr/include/boost-1_32/boost/token_functions.hpp --- boost/token_functions.hpp 2004-08-19 12:23:46.000000000 -0300 +++ /usr/include/boost-1_32/boost/token_functions.hpp 2004-08-23 16:34:48.000000000 -0300 @@ -212,7 +212,7 @@ } template<class Token, class Value> - static void plus_equal(Token &t, const Value &v) { + static void plus_equal(Token &, const Value &) { } @@ -220,7 +220,7 @@ // the clear. // template<class Token> - static void clear(Token &t) { + static void clear(Token &) { } };

5 5

zip iterator misbehaving
by Antonio Piccolboni 27 Aug '04

27 Aug '04

Hi everyone, I have the following problem. I need to apply the same permutation to two sequence collections. The following code for the single permutation works like a charm: random_shuffle(TGraphRowVectorIterator<Identifier>(theGraph.begin()), TGraphRowVectorIterator<Identifier>(theGraph.end())); (only, I haven't figured out how to random seed random_shuffle, but I guess this is a question for another forum) TGraphRowVectorIterator<Identifier> is a projection iterator. Unfortunately when I wrote it I didn't know about boost so I wrote it by hand and I hate that code now (attached at the end) but it seems to work ok in many contexts. Now to the simultaneous permutation of two: random_shuffle (boost::make_zip_iterator (boost::make_tuple (TGraphRowVectorIterator<long>(firstGraph.begin()), TGraphRowVectorIterator<long>(secondGraph.begin()) ) ), boost::make_zip_iterator (boost::make_tuple (TGraphRowVectorIterator<long>(firstGraph.end()), TGraphRowVectorIterator<long>(secondGraph.end()) ) ) ); (I think if this is going to work I will make it my favorite example of generic programming. Isn't it a thing of beauty? Can this be solved in C without duplicating and uglyfying the shuffle code?). This unfortunately doesn't return a permutation. The resulting vector has repetitions in it. I debugged the code all the way inside iter_swap and it looks like the side effects of the swap are propagated only to one of the arguments, to my astonishment because they have THE SAME TYPE. So if I screwed with the iterator definition, which is totally a possibility, it should simply not permute anything. I am not yet ready to claim there is a bug in zip_iterator, but this is very suspicios. Thanks for anyone's help Antonio ----Ugly iterator code, is there anythng wrong with the signatures? Thank God for the <iterator>!------- template<class Identifier> class TGraphRowVectorIterator : public iterator<random_access_iterator_tag, vector<double>, long> { typename TGraph<Identifier>::iterator rowIterator; public: TGraphRowVectorIterator<Identifier> (typename TGraph<Identifier>::iterator rowI) { rowIterator = rowI; } TGraphRowVectorIterator<Identifier> () { } vector <double> & operator *() const { return rowIterator->values; } vector <double> * operator ->() { return &(operator*()); } bool operator == (const TGraphRowVectorIterator<Identifier> & that) const { return rowIterator == that.rowIterator; } bool operator != (const TGraphRowVectorIterator<Identifier> & that) const { return !(*this == that); } bool operator < (const TGraphRowVectorIterator<Identifier> & that) const { return rowIterator < that.rowIterator; } bool operator >= (const TGraphRowVectorIterator<Identifier> & that) const { return !(*this < that); } bool operator >(const TGraphRowVectorIterator<Identifier> & that) const { return (*this >= that) && (*this != that); } bool operator <= (const TGraphRowVectorIterator<Identifier> & that) const { return !(*this > that); } TGraphRowVectorIterator<Identifier> operator ++ (){ rowIterator ++; return *this; } TGraphRowVectorIterator<Identifier> operator -- (){ rowIterator --; return *this; } TGraphRowVectorIterator<Identifier> operator ++ (int){ TGraphRowVectorIterator<Identifier> tmp(*this); rowIterator ++; return tmp; } TGraphRowVectorIterator<Identifier> operator -- (int){ TGraphRowVectorIterator<Identifier> tmp(*this); rowIterator --; return tmp; } TGraphRowVectorIterator<Identifier> operator + (long drow) { return TGraphRowVectorIterator<Identifier> (rowIterator + drow); } TGraphRowVectorIterator<Identifier> operator += (long drow) { rowIterator += drow; return *this; } TGraphRowVectorIterator<Identifier> operator - (long drow) const{ return (*this + (-drow)); } long operator - (TGraphRowVectorIterator<Identifier> that) const { return rowIterator - that.rowIterator; } Identifier position() { return rowIterator->position(); } }; -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

1 0

typeof for vintage compilers
by Peder Holt 27 Aug '04

27 Aug '04

Hi. I started working on implementing remove_bounds for the VC 6.5 compiler, and found that the source had all the similarities of Arkadiys typeof implementation, so I have implemented typeof for compilers not supporting partial specialization. I took many ideas from Arkadiys implementation, but I had to rewrite the encoding part from scratch. The library (apart from being incomplete with respect to function types etc) has the following key elements in place: encoding/decoding of: -fundamental types -template types -modifiers (*&const volatile []) The library has a few improvements that could perhaps be implemented in Arkadiys typeof implementation as well: The max depth of an expression increased from the mpl limit of 60 to the preprocessor limit of 256 template expressions containing integral values are allowed The template: template<typename T,unsigned long V> struct X {}; can be exposed to typeof in the following way: BOOST_TYPEOF_DEFINE_TEMPLATE(X,2,(typename,unsigned long)) (VC 7.1 had some problems preprocessing the code needed to make this work.) The source is available at: http://groups.yahoo.com/group/boost/files/typeof_vintage.zip I have compiled the library for VC 6.5 and 7.0. They both fail when the depth of an expression gets too large, with the error message: fatal error C1045: compiler limit : linkage specifications nested too deeply. -- Peder Holt

2 3

Re: RE: [boost] [minmax] patch to solve issue in GCC 2.95
by JOAQUIN LOPEZ MU?Z 27 Aug '04

27 Aug '04

----- Mensaje original ----- De: "Rozental, Gennadiy" <gennadiy.rozental(a)thomson.com> Fecha: Viernes, Agosto 27, 2004 6:47 pm Asunto: RE: [boost] [minmax] patch to solve issue in GCC 2.95 > Which file? My bad :) The file is libs/algorithm/minmax/test/minmax_test.cpp > > > -----Original Message----- > > From: boost-bounces(a)lists.boost.org > > [boost-bounces(a)lists.boost.org] On Behalf Of joaquin(a)tid.es > > Sent: Friday, August 27, 2004 4:14 AM > > To: boost(a)lists.boost.org > > Subject: [boost] [minmax] patch to solve issue in GCC 2.95 > > > > > > GCC 2.95 has problems supporting using declarations inside > > functions, as > > > > indicated by BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL. > > > > This affects a minmax test in this compiler. The following > > trivial patch moves a using directive to global scope and > > solves the issue. This would make it all green for minmax > > regression tests under every platform considered. > > > > OK to commit? > > > > Joaquín M López Muñoz > > Telefónica, Investigación y Desarrollo > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

RE: [boost] [minmax] patch to solve issue in GCC 2.95
by Rozental, Gennadiy 27 Aug '04

27 Aug '04

Which file? > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of joaquin(a)tid.es > Sent: Friday, August 27, 2004 4:14 AM > To: boost(a)lists.boost.org > Subject: [boost] [minmax] patch to solve issue in GCC 2.95 > > > GCC 2.95 has problems supporting using declarations inside > functions, as > > indicated by BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL. > > This affects a minmax test in this compiler. The following > trivial patch moves a using directive to global scope and > solves the issue. This would make it all green for minmax > regression tests under every platform considered. > > OK to commit? > > Joaquín M López Muñoz > Telefónica, Investigación y Desarrollo >

1 0

Re: Copyright
by Vladimir Prus 27 Aug '04

27 Aug '04

David Abrahams wrote: > Vladimir Prus <ghost(a)cs.msu.su> writes: > > Could you clarify? To be exactly specific, if I have a file with the > > following content, as a part of Boost.Build test: > > > > int main() { return 0; } > > > > why does it need copyright? > > Files without copyrights make corporate lawyers nervous, and that's a > barrier to adoption. If everything in Boost is copyrighted, there > won't be any problem with dropping a Boost release on a corporate > server. *Any* file without copyright? What about 'boost.css' or 'c++boost.gif' for example? What about BoostBook DTD, which has the following: Copyright (c) 2002 by Peter Simons <simons(a)computer.org>. All Rights Reserved. What about tools/regression/xsl_reports/merger/__init__.py And, for a completely interesting question, whose copyright should be on 'status/explicit-failures-markup.xml'? Of all the authors? The reason I'm asking all this is that it seems that a lot effort was already spend to add copyrights, and more is likely to be spend and I find it hard to believe that lawyers will examine every single file of Boost. Maybe, just headers and the code which goes into compiled libraries really need to be license-clean. - Volodya

2 1

[program_options + test] Intel problem
by Vladimir Prus 27 Aug '04

27 Aug '04

The error message in http://tinyurl.com/6ynh9 says that some symbols are multiply declared. The error messages refer to Boost.Test, and also some compiler library, and is hard to understand. Could any expert take a look? - Volodya

7 11

a problem with lambda expressions
by zaufi 27 Aug '04

27 Aug '04

Hi, everybody! We've got a problem with a following code that does not compile: -------------------------------------------------------------------------------------- #include <list> #include <algorithm> #include <boost/lambda/bind.hpp> int main() { using namespace boost::lambda; std::list<std::list<int> > l; bool some_are_empty = false; std::for_each(l.begin(), l.end(), var(some_are_empty) = bind(&std::list<int>::empty, _1) || some_are_empty); return 0; } ---------------------------------------------------------------------------------------- Compiler (gcc 3.4.1) gives the following errors: ---------------------------------------------------------------------------------------- lambda-problem.cc: In function `int main()': lambda-problem.cc:13: error: no match for 'operator||' in 'boost::lambda::bind(const Arg1&, const Arg2&) [with Arg1 = bool (std::list<int, std::allocator<int> >::*)() const, Arg2 = boost::lambda::lambda_functor<boost::lambda::placeholder<1> >](((const boost::lambda::lambda_functor<boost::lambda::placeholder<1> >&) (+boost::lambda::<unnamed>::_1))) || some_are_empty' lambda-problem.cc:13: note: candidates are: operator||(bool, bool) <built-in> -------------------------------------------------------------------------------------- Can anybody shed a light on what are we doing wrong in this example?

3 2

discrepancy between regression tests and manual testing
by Bronek Kozicki 27 Aug '04

27 Aug '04

While examining some error in regression tests I have noticeed that this error does not appear when I'm starting bjam in "test" directory of library. It does however appear in regression test. Reason for this discrepancy is that regression tests are always started from boost/status/Jamfile , and this Jamfile contains number of settings for specific tests ; thus when test started from different Jamfile (like the one in test directory) these settings are not applied, effectively both Jamfiles produce different results. I hope it's possible to move all these library-specific settings into specific Jamfiles in test directories? Right now it might be quite difficult to fix regression errors for someone not willing to run full regression tests. B.

1 0

Re: mingw test results
by John Maddock 27 Aug '04

27 Aug '04

> >I've been looking at your regression test results for mingw: > > > >config_test and all the regex tests are failing with a runtime exit code of > >128, however they pass for me here, and for some of the other testers as > >well (see the Bronek Kozicki results). Do you have any idea what's > >happening here? If you can get a stack backtrace for the problem that's > >happening in config_test that would be a big help. > > I re-compiled the test (config) using dev-cpp (which is the mingw I'm > using) and ran the test manually AND with the debugger > error_count (and what gets returned) is clearly 0 in both runs. > > apparently there is some hiccup w/ the interface to the boost test fixture. > I'll be happy to debug there if someone can give me a hint where to start. Not sure, but you could try: bjam -a -d2 config_test which may indicate some kind of difference between what bjam is doing, and what your manual builds are doing; then again it may not :-( Thanks! John.

1 0