[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnash-dev] Re: AMF::encodeObject,encodeElement

From: Rob Savoye
Subject: [Gnash-dev] Re: AMF::encodeObject,encodeElement
Date: Tue, 18 Nov 2008 14:39:05 -0700
User-agent: Thunderbird (X11/20080723)

strk wrote:

> When the element is not of type object,
> a shared_ptr is constructed with 'this'
> for passing it to AMF::encodeElement.

  It's entirely possible here is a bug, after the big change to boost
shared_ptrs from real pointers, I'm still occasionally finding a few
things that can't work the same way anymore.

> Now, avoiding any redesign attempt, is there any

  Please don't start redesigning libamf. Improvements, bug fixes, etc
are ok, but any big API changes will force me to change a whole lot of
Cygnal code that I don't feel like changing massively right now.

> reason for AMF::encodeElement to take a shared_ptr<Element>
> rather then a const Element& ?

  Because often the Element being passed in is stored in an vector of
shared_ptrs, which is used to store the properties of an object.

> All the encoder does is serializign the Element, and
> keeps no state between calls, right ?

Some encoding does keep track of how many bytes have been parsed out of
the byte stream, primarily used to keep track of how many bytes have
been encoded, which you do have to keep track of when encoding multiple
properties of an object. The private variable AMF::_totalsize stores
this accumulator.

        - rob -

reply via email to

[Prev in Thread] Current Thread [Next in Thread]