- Boost - lists.boost.org

Re:[boost] [serialization] use of iterator_facade, CW8 build
by Robert Ramey 01 Aug '04

01 Aug '04

Rene Rivera wrote: >In another painfully hunt to fix the problems with the seriazation lib >issues in CW8... I tracked the problem down to another instance of: >static_cast<const&>(x) where x is a template with template ctors. The >problem was in iterator_facade, and not directly in the serialization >lib which made it even harder to find :-( >Anyway, I applied this change (figured since this is a known problem by >now with an easy portable solution it would not be a problem)... Hats off - I know this was hard to find. BTW it didn't show up on my test machine which was running CW Pro 9 . Also it looks like someone (B. Dawes? Or perhaps the tester) modified the build so that we don't get a lot of link errors. I believe I'm making progress in understanding an issue with broken function template overloads which breaks non-intrusive serialization. We'll see. Robert Ramey

1 0

[build] bjam crash
by Bertolt Mildner 01 Aug '04

01 Aug '04

I just had a bjam crash: "... instruction at 0x0040d4bd tried to access memory at 0x00000040 ..." current public CVS snapshot bjam built with MSVC 6.5 (build.bat msvc) Win2k SP4 (german) gcc 3.3.1 (cygming special) TOOLS = gcc BUILD=debug release commandline: bjam clean (in \libs\thread\build) Tried to run bjam several times, but always got the same crash. Deleting .jamdeps in \bin solved the problem. After the secessful clean i restored .jamdeps and ran "bjam clean" again, but it did not crash again. I have attached the (winzipped) .jamdeps Bertolt -- Free Crypto Token - FCT www.FreeCryptoToken.org ***************************************************************************** ** ** ** WARNING: This email contains an attachment of a very suspicious type. ** ** You are urged NOT to open this attachment unless you are absolutely ** ** sure it is legitmate. Opening this attachment may cause irreparable ** ** damage to your computer and your files. If you have any questions ** ** about the validity of this message, PLEASE SEEK HELP BEFORE OPENING IT. ** ** ** ** This warning was added by the IU Computer Science Dept. mail scanner. ** *****************************************************************************

1 0

VC 7.1 level 4 warnings (thread, lexical_cast)
by Johan Nilsson 01 Aug '04

01 Aug '04

[Should this really go to boost.users instead?] Hi, loads of warnings are generated when compiling code with VC 7.1 using Boost.Thread and lexical_cast with the warning level set to 4. I use Boost 1.31.0, but at a quick look at the latest versions they seem to have the same problem * Boost.Thread generates numerous C4275 and C4251 (both related to dll-interface), examples: --- ../../../deps\boost\boost\thread\exceptions.hpp(29) : warning C4275: non dll-interface class 'std::logic_error' used as base for dll-interface class 'boost::lock_error' d:\VS.NET_2003\Vc7\include\stdexcept(14) : see declaration of 'std::logic_error' ../../../deps\boost\boost\thread\thread.hpp(78) : warning C4251: 'boost::thread_group::m_threads' : class 'std::list<_Ty>' needs to have dll-interface to be used by clients of class 'boost::thread_group' --- * lexical_cast generates C4511, C4512 + C4127, examples: -- ../../../deps\boost\boost\lexical_cast.hpp(180) : warning C4512: 'boost::detail::lexical_stream<Target,Source>' : assignment operator could not be generated ... ../../../deps\boost\boost\lexical_cast.hpp(180) : warning C4511: 'boost::detail::lexical_stream<Target,Source>' : copy constructor could not be generated ... ../../../deps\boost\boost\lexical_cast.hpp(133) : warning C4127: conditional expression is constant --- Would it be possible to get rid of those using pragmas in the header files? I wouldn't mind disabling C4511/4512 globally but the other ones I'd prefer not to. Selectively disabling the other warnings when including the files is practically impossible. I guess this has been discussed before, but why not compile with warning level 4 + warnings as errors by default? // Johan

3 3

lexical cast and locale
by Martin 01 Aug '04

01 Aug '04

This might be a stupid question but I couldn't find anything in the documentation about it. How do I control the locale used in lexical cast? More specificly I want to control the decimal separator.

2 2

Review Wizard - Status Report
by Tom Brinkman 01 Aug '04

01 Aug '04

I'm currently attempting to contact the authors of the eight remaining libraries to be reviewed. I will start the reviews immediately after the next release of boost is completed. If you are one of the eight authors, and I have not contacted you yet, please contact me directly, and tell me what your availability is. I will schedule the reviews in the months of August, September and October. Please tell me if you have a suggestion for a review manager for your library or if you have any questions about the review process. I will research them for you. Tom Brinkman Review Wizard reportbase(a)yahoo.com __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo

3 2

[algorithm/string] predicate failure for CW8
by Rene Rivera 31 Jul '04

31 Jul '04

It took some digging but I figured out what the problem with the failure on this test is for CW8. Basically CW8 is doing a copy construction on the use of static_cast for a reference when the type of the reference is itself a template typename. In all other cases it does the cast correctly. The work-around is to do the cast on the pointer type and dereference instead of the cast on the reference directly: =================================================================== RCS file: /cvsroot/boost/boost/boost/algorithm/string/classification.hpp,v retrieving revision 1.4 diff -u -r1.4 classification.hpp --- classification.hpp 15 Jul 2004 21:48:25 -0000 1.4 +++ classification.hpp 29 Jul 2004 21:32:49 -0000 @@ -236,8 +236,8 @@ const predicate_facade<Pred2T>& Pred2 ) { return detail::pred_andF<Pred1T,Pred2T>( - static_cast<const Pred1T&>(Pred1), - static_cast<const Pred2T&>(Pred2) ); + *static_cast<const Pred1T*>(&Pred1), + *static_cast<const Pred2T*>(&Pred2) ); } //! predicate 'or' composition predicate @@ -257,8 +257,8 @@ const predicate_facade<Pred2T>& Pred2 ) { return detail::pred_orF<Pred1T,Pred2T>( - static_cast<const Pred1T&>(Pred1), - static_cast<const Pred2T&>(Pred2)); + *static_cast<const Pred1T*>(&Pred1), + *static_cast<const Pred2T*>(&Pred2)); } //! predicate negation operator @@ -273,7 +273,7 @@ inline detail::pred_notF<PredT> operator!( const predicate_facade<PredT>& Pred ) { - return detail::pred_notF<PredT>(static_cast<const PredT&>(Pred)); + return detail::pred_notF<PredT>(*static_cast<const PredT*>(&Pred)); } } // namespace algorithm =================================================================== Those changes make it work on CW8, and it still works on VC7.1 and MinGW. OK to commit?? -- I'll assume the answer is *yes* after a few hours ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

3 5

[serialization] use of iterator_facade, CW8 build fixed.
by Rene Rivera 31 Jul '04

31 Jul '04

In another painfully hunt to fix the problems with the seriazation lib issues in CW8... I tracked the problem down to another instance of: static_cast<const&>(x) where x is a template with template ctors. The problem was in iterator_facade, and not directly in the serialization lib which made it even harder to find :-( Anyway, I applied this change (figured since this is a known problem by now with an easy portable solution it would not be a problem)... =================================================================== RCS file: /cvsroot/boost/boost/boost/iterator/iterator_facade.hpp,v retrieving revision 1.26 retrieving revision 1.27 diff -u -r1.26 -r1.27 --- iterator_facade.hpp 31 Jul 2004 18:10:00 -0000 1.26 +++ iterator_facade.hpp 31 Jul 2004 22:56:49 -0000 1.27 @@ -814,8 +814,8 @@ is_interoperable< Derived1, Derived2 >::value \ )); \ return_prefix iterator_core_access::base_op( \ - static_cast<Derived1 const&>(lhs) \ - , static_cast<Derived2 const&>(rhs) \ + *static_cast<Derived1 const*>(&lhs) \ + , *static_cast<Derived2 const*>(&rhs) \ , BOOST_ITERATOR_CONVERTIBLE(Derived2,Derived1) \ ); \ } =================================================================== After that the serialization lib builds, and tests run. Of course not all tests pass ;-) VC7.1 and Mingw behave as before also. PS. There was one other minor change to the libs/serialization/test/Jamfile to account for locale requirement. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

1 0

[Graph] New branch for graph library development (graph_devel)
by Doug Gregor 31 Jul '04

31 Jul '04

I've started a new branch for further development of the graph library, graph_devel. At the moment it contains only a small amount of work (Brandes' algorithm for betweenness centrality and the Kamada-Kawai spring layout for undirected graphs), but it will be used for more aggressive development as well. Algorithms will be merged to mainline so long as we _aren't_ planning a release in the next few days, but any infrastructure changes will remain on the branch for a bit longer. I've only branched the boost/graph and libs/graph directories. Doug

1 0

[thread] barrier.cpp don't compile with msvc60 & stlport]
by Sven Johannsen 31 Jul '04

31 Jul '04

Hi, with the current cvs-version (7/23/2004) i can't build the thread library with stlport 4.5.3 and msvc60. I use the following bjam command: bjam "-sTOOLS=msvc-stlport" "-sSTLPORT_PATH=D:\develop\STLPort" "-sSTLPORT_VERSION=4.5.3" and get the following errortext: ...\boost-23072004\libs\thread\build\..\src\barrier.cpp(21) : error C2440: 'type cast' : 'char [22]' kann nicht in 'class _STL::invalid_argument' konvertiert werden Quelltyp konnte von keinem Konstruktor angenommen werden, oder die Ueberladungsaufloesung des Konstruktors ist mehrdeutig Sorry about the german error-text. it's something about: can't convert char[22] to 'class _STL::invalid_argument' I don't know that wrong about: throw std::invalid_argument("count cannot be zero."); because the StlPort defines invalid_argument as: class _STLP_CLASS_DECLSPEC invalid_argument : public logic_error { public: invalid_argument(const string& __arg) : logic_error(__arg) {} # ifdef _STLP_OWN_IOSTREAMS ~invalid_argument() _STLP_NOTHROW_INHERENTLY; # endif }; With the microsoft stl everything compile fine. (bjam "-sTOOLS=msvc") Sven

5 10

Boost-wide report -- explicit failure markup not working?
by Jeff Garland 31 Jul '04

31 Jul '04

Looking at the boost-wide reports today, testmicrosec_time_clock is marked as failing red on a whole series of compilers. However, they should be 'green' (and have been in past reports) as they have been explicitly marked as failing: http://www.meta-comm.com/engineering/boost-regression/developer/date_time.h… <test name="testmicrosec_time_clock"> <mark-failure> <toolset name="msvc"/> <toolset name="vc7"/> <toolset name="vc7.1"/> <toolset name="cwpro8"/> <toolset name="borland-5.6.4"/> <toolset name="gcc"/> <toolset name="borland"/> <toolset name="mingw"/> <toolset name="meta-como-win32-4.3.3-msvc"/> <note author="B. Garst" refid="22"/> </mark-failure> </test> Seems like there is something amiss in the results reporting... Jeff

5 5