July 2004 - Boost - lists.boost.org

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 13 Jul '04

13 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

RE: [boost] Generalizing the shared_ptr
by Max Khesin 13 Jul '04

13 Jul '04

As of version 3.1 boost shared_ptr has a constructor that takes a user-defined deleter: template<class Y, class D> shared_ptr(Y * p, D d): px(p), pn(p, d) { detail::sp_enable_shared_from_this(p, p, pn); } Maybe I missed something, but what is your library adding to this? m -----Original Message----- From: Maciej Sobczak [mailto:prog@msobczak.com] Sent: Wednesday, July 07, 2004 4:18 PM To: boost(a)lists.boost.org Subject: [boost] Generalizing the shared_ptr << File: scoped_handle.h >> << File: test.cc >> << File: ATT57508.txt >> 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/ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

5 4

[optional] outdated tests?
by Rene Rivera 13 Jul '04

13 Jul '04

Boost.Optional optional_test and optional_test_ref both have the following error: Cannot open include file: 'boost/detail/none.hpp': No such file or directory. But only on the Win32 tests, and not on the Linux test. Not sure what the discrepancy is about but the file is definitely not there in CVS. It got moved from boost/detail/none.hpp to boost/none.hpp. So if no one minds I'll fix it. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

2 3

Boost Socket
by Dan 13 Jul '04

13 Jul '04

Hugo Duncan has been laboring over what will hopefully be the Boost socket library. I need to do quite a bit of network programming so I would like to get in contact with Hugo. Hopefully Hugo reads this, but if not, does anybody know how to contact him? I've tried emailing him at his sourceforge address but so far haven't received a response. I'd like to find out what the status of his library is and hopefully help him complete and test the relevant parts of it. -Dan "The only impossible task is the task you never start"

2 1

Re: Boost Digest, Vol 779, Issue 4
by François Dumont 13 Jul '04

13 Jul '04

Thanks for your advise about avoiding the call_traits library. I finaly based my code on the type_traits library even if the param_type from call_traits is quite a usefull type. If call_traits was deprecated putting a param_type in type_traits sounds to me like a good idear. About the doc I also had the feeling of an incomplete one for type_traits for 2 reasons. add_const<add_reference> do not lead to the same type as add_reference<add_const>, even if I agree with this behavior, a little note about it in the doc would be great. Second is about the compiler support of the type_traits feature. Isn't there yet any compiler able to give info about the compiled types? But of course it might appear as a commercial information so it is only a suggestion. Just for you to know my major insterest in boost is not in its type_traits library but in the move semantic lib. How is it going? For the coming STLport version I have added a very simple move constructor framework. It is not documented as I don't think that STLport is the right place for this kind of library. As soon as the next STLport version is released I will have a closer look on the boost move semantic lib. Francois Dumont > > Date: Mon, 05 Jul 2004 16:55:50 -0400 > From: David Abrahams <dave(a)boost-consulting.com> > Subject: [boost] Re: Fw: STLport & boost > To: boost(a)lists.boost.org > Message-ID: <uzn6erx61.fsf(a)boost-consulting.com> > Content-Type: text/plain; charset=iso-8859-1 > > François Dumont <francois.cppdevs(a)free.fr> writes: > > > Hello > > > > I am currently actively contributing to STLport. One of my > > contribution is to make boost and STLport closer. I think STLport can > > gain a lot in using some of the boost libraries and then boost will be > > able to count on a robust std lib. > > This sounds really cool, BTW. > > > For the moment I only use 2 libraries from boost, type_traits and > > call_traits. > > Take care with call_traits. The documentation isn't very clear about > how it behaves in all circumstances (especially on broken compilers). > I would be inclined to build my own individual metafunctions (rather > than traits "blobs") for doing the kinds of thigs that call_traits > tries to address. > > -- > Dave Abrahams > Boost Consulting > http://www.boost-consulting.com >

2 1

Question about Boost.Random
by Anders Edin 12 Jul '04

12 Jul '04

// The following program illustrates a problem in Boost.Random. // Is this the desired behavior? // If so, what is the reason for this? // I use Boost version 1.31 and GCC version 3.3.3 on Suse 9.1 #include <vector> #include <algorithm> #include <boost/random.hpp> // Definition of the random number generator typedef boost::mt19937 engine_t; typedef boost::uniform_int<int> distribution_t; typedef boost::variate_generator<engine_t, distribution_t> rng_t; int main() { const unsigned int N = 13, A = 0, B = 1000; std::vector<int> run1(N), run2(N), run3(N); // Generate some random integers { engine_t engine; distribution_t distribution(A,B); rng_t rng(engine, distribution); std::generate(run1.begin(), run1.end(), rng); } // Verify that I get the same sequence if I start again { engine_t engine; distribution_t distribution(A,B); rng_t rng(engine, distribution); std::generate(run2.begin(), run2.end(), rng); } // It appears that the generator restarts for each generate, since // the generate algorithm creates a copy of the functor so that // its state is lost { engine_t engine; distribution_t distribution(A,B); rng_t rng(engine, distribution); std::generate(run3.begin(), run3.begin()+N/2, rng); std::generate(run3.begin()+N/2, run3.end(), rng); } // For me it would seem more natural if the engine class would be a // singleton, so that there can be only one object of any particular // random generator engine type. // Our purpose for using random numbers is to simulate physical processes. // I can't think of a case when there would be a need for several random // engines, even if there can of course be many different random // distributions in an application. // Having the same random number sequence in different parts of a simulation // can probably create very strange behaviour, since the numbers from the // different engines of the same type will be perfectly correlated. // Perhaps other applications have use of several random engines? for(unsigned i=0; i<N; ++i) { if(i==N/2) std::cout<<"Halfway there!"<<std::endl; std::cout <<run1[i] <<" == "<<run2[i] <<" == "<<run3[i] <<std::endl; } return 0; } // Anders Edin // Sidec Technologies AB

2 3

"memory access violation" in boost::serialization
by Dirk Griffioen 12 Jul '04

12 Jul '04

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). Thanks in advance, Dirk

2 1

[Boost-bugs] [ boost-Bugs-989487 ] wrong usage of ios_base::narrow
by SourceForge.net 12 Jul '04

12 Jul '04

Bugs item #989487, was opened at 2004-07-12 22:03 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=989487&group_i… Category: date_time Group: None Status: Open Resolution: None Priority: 5 Submitted By: Vyacheslav E. Andrejev (vandrejev) Assigned to: Jeff Garland (az_sw_dude) Summary: wrong usage of ios_base::narrow Initial Comment: /cvsroot/boost/boost/boost/date_time/date_parsing.hpp revision 1.18, lines 207, 214 std::stringstream has char_type typedef evidently equal to char, not wchar_t, so in std::stringstream::narrow function the first argument has type char and in the call ss << ss.narrow(*beg++, 'X'); *beg will be converted from wchar_t to char before call to narrow will be made. I suggest the following patch: diff -c -r1.18 date_parsing.hpp *************** *** 207,214 **** wchar_t) { std::stringstream ss(""); while(beg != end) { ! ss << ss.narrow(*beg++, 'X'); // 'X' will cause exception to be thrown } return parse_date<date_type>(ss.str()); } --- 207,215 ---- wchar_t) { std::stringstream ss(""); + std::locale loc; while(beg != end) { ! ss << std::use_facet<std::ctype<wchar_t> > (loc).narrow(*beg++, 'X'); } return parse_date<date_type>(ss.str()); } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=989487&group_i… ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0