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

[BGL] Dijkstra Shortest Paths
by Marcio Paim de Aquino 01 Mar '06

01 Mar '06

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? Thanks, Marcio

1 0

Re: [Boost-users] problem with serialization of pure virtual
by Nat Goodspeed 01 Mar '06

01 Mar '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Tobias Combe > Sent: Tuesday, February 28, 2006 7:18 AM > To: boost-users(a)lists.boost.org > Subject: [Boost-users] problem with serialization of pure virtual > > When i use "ar.register<derived>();" in the template of the base-class > to register the derived classes, i get a syntax error. [Nat] What compiler are you using?

2 1

serialization: found a (satisfactory) way to avoid the abstract class problem linking problem
by RIVASSEAU Jean Noel 01 Mar '06

01 Mar '06

Hello Robert, I found a way to avoid the link problem when dealing with a base abstract class, that maintains the base class abstract : I just manually instantiated the save/load functions for the abstract base class. They should have been instantiated by BOOST_CLASS_EXPORT, but this apparently does not work with abstract base classes; however manual instantiation works just fine. So I now have only one more problem (unfortunately, very serious), that happens with the serialization of std::vector containing pointers. Jean-Noël

1 0

What can I do after I finished all the steps of "getting started" ?
by 郭华长 01 Mar '06

01 Mar '06

thanks _________________________________________________________________ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn

1 0

Re: [Boost-users] serialization: errata: even manual instantiationisimpossible
by RIVASSEAU Jean Noel 01 Mar '06

01 Mar '06

// my_class_serialization.cpp or my_class.cpp or .. *.cpp #include <boost/archive/xml_iarchive.hpp> .... // all archives you might whant to use here. template<class Archive> serialize(Archive &ar, my_class &t....){ ... serialization for class my_class } #include "my_class.hpp" // explict instantiation here for all the archives which interest me template void serialize<boost::archive::xml_iarchive, my_class>; ... // explicit instantiation for all other archives you might use here. I notice you still include the archive headers in my_class_serialization.cpp. In that case, you do not have in fact to manually instantiate templates, since my_class_serialization.cpp includes "my_class.hpp" which includes export.hpp and maybe BOOST_CLASS_EXPORT after the archive headers included in class_serialization.cpp, so template instantiation will occure anyway. Anyway let's close this topic. I understood what the point was. Jean-Noël

1 0

Re: [Boost-users] Serialization : unregistered_cast & otherquestions
by RIVASSEAU Jean Noel 01 Mar '06

01 Mar '06

This is true. But this is a minor in my opinion. The root cause of this situation is that linkers complain about multiply defined functions - even when those functions are identical. Maybe someday we'll have smarter linkers - but until then this works quite well. It does require that one spend a little time explicitly considering code instantiation. But this isn't necessarily bad. Letting the compile/linker do all the work will lead to code bloat and compilation time problems. I definitely agree with you - smarter linkers would be a big gift. Right now dealing with templates is generally a pain because of linker issues, and requires that one takes a lot of precaution to insure everything compiles/links smoothly. I had the same problems when using the BGL last year, and also had to resort to manual template instantiation in the end. Jean-Noël

1 0

[iostreams] array_sink
by Jeff Flinn 28 Feb '06

28 Feb '06

My reading of the docs states that array_sink models the concept sink, meaning that the following should compile: #include <boost/iostreams/device/array.hpp> #include <boost/iostreams/operations.hpp> namespace io = boost::iostreams; int main( int argc, char* argv[] ) { char x[4] = {}; io::array_sink lSink(x,4); const char* y = "abc"; io::write( lSink, y, 4 ); return 0; } 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>' with [ Ch=char ] c:\boost\boost_1_33_1\boost\iostreams\write.hpp(52) : see reference to function template instantiation 'std::streamsize boost::iostreams::detail::write_device_impl<boost::iostreams::output>::write<boost::unwrap_reference<T>::type>(T &,const boost::iostreams::detail::member_char_type<T>::type *,std::streamsize)' being compiled with [ T=boost::iostreams::array_sink ] c:\dev\AAA - Advantage New\DasNew\DasClientTest\DasClientTest.cpp(36) : see reference to function template instantiation 'std::streamsize boost::iostreams::write<boost::iostreams::array_sink>(T &,const boost::iostreams::detail::member_char_type<T>::type *,std::streamsize)' being compiled with [ T=boost::iostreams::array_sink ] Any thoughts are appreciated. Thanks, Jeff

1 0

Re: [Boost-users] [mpl] newbie question
by Gottlob Frege 28 Feb '06

28 Feb '06

Top posting because I'm going to remark about this thread in general, but this message is a fine example. Andy seems to be speaking (mostly) about int_<>, integral_c, etc (I'll just say the incorrect 'int<>') and plus; David is talking about transform. I think, but can't say for sure, that Andy wants plus to work 'as expected' and always return int<>, not just 'concept-identical' to int. Maybe it does, I'm not sure. And/or he wants transform ***when applied to int<> with plus, etc*** to return int<>. David, says, that ***in general*** transform can't make the return type "match" (in Andy's stricter sense) the inputs. Maybe it could for the special case of int<>? IMO, that would be quite hard, as the point of the templates is to be general. Do I have this right, in any sense? P.S. for David, below: Date: Sat, 25 Feb 2006 10:22:57 -0500 > From: David Abrahams <dave(a)boost-consulting.com> > Subject: Re: [Boost-users] [mpl] newbie question > To: boost-users(a)lists.boost.org > Message-ID: <uoe0v799q.fsf(a)boost-consulting.com> > Content-Type: text/plain; charset=us-ascii > > "Andy Little" <andy(a)servocomm.freeserve.co.uk> writes: > > > I think we need a little bit more context here. > > > >> > > OP > >>> David Abrahams > >> > >> Andy Little (me) > >> > >> > > Just trying to use mpl::transform on a vector of int's and I can't > seem to > >> > > get > >> > > it working properly. Can anyone see what's wrong?? I'm trying to > perform > >> > > > >> > > vector_c<int, 1, 2, 3> + vector_c<int, 1, 1, 1> = vector_c<int, 2, > 3 ,4> > >> > > > >> > > The is_same function always returns false when I compile and run > it. > >> > > >> > The result of the transform is only required to be > "concept-identical" the line above says "the transform" >> > to the result you're looking for. > >> > > >> IMO that behaviour is sloppy. I see no reason why (at least) > >> > >> boost::is_same < plus< int_<1> ,int_<1> >::type, int_<2> > shouldnt > >> be true. > > > > Your change from "the transform" to "being about transform" above is > > problematic for me. I don't know what you mean. Nobody wrote "the transform" above. as mentioned, he did, but that doesn't mean I understand the point he is trying to make. Don't make this complicated. It is very simple: I made a statemnt > *about the behavior of transform*, and you replied "that behavior is > sloppy," and then proceeded to go on about something only distantly > related (the type of results of arithmetic operations). > > The behavior I was describing is not sloppy. To make the library > behave differently would introduce a huge overhead in implementation > code that is more likely than not to slow down compilation of user > programs. > > Let me be a little more explicit: > > transform<vector_c<int, ...> >::type > > is likely to be a specialization of vectorN where N is a numeral. > Therefore, testing it against a vector_c specialization using is_same > will always fail. That is the behavior I was referring to. > > I wouldn't care much what you said, except for that you're doing this > in a thread where impressionable "newbies" are reading, and I don't > want them to misunderstand the library design or the implementation > decisions and their costs/benefits. Your statement above not only > unfairly maligns Aleksey's work, it is misleading. > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > >

3 7

Re: [Boost-users] problem with serialization of pure virtual
by RIVASSEAU Jean Noel 28 Feb '06

28 Feb '06

You should send a code snippet. What are the syntax error you get, and the error you get when doing a "BOOST_CLASS_EXPORT(derived);" ? I also have a problem with an abstract base class (although at link time, not compile time). Try removing the pure virtual function (just to see if it works). Another hint too would be to try to serialize a constant member; sometimes I had strange ASSERTION_FAILURE related to serialization of non-constants (this is also explained in the docs). 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 Tobias Combe Envoyé : mardi 28 février 2006 13:18 À : boost-users(a)lists.boost.org Objet : [Boost-users] problem with serialization of pure virtual Hello I read the documention and some prior postings to related topics. But none of the proposed solutions seems to work for me. My problem: I have an abstarct base class(with pure vitual function) and several derived from that. All are written in the same source/header -file. I want to serialize an object via a pointer to the base-class. When i use "ar.register<derived>();" in the template of the base-class to register the derived classes, i get a syntax error. When i export them with "BOOST_CLASS_EXPORT(derived);" or BOOST_CLASS_EXPORT_GUID(derived,"derived") it doesn't work (i think because they are all in the same file). I'm also using "BOOST_IS_ABSTRACT(base);" When i comment "oa << object;" ervything compiles fine. Uncommented i get a: boost/archive/detail/oserializer.hpp:567: error: incomplete type ` boost::STATIC_ASSERTION_FAILURE<false>' does not have member `value' error... So is there a solution (without seperating the derived classes into different files) for this problem? _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

3 2

[serialization] problem building libs
by Federico Feller 28 Feb '06

28 Feb '06

Hi, I am trying to use the serialization library with borland 6, but when i try to link a program that uses it, the linking fails to find the libboost_serialization-bcb-mt-d-1_33_1.lib file. I checked the libraries generated when i built the library (using bjam) and i found out that the 'mt' version of the library wasnt there. I generated the files ejecuting 'bjam -sTOOLS=borland' under the serialization/build directory. How can i get the mt libraries generated? thanks Federico __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1