- Boost-users - lists.boost.org

boost::normal_distribution in boost 1.32
by Roman 21 Feb '05

21 Feb '05

Hi all. I observe boost::normal_distribution always return "nan" with all RNGs whereas other distributions behave normally. I'm talking about boost 1.32 - in earlier version boost::random has different interface.

2 2

Boost 1.32.0 and VS.NET 2005 under AMD64
by p.klotz＠icoserve.com 21 Feb '05

21 Feb '05

There exist a few problems when trying to compile Boost 1.32.0 under AMD64 with VS.NET 2005: * No toolset exists to compile Boost 1.32.0 native on the AMD64 platform (no cross compile). The attached file vc-8_0-amd64-tools.jam fixes that. * InterlockedExchange() in line 44 of lwm_win32.hpp collides with a macro of the same name in WinBase.h One finds in WinBase.h: #elif defined(_M_AMD64) && !defined(RC_INVOKED) ... #define InterlockedExchange _InterlockedExchange I changed the name of Boost's function to InterlockedExchangeBoost() to avoid this problem. * No type long_type exists when compiling with the Microsoft Compiler. The 64Bit part in lwm_win32.hpp seems to have been written for the Intel Compiler. An additional #ifdef now checks if the 64Bit compiler is from Intel or Microsoft. The InterlockedExchange() and long_type issues are fixed by boost_1_32_0-AMD64.patch. Maybe these changes can be integrated in some form in the next version of Boost. Best regards, Peter.

1 0

Creating a mst graph from another, undirected one
by aitor 21 Feb '05

21 Feb '05

Hello, i'm working with a (huge) undirected graph, with severeal internal properties in both vertices and edges, including weights. At one point, i compute the minumim spanning tree of the graph. The question is simple: how can i create another graph (a tree, so a directed graph) from the original undirected graph plus the list of edges conforming the mst ? And how can i do it _efficiently_ (considering that the original graph will be huge) ? Consider this seudo-code: #include <boost/graph/adjacency_list.hpp> #include <boost/graph/graph_traits.hpp> #include <boost/property_map.hpp> #include <boost/graph/properties.hpp> #include <boost/graph/kruskal_min_spanning_tree.hpp> typedef adjacency_list < boost::listS, boost::vecS, boost::undirectedS, VertexProperties, EdgeProperties> UGraph; typedef adjacency_list < boost::listS, boost::vecS, boost::directedS, VertexProperties, EdgeProperties> MSTree; void createGraph() { UGraph g; add_vertices(); add_edges(); compute_edges_weights(); vector<graph_traits<UGraph>::edge_descriptor> mst_edges(num_vertices(g)); kruskal_minimum_spanning_tree(g, back_inserter(mst_edges)); // At this point i want to create another graph of type MSTree from // g and mst_edges. How can i do it efficiently ? } thank you in advance aitor

2 5

Boost graph problem removing last vertex
by gast 128 21 Feb '05

21 Feb '05

Dear all, I have a graph, but when I remove the last vertex, the edge isn't removed. This can even lead to a crash. typedef boost::adjacency_list<boost::listS, boost::vecS, //or listS, same problem boost::directedS, boost::property<boost::vertex_index_t, int, boost::property<boost::vertex_name_t, std::string> > > GraphCrash; typedef boost::graph_traits<GraphCrash>::vertex_descriptor vertex_t; typedef boost::graph_traits<GraphCrash>::edge_descriptor edge_t; typedef boost::graph_traits<GraphCrash>::vertex_iterator vertex_iterator; typedef boost::graph_traits<GraphCrash>::edge_iterator edge_iterator; GraphCrash graph; //vertices vertex_t v1 = boost::add_vertex(graph); boost::put(boost::vertex_name, graph, v1, "v1"); vertex_t v2 = boost::add_vertex(graph); boost::put(boost::vertex_name, graph, v2, "v2"); //edges boost::add_edge(v1, v2, graph); //remove last vertex boost::remove_vertex(v2, graph); //should not give any edge, however...: std::pair<edge_iterator, edge_iterator> prEdges; for (prEdges = boost::edges(graph); prEdges.first != prEdges.second; ++prEdges.first) { const edge_t e = *prEdges.first; const vertex_t u = boost::source(e, rGraph); const vertex_t v = boost::target(e, rGraph); } Do I something wrong? I use vc++ 7.1. Wkr, me (btw entering this message through gmane, it bounces back, with error that is is a top posting. Strange...) _________________________________________________________________ Talk with your online friends with MSN Messenger http://messenger.msn.nl/

4 4

regex/string algorithm problem
by The Grumpiest Man You Know 21 Feb '05

21 Feb '05

Hi, I think this is a bug but I'm willing to believe I'm misusing something. As a side point, I'm unsure of how to choose the regex syntax. I think I use boost::regex::perl as the second argument to the constructor but I haven't had much look with either that or the char_classes value. Anyway for me the snippet below the ----s hangs in the second find_all_regex. Ok, it may not hang, it may be building up a nice big core to dump but I only leave it for 20 seconds or so. This started with me trying to use find_regex which segfaulted when I tried to increment the iterator for the first time. I thought that might be me so I tried the safer way of just asking someone else to do all the real work :). This might prompt calls of "known issue." if I haven't messed up. In which case would someone care to hit me with a clue stick as to how I should check before bugging the list? Thanks for your time. Using Debian unstable: ii libboost-regex 1.32.0-2 regular expression library for C++ ii libboost-regex 1.32.0-2 regular expression library for C++ which I'm pretty sure is one for the library and one for the dev headers but I'm a noob there too, so I could be wrong. The compiler is: $ g++ -v Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux Thread model: posix gcc version 3.3.5 (Debian 1:3.3.5-8) -------------- #include <string> #include <iostream> #include <boost/algorithm/string_regex.hpp> template<class T> std::ostream& operator<<(std::ostream& cout, const std::vector<T>& v) { std::copy(v.begin(), v.end(), std::ostream_iterator<T>(cout, " ")); return cout; } main() { std::string line1("word -opt 5 -opt 45M -flag word -flag -opt word"); typedef boost::find_iterator<std::string::iterator> fi; for (fi i = boost::make_find_iterator(line1, boost::first_finder("word", boost::is_equal())); ! i.eof(); ++i) { std::cout << boost::copy_iterator_range<std::string>(*i) << std::endl; } std::vector<std::string> result; boost::regex rx1(" [-a-z]*"); boost::find_all_regex(result, line1, rx1); std::cout << result.size() << result << std::endl; result.clear(); boost::regex rx2("[-a-z]*"); boost::find_all_regex(result, line1, rx2); std::cout << result.size() << result << std::endl; std::cout << line1 << std::endl; } -- Blue Skies

2 1

Errors in date_time module
by Markus Petermann 20 Feb '05

20 Feb '05

Hello! I tried to build the date_date libraries of Boost 1.31.0 with a gcc 2.95.2 compiler on a SuSE 7.0 Linux system. I discovered several problems: 1. Several header and source files try to include the sstream header file. This header is not available for gcc 2.95.2. I solved this problem by using #if defined(BOOST_NO_STRINGSTREAM) ... #else ... #endif constructions to include the correct header file and use the correct class. 2. In order to trigger the correct header file from error no. 1 the flag BOOST_NO_STRINGSTREAM must be set. This should be done by the config system (e.g. in boost/config/compiler/gcc.hpp). 3. I tried to include the date_time header files into a source file that also uses the Xerces library. This resulted in an error in file boost/date_time/gregorian_calendar.ipp, function gregorian_calendar_base<ymd_type_,date_int_type_>::day_number(const ymd_type& ymd) because of two + operators the compiler can use ( the buildin operator+(int, int) and second one from Xerces ). This error can be solved by doing a static cast to unsigned int for the three classes boost::gregorian::greg_year, greg_month and greg_day. The unsigned int operator is defined for all three classes. I have created two patch files for boost versions 1.31.0 and 1.32.0: http://home.arcor-online.de/markus.petermann/boost_1_31_0.patch http://home.arcor-online.de/markus.petermann/boost_1_32_0.patch Maybe these corrections can be considered for future releases. Best regards, Markus Petermann

4 5

RE: Program options: terminating parsing.
by The Grumpiest Man You Know 20 Feb '05

20 Feb '05

Since I might still be in the moderation queue I don't know how useful this is but ... Thanks for the ears :) I did infact make an object that changed the words to all be a dummy option and it seems to work fine. If there is a simple control I overlooked I'd be happy to hear about it but after sending the late night message and sleeping I think the solution I mumbled is quite fitting. -- Blue Skies

1 0

Singleton factories, shared_ptr, and serialization, oh my!
by Bill Lear 20 Feb '05

20 Feb '05

I have a long question on how to combine a Singleton factory, serialization, shared pointers and an object hierarchy half of which will be created by a factory, and half of which will not. I think solving this problem in an elegant way might be very useful for others, so if someone with more experience with these things could take the time to plough through this, we might get something that is very valuable to the rest of the community. I have a base class (Base) and several derived classes that fall into two categories: production classes that are created by a singleton factory, and test derived classes that are created "by hand" in test code: Base DerivedProductionA DerivedProductionB DerivedTestA DerivedTestB A Singleton factory is used to create "production" Base objects by examining a string key and available data on the file system. If certain conditions obtain, DerivedProductionA is created, otherwise DerivedProductionB is created, and the key used to create the object is used to set a property in the object so it "knows" its creation key. The created object is stored in a hash map by key and a reference (currently, a raw pointer, but I'm contemplating using shared_ptr) to the object is returned. The Base object is used by other objects that need to be serialized: class Thing { Base* my_base; template <class Archive> void save(Archive& ar, unsigned int) const { // TBD } template <class Archive> void load(Archive& ar, unsigned int) { // TBD } }; Currently, the save/load methods inspect the Base object's creation key. If the key is blank, the object is serialized directly (a test class). If the key is not blank, the creation key is serialized (thus, a "production" class). Before this is done, a boolean flag is serialized indicating that a creation key was used to store the object or the object itself was stored. This is it, in rough form: template <class Archive> void save(Archive& ar, unsigned int) const { bool flag = key.size() != 0; ar << flag; if (flag) { ar << my_base->key(); } else { ar << my_base; } } template <class Archive> void load(Archive& ar, unsigned int) { bool flag; ar >> flag; if (flag) { string key; ar >> key; my_base = Factory::create(key); } else { ar >> my_base; } } Now, this works just fine, but it is a bit inelegant (a friend calls this uninheritance). I would prefer to be able to encapsulate the logic of serialization in a separate class, something like this: class BaseHandle { Base* my_base; template <class Archive> void save(Archive& ar, unsigned int) const { // As above. } template <class Archive> void load(Archive& ar, unsigned int) { // As above. } }; Then, the Thing class, and any other class that would want to serialize a Base object would be straightforward: class Thing { Base* my_base; template <class Archive> void save(Archive& ar, unsigned int) const { ar << my_base; } template <class Archive> void load(Archive& ar, unsigned int) { ar >> my_base; } }; My question is: Has anyone else run across this type of pattern? I would prefer to use a shared pointer to the Base class throughout and to hide the constructors of all Base (and its derived classes), to force allocation of these objects through special static alloc methods that create shared_ptr-wrapped objects. My problem is I don't quite know how to combine all of these ideas. For example, using shared_ptr, class Thing would be quite simple: typedef shared_ptr<Base> BasePtr; class Thing { BasePtr my_base; template <class Archive> void save(Archive& ar, unsigned int) const { ar << my_base; } template <class Archive> void load(Archive& ar, unsigned int) { ar >> my_base; } }; However, now I've broken the previous work: I'd have to go back and put all of the serialization logic for factory construction back in the Thing class itself. If I try to combine all of this in the BaseHandle class, I run into difficulties: typedef shared_ptr<Base> BasePtr; class BaseHandle { BasePtr my_base; template <class Archive> void save(Archive& ar, unsigned int) const { bool flag = key.size() != 0; ar << flag; // Ok, now what? Do I just proceed as before and // pick up the pieces in the load method?? if (flag) { ar << my_base->key(); } else { ar << my_base; } } template <class Archive> void load(Archive& ar, unsigned int) { bool flag; ar >> flag; // Ok, now I know how my BasePtr was created: either // through the factory, or through the static alloc() method. // But, is the following appropriate? if (flag) { string key; ar >> key; my_base = Factory::create(key); } else { ar >> my_base; } } }; I tried sketching this out with BaseHandle inheriting from shared_ptr (don't even know if that's possible or at all advisable), which seemed to me to be the most elegant solution: typedef shared_ptr<Base> BasePtr; class BaseHandle : BasePtr { template <class Archive> void save(Archive& ar, unsigned int) const { bool flag = key.size() != 0; ar << flag; // Is this reasonable? Base* my_base = get(); if (flag) { ar << my_base->get(); } else { ar << my_base; } } template <class Archive> void load(Archive& ar, unsigned int) { bool flag; ar >> flag; // Oy, now what?? Base* my_base; if (flag) { string key; ar >> key; my_base = Factory::create(key); } else { ar >> my_base; } // OK, I've got Base* now, fully built. // how do I make "this" (shared_ptr) wrap // this?? // Do I do this? : *this = BasePtr(my_base); // or this??: reset(my_base); } }; If someone could help out here, I'd really appreciate it. Thanks. Bill

2 2

proposed modif for boost connection
by frantz.maerten＠igeoss.com 19 Feb '05

19 Feb '05

I took a look at libsidc++ and found very interresting the way of blocking/unblocking connections. I added some small modifications in boost::signals lib in order to have this functionality (2 patches in attachment to apply at the parent of the boost_1_32_0 distrib). Only the interface of connection has changed (3 new methods), and I added a boolean flag in basic_connection struct. So, my questions are: 1) is it interresting to incorporate it (for me, YES, it is veru useful)? 2) is it a safe implementation? You can test it like that: MySignal sig ; boost::signals::connection conn1 = sig.connect(&fct1) ; boost::signals::connection conn2 = sig.connect(&fct2) ; sig(10) ; // call fct1 and fct2 conn1.block() ; sig(20) ; // call only fct2 conn1.unblock() ; sig(30) ; // call fct1 and fct2

2 1

boost::fsm and templated states
by Jan Eickmann 19 Feb '05

19 Feb '05

Hi, I'm trying to get templated states to work with boost::fsm. Background is that I want to create an OptionsDialog I can show from different screens. So for now this works: template<class ParentState> class OptionsDialog : public boost::fsm::simple_state< OptionsDialog<ParentState>, ParentState, boost::mpl::list< boost::fsm::transition<EvOptionsExit, ParentState>, boost::fsm::custom_reaction<EvOptionsSound>, boost::fsm::custom_reaction<EvOptionsSoundExit> > > { //... }; This works perfectly so far. Now, what I want to do is have inside of the OptionsDialog substates (one for the sound-panel, one for video, etc.). This is my attempt so far: template <class Parent> class InnerInitial; template<class ParentState> class OptionsDialog : public boost::fsm::simple_state< OptionsDialog<ParentState>, ParentState, boost::mpl::list< boost::fsm::transition<EvOptionsExit, ParentState>, boost::fsm::custom_reaction<EvOptionsSound>, boost::fsm::custom_reaction<EvOptionsSoundExit> > >, InnerInitial< OptionsDialog<ParentState> { //... }; template <class Parent> class InnerInitial : public fsm::simple_state<InnerInitial<Parent>, Parent> { }; When trying to compile this (and of course using the OptionsDialog as a substate somewhere) I get the following compiler errors (sorry, I know it's long, but I couldn't make any sense of it so I don't know whats important). Could anyone shed some light on this? Thanks a lot, Jan Eickmann f:\xenocide\devpack.net2003\dependencies\include\boost\fsm\simple_state.hpp(191) : error C2039: 'inner_context_type' : is not a member of 'Xenocide::Client::UI::Common::OptionsDialog<ParentState>' with [ ParentState=Xenocide::Client::UI::Geoscape::PlanetviewState ] f:\xenocide\xenocide\src\client\ui\optionsdialog\optionsdialog.h(175) : see reference to class template instantiation 'boost::fsm::simple_state<MostDerived,Context>' being compiled with [ MostDerived=Xenocide::Client::UI::Common::InnerInitial<Xenocide::Client::UI::Common::OptionsDialog<Xenocide::Client::UI::Geoscape::PlanetviewState>>, Context=Xenocide::Client::UI::Common::OptionsDialog<Xenocide::Client::UI::Geoscape::PlanetviewState> ] f:\xenocide\devpack.net2003\dependencies\include\boost\mpl\aux_\has_tag.hpp(20) : see reference to class template instantiation 'Xenocide::Client::UI::Common::InnerInitial<Parent>' being compiled with [ Parent=Xenocide::Client::UI::Common::OptionsDialog<Xenocide::Client::UI::Geoscape::PlanetviewState> ] f:\xenocide\devpack.net2003\dependencies\include\boost\mpl\sequence_tag.hpp(112) : see reference to class template instantiation 'boost::mpl::aux::has_tag<T>' being compiled with [ T=Xenocide::Client::UI::Common::InnerInitial<Xenocide::Client::UI::Common::OptionsDialog<Xenocide::Client::UI::Geoscape::PlanetviewState>> ] f:\xenocide\devpack.net2003\dependencies\include\boost\mpl\begin_end.hpp(33) : see reference to class template instantiation 'boost::mpl::sequence_tag<Sequence>' being compiled with [ Sequence=Xenocide::Client::UI::Common::InnerInitial<Xenocide::Client::UI::Common::OptionsDialog<Xenocide::Client::UI::Geoscape::PlanetviewState>> ] f:\xenocide\devpack.net2003\dependencies\include\boost\mpl\is_sequence.hpp(94) : see reference to class template instantiation 'boost::mpl::begin<Sequence>' being compiled with [ Sequence=Xenocide::Client::UI::Common::InnerInitial<Xenocide::Client::UI::Common::OptionsDialog<Xenocide::Client::UI::Geoscape::PlanetviewState>> ] f:\xenocide\devpack.net2003\dependencies\include\boost\mpl\if.hpp(63) : see reference to class template instantiation 'boost::mpl::is_sequence<T>' being compiled with [ T=Xenocide::Client::UI::Common::InnerInitial<Xenocide::Client::UI::Common::OptionsDialog<Xenocide::Client::UI::Geoscape::PlanetviewState>> ] f:\xenocide\devpack.net2003\dependencies\include\boost\mpl\eval_if.hpp(40) : see reference to class template instantiation 'boost::mpl::if_<T1,T2,T3>' being compiled with [ T1=boost::mpl::is_sequence<Xenocide::Client::UI::Common::InnerInitial<Xenocide::Client::UI::Common::OptionsDialog<Xenocide::Client::UI::Geoscape::PlanetviewState>>>, T2=boost::mpl::identity<Xenocide::Client::UI::Common::InnerInitial<Xenocide::Client::UI::Common::OptionsDialog<Xenocide::Client::UI::Geoscape::PlanetviewState>>>, T3=boost::mpl::identity<boost::mpl::list<Xenocide::Client::UI::Common::InnerInitial<Xenocide::Client::UI::Common::OptionsDialog<Xenocide::Client::UI::Geoscape::PlanetviewState>>>> ] f:\xenocide\devpack.net2003\dependencies\include\boost\fsm\simple_state.hpp(71) : see reference to class template instantiation 'boost::mpl::eval_if<C,F1,F2>' being compiled with [ C=boost::mpl::is_sequence<Xenocide::Client::UI::Common::InnerInitial<Xenocide::Client::UI::Common::OptionsDialog<Xenocide::Client::UI::Geoscape::PlanetviewState>>>, F1=boost::mpl::identity<Xenocide::Client::UI::Common::InnerInitial<Xenocide::Client::UI::Common::OptionsDialog<Xenocide::Client::UI::Geoscape::PlanetviewState>>>, F2=boost::mpl::identity<boost::mpl::list<Xenocide::Client::UI::Common::InnerInitial<Xenocide::Client::UI::Common::OptionsDialog<Xenocide::Client::UI::Geoscape::PlanetviewState>>>> ] f:\xenocide\devpack.net2003\dependencies\include\boost\fsm\simple_state.hpp(82) : see reference to class template instantiation 'boost::fsm::detail::make_list<T>' being compiled with [ T=Xenocide::Client::UI::Common::InnerInitial<Xenocide::Client::UI::Common::OptionsDialog<Xenocide::Client::UI::Geoscape::PlanetviewState>> ] f:\xenocide\devpack.net2003\dependencies\include\boost\fsm\simple_state.hpp(191) : see reference to class template instantiation 'boost::fsm::detail::simple_state_base_type<MostDerived,Context,InnerInitial>' being compiled with [ MostDerived=Xenocide::Client::UI::Common::OptionsDialog<Xenocide::Client::UI::Geoscape::PlanetviewState>, Context=boost::fsm::simple_state<Xenocide::Client::UI::Geoscape::PlanetviewState,Xenocide::Client::UI::RunningGameState,boost::mpl::list<boost::fsm::custom_reaction<Xenocide::Client::UI::Geoscape::EvXNet>,boost::fsm::custom_reaction<Xenocide::Client::UI::Geoscape::EvOptions>,boost::fsm::custom_reaction<Xenocide::Client::UI::Common::EvOptionsAbandonGame>>,Xenocide::Client::UI::Geoscape::PlanetviewNoOpInnerInitial,has_no_history>::inner_context_type, InnerInitial=Xenocide::Client::UI::Common::InnerInitial<Xenocide::Client::UI::Common::OptionsDialog<Xenocide::Client::UI::Geoscape::PlanetviewState>> ] f:\xenocide\xenocide\src\client\ui\optionsdialog\optionsdialog.h(57) : see reference to class template instantiation 'boost::fsm::simple_state<MostDerived,Context,Reactions,InnerInitial>' being compiled with [ MostDerived=Xenocide::Client::UI::Common::OptionsDialog<Xenocide::Client::UI::Geoscape::PlanetviewState>, Context=Xenocide::Client::UI::Geoscape::PlanetviewState, Reactions=boost::mpl::list<boost::fsm::transition<Xenocide::Client::UI::Common::EvOptionsExit,Xenocide::Client::UI::Geoscape::PlanetviewState>,boost::fsm::custom_reaction<Xenocide::Client::UI::Common::EvOptionsSound>,boost::fsm::custom_reaction<Xenocide::Client::UI::Common::EvOptionsSoundExit>>, InnerInitial=Xenocide::Client::UI::Common::InnerInitial<Xenocide::Client::UI::Common::OptionsDialog<Xenocide::Client::UI::Geoscape::PlanetviewState>> ] f:\xenocide\devpack.net2003\dependencies\include\boost\fsm\simple_state.hpp(693) : see reference to class template instantiation 'Xenocide::Client::UI::Common::OptionsDialog<ParentState>' being compiled with [ ParentState=Xenocide::Client::UI::Geoscape::PlanetviewState ] f:\xenocide\devpack.net2003\dependencies\include\boost\fsm\simple_state.hpp(303) : see reference to function template instantiation 'boost::fsm::result boost::fsm::simple_state<MostDerived,Context,Reactions,InnerInitial,historyMode>::transit_impl<DestinationState,MostDerived,boost::fsm::detail::no_transition_function>(const TransitionAction &)' being compiled with [ MostDerived=Xenocide::Client::UI::Geoscape::PlanetviewState, Context=Xenocide::Client::UI::RunningGameState, Reactions=boost::mpl::list<boost::fsm::custom_reaction<Xenocide::Client::UI::Geoscape::EvXNet>,boost::fsm::custom_reaction<Xenocide::Client::UI::Geoscape::EvOptions>,boost::fsm::custom_reaction<Xenocide::Client::UI::Common::EvOptionsAbandonGame>>, InnerInitial=Xenocide::Client::UI::Geoscape::PlanetviewNoOpInnerInitial, historyMode=has_no_history, DestinationState=Xenocide::Client::UI::Common::OptionsDialog<Xenocide::Client::UI::Geoscape::PlanetviewState>, TransitionAction=boost::fsm::detail::no_transition_function ] f:\xenocide\xenocide\src\client\ui\planetview\planetview.cpp(371) : see reference to function template instantiation 'boost::fsm::result boost::fsm::simple_state<MostDerived,Context,Reactions,InnerInitial,historyMode>::transit<Xenocide::Client::UI::Common::OptionsDialog<ParentState>>(void)' being compiled with [ MostDerived=Xenocide::Client::UI::Geoscape::PlanetviewState, Context=Xenocide::Client::UI::RunningGameState, Reactions=boost::mpl::list<boost::fsm::custom_reaction<Xenocide::Client::UI::Geoscape::EvXNet>,boost::fsm::custom_reaction<Xenocide::Client::UI::Geoscape::EvOptions>,boost::fsm::custom_reaction<Xenocide::Client::UI::Common::EvOptionsAbandonGame>>, InnerInitial=Xenocide::Client::UI::Geoscape::PlanetviewNoOpInnerInitial, historyMode=has_no_history, ParentState=Xenocide::Client::UI::Geoscape::PlanetviewState ] f:\xenocide\devpack.net2003\dependencies\include\boost\fsm\simple_state.hpp(191) : error C2146: syntax error : missing ',' before identifier 'inner_context_type' f:\xenocide\devpack.net2003\dependencies\include\boost\fsm\simple_state.hpp(191) : error C2065: 'inner_context_type' : undeclared identifier f:\xenocide\devpack.net2003\dependencies\include\boost\fsm\simple_state.hpp(191) : error C2976: 'boost::fsm::detail::simple_state_base_type' : too few template arguments f:\xenocide\devpack.net2003\dependencies\include\boost\fsm\simple_state.hpp(99) : see declaration of 'boost::fsm::detail::simple_state_base_type' f:\xenocide\devpack.net2003\dependencies\include\boost\fsm\simple_state.hpp(191) : error C2955: 'boost::fsm::detail::simple_state_base_type' : use of class template requires template argument list f:\xenocide\devpack.net2003\dependencies\include\boost\fsm\simple_state.hpp(99) : see declaration of 'boost::fsm::detail::simple_state_base_type' f:\xenocide\devpack.net2003\dependencies\include\boost\fsm\simple_state.hpp(191) : error C2955: 'boost::fsm::detail::simple_state_base_type' : use of class template requires template argument list f:\xenocide\devpack.net2003\dependencies\include\boost\fsm\simple_state.hpp(99) : see declaration of 'boost::fsm::detail::simple_state_base_type' f:\xenocide\devpack.net2003\dependencies\include\boost\fsm\simple_state.hpp(192) : fatal error C1903: unable to recover from previous error(s); stopping compilation xnet.cpp

5 9