- Boost-users - lists.boost.org

RE: [Boost-users] configuring boost on MS Visual Studio 6 where the installation drive isn't C:
by Dernoncourt, Wayne CTR NAVAIR 3184, ,10 06 Feb '04

06 Feb '04

(I've been using MS Outlook for years and I still don't like the way it handles quoting like this!) Please pardon the newbieness, these are probably elmentary questions. It turns out the copy of Boost I have didn't have a bjam.exe (I don't know why) so I had to puzzle out how to build that (bad path, etc.) Now trying to figure out how to get Boost to build - done sort of. I don't see how this is going to examine the conflicts with the subset of RogueWave being used by the third party SDK. According to the results from the command "bjam" being executed in the D:\boost-1.30.2 directory: - failed updating 660 targets - skipped 234 targets - updated 260 targets (the actual number has scrolled off screen...) Looking back through the screens, there seem to be CALL "C:\Program Files\Microsoft\Visual Studio...", well that isn't right, it lives on D:, not C:. An earlier email suggested an S setting, so I tried: bjam "VC6_ROOT=D:\Progra~1\Micros~1" and it complains about not having Python (well, it hasn't been installed, we don't need it for this project, though it seems to be very popular) and then it complains about not knowning how to make VC6_ROOT=D:\same stuff. ...found 1 target ...can't find 1 target and it quits. -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org]On Behalf Of Administrator Sent: Wednesday, February 04, 2004 14:54 To: 'Boost Users mailing list' Subject: RE: [Boost-users] configuring boost on MS Visual Studio 6 where the installation drive isn't C: Wayne, What configure script? Boost requires bjam.exe. If you follow the directions here: http://www.boost.org/more/getting_started.html you should have no problems. I have never had a problem with either MS Visual C++ 6.0 with regards to bjam, nor have I ever used a configure script with Boost. Cygwin is an alternative, but you shouldn't need it if you follow the getting started directions. Dale -----Original Message----- From: Dernoncourt, Wayne CTR NAVAIR 3184, ,10 [mailto:wayne.dernoncourt@navy.mil] Sent: Wednesday, February 04, 2004 9:17 AM To: Boost Users mailing list Subject: [Boost-users] configuring boost on MS Visual Studio 6 where the installation drive isn't C: For a number of reasons we don't have MS Visual Studio installed on the C: drive. We also have another SDK installed that uses part of Rogue Wave. Both libraries try to define min, max and a reverse iterator (there are items, those are the ones we've come across in an afternoon of experimentation). As I understand things, the ./configure script will look for conflicts with other libraries and try to work around them. The ./configure script is a bourne shell script, but there is no obvious way of running that script in Windows. One approach I thought of was to install cygwin to run the script, but that would have to invoke the MS C++ compiler (invoking a Windows based tool from inside of a Linux like environment), I'm not sure that would actually work. Are there alternatives that need to be explored? Would the cygwin approach actually work? (we are currently using MS Visual Studio 6 because of requirement of the other SDK) _______________________________________________ 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

Boost release 1.31.0 is available
by Beman Dawes 06 Feb '04

06 Feb '04

Boost release 1.31.0 is available. See the www.boost.org home page for latest news about what's in the release. Or go right to http://sourceforge.net/project/showfiles.php?group_id=7586 to download. Thanks to everyone who helped with this release. The folks that run the regression tests and review the release candidates get a special pat on the back. Due to compiler updates, three shipping and one soon-to-ship C++ compiler now pass almost all of Boost's regression tests. A year ago, no compilers could do that. --Beman

3 3

Problems with boost build with latest CVS head.
by Jeff Holle 06 Feb '04

06 Feb '04

I updated my CVS head of boost at Wed Feb 4 13:17:44 PST 2004. I am using gcc version 3.3. I've run into 2 types of problems which I have not experienced before. 1. There is some diff trible in boost/tools/build/v1/gcc-tools.jam starting at line 61. I solved it by commenting out three lines. 2. Compiler errors with boost/libs/date_time/src/gregorian/greg_month.cpp at line 18. Since I'm not using this part of boost, I haven't bothered fixing it. An example of the errors is: /boost/boost/date_time/date_parsing.hpp: In function ` date_type boost::date_time::parse_date(const std::string&, int)': /boost/boost/date_time/date_parsing.hpp:100: error: parse error before `>' token

3 3

Rationale on explicit shared_ptr constructor
by Aaron W. LaFramboise 05 Feb '04

05 Feb '04

Hi, (I can't beleive this wouldn't have been discussed already, but I haven't been able to find an answer in my searches [Google's search results into boost's web maillist seem to be incoherent.].) I recently converted a portion of a medium-sized project from loki::Smart_Ptr to boost::shared_ptr (primarily for weak_ptr support), and almost everything worked out of the box, except: boost: template<class Y> explicit shared_ptr <#constructors>(Y * p); loki: SmartPtr(const StoredType& p) In other words, code like this stopped working: some_smart_ptr<int> my_function() { return new int; // error: conversion from `int*' to non-scalar type `boost::shared_ptr<int>' // requested } Even when I adopt the convention to convert the return value to the smart pointer type such as with "return some_smart_ptr<int>(new int)", returning a null pointer as 'zero' doesn't work: some_smart_ptr<int> my_function() { return some_smart_ptr<int>(0); // error: no matching function for call to // `boost::shared_ptr<int>::shared_ptr(int)' } I've worked around this by simply using "return some_smart_ptr<int>();". However, I feel somewhat strongly that this sort of usage is unnecessarily ugly, and confuses the meaning of the code unnecessarily. More importantly, it causes smart pointers to behave differently from ordinary pointers, which is undesirable, as it requires the user (who may not know or care anything about the smart pointer, or even know that it is one, depending on a module's implementation and documentation) to have to learn and use and debug additional semantics. So my question follows. I understand that there are very good reasons for disallowing automatic conversion from a smart pointer, but why disallow automatic conversion to the smart pointer type also? If there are strong reasons for this, would it be reasonable to document this somewhere in the shared_ptr documentation? If not, is this particular aspect of shared_ptr possibly subject to discussion or change in the future? Thank you for your time, Aaron W. LaFramboise

2 1

regex_match error
by Vikrant Rathore 05 Feb '04

05 Feb '04

Hi, I am using the regex library and using the following expression. But it seems it is wrong. Since there is no compilation or linker error but runtime error. the expression is boost::regex e("*\\.exe") and the call to regex_match is if (boost::regex_match((*dir_itr).native_file_string(),e)) But as soon as I use * it throws some runtime error. If I remove "\\." and "*". It works fine. Does anyone have such issue. Thanks with best regards, Vikrant

3 3

Subgraph and internal properties
by Hugues Joly 05 Feb '04

05 Feb '04

Hi, I'm posting again a question that got confused due to mistakes from my part... I'd like to clarify a point about internal properties accessed through a subgraph. According to the documentation of the method "get(PropertyTag, subgraph& g)": "vertex and edge properties are shared by all subgraphs, so changes to a property through a local vertex descriptor for one subgraph will change the property for the global vertex descriptor, and therefore for all other subgraphs." (c.f. boost-1.30.2/libs/graph/doc/subgraph.html) Here, I'm sending you a small program inspired by the boost-1.30.2/libs/graph/example/subgraph.cpp example. >From its behavior, it seems that: 1) A property value is not shared between the global descriptor and its corresponding local descriptors. 2) we need to initialize property values for each of the subgraphs. For example, if I set a name "A" for the global vertex descriptor A, that property is not seen through the corresponding local vertex descriptors. Is this a case of misuse or is it a bug? __________________________________________________________ Lèche-vitrine ou lèche-écran ? magasinage.yahoo.ca /* Sample output: After initializing properties for G1: Global and local properties for vertex G0[C]... G0[C]= C G1[A1]= A1 Global and local properties for vertex G0[E]... G0[E]= E G1[B1]= B1 Global and local properties for vertex G0[F]... G0[F]= F G1[C1]= C1 After initializing properties for G2: Global and local properties for vertex G0[A] G0[A]= A G2[A2]= A2 Global and local properties for vertex G0[C]... G0[C]= C G1[A1]= A1 G2[B2]= B2 */ #include <boost/config.hpp> #include <iostream> #include <boost/graph/subgraph.hpp> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/graph_utility.hpp> int main(int,char*[]) { using namespace boost; //typedef adjacency_list_traits<vecS, vecS, directedS> Traits;// Does nothing? typedef property< vertex_color_t, int, property< vertex_name_t, std::string > > VertexProperty; typedef subgraph< adjacency_list< vecS, vecS, directedS, VertexProperty, property<edge_index_t, int> > > Graph; const int N = 6; Graph G0(N); enum { A, B, C, D, E, F}; // for conveniently refering to vertices in G0 property_map<Graph, vertex_name_t>::type name = get(vertex_name_t(), G0); name[A] = "A"; name[B] = "B"; name[C] = "C"; name[D] = "D"; name[E] = "E"; name[F] = "F"; Graph& G1 = G0.create_subgraph(); enum { A1, B1, C1 }; // for conveniently refering to vertices in G1 add_vertex(C, G1); // global vertex C becomes local A1 for G1 add_vertex(E, G1); // global vertex E becomes local B1 for G1 add_vertex(F, G1); // global vertex F becomes local C1 for G1 property_map<Graph, vertex_name_t>::type name1 = get(vertex_name_t(), G1); name1[A1] = "A1"; std::cout << std::endl << "After initializing properties for G1:" << std::endl; std::cout << " Global and local properties for vertex G0[C]..." << std::endl; std::cout << " G0[C]= " << boost::get(vertex_name, G0, C) << std::endl;// prints: "G0[C]= C" std::cout << " G1[A1]= " << boost::get(vertex_name, G1, A1) << std::endl;// prints: "G1[A1]= A1" name1[B1] = "B1"; std::cout << " Global and local properties for vertex G0[E]..." << std::endl; std::cout << " G0[E]= " << boost::get(vertex_name, G0, E) << std::endl;// prints: "G0[E]= E" std::cout << " G1[B1]= " << boost::get(vertex_name, G1, B1) << std::endl;// prints: "G1[B1]= B1" name1[C1] = "C1"; std::cout << " Global and local properties for vertex G0[F]..." << std::endl; std::cout << " G0[F]= " << boost::get(vertex_name, G0, F) << std::endl;// prints: "G0[F]= F" std::cout << " G1[C1]= " << boost::get(vertex_name, G1, C1) << std::endl;// prints: "G1[C1]= C1" Graph& G2 = G0.create_subgraph(); enum { A2, B2 }; // for conveniently refering to vertices in G2 add_vertex(A, G2); // global vertex A becomes local A2 for G2 add_vertex(C, G2); // global vertex C becomes local B2 for G2 property_map<Graph, vertex_name_t>::type name2 = get(vertex_name_t(), G2); name2[A2] = "A2"; std::cout << std::endl << std::endl << "After initializing properties for G2:" << std::endl; std::cout << " Global and local properties for vertex G0[A]" << std::endl; std::cout << " G0[A]= " << boost::get(vertex_name, G0, A) << std::endl;// prints: "G0[A]= A" std::cout << " G2[A2]= " << boost::get(vertex_name, G2, A2) << std::endl;// prints: "G2[A2]= A2" name2[B2] = "B2"; std::cout << " Global and local properties for vertex G0[C]..." << std::endl; std::cout << " G0[C]= " << boost::get(vertex_name, G0, C) << std::endl;// prints: "G0[C]= C" std::cout << " G1[A1]= " << boost::get(vertex_name, G1, A1) << std::endl;// prints: "G1[A1]= A1" std::cout << " G2[B2]= " << boost::get(vertex_name, G2, B2) << std::endl;// prints: "G2[B2]= B2" return 0; }

2 4

RE: [Boost-users] configuring boost on MS Visual Studio 6 where t he installation drive isn't C:
by Administrator 05 Feb '04

05 Feb '04

Wayne, What configure script? Boost requires bjam.exe. If you follow the directions here: http://www.boost.org/more/getting_started.html you should have no problems. I have never had a problem with either MS Visual C++ 6.0 with regards to bjam, nor have I ever used a configure script with Boost. Cygwin is an alternative, but you shouldn't need it if you follow the getting started directions. Dale -----Original Message----- From: Dernoncourt, Wayne CTR NAVAIR 3184, ,10 [mailto:wayne.dernoncourt@navy.mil] Sent: Wednesday, February 04, 2004 9:17 AM To: Boost Users mailing list Subject: [Boost-users] configuring boost on MS Visual Studio 6 where the installation drive isn't C: For a number of reasons we don't have MS Visual Studio installed on the C: drive. We also have another SDK installed that uses part of Rogue Wave. Both libraries try to define min, max and a reverse iterator (there are items, those are the ones we've come across in an afternoon of experimentation). As I understand things, the ./configure script will look for conflicts with other libraries and try to work around them. The ./configure script is a bourne shell script, but there is no obvious way of running that script in Windows. One approach I thought of was to install cygwin to run the script, but that would have to invoke the MS C++ compiler (invoking a Windows based tool from inside of a Linux like environment), I'm not sure that would actually work. Are there alternatives that need to be explored? Would the cygwin approach actually work? (we are currently using MS Visual Studio 6 because of requirement of the other SDK) _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

RE: [Boost-users] configuring boost on MS Visual Studio 6 where the installation drive isn't C:
by Kutch, Patrick G 05 Feb '04

05 Feb '04

I believe you simply need to set VC6_ROOT environment variable to the location where you have MS Visual Studion 6 installed. Patrick Kutch Life is too short to drink bad coffee. -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Dernoncourt, Wayne CTR NAVAIR 3184, ,10 Sent: Wednesday, February 04, 2004 9:17 AM To: Boost Users mailing list Subject: [Boost-users] configuring boost on MS Visual Studio 6 where the installation drive isn't C: For a number of reasons we don't have MS Visual Studio installed on the C: drive. We also have another SDK installed that uses part of Rogue Wave. Both libraries try to define min, max and a reverse iterator (there are items, those are the ones we've come across in an afternoon of experimentation). As I understand things, the ./configure script will look for conflicts with other libraries and try to work around them. The ./configure script is a bourne shell script, but there is no obvious way of running that script in Windows. One approach I thought of was to install cygwin to run the script, but that would have to invoke the MS C++ compiler (invoking a Windows based tool from inside of a Linux like environment), I'm not sure that would actually work. Are there alternatives that need to be explored? Would the cygwin approach actually work? (we are currently using MS Visual Studio 6 because of requirement of the other SDK) _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

configuring boost on MS Visual Studio 6 where the installation drive isn't C:
by Dernoncourt, Wayne CTR NAVAIR 3184, ,10 05 Feb '04

05 Feb '04

For a number of reasons we don't have MS Visual Studio installed on the C: drive. We also have another SDK installed that uses part of Rogue Wave. Both libraries try to define min, max and a reverse iterator (there are items, those are the ones we've come across in an afternoon of experimentation). As I understand things, the ./configure script will look for conflicts with other libraries and try to work around them. The ./configure script is a bourne shell script, but there is no obvious way of running that script in Windows. One approach I thought of was to install cygwin to run the script, but that would have to invoke the MS C++ compiler (invoking a Windows based tool from inside of a Linux like environment), I'm not sure that would actually work. Are there alternatives that need to be explored? Would the cygwin approach actually work? (we are currently using MS Visual Studio 6 because of requirement of the other SDK)

1 0

Re: [Boost-users] boost::bind throws exception with VisualStudio
by Cheenu Srinivasan 05 Feb '04

05 Feb '04

Douglas Gregor wrote: >Cheenu Srinivasan wrote: > > Peter Klotz wrote: > > >Cheenu Srinivasan wrote: > > > > The following program throws a bad_function_call exception when > > > > compiled with VisualStudio 7.1. It happens with both boost-1.30.2 > > > > and boost_1_31_0_rc2. No problems when compiled with g++ 2.95.1 > > > > on solaris. > > > > > >Tried it with VC++7.1 and Boost 1.30.2. > > > > > >Compiles and runs without problems. > > > > Hmm, tried it on someone else's PC with VisualStudio 7.1 and both 1.30.2 > > and boost_1_31_0_rc2 throw the exception there as well, so it isn't >simply > > something > > in my environment. > > > > "About" reports the following version info (on all three PCs I've tried >it > > on): > > > > Microsoft Development Environment 2003 -- Version 7.1.3088 > > Microsoft .NET Framework 1.1 -- Version 1.1.4322 > >Are you compiling it as Managed C++ or native C++? Some feedback on the >developer's list seems to say that it's a Managed C++ issue, which I can >fix in CVS but not for 1.31.0. You're right. If I build it using the IDE as a .NET project (created using "File | New | Projects | Visual C++ Projects | .NET | Empty Project (.NET)" then I have this problem. It works fine when I build it with my own makefile. Thanks. _________________________________________________________________ Find high-speed net deals comparison-shop your local providers here. https://broadband.msn.com

1 0