May 2005 - Boost - lists.boost.org

Big integer library
by Marcin Kalici�ski 19 May '05

19 May '05

Tracking the disussion on n1774 'Big integer library proposal for C++0x' I see there is a lot of controversy about it, and it will probably need much tweaking before (if ever) it is accepted. Wouldn't that be a good idea to have a big integer added to boost so that we can create a 'working practice' before anything gets standarised? I have some preliminary source code, some spare time, and would volunteer to work on it if there's enough interest. cheers, M.

11 10

[Iterator] advance and distance that understand new iterator concepts?
by Douglas Gregor 19 May '05

19 May '05

Do we have counterparts to std::advance and std::distance that are optimized for random_access_traversal_tag instead of std::random_access_iterator_tag? Doug

2 1

[Wave] Boost Inspection Report
by Hartmut Kaiser 19 May '05

19 May '05

Hi all, the boost inspection report claims that one of the Wave test files contains tabs. And this is correct! But: it needs to contain tabs because it's a testcase... Should I ignore this warning? Or is there a way to tell the inspect program to ignore tabs in this particular file? Regards Hartmut

4 10

xpressive not in boost.1.33, but what about 1.34?
by Bronek Kozicki 19 May '05

19 May '05

I suppose xpressive has not been accepted into boost yet (or I missed library review). This would mean that we will not see it in boost 1.33. Is there any chance we would see it in boost 1.34? B. -- Bronek Kozicki brok(a)rubikon.pl http://b.kozicki.pl/

8 13

RE: [boost] Re: Non-intrusive serialization with VC2003 (7.1)
by Marcin Tustin 19 May '05

19 May '05

> -----Original Message----- > From: Robert Ramey [mailto:ramey@rrsd.com] > Sent: 18 May 2005 16:54 > To: boost(a)lists.boost.org > Subject: [boost] Re: Non-intrusive serialization with VC2003 (7.1) > > By extensive error trace I mean the whole chain of > instantiations with lines like "instanciated from" ... > Sometimes this chain is dozens of lines long. Its the > compile-time version of a call stack. This can be used to > trace back through the chain of calls to determine which one > didn't work as expected. How do I access this trace? I've never seen such a thing. > Robert Ramey > > > Perhaps I don't know enough about VC 7.1, but what > extensive error > > trace? > > > > c:\new_boost\boost\boost\serialization\access.hpp(107): error C2039: > > 'serialize' > >> is not a member of 'Jrs::SmartPtr<T>' > > with > > [ > > T=D2::Message > > ] > > > > is all that I get. I can't begin to imagine how I would go about > > diagnosing the cause of the error. > > > > > > >

2 1

[Boost-bugs] [ boost-Bugs-1204688 ] Document copy_component
by SourceForge.net 19 May '05

19 May '05

Bugs item #1204688, was opened at 2005-05-18 21:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1204688&group_… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: Document copy_component Initial Comment: It's in boost/graph/copy.hpp, and useful, so we should document it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1204688&group_… ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1204684 ] random_vertex/random_edge are unnecessarily inefficient
by SourceForge.net 19 May '05

19 May '05

Bugs item #1204684, was opened at 2005-05-18 21:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1204684&group_… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: random_vertex/random_edge are unnecessarily inefficient Initial Comment: random_vertex and random_edge should require constant time for RandomAccessTraversal iterator, but they are still linear time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1204684&group_… ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[operators] Improved workaround for BOOST_NO_OPERATORS_IN_NAMESPACE
by Daniel Frey 18 May '05

18 May '05

A new version of operators.hpp is available in the sandbox at <http://boost-sandbox.sourceforge.net/vault/index.php?&directory=daniel_frey>, it contains an improved workaround for compilers that need BOOST_NO_OPERATORS_IN_NAMESPACE. Other compilers should not be affected, but hey, you never know :) I'd like to ask for people to test the new version. In particular, the following compilers set BOOST_NO_OPERATORS_IN_NAMESPACE in their config-files (see boost/config/compiler/...) for some versions: - GCC < v3 - Borland - Digital Mars - ACC (hp_acc) If you (still) have one of these compiler with the affected versions, please test the new operators.hpp. Besides running the regression tests, which obviously must work, you can try to compile the following examples with the old and the new version: Example1.cpp: #include <boost/operators.hpp> using namespace boost; class a:addable1<a>{ public: a& operator+=(const a&){return *this;}; }; int main(){ } Example2.cpp: #include <boost/operators.hpp> bool addable1; int main(){ } Both examples previously failed to compile on (some of?) the compilers that had BOOST_NO_OPERATORS_IN_NAMESPACE defined, the new version should fix that. Also, reviews of the patch are also welcome. One final note: The new version will not go into 1.33.0, which is why I choose to put the new version in the sandbox first. Once 1.33.0 is out and given that the initial tests look positive, it will go into CVS to make sure the full regression testing is applied and the regression test will be improved to check for the above examples. Out of curiousity: Will the new version (with the appropriate define set) improve the situation for the VC7? Anyone care to check that, too? (If it shows an improvement, I honestly have no clue why ;) Thanks for you time. Regards, Daniel

1 0

RE: [boost] Re: Re: Non-intrusive serialization with VC2003 (7.1)
by Marcin Tustin 18 May '05

18 May '05

> -----Original Message----- > From: Robert Ramey [mailto:ramey@rrsd.com] > Sent: 16 May 2005 16:30 > To: boost(a)lists.boost.org > Subject: [boost] Re: Re: Non-intrusive serialization with VC2003 (7.1) > > Note the "long int hack" isn't used with vc 7.1 as it support > correct partial template ordering. Interesting. Still doesn't explain why the compiler is trying to use the intrusive stuff, rather than the non-intrusive layer, at least to my relatively unschooled C++ mind. Is there anything I should do, or should I try something like writing wrapper classes for everything? > Marcin Tustin wrote: > >> -----Original Message----- > >> From: Robert Ramey [mailto:ramey@rrsd.com] > >> Sent: 13 May 2005 15:51 > >> To: boost(a)lists.boost.org > >> Subject: [boost] Re: Non-intrusive serialization with VC2003 (7.1) > >> > >> Try putting your function inside the namespace D2 > > > > I did. I also tried putting it in the global namespace. Same error. > > > >> Robert Ramey > >> > >> Marcin Tustin wrote: > >>> I'm trying to use the serialization and archive > libraries, and I'm > >>> having a bit of trouble getting non-intrusive serializaton > >> to work; I > >>> keep getting the error > >>> "c:\boost_1_32_0\boost\serialization\access.hpp(106): error C2039: > >>> 'serialize' : is not a member of 'D2::Message'". My guess > >> is that for > >>> some reason the "long int" hack isn't working properly. I have > >>> serialize methods in the boost::seralization namespace like this: > >>> > >>> namespace boost { > >>> namespace serialization { > >>> template<class Archive > > >>> static void serialize(Archive & ar, const > >> D2::Message& g, const > >>> unsigned int version) > >>> { > >>> //... > >>> } > >>> > >>> } }; > >>> > >>> Which are textually before any use of the library, as far > as I can > >>> tell. > >>> > >>> Any help would be much appreciated. > >>> > >>> Marcin Tustin > >>> IT Innovation Centre > >>> 2 Venture Road > >>> Chilworth Science Park > >>> Southampton, SO16 7NP, UK > >>> > >>> tel: +44 23 8076 0834 > >>> fax: +44 23 8076 0833 > >>> > >>> mailto:mt@it-innovation.soton.ac.uk > >>> http://www.it-innovation.soton.ac.uk > >>> > >>> _______________________________________________ > >>> Unsubscribe & other changes: > >>> http://lists.boost.org/mailman/listinfo.cgi/boost > >> > >> > >> > >> > >> > > > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > > > >

2 4

[python] Patch for Tru64/cxx
by Markus Schöpflin 18 May '05

18 May '05

Attached patch allows the python library to successfully build on Tru64/cxx65. Ok to commit? Markus Index: registry.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/python/src/converter/registry.cpp,v retrieving revision 1.28 diff -u -w -r1.28 registry.cpp --- registry.cpp 16 May 2005 03:31:12 -0000 1.28 +++ registry.cpp 18 May 2005 09:41:25 -0000 @@ -161,11 +161,13 @@ assert(slot == 0); // we have a problem otherwise if (slot != 0) { - std::string msg( - "to-Python converter for " - + lexical_cast<std::string>(source_t) - + " already registered; second conversion method ignored." - ); + std::string msg("to-Python converter for "); +#if BOOST_WORKAROUND(__DECCXX_VER, BOOST_TESTED_AT(60590042)) + msg += source_t.name(); +#else + msg += lexical_cast<std::string>(source_t); +#endif + msg += " already registered; second conversion method ignored."; if ( ::PyErr_Warn( NULL, const_cast<char*>(msg.c_str()) ) ) {

2 2