April 2005 - Boost - lists.preview.boost.org

range\config.hpp and regression tests broken
by Victor A. Wagner Jr. 09 Apr '05

09 Apr '05

I arbitrarily rolled back (effectively) the 1.6 version of boost\range\config.hpp (see attached) C:\Projects\boost\boost\range>cvs diff config.hpp Index: config.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/range/config.hpp,v retrieving revision 1.6 diff -r1.6 config.hpp 36c36,37 < #if BOOST_WORKAROUND( BOOST_MSVC, <= 1200 ) || __MWERKS__ <= 0x3003 --- > //#if BOOST_WORKAROUND( BOOST_MSVC, <= 1200 ) || __MWERKS__ <= 0x3003 > #if _MSC_VER <= 1200 && !defined( __COMO__ ) && !defined( __GNUC__ ) && __MWERKS__ <= 0x3003 Note that I commented out the "new" line and added the old. I hope someone can tell me how these two lines are supposed to be equivalent, or if there was a bug in the original (current) then how the "new" line was supposed to fix it. Perhaps a much larger problem is that after this change, there was NO change in the regression I was reporting, even thought the logs clearly showed compile errors (the old log should still be ftp://rudbek.com/pub/boost ) My normal testing automatically kicked off 25 minutes ago, so it won't be there forever (the last run took FIVE(5) hours (the tests _had_ been running in about 2)). I also changed two other files in iostream which suddenly got \r\r\n line endings (vc8.0 doesn't like those for some reason) The fact that the change would likely have gone unnoticed if I hadn't been working on some updates for a client and _known_ that the program had compiled 26.5 hours ago, and failed 16 hours ago and could chase down who'd changed what is rather disturbing. We _must_ make some changes in how the regression tests are run (or perhaps how the results are analyzed) if we ever hope to have reliable stuff going out the door. I believe this throws into serious question whether it is reasonable to expect to do a release of a new version of boost in the immediate future (starting a freeze in 7 days). Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

3 3

[shared_ptr] PPC implementations updated
by Peter Dimov 09 Apr '05

09 Apr '05

I have fixed a 970-specific problem with the PPC implementations that was pointed to us by Philip Koch. Thanks to Miro Jurisic for getting his attention. So the tests will need to be re-run. I hope I didn't make any stupid mistakes. -- Peter Dimov http://www.pdimov.com

4 21

[timer] progress_timer's dtor - strange behavior
by Pavel Chikulaev 09 Apr '05

09 Apr '05

Hi all, I'm just happened to use boost::progress_timer for the first time, and was shocked by strange behavior of the progress_timer dtor: Surprisingly, it puts two newlines in the stream ('\n', then endl). So, I've got question - it is a bug or it is a feature? Using current implementation I just can't get the output look like: the first block took 2.34 s the second block took 5.67 s IMO this's a bug, and it should be fixed. Also I would like to be able to specify that no newlines in dtor are needed at all. This is very useful for stringstreams for example. Here's the fixed progress_timer: class progress_timer : public timer, private noncopyable { public: explicit progress_timer(std::ostream & os = std::cout, bool putnewline = true) : m_os(os), m_putnewline(putnewline) {} ~progress_timer() { try { std::istream::fmtflags old_flags = m_os.setf( std::istream::fixed, std::istream::floatfield ); std::streamsize old_prec = m_os.precision( 2 ); m_os << elapsed() << " s"; if (m_putnewline) m_os << std::endl; m_os.flags( old_flags ); m_os.precision( old_prec ); } catch (...) {} } private: std::ostream & m_os; bool m_putnewline; }; -- Pavel Chikulaev

1 0

[boost::serialization] - serialization + shared_ptrs
by Martin Slater 09 Apr '05

09 Apr '05

Hi there, After fixing header include orders for the umpteenth time to ensure boost/serialization/shared_ptr.hpp is included before shared_ptr.hpp so it can do it's #define private public hack I wondered if this was any closer to an acceptable resolution? I know this is brought up periodcally but it really needs to be sorted out in someway, currently I have just hacked my local boost source to make shared_ptr's private declarations public to avoid the issue but obviously this is far from ideal. Thanks Martin

7 23

[Boost-bugs] [ boost-Bugs-1179641 ] boost::pool_allocator breaks with vector of vectors
by SourceForge.net 09 Apr '05

09 Apr '05

Bugs item #1179641, was opened at 2005-04-09 00:46 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=1179641&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Rosenblatt (glr9940) Assigned to: Nobody/Anonymous (nobody) Summary: boost::pool_allocator breaks with vector of vectors Initial Comment: The resulting executable built with the following code under GCC 3.3.5 produces a segmentation fault when run: Note that switching the definition of EventVector to use a vector with a standard allocator will fix the problem. Also note that the definition of IndexVector doesn't seem to matter. #include <boost/pool/pool_alloc.hpp> #include <vector> #include <iostream> template <typename DataType> struct PooledVector { typedef std::vector<DataType, boost::pool_allocator<DataType> > Type; }; typedef PooledVector<int>::Type EventVector; //typedef std::vector<int> EventVector; //typedef PooledVector<EventVector>::Type IndexVector; typedef std::vector<EventVector> IndexVector; int main() { IndexVector iv; iv.push_back(EventVector()); iv.back().push_back(3); std::cout << "it works\n"; return 0; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1179641&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

resolving a string to a type
by George M. Garner Jr. 09 Apr '05

09 Apr '05

Does boost provide a standard way to resolve a string to a type within a typelist? Regards, George.

1 0

[Boost-bugs] [ boost-Bugs-1179501 ] tools/bcp/bcp_imp.cpp (unknown identifier getline)
by SourceForge.net 08 Apr '05

08 Apr '05

Bugs item #1179501, was opened at 2005-04-08 22:13 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=1179501&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: squeeze (sqzme) Assigned to: Nobody/Anonymous (nobody) Summary: tools/bcp/bcp_imp.cpp (unknown identifier getline) Initial Comment: 108: while (getline(in, line)) { produces a linker error. Should be: 108: while (std::getline(in, line)) { ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1179501&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[serialization1.32]:VC7.1 error C2039: 'integral_c_tag' : n'est pas membre de 'boost::mpl'
by Francis ANDRE 08 Apr '05

08 Apr '05

Hi Robert I got this error from error C2039: 'integral_c_tag' : n'est pas membre de 'boost::mpl' Here the beginning of level.hpp I got: ---------------------------------------------------------------------------- ------ #include <boost/mpl/int.hpp> #include <boost/mpl/integral_c.hpp> #include <boost/serialization/level_enum.hpp> #include <boost/serialization/traits.hpp> namespace boost { namespace serialization { // default serialization implementation level template<class T> struct implementation_level { template<class U> struct traits_class_level { typedef BOOST_DEDUCED_TYPENAME U::level type; }; typedef mpl::integral_c_tag tag; // <== problem here // #if BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(600)) // typedef ---------------------------------------------------------------------------- -------- >From what I check of the latest HEAD release from CVS, it should be integral_c instead of integral_c_tag?? Regards FA

2 1

[serialization] exception in destructor
by Vyacheslav E. Andrejev 08 Apr '05

08 Apr '05

Hello Robert, I spent a lot of time trying to understand where my program failed. Finally, I found that the cause was in destructor of basic_xml_oarchive class: template<class Archive> #if !defined(__BORLANDC__) BOOST_DECL_ARCHIVE_OR_WARCHIVE #endif basic_xml_oarchive<Archive>::~basic_xml_oarchive(){ if(!header) return; this->This()->put("</boost_serialization>\n"); } basic_text_oprimitive::put(const char * s) can throw an exception, causing unexpected termination of program when stack unwind. I heard many times that uncaught exception in destructor is not very good thing. Should we consider refactoring of this point in basic_xml_oarchive? Regards. Slava. -- Vyacheslav E. Andrejev System Architect, Excelsior, LLC

2 1

Bug in posix_time::ptime documentation?
by Wolfgang Fertsak 08 Apr '05

08 Apr '05

I don't know if this has been reported already, but in the ptime-class documentation (boost_1_32_0/doc/html/date_time/posix_time.html) in the section "Construct from Clock" is a list of the three construction functions second_clock::local_time() second_clock::universal_time() microsec_clock::local_time() The example for second_clock::universal_time() shows a call of second_clock::universal_day() - which will not compile. Kind regards, Wolfgang

2 1