- Boost - lists.boost.org

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

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

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

12 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

Problem about build regex under win32 using stlpot5.0
by huangliang 12 Jul '04

12 Jul '04

Recently I begin to use stlport in my programs, and I want to build boost regex under win32 using vc6 and stlport 5.0. But when I build them,the following errors occurs: C:\lib\boost-1.30.2\libs\regex\build>set MSVCDIR= D:\Program Files\Microsoft Visual Studio\VC98\Bin C:\lib\boost-1.30.2\libs\regex\build>set STLPORT_PATH=E:/HuangLiang/c++stl/STLport-5.0-1031 C:\lib\boost-1.30.2\libs\regex\build>nmake -fvc6-stlport.mak cl /nologo /MT /W3 /GX /O2 /GB /GF /Gy /IE:/HuangLiang/c++stl/STLport-5.0-1031\stlport /I..\..\..\ /D_MT /DWIN32 /DNDEBUG /D_MBCS /D_LIB /YX /FD /c -Fpvc6-stlport/boost_regex_vc6-stlport_mss/boost_regex_vc6-stlport_mss.pch -Fo./vc6-stlport/boost_regex_vc6-stlport_mss/ -Fdvc6-stlport/boost_regex_vc6-stlport_mss.pdb ../src/cpp_regex_traits.cpp cpp_regex_traits.cpp ../src/cpp_regex_traits.cpp(662) : error C2660: 'isspace' : function does not take 2 parameters ../src/cpp_regex_traits.cpp(662) : fatal error C1903: unable to recover from previous error(s); stopping compilation After I searched msdn, I found that isspace have been defined at 2 places: isspace template<class E> bool isspace(E c, const locale& loc) const; The template function returns use_facet< ctype<E> >(loc). is(ctype<E>:: space, c). and in ctype.h. I remember when I compile regex using vc6 without stlport, no same errors occured. I need some help about what has happened with me. Thank you !

2 1

VC 7.1: unable to bind specialized member function template
by Stefan Slapeta 12 Jul '04

12 Jul '04

Hi all, this code sample produces a compiler error on VC 7.1. It seems that boost::bind isn't able to get the right type for the specialization of the member function template [&Test::g<Type1, Type2>]. Is there a good workaround? (The only one I could find so far is to 'hide' the function template as normal member function in a class template.) Intel 8.0 compiles ok! #include <boost/bind.hpp> #include <boost/function.hpp> class Test { public: template <typename Type1, typename Type2> void f(Type1 one, Type2 two) { boost::function<void (Type1, Type2)> bf = boost::bind(&Test::g<Type1, Type2>, this, one, two); } template <typename Type1, typename Type2> void g(Type1, Type2) { } }; int main() { Test t; t.f(0, 0); }

2 3

[Boost-bugs] [ boost-Bugs-989168 ] intrusive_ptr may cause dungling ptr access
by SourceForge.net 12 Jul '04

12 Jul '04

Bugs item #989168, was opened at 2004-07-11 20:04 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=989168&group_i… Category: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Peter Dimov (pdimov) Summary: intrusive_ptr may cause dungling ptr access Initial Comment: I think intrusive_ptr may cause dungling ptr access in multithreaded environment. Currently, it's constructor is: intrusive_ptr(T * p, bool add_ref = true) : p_(p) /* the object may be deleted by other thread because this thread does not increment reference counter yet. */ { if(p_ != 0 && add_ref) intrusive_ptr_add_ref(p_); /* this may occur dungling ptr operation. */ } We can avoid this problem by "addref-before-use" policy. intrusive_ptr(T * p, bool add_ref = true) { if(p != 0 && add_ref) intrusive_ptr_add_ref(p_); /* other thread never delete the object */ p_ = p; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=989168&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

Yet more math functions - a draft TR2 proposal
by Paul A Bristow 12 Jul '04

12 Jul '04

I posted a note previous with modest reponse. In the hope that a better link will provoke some more reaction, I am reposting. As promised recently, I am presenting a draft of proposals for math functions which are needed for even most elementary statistics. I have been encouraged to submit this to both the C and C++ Standard Library groups at the same time. (They seem to speaking more than in the past). These are additions to the list drawn up by Walter Brown accepted into TR-1. The style and format follows his closely even though there were some opposition to them from the C++ community. However I think we have to accept that C and C++ compatibility are valued more than C++ 'ideality', and not try to re-open this area of dissent. The draft has been uploaded to the files area in a new folder Math Functions as "More Mathematical Functions.pdf" 220 kb. It is accessible at: http://tinyurl.com/357a6 be grateful if some CVS whizz would copy it to the sandbox as I know that many are unable to access the files section. It would be useful to have comments on 1 Typographical mistakes. 2 Mathematical mistakes (prepared by someone with seriously rusty math!). 3 The choice of functions espcially if there are any your feel strongly are missing, or are not needed (say why). 4 The choice of names. Clarity is preferred to curtness. 5 The choice of names for derivatives like the inverse and complement. I have added suffixes _inc and _c (or _com?). ( for C there will be suffixes f and l for the float and long double versions). Thanks. Paul Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow(a)hetp.u-net.com

3 2