- Boost-users - lists.preview.boost.org

Efficient removal of std::list items
by Cory Nelson 20 Dec '04

20 Dec '04

This seems like the type of thing boost may have an answer to, yet I still havn't found it: I have two std::lists, about 50,000 items in each. The items are all number ranges so two uints start and end. I need to remove one list from the other - exact matches or subranges only. Currently I'm using remove_if() to remove/shrink/split them but it is taking forever, around 30sec. Anyone know of a better solution? -- Cory Nelson http://www.int64.org

4 10

Re: [Boost-users] boost::variant with boost::signals leads to Internal Compiler Error with MSDEV 7.1
by Victor A. Wagner Jr. 20 Dec '04

20 Dec '04

your snippit compiles fine using my vs7.1 and the latest from CVS. is there some code needed to instantiate any of this needed to cause the ICE? At Monday 2004-12-20 08:30, you wrote: >Hi > >Environment: >MS 7.1 compile with MS implementation of STL >Boost 1.32.0 > >Summary: > >I get an internal compiler error using boost::variant as a parameter of a >boost::signal compiling with MSDEV 7.1, but not with gcc3.3/3.4 or MinGW >(3.5). > >Does anyone knows a workaround other than not using boost::signals? > >Details > >Using a signal with a variant of 2 simple classes (see code snippet) leads >to an >internal compiler error C1001. Using pragma command to turn optimisation >off as >Suggested by the compiler does not change a thing > >Does anyone knows a workaround? > >Regards, jom > >Here's the bad code snippet: > >#include <boost/bind.hpp> >#include <boost/signals.hpp> >#include <boost/variant.hpp> > >#include <vector> > >class MessageException : public std::exception >{ >public: > MessageException() > : std::exception( "Message error" ) > {} >}; > >class Message >{ >public: > typedef std::vector<unsigned char> Content; > > Message(unsigned int p, unsigned char def = ' ') > : m_vector( p, def ) > {} > > const Content& message() {return m_vector;} >private: > Content m_vector; >}; > >typedef boost::variant<MessageException, Message> MessageVariant; > >class TestWrap >{ >public: > TestWrap(){} > > typedef boost::signal1<void, MessageVariant> MessageSignal; > //typedef boost::signal<void (MessageVariant)> MessageSignal; > > > void send_signal (MessageVariant& variant) > { > m_message_signal( variant ); > } >private: > MessageSignal m_message_signal; >}; > > >_______________________________________________ >Boost-users mailing list >Boost-users(a)lists.boost.org >http://lists.boost.org/mailman/listinfo.cgi/boost-users Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

Bug in BGL with num_vertices( filtered_graph )
by Sebastian Weber 20 Dec '04

20 Dec '04

Hello there! I think I found a bug in the BGL concerning the num_vertices function applied to filtered graphs. I use the filtered graph stuff with a vertice predicate. When I loop through the filtered graph with the vertex_iterator, I end up with a loop over all vertices where the predicate is true, just as it is supposed to be. But the function num_vertices on the filtered graph does return me the number of vertices of the original graph and not of the filtered graph. My system: boost 1.32.0, g++ 3.3.4, debian sarge. My graph type is boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS > and boost::filtered_graph<graph_t, boost::keep_all, largest_component<graph_t> > Greetings, Sebastian Weber

3 5

enable_if for class templates
by Agoston Bejo 20 Dec '04

20 Dec '04

Has anyone succeeded in specializing class templates with enable_if under VC++7.1? I have created the simplest example possible and cannot imagine how I could rewrite so that no Internal Compiler Error occurs. I have tried with both the boost 1.31 and 1.32 headers, with no difference. ------------------------------------------------------ #include <iostream> #include <boost/utility/enable_if.hpp> #include <boost/type_traits.hpp> using namespace std; using namespace boost; template<typename T, typename E = void> struct A { enum { X = 0 }; }; template<typename T> struct A<T, typename enable_if< typename is_arithmetic<T> >::type> { enum { X = 1 }; }; template<typename T> struct A<T, typename enable_if< typename is_object<T> >::type> { enum { X = 2 }; }; struct B {}; int _tmain(int argc, _TCHAR* argv[]) { // cout << is_arithmetic<double>::value << endl; typedef A<float> Afloat; cout << Afloat::X << endl; // Internal Compiler Error cout << A<int>::X << endl; cout << A<B>::X << endl; return 0; } ------------------------------------------------------

3 4

Where should STL suggestions go?
by Jim Lear 20 Dec '04

20 Dec '04

I know this is not the correct place to suggest new features to the STL, but I can't find a similar group for STL. Any suggestions? Sorry for the interruption. P.S. In case you're wondering what the suggestion is: Add ability to use random access operators with iterators. E.g. vector<int> intv; ... vector<int>::iterator i=intv.begin(); intv[i]++; It seems odd and confusing that iterators have pointer semantics but not random access semantics. -- Jim Lear

8 21

Return type of boost::bind(...)
by Agoston Bejo 19 Dec '04

19 Dec '04

Hi! Is there an easy way to use the exact type of what boost::bind(...) returns? The example above sheds some light of the source of this question. It would be much better (actually this is what bind is for, isn't it?) if I didn't have to define the plus_5 struct in order to be able to use transform_iterator. I wrote it in the comment what I'm thinking about. I could delve deeply into the bind header files and try to explicitly find what the exact class definition is, but I suspect it would not be too easy. Anyway, I may be forced to do that. Thx, Agoston // ------------------------------------------- #include <iostream> #include <functional> #include <algorithm> #include <boost/iterator/transform_iterator.hpp> #include <boost/bind.hpp> using namespace std; using namespace boost; struct plus_5 : public unary_function<int, int> { int operator()(int i) const { return i + 5; } }; typedef transform_iterator<plus_5, int*> Iterator; //------- *** ---------------------- //typedef transform_iterator< bind_type<plus<5>, _1, 5>, int* > Iterator; // how to easily get the return type of bind(plus<5>(), _1, 5) // in compilation time? //------- *** ------------------------ int _tmain(int argc, _TCHAR* argv[]) { int ia[] = {1,2,3,4,5}; copy(Iterator(ia), Iterator(ia+5), ostream_iterator<int>(cout, " ")); cout << endl; return 0; }

3 3

[range]array of ints
by Duane Murphy 18 Dec '04

18 Dec '04

I am changing a code base that previously was using the no longer supported array_traits. I use the begin() and end() functions in a lot of places with arrays of integers. I have converted everything to using boost::range::begin() and end(). However, there is a severe collision. begin() and more importantly end() are overloaded for wchar_t. Turns out on Mac OS X, wchar_t is the same as an int. This causes end() to look for a null terminator instead of just using the array length template function. Is there a way I can make range::end() work for real array's of int rather than wchar_t? Thanks for any tips, ...Duane

2 2

Re: Trouble using shared_ptr with g++ -O0 and -O2 options
by Bjoern Rasmussen 18 Dec '04

18 Dec '04

Hello Andreas Unfortunately I haven't figured out what causes this, so right now I'm just using the -O0 option for my release version. Do you have a simple code example which provokes this error? Then I can try to test it on previous versions of g++ Kinds regards Bjoern D. Rasmussen >From: akabel(a)stanford.edu >To: "Bear" <bjoern_rasmussen(a)hotmail.com> >Subject: Re: Trouble using shared_ptr with g++ -O0 and -O2 options >Date: Fri, 17 Dec 2004 12:06:37 -0800 > > >Bear wrote: > > Hello there > > > > I'm getting a SIGSEGV when using the boost::shared_ptr in my program >and > > compiling with the g++ -O2 option, whereas if I'm using the g++ -O0 >option > > my programs works the way it should. My program is multi-threaded but >to the > > best of my knowledge it is mutex'ed correctly. > >I have a very similar problem in a (single-threaded) program. I tried >several compilers; Intel icc v8.0 behaves correctly, even for high >optimization level, >gcc 3.4 and gcc 3.3 dump core at -O2 and behave correctly at -O0. Did >you find >out what causes this? > >Thanks, > > Andreas > _________________________________________________________________ Del din verden med MSN Spaces http://spaces.msn.com

1 0

RE: [Boost-users] boost and memory allocations (signals and others)
by Frank Maddin 17 Dec '04

17 Dec '04

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Beman Dawes > Sent: Thursday, December 16, 2004 4:19 PM > To: boost-users(a)lists.boost.org; boost-users(a)lists.boost.org > Subject: Re: [Boost-users] boost and memory allocations (signals and > others) > > At 09:17 AM 12/15/2004, Caleb Epstein wrote: > >On Mon, 13 Dec 2004 09:01:01 -0800, Frank Maddin > <frankmad(a)microsoft.com> > > >wrote: > > > >> We've been thinking about using certain boost functionality on a > project. > > > >> We were trying to keep the number of allocations down. > > > >See the attached test program which makes the Hello class "noisy" and > >runs two different versions of your signals test. One uses object > >copy semantics and the other uses reference semantics. Compare the > >output: > > > >copy test: > >Hello::Hello () @ 0xbfffb950 > >Hello::Hello (const ref) @ 0xbfffb8c0 > >Hello::Hello (const ref) @ 0xbfffb870 > >Hello::Hello (const ref) @ 0xbfffb830 > >Hello::Hello (const ref) @ 0xbfffb7e0 > >Hello::Hello (const ref) @ 0x8050fb0 > >Hello::~Hello @ 0xbfffb7e0 > >Hello::~Hello @ 0xbfffb830 > >Hello::~Hello @ 0xbfffb870 > >Hello::~Hello @ 0xbfffb8c0 > >Hello::Hello (const ref) @ 0x8050fc0 > >Hello::Hello (const ref) @ 0x8050fc8 > >Hello::Hello (const ref) @ 0x8050fd0 > >Hello::~Hello @ 0x8050fc8 > >Hello::~Hello @ 0x8050fc0 > >Hello::~Hello @ 0x8050fb0 > >i = 1968 > >Hello::~Hello @ 0x8050fd0 > >Hello::~Hello @ 0xbfffb950 > > > >ref test: > >Hello::Hello () @ 0xbfffb950 > >i = 1968 > >Hello::~Hello @ 0xbfffb950 > > Wow! That is a pretty substantial difference. > > Seems like the signals docs should make a point of explaining the > efficiency gained by using ref. Or maybe they do, but I didn't find > anything in several minutes of poking around the docs. There is no table > of > contents entry like "Efficiency considerations" or similar. > > --Beman > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users Thanks, that did indeed remove some churn. As Mr. Dawes pointed out, it would be nice to have that info in the docs somewhere. Overall though, I'm not sure that the allocations I'm seeing are acceptable for my application. Ideally, I'd like 1 allocation on connect and 0 allocations on signal send. We will be using an optimized small block allocator, but we still want to reduce memory operations as much as possible. Is there any suggestion to reduce this? I ran my own test putting in _CrtSetAllocHook(MyAllocHook), just copied from msdn. Below are the results (cleaned up a bit for just alloc hook calls). I haven't really looked at memory pools too closely. Would they be useful in any sort of situation with signals? >From the pool docs: >Pools are generally used when there is a lot of allocation and de-allocation of small objects. Another common usage >is the situation above, where many objects may be dropped out of memory. Thanks, Frank ref test before declaration: Memory operation in (null), line 0: allocating a 1-byte 'Normal' block (# 93) Memory operation in (null), line 0: allocating a 40-byte 'Normal' block (# 95) Memory operation in (null), line 0: allocating a 1-byte 'Normal' block (# 96) Memory operation in (null), line 0: allocating a 1-byte 'Normal' block (# 97) Memory operation in (null), line 0: freeing a 0-byte 'Normal' block (# 0) at 3240f8 Memory operation in (null), line 0: allocating a 40-byte 'Normal' block (# 98) Memory operation in (null), line 0: allocating a 24-byte 'Normal' block (# 99) Memory operation in (null), line 0: freeing a 0-byte 'Normal' block (# 0) at 321688 Memory operation in (null), line 0: allocating a 24-byte 'Normal' block (# 100) after declaration: before connect: Memory operation in (null), line 0: allocating a 24-byte 'Normal' block (# 101) Memory operation in (null), line 0: allocating a 20-byte 'Normal' block (# 102) Memory operation in (null), line 0: allocating a 24-byte 'Normal' block (# 103) Memory operation in (null), line 0: allocating a 16-byte 'Normal' block (# 104) Memory operation in (null), line 0: allocating a 24-byte 'Normal' block (# 105) Memory operation in (null), line 0: allocating a 20-byte 'Normal' block (# 106) Memory operation in (null), line 0: allocating a 24-byte 'Normal' block (# 107) Memory operation in (null), line 0: allocating a 4-byte 'Normal' block (# 108) Memory operation in (null), line 0: allocating a 16-byte 'Normal' block (# 109) Memory operation in (null), line 0: allocating a 16-byte 'Normal' block (# 110) Memory operation in (null), line 0: allocating a 40-byte 'Normal' block (# 111) Memory operation in (null), line 0: allocating a 16-byte 'Normal' block (# 112) Memory operation in (null), line 0: freeing a 0-byte 'Normal' block (# 0) at 3244e0Memory operation in (null), line 0: freeing a 0-byte 'Normal' block (# 0) at 324490Memory operation in (null), line 0: freeing a 0-byte 'Normal' block (# 0) at 324340Memory operation in (null), line 0: freeing a 0-byte 'Normal' block (# 0) at 321688Memory operation in (null), line 0: freeing a 0-byte 'Normal' block (# 0) at 324290Memory operation in (null), line 0: freeing a 0-byte 'Normal' block (# 0) at 3242e8 after connect: before sig send: Memory operation in (null), line 0: allocating a 1-byte 'Normal' block (# 113) Memory operation in (null), line 0: allocating a 24-byte 'Normal' block (# 114) Memory operation in (null), line 0: freeing a 0-byte 'Normal' block (# 0) at 321688 Memory operation in (null), line 0: freeing a 0-byte 'Normal' block (# 0) at 324490 after sig send: copy test: before declaration: Memory operation in (null), line 0: allocating a 1-byte 'Normal' block (# 67) Memory operation in (null), line 0: allocating a 40-byte 'Normal' block (# 69) Memory operation in (null), line 0: allocating a 1-byte 'Normal' block (# 70) Memory operation in (null), line 0: allocating a 1-byte 'Normal' block (# 71) Memory operation in (null), line 0: freeing a 0-byte 'Normal' block (# 0) at 3240f8 Memory operation in (null), line 0: allocating a 40-byte 'Normal' block (# 72) Memory operation in (null), line 0: allocating a 24-byte 'Normal' block (# 73) Memory operation in (null), line 0: freeing a 0-byte 'Normal' block (# 0) at 321688 Memory operation in (null), line 0: allocating a 24-byte 'Normal' block (# 74) after declaration: before connect: Memory operation in (null), line 0: allocating a 1-byte 'Normal' block (# 75) Memory operation in (null), line 0: allocating a 24-byte 'Normal' block (# 76) Memory operation in (null), line 0: allocating a 20-byte 'Normal' block (# 77) Memory operation in (null), line 0: allocating a 24-byte 'Normal' block (# 78) Memory operation in (null), line 0: allocating a 16-byte 'Normal' block (# 79) Memory operation in (null), line 0: allocating a 1-byte 'Normal' block (# 80) Memory operation in (null), line 0: allocating a 24-byte 'Normal' block (# 81) Memory operation in (null), line 0: allocating a 20-byte 'Normal' block (# 82) Memory operation in (null), line 0: allocating a 24-byte 'Normal' block (# 83) Memory operation in (null), line 0: allocating a 4-byte 'Normal' block (# 84) Memory operation in (null), line 0: allocating a 16-byte 'Normal' block (# 85) Memory operation in (null), line 0: allocating a 1-byte 'Normal' block (# 86) Memory operation in (null), line 0: allocating a 16-byte 'Normal' block (# 87) Memory operation in (null), line 0: allocating a 1-byte 'Normal' block (# 88) Memory operation in (null), line 0: allocating a 40-byte 'Normal' block (# 89) Memory operation in (null), line 0: allocating a 16-byte 'Normal' block (# 90) Memory operation in (null), line 0: allocating a 1-byte 'Normal' block (# 91) Memory operation in (null), line 0: freeing a 0-byte 'Normal' block (# 0) at 3245f0 Memory operation in (null), line 0: freeing a 0-byte 'Normal' block (# 0) at 3245a0 Memory operation in (null), line 0: freeing a 0-byte 'Normal' block (# 0) at 324560 Memory operation in (null), line 0: freeing a 0-byte 'Normal' block (# 0) at 324510 Memory operation in (null), line 0: freeing a 0-byte 'Normal' block (# 0) at 32439 0Memory operation in (null), line 0: freeing a 0-byte 'Normal' block (# 0) at 324340 Memory operation in (null), line 0: freeing a 0-byte 'Normal' block (# 0) at 3240f8 Memory operation in (null), line 0: freeing a 0-byte 'Normal' block (# 0) at 321688 Memory operation in (null), line 0: freeing a 0-byte 'Normal' block (# 0) at 324290 Memory operation in (null), line 0: freeing a 0-byte 'Normal' block (# 0) at 3242e8 after connect: before sig send: Memory operation in (null), line 0: allocating a 1-byte 'Normal' block (# 92) Memory operation in (null), line 0: allocating a 24-byte 'Normal' block (# 93) Memory operation in (null), line 0: freeing a 0-byte 'Normal' block (# 0) Memory operation in (null), line 0: freeing a 0-byte 'Normal' block (# 0) at 324510 after sig send:

1 0

boost::not1(boost::bind(...))
by Agoston Bejo 17 Dec '04

17 Dec '04

This does not seem to work, because the object bind returns does not have an argument_type typedef. Why is that so? Is there a workaround? Thx, Agoston

2 5

RE: [Boost-users] bind and default function parameters
by Mihalicza, Jozsef 17 Dec '04

17 Dec '04

Hello, Attached you can find a modified version of your code snipplet that works. In fact you needn't specify <bool>, but you have to pass as many arguments as the function actually takes, three in this case. Even if you specify a default value for threshold, the compiler treats equ as a function taking three parameters. HTH Best regards, Jocó P.S. to Agoston Bejo: Kicsi a világ :) -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Agoston Bejo Sent: Friday, December 17, 2004 1:01 AM To: boost-users(a)lists.boost.org Subject: [Boost-users] bind and default function parameters Hi! A small example: -------------------------------- template<typename T1, typename T2> bool equ(T1 t1, T2 t2, double threshold) { return t1 == t2; } int _tmain(int argc, _TCHAR* argv[]) { int ia1[] = {1,2,3,4,5}; cout << *find_if(ia1, ia1+5, bind<bool>(equ<int, int>, _1, 5)) << endl; // ERROR return 0; } ----------------------------------- Compiler: VC++7.1 (Intermezzo: another question: why do I have to specify the result type for bind in this case (bool)? Why can't it deduce it from the template function declaration: the return type is non-dependent.) Error message: c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\boost\bind.hpp(246) : error C2198: 'bool (__cdecl *)(int,int,double)' : too few arguments for call through pointer-to-function ... and the rest (I suppose they are mainly irrelevant) c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\boost\bind\bind_template.hpp(33) : see reference to function template instantiation 'R boost::_bi::list2<A1,A2>::operator ()<boost::_bi::bind_t<R,F,L>::result_type,bool(__cdecl *)(T1,T2,double),boost::_bi::list1<int &>>(boost::_bi::type<T>,F,A &)' being compiled with [ R=boost::_bi::bind_t<bool,bool (__cdecl *)(int,int,double),boost::_bi::list2<boost::_bi::list_av_2<boost::arg<1>,int >::B1,boost::_bi::list_av_2<boost::arg<1>,int>::B2>>::result_type, A1=boost::_bi::list_av_2<boost::arg<1>,int>::B1, A2=boost::_bi::list_av_2<boost::arg<1>,int>::B2, F=bool (__cdecl *)(int,int,double), L=boost::_bi::list2<boost::_bi::list_av_2<boost::arg<1>,int>::B1,boost::_bi: :list_av_2<boost::arg<1>,int>::B2>, T1=int, T2=int, T=boost::_bi::bind_t<bool,bool (__cdecl *)(int,int,double),boost::_bi::list2<boost::_bi::list_av_2<boost::arg<1>,int >::B1,boost::_bi::list_av_2<boost::arg<1>,int>::B2>>::result_type, A=boost::_bi::list1<int &> ] c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\algorithm(64) : see reference to function template instantiation 'boost::_bi::bind_t<R,F,L>::result_type boost::_bi::bind_t<R,F,L>::operator ()<int>(A1 &)' being compiled with [ R=bool, F=bool (__cdecl *)(int,int,double), L=boost::_bi::list2<boost::_bi::list_av_2<boost::arg<1>,int>::B1,boost::_bi: :list_av_2<boost::arg<1>,int>::B2>, A1=int ] d:\prog\vcpp\Boost\xBindAndDefFuncArg\xBindAndDefFuncArg.cpp(22) : see reference to function template instantiation '_InIt std::find_if<int*,boost::_bi::bind_t<R,F,L>>(_InIt,_InIt,_Pr)' being compiled with _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 1

Disable Unused Argments
by Duane Murphy 17 Dec '04

17 Dec '04

When using the range libraries size() function, I get an unused argument warning. While I could turn off these warnings explicitly for the project, I would rather not (in order to prevent other potential mistakes). Does boost have a more generalized or compiler specialized mechanism for disabling unused arguments in a function? To complicate matters more, this is a template function so the unused arguments pragma that I would use (with CodeWarrior 8.3) doesn't work. Suggestions welcomed. Thanks, ...Duane

1 0

Re: newbie build question
by Frank Brown 17 Dec '04

17 Dec '04

> > It's not the correct location. This: > > C:\Boost\include\boost-1_32\boost > > Should be: > > C:\Boost\include\boost-1_32 yes - that fixed it. many thanks! now i can move on to making coding errors! -frank

1 0

bind and default function parameters
by Agoston Bejo 17 Dec '04

17 Dec '04

Hi! A small example: -------------------------------- template<typename T1, typename T2> bool equ(T1 t1, T2 t2, double threshold) { return t1 == t2; } int _tmain(int argc, _TCHAR* argv[]) { int ia1[] = {1,2,3,4,5}; cout << *find_if(ia1, ia1+5, bind<bool>(equ<int, int>, _1, 5)) << endl; // ERROR return 0; } ----------------------------------- Compiler: VC++7.1 (Intermezzo: another question: why do I have to specify the result type for bind in this case (bool)? Why can't it deduce it from the template function declaration: the return type is non-dependent.) Error message: c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\boost\bind.hpp(246) : error C2198: 'bool (__cdecl *)(int,int,double)' : too few arguments for call through pointer-to-function ... and the rest (I suppose they are mainly irrelevant) c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\boost\bind\bind_template.hpp(33) : see reference to function template instantiation 'R boost::_bi::list2<A1,A2>::operator ()<boost::_bi::bind_t<R,F,L>::result_type,bool(__cdecl *)(T1,T2,double),boost::_bi::list1<int &>>(boost::_bi::type<T>,F,A &)' being compiled with [ R=boost::_bi::bind_t<bool,bool (__cdecl *)(int,int,double),boost::_bi::list2<boost::_bi::list_av_2<boost::arg<1>,int >::B1,boost::_bi::list_av_2<boost::arg<1>,int>::B2>>::result_type, A1=boost::_bi::list_av_2<boost::arg<1>,int>::B1, A2=boost::_bi::list_av_2<boost::arg<1>,int>::B2, F=bool (__cdecl *)(int,int,double), L=boost::_bi::list2<boost::_bi::list_av_2<boost::arg<1>,int>::B1,boost::_bi: :list_av_2<boost::arg<1>,int>::B2>, T1=int, T2=int, T=boost::_bi::bind_t<bool,bool (__cdecl *)(int,int,double),boost::_bi::list2<boost::_bi::list_av_2<boost::arg<1>,int >::B1,boost::_bi::list_av_2<boost::arg<1>,int>::B2>>::result_type, A=boost::_bi::list1<int &> ] c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\algorithm(64) : see reference to function template instantiation 'boost::_bi::bind_t<R,F,L>::result_type boost::_bi::bind_t<R,F,L>::operator ()<int>(A1 &)' being compiled with [ R=bool, F=bool (__cdecl *)(int,int,double), L=boost::_bi::list2<boost::_bi::list_av_2<boost::arg<1>,int>::B1,boost::_bi: :list_av_2<boost::arg<1>,int>::B2>, A1=int ] d:\prog\vcpp\Boost\xBindAndDefFuncArg\xBindAndDefFuncArg.cpp(22) : see reference to function template instantiation '_InIt std::find_if<int*,boost::_bi::bind_t<R,F,L>>(_InIt,_InIt,_Pr)' being compiled with

2 1

Re: newbie build question
by Frank Brown 17 Dec '04

17 Dec '04

D:\c\whereis>cl testBoost.cpp Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86 Copyright (C) Microsoft Corporation 1984-2002. All rights reserved. testBoost.cpp testBoost.cpp(5) : fatal error C1083: Cannot open include file: 'boost/regex.hpp': No such file or directory D:\c\whereis>set include INCLUDE=E:\Program Files\Microsoft Visual Studio .NET 2003\VC7\ATLMFC\INCLUDE;E:\Program Files\Microsoft Visual Studio .NET 2003\VC7\INCLUDE;E:\Program Files\Microsoft Visual Studio .NET 2003\VC7\PlatformSDK\include\prerelease;E:\Program Files\Microsoft Visual Studio .NET 2003\VC7\PlatformSDK\include;E:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\include;C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\include\;C:\Program Files\Microsoft Visual Studio .NET\FrameworkSDK\include\;C:\Boost\include\boost-1_32\boost D:\c\whereis>dir C:\Boost\include\boost-1_32\boost\regex.hpp Volume in drive C is SYSXP Volume Serial Number is 6B12-D3A9 Directory of C:\Boost\include\boost-1_32\boost 10/04/2003 06:28 941 regex.hpp 1 File(s) 941 bytes 0 Dir(s) 472,326,144 bytes free D:\c\whereis>set BOOST_ROOT BOOST_ROOT=C:\Boost\include\boost-1_32 AFAICT the above shows the cl compiler can't find boost/regex.hpp, however the include path lists the correct location, regex.hpp shows up in a directory listing, and BOOST_ROOT is correctly set. What's going on? Something stupid perhaps. -frank brown http://www.inwa.net/~frog

2 1

using boost with .NET CLR
by Kevin Kuo 17 Dec '04

17 Dec '04

Hi all, I'm not very familar with microsoft .net technologies, but I would like to know if anyone has been able to use boost inside a managed c++ application? Are there some performance hits, pitfalls, or is it in general a bad idea? Thanks. Kevin

3 2

boost and memory allocations (signals and others)
by Frank Maddin 16 Dec '04

16 Dec '04

We've been thinking about using certain boost functionality on a project. We were trying to keep the number of allocations down. An engineer did some testing on signals and their usage of memory and found that there was a surprising number of allocation related things were happening. Even sending a signal did allocation ops. If developers want to reduce allocation overhead, do they use memory pools or some other solution? Is there a pattern of large numbers of small allocations across the lib? For things like the boost's smart pointers also? Below is a description of the test. Thanks, -fm ------------ Memory Usage I ran a simple test to see how much memory is being used struct Hello { void operator (int year) { printf("Year = %d\n",year); } }; void Test () { Hello hello; boost::signal< void(int) > sig; sig.connect( hello ); sig( 1968 ); } Note: I used _CrtSetAllocHook to monitor the memory usage... Results: sizeof( sig ) = 24 bytes but the default constructor does a surprising amount of dynamic allocation (for an empty list) calls malloc or free 51 times allocates 277 bytes in 13 blocks (not including heap overhead) so the actual size is more like 24 + 277 + 13*8 = 405 byes a call to connect does 26 alloc-operations... resulting in 133 bytes in 8 blocks a call to send a signal does 78 alloc-operations... resulting in 0 bytes in 0 blocks ... My tests were debug builds... but I looked at the calls and the library just calls new a lot... there seems to be a pattern of having empty wrapper classes where the constructor dynamically allocates the actual implementation...

3 2

Tuple access on Solaris
by darren.gilbert＠ubs.com 16 Dec '04

16 Dec '04

Hello, I was using the boost tuples library (from boost 1.31) to create a cache key. However, the Solaris compiler (SUNWspro v6.2.p1) complained when I tried to access the last element in the tuple. My class looked something like this: typedef enum result_type_id { ... } ResultTypeID; class ParamStateKey; class Cache { typedef boost::tuple<ParamStateKey, ResultTypeID, int, int, int> key_type; // cache implementation ... // some helper functions defined to hide the boost::tuple interface static ParamStateKey &GetState(key_type &k) { return boost::tuples::get<0>(k); } static ResultTypeID &GetGreek(key_type &k) { return boost::tuples::get<1>(k); } static int &GetProduct(key_type &k) { return boost::tuples::get<2>(k); } static int &GetSubpage(key_type &k) { return boost::tuples::get<3>(k); } static int &GetBucket(key_type &k) { return boost::tuples::get<4>(k); } static key_type MakeKey(const ParamStateKey &psk, ResultTypeID r, int p1, int p2, int bkt) { return boost::tuples::make_tuple(psk, r, p1, p2, bkt); } }; The solaris compiler complained whenever I tried to call Cache::GetBucket() with the following error: "../../../../incl/3rd/boost/tuple/detail/tuple_basic.hpp", line 105: Error: Could not find a match for boost::tuples::detail::get_class<0>::get<boost::tuples::detail::get_class<0>::RET, boost::tuples::detail::get_class<0>::HT, boost::tuples::detail::get_class<0>::TT>(boost::tuples::cons<int, boost::tuples::null_type>). "../../../../incl/3rd/boost/tuple/detail/tuple_basic.hpp", line 105: Where: While instantiating "static boost::tuples::detail::get_class<1>::get<int&, int, boost::tuples::cons<int, boost::tuples::null_type>>(boost::tuples::cons<int, boost::tuples::cons<int, boost::tuples::null_type>>&)". "../../../../incl/3rd/boost/tuple/detail/tuple_basic.hpp", line 105: Where: Instantiated from non-template code. Firstly, I have no way of deciphering that error message. Through trial and error, I found that removing the GetBucket() calls solved the problem. However, I needed these calls. I reasoned that since the other helper functions worked, it was a problem accessing the last element of the tuple. So I created a dummy entry in the tuple and redefined my typedef: typedef boost::tuple<ParamStateKey, ResultTypeID, int, int, int, int> key_type; This work-around is fine, so this is not an urgent problem. But it seems like this should not be necessary. ________________________________________ Darren Gilbert Associate Director UBS - Equities Quantitative Strategies Phone: +1 (312) 525-5766 Stein's law: "When a trend cannot continue it will stop." -- Herb Stein, Chairman of the Council of Economic Advisors under Nixon Visit our website at http://www.ubs.com 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. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.

1 0

a simple question from a green hand
by Gump Xu 16 Dec '04

16 Dec '04

Hi, there. I am a new user of Boost lib. I have a simple question about installation. I've download and unpacked boost-1.32.0 to my Linux box. When I followed the instruction in "Get Started" to install Boost, I found there was no such a "bjam" binary file in my ~/boost_1_32_0 directory. Can anybody help me out? Thank you.

3 2

scoped_ptr has no release function
by gast128 16 Dec '04

16 Dec '04

Dear all, Probably there will be a good rationale for this, but the scoped_ptr has no release fct. No we have to use the auto_ptr, with all its drawbacks. Does anyone know the reason for this? Wkr, me

5 5

BGL + VC7: no bundled properties because of BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
by Dan Dimerman 16 Dec '04

16 Dec '04

Hello, Failing to do it by myself, I ask for the group's help to fully understand why I can't use BGL's bundled properties with MS VC7. I traced the impediment to the fact that in the configuration header "visualc.hpp" the constant BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION is #defined. This, further on (properties.hpp), causes the BOOST_GRAPH_NO_BUNDLED_PROPERTIES to be #defined. My question is, what is in this context understood by "template partial specialization" ? I ask, because I'm almost sure I've used this feature in VC7 before, hence my confusion. Many thanks in advance... Dan

2 1

[BGL] Obtaining corresponding vertex_descriptors
by J Swan 16 Dec '04

16 Dec '04

Suppose we have two BGL graphs g1 and g2, of type Graph1 and Graph2 respectively, such that g2 is a copy of g1. Given a vertex_descriptor v1 belonging to g1, can one generically obtain the corresponding vertex descriptor for g2: a) if Graph1 and Graph2 are actually the same type b) if Graph1 and Graph2 are different types? Regards, Jerry.

2 1

How to make an iterator with a stride... and more
by Eli Pulsifer 16 Dec '04

16 Dec '04

Hello, I have a situation which is probably quite common and already addressed by boost. So rather than write it my self, maybe someone can point me to the answer. I've got a geometry class that needs to expose iterators for the underling vertex components. Example: Class Vertex { positions_iterator PositionsBegin(); positions_iterator PositionsEnd(); normals_iterator NormalsBegin(); normals _iterator NormalsEnd(); ... } The first problem is depending on the format of the underling vertices, the stride between the data elements will change. Is there some easy way to implement this? I think writing my own using the boost::iterator_adapter is probably the way to go. Second problem is more involved. The texture data not only has a stride but a variable number of elements. Some vertices have 2 texture coordinates, some 3, some even more. Id love to define this iterator like this: stride_iterator< pair<float_iterator, float_iterator> > tex_coord_iterator; then create the iterator: stride_tupel_iterator< pair<float_iterator, float_iterator> >( pFirstTexCoord, texCoordStride, texCoordCount ); then use it: stride_tupel_iterator< pair<float_iterator, float_iterator> > it; for( it = vertex.PositionBegin() ; it != vertex.PositionEnd() ; ++it) { pair<float_iterator, float_iterator> coords; float_iterator iCoord; for(iCoord = coords.first ; iCoord != coords.last ; ++iCoord) { } } This will probably also require me to create my own highly special iterator class or is there a better way.

4 3

newbie build question
by Frank Brown 16 Dec '04

16 Dec '04

sorry if this has been asked before, it's very elementary but i can't find references in the archives or faq so here goes: i just installed boost libraries and built them via bjam. they seemed to build successfully. i'm using the vc7.1 compiler. when i try to compile (cl) a .cpp file containing the following include #include <boost/regex.hpp> i get the following: testBoost.cpp(8) : fatal error C1083: Cannot open include file: 'boost/regex.hpp': No such file or directory if i replace the include with the actual file spec like this: #include "C:\Boost\include\boost-1_32\boost\regex.hpp" i get the following compiler error: testboost.cpp C:\Boost\include\boost-1_32\boost\regex.hpp(28) : fatal error C1083: Cannot open include file: 'boost/regex/config.hpp': No such file or directory apparently the compiler (cl) isn't translating <boost>. since one boost header refers to others i need to fix this basic problem. i tried substituting the bjam.exe in place of cl to compile, then i get a different error: Unable to load Boost.Build: could not find "boost-build.jam" --------------------------------------------------------------- Attempted search from D:\c\whereis up to the root so i'm sorry to bother y'all with such a simple problem, all i need to know is how to compile (the 'hello world' scenario). thanks for your attention. -frank brown (stupid jerk) http://www.inwa.net/~frog

2 1

[BGL][variant] variant as internal edge property - nastiness w/MS7.1 + 1.31.0
by Christopher D. Russell 15 Dec '04

15 Dec '04

This isn't a question but rather a quick report for my future reference - I need to circle back and try to characterize this problem more fully when I'm not on deadline and can run some additional tests with Boost 1.32.0. Environment: - MS 7.1 compiler w/their STL distribution - Boost 1.31.0 (my client doesn't want to update to 1.32.0 until after this release) Summary: boost::variant registered as an internal edge property map member on a BGL graph causes the resultant graph to be inaccessible due to what appears to be incorrect initialization of both the internal vertex and edge property maps. I SUSPECT THAT THE ROOT CAUSE OF THIS CAN BE TRACKED BACK TO A MS 7.1 COMPILER BUG due to the fact that attempts to compile my test code results in either of (a) an C1001 Internal Compiler Error (b) a error-free compile and a completely screwed runtime. Details: The boost::variant in question is bounded by several unique specializations of a fully-specialized class. As follows: // pseudocode class A; class B; class C; template <typename tail_T, typename head_T> class edge_exeuctor {}; template <> class edge_executor<A, B>; template <> class edge_exeuctor<A,C>; tempalte <> class edge_exeuctor<B,C>; template <> class edge_executor<B,A>; tempalte <> class edge_executor<C,A>; template <> class edge_executor<C,B>; typedef boost::variant< edge_executor<A,B>, edge_executor<A,C>, edge_executor<B,C>, edge_executor<B,A>, edge_executor<C,A>, edge_executor<C,B> > variant_edge_t; The graph in question is declared as: enum vertex_foo_property_t { vertex_foo_property = 801 }; enum edge_foo_property_t {edge_foo_property = 802 }; BOOST_INSTALL_PROPERTY(vertex, foo_property); BOOST_INSTALL_PROPERTY(edge, foo_property); typedef property<vertex_foo_property, int, boost::property<vertex_color_t, default_color_type> > vertex_properties_t; typedef property<edge_foo_property, variant_edge_t> edge_properties_t; typedef adjacency_list<listS, listS, bidirectionalS, vertex_properties_t, edge_properties_t> graph_t; typedef graph_traits<graph_t>::edges_size_type edges_size_t; Failure: // THE TEST CODE WILL NOT ALWAYS COMPILE W/MS 7.1 // HALF THE TIME IT BOMBS W/C1001 INTERNAL COMPILER ERROR // when it does compile, no errors are reported by the following runtime behavior is observed graph_t g; edges_size_t edge_count = num_edges(g); // <- protection fault // stepping into num_edges in a debug build reveals that both vertex and edge property maps point to uninitialized memory (0xcdcdcdcd) // removing variant_edge_t from edge_properties_t and replacing with an int works as expected... ---- - Chris

2 2