- 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 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

[type traits] problem on MSVC 7.1 with is_base_and_derived
by JOAQUIN LOPEZ MU?Z 22 Apr '05

22 Apr '05

Hello, Jochen Hammann has stumbled onto a problem which can be reduced to the following: In MSVC 7.1, if setting the compiler option /vmg, is_base_and_derived crashes when dealing with instantiations of template classes that have pointers to members as template params. The attached code, if compiled with /vmg, ICEs as follows: d:\...\boost\type_traits\is_base_and_derived.hpp(127) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 2701) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information (I don't know if the problem persists in MSVC 8.0.) Is there any hope that this can be solved? Thanks in advance, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 6

Iostreams filter buffering policy leads to extremely small reads.
by George M. Garner Jr. 21 Apr '05

21 Apr '05

Johnathan, The Iostreams library provides for built in buffering of filters which in principle should permit efficient use of filters even with streams that do not support filtering. However, in practice it does not appear to live up to expectations. More specifically, the following line in indirect_streambuf.hpp can lead to extremely fragmented reads to lower filters or devices: std::streamsize indirect_streambuf<T, Tr, Alloc, Mode>::xsgetn (char_type* s, std::streamsize n) { [...] streamsize amt = obj().read(s + avail, n - avail, next_); // n - avail may equal 10 or less [...] } This is true even if the filter buffer size is set to 1MiB or more. Large buffer sizes (> 2 MiB) greatly enhances read and write performance on many modern operating systems. This is particularly felt when reading and writing large files (> 4 GiB). Ideally, if you set a filter buffer policy (e.g. to 1 MiB) you would like all reads to lower filters and devices to request that value, except possibly for the last read. Fortunately, it is relatively trivial to disable Iostreams buffering altogether and write a buffering_shim_filter. But then I do not understand what purpose Iostreams buffering serves. I Googled through the online documentation and I didn't find a detailed discussion of its objectives, though there were some comments that touched on the subject matter during the review process. Perhaps you can further elaborate this subject matter. Regards, George.

2 5

Linking to shared library
by Gander 21 Apr '05

21 Apr '05

Hi, I get an error linking the example program days_alive to the shared library libboost_date_time. g++ -L/usr/lib -lboost_date_time -odays_alive days_alive.o days_alive.o(.gnu.linkonce.t._ZN5boost9date_time19month_str_to_ushortINS_9gregorian10greg_monthEEEtSs+0xec): In function `unsigned short boost::date_time::month_str_to_ushort<boost::gregorian::greg_month>(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)': /usr/include/boost/token_functions.hpp:587: undefined reference to `boost::gregorian::greg_month::get_month_map_ptr()' collect2: ld returned 1 exit status Platform is FC2 gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) I built Boost from the SRC RPM boost-1.32.0-3.src.rpm with no special switches. I found a comment in the boost mailings advising linking to static library. This was successful. Is the general advice to only use the static libraries? Giles Anderson

3 8