- Boost - lists.boost.org

Simple regex problem
by Preston A. Elder 03 Feb '05

03 Feb '05

Hum, Consider the following application (running on Linux with GCC): === BEGIN CODE #include <boost/regex.hpp> #include <iostream> #include <exception> #include <typeinfo> int main() { try { std::string rx_string = "^([[:alpha:]][-[:alnum:]]*[[:space:]]*)+$"; boost::regex rx(rx_string, boost::regex_constants::char_classes | boost::regex_constants::intervals); std::string test = "GlobalMSG HelpServ DevNull"; if (boost::regex_match(test, rx)) std::cout << "Matched." << std::endl; else std::cout << "Not Matched." << std::endl; } catch (const std::exception &e) { std::cout << "Exception " << typeid(e).name() << ": " << e.what() << std::endl; } return 0; } === END CODE The result of running this is: Exception N5boost14bad_expressionE: Memory exhausted My question is, why? The regex is simple enough, and the source string is quite short. Please note, the same regex with the test string of: "OperServ Magick-1" runs and completes successfully without a problem. Any ideas on how to fix this? -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net)

3 3

CW and NOMINMAX
by Stefan Slapeta 03 Feb '05

03 Feb '05

Hi all, I wonder why NOMINMAX is defined globally for _all_ platforms in cw-tools.jam. # Some language related options flags cw C++FLAGS : -DNOMINMAX ; This produces warnings for some regressions due to redefinitions in the code! Aside from that, IMO it doesn't make sense to define NOMINMAX on other platforms than windows, no? If nobody objects, I would like to remove this line to see what happens. Stefan

1 0

New Library?
by John Eddy 03 Feb '05

03 Feb '05

Would anyone be interested in a library for doing logging? I've written one for my own purposes and thought others might find it useful. It will store log entries at various levels (FATAL, SHOUT, ERROR, WARN, INFO, DEBUG, DETAIL). There is a default level and the level can be customized for entries by individual instances of any type and for entries by any types as a whole. I'll be glad to provide more information if anyone is interested. John

8 14

Re: [boost] Re: Help needed with BGL & multi_index_container
by JOAQUIN LOPEZ MU?Z 03 Feb '05

03 Feb '05

Hi Alexander, ----- Mensaje original ----- De: Alexander <rhjrjlbk2002(a)yahoo.com> Fecha: Miércoles, Febrero 2, 2005 8:38 pm Asunto: [boost] Re: Help needed with BGL & multi_index_container > Hi Joaquin and Jeremy, > > Below you may find latest version of my test program. > This time it compiles, links and works :-). I have to > say - it was not easy to make it working. > > The only trouble I have is clumsy code in templated > ItemHolder::operator()(const P&p) and correspondent call > to template ItemHolder::get_int(...). See my comments > below. > > I'm looking for advice to make it nicer. I think I've got something, please read below. > > Replacement of "const P& p" to "void*" breaks VS 7.1. > [...] > > > From: Joaquin M Lopez Munoz <joaquin <at> tid.es> > > Date: Tue, 01 Feb 2005 22:51:12 +0000 > > MG::vertex_descriptor vd1 = > > add_vertex( ItemHolder( 1, Item(1) ), mg ); > > In this line following is happen: > > 1. adjacency_list allocates (with new) a new > stored_vertex structure to store property > element of type ItemHolder (yes, using my initialization > value), fields to store incoming, outgoing edges and > other fields. > > 2. This pointer is cast to a void *, to be used as > the new vertex descriptor. > > 3. The void * is fed to the multi_index_container used > for vertex storage. > > 4. Now, inside ItemHolderKey, that "void *" must be converted to back > to stored_vertex type, defined in base class of adajcent_list. And > thisI find as a real threat to break everything. To my regret, I > can't spend > more > time - I have to put all that into my project. > > > Well, all in all I must say this is a glorious hack :) > > Thank you! Indeed, you did helped me. > > > Probably, the only sensible approach is to write from > > scratch a graph-compliant structure that uses > > I already did that couple of times. I do not want that anymore. > Writing, testing, documenting, helping colleques to numerous > suboptimal versions of the same component, scattered through > number of versions of different products... No, thank you. > > > That said, the thing seems to work and may suffice > > for your purposes. > > I see that as a quite general use case. > > > It'd be great if some BGL expert (Jeremy?) jumped > > in and comment on this. > > Yes, that would be great. > > Kind Regards, > Alexander > > -------------- sample code -------------- > #include <iostream> > > #include <boost/multi_index_container.hpp> > #include <boost/multi_index/ordered_index.hpp> > #include <boost/multi_index/sequenced_index.hpp> > > #include <boost/graph/adjacency_list.hpp> > > using namespace boost; > using namespace boost::multi_index; > > using namespace std; > > template<class Index> > struct MICSelector > { > typedef Index index; > }; > > struct Item > { > Item(int _a=0, int _b=0, int _c=0) > : a(_a), b(_b), c(_c) {} > > int a,b,c; > > friend std::ostream& operator<< > (std::ostream& os, const Item& item) > { > return os << " a: " << item.a << > " b: " << item.b << " c: " << > item.c << " "; > } > }; > > struct ItemHolder > { > ItemHolder(int id=0, const Item item=Item()) > : m_ID(id), m_item(item) {} > > int m_ID; > Item m_item; > > friend std::ostream& operator<< > (std::ostream& os, const ItemHolder& item) > { > return os << " ID: " << item.m_ID > << " Item( " << item.m_item << ") "; > } > }; > > struct ItemHolderKey > { > typedef int result_type; > int operator()(const ItemHolder& v) const { return v.m_ID; } > > template<class P, class Derived, class Config, class Base> > int get_int(const P& p, const adj_list_impl<Derived, Config, Base>&) > const; > > template<class P> > int operator()(const typename P& p) const; > }; The problem with your approach to implementing this oeprator() is that you've got a circular dependency between ItemHolderKey, which is nasty to say the least. Since you're hacking your way through this, I guess you won't mind relying on just another undocumented feature to solve this in a nicer manner. Reviewing the BGL source, seems like the container is not instantiated with void*s but rather with the actual stored_vertex pointer. stored_vertex must be one of the following types: boost::graph::detail::adj_list_gen<...>::config::seq_stored_vertex; boost::graph::detail::adj_list_gen<...>::config::bidir_seq_stored_vertex ; boost::graph::detail::adj_list_gen<...>::config::rand_stored_vertex; boost::graph::detail::adj_list_gen<...>::config::bidir_rand_stored_verte x; So you just can provide overloads for all of them and get rid of the "static MG m" dependency and the get_int() memfun: template <class Graph, class VertexListS, class OutEdgeListS, class DirectedS, class VertexProperty, class EdgeProperty, class GraphProperty, class EdgeListS> int operator()( const boost::graph::detail::adj_list_gen<...>::config::seq_stored_vertex* p) const { return p->m_property.m_value.m_ID; } //etc for the other stored_vertex types See what I mean? You can even do better and provide an adaptor that takes a general key extractor and performs the surgery: template<typename KeyExtractor> struct from_adjacency_list: private KeyExtractor { typedef KeyExtractor::result_type result_type; // we forward to KeyExtractor for the general case template<typename Value> const result_type& operator()(const Value& v) { return KeyExtractor::operator()(v); } // overloads for the various stored_vertex types template <class Graph, class VertexListS, class OutEdgeListS, class DirectedS, class VertexProperty, class EdgeProperty, class GraphProperty, class EdgeListS> const result_type& operator()( const boost::graph::detail::adj_list_gen<...>::config::seq_stored_vertex* p) const { return KeyExtractor::operator()(p->m_property.m_value); } // etc }; Now you can use this adaptor in a fairly general way: // No need to define ItemHolderKey. // No dependecies from the particular adjacency_list you're // instantiating. typedef indexed_by < sequenced<>, ordered_unique< from_adjacency_list<member<ItemHolder,int,&ItemHolder::m_ID> > > // and other indices > Index; I haven't actually tried this, but I think it should work and provide with a much more comfortable way to define your embedded MICs. [...] > It is correct that I use undocumented features of BGL to > fuse MIC and BGL. OTOH, it is the way how std::list, > std::vector etc. are used. It would be a surprise if it > is gonna change. One could say that it is > documentation issue, rather then the code. Well, the thing should work but won't be surprised if everthing goes to heck when ugrading to Boost 1.3x. As for this being a documentation issue, I'm afraid too much detail is relied on to think realistically BGL authors will concede to open it to the public. A most viable solution (applicable not only to MIC but also to any other container) would be to have a graph class modeled after adjacency_list with the following aspect: template< typename ElementType, typename EdgeList, typename VertexList, ... > element_adjacency_list; so that it guarantees that the edge container is instantiated with elements of type ElementType*. This is not very hard to achieve if the actual stored_vertex is defined like this: template<typename ElementType> struct element_pointer { ElementType* ptr; }; template<typename ElementType,...> struct stored_vertex: public element_pointer<ElementType> { // rest of the payload (properties, pointer to edge list, etc. }; // from stored_vertex* to ElementType* stored_vertex<...>* sv; ElementType* ptr=sv->ptr; // from ElementType* to stored_vertex // this is portable! ElementType* ptr; element_pointer<ElementType>* eptr= reinterpret_cast<element_pointer<ElementType>*>( reinterpret_cast<char*>(ptr)- offsetof(element_pointer<ElementType>,ptr) ); stored_vertex<...>* sv=static_cast<stored_vertex<...>*>(eptr); Implementing this should be mostly cut&paste from the original adjacency_list, so, who knows, maybe you can convince BGL authors to do it :) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[Boost-bugs] [ boost-Bugs-1115124 ] Diff in state of mersenne_twister gen between GCC3.41 & CW9
by SourceForge.net 03 Feb '05

03 Feb '05

Bugs item #1115124, was opened at 2005-02-02 16:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1115124&group_… Category: random Group: None Status: Open Resolution: None Priority: 5 Submitted By: Morgan (toth21) Assigned to: Jens Maurer (jmaurer) Summary: Diff in state of mersenne_twister gen between GCC3.41 & CW9 Initial Comment: I have found a bug with the mersenne_twister random number generator class, where results when calling for a random number vary between codewarrior 9.0 and gcc 3.4.1 with boost 1.31.0. A simple example is shown below: #include <boost/random/mersenne_twister.hpp> //for mt11213b typedef boost::mt11213b base_generator_type; class foo { public: foo(const base_generator_type gen):m_gen(gen) {} ~foo(void) {} rand_type operator() ( void ) { const float x = m_gen(); return x; } private: base_generator_type m_gen; } int main(void) { base_generator_type gen( (uint32_t) 2000); //seed is not important foo f(gen); cout << "Random result is " << f() << endl; } The resulting numbers will be different between codewarrior 9.0 running on windows (xp or 2000) and gcc 3.4.1 running on Suse linux 7.3.(Hope that is enough info). I tracked the cause of the bug down to class initialization. In the case of CW9.0, the compiler when constructing a foo, will use a mersenne_twister copy ctor when initializing m_gen, while in the case of gcc 3.4.1 it will choose the following in the .hpp file template<class Generator> explicit mersenne_twister(Generator & gen) { seed (gen); } therefore using the provided generator as a seed to the new generator rather than just copying its state, even though no template parameter is provided. Anyways I will leave it up to the more informed to decide which is more desirable/proper; however, this is a fairly nasty bug at the moment as you can not reproduce results between these two platforms when using this random number generator for your random numbers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1115124&group_… ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: Boost Digest, Vol 991, Issue 1
by Jared McIntyre 02 Feb '05

02 Feb '05

> Well, it doesn't look like you're inclined to give up so I guess we can't > either. Thas greatly appreciated. > Do I take this to mean that almost all the tests (200+) compiled, linked, > and executed with no error? Correct. To be exact, there were 5 skipped and 5 that failed. > General > 1) Configuration Type: Application(.exe) > 2) Use of MFC: Use Standard Windows Libraries > 3) Use of ATL: Not using ATL This project is MFC based, but I can't imagine that is causing an issue. Otherwise its the same. > C/C++ > 1) General > Additional Include Directories - the directory that contains boost > headers > 3) Preprocessor: > Preprocessor definitions - WIN32;_DEBUG;_CONSOLE > 4) Code Generation > Enable C++ Exceptions - Yes(/EHsc) > Runtime Library - Multi-threaded Debug DLL - note the DLL ! ( I > suspect this is the problem) > Enable Function-level Linking - Yes(/Gy) I prefer this myself but > not strictly necessary > 5) Language > Enable Run-Time type info - Yes (/GR) > Linker > 1) General > Additional Library Directories - <directory that contains the > serialization library here> > 2) Input > Additional Dependencies - libboost_serialization.lib This is all the same with the exception of the console part (since it is an MFC GUI app), but again, I doubt that is causing it. > I would hope that those settings should do it. To make sure its finding the > correct libboost_serialization.lib - change the name of this file. It > should come up with an error at link time - can't find file > libbost_serialization.lib. Changing this name back should make this error go > away. Check > The program should now compile !? Saddly, the problem persists. Perhaps it is something other than the library. Here are some code snippets in case there are issues there. The includes in the file that performes the save: #include <fstream> #include <boost/serialization/serialization.hpp> #include <boost/serialization/vector.hpp> #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> Here is the save code: std::ofstream ofs(PCSZ_USER_TOOLS_FILE, std::ios::binary); boost::archive::text_oarchive oa(ofs); // write class state from archive oa << boost::serialization::make_nvp("UserToolList", m_UserTools); // close archive ofs.close(); m_UserTools is an instance of a typedefed vector defined as: typedef std::vector<BusUserTool*> USER_TOOL_LIST; Thanks for hanging in with me. I will probably need to change the code so I compile the serialization code into the project soon in order to meet my deadlines, but I'd like to get the library working if possible. Jared

3 2

Dimensional Analysis
by Sérgio Vale e Pace 02 Feb '05

02 Feb '05

Is the dimensional analisys code shown in the MPL tutorial, part of the mpl library ? Or any other boost library ?

9 30

1.32 intel 8.1 in windows
by Matt Hurd 02 Feb '05

02 Feb '05

Trying and failing to compile v1.32 with Intel 8.1 on windows. Seems mainly /Zm800 option is in error. Is there a quick fix for building 1.32 with this toolset? I'm simply doing this from the boost root bjam "-sTOOLS=intel-win32" "-sINTEL_BASE_MSVC_TOOLSET=vc-7_1" stage TIA, Matt. matthurd(a)acm.org

2 4

Help needed with BGL & multi_index_container
by Me here 02 Feb '05

02 Feb '05

Hi there, I need an advanced container which allows me to access my data over number of different indices. That is exactly what for boost::multi_index_container was made. But, my data items also have relationships with other data in the same container, which could be represented as directed graph. So, I have made a custom container, which aggregates multi_index_container (MIC) to store data items and a graph (BGL) to store relationships. To allow switching from MIC to walk over relationships, as an additional field of my item in MIC I store BGL vertex; as vertex property in graph I store the key of unique index in MIC. So, MIC and BGL refer to each other. But, it is difficult to have those two containers in sync. So, I made another attempt to have MIC as customized vertex storage. I succeed two write the code for it (see it below). It also compiles and links :-). Unfortunately, I can not add neither vertices not edges. If I try to add vertex as in commeted code below, an error errors that there is no convertion from vertex property to vertex descriptor (error message is below). What's wrong? My another question is: how can I get access to my MIC stored in graph? I would like to use its indices. Best wishes, Alexander --------- sample code ----------- #include <iostream> #include <boost/multi_index_container.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/graph/adjacency_list.hpp> using namespace boost; using namespace boost::multi_index; using namespace std; struct MICSelector {}; struct Item { Item(int _a=0, int _b=0, int _c=0) : a(_a), b(_b), c(_c) {} int a,b,c; }; struct ItemHolder { ItemHolder(int id=0, const Item item=Item()) : m_ID(id), m_item(item) {} int m_ID; Item m_item; }; struct ItemHolderKey { typedef int result_type; int operator()(const ItemHolder& v) const { return v.m_ID; } }; template<class ValueType> struct MICWrapper { typedef multi_index_container < ValueType, indexed_by < ordered_unique< ItemHolderKey > > > type; }; namespace boost { // the specialization for your selector template<class ValueType> struct container_gen<MICSelector, ValueType> { typedef typename MICWrapper<ValueType>::type type; }; template <> struct parallel_edge_traits<MICSelector> { typedef allow_parallel_edge_tag type; }; }; typedef adjacency_list < listS, MICSelector, bidirectionalS, ItemHolder > MG; int tmain(int argc, char* argv[]) { MG mg; /* ItemHolder IH( 1, Item(1) ); add_vertex( &IH, mg ); // add_edge( // ItemHolder( 1, Item(1) ), // ItemHolder( 2, Item(2) ), // mg ); */ cout << typeid( boost::graph_traits<MG>::vertex_descriptor ).name(); return 0; } --------- sample code ----------- ----------- error message ------------- Compiling... MIC_BGL.cpp c:\test\MIC_BGL.cpp(87) : error C2664: 'boost::add_vertex' : cannot convert parameter 1 from 'ItemHolder *__w64 ' to 'const boost::detail::adj_list_gen<Graph,VertexListS,OutEdgeListS,DirectedS,VertexProperty,EdgeProperty,GraphProperty,EdgeListS>::config::vertex_property_type &' with [ Graph=boost::adjacency_list<boost::listS,MICSelector,boost::bidirectionalS,ItemHolder>, VertexListS=MICSelector, OutEdgeListS=boost::listS, DirectedS=boost::bidirectionalS, VertexProperty=boost::detail::retag_property_list<boost::vertex_bundle_t,ItemHolder>::type, EdgeProperty=boost::detail::retag_property_list<boost::edge_bundle_t,boost::no_property>::type, GraphProperty=boost::no_property, EdgeListS=boost::listS ] Reason: cannot convert from 'ItemHolder *__w64 ' to 'const boost::detail::adj_list_gen<Graph,VertexListS,OutEdgeListS,DirectedS,VertexProperty,EdgeProperty,GraphProperty,EdgeListS>::config::vertex_property_type' with [ Graph=boost::adjacency_list<boost::listS,MICSelector,boost::bidirectionalS,ItemHolder>, VertexListS=MICSelector, OutEdgeListS=boost::listS, DirectedS=boost::bidirectionalS, VertexProperty=boost::detail::retag_property_list<boost::vertex_bundle_t,ItemHolder>::type, EdgeProperty=boost::detail::retag_property_list<boost::edge_bundle_t,boost::no_property>::type, GraphProperty=boost::no_property, EdgeListS=boost::listS ] No constructor could take the source type, or constructor overload resolution was ambiguous ----------- error message ------------- __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250

6 5

[mpl]mpl::plus and non Integral Constants
by Andy Little 02 Feb '05

02 Feb '05

Reading the mpl documentation it states that boost::mpl::plus is expected to be specialised for non Integral Constants. Therefore should the following work ?: typedef boost::mpl::plus<int,int>::type int_plus_int_type; // eg int presumably OTOH it could be said that: mpl::plus<int_<1>, int_<1> >::type and mpl::plus<int,int>::type are conceptually different and that therefore mpl::plus<int,int> should be(remain) invalid. Any thoughts? regards Andy Little

3 2