- Boost-users - lists.boost.org

member data pointer and nested bind
by JaeWook Choi 20 Feb '06

20 Feb '06

Hello, I've been trying to use STL alogorithms on POD struct data member without writing any user defined functor nor adding get/set member function to the POD sturct, instead I just wanted to use boost::mem_fn, boost::bind, boost::lambda for member data pointer. It was fine to use the member data pointer with any of boost::mem_fn, boost::bind and boost::lambda only until I tried to use them in the nested bind as an argument of outter bind. If I use them in nested bind, I got compile error message of "cannot convert parameter 1 from 'boost::_bi::bind_t<R,F,L> ' to 'const RECT *'" or "cannot convert parameter 1 from 'boost::lambda::lambda_functor<T>' to 'const RECT *'" As a boost newbie, it is too difficult for me to figure out the problem here. Maybe someone can help me out to sovle the problem. Thanks, Jae. The below is my test code. (BTW, I compiled it on VC71) ~~~ #include "stdafx.h" #include <wtypes.h> #include <vector> #include <algorithm> using std::vector; using std::find_if; #define BOOST_BIND_ENABLE_STDCALL #include <boost/bind.hpp> #include <boost/lambda/lambda.hpp> using boost::mem_fn; using boost::bind; // an arbitrary POD struct struct CTestClass { RECT rc; }; int main(int argc, char* argv[]) { vector<CTestClass> vecTestClass; CTestClass testObj = { { 0, 0, 100, 100} }; vecTestClass.push_back(testObj); ::OffsetRect(&testObj.rc, 100, 100); vecTestClass.push_back(testObj); LONG rc_left = mem_fn(&CTestClass::rc)(testObj).left; // mem_data_ptr & boost::mem_fn LONG rc_top = bind(&CTestClass::rc, _1)(testObj).top; // mem_data_ptr & boost::bind LONG rc_right = ((&boost::lambda::_1)->*&CTestClass::rc)(testObj).right; // mem_data_ptr & boost::lambda POINT ptTest = { 150, 150 }; ::PtInRect(&mem_fn(&CTestClass::rc)(testObj), ptTest); // ok ::PtInRect(&bind(&CTestClass::rc, _1)(testObj), ptTest); // ok ::PtInRect(&((&boost::lambda::_1)->*&CTestClass::rc)(testObj), ptTest); // ok vector<CTestClass>::iterator it_f1 = find_if(vecTestClass.begin(), vecTestClass.end(), bind(::PtInRect, &bind(&CTestClass::rc, _1), ptTest) ); // compile error! vector<CTestClass>::iterator it_f2 = find_if(vecTestClass.begin(), vecTestClass.end(), bind(::PtInRect, &((&boost::lambda::_1)->*&CTestClass::rc), ptTest) ); // compile error! return 0; } ~~~

2 5

Using push_relabel_max_flow
by Yannack 20 Feb '06

20 Feb '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everyone, I am new at the BGL, and I am having a little problem here. I need to calculate a max flow on a graph, so thought i would use push_relabel_max_flow. I get the correct value for the maxflow as the return value for the function, however, the residual capacities are really weird: the maxflow goes through cycles, and even when I have a maxflow with a value=1, I get some links with capacity=2 fully loaded to capacity... Is this normal behavior? If so, is there a way of getting the correct residual capacities without cycles? If not, is this a know bug? Is there a work around? Thank you very much for your help and time, Yannack -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+cEqrhthX5fBuCIRAq2aAJ9D6mCUnYKUXBClLjjSju7XqN76ywCfaObE tNd9iv52UCBjBi4eRVrjGHw= =l5gE -----END PGP SIGNATURE-----

1 0

Meta Template Programming with MPL - Compiler Bug or is the code really so evil slow?
by Vinzenz 'evilissimo' Feenstra 20 Feb '06

20 Feb '06

Hi, I've written a little Meta Template Program which should calculate the first 3 perfect numbers. ( range 1 - 500 ) The code is compilable if you use the range 1 - 30 really fast and works correctly. But I've tried to compile the code but I can't get it finished. Someone tried it on a Machine with 40 GB RAM and it now compiles for more than 12 hours and uses more than 7.1 GB RAM ( the compilation ) I've tried it by myself with g++ 3.4.x and g++ 4.0.x and with VC++ 7.1 The code works on all tested compilers if the range would be 1 - 30 but If the range is 1 - 500 VC++ says: d:\boost\vc71\include\boost-1_33_1\boost\mpl\aux_\preprocessed\plain\apply_wrap.hpp(48): fatal error C1204: compiler limit: internal structure overflow. ( This seems to be a known bug in VC++ http://support.microsoft.com/default.aspx?scid=kb;en-us;883655 ) and g++ compiles and compiles and uses more and more RAM. Is the code really so evil slow or is it a compiler Bug in g++? Maybe anyone has an answer. BR evilissimo #include <boost/mpl/long.hpp> #include <boost/mpl/range_c.hpp> #include <boost/mpl/vector_c.hpp> #include <boost/mpl/arithmetic.hpp> #include <boost/mpl/accumulate.hpp> #include <boost/mpl/back_inserter.hpp> #include <boost/mpl/equal.hpp> #include <boost/mpl/copy_if.hpp> #include <boost/mpl/at.hpp> #include <boost/mpl/size.hpp> #include <iostream> namespace mpl = boost::mpl; template < typename Sum , typename Div , typename Num > struct perf_num_plus_if : mpl::if_< mpl::equal_to< mpl::modulus< Num,Div > , mpl::long_<0> >, typename mpl::plus<Sum,Div>::type, Sum >::type {}; template< typename Num > struct perf_num_impl : mpl::accumulate< mpl::range_c< long, 1, Num::value/2+1 >, mpl::long_<0>, perf_num_plus_if< mpl::_, mpl::_, Num > >::type {}; template< long Start , long End > struct perfect_number : mpl::copy_if< mpl::range_c<long,Start,End>, mpl::equal_to< mpl::_1 , perf_num_impl<mpl::_1> >, mpl::back_inserter< mpl::vector_c<long> > >::type {}; template< typename Seq , size_t Pos , size_t Max > struct Output { Output() { std::cout << mpl::at_c<Seq, Pos >::type::value << std::endl; Output< Seq , Pos+1 , Max >(); } }; template< typename Seq , size_t N > struct Output< Seq , N , N > { Output(){} }; int main() { typedef perfect_number< 1 , 500 > vec; Output< vec , 0 , mpl::size< vec >::value >(); }

3 2

Re: [Boost-users] [Serialization]: bug while serializingastd::string
by RIVASSEAU Jean Noel 20 Feb '06

20 Feb '06

As written in a previous mail (re read ;) I have tried strstream, which effectively does NOT triggers the bug. I will try to make small examples from you, I don't know if I'll manage to however. To test them, you will probably need to install the Qt 4.1 libraries as my project uses them. Jean-Noël _____ De : boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] De la part de Robert Ramey Envoyé : vendredi 17 février 2006 16:48 À : boost-users(a)lists.boost.org Objet : Re: [Boost-users] [Serialization]: bug while serializingastd::string also try using strstream as it does no code conversion. If you can make small example that illustrates the problem I would be glad to look at it. Robert Ramey "RIVASSEAU Jean Noel" <JN.RIVASSEAU(a)oberthurcs.com> wrote in message news:87F60F7FA02FF749AFB02BD9FCAA6B04D27419@naserv31.nanterre.oberthurcs.com... Hello I have tried to open an archive in text mode with no_codecvt attribute, like this: std::ifstream ifs("archive.mob"); boost::archive::text_iarchive ia(ifs, boost::archive::no_codecvt); but it still triggers the bug. I do not think the bug is due to something that is not handled in the stream, since I do not have any special characters or stuff like that (except end lines). Plus, the fact that it crashes at the magical number 512 characters get me to think it is more related to a buffer problem, however, you are the specialist. How can I investigate the code conversion facets used by text archive? I am not familiar at all with locales, or facets, but if you give me some hints about how they are used in the BSL, I may get started. Regards Jean-Noël Ps: everything works fine in XML archive mode, so for my project I have switched to that, but I'd still like to get this bug fixed for the benefits of all... _____ De : boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] De la part de Robert Ramey Envoyé : jeudi 9 février 2006 17:11 À : boost-users(a)lists.boost.org Objet : Re: [Boost-users] [Serialization]: bug while serializingastd::string Sorry I got mixed up with another post. The main difference between strstream and other streams is that strstream doesn't do any code conversion. This is also consistent with the idea that something in the string isn't being handled in the code conversion facet of the the stream in the expected manner. a couple of ideas would be to investicate the code conversion facets used by the text archive. Also look at the no_codecvt attribute on archive open. Robert Ramey "RIVASSEAU Jean Noel" <JN.RIVASSEAU(a)oberthurcs.com> wrote in message news:87F60F7FA02FF749AFB02BD9FCAA6B04CB28D4@naserv31.nanterre.oberthurcs.com... I am assuming you meant : std::ofstream ifs("container.mob"); boost::archive::text_oarchive ia(ofs); oa << MyObject; ofs << std::endl; and not std::ifstream ifs. So if I understand well, this "patch" only adds a newline to the archive at the saving stage. I tried it but it did not help in any way; in fact I cannot see how it could help, since the problem is at the point of the loading of the std::string, not at the end of the load of the whole object. What I mean here is that MyObject is, in my case, a class containing a std::vector of pointers to class containing std::strings. One of these strings is too long, which causes the crash. Maybe what you meant is appending the std::endl after the serialization of the std::string, but this is not possible since at this point I have only access to the archive, not the underlying ofstream : template<class Archive> void serialize(Archive & ar, const MyClass& m, const unsigned int version) { ar & m.a_standard_string; } I do not have access there to the underlying ofstream of the implementation. Note that here, MyObject would contain a std::vector < MyClass * >. And I am serializing directly MyObject which causes the serialization of MyClass later. So, what do you mean? Have you located the bug ? _____ De : boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] De la part de Robert Ramey Envoyé : jeudi 9 février 2006 04:46 À : boost-users(a)lists.boost.org Objet : Re: [Boost-users] [Serialization]: bug while serializing astd:string Untl 1.34 comes out try the following on the output stream std::ifstream ofs("container.mob"); boost::archive::text_oarchive ia(ofs); oa << MyObject; ofs << std::endl; "RIVASSEAU Jean Noel" <JN.RIVASSEAU(a)oberthurcs.com> wrote in message news:87F60F7FA02FF749AFB02BD9FCAA6B04C87411@naserv31.nanterre.oberthurcs.com... I have been able to test with a string stream; the bug does not occur. That is, this code produces the bug: std::ifstream ifs("container.mob"); boost::archive::text_iarchive ia(ifs); ia & MyObject; while the following does not: std::ifstream ifs("container.mob"); std::ostringstream tmp; tmp << ifs.rdbuf(); std::istringstream is(tmp.str()); boost::archive::text_iarchive ia(is); ia & MyObject; a) try using a different stream buffer - strstream So do you have any clue, Robert ?? Clearly the problem has to do with buffering somewhere.... Jean-Noël _____ _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users _____ _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users _____ _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: [Boost-users] [bcp] [shared_ptr] [wave] Extracting subset ofboostforshared_ptr - 3.2MB?
by Nat Goodspeed 19 Feb '06

19 Feb '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of David Abrahams > Sent: Saturday, February 18, 2006 1:02 PM > To: boost-users(a)lists.boost.org > Cc: Hartmut Kaiser > Subject: Re: [Boost-users] [bcp] [shared_ptr] [wave] Extracting subset > ofboostforshared_ptr - 3.2MB? > > "John Maddock" <john(a)johnmaddock.co.uk> writes: > > >> Unfortunately bcp isn't smart enough to not look into optional > >> dependencies that are guarded by #ifdef. > > we need a better system. It would be > a lot of work, but maybe it would be the first real use of Wave as a > library rather than just as a preprocessor. We could use the graph > library to do a real search with some knowledge of compiler and > configuration #defines. [Nat] That was my reaction as soon as I first saw John's post "bcp isn't smart enough...": wow, he could use Wave! But I'm confused as to why you'd need the graph library? Wouldn't it work just to point bcp to the compiler of interest -- by giving it the name of one of a set of small prepackaged files that #defines the vendor-specific compiler-predefined macros that Boost cares about -- and let bcp operate on post-Wave, fully-preprocessed source code? Ah: that would actually discard the identities of all the #included files! Sigh. Nonetheless, it feels as if that approach could be tweaked to get much closer to the "I only care about this one compiler" use case than is currently possible.

4 12

Re: [Boost-users] [bcp] [shared_ptr] [wave] Extracting subsetofboostforshared_ptr - 3.2MB?
by Nat Goodspeed 19 Feb '06

19 Feb '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of David Abrahams > Sent: Saturday, February 18, 2006 1:42 PM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] [bcp] [shared_ptr] [wave] Extracting > subsetofboostforshared_ptr - 3.2MB? > > > Wouldn't it > > work just to point bcp to the compiler of interest -- by giving it the > > name of one of a set of small prepackaged files that #defines the > > vendor-specific compiler-predefined macros that Boost cares about -- > > Also, there are macros introduced by Jamfiles and configuration macros > set by users in their own Jam/Make/whateverfiles. Unless you know > what their values will be ahead of time, you may leave out some files > the user will need. [Nat] Okay. But the reason I suggested capturing a compiler's typical #defines in a config file was to enable a user to create a custom one containing their own #defines as well. Heh, the custom config file wouldn't need to *clone* the generic one packaged with bcp: it could #include the generic one and then add to it.

1 0

Regex++
by Winson Yung 19 Feb '06

19 Feb '06

Hello all, I am a new user of Boost Regex++, I have seen some strange behavior from the return of Regex++. Not sure this is the right mailing list to ask such a question or not. If not, please refer me to the right one. Here is my question: My program is written in MFC, and it has been built under both Visual C++ 6 and Visual Studio .NET 2003. Under Visual Studio .NET 2003, the following code returns result = 1, however expr[1].c_str() always returns an empty string. boost::RegEx expr(itField->GetFieldRegEx(), TRUE); unsigned int result = expr.Grep(v, wholeFileStr); if (result != 0) { for (int i = 1;i <= itField->GetMatchNum();i++) { const char *buf = expr[i].c_str(); // Get match result if (std::strlen(buf) == 0) { The same code works fine under Visual C++ 6 with the same content inside wholeFindStr.

2 2

[pkg-boost-devel] Boost on Debian
by Steve M. Robbins 19 Feb '06

19 Feb '06

Hello Dave, I'm responding to your message on boost mailing list http://lists.boost.org/Archives/boost/2006/02/100262.php Domenico Andreoli also contributed to this response. Apologies for the tardy response. I read the list very infrequently via web archives and I have only just noticed the message. So you ask: I am going to be trying to write some new "getting started" documentation for Boost for the upcoming release. I would really like to include some information about what people can expect when they get Boost packages from their Debian, RedHat, whatever distribution. All of our documentation so far is written from the perspective that users have a complete Boost CVS tree, but I guess that's not true for everyone? Can you fill us in? The short answer is: someone wishing to develop code using Boost under Debian need install the package libboost-dev (and, possibly, other -dev packages like libboost-filesystem-dev). The headers as well as static and shared library files are all installed into standard linux locations. Compilation and linking is done with no special options other than specifying the library; e.g. "-lboost_filesystem". Our goal is to make the Debian Boost library packages as much like standard libraries as possible. For Debian, this means that headers and link-time library files are contained in a "-dev" package. In addition, for each library that builds a shared object, we have a separate, versioned package, e.g. "libboost-filesystem1.33.1". Normally, however, one isn't concerned with the library package because the "-dev" package depends on the shared library package and installing the former automatically brings in the latter. The list of all -dev packages can be obtained by looking at what libboost-dev suggests with standard Debian tools like "aptitude" or "apt-cache". The "-dev" package contains the "release" build with both single- and multi-threaded versions, in both static and shared flavours for a total of 4 libraries. So the developer may choose to link using "-llibboost_filesystem-gcc-1_33_1" or " "-llibboost_filesystem-gcc-mt-1_33_1", shared or static. We also provide a shorthand symbolic link for the multithreaded version; you can use just "-llibboost_filesystem" (shared or static). In addition to the "-dev" packages, we have libboost-doc (documentation) bcp boost-jam boost-build (v2) Finally, there is a "libboost-dbg" package that contains the debug build of all the shared libraries, both single- and multi-threaded. Hope this is helpful, -Steve _______________________________________________ pkg-boost-devel mailing list pkg-boost-devel(a)lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-boost-devel

1 0

[Boost.Build v2] doc defect
by jth01＠arcor.de 18 Feb '06

18 Feb '06

Hello, /doc/src/advanced.xml introduces the unit-test rule but says nothing about import testing ; being necessary in order to use it. I'm not sure: Are trivial reports like this desired? Jens

1 0

[Tuple documentation] Maybe a bug
by raulh39＠ya.com 18 Feb '06

18 Feb '06

Hello Newsgroup, I think that in "libs/tuple/doc/tuple_advanced_interface.html" there is a mistake: "The template access_traits defines three type functions. Let T be a type of an element in a tuple: 1. access_traits<T>::type maps T to the return type ... " There is no such member "::type". ¿Maybe it is "::non_const_type"? Best regards, Raúl.

1 0