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

Re: [Boost-users] Using multiple versions/targets of Boost
by Staal, J.J. (Joes) 02 Mar '06

02 Mar '06

> > It should... Did you use "-sTOOLS=vc-8_0" both times? As that's what > > it uses to determine the "vc80" tag. I had a similar problem, until I found out that I made an error. I used -"sTOOLS=vc-8_0" instead of "-sTOOLS=vc-8_0" (notice the location of the first minus sign). Joes. This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html

2 1

Using multiple versions/targets of Boost
by Mateusz Łoskot 02 Mar '06

02 Mar '06

Hi, I have VC++ 7.1 and VC++ 8.0 installed on my laptop. I'd like to use Boost with both VC++. So, as I understand I need to build Boost twice, with VC++ 7.1 and with VC++ 8.0. Documentation does not say anything about such case. Now, the question is, should I install both targets to separate directories (different --prefix, e.g. C:\Boost-vc-8.0 and C:\Boost-vc-7.1) or can I install then in common dir C:\Boost ? AFAIK, libs names include toolset name e.g. libboost_date_time-vc71-mt-gdp.lib ^^^^^ So, I suppose I can install both targets into common place and I'll have following files in C:\Boost\lib: libboost_date_time-vc71-mt-gdp.lib and libboost_date_time-vc80-mt-gdp.lib Are my assumptions correct? Or it's more recommended to install separate targets (builds made with different toolsets) to separate folders? Thanks in advance Best regards -- Mateusz Łoskot http://mateusz.loskot.net

4 6

Re: [Boost-users] Serialization: docs regarding abstract base class
by RIVASSEAU Jean Noel 02 Mar '06

02 Mar '06

Since the demo doesn't use BOOST_EXPORT, I suspect that that there is some sort of problem related to instantiation of abstract base class code for exported types. I'lll look into it. If you can look into it, thank you, Robert. I have finished the organization of my (big) project serialization into separate files for each class, and now everything is working fine ! :) However, I still have the problem that every time I use a std::vector of pointers, and serialize it as such, there is a compile time error, since extended_type_info for the std::vector is not defined. This is a bug since type info should not matter here. My workaround was to use a BOOST_CLASS_TYPE_INFO(std::vector< ClassPointedTo *>, extended_type_info_no_rtti< std::vector< ClassPointedTo *> >) everytime such a vector occurs. However, if you can look into this problem and fix it, Robert, this would appreciated. I could then remove my workaround code, which makes my code ugly :) Jean-Noël -----Message d'origine----- De : boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] De la part de Robert Ramey Envoyé : jeudi 2 mars 2006 03:49 À : boost-users(a)lists.boost.org Objet : Re: [Boost-users] Serialization: docs regarding abstract base class Note that the tutorial programs do use BOOST_IS_ABSTRACT so I've always assumed that it functions as advertised. Since the demo doesn't use BOOST_EXPORT, I suspect that that there is some sort of problem related to instantiation of abstract base class code for exported types. I'lll look into it. Robert Ramey "RIVASSEAU Jean Noel" <JN.RIVASSEAU(a)oberthurcs.com> wrote in message news:87F60F7FA02FF749AFB02BD9FCAA6B04DE1BE3@naserv31.nanterre.oberthurcs.com... I quote the Boost serialization docs: When serializing an object through a pointer to its base class and that base class is abstract (i.e. has at least one virtual function assigned a value of 0), A compile error will be emitted. This is addressable in one over several ways: remove the =0 in the base classes so that the base class is no longer abstract. implement is_abstract for your compiler. (code written according to the C++ standard is included with this library. But it is known to fail on several compilers. If the compiler suports "is_abstract" type trait - use that. Otherwise assume a class is NOT abstract unless BOOST_IS_ABSTRACT has been set for the class. use the macro BOOST_IS_ABSTRACT(my_class) to indicate that the class is an abstract base class. This will cause the compiler to avoid generating code that causes this error. I still do not understand part 2 of this advice, Robert. Could you explain? Jean-Noël Ps: as already mentioned, part 3 does not change anything for me, and I'd like to avoid the solution of part 1 since I do want the base class to be abstract. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Can't statically link demo program with Boost.Serialization 1.33
by Demos Rali 02 Mar '06

02 Mar '06

Hello, I am having difficulties statically compiling the demo program at http://www.boost.org/libs/serialization/example/demo.cpp on Linux (Linux 2.6.15-1.1831_FC4 #1 SMP Tue Feb 7 13:37:59 EST 2006 x86_64 GNU/Linux) with gcc version 4.0.2 20051125. When I try: g++ -o demo -I /path/boost/ -L /path/boost/ -lboost_serialization demo.cpp it works fine, but I get a program which needs dynamic versions of the serialization library. However, I would like to compile against the static versions of the Boost.Serialization library. If I try g++ -static -o demo -I /path/boost/ -L /path/boost/ -lboost_serialization demo.cpp the linker complains of a lot of undefined references, like /tmp/ccFAJsqB.o(.gnu.linkonce.r._ZTIN5boost13serialization16void_cast_detail21void_caster_primitiveIK20bus_stop_destinationK8bus_stopEE[typeinfo for boost::serialization::void_cast_detail::void_caster_primitive<bus_stop_destination const, bus_stop const>]+0x10): undefined reference to `typeinfo for boost::serialization::void_cast_detail::void_caster' ... I have no difficulties when statically linking against other boost libraries. I built the librairies with gcc, with no exotic options. Any suggestions would be greatly appreciated. Thanks a lot. Fabrizio

2 1

Serialization: docs regarding abstract base class
by RIVASSEAU Jean Noel 02 Mar '06

02 Mar '06

I quote the Boost serialization docs: When serializing an object through a pointer to its base class and that base class is abstract (i.e. has at least one virtual function assigned a value of 0), A compile error will be emitted. This is addressable in one over several ways: * remove the =0 in the base classes so that the base class is no longer abstract. * implement is_abstract for your compiler. (code written according to the C++ standard is included with this library. But it is known to fail on several compilers. * use the macro BOOST_IS_ABSTRACT(my_class) to indicate that the class is an abstract base class. This will cause the compiler to avoid generating code that causes this error. I still do not understand part 2 of this advice, Robert. Could you explain? Jean-Noël Ps: as already mentioned, part 3 does not change anything for me, and I'd like to avoid the solution of part 1 since I do want the base class to be abstract.

3 2

Re: [Boost-users] Boost thread questions
by Merrill Cornish 01 Mar '06

01 Mar '06

Hector, >>> how to lock a file (fstream) for reading/writing Are you trying to lock the _file_ on disk for all applications running on the system? Or, are you trying to lock a stream opened to that file for different threads in your application? In the first case, you need to use an OS-level lock, not Boost. In the second case, use a mutex as someone else suggested. Merrill

1 0

[statechart] Template States, Compile Error
by David Greene 01 Mar '06

01 Mar '06

The attached testcase doesn't compile with g++ 4.0.2 or g++ 3.2.3. The compiler generates a series of error messages like this: boost/statechart/simple_state.hpp:189: error: no type named 'inner_context_type' in 'struct Test::NormalMode<int>' I hastily sketched this out based on a larger code. If there are typos or other mistakes, let me know but the main problem I'm trying to solve is the "no type named" problem. I typedef it right in the template definition for NormalMode! This is using the current CVS for statechart, 1.33.1 for mpl. Is it possibly a compiler bug? Thanks! -Dave ---------------- Testcase #include <boost/statechart/state_machine.hpp> #include <boost/statechart/simple_state.hpp> #include <boost/statechart/event.hpp> #include <boost/statechart/custom_reaction.hpp> #include <boost/statechart/state.hpp> #include <boost/statechart/transition.hpp> #include <boost/mpl/list.hpp> #include <iostream> // Switch finite state machine for multiplexor schedule policy namespace Test { namespace sc = boost::statechart; namespace mpl = boost::mpl; // Inner states template <typename Type> struct On; template <typename Type> struct Off; template <typename Type> struct Error; // Outer states template <typename Type> struct NormalMode; template <typename Type> struct ErrorMode; // Events struct End : public sc::event<End> {}; struct UnconsumedEvent : public sc::event<UnconsumedEvent> { std::string st; UnconsumedEvent(const std::string &s) : st(s) {}; const std::string &state(void) const { return(st); }; }; template<typename Derived, typename Type> struct SwitchEvent : public sc::event<Derived> { typedef Type value_type; value_type ev; SwitchEvent(value_type e) : ev(e) {}; value_type value(void) const { return(ev); } }; template<typename Type> struct TurnOn : public SwitchEvent<TurnOn<Type>, Type> { TurnOn(Type value) : SwitchEvent<TurnOn<Type>, Type>(value) {}; }; template<typename Type> struct TurnOff : public SwitchEvent<TurnOff<Type>, Type> { TurnOff(Type value) : SwitchEvent<TurnOff<Type>, Type>(value) {}; }; template<typename Type> struct Switch; namespace detail { template<typename Type> struct typedefs { typedef Type value_type; typedef Switch<value_type> switch_context; typedef TurnOn<value_type> turn_on; typedef TurnOff<value_type> turn_off; typedef On<value_type> on; typedef Off<value_type> off; }; }; // The state machine template<typename Type> struct Switch : public sc::state_machine<Switch<Type>, NormalMode<Type> >, public detail::typedefs<Type> { typedef sc::state_machine<Switch<Type>, NormalMode<Type> > Base; typedef Switch<Type> This; std::string state(void) const { if (this->template state_cast<const typename This::on *>()) { return("ON"); } else if (this->template state_cast<const typename This::off *>()) { return("OFF"); } else { std::cerr << "Unknown state" << std::endl; std::abort(); return("ERROR"); } }; // Abort on unexpected events void unconsumed_event(const sc::event_base &event) { std::cerr << "Unexpected event in state " << state() << std::endl; std::abort(); this->post_event(new UnconsumedEvent(state())); }; }; // Define states // Outer template<typename Type> struct NormalMode : public sc::simple_state<NormalMode<Type>, Switch<Type>, Off<Type> >, public detail::typedefs<Type> { typedef sc::simple_state<NormalMode<Type>, Switch<Type>, Off<Type> > state_base; typedef typename state_base::inner_context_type inner_context_type; }; template<typename Type> struct ErrorMode : public sc::simple_state<ErrorMode<Type>, Switch<Type>, Error<Type> >, public detail::typedefs<Type> { typedef sc::simple_state<ErrorMode<Type>, Switch<Type>, Error<Type> > state_base; typedef typename state_base::inner_context_type inner_context_type; }; // Inner template<typename Type> struct Off : public sc::simple_state<Off<Type>, NormalMode<Type> >, public detail::typedefs<Type> { typedef Off<Type> This; typedef mpl::list< sc::custom_reaction<typename This::on>, sc::custom_reaction<End> > reactions; sc::result react(const typename This::on &) { this->template context<typename This::switch_context>().transit("OFF", "ON"); return(this->template transit<typename This::on>()); }; sc::result react(const End &) { this->terminate(); }; }; template<typename Type> struct On : public sc::simple_state<On<Type>, NormalMode<Type> >, public detail::typedefs<Type> { typedef On<Type> This; typedef mpl::list< sc::custom_reaction<typename This::off>, sc::custom_reaction<End> > reactions; sc::result react(const typename This::off &) { this->template context<typename This::switch_context>().transit("ON", "OFF"); return(this->template transit<typename This::off>()); }; sc::result react(const End &) { this->terminate(); }; }; template<typename Type> struct Error : sc::simple_state<Error<Type>, ErrorMode<Type> >, public detail::typedefs<Type> { }; }; int main(void) { Test::Switch<int> machine; machine.initiate(); machine.process_event( Test::TurnOn<int>(0) ); std::cout << "Now in state " << machine.state() << std::endl; machine.process_event( Test::TurnOff<int>(0) ); std::cout << "Now in state " << machine.state() << std::endl; machine.process_event( Test::TurnOff<int>(0) ); // Should produce error std::cout << "Now in state " << machine.state() << std::endl; machine.process_event( Test::End() ); }

3 8

Re: [Boost-users] [iostreams] array_sink
by EMalenfant＠interstarinc.com 01 Mar '06

01 Mar '06

From: Jeff Flinn [mailto:TriumphSprint2000@hotmail.com] > > My reading of the docs states that array_sink models the > concept sink, meaning that the following should compile: > [snip] > > io::array_sink lSink(x,4); > > const char* y = "abc"; > > io::write( lSink, y, 4 ); [snip] > > I must be doing something obviously wrong, on VC7.1 I get: > > c:\boost\boost_1_33_1\boost\iostreams\write.hpp(118) : error > C2039: 'write' > : is not a member of 'boost::iostreams::basic_array_sink<Ch>' [snip] Hi Jeff, I think this is related to the fact that array_sink is a "direct" sink. At the bottom of this page: http://www.boost.org/libs/iostreams/doc/?path=4.1.1.7 there is mention that "io::write()" is subject the the precondition that the sink is *not* convertible to "direct_tag". BTW, in the "details" of the iostreams library, there is a "direct_adapter" which seems to allow one to expose a "direct" Device as an "indirect" one. HTH, Éric Malenfant

2 1

Re: [Boost-users] [mpl] newbie question
by james.jones＠firstinvestors.com 01 Mar '06

01 Mar '06

Andy Little wrote: > Of course If anyone can implement the dimensional-analysis part of pqs > (in the Boost vault in The Physical Quantities Units directory) , such > that it compiles faster than it does currently, by using mpl, then I > will be happy to re-implement it using mpl. If I recall previous posts correctly, the compile-time using MPL was 30 seconds, and using your own code 4 seconds. Is this really a good reason not to use MPL? I would understand if it were 30 *minutes* versus 4 seconds. But in this case you're gaining 26 seconds per compile at the price of writing some custom code that may or may not be as maintainable as MPL (not saying it isn't - I haven't looked at pqs). I think in general it's understood that C++ in general, and BOOST in particular, can tend to increase compile times, because they heavily invest in compile-time template logic. But as I see it, an extra 26 seconds per compile times, say, 1000 compilations (to be generous) on a given project, is about one man-day (really less: it's 7-1/4 hours; how many of us put in only that much in a given workday?). Do you think it takes less than a man-day to come up with an MPL replacement, even one that only handles a subset of the functionality? Maybe, but I think there's reason to be skeptical. Also, if MPL resulted in a 7-times slower *runtime* than custom code, then choosing not to use might make more sense. Is that the case? If so, I missed it. Anyway, not saying you made the wrong decision, just offering a possible alternative way to think about this. - James

2 1

Re: [Boost-users] [BGL] Dijkstra Shortest Paths
by Michael Kettner 01 Mar '06

01 Mar '06

Hi Marcio! On Wednesday 29 March 2006 14:43, Marcio Paim de Aquino wrote: > Hello all, > > does anyone know how to make a custom dijkstra visitor that ends the > algorithm when > it finds the path between two especified vertexes? You might read the manual. This is from http://www.boost.org/libs/graph/doc/faq.html How do I perform an early exit from an algorithm such as BFS? Create a visitor that throws an exception when you want to cut off the search, then put your call to breadth_first_search inside of an appropriate try/catch block. This strikes many programmers as a misuse of exceptions, however, much thought was put into the decision to have exceptions has the preferred way to exit early. See boost email discussions for more details. Regards, Michael > Thanks, > > Marcio

2 1