April 2005 - Boost-users - lists.boost.org

Re: You provide gun, I provide foot.
by C. Michailidis 10 Apr '05

10 Apr '05

> do have models. What prevents you from using say, the > boost::mutex::scoped_lock model? (Which has the lock/unlock calls.) Perhaps my initial mailing was too general. I'll try to state my problem more specifically. The following url, http://www.boost.org/libs/thread/example/mutex.cpp , gives an example of how mutexes and scoped_locks are typically used. The counter class shows how an atomic counter is implemented. For completeness I'll copy and paste part of the example into my email, here's the class: class counter { public: counter() : count(0) { } int increment() { boost::mutex::scoped_lock scoped_lock(mutex); return ++count; } private: boost::mutex mutex; int count; }; As I understand it, a thread calling the 'increment' method will be blocked until any other thread that has already called 'increment' has returned from the method call (more or less). When the scoped_lock object is instantiated its constructor locks the mutex until the scoped_lock goes out of scope (at which time the destructor of scoped_lock unlocks the mutex enabling other threads to reach the body of increment). This is all fine and dandy. My problem is that I have an existing COM component which is more similar to: // please excuse the MSFT parlance class counter { public: counter() : count(0) { mutex=CreateMutex(NULL, false, NULL); } void lock() { WaitForSingleObject(mutex, INFINITE); } int increment() { return ++count; } void unlock { ReleaseMutex(mutex); } ~counter() { CloseHandle(mutex); } private: unsigned long mutex; int count; }; When using the COM component the caller is required to call 'lock' before calling any other methods (in this case 'increment'), when you are finished using the component you must call 'unlock'. So... here's my problem, how can I use Boost.Threads to create the same kind of functionality without changing my COM interfaces? Remember that this is just for illustration so my sample code may need changes before compiling ;-) In any case, the actual component is more sophisticated than the simple example I gave, and could actually be called from a language other than C++ (e.g. Visual Basic). AFAIK boost mutexes must be locked using scoped_locks and it would seem that they aren't appropriate for my situation. I can certainly appreciate the benefits of scoped_locks (esp. in a homogeneous environment where all code is written in C++). It just seems silly to force the user to use ONLY scoped_locks when in some situations the additional requirements they have make them unusable. Sure, most of the time the mutex should be unlocked at the end of the block... however when the critical section is composed of code written in more than one language or in a more dynamic algorithm it may easier to unlock it elsewhere, no? Perhaps this is an issue more appropriate for the boost-devel list... but, if there really isn't a way to simply lock/unlock a mutex I think it is awefully rude and arrogant of the developers considering the fact that more straight-forward multi-threaded IPC mechanisms have been around for quite some time and programmers have been able to use them effectively without much trouble. It's my opinion that a great toolkit not only provides robust and sophisticated facilities but *ALSO* gives the developer enough 'rope to hang themselves'. After all, isn't the freedom to shoot yourself in the foot one of the major advantages of writing code in C/C++? I use the Boost library not only to add functionality to my software but to act as a common API in cross-platform environments. Nearly every modern API supports some kind of fundamental lock/unlock mechanism for mutexes, why shouldn't boost? And yes, to answer one of the replys... I am not being forced to use boost, in this case it seems as though I can't! It would be nice however, since I'm using other Boost modules in the project. In summary, since "Lock concepts are the only way to lock and unlock a mutex object: lock and unlock functions are not exposed by any Boost.Threads mutex objects", it seems as though I'm left out in the cold! Any suggestions? Any boost developers reading this? Anyone feel my pain? Am I just being blindly stubborn? LOL, Dino

3 3

Heterogenous properties
by Martin Jynge 10 Apr '05

10 Apr '05

Hi. I'm trying to develop a (bidirectional) graph whose edges contain a property Value, which is a baseclass with different inherited classes dependent upon the type of vertex they are connected to. I attach a pointer to a base class Node to each vertex - the node containing only a virtual method called from a designated parsing algorithm. This method needs to access the Value leafclasses of the vertex's outedges. For example, a particular vertex receives a double from one outedge and a struct xy {double x,y; } from another, does some operation and stores, say, a complex number in a relevant inedge. In essense it's kind of like genetic programming with multiple parents and multiple value types. I would really like to avoid using dynamic_cast in dispatching edge Value descendants. Any thoughts on this?

1 0

BOOST_CHECK_EQUAL compiler warning
by shopper11＠cfl.rr.com 09 Apr '05

09 Apr '05

I get a compiler warning when using BOOST_CHECK_EQUAL in conjunction with BOOST_AUTO_UNIT_TEST. The code and warning are below. Anyone know what I'm doing to cause the warning? Environment: Windows XP with MS VS 2003 #define BOOST_AUTO_TEST_MAIN #include <boost/test/auto_unit_test.hpp> class MyTest { public: MyTest( int newVal = 3 ) : a (newVal) {} int GetA() {return(a);} protected: int a; }; MyTest test1; // _____________________________________ BOOST_AUTO_UNIT_TEST( TestCase1 ) { int b = test1.GetA(); BOOST_CHECK_EQUAL( b, 1 ); } The warning is: c:\Boost\include\boost-1_32\boost\test\detail\wrap_stringstream.hpp(69) : warning C4267: 'argument' : conversion from 'size_t' to 'unsigned int', possible loss of data c:\Boost\include\boost-1_32\boost\test\test_tools.hpp(435) : see reference to function template instantiation 'boost::basic_wrap_stringstream<CharT> &boost::operator <<<char,size_t>(boost::basic_wrap_stringstream<CharT> &,const T &)' being compiled with [ CharT=char, T=size_t ] m:\jclaybau_InWork_view\CHAMELEON\SoftwareDevelopmentFolder\Source\AM\Test\AMTest\AMTest.cpp(20) : see reference to function template instantiation 'bool boost::test_tools::tt_detail::equal_and_continue_impl<int,int>(const Left &,const Right &,boost::wrap_stringstream &,boost::test_tools::const_string,size_t,boost::unit_test::log_level,size_t)' being compiled with [ Left=int, Right=int ]

2 1

Followup to KCC compile error
by Stephen Gross 09 Apr '05

09 Apr '05

To review: > When including "boost/iterator/indirect_iterator.hpp", I get: > > "/usr/local/sagedev/apis/include/boost_1_32_0/boost/detail/is_incrementable.hpp", > line 56: error: > > expression must have arithmetic, enum, or pointer type > > BOOST_STATIC_CONSTANT( > ^ Some new thoughts upon investigation: It is not in the BOOST_STATIC_CAST. Doing manual compiler preprocessing has resulted in the following code, which is what the compiler is complaining about: template <class T> struct impl { static typename remove_cv<T>::type& x; static const bool value = sizeof(is_incrementable_::check(++x,0)) == 1; }; The problem is the ++x, not the static cast. The problem seems to be a question of that x variable. If I replace the typename of x with, say int&, it works with one additional modification (see below), and if I replace it with a non-incrementable object, say 'foo', that also works. My theory was it might be in the remove_cv, but replacing the type with T& does not work. We still get the 'must be of XXX' type message despite T being known to be a type. So, it would seem to be something about the templates. I'm stuck at this point. What I had to do to make known types work: With known types (int, foo), the compile only works when I add an additional set of parentheses around the ++x,0 in the check. I assume this is an order of evaluations thing, to make certain the comma operator is processed before the check function, which since all versions of check are single argument, I assume is the intent here. --Steve (sgross(a)darwin.cwru.edu)

2 1

potential bugs in BGL function "brandes_betweenness_centrality()"
by Qiaofeng Yang 09 Apr '05

09 Apr '05

Hi, I use g++ (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5). What I did is as follows: ===================================================================== 1. Use "brandes_betweenness_centrality()" to calculate the vertex betweenness centrality for all the vertices in the graph. 2. Find the vertex with the highest betweenness value. 3. Delete the vertex from the graph. 4. Repeat step 1 until no vertex left in the graph. ===================================================================== The code is sketched as follows: ======================================================================== typedef property<vertex_name_t, string> VertexName; typedef property<vertex_index_t, int, VertexName> VertexProperty; typedef property<edge_index_t, int> EdgeProperty; typedef adjacency_list<listS, listS, undirectedS, VertexProperty, EdgeProperty> Graph; Graph G; //load graph ... while(num_vertices(G)>0) { int V = num_vertices(G); vector<double> vertex_centrality(V); brandes_betweenness_centrality(G, make_iterator_property_map(vertex_centrality.begin(), get(vertex_index, G), double())); //print the vertex betweenness centrality for all the vertices ... //find the index of the vertex with the highest betweenness centrality ... clear_vertex(...); remove_vertex(...); } ======================================================================== The above code is run on a graph with 8 vertices and 9 edges. Below is the edge list representation of my graph: node0 node4 node0 node1 node0 node2 node0 node3 node1 node2 node2 node3 node4 node5 node4 node6 node4 node7 The problem is as follows: 1. Extremely slow. The first iteration is fast, but you have to wait for a long time before the results of the second iteration to print out. 2. After several iterations, the vertex name printed out is wrong. (In my graph, at the third iteration, the vertex name is printed out wrong) 3. When there are two vertices and no edges in the graph, the program stops printing out anything, basically freezes there. >From my previous experience with BGL, the subgraph function has similar problem. When I create a subgraph from a graph, everything is inherited correctly, including vertex names, edges, etc. When I try to create a subgraph from the subgraph from the previous step, I get segmentation fault when trying to print out vertex names. I think there may be some bugs in the source files dealing with the graph structure modification. Best regards, Qiaofeng

2 1

a question about the vertices in boost graph libary (BGL)
by Vivid Yang 08 Apr '05

08 Apr '05

Hi, I saw all the BGL examples begin with enumeration: // Make convenient labels for the vertices enum { Amherst, Boston, City, Denver, Egypt, Niagara }; So it is convenient to access properties, for example: distance(Boston) = 50; //distance is a property of vertices The problem is that I have to build my graph incrementally and might have to remove some vertices later. So enumeration does not work for me. When I want to set distance(Boston) = 50, I have to find the descriptor for "Boston" first, (It takes O(n) to traverse all the vertices). It is too expensive for a large graph. Is there anyway I can skip this step? I am thinking add a hash table, which maps each city to a descriptor. I have to update the hash table whenever I remove vertices. It is inconvenient neither. Do I think it in the right way? Any suggestions? Thanks a lot. Vivid

2 2

I can't link Boost Thread library
by Ivan Makale 08 Apr '05

08 Apr '05

I tried to use the Boost Thread library with Windows and VC++ 7.1 (.NET IDE) and STLPort-4.6.2 but I didn't succeed. I tried with: - boost jam - generating a DLL from a new project directly in the IDE (dynamic linking) - including the sources in the exe project (static linking) The static linking gives me an error with "tss_cleanup_implemented", which is not accidental but wanted by the developers ("This function's sole purpose is to cause a link error..."), while the dinamyc linking gives me another error: "TestPalantirWrapper error LNK2019: unresolved external symbol "public: __thiscall boost::thread::thread(class boost::function0<void,class _STL::allocator<class boost::function_base> > const &)" (??0thread@boost@@QAE@ABV?$function0@XV?$allocator@Vfunction_base@boost@@@_STL@@@1@@Z) referenced in function _main" (it was th thread.cpp example). A strange thing happens with dynamic linking: using "BOOST_LIB_DIAGNOSTIC", I get the message "Linking to lib file: libboost_thread-vc71-mt-sgdp-1_32.lib" , beginning with "lib", and not the dynamic one (without "lib"). In particular, generating a DLL from the IDE from the the source files: (1) requires the library libboost_thread-vc71-mt-sgdp-1_32.lib (why?) (2) doesn't generate an import library (".lib") but only the .dll Thank you, Ivan Makale __________________________________________________________________ Tiscali Adsl 3 Mega Flat con 3 MESI GRATIS! Con Tiscali Adsl 3 Mega Flat navighi con la Supervelocita' a soli 29.95 euro al mese, senza limiti di tempo. E se attivi entro il 15 Aprile, 3 MESI sono GRATIS! Scopri come risparmiare navigando veloce, su http://abbonati.tiscali.it/adsl/sa/2flat_tc/

2 1

You provide gun, I provide foot.
by C. Michailidis 08 Apr '05

08 Apr '05

Quoting from http://www.boost.org/doc/html/threads/concepts.html#threads.concepts.mutexes "Many C++ threading libraries use a pattern known as Scoped Locking[SchmidtStalRohnertBuschmann] to free the programmer from the need to explicitly lock and unlock mutex objects. With this pattern, a Lock concept is employed where the lock object's constructor locks the associated mutex object and the destructor automatically does the unlocking. The Boost.Threads library takes this pattern to the extreme in that Lock concepts are the only way to lock and unlock a mutex object: lock and unlock functions are not exposed by any Boost.Threads mutex objects. This helps to ensure safe usage patterns, especially when code throws exceptions." Unfortunately, I actually WANT to shoot myself in the foot this time and Boost.Threads won't let me!!! I can understand ENCOURAGING users to write safe code, but forcing them to is outright fascist! My problem is that I have existing code which I would like to make more portable by using Boost.Threads. Now, this wouldn't be a problem except for the fact that I'm (effectively) dealing w/ a COM object that already has its interface defined. There must be millions of lines of code which won't be able to get a minor face-lift because "lock and unlock functions are not exposed". Since when is ensuring safe usage more important than providing common functionality? Ugh, Dino

6 10

random_demo.cpp doesn't work with VC++6.0?
by Vivid Yang 08 Apr '05

08 Apr '05

Hi, I failed to compile random_demo.cpp (www.boost.org/libs/random/random_demo.cpp) with VC++6.0 under WINXP sp2. I have attached the error message below. (I have installed VC++6.0 service pack 4,5 and 6.) Could anybody help? Examples of using boost::random will help too, such as uniform_01 and normal_distribution, etc. Thanks a lot. Vivid (test2.cpp is random_demo.cpp) e:\shared\boost_1_32_0\boost\random\detail\ptr_helper.hpp(29) : error C2529: '<Unknown>' : reference to reference is illegal e:\shared\boost_1_32_0\boost\random\detail\pass_through_engine.hpp(32) : see reference to class template instantiation 'boost::random::detail::ptr_helper<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &>' being c ompiled e:\shared\boost_1_32_0\boost\random\variate_generator.hpp(90) : see reference to class template instantiation 'boost::random::detail::pass_through_engine<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &>' being c ompiled E:\temp\test2\test2.cpp(71) : see reference to class template instantiation 'boost::variate_generator<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &,class boost::uniform_real<double> >' being compiled e:\shared\boost_1_32_0\boost\random\detail\ptr_helper.hpp(30) : warning C4181: qualifier applied to reference type ignored e:\shared\boost_1_32_0\boost\random\detail\pass_through_engine.hpp(32) : see reference to class template instantiation 'boost::random::detail::ptr_helper<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &>' being c ompiled e:\shared\boost_1_32_0\boost\random\variate_generator.hpp(90) : see reference to class template instantiation 'boost::random::detail::pass_through_engine<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &>' being c ompiled E:\temp\test2\test2.cpp(71) : see reference to class template instantiation 'boost::variate_generator<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &,class boost::uniform_real<double> >' being compiled e:\shared\boost_1_32_0\boost\random\detail\ptr_helper.hpp(30) : error C2529: '<Unknown>' : reference to reference is illegal e:\shared\boost_1_32_0\boost\random\detail\pass_through_engine.hpp(32) : see reference to class template instantiation 'boost::random::detail::ptr_helper<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &>' being c ompiled e:\shared\boost_1_32_0\boost\random\variate_generator.hpp(90) : see reference to class template instantiation 'boost::random::detail::pass_through_engine<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &>' being c ompiled E:\temp\test2\test2.cpp(71) : see reference to class template instantiation 'boost::variate_generator<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &,class boost::uniform_real<double> >' being compiled e:\shared\boost_1_32_0\boost\random\detail\ptr_helper.hpp(31) : error C2529: '<Unknown>' : reference to reference is illegal e:\shared\boost_1_32_0\boost\random\detail\pass_through_engine.hpp(32) : see reference to class template instantiation 'boost::random::detail::ptr_helper<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &>' being c ompiled e:\shared\boost_1_32_0\boost\random\variate_generator.hpp(90) : see reference to class template instantiation 'boost::random::detail::pass_through_engine<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &>' being c ompiled E:\temp\test2\test2.cpp(71) : see reference to class template instantiation 'boost::variate_generator<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &,class boost::uniform_real<double> >' being compiled e:\shared\boost_1_32_0\boost\random\detail\ptr_helper.hpp(32) : warning C4181: qualifier applied to reference type ignored e:\shared\boost_1_32_0\boost\random\detail\pass_through_engine.hpp(32) : see reference to class template instantiation 'boost::random::detail::ptr_helper<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &>' being c ompiled e:\shared\boost_1_32_0\boost\random\variate_generator.hpp(90) : see reference to class template instantiation 'boost::random::detail::pass_through_engine<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &>' being c ompiled E:\temp\test2\test2.cpp(71) : see reference to class template instantiation 'boost::variate_generator<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &,class boost::uniform_real<double> >' being compiled e:\shared\boost_1_32_0\boost\random\detail\ptr_helper.hpp(32) : warning C4181: qualifier applied to reference type ignored e:\shared\boost_1_32_0\boost\random\detail\pass_through_engine.hpp(32) : see reference to class template instantiation 'boost::random::detail::ptr_helper<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &>' being c ompiled e:\shared\boost_1_32_0\boost\random\variate_generator.hpp(90) : see reference to class template instantiation 'boost::random::detail::pass_through_engine<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &>' being c ompiled E:\temp\test2\test2.cpp(71) : see reference to class template instantiation 'boost::variate_generator<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &,class boost::uniform_real<double> >' being compiled e:\shared\boost_1_32_0\boost\random\detail\ptr_helper.hpp(32) : error C2529: '<Unknown>' : reference to reference is illegal e:\shared\boost_1_32_0\boost\random\detail\pass_through_engine.hpp(32) : see reference to class template instantiation 'boost::random::detail::ptr_helper<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &>' being c ompiled e:\shared\boost_1_32_0\boost\random\variate_generator.hpp(90) : see reference to class template instantiation 'boost::random::detail::pass_through_engine<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &>' being c ompiled E:\temp\test2\test2.cpp(71) : see reference to class template instantiation 'boost::variate_generator<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &,class boost::uniform_real<double> >' being compiled e:\shared\boost_1_32_0\boost\random\detail\ptr_helper.hpp(32) : error C2529: '<Unknown>' : reference to reference is illegal e:\shared\boost_1_32_0\boost\random\detail\pass_through_engine.hpp(32) : see reference to class template instantiation 'boost::random::detail::ptr_helper<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &>' being c ompiled e:\shared\boost_1_32_0\boost\random\variate_generator.hpp(90) : see reference to class template instantiation 'boost::random::detail::pass_through_engine<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &>' being c ompiled E:\temp\test2\test2.cpp(71) : see reference to class template instantiation 'boost::variate_generator<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &,class boost::uniform_real<double> >' being compiled e:\shared\boost_1_32_0\boost\random\detail\pass_through_engine.hpp(33) : error C2039: 'result_type' : is not a member of '`global namespace'' e:\shared\boost_1_32_0\boost\random\variate_generator.hpp(90) : see reference to class template instantiation 'boost::random::detail::pass_through_engine<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &>' being c ompiled E:\temp\test2\test2.cpp(71) : see reference to class template instantiation 'boost::variate_generator<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &,class boost::uniform_real<double> >' being compiled e:\shared\boost_1_32_0\boost\random\detail\pass_through_engine.hpp(33) : error C2146: syntax error : missing ';' before identifier 'result_type' e:\shared\boost_1_32_0\boost\random\variate_generator.hpp(90) : see reference to class template instantiation 'boost::random::detail::pass_through_engine<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &>' being c ompiled E:\temp\test2\test2.cpp(71) : see reference to class template instantiation 'boost::variate_generator<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &,class boost::uniform_real<double> >' being compiled e:\shared\boost_1_32_0\boost\random\detail\pass_through_engine.hpp(33) : error C2868: 'result_type' : illegal syntax for using-declaration; expected qualified-name e:\shared\boost_1_32_0\boost\random\variate_generator.hpp(90) : see reference to class template instantiation 'boost::random::detail::pass_through_engine<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &>' being c ompiled E:\temp\test2\test2.cpp(71) : see reference to class template instantiation 'boost::variate_generator<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &,class boost::uniform_real<double> >' being compiled e:\shared\boost_1_32_0\boost\random\detail\pass_through_engine.hpp(42) : error C2529: '<Unknown>' : reference to reference is illegal e:\shared\boost_1_32_0\boost\random\variate_generator.hpp(90) : see reference to class template instantiation 'boost::random::detail::pass_through_engine<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &>' being c ompiled E:\temp\test2\test2.cpp(71) : see reference to class template instantiation 'boost::variate_generator<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &,class boost::uniform_real<double> >' being compiled e:\shared\boost_1_32_0\boost\random\detail\pass_through_engine.hpp(43) : warning C4181: qualifier applied to reference type ignored e:\shared\boost_1_32_0\boost\random\variate_generator.hpp(90) : see reference to class template instantiation 'boost::random::detail::pass_through_engine<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &>' being c ompiled E:\temp\test2\test2.cpp(71) : see reference to class template instantiation 'boost::variate_generator<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &,class boost::uniform_real<double> >' being compiled e:\shared\boost_1_32_0\boost\random\detail\pass_through_engine.hpp(43) : error C2529: '<Unknown>' : reference to reference is illegal e:\shared\boost_1_32_0\boost\random\variate_generator.hpp(90) : see reference to class template instantiation 'boost::random::detail::pass_through_engine<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &>' being c ompiled E:\temp\test2\test2.cpp(71) : see reference to class template instantiation 'boost::variate_generator<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &,class boost::uniform_real<double> >' being compiled e:\shared\boost_1_32_0\boost\random\variate_generator.hpp(104) : error C2529: '<Unknown>' : reference to reference is illegal E:\temp\test2\test2.cpp(71) : see reference to class template instantiation 'boost::variate_generator<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &,class boost::uniform_real<double> >' being compiled e:\shared\boost_1_32_0\boost\random\variate_generator.hpp(105) : warning C4181: qualifier applied to reference type ignored E:\temp\test2\test2.cpp(71) : see reference to class template instantiation 'boost::variate_generator<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &,class boost::uniform_real<double> >' being compiled e:\shared\boost_1_32_0\boost\random\variate_generator.hpp(105) : error C2529: '<Unknown>' : reference to reference is illegal E:\temp\test2\test2.cpp(71) : see reference to class template instantiation 'boost::variate_generator<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &,class boost::uniform_real<double> >' being compiled e:\shared\boost_1_32_0\boost\random\variate_generator.hpp(104) : error C2529: '<Unknown>' : reference to reference is illegal E:\temp\test2\test2.cpp(116) : see reference to class template instantiation 'boost::variate_generator<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &,class boost::uniform_int<int> >' being compiled e:\shared\boost_1_32_0\boost\random\variate_generator.hpp(105) : warning C4181: qualifier applied to reference type ignored E:\temp\test2\test2.cpp(116) : see reference to class template instantiation 'boost::variate_generator<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &,class boost::uniform_int<int> >' being compiled e:\shared\boost_1_32_0\boost\random\variate_generator.hpp(105) : error C2529: '<Unknown>' : reference to reference is illegal E:\temp\test2\test2.cpp(116) : see reference to class template instantiation 'boost::variate_generator<class boost::random::linear_congruential<long,48271,0,2147483647,399268537> &,class boost::uniform_int<int> >' being compiled E:\temp\test2\test2.cpp(124) : error C2679: binary '<<' : no operator defined which takes a right-hand operand of type 'class boost::random::linear_congruential<long,48271,0,2147483647,399268537>' (or there is no acceptable conversion) Error executing cl.exe.

3 3

Installation issue
by Micha Bieber 07 Apr '05

07 Apr '05

Hi, group After some years staying away from boost, I installed the 1.32 release. The system was WinXP with VC6. I used the .exe variant. Take the following as remarks from an innocent, also if some of the issues seem to be trivial. Even though, I'm a C++ developer for more than 10 years now. I have used literally thousends of programs and libraries and I know, how quickly someone decides to skip the usage of software completely, simply because the installation becomes too strenous. The story: The exe is in fact an archive. This should be stated, because it suggests some form of installer. Starting with bjam "-sTOOLS=msvc" stage first of all I got without bigger (*) problems a bulk of single/multi-threaded/whatever_other_configured libraries. So my next wish was to reduce the diversity. I deleted the stage directory and went on.. The doc states the usage of thread flags (-mt) but I was unable to set up a command line intuitively to build only multi-threaded release versions. One (!) example line should provide a recipe to solve this problem. I guess this is possible, after looking in Boost.Build. The next point is, I need in fact only the BGL. So I tried: v:\src\boost_1_32_0>bjam "-sTOOLS=msvc" --with-graph stage --------------------------------------------------------------------- skipping Boost.Python library build due to missing or incorrect configuration couldn't find Python.h in "c:/tools/python/include" You can configure the location of your python installation by setting: PYTHON_ROOT - currently "c:/tools/python" PYTHON_VERSION - The 2-part python Major.Minor version number (e.g. "2.2", NOT "2.2.1") - currently "2.2" The following are automatically configured from PYTHON_ROOT if not otherwise set: PYTHON_LIB_PATH - path to Python library object; currently "c:/tools/python/libs" --------------------------------------------------------------------- don't know how to make stage ...found 1 target... ...can't find 1 target... v:\src\boost_1_32_0> I dont't know, if the python configuration/message is really necessary. Maybe an existing python installation can be found (I have an ActivePython here). But the the last 3 lines are completely meaningless. What shall I do with it ? A command line error ? A problem with graph's dependencies ? Something else ? msvc specific: The library as a heavily template-loaded piece of software should IMO suppress warning 4786 at least in their own implementation files. This makes it easier to spot errors during the installation run. Generally I lack information regarding dependencies for the single libraries. This should be part of the documentation (a must IMO, some accentuated doxygen graphs for the include hierarchy would be very helpful). Boost contains so many different things, and many people don't need all this stuff. It was absolutely no problem in the past, to install BGL (or its predecessor) by simply copying the header (neglecting for the moment the graphviz) interface. IMO, this should be possible further on, maybe some additional helper like iterator. But it should be documented ! Many people prefer lightwight libraries and it seems also current versions of boost _can_ be configured this way (with som acceptable manual adjusting). So a bit emphasis on these things yet in the doumentations "Getting started" section at a would be a nice thing (tm) and raise the libraries acceptance for new users. (*) ...failed updating 24 targets... ...skipped 48 targets... ...updated 1051 targets... Micha --

4 10