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

REGEX - expression doesn't match
by Fr�d�ric Mayot 24 Aug '02

24 Aug '02

Hi, My problem is really simple : I have several regular expressions (like (19[4-9]\d)|(200\d)|( [09]\d ) ) which work when they correspond to the entire string, e.g. : "2002" OK; "something 2002 something" NOT OK. Everythings worked fine with the GRETA library, and now, it doesn't. Does anyone have an idea ? Thanks. Fred

3 5

Re: [Boost-Users] Re: REGEX - expression doesn't match
by dan.ellis＠sophos.com 23 Aug '02

23 Aug '02

> It's simple : I have a string and a regular expression. I only want to > find the FIRST sub-string which matches my regular expression (S), then > to extract the sub-string before S and the sub-string after S. Off the top of my head, it sounds like you want: (.+)(200\d)(.*) -- Dan Ellis, Software Engineer, Sophos Anti-Virus Email: dan.ellis(a)sophos.com, DDI: 01235 540204 Real Business/CBI Growing Business Awards: Company of the Year Tel: 01235 559933, Web: http://www.sophos.com/

1 0

Graph - return edge_descriptor
by Shaw, Richard A 23 Aug '02

23 Aug '02

Can anybody tell my why the find_edge function in the code below fails to get a property if I return the first edge in the list. This is what happens - Find_edge looks for edge A - B It winds it and prints out the edge descriptor, and the weight of the edge It the returns the edge The main code prints out the edge descriptor and the fails when trying to print the weight. BTW - Is there a ready made function to find an edge based on the vertices ? #include <boost/config.hpp> #include <iostream> #include <fstream> #include <boost/graph/graph_traits.hpp> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/dijkstra_shortest_paths.hpp> using namespace boost; // Find edge template <class Graph> std::pair<bool, graph_traits<Graph>::edge_descriptor> find_edge(graph_traits<Graph>::vertex_descriptor u, graph_traits<Graph>::vertex_descriptor v, Graph g) { graph_traits<Graph>::out_edge_iterator ei, edge_end; for (boost::tie(ei,edge_end) = out_edges(u, g); ei != edge_end; ++ei) { if (target(*ei, g) == v) { std::cout << "Inside " << *ei << " " << get(edge_weight, g, *ei) << std::endl; return std::make_pair(true, *ei); } } return std::make_pair(false, *ei); // Is there a null edge that I can return ? } int main(int, char *[]) { typedef adjacency_list < listS, vecS, directedS, no_property, property < edge_weight_t, int > > graph_t; typedef graph_traits < graph_t >::vertex_descriptor vertex_descriptor; typedef graph_traits < graph_t >::edge_descriptor edge_descriptor; typedef std::pair<int, int> Edge; const int num_nodes = 5; enum nodes { A, B, C, D, E }; Edge edge_array[] = { Edge(A, C), Edge(B, B), Edge(B, D), Edge(B, E), Edge(C, B), Edge(C, D), Edge(D, E), Edge(E, A), Edge(E, B) }; int weights[] = { 1, 2, 1, 2, 7, 3, 1, 1, 1 }; int num_arcs = sizeof(edge_array) / sizeof(Edge); #ifdef BOOST_MSVC graph_t g(num_nodes); property_map<graph_t, edge_weight_t>::type weightmap = get(edge_weight, g); for (std::size_t j = 0; j < num_arcs; ++j) { edge_descriptor e; bool inserted; tie(e, inserted) = add_edge(edge_array[j].first, edge_array[j].second, g); weightmap[e] = weights[j]; } #else graph_t g(edge_array, edge_array + num_arcs, weights, num_nodes); property_map<graph_t, edge_weight_t>::type weightmap = get(edge_weight, g); #endif graph_traits < graph_t >::edge_descriptor e; bool found; std::cout << "List All" << std::endl; graph_traits < graph_t >::edge_iterator ei, ei_end; for (tie(ei, ei_end) = edges(g); ei != ei_end; ++ei) { std::cout << *ei << get(weightmap, *ei) << std::endl; } std::cout << "List Not First" << std::endl; tie(found, e) = find_edge< graph_t >(E, A, g); std::cout << "Outside " << e << get(weightmap, e) << std::endl; // This edge is OK std::cout << "List First" << std::endl; tie(found, e) = find_edge< graph_t >(A, C, g); std::cout << "Outside " << e << get(weightmap, e) << std::endl; // This line fails to get the weight return EXIT_SUCCESS; } Richard Shaw ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°`°º¤ø,¸¸,ø¤ Atkins Transport Systems Woodcote Grove Ashley Road Epsom KT18 5BW Direct Dial.: +44 (0) 1372 756407 Switchboard: +44 (0) 1372 726140 Fax: +44 (0) 1372 740055 www.atkinsglobal.com/transportsystems <www.atkinsglobal.com/transportsystems> This email and any attached files are confidential and copyright protected. If you are not the addressee, any dissemination of this communication is strictly prohibited. Unless otherwise expressly agreed in writing, nothing stated in this communication shall be legally binding.

4 4

RE: [Boost-Users] Re: boost::object_pool
by scleary＠jerviswebb.com 22 Aug '02

22 Aug '02

> -----Original Message----- > From: wugui [mailto:yg-boost-users@m.gmane.org] > > another question: > > how make boost::object_pool thread_safe? To make a pool object thread-safe, guard all access with a mutex. -Steve

1 0

RE: [Boost-Users] boost::object_pool
by scleary＠jerviswebb.com 22 Aug '02

22 Aug '02

> -----Original Message----- > From: wugui [mailto:yg-boost-users@m.gmane.org] > > class A; > class B; > class AB : virtual public A, virtual public B; > > all destruct is virtual > > boost::object_pool<AB> pool_ab; > > B * pb = pool_ab.constuct(); > pool_ab.destroy(pb); // is this right? This looks right to me; what "pool_ab.destroy(pb);" does is: pb->~AB(); free(pb); // puts pb back in the free list of pool_ab -Steve

1 0

Kai C++ for Linux and Solaris
by Wintermantel , Marc 22 Aug '02

22 Aug '02

Hi everybody, We really badly need the latest version available of Kai C++ Compiler for Linux and Solaris. If someone wants to sell his copy, please write me!!! We would really be grateful. Yours truly, Marc Wintermantel Marc Wintermantel IMES - Structures Technology ETH Zurich, LEO C4 Leonhardstrasse 27 CH- 8092 Zurich Tel. ++41 1 633 35 32 Fax. ++41 1 632 17 02 [Non-text portions of this message have been removed]

1 0

boost::object_pool
by wugui 22 Aug '02

22 Aug '02

class A; class B; class AB : virtual public A, virtual public B; all destruct is virtual boost::object_pool<AB> pool_ab; B * pb = pool_ab.constuct(); pool_ab.destroy(pb); // is this right?

1 1

boost lambda library compile error
by khuroth 21 Aug '02

21 Aug '02

I have searched already in this list and the dev list for these MSVC compiler errors, but none of the solutions have worked so far. I have turned off precompiled headers, built clean, tried defining BOOST_NO_MEMBER_TEMPLATES before including "boost/lambda/lambda.hpp" (or "boost/lambda/bind.hpp"), and I still always get this error under Visual C++ 6 SP5 (Win2k Pro SP3), in both the Debug and Release configurations: Deleting intermediate files and output files for project 'dWin - Win32 Release'. --------------------Configuration: dWin - Win32 Release--------------- ----- Compiling... dwin-button.cpp dwin-common-control.cpp dwin-dialog.cpp C:\TMP\BOOST\BOOST_1_28_0\boost/lambda/detail/lambda_fwd.hpp(31) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 1794) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information Not sure what I'm doing wrong..

4 6

Boost Concept Check Library
by igor_bashkirov 21 Aug '02

21 Aug '02

Hello, I work on big software project that is ported to several platforms/compilers, including Linux,Solaris/GCC 2.95.2,3.0.4); Windows/MSVC 6.0; AIX/VisualAge; MacOS X / GCC 2.95.2 (Apple). Recently, I decided to make use of Boost library (v 1.28) and the first thing I tried was Boost Concept Check Library (BCCL). Unfortunately, the use of the library wasn't as smooth as I expected, namely, with respect to BOOST_CLASS_REQUIRES macro. Thus, I'd like to submit a couple of observations and one proposal regarding usage of this macro. Let's start with observations: following is the snippet from <boost/concept_check.hpp> header: [code // The BOOST_CLASS_REQUIRES macros use function pointers as // template parameters, which VC++ does not support. #if defined(BOOST_NO_FUNCTION_PTR_TEMPLATE_PARAMETERS) #define BOOST_CLASS_REQUIRES(type_var, concept) .... #else #define BOOST_CLASS_REQUIRES(type_var, concept) \ typedef void (concept <type_var>::* func##type_var##concept)(); \ .... end code] As you could see, BOOST_CLASS_REQUIRES macros evaluate to nothing if BOOST_NO_FUNCTION_PTR_TEMPLATE_PARAMETERS symbol is defined. But, to my great surprise, I didn't find any more references to BOOST_NO_FUNCTION_PTR_TEMPLATE_PARAMETERS symbol throughout the Boost library. Moreover, the above comment about VC++ not supporting function pointers as template parameters is wrong (at least for MSVC 6.0 with SP5). Not to be unfounded, I will provide following sample program successfully compiled and run under MSVC 6.0 with SP5: [code #include <iostream> using namespace std; typedef void(*FP)(); template <FP T> class X { FP fp_; public: X() : fp_(T) {} void print() const { cout << fp_ << endl; } }; void f() {} int main(int, char**) { X<&f> x1; x1.print(); return 0; } end code] The same is true for pointers to member functions of both ordinary and template classes. OK, this observation could be treated as "cosmetic" one, but the following won't. Let's look at the definition of BOOST_CLASS_REQUIRES macro: [code #define BOOST_CLASS_REQUIRES(type_var, concept) \ typedef void (concept <type_var>::* func##type_var##concept)(); \ template <func##type_var##concept _Tp1> \ struct concept_checking_##type_var##concept { }; \ typedef concept_checking_##type_var##concept< \ BOOST_FPTR concept <type_var>::constraints> \ concept_checking_typedef_##type_var##concept end code] and at a typical usage of this macro (taken from Boost documentation): [code template <class T> struct generic_library_class { BOOST_CLASS_REQUIRES(T, EqualityComparableConcept); // ... }; end code] Here, the "EqualityComparableConcept" is a concept checking class defined in the "boost" namespace. OK, that's great and works fine until "generic_library_class" is also declared in the "boost" namespace. Let's now suppose "generic_library_class" is declared in namespace "ns1". Then, BOOST_CLASS_REQUIRES macro evaluates to following: [code namespace ns1 { template <class T> struct generic_library_class { typedef void (EqualityComparableConcept <T>::* funcTEqualityComparableConcept)(); ... }; } end code] Did you see the problem places? Yes, it's where "concept" parameter of the macro is substituted for "EqualityComparableConcept". This name is not declared in the namespace "ns1"! The first itch could be to specify "boost::EqualityComparableConcept" as a value of the second parameter of the macro, but, "not so fast, Skywalker!" - in this case we will end up with "funcTboost::EqualityComparableConcept" name for the pointer to member function that is not a legal name of C/C++ identifier. Someone could say "What a big deal?! Just write 'using namespace boost;' or 'using boost::EqualityComparableConcept;' just before declaring 'generic_library_class'.". Well, the declaration of "generic_library_class" seems to be in the header, right? And what do you think about writing "using-directives" in header files? Yes, right, - it's evil! Especially for large production code. Just check your favorite C++ book. Though, the use of "using-declarations" in headers is a moot point, I also consider it as evil for the same reasons as for "using- directives". Anyway, "using-declarations" won't help us, - they just don't work under MSVC 6.0 in our case. So, what do we have, - "exclusive circle"? I hope not. Finally, I got to the proposal that should help us to eliminate defects of the macro and to obviate above-stated difficulties. What if to add one more parameter, say, "ns", to the BOOST_CLASS_REQUIRES macro to pass the name of the namespace the concept checking class belongs to? Let's look at the new definition of the macro: [code #define BOOST_CLASS_REQUIRES(type_var, ns, concept) \ typedef void (ns::concept <type_var>::* func##type_var##ns##concept) (); \ template <func##type_var##ns##concept _Tp1> \ struct concept_checking_##type_var##ns##concept { }; \ typedef concept_checking_##type_var##ns##concept< \ BOOST_FPTR ns::concept <type_var>::constraints> \ concept_checking_typedef_##type_var##ns##concept; end code] and at it's usage: [code namespace ns1 { template <class T> struct generic_library_class { BOOST_CLASS_REQUIRES(T, boost, EqualityComparableConcept); // ... }; } end code] that will evaluate to the following: [code namespace ns1 { template <class T> struct generic_library_class { typedef void (boost::EqualityComparableConcept <T>::* funcTboostEqualityComparableConcept)(); ... }; } end code] That's it. Moreover, this solution does not suffer from yet another drawback inherent to the original one, viz, name clashing when using in the same class concept checking classes with the same name, but from different namespaces. The only issue I could see with my suggestion was impossibility to use concept checking classes declared at the global scope, but, I hope nobody would think of such thing, because it's evil (sorry for repetition). I hope the proposed solution will increase usability of the BCCL. Best regards, Igor Bashkirov.

3 2

Upgrade VisC++ compiler
by sen_al2002 20 Aug '02

20 Aug '02

Hi, I am a newbie to all this programmer stuff. I am a physics student doing some computer simulations. I was trying to use the special function atanh from boost libraries but couldn't. The error message reads d:\boost_1_28_0\atanh.hpp(77) : error C2989: 'atanh_helper1_t<T,0>' : template class has already been defined as a non-template class Some advised me to update my VisC++ ver 6.0 compiler. How can I do that? Does anybody out there have any better advise? Thanks sen

4 4