[gst-devel] GstStructure mutability question

[José Alburquerque]

Andy Wingo wrote:
> On Fri 18 Jan 2008 00:24, José Alburquerque <jaalburquerque at cox.net> writes:
>
>   
>> Hi.  I have a question on the mutability enforcement ability of a 
>> GstStructure.
>>     
>
> Check gstreamer/docs/design/part-MT-refcounting.txt, "Mutable
> substructures". 
>
> Andy
>   
Thanks for replying.  I'm in the process of reading the documentation.  
In the mean time, my real question may not be directly answered there 
because my question is a bit more general.  I'm a bit curious as to why 
the GstStructure immutability is related to the parent's ref count and 
not to some other criteria.  Is the ref count the best way to implement 
immutability?  Is the ref count used because, by design, a GstStructure 
*cannot* be modified when its parent is referenced more than once or 
could it be possible to reference the parent more than once and still 
modify the GstStructure?

In trying to provide C++ bindings, I'm encountering a few difficulties 
with GstStructure immutability because in C++, inadvertently, an object 
such as a GstCaps may be referenced more than once by a simple C++ 
statement (by our design, of course) such as:

caps->set_simple("field1", value1)->set_simple("field2", 
value2)->set_simple("field3", val3);

In our bindings, the set_simple() method of the Gst::Caps class returns 
a "Reference Pointer" (RefPtr)  to the Caps.  (A "Reference Pointer" is 
a class that "wraps" other classes, automatically referencing them and 
unreferencing them when the class goes out of scope.)  We want this 
feature to make referencing and unreferencing of  objects automatic, but 
the multiple references caused in this situation (and others similar to 
this one that I can describe) makes the GstStructure of the caps 
immutable before all the "setting" can be completed.  Can someone see 
our predicament?  Thanks.

-Jose