- Boost - lists.boost.org

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

Why protect()?
by alex 18 May '05

18 May '05

I test the sample in the section "Nesting STL algorithm invocations": -------------------------------------- int a[100][200]; int sum = 0; std::for_each(a, a + 100, bind(ll::for_each(), _1, _1 + 200, protect(sum += _1))); ------------------------------------------------If I remove the protect function, and I will get a complie error.Thx!

2 1

program_options version
by Janusz Piwowarski 18 May '05

18 May '05

Hi, I think that BOOST_PROGRAM_OPTIONS_VERSION should be incremented in 1.33 release. Regards, Janusz

1 0

[serialization] problems in Comeau
by Joaquín Mª López Muñoz 18 May '05

18 May '05

Boost.Serialization is currently failing to build in Comeau 4.3.3, apparently for legitimate reasons: http://tinyurl.com/adv2g The detail type helper_type in libs/serialization/src/basic_oarchive.cpp contains the following member: const boost::serialization::extended_type_info * const m_eti; whose constness prevents the compiler from generating a default assignment operator for helper_type. Hence helper_type is not Assignable and thus cannot be used in a STL container like attempted at line 164 in the same archive: std::set<helper_type, helper_compare> m_helpers; I guess removing the const qualifier of m_eti would suffice to make this error go away. Any objection to me applying the attached patch (confirmed to work on MSVC, yet untested in Comeau)? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 143c143 < const boost::serialization::extended_type_info * const m_eti; --- > const boost::serialization::extended_type_info * m_eti; 146c146 < const boost::serialization::extended_type_info * const eti --- > const boost::serialization::extended_type_info * eti

2 1