- Boost - lists.boost.org

Re: [boost] Re: [network] An RFC - updated
by Iain Hanson 22 Apr '05

22 Apr '05

On Fri, 2005-04-22 at 16:24 +0200, Peter Simons wrote: > Iain Hanson writes: > > >>> This would give a significant performance hit as there > >>> will now be two copies of the data. > > >> Not if the callback doesn't make any copies. > > > That is a long way from being the common case. > > Maybe, maybe not. My point is that whether or not data has > to be copied depends on the _callback_, not on the I/O > driver. Your original statement made it appear as if copying > of data would be inevitable in a callback-driven design -- > and it is not. > No. Copying the data becomes probable when the lib provides the buffer. Nothing to do with callbacks. > > > I really don't see this as workable in the general case. > > The library has to guess the size of the read buffer. > > No, the caller can provide the capacity (or the buffer). > > > > It would also prevent reading a complete record on a > > stream by reading a header up to the length field and > > then making a 2nd read call for that length with the > > correct size buffer. > > Why exactly would that be impossible in a callback-driven > design? > > > > It would also add dynamic memory allocation to the > > library [...]. > > Let the user pass the buffer when calling the driver, and > then there's no memory management at all. This is what I was arguing for. /ikh

1 0

Re: [boost] Re: Re: (Another) socket streams library
by Iain Hanson 22 Apr '05

22 Apr '05

On Fri, 2005-04-22 at 13:26 +0300, Boris wrote: > Caleb Epstein wrote: > > [...] > > concise, which is a tribute to the your implementation. At the same > > time, it is missing asynchronous and/or non-blocking operations and > > any means for doing single-threaded I/O multiplexing (e.g. > > select/poll/etc). > > But these don't belong to a streams library anway - at least I wouldn't know > how to support these I/O models without changing the stream interface. > Sorry, but I think that they do. At least both non-blocking and a reactor. I don't see why just because you are using iostreams that these become excluded. /ikh

1 0

BGL::johnson_all_pairs_shortest_path question
by Andreas Fabri 22 Apr '05

22 Apr '05

Hello, What is the non-named parameter version of this algorithm. In the online manual it says Weight (and this is probably a typo, as there is a template parameter WeightMap). Also what are the arguments id1 and zero good for? andreas

1 0

Re: [boost] Re: [network] An RFC - updated
by Iain Hanson 22 Apr '05

22 Apr '05

On Fri, 2005-04-22 at 13:07 +0200, Peter Simons wrote: > Iain Hanson writes: > > >> async_read should not take a buffer; instead, the > >> callback should receive a pointer to a buffer managed by > >> the library that is guaranteed to be valid for the > >> duration of the callback. (Not by default, at least.) > > >> async_write (by default) should not assume that the > >> passed buffer stays valid after async_write returns. > > > This would give a significant performance hit as there > > will now be two copies of the data. > > Not if the callback doesn't make any copies. > That is a long way from being the common case. /ikh

2 1

bgl at boost.org and bostconsulting
by Andreas Fabri 22 Apr '05

22 Apr '05

Hello, When comparing the tables of content of the BGL http://www.boost.org/libs/graph/doc/table_of_contents.html http://www.boost-consulting.com/boost/libs/graph/doc/table_of_contents.html I see that the latter offers more algorithms. Are they also distributed ??? andreas

2 1

[Spirit + Graph] Request for help!
by Doug Gregor 22 Apr '05

22 Apr '05

The new GraphViz parser in the Graph library is implemented as an ultra-slick Spirit grammar from Ron Garcia. It works fine on newer versions of GCC and EDG, but Visual C++ 7.0 completely croaks with an internal compiler error. I've moved around code, eliminated some templates from the equation, etc., but I don't have a feel for how to fix the compiler, especially when Spirit is concerned. Are there any Spirit jockeys that could give me a few hints on how to deal with this or, better yet, get it working on VC 7.1? Cheers, Doug

4 6

Re: [boost] Re: [network] An RFC - updated
by Iain Hanson 22 Apr '05

22 Apr '05

On Fri, 2005-04-22 at 12:42 +0300, Peter Dimov wrote: > async_read should not take a buffer; instead, the callback should receive a > pointer to a buffer managed by the library that is guaranteed to be valid > for the duration of the callback. (Not by default, at least.) > > async_write (by default) should not assume that the passed buffer stays > valid after async_write returns. > > Rationale: buffer management is a pain with multiple callbacks active ;-) > This would give a significant performance hit as there will now be two copies of the data. The 1st from kennel space to the library and the second in the callback from the library to the user. /ikh

4 3

Re: [boost] Re: [network] An RFC - updated
by Iain Hanson 22 Apr '05

22 Apr '05

On Fri, 2005-04-22 at 09:01 +0200, Michel André wrote: > I see no problem with this. The only thing an connector gives you is the > possibility to do some hand shaking or whatever before handing the > stream to the handler and this handshacking wouldn't be relevant to the > protocol handler. > A connector sets socket options that can not be set after a call to connect on a TCP connection! /ikh

2 1

Re: [boost] (Named) Parameter Library
by Cromwell Enage 22 Apr '05

22 Apr '05

>From my understanding of the new interface: boost::keyword is now boost::named_params::keyword, boost::keywords is now boost::named_params::parameters, and boost::named_param<KW,boost::mpl::true_,Restriction> and boost::named_param<KW,boost::mpl::true_,Restriction> are replaced by boost::named_params::required<KW,Restriction> and boost::named_params::optional<KW,Restriction>. Am I correct? The type-extraction functionality I mentioned earlier has now been reimplemented in terms of the current code base, as is the BOOST_NAMED_PARAMS_MEMBER_FUN macro I proposed a while back. I also discovered an extraneous #define in <boost/named_params/aux_/arg_list.hpp> that prevents me from increasing the maximum arity of a function. The files I added and/or fixed are in the new File Vault, subdirectory "expaler", filename "named_params.zip". Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Re: [boost] Boost serialization: 'serialize' : is not a member of 'std::vector<_Ty>'
by Vishnu Mahadevan Menon 22 Apr '05

22 Apr '05

Thanks for your reply! Yes, I did try including <boost/serialization/string.hpp>, but the error is still there. The strange thing is, I do not get this error everytime I try to serialize STL collections - it seems to pop up only in certain places. Regards, Vishnu. --- Felipe Magno de Almeida <felipe.almeida(a)ic.unicamp.br> wrote: > I dont know if has anything with this error, but > Have you included <boost/serialization/string.hpp> ? > > Vishnu Mahadevan Menon wrote: > > Hello! > > > > I seem to be getting the following compilation > error > > even after I've included > > <boost/serialization/vector.hpp> in the source > file. > > I'm using VS.net 7.1 to compile. > > > > [QUOTE] > > > > > c:\Boost\include\boost_1_32_0\boost\serialization\access.hpp(106) > > : error C2039: 'serialize' : is not a member of > > 'std::vector<_Ty>' > > with > > [ > > _Ty=std::string > > ] > > > > > c:\Boost\include\boost_1_32_0\boost\serialization\serialization.hpp(78) > > : see reference to function template instantiation > > 'void > > > boost::serialization::access::serialize<Archive,T>(Archive > > &,T &,const unsigned int)' being compiled > > with > > [ > > Archive=boost::archive::xml_iarchive, > > T=std::vector<std::string> > > ] > > > > > c:\Boost\include\boost_1_32_0\boost\serialization\serialization.hpp(121) > > : see reference to function template instantiation > > 'void > > boost::serialization::serialize<Archive,T>(Archive > &,T > > &,const unsigned int)' being compiled > > with > > [ > > Archive=boost::archive::xml_iarchive, > > T=std::vector<std::string> > > ] > > > > > c:\Boost\include\boost_1_32_0\boost\archive\detail\iserializer.hpp(159) > > : see reference to function template instantiation > > 'void > > > boost::serialization::serialize_adl<Archive,T>(Archive > > &,T &,const unsigned int)' being compiled > > with > > [ > > Archive=boost::archive::xml_iarchive, > > T=std::vector<std::string> > > ] > > > > > c:\Boost\include\boost_1_32_0\boost\archive\detail\iserializer.hpp(109) > > : while compiling class-template member function > 'void > > > boost::archive::detail::iserializer<Archive,T>::load_object_data(boost::archive::detail::basic_iarchive > > &,void *,const unsigned int) const' > > with > > [ > > Archive=boost::archive::xml_iarchive, > > T=std::vector<std::string> > > ] > > > > [Long dump.. UNQUOTE] > > > > Could anyone tell me why the above is happening > and > > how to get around the problem? I'll post the > > source-code if that'll help! > > > > I also searched and stumbled into > > (http://lists.boost.org/boost/2005/02/19606.php) > which > > *seems* to be saying that the issue is addressed > > somewhere in the serialization documentation, but > was > > unable to locate where. > > > > Thanks and regards, > > Vishnu. > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > _______________________________________________ > > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > > > -- > Felipe Magno de Almeida > UIN: 2113442 > email: felipe.almeida at ic unicamp br, > felipe.m.almeida at gmail > com, felipe at synergy com > I am a C, modern C++, MFC, ODBC, Windows Services, > MAPI developer > from synergy, and Computer Science student from > State > University of Campinas(UNICAMP). > To know more about: > Unicamp: http://www.ic.unicamp.br > Synergy: http://www.synergy.com.br > current work: http://www.mintercept.com > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0