- Boost - lists.boost.org

[program_options] Comeau DLL failures
by Vladimir Prus 13 Jul '04

13 Jul '04

Hello, the program_options test results for Comeau (e.g. http://tinyurl.com/4zl6f) show that it does not understand __declspec. Anybody has ideas why? Maybe, we should pass "--windows" to that compiler, or somehow enable __declspec support? - Volodya

1 0

Sombody broke the build system?
by David Abrahams 13 Jul '04

13 Jul '04

This just started happening: cd c:/tmp/ myjam -sTOOLS=gcc foo.obj BD Software STL Message Decryptor v2.43 for gcc c:\tmp\../boost/tools/build/v1\testing.jam:51: in boost-test *** argument error * rule get-library-name ( path ) * called with: ( ) * missing argument path c:\tmp\../boost/tools/build/v1\testing.jam:21:see definition of rule 'get-library-name' being called c:\tmp\../boost/tools/build/v1\testing.jam:470: in run Jamfile:3: in load-jamfiles c:\tmp\..\boost\tools\build\v1\bootstrap.jam:22: in boost-build c:\tmp\boost-build.jam:6: in module scope Compilation finished at Tue Jul 13 08:46:09 -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

RE: [boost] Re: "memory access violation" in boost::serialization
by Dirk Griffioen 13 Jul '04

13 Jul '04

Thanks Jeff, Your solution works - with a little twist: I took the solution from #20 (thanks Robert!) and now it loooks like: if(NULL != t.pi_) t.pi_->add_ref_copy(); I also outcommented line 125. & now my app works fine! We will, however, upgrade to #20 as soon as possible. Regarding the little discussion: it might very well be the case that uses find the library very usefull, without too many a problem. We certainly do, for instance on windows 2k (vc71) and HP True64 (probably gcc but I'm not sure). We have a lot of platforms here (HP, AIX, SUN, VMS, AS400 and Mainframe - with different versions of native compilers and/or gcc) and it is likely we will port to those platforms. If there's an interest, it might be possible to gather some figures. Cheers, Dirk -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jeff Flinn Sent: maandag 12 juli 2004 17:07 To: boost(a)lists.boost.org Subject: [boost] Re: "memory access violation" in boost::serialization "Dirk Griffioen" <d.griffioen(a)HumanInference.com> wrote in message news:2505062E579A9B45888B70D9BCFB3C073BA8BD@ex03.hidomain... > Hi, > > I encountered the following little problem: > > I would like to use the following datastructures with boost::serialize: > > struct Match {}; > typedef std::string Key; > typedef tst< Match, Key > TernarySearchTree; //this one has a shared_ptr > > typedef std::vector< TernarySearchTree > Trees; > typedef std::map< std::string, Trees > Symbols; > > I have defined some serialize overloads so saving goes fine, but when > loading I get a "memory acces violation" inside the following code: > > { > boost::archive::text_iarchive ia(ifs); > ia >> symbols_; > } > > More specific, inside <boost/serializiton/shared_count.hpp> > > void add_ref_copy() > { > #if defined(BOOST_HAS_THREADS) > mutex_type::scoped_lock lock(mtx_); > #endif > ++use_count_; > } > > Which constructs a scoped_lock, and there, the "explicit > scoped_lock(lightweight_mutex & m): m_(m)" seems to go wrong. Actually you'll find that the this pointer is either NULL or invalid. > > What could be the reason? The more since all worked fine (saving and > loading) when I used a simple vector of tst's. The following changes to .../boost/serialization/shared_ptr.hpp should do it: change line 74: if(t) t->add_ref_copy(); and comment out line 125: // shared_ptr_access::weak_count(*t) = 0; IIRC, line 125 is the primary culprit. ----------------- Jeff Flinn Applied Dynamics, International _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Pretty Good Initialization Library
by Andrei Alexandrescu (See Website for Email) 13 Jul '04

13 Jul '04

Just sent the message below to clc++m. Any comments are welcome. There's a library that I understand is being proposed for Boost: http://www.codeproject.com/vcpp/stl/PGIL.asp It does useful things, but it runs straight against the commonly given advice (with which I happen to agree) that one should not override operator, unless using expression templates that ensure left-to-right evaluation. So now, in the referenced article, the author makes the comment: " Overloading operator comma is sometimes viewed as a bad practice [3]. However, it has been done with success in eg. the Generative Matrix Computation Library and Blitz to initialize matrices (see [4]) and [5]). The Initialization Library overloads the comma operator in a safe manner by letting set_cont and set_map return an object that is responsible for the initialization. Therefore it takes explicit action from the programmer to begin using the overloaded operator,(). " I think the mentioned libraries do employ expression templates, while the initialization library does not. So I am unsatisfied. Anyone here can soothe my concerns? Is overloading the comma operator considered harmless after all? Andrei

11 34

"bin" directories clean-up [Was: Regression testing goes horribly wrong! (+ patch)]
by Aleksey Gurtovoy 13 Jul '04

13 Jul '04

Guillaume Melquiond writes: > Le lun 12/07/2004 à 04:22, Aleksey Gurtovoy a écrit : > > [...] > > > > Maybe you did patch some Jamfiles or bjam? > > > > "boost\tools\build\v1\testing.jam" > > Great! > > > I don't know if it is actually necessary (or if it is even possible), > but maybe a similar patch should be applied to bjam v2? Most likely, but that's something we can worry about after the release. > I have another concern. Maybe I'm overly pessimistic, but I think > regression testers should restart their testing from scratch (rm -r > boost/bin, or whatever it is called) now that the format has changed, > shouldn't they? If somebody is still experiencing the problems we were fighting, yes. Looking at the reports, it seems that SunOS and Darwin platforms might need it. BTW, it would be nice if these reports' comments listed a contact point. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Generalizing the shared_ptr
by Maciej Sobczak 13 Jul '04

13 Jul '04

Hi, (not sure if it was discussed before) I've found Boost smart pointers inflexible in the sense that they operate only on pointers. It would be a good idea to generalize their interface to handle just about anything that requires special care when destroying. HANDLE (on Windows), FILE*, file descriptors (on Unix), third-party API handles, etc. come to mind. I wrote a very simple class (see attachments), scoped_handle, which encapsulates the resource (whatever it is) and its disposing (whatever that means). The techniques used are similar to those used in implementation of boost::shared_ptr. The example file shows how the class can be used to guard resources allocated by operator new, fopen, open, etc. Is it possible to achieve the same results with the existing Boost libraries? If not, is there any interest in developing this kind of class? -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/ // // Copyright (C) 2004 Maciej Sobczak // http://www.msobczak.com/ // // Permission to copy, use, modify, sell and distribute this software // is granted provided this copyright notice appears in all copies. // This software is provided "as is" without express or implied // warranty, and with no claim as to its suitability for any purpose. // #ifndef SCOPED_HANDLER_H_INCLUDED #define SCOPED_HANDLER_H_INCLUDED template <typename Resource> class disposer_base { public: virtual ~disposer_base() {} virtual void dispose(Resource) = 0; }; template <typename Resource, typename Deleter> class disposer_impl : public disposer_base<Resource> { public: disposer_impl(Deleter d) : d_(d) {} void dispose(Resource r) { d_(r); } private: Deleter d_; }; template <typename Resource> void simpleDeleter(Resource r) { delete r; } template <typename Resource> void arrayDeleter(Resource r) { delete [] r; } // requirements: // Resource and Deleter are copy-constructible and do not throw while copying // For Resource r and Deleter d, d(r) is a valid expression that doesn't throw template <typename Resource> class scoped_handle { public: scoped_handle(Resource r) : r_(r) { initDeleter(simpleDeleter<Resource>); } template <typename Deleter> scoped_handle(Resource r, Deleter d) : r_(r) { initDeleter(d); } ~scoped_handle() { disp_->dispose(r_); delete disp_; } Resource get() const { return r_; } private: scoped_handle(const scoped_handle &); scoped_handle & operator=(const scoped_handle &); template <typename Deleter> void initDeleter(Deleter d) { try { disp_ = new disposer_impl<Resource, Deleter>(d); } catch (...) { d(r_); throw; } } disposer_base<Resource> *disp_; Resource r_; }; #endif // SCOPED_HANDLER_H_INCLUDED #include "scoped_handle.h" #include <iostream> #include <functional> // this is for Unix only #include <fcntl.h> #include <unistd.h> using namespace std; class A { public: A() { cout << "A()\n"; } ~A() { cout << "~A()\n"; } }; void specialDeleter(A *p) { cout << "special deleter: "; delete p; } void anotherSpecialDeleter(A *p, int i) { cout << "another special deleter (" << i << "): "; delete p; } int main() { { scoped_handle<A*> h1(new A); scoped_handle<A*> h2(new A, specialDeleter); scoped_handle<A*> h3(new A, bind2nd(ptr_fun(anotherSpecialDeleter), 7)); // resources are released in the reverse order } { scoped_handle<FILE*> h4(fopen("test.txt", "w"), fclose); // ... } { // this is for Unix only scoped_handle<int> h5(open("test.txt", O_RDONLY), close); // ... } // etc. }

2 3

New version of MPL?
by Joaquín Mª López Muñoz 13 Jul '04

13 Jul '04

According to 1.32 release plans, a new version of MPL would have to be checked in main CVS by Sunday; if I'm not wrong, this hasn't happened yet. * Any news regarding the new MPL? * Is still July 16 a realistic date for branching? Unless the new MPL checks in real smooth, I'm afraid 4 days is probably too little time to tidy everything up. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Boost.Random patch for gcc-3.4.1
by Synge Todo 13 Jul '04

13 Jul '04

Dear Boosters, I'm sending a small patch for Boost.Random to compile by using gcc-3.4.1 (on Linux Fedora Core 2). Could somebody apply this patch? Thank you in advance. Best regards, Synge Todo diff -crN boost-20040713.orig/boost/random/lagged_fibonacci.hpp boost-20040713/boost/random/lagged_fibonacci.hpp *** boost-20040713.orig/boost/random/lagged_fibonacci.hpp Fri Jul 2 10:21:32 2004 --- boost-20040713/boost/random/lagged_fibonacci.hpp Tue Jul 13 14:10:44 2004 *************** *** 23,28 **** --- 23,29 ---- #include <iostream> #include <algorithm> // std::max + #include <cmath> #include <iterator> #include <boost/config.hpp> #include <boost/limits.hpp> diff -crN boost-20040713.orig/boost/random/subtract_with_carry.hpp boost-20040713/boost/random/subtract_with_carry.hpp *** boost-20040713.orig/boost/random/subtract_with_carry.hpp Fri Feb 27 03:26:54 2004 --- boost-20040713/boost/random/subtract_with_carry.hpp Tue Jul 13 14:10:56 2004 *************** *** 23,28 **** --- 23,29 ---- #include <iostream> #include <algorithm> // std::equal + #include <cmath> #include <stdexcept> #include <boost/config.hpp> #include <boost/limits.hpp>

1 0

Lambda and VC71 ICE
by Richard Crossley 13 Jul '04

13 Jul '04

With the current CVS I'm getting an ICE with VC71. Console project, single .cpp file containing the single line: #include <boost/lambda/bind.hpp> Compiling... lambda_fail.cpp C:\boost\boost\lambda\detail\lambda_functors.hpp(172) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 2701) Tried various permutations of complier options but the ICE is consistent. Regards, Richard.

2 1

Re:[boost] "memory access violation" in boost::serialization
by Robert Ramey 12 Jul '04

12 Jul '04

I presume you are using serialization draft # 18 upload last april. Since then helpful users have found a couple of bugs which I have subsequently fixed. There is a more recent version that I have tested with boost 1.31 at www.rrsd.com. It is labeled serialization #20. I am currently struggling - so far with only limited success - in getting the most recent version of the serialization library checked in to the main boost CVS. This as been too slow to get it done but too fast to give up on. Regarding your particular problem, I believe that this came up under the the condition where a n object is saved through a pointer to its base class and it was not registered or exported. This has been addressed in the current library by throwing an exception. Of course this helps characterize the problem - but it doesn't really fix the cause. This latter one has to do himself. BTW, there have been a couple of other small bug fixes related to some collections (hmm - map was among them!)- this might or might not address your symptoms. Another bug in the serialization of shared_ptr was uncovered which was causing a memory leak. I hope all this helps. Thanks for the feedback. As an aside - I notice that I'm getting about 300 downloads/month of the serialization package from my web site. I have no information about downloads from the Yahoo/Boost files area - (which I would be curious to know). I get very little feedback - I'm wondering if lots of downloaders take a look and decide it's too complex to actually use. Robert Ramey >Hi, >I encountered the following little problem: >I would like to use the following datastructures with boost::serialize: >struct Match {}; >typedef std::string Key; >typedef tst< Match, Key > TernarySearchTree; //this one has a shared_ptr >typedef std::vector< TernarySearchTree > Trees; >typedef std::map< std::string, Trees > Symbols; >I have defined some serialize overloads so saving goes fine, but when >loading I get a "memory acces violation" inside the following code: >{ > boost::archive::text_iarchive ia(ifs); > ia >> symbols_; >} >More specific, inside <boost/serializiton/shared_count.hpp> > void add_ref_copy() > { >#if defined(BOOST_HAS_THREADS) > mutex_type::scoped_lock lock(mtx_); >#endif > ++use_count_; > } >Which constructs a scoped_lock, and there, the "explicit >scoped_lock(lightweight_mutex & m): m_(m)" seems to go wrong. >What could be the reason? The more since all worked fine (saving and >loading) when I used a simple vector of tst's. >Is it not possible to use a map of string/vector (the error seems to >suggest the library failing when copying vector to map - eg ++use_count >of the shared_ptr inside the TST).

3 2