Glenn Ramsey | 1 Sep 01:00
Picon

[Serialization] Compatibility of text archives in 1.36 and 1.34

Hi,

I recently upgraded from boost 1.34 to boost 1.36. A version of my
application built with 1.36 can read the text archives produced by 1.34,
but a version of my application built with 1.34 cannot read the text
archives produced by 1.36.

Is this the behaviour that I should expect?

Glenn

--

-- 
Glenn Ramsey
http://www.componic.co.nz
Jonathan Biggar | 1 Sep 02:36

Re: [Serialization] Are the serialized char* different when code runs in 32/64 bits machines ?

jotalo jotalo wrote:
> Hi,
> I use the Bost  serialization library to serialize some classes that I put in a char* variable ...
> I have a Server which publish this char* variable  and Clients get this variable and de-serialize it to
obtain the original class...
> 
> Everything work fine when servers and clients are running in machines with the same architecture (64 or 32 bits)...
> 
> But when I run the server in a 64 bits machine, the char* variable is not recognized in a 32 bits client. In
this code:
>     std::stringstream is;
>     is.rdbuf()->pubsetbuf(c, m_StringSize);
>     boost::archive::binary_iarchive *ia = new boost::archive::binary_iarchive(is);
> 
> The last line returns the std::exception: "invalid signature"
> 
> To be sure that I am not doing something wrong I printed the first 80 characters of this variable when it is 
> created in a 64 bits server and a 32 bits server:
> 
> In a 64 bits machine server, the print out is:
> 
> "........serialization::archive.................MonH1F............Efficiency.(cou"    (the "."
are not printable ascii characters)
> 
> in Hexa format it is :
> 
> 16 00 00 00 00 00 00 00 73 65 72 69 61 6C 69 7A 61 74 69 6F 6E 3A 3A 
>  61 72 63 68 69 76 65 04 04 08 04 08 01 00 00 00 06 00 00 00 00 00 00 00 
> 4D 6F 6E 48 31 46 00 00 00 00 1E 00 00 00 00 00 00 00 45 66 66 69 63 69 
> 65 6E 63 79 20 28 63 6F 75
(Continue reading)

Ting Yu | 1 Sep 03:56
Picon
Picon

Outer product in the uBLAS

Hi All,
I am using the uBLAS to do an outer product between a vector and a 
matrix. The function "outer_prod" seems to only accept two vectors 
instead of a vector and a matrix. Is there anyone successfully to do 
the outer product between a vector and a matrix? Many Thanks

Cheers

Ting Yu

Research Fellow, PhD
The Center for Integrated Sustainability Analysis (ISA)
Office: Room 408, Physics Building A28, University of Sydney, NSW 2006
Tel: (02) 9351 2627 (Shared)
Fax: (02) 9351 7726 
Picon
Gravatar

[Min-Max] Usage with a member function as criteria.

Hello Boost users,

I'm working on my thesis with the Boost library (Boost-1.34.1) running on g++ (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2).

What I'm trying to do can be done very simply, but I preferred to do it more appropriately, I believe, using the Boost Min-Max library. I'm trying to simultaneously obtain the maximum and minimum values of a member function call over a lists of objects.

Suppose there exists a
    class utl::Particle;
with a member function
    double GetEnergy() const;

In a member field of another class I have a list of those particles
    std::list<utl::Particle> particles;
for which I want min/max GetEnergy() values.

How is that accomplished using Boost.Min-Max?

Below I give some excerpts of some of the things I've tried, but didn't work. In order to try to understand what I was doing I split the code over several lines, so to minimize the non-compiling one. In both cases the error seems to be (that line is what I believe to be the most important part of all the error messages):

boost/iterator/iterator_adaptor.hpp:353: error: no match for 'operator-' in...

First attempt:
    boost::function<double(const utl::Particle&)> energy =  boost::lambda::bind(&utl::Particle::GetEnergy, boost::lambda::_1 );
    boost::transform_iterator< boost::function<double(const utl::Particle&)> , list<utl::Particle>::const_iterator>
        itBeg(particles.begin(), energy),itEnd(particles.end(), energy);
    boost::minmax(itBeg, itEnd); // This call doesn't compile.

Second attempt:
    boost::function<double(const utl::Particle&)> energy =  boost::lambda::bind(&utl::Particle::GetEnergy, boost::lambda::_1 ); // As in the first case.
      boost::minmax(
          boost::make_transform_iterator(particles.begin(),energy ),
          boost::make_transform_iterator(particles.end()  ,energy )); // This call doesn't compile.

Thanks a lot for your help.

--
Rodolfo Federico Gamarra
_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Favicon
Gravatar

Re: [Serialization] Are the serialized char* different when code runs in 32/64 bits machines ?

On Sun, 31 Aug 2008, jotalo jotalo wrote:

>
> Hi,
> I use the Bost  serialization library to serialize some classes that I put in a char* variable ...
> I have a Server which publish this char* variable  and Clients get this variable and de-serialize it to
obtain the original class...

You might wanna at look Boost Asio serialization examples.
http://www.boost.org/doc/libs/1_36_0/doc/html/boost_asio/examples.html

-V
Favicon
Gravatar

Re: [Boost.Asio] service_name/port inconsistency

On Sun, 31 Aug 2008, Boris wrote:

>> [...]a) What is the point passing endpoint_type, when we know for sure that
>> endpoint will only accept address which *cannot* be a FQDN. What do we
>> achieve by doing this?
>
> If I'm not mistaken it's basically a wrapper for getnameinfo().

Maybe I haven't expressed myself correctly.

resolver.resolve(endpoint) - does not resolve anything since the endpoint 
can only be expressed in dotted decimal form, or in hexadecimal
notation.

>> b) To be more precise: How come basic_resolver_query does not take
>> unsigned short as a parameter for service/port?
>
> I don't know why but you can pass a port number by converting it to a 
> std::string.

Yeah, that's what I'm dong (lexical cast) in order to keep the code
simple and generic.

Thanks!

V
Robert Ramey | 1 Sep 06:31

Re: [Serialization] Are the serialized char* different when code runs in 32/64 bits machines ?

binary_archives are not portable accross machine architectures.

Robert Ramey 
Robert Ramey | 1 Sep 06:33

Re: [Serialization] Compatibility of text archives in1.36 and 1.34


Glenn Ramsey wrote:
> Hi,
>
> I recently upgraded from boost 1.34 to boost 1.36. A version of my
> application built with 1.36 can read the text archives produced by
> 1.34, but a version of my application built with 1.34 cannot read the
> text archives produced by 1.36.
>
> Is this the behaviour that I should expect?

yes.  We currently guarentee the ability to read archives made by previous
versions of the library.  We do not guarentee the ability to read archives
made by future versions of the library.

Robert Raey

> Glenn 
troy d. straszheim | 1 Sep 06:44
Favicon

Re: serialization 1.36.0 extended_type_info exitissue(s)

Robert Ramey wrote:
> This has been reported in two trak items.
> 
> I've looked at it and made changes which I believe will
> address the problem.  But I haven't been able to test it
> yet.
> 
> Robert.
> 

Hey Robert,

Got any hints on what is going on here?  svn revision#
of the relevant changes?   We've hit this one as well, looking
for a workaround, not making much progress.

-t
Robert Ramey | 1 Sep 07:47

Re: serialization 1.36.0extended_type_info exitissue(s)

I've addressed it on my personal copy. Just now passed tests on my
local machine.  I will be uploading to the trunk soon.  Unfortunately
I can't be sure my changes fix the problem as it doesn't manifest
itself on my machine.

Robert Ramey

troy d. straszheim wrote:
> Robert Ramey wrote:
>> This has been reported in two trak items.
>>
>> I've looked at it and made changes which I believe will
>> address the problem.  But I haven't been able to test it
>> yet.
>>
>> Robert.
>>
>
> Hey Robert,
>
> Got any hints on what is going on here?  svn revision#
> of the relevant changes?   We've hit this one as well, looking
> for a workaround, not making much progress.
>
> -t 

Gmane