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

Re: [Boost-users] [msm] EUML in a header file
by Nate Knight 12 May '11

12 May '11

Christophe Henry <christophe.j.henry <at> googlemail.com> writes: > > >Christophe Henry <christophe.j.henry <at> googlemail.com> writes: > > > >> You can also provide your own instances inside a front-end definition, > >> thus eliminating the problem completely, as in: > >> > >http://www.boost.org/doc/libs/1_46_0/libs/msm/doc/HTML/examples/SimpleTutor… > >> A couple more questions. I think you may be missing some more const specifiers in the trunk code. In common.hpp for instance, I think the following #define BOOST_MSM_EUML_EVENT(instance_name) \ struct instance_name ## _helper : msm::front::euml::euml_event<instance_name ## _helper>{ \ instance_name ## _helper(){} \ instance_name ## _helper const& operator()(){return *this;} }; \ instance_name ## _helper const instance_name = instance_name ## _helper(); should be #define BOOST_MSM_EUML_EVENT(instance_name) \ struct instance_name ## _helper : msm::front::euml::euml_event<instance_name ## _helper>{ \ instance_name ## _helper(){} \ instance_name ## _helper const& operator()() const {return *this;} }; \ instance_name ## _helper const instance_name = instance_name ## _helper(); If the operator() is not const then it can't be called on the defined instance. Also, the addition of "= instance_name ## _helper();" makes the macros unusable in class definitions since instance_name is not static.

1 0

[signals2] compilation issues with gcc4.4 and -pedantic
by Christophe Bourez 12 May '11

12 May '11

The following code: #include <boost/signals2.hpp> int main(int , char *[]) { return 0; } compiles fine with gcc-4.1 and gcc-4.2 and the -pedantic option, but generates the following errors using gcc-4.4 with the same compiling options: /home/build/repository/boost-1.46.1-2/gcc-4.4/include/boost/signals2/detail/preprocessed_arg_type_template.hpp:21: error: invoking macro BOOST_SIGNALS2_PREFIXED_ARGS_TEMPLATE_DECL argument 2: empty macro arguments are undefined in ISO C90 and ISO C++98 /home/build/repository/boost-1.46.1-2/gcc-4.4/include/boost/signals2/detail/preprocessed_arg_type_template.hpp:21: error: invoking macro BOOST_PP_CAT argument 1: empty macro arguments are undefined in ISO C90 and ISO C++98 /home/build/repository/boost-1.46.1-2/gcc-4.4/include/boost/signals2/detail/preprocessed_arg_type_template.hpp:21: error: invoking macro BOOST_PP_CAT_I argument 1: empty macro arguments are undefined in ISO C90 and ISO C++98 Adding the option -std=c++0x removes these errors, but I am supporting legacy code that does not compile with -std=c++0x Is there any workaround or patch I could apply ? Thank you, Christophe

3 3

Unwanted implicit conversions to bool
by Dominik Steenken 12 May '11

12 May '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everyone, i am having a bit of a problem using boost/hash in combination with boost/shared_ptr. Essentially, what i want when i hash a shared_ptr object is to hash the object it points to. So i wrote a template function to that effect, i.e. inline std::size_t hash_value(boost::shared_ptr<const IHashable> obj) { return obj->hash_value(); } where IHashable is an interface forcing the existence of the hash_value() function. Now i am getting compiler errors because apparently there is an implicit conversion to bool from boost::shared_ptr<T> and obviously there is a hash function for bool. Thus, something like boost::shared_ptr<IHashable> p(new something()); boost::hasher<something> hasher; std::size_t hash = hasher(p); is now ambiguous. I already found the BOOST_HASH_NO_IMPLICIT_CASTS switch, but it does not seem to change anything. I still get compiler errors like this one: In file included from /usr/include/boost/functional/hash/hash.hpp: 494:0, from /usr/include/boost/functional/hash.hpp:6, from types/../common.h:14, from types/variables.h:11, from types/abstractformula.h:11, from types/unaryoperations.h:11, from types/unaryoperations.cpp:1: types/unaryoperations.cpp:49:37: instantiated from here /usr/include/boost/functional/hash/extensions.hpp:176:34: error: call of overloaded ?hash_value(const boost::shared_ptr<terms::CAbstractFormula>&)? is ambiguous /usr/include/boost/functional/hash/hash.hpp:120:24: note: candidates are: size_t boost::hash_value(bool) types/../common.h:86:24: note: size_t terms::hash_value(boost::shared_ptr<const terms::IHashable>) Any idea on what i could to to prevent this would be greatly appreciated. cheers, Dominik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNy70+AAoJEPKXvh6MABK35dkQAKRFv48yZ7XyZh/6F+SSh02G IBfSEMi/xMXerLRH+/FV2lB6/gx1tymkYXxF02gopfIlavHHTWPz0vnkqZYFAABq ZzLMpggx4G50KtUGZfeKKfMGdbR5+0AHHT5ZRuL6aTzsvgr6nMYDdxwBKlAPvTJv nDuH8fHaV2QU6tw8OSmqzsdtiKrA4rnSqLPg4T6g/e/EqvH2Pf8GkXowRVK0T9Sq uAPnqcNZcMPuaIbtACC+AzsVA3CBw5fFQktRVbkLUtqDRVr10a9qOxgnDo6b7Duz c/KGNnWH2n1Lnwp9GbrvZoScqwThr9WqBvdcITD3ivgAkWhy5Fy6pnR1leRZhbZ7 +eFv3c1tY7b4yE7I9qCfRwW8LDhnkAJ/nAdcmGhWNX8RRSkETTguoCe9KUPMPoSs MBUEVk8VUNC9J3/JQmxlDhVju4WvJjlAnYrf7zir2XTFQ7v5eP86BeXkYArl+eyg OI2qRVp2ZuhReorwDc09Hef4/NrXPy3Bpq5nEWsref/mBbsyeopH3wqTZBrtruky RtSiJInhm4CETfMVJ8aJh/QO3MzGw2PXRLLCQ/mR2xHRgvEWOH53r84/1s8H3uSA URvXvPLKBuTpog30+GhHgfWOYx1/1Hy3atHbR9XikNW9y6Pv8IxUISA4AaQXNZyn XkjTDMHQ5XAqj/6Etgr7 =ak4K -----END PGP SIGNATURE-----

4 3

[Thread] Assert after reloading multiple times a .so linked with the static build of Boost.Thread
by Sorin Fetche 12 May '11

12 May '11

Hi, The attached test program shows that after a few hundred reloads of a shared library linked with the static build of Boost.Thread, an assert will be raised (gcc 4.4; boost 1.46.1). Does this show a valid bug in a supported usage pattern? ./a.out Call: 0 Call: 100 Call: 200 Call: 300 Call: 400 Call: 500 a.out: /home/sfetche/local/boost/src/boost_1_46_1/boost/thread/pthread/condition_variable_fwd.hpp:46: boost::condition_variable::~condition_variable(): Assertion `!pthread_mutex_destroy(&internal_mutex)' failed. Aborted The test program demonstrates the usage of a shared library that exposes a C interface and is implemented using statically linked Boost libraries. This approach has been taken in order to allow different modules using different versions of Boost to get (re)loaded in the same plugin-based application and has been inspired by this discussion: http://lists.boost.org/Archives/boost/2005/09/94134.php Thank you, Sorin Fetche

1 1

truncate file to n bytes
by Andrej van der Zee 12 May '11

12 May '11

Hi, I was wondering is there is any way to truncate the file-size to n bytes, while deleting from the end of the file? Does boost::filesystem support something like this? Thank you, Andrej

2 1

[boost::property_tree] how to put to paths with '/' slashes?
by Julien Claassen 12 May '11

12 May '11

Hello everyne! I'm just looking at the property_tree and wonder, if I can do something like this: ptree my_tree; my_tree.put('/',"/path/to/my.node","hello world"); The get functions support this syntax, but I didn't see anything corresponding to it with put ? Any ideas, workarounds? Kind regards and thanks Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

2 2

Re: [Boost-users] [msm] EUML in a header file
by Christophe Henry 12 May '11

12 May '11

>Christophe Henry <christophe.j.henry <at> googlemail.com> writes: > >> You can also provide your own instances inside a front-end definition, >> thus eliminating the problem completely, as in: >> >http://www.boost.org/doc/libs/1_46_0/libs/msm/doc/HTML/examples/SimpleTutor… >> >> Here the states and events could easily be move inside the front-end. >> It's actually my personal preference. >> > >That makes a lot of sense. I think I may prefer this approach as well, but >thanks for looking into the other issue anyway. > >Nate I forgot to add that you can of course mix. I often define my actions or simple events with the macros inside the front-end definition. Christophe

1 0

how to use no_init dijkstra
by Fletcher Foti 12 May '11

12 May '11

I'm really surprised I can't find information on this - I feel like I'm doing something very basic... What I want is all the nodes within a certain distance in the graph. I have a graph of half a million nodes and will only be visiting 20 or so - if you're curious, I have a graph of the street network in the Bay Area and will be looking at only those nodes within walking distance. So I read elsewhere that I need to inherit from default_dijkstra_visitor and throw an exception when I finalize a vertex beyond my search radius. I think I have this working. Now my problem is that I have to do this search many, many times - performance is very important - and I don't want to initialize the values for a half a million nodes when I'm only going to visit 20. I therefore want to use a std::map to store distances, and I want a key missing from that map to indicate an unvisited node, right? I also want to use dijkstra_shortest_path_no_init so as to skip initialization, but it's very hard to find documentation on this. I could post all my code here, but I'm not yet sure if that's the most efficient way to get my question answered. How does the no_init function work? Why doesn't it take a value for infinity? I feel like I need to pass DistanceMap.end() as my value for infinity so that a node not in the distance map looks like an unvisited node. Can anyone explain to me in words what I the no_init function expects me to pass to it? Thanks in advance! Fletcher

3 2

Polygon, accessing Points_Data
by AmandaLind 12 May '11

12 May '11

Greetings, This is my first post here. Please help me as I am stuck on how to access the points defining the new polygon generated with two other polygons and a boolean operation. I am having a hard time with using the iterators properly. The code runs well up to that point. Thanks in advance, ~Amanda namespace gtl = boost::polygon; using namespace boost::polygon::operators; using namespace gtl; //lets construct the two polygons typedef gtl::polygon_data Polygon; typedef gtl::polygon_traits::point_type Point; //Polygon1 Point pts1[numcorners1]; for (int index=0; index<numcorners1; index++) { pts1[index]=gtl::construct<Point>(rotated_corners1[index].x*1000, rotated_corners1[index].y*1000); } Polygon poly1; gtl::set_points(poly1, pts1, pts1+numcorners1); //Polygon 2 Point pts2[numcorners2]; for (int index=0; index<numcorners2; index++) { pts2[index]=gtl::construct<Point>(rotated_corners2[index].x*1000, rotated_corners2[index].y*1000); //mult by 1000 because it rounds to integers. } Polygon poly2; gtl::set_points(poly2, pts2, pts2+numcorners2); using namespace boost::polygon::operators; Polygon poly3; poly3 = poly1 & poly2; Point pts3[poly3.size()]; //how does one use iterators ?! std::vector<point_data<int> >::iterator itr ; itr= poly3.begin(); int index=0 for(itr; itr != ploy3.end(); ++itr) { pts3(index)=*itr; index++; } -- View this message in context: http://boost.2283326.n4.nabble.com/Polygon-accessing-Points-Data-tp3446015p… Sent from the Boost - Users mailing list archive at Nabble.com.

3 10

[MSM] event type change while using a direct entry
by Christophe Henry 11 May '11

11 May '11

> Dear list, > > while writing a state machine, I added an explicit_entry to my machine. My problem now is, if I want to write different function for different event types for the entry action like this: > template < class FSM> > void on_entry(event2 const& ev,FSM&fsm ){ … } > not all events were catched by it. After some compiling and generating an example, I know when the problem occurs. I am not sure if this is a bug or a feature ☺. It's a bug ;-) >The event for the explicit entry is wrapped with a direct_entry_event. If the transition is from outside the statemachine this is quite ok (I got the original event, not the direct_entry_event), but if >transition is inside the machine, the direct_entry_event is not removed and I got this to my on_entry. > > The example and the console output from the listing below show this effect. Is this a compiler problem or a problem/bug/feature coming from the msm? > > I am using a gcc 4.3.4 and boost 1.46.1 (trunk also shows this) > > Kind regards, > Sven Steckmann I fixed this in the trunk (rev. 71879). Please let me know if you have any problem with the fix. Thanks, Christophe

1 0