- Boost - lists.boost.org

Re: [boost] [serialization] No Reply?
by JOAQUIN LOPEZ MU?Z 13 Sep '05

13 Sep '05

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Lunes, Septiembre 12, 2005 11:06 pm Asunto: Re: [boost] [serialization] No Reply? > * You should find some way to describe what it means for an input > and an output archive to be compatible. Try to do that as > formally as possible. You may have to rely on the fuzzy C++ > notion of "equivalence," but I wouldn't blame you for that. IMHO, there's no need to go fuzzy or rely on an undefined notion of "equivalence" between a serialized object and its restored copy. One can define these concepts with much precision in an "operational semantics" way, much as, for instance, semantics of logic languages is formally defined: * A type T is serializable if the expressions oar<<ct; iar>>t; are valid, where ct is of type const T& and t is of type T&, oar is an output archive and iar is an input archive. * The storage sequence, or simply storage, of an output archive oar is the ordered sequence of *all* calls s(i) of the form: oar<<out(i); where out(i) is of type const T(i)&. * Given an output archive oar with storage s(i) such that every T(i) is serializable, we say that an input archive iar is associated to oar if the sequence of expressions iar>>in(i); where in(i) is of type T(i)&, does not throw. We assume the input sequence ranges over the entire lifetime of iar. * Under the assumptions above, we say that in(i) is a restored copy of out(i). This defines association between archives in an abstract way. We can go concrete on a per archive basis, for instance: * Given an text output archive oar dumping to a file ofl, and an text input archive iar reading from a file if, iar is associated to oar if the contents of ifl coincide with those of ofl. Now that we have defined what it means for an input archive to be associated to an output archive, we can define the operational semantics of serialization from the concept "being a restored copy". In what follows we use the previous notation. The idea is to begin with primitive types and build on those. * If in(i) is of type bool&, in(i)==true if and only if out(i)==true. * If in(i) is of type char&, the numerical value of in(i) is that of out(i). * Similarly for other integral types. Different word sizes should be taken into account. * If in(i) is of type T*&, and T is serializable, *in(i) is a restored copy of *out(i). We can extend this schema inductively as we progress to more complex types. For example: * If in(i) is of type std::vector<T>&, and T is serializable, then in(i).size()==out(i).size() and each in(i)[j] is a restored copy of out(i)[j]. IMHO, this is sufficiently formal and solves two theoretical issues: * We have defined association between output and input archives without mentioning extralinguistical devices (files, network streams, and so on.) * We have a satisfactory definition of what serialization is supposed to do without relying on a naive "equivalence" relationship between objects and their restored copies: the main difficulty of such a naive approach like for instance "the restored copy has the same value as the original object", is that it does not mean much when these objects belong to different programs, running on different timeframes and perhaphs on different platforms. What do you think? Admittedly, what I've written still has some edges to rough, but I think it is sound enough. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[serialization]: test_diamond partly untested in release mode.
by Stefan Seefeld 13 Sep '05

13 Sep '05

I'm looking for references in boost library tests as to how to use BOOST_ASSERT correctly. I thus found the test_diamond tests in boost/serialization. It appears that the way BOOST_ASSERT is used there doesn't do anything in release mode, i.e. the expression isn't evaluated at all. (I modified the expression and the test still passed.) (As it happens, I was looking specifically for applications of http://www.boost.org/libs/utility/assert.html, as I want to use it in my own tests.) Regards, Stefan

2 1

stlport toolset patches
by François Dumont 13 Sep '05

13 Sep '05

Here is a first patch to build boost using STLport 5.0 with MSVC compilers. STLport 5.0 has adopt a more simple naming schema for generated library, compiler name is not part of it anymore. Rather than changing existing variable in the .jam files I prefered to introduce a new variable STLPORT_USE_AUTO_LINK to signal support of the auto link feature. In this case no lib is specified at link phase, STLport takes care of it. Any remark on the patches will be welcome as I am a completely beginner with bjam. What I would like to achieve now is reflect in bajm files that 5.0 do not support 'wrapper' mode anymore, stlport-iostream feature has to be on per default with this version, is it possible? Bests *** msvc-stlport-tools.jam.orig Thu Aug 25 05:10:34 2005 --- msvc-stlport-tools.jam Thu Aug 25 16:36:23 2005 *************** *** 13,18 **** --- 13,19 ---- STLPORT_LIB_BASE_NAME ?= stlport_vc6 ; STLPORT_LIB_STATIC_SUFFIX ?= _static ; + STLPORT_USE_AUTO_LINK = yes ; # bring in the STLPort configuration SEARCH on stlport.jam = $(BOOST_BUILD_PATH) ; *** stlport.jam.orig Thu Aug 25 05:11:22 2005 --- stlport.jam Thu Aug 25 16:37:06 2005 *************** *** 105,111 **** flags $(CURR_TOOLSET) DEFINES <runtime-build>debug : _STLP_DEBUG=1 _STLP_DEBUG_UNINITIALIZED=1 ; flags $(CURR_TOOLSET) DEFINES <runtime-link>dynamic : _STLP_USE_DYNAMIC_LIB=1 ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_DEBUG_SUFFIX)$(STLPORT_LIB_STATIC_SUFFIX) ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_DEBUG_SUFFIX) ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_STATIC_SUFFIX) ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME) ; --- 105,114 ---- flags $(CURR_TOOLSET) DEFINES <runtime-build>debug : _STLP_DEBUG=1 _STLP_DEBUG_UNINITIALIZED=1 ; flags $(CURR_TOOLSET) DEFINES <runtime-link>dynamic : _STLP_USE_DYNAMIC_LIB=1 ; ! if ! $(STLPORT_USE_AUTO_LINK) ! { ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_DEBUG_SUFFIX)$(STLPORT_LIB_STATIC_SUFFIX) ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_DEBUG_SUFFIX) ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_STATIC_SUFFIX) ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME) ; ! } *** vc7-stlport-tools.jam.orig Thu Aug 25 05:21:13 2005 --- vc7-stlport-tools.jam Thu Aug 25 16:36:40 2005 *************** *** 3,8 **** --- 3,9 ---- flags $(gCURRENT_TOOLSET) STLPORT_LIB_BASE_NAME ; STLPORT_LIB_BASE_NAME ?= stlport_vc70 ; + STLPORT_USE_AUTO_LINK ?= yes ; # bring in the STLPort configuration SEARCH on stlport.jam = $(BOOST_BUILD_PATH) ;

3 3

Re: [boost] Boost regression notification (2005-09-03 [HEAD])
by Martin Bonner 13 Sep '05

13 Sep '05

Doug Gregor [mailto:dgregor@cs.indiana.edu] wrote: >> Somebody wrote: >>>> It looks like some code isn't handling the improved "long double" >>>> type very well.... (With Mac OS X Tiger 10.4 and GCC 4, the >>>> "long double" type is finally distinct and bigger than "double". >>>> The pre-Tiger warnings about not using "long double" are >>>> obviously removed. But it looks like the "double" version of >>>> "exp" is being used. Taking a quick look at a system "math.h"... > > I've traced through this, and the right "exp" is getting called. The > machine epsilon for long double is: > > 4.9406564584124654417656879286822137236505980261432476442558568250067550 > 727020875e-324 Are you sure that's right? That implies a 1074-bit mantissa. That's a VERY long double! (It is also a rather odd sized one. In such a large type, I would expect the mantissa to be an exact number of bytes - or mantissa+sign to be an exact number of bytes). That value looks much more reasonable for the smallest non-zero value of long double. (I am assuming that by epsilon you mean the smallest values such that 1+epsilon != 1, rather than the smallest value such that epsilon > 0). > > There's no *way* we'll get that much accuracy out of the C library's > sin/atan/cos/etc. Here's the result of a little program that prints > out atan(1), 4*atan(1), and sin(4*atan(1)). There isn't a large enough > improvement in precision from "double" to "long double": > > atan(1) with float = 0.785398185253143310546875 > 4*atan(1) with float = 3.1415927410125732421875 > sin(4*atan(1)) with float = > -8.74227765734758577309548854827880859375e-08 > atan(1) with double = > 0.78539816339744827899949086713604629039764404296875 > 4*atan(1) with double = > 3.141592653589793115997963468544185161590576171875 > sin(4*atan(1)) with double = > 1.224606353822377258211417938582599163055419921875e-16 > atan(1) with long double = > 0.7853981633974483096282022398515465511081856675446033477783203125 > 4*atan(1) with long double = > 3.14159265358979323851280895940618620443274267017841339111328125 > sin(4*atan(1)) with long double = > -5.42101086242752217003726400434970855712890625e-20 If long double is actually 80 bits (which is the usual Intel interpretation), that looks plausible. > I don't even think that we can call this a platform bug; we just can't > expect the C library routines to have that kind of precision. If long double really is >1kbits, I don't see why the C runtime shouldn't support them. > I think > we should consider long double tests on this platform bogus and > disable them. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

2 1

[Boost.Thread]: consider removing catch(...) from thread_proxy
by Slawomir Lisznianski 13 Sep '05

13 Sep '05

Hello, I find the catch(...) clause in the thread_proxy function (thread.cpp) causing more harm than good. If exception "leaks" from a function executing in the context of a thread, the thread silently goes away but the application continues to operate as if nothing happend. I think, in this instance, the library simply "does too much" by trying to do the cleanup. As a user, I can always wrap the code in the catch-all, but what I cannot change is the fact that when unhandled exception is thrown, I will not see the function in the stack trace where the exception originated. Here is the proposed proxy, after trivial changes: extern "C" { #if defined(BOOST_HAS_WINTHREADS) unsigned __stdcall thread_proxy(void* param) #elif defined(BOOST_HAS_PTHREADS) static void* thread_proxy(void* param) #elif defined(BOOST_HAS_MPTASKS) static OSStatus thread_proxy(void* param) #endif { thread_param* p = static_cast<thread_param*>(param); boost::function0<void> threadfunc = p->m_threadfunc; p->started(); threadfunc(); #if defined(BOOST_HAS_WINTHREADS) on_thread_exit(); #endif #if defined(BOOST_HAS_MPTASKS) ::boost::detail::thread_cleanup(); #endif return 0; } } Regards, Slawomir

14 47

Yet another regression system question
by Arkadiy Vertleyb 12 Sep '05

12 Sep '05

Hi All, Is it possible to use "run" or "link" test types in combination with more than one source (I need this for ODR testing)? If not, how do I define such a test? Thanks, Arkadiy

2 2

[xpressive][review] regex type
by Thomas Witt 12 Sep '05

12 Sep '05

What is the rationale for having the regex type bound to the iterator type used when matching/searching ? Thomas

2 1

[Filesystem] Removed extraneous debugging info
by Douglas Gregor 12 Sep '05

12 Sep '05

Failures in the filesystem library were breaking testing on several of our *nix machines. The problems were due to some extraneous debugging output statements that worked only on Windows. I've checked in the obvious fix to libs/filesystem/src/operations_posix_windows.cpp. Doug

3 2

[Serialization] Pointer to const
by Loïc Joly 12 Sep '05

12 Sep '05

Hello everybody, There a still many stuff I do not understand how to do with boost::serialization. One of them is the following : Let's say I have the following classes : struct B { int i; template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & i;} }; struct A { B const *pc; template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & pc; } }; When I try to serialize a A, I get the following error (MSVC8 beta 2): c:\boost\include\boost-1_33\boost\archive\detail\iserializer.hpp(474) : error C2440: 'reinterpret_cast' : cannot convert from 'const B **__w64 ' to 'void **' Conversion loses qualifiers c:\boost\include\boost-1_33\boost\archive\detail\iserializer.hpp(471) : while compiling class template member function 'void boost::archive::detail::load_pointer_type<Archive,Tptr>::invoke(Archive &,Tptr &)' with [ Archive=boost::archive::text_iarchive, Tptr=const B * ] Of course, if I replace B const *pc by B *pc, then the code works correctly.What can I do to serialize pointers to const data ? Regards, -- Loïc

2 4

[gmane web interface] why is the latest artivle from the 8th of sep????
by Thorsten Ottosen 12 Sep '05

12 Sep '05

The headline pretty much says it all. Without an up to date web interface, I can't post stuff :-( br -Thorsten

2 1