- Boost - lists.boost.org

Re: [boost] [serialization] facets for non-finite numbers
by Johan Råde 18 Aug '06

18 Aug '06

I have uploaded a new version to the vault. This version features: 1. Strict C99 conformance: Output is consistent with C99. (In particular, negative NaN is written as "-nan". All representations allowed by C99 are recognized as input. 2. Optional support for negative 0. 3. Clean build with VC++ 7.1 at warning level 4. 4. Improved documentation. This version is backwards compatible with earlier versions. The code comes with a test program. I have only run the test program on VC++ 7.1. If you run the test program on any other platform, please report the result to me. Both good and bad results are of interest. Many thanks to Paul Bristow, John Maddock and Gennaro Prota for valauble comments. --Johan Råde Johan Råde wrote: > ----- The Problem ----- > > The C++98 standard does not specify how non-finite floating point > numbers, > such as infinity and not-a-number, should be represented in text streams. > As a result, different platforms use different representations. > This can cause undefined behavior when text files and serialization > archives > are moved between different platforms. > > Some platforms can not even read their own output! > For instance, the following test fails with VC++ 7.1: > > stringstream s; > double x = numeric_limits<double>::infinity(); > double y; > ss << x; > ss >> y; > assert(x == y); > > > ----- The Solution ----- > > The facets extended_num_put and extended_num_get > write and read non-finite floating point numbers > to text streams in a consistent and portable manner. > > The following test succeeds with VC++ 7.1: > > stringstream s; > locale old_locale; > locale tmp_locale(old_locale, new extended_num_put<char>); > locale new_locale(tmp_locale, new extended_num_get<char>); > s.imbue(new_locale); > > double x = numeric_limits<double>::infinity(); > double y; > ss << x; > ss >> y; > assert(x == y); > > >

7 22

[test] Request related to BOOST_PRG_MON_CONFIRM
by Gennaro Prota 18 Aug '06

18 Aug '06

Hi, I'd like to request a way to inform the test system whether I want a success message or not. The Inspect tool makes a good example: if the user just invokes <inspect --help> I do not want a "no errors detected" to be displayed at the end. However, if I really run the inspection and there are no errors I'd like to have the message. Of course BOOST_PRG_MON_CONFIRM can't do that. We could choose a particular bit in the cpp_main return value to carry the desired piece of information, but that's not something I would be proud of. What's the best solution in the context of the test framework? -- [ Gennaro Prota, C++ developer for hire ]

2 6

Re: [boost] [Serialization] Proposal for improved support for ptrs
by Dan Notestein 18 Aug '06

18 Aug '06

Robert Ramey wrote: > > For me a one pass solution was a requirement - even though > I didn't state it explicitly. I just presumed that users would > object to the exra cost of a second pass. So I never really > considered it. I don't believe a second pass as described would have a significant impact on serialization performance. Similar operations are being performed during the one-pass serialization now, and the additional traversal itself should not be expensive compared to the time it takes to perform the operations on each element (even when we're not serializing to a slow medium, such as a hard disk). Also note that during the first pass, no data is actually being serialized to a medium, it's just performing an analysis to determine which objects are contained within other objects. For many situations, I think the proposed algorithm would actually be faster. For example, when serializing a vector of trackable objects, the current implementation must add each element of the vector to the object-id lookup tables in case there is a pointer to the element somewhere. In the proposed implementation, the elements don't need to be added to the object-id table, since we know the boundaries of the containing object and we would be using an offset into the containing object for any pointer references to these elements. So for any datastructure that had arrays or vectors with a large number of trackable elements, the object lookup tables would be drastically smaller, which should yield better speed performance as well. The ability to use more contained data is a big memory and speed performance advantage of it's own, and should outweigh any possible disadvantage of the analysis pass. Being able to use high performance data structures is one of the main motivations for this proposal. I think the ability to serialize many common data structures that are not currently serializable is another reason to consider such a change. I've tried to use the serialization library in it's current form on two different data structures and both times I've encountered problems because of limitations in the current implementation. The first attempt was to serialize off an abstract syntax tree for a Verilog compiler, and I eventually had to give up on this because of the sheer number of changes that would be required to the data structure. The second data structure was designed with the serialization library in mind, but it's still difficult to get around the previously mentioned limitations as the number of object relationships increases. best regards, Dan Notestein

1 0

boost.interprocess error - no file boost/interprocess/detail/move.hpp
by Alex Ott 18 Aug '06

18 Aug '06

Hi all i trying to play with boost.interprocess, but examples in current CS doesn't compile - no file boost/interprocess/detail/move.hpp -- With best wishes, Alex Ott Jet Infosystems, Head of software development group, MBA +7 (495) 411 76 01 http://www.jetsoft.ru/

2 1

[date_time] EDG compilation problems
by Ralf W. Grosse-Kunstleve 18 Aug '06

18 Aug '06

The following two lines don't compile with the EDG 304 based Tru64 cxx compiler: #include <time.h> #include "boost/date_time/gregorian/gregorian.hpp" The full error message is attached. It looks like this struct is instantiated with C = char: namespace boost { template< typename C > struct range_const_iterator { typedef typename C::const_iterator type; }; } I tried adding a full specialization for range_const_iterator<char> but this didn't help. Older EDG's seem to have the same problem. Does someone have experience compiling the date_time library with an EDG-based compiler? I'd be grateful for suggestions. Thanks! Ralf __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

5 5

Re: [boost] Boost Units library preview
by Eric Lemings 18 Aug '06

18 Aug '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Andy Little > Sent: Thursday, August 17, 2006 3:50 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Boost Units library preview > > ... > ----------- > output: > > E:\projects\Test>testgcc > quan qft.numeric_value() = 3 > boost.units ft1.value() = 3 > assertion "f1.value() == 3" failed: file "test.cpp", line 17 > 6 [sig] testgcc 3984 open_stackdumpfile: Dumping stack > trace to testgcc.ex e.stackdump > 33204 [sig] testgcc 3984 E:\projects\Test\testgcc.exe: *** > fatal error - E:\pr > ojects\Test\testgcc.exe: *** called with threadlist_ix -1 In the Units library, the default value type is (currently) double and the semantics of all arithmetic operations are based on this built-in type. No assumptions are made about semantics, only that the required operations exist for ValueType. What is the default value type in Quan? I'm guessing it has something to do with a united value or some other manipulation of value semantics within Quan? Also be careful of literal values and promotions. 3 is an integer, 3.0 is a double, 3L is a long, 3LL is a long long, etc. Eric.

2 1

Re: [boost] Presentation of Boost.Process (SoC project)
by Oliver.Kowalke＠qimonda.com 18 Aug '06

18 Aug '06

> I am confused now. Are you really saying that whether > throwing exceptions from a signal handler works is in some > way related to support for WCONTINUED? No - it is wrong! It was a mistake. I suggest to support WIFCONTINUED because WIFSTOPPED is already used in your code. Oliver

1 0

Re: [boost] Presentation of Boost.Process (SoC project)
by Oliver.Kowalke＠qimonda.com 18 Aug '06

18 Aug '06

> Davide Bolcioni wrote: > > > Is throwing an exception in a signal handler supported by POSIX ? > > No. Right - I've replaced my error reporting mechanism by throw clause - was a mistake. > Additionally, it is also known not to work on a number of systems. But on systems which support WCONTINUED boost.process shouild support it.

2 1

[RC_1_34_0] MSVC 8.0 link looking for lib*
by Dean Michael Berris 18 Aug '06

18 Aug '06

Hi Everyone, I've recently updated my local copy of RC_1_34_0 (as in a couple days ago), and the build/install problem recurred: when I do `bjam --v2 install' the headers (boost/*.hpp) weren't copied to the destination directory (c:\install by default, and even in --prefix=...) and the library files don't have the `lib' prefix (boost_date_time-vc80-1_34.lib) save for libboost_prg_exec_monitor and libboost_unit_test_framework. This used to be fixed, but now it seems like the build scripts were reverted or something else happened between then and now. Hope this helps, and keep up the great work guys! -- Dean Michael C. Berris C/C++ Software Architect Orange and Bronze Software Labs http://3w-agility.blogspot.com/ http://cplusplus-soup.blogspot.com/ Mobile: +639287291459 Email: dean [at] orangeandbronze [dot] com

1 0

[Asio] How do i code a resource clean server shutdown?
by Rod Morison 18 Aug '06

18 Aug '06

I'm studying the async daytime server example, Daytime.3 (0.3.7 flavor): http://asio.sourceforge.net/boost_asio_0_3_7/libs/asio/doc/tutorial/tutdayt… (I'm doing an Asio proof/concept for an app that has to dynamically change it's service ports.) I'm trying to think through how to perform a clean shutdown in this example. There could be a number of pending async_write()'s, each with their own socket and uncalled handler. There is probably also a socket waiting on the async_accept() with an an uncalled handler. Questions: - With the work pending, io_service will need to call it's interrupt() function (from another thread) to stop processing, correct? - If io_service is destroyed, what happens to the otherwise pending work, i.e., the async_write's and async_accepts that it controls? What about the socket resources? - I can close the tcp::acceptor in tcp_server, but what about the socket that's listening on it? - If Asio doesn't release system handles, e.g., sockets, how do I get at the resources to clean up? - Is there an example of a resource clean shutdown? I skimmed the example apps and didn't see one first pass. Thanks, Rod - If the io_service is destroyed, what Is there a way to do this with the io_service? In a watchdog thread... -call io_service.interrupt() to stop processing -tell the tcp_server to The io_service.run() won't exit until all services and handlers are finished. Let me take a stab at a shutdown design and perhaps Asio vets would be willing to tear it apart/fix it? This assumes the Daytime.3 server code at http://asio.sourceforge.net/boost_asio_0_3_7/libs/asio/doc/tutorial/tutdayt… (I noticed the 0.3.6 example is somewhat different.) in tcp_server ------------- - add a cleanup() method that calls acceptor_.close() in main() --------- - add a watchdog thread that will shutdown the server's io_service - if shutdown time then How do I notify handlers io_service.dispatch() or io_service.post() to wake up handlers

2 3