- Boost - lists.boost.org

[Date-time] Fix for testing Jamfile?
by Doug Gregor 31 Dec '05

31 Dec '05

It seems that the Jamfile for the date-time regression tests is making GCC 2.95.x regression testing fail with this: /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/boost-base.jam:1585: in find-compatible-subvariant *** argument error * rule split-target-subvariant ( target-var properties-var toolset-var variant-var : subvariant ) * called with: ( sv-target sv-properties sv-toolset sv-variant : ) * missing argument subvariant /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/boost-base.jam:2032:see definition of rule 'split-target-subvariant' being called /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/boost-base.jam:1654: in link-libraries /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/boost-base.jam:1857: in generate-dependencies /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/boost-base.jam:1964: in subvariant-target /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/boost-base.jam:2057: in main-target /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/boost-base.jam:1369: in declare-local-target /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/testing.jam:64: in boost-test /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/testing.jam:552: in run Jamfile:218: in load-jamfiles /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/bootstrap.jam:21: in boost-build /.automount/magrathea/root/home/user3/dgregor/Projects/boost/boost- build.jam:16: in module scope The following patch, which I've already applied, seems to fix the problem. However, that USE_DATE_TIME_PRE_1_33_FACET_IO define seems rather strange to me; is that really what was intended for the serialization tests? Doug Index: Jamfile =================================================================== RCS file: /cvsroot/boost/boost/libs/date_time/test/Jamfile,v retrieving revision 1.34 diff -u -r1.34 Jamfile --- Jamfile 28 Nov 2005 13:20:35 -0000 1.34 +++ Jamfile 29 Dec 2005 19:45:26 -0000 @@ -183,6 +183,8 @@ local DATE_TIME_PROPERTIES = <define>BOOST_DATE_TIME_STATIC_LINK <define>BOOST_ALL_NO_LIB <define>USE_DATE_TIME_PRE_1_33_FACET_IO std::locale-support toolset::require-boost-spirit-support ; + local DATE_TIME_DYNAMIC_PROPERTIES = <define>BOOST_ALL_DYN_LINK <runtime-link>dynamic <define>USE_DATE_TIME_PRE_1_33_FACET_IO <define>BOOST_ALL_NO_LIB + std::locale-support toolset::require-boost-spirit-support ; test-suite date_time_serialization :

2 1

[asio] socket_stream noncopyable
by Felipe Magno de Almeida 31 Dec '05

31 Dec '05

Hello, I have some questions that I'm not getting answers from the documentation: Why is socket_stream noncopyable? Is it an expensive class? If it is, why?? How can I create sockets and accept them without using new on them? I'm not being able to figure it out how. Thanks, -- Felipe Magno de Almeida

2 3

A Re: Filesystem I18n comments
by Seb Martel 30 Dec '05

30 Dec '05

> > > > I would welcome a non-throwing iterator as well. Most of our path > > iterating routines are littered with try catches to handle cases that > > aren't truly exceptional. > > Is the litter just to deal with exceptions coming out of directory_iterator > constructors? Or are there other use cases needing excessive try/catch > blocks? It is pretty much all about handling throwing constructors. > > Also, what should the interface to a non-throwing directory_iterator look > like? > > First try - in addition to the current public members, add: > > directory_iterator( const path & ph, std::nothrow_t ); > // Effects (in addition to normal construction): If error occurs, save > errno, and make iterator == the end iterator. > > system_error_type error(); > // Returns 0 if no constructor error, else errno saved by the > constructor This works well, however, pie in the sky, can we consider making the directory_iterator be no_throw by default ? Our catch implementations either logs the error and/or ignores it (pretty much all our current use cases), or pushes up a message to the user signaling the invalid input (only one occurrence of this behavior in our app): skip and move on is our most common scenario. Such a no-throw interface would at least not kill the iteration process in the advent of an error. The grief comes from a dev forgetting to try/catch the errors and the whole process being aborted prematurely and half completed. This usually gives unsatisfactory results for the user. We catch those problems in the QA cycle, but the fix isn't with a logic error, simply oversight from the developer. I would prefer having a reversed situation where the dev has the responsibility to look for errors if the specifications of the use-case requires to. The status quo is to simply try catch all path iterating routines. On a separate note, I ran into fun times with the MAX_PATH limitation on win32 =) The issue is that GetFileAttributesEx (used through fs::exists for one) fails to process anything bigger than MAX_PATH through the ascii interface. Exists would simply return false. This was causing an infinite loop in a routine that was attempting to create a unique filename through repeated tests. The wide version of GetFileAttributeEx supports a 32,767 character limit, on all but windowsME/98 platforms. Can this situation be improved by considering using the wide interface when MAX_PATH considerations kick in? Possibly introduce some asserts, or *gulp* exceptions? Cheers, -seb

1 0

lvalues and rvalues
by Arkadiy Vertleyb 30 Dec '05

30 Dec '05

Hi, What is current state of the art on l-value/r-value detection? (I know Eric made some progress in the past by using the "?" operator). What we have in typeof is quite primitive :-( I think it might be a good idea to eventially factor it out into a separate header file, and reuse, to avoid contradictions between different libs, and provide the single point of maintenance... Regards, Arkadiy

11 22

yet another asio review
by Jose 30 Dec '05

30 Dec '05

I vote YES to accept asio into boost. Below are some general comments, mostly on what I think should be added. Many thanks to Chris for sharing his expertise and continuing to work on this much needed library ! I have an FC4 x86_64 box and have spent several hours using the library and writing basic examples. I have spent many more hours surveying networking libraries and ensuring I wanted to use asio - documentation and examples It would be nice to add some client/server protocol guidelines that help in designing protocols. Something along the lines on what Chris wrote to compare using the reactor pattern vs using the proactor pattern in asio but geared to different protocols characteristics like fixed header vs variable header, line-oriented, .. The documentation could also include some tips on how to handle special cases raised in the list, like throttling .. An HTTP GET client example would be nice. Not a complete example but maybe an skeleton that can be compiled and shows how asio should be used. No doubt this would be the most used example ! - design This is the main reason I became interested in asio. The design is not only sound but also reflects the practical and wide networking experience of the author - implementation I think the library should use Boost.Threads maybe in addition to the current approach. By using Boost.Threads with asio we'll ensure continued feedback/improvements for two libraries that in many cases will be used together - performance While it has been raised that a synch iostreams interface is nice for basic usage, the major value of C++ asio is performance. I think it would be useful to keep some focus on this, maybe by providing a basic client framework to measure server performance. A basic usage for this would be to compare/benchmark different asio server implementations (latency and throughput). Look forward to the new releases !!

1 0

BCCL : Serialization Concept
by nitin motgi 30 Dec '05

30 Dec '05

Hi, Is there something in the pipeline for BCCL to validate the serialization concept. Thank you, Nitin Motgi NITIN . DOT. MOTGI .AT. GMAIL .DOT. COM

4 7

iterative type registration with typeof
by Arkadiy Vertleyb 30 Dec '05

30 Dec '05

An alternative approach to ones discussed earlier would be to use file iteration, such as: main.cpp----------------------------------- #define BOOST_TYPEOF_COMPLIANT #include <boost/typeof/typeof.hpp> #include <boost/mpl/vector.hpp> #include <boost/preprocessor/iteration/iterate.hpp> #include BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP() BOOST_TYPEOF_REGISTER_TYPE(boost::mpl::vector<>) BOOST_TYPEOF_REGISTER_TYPE(boost::mpl::vector0<>) # define BOOST_PP_ITERATION_LIMITS (1, 10) # define BOOST_PP_FILENAME_1 "register_mpl.hpp" # include BOOST_PP_ITERATE() int main() { boost::mpl::vector1<boost::mpl::vector<int, boost::mpl::vector0<> > > v; typedef BOOST_TYPEOF(v) v_type; return 0; } register_mpl.hpp-------------------------------------------- #include <boost/typeof/typeof.hpp> #define n BOOST_PP_ITERATION() #include BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP() BOOST_TYPEOF_REGISTER_TEMPLATE(boost::mpl::vector, n) BOOST_TYPEOF_REGISTER_TEMPLATE(BOOST_PP_CAT(boost::mpl::vector, n), n) #undef n -------------- This approach can be also applied to sequences. It would work with the current typeof. Regards, Arkadiy

1 0

Re: [boost] Filesystem I18n comments
by Seb Martel 30 Dec '05

30 Dec '05

> > > 2. Any chance of having a non-throwing version of directory_iterator > > (similar > > to status). Since such a common error like not having access to a > > directory > > throws an exception, every directory_iterator construction needs a > > try/catch. > > The recursive_directory_iterator is kind of useless since it will stop as > > soon > > as you get an "access denied". > > (Maybe a portable can_be_iterated function can be added) > > Hum. Worth considering. > I would welcome a non-throwing iterator as well. Most of our path iterating routines are littered with try catches to handle cases that aren't truly exceptional. -Seb

2 1

asio review extended till Dec 30th
by Jeff Garland 30 Dec '05

30 Dec '05

Thanks to everyone for the excellent reviews and discussions of asio! Some folks want additional time for the asio review, so the review will be extended until Dec 30th. Note that Chrisopher may not be able to respond to posts during a significant part of this time due to holiday commitments, but the feedback will eventually be addressed and discussed. In the way of reminder, here's the library details again: Today (Dec 22nd) is the first continuation of the formal review of the Asynchronous I/O library (asio) library by Christopher Kohlhoff. The review will run be extended until Friday December 30th. I will be serving as review manager. From the library synopsis: Boost.Asio is a cross-platform C++ library for network programming that provides developers with a consistent asynchronous I/O model using a modern C++ approach. Downloads of the library as well as online documentation can be found at: http://asio.sourceforge.net/ http://asio.sourceforge.net/boost-asio-proposal-0.3.6/libs/asio/doc/ As usual, please state in review comments how you reviewed the library and whether the you think the library should be accepted into Boost. Further guidelines for writing reviews can be found on the website at: http://www.boost.org/more/formal_review_process.htm#Comments Please review early and often! Thanks, Jeff ******************************************************* A Few Library Details: ******************************************************* Supported Platforms The following platforms and compilers have been tested: * Win32 using Visual C++ 7.1 and Visual C++ 8.0. * Win32 using Borland C++Builder 6 patch 4. * Win32 using MinGW. * Linux (2.4 or 2.6 kernels) using g++ 3.3 or later. * Solaris using g++ 3.3 or later. * Mac OS X 10.4 using g++ 3.3 or later. Rationale The Boost.Asio library is intended for programmers using C++ for systems programming, where access to operating system functionality such as networking is often required. In particular, Boost.Asio attempts to address the following goals: * Portability. The library should support, and provide consistent behaviour across, a range of commonly used operating systems. * Scalability. The library should allow, and indeed encourage, the development of network applications that scale to hundreds or thousands of concurrent connections. The library implementation for each operating system should use the mechanism that best enables this scalability. * Efficiency. The library should support techniques such as scatter-gather I/O, and allow protocol implementations that minimise data copying. * Model Berkeley sockets. The Berkeley sockets API is widely implemented and understood, as well as being covered in much literature. Other programming languages often use a similar interface for networking APIs. * Ease of use. Lower the entry barrier for new users by taking a toolkit, rather than framework, approach. That is, try to minimise the up-front investment in time to just learning a few basic rules and guidelines. After that, a library user should only need to understand the specific functions that are being used. * Basis for further abstraction. The library should permit the development of other libraries that provide higher levels of abstraction. For example, implementations of commonly used protocols such as HTTP. Although the current incarnation of Boost.Asio focuses primarily on networking, its concepts of asynchronous I/O can be extended to include other operating system resources such as files.

6 19

Signals Thread-Safety
by David A. Greene 29 Dec '05

29 Dec '05

I'm starting a project in which I'd hoped to use Boost.Signals but I see that it is not thread-safe. Is there a timeline for making it thread-safe? Thanks. -Dave

4 4