[gst-devel] why is gst_element_class_set_details only for use in base_init function?

[Stefan Kost]

Hi,

can you please file a bug about this in http://bugzilla.gnome.org.  I will look
at this real soon.

Stefan

Shixin Zeng schrieb:
> Yes, I think I find a case that this happens:
> GstPipeline is derived from GstBin which is derived from GstElement
> 
> In GstBin's base_init function:
> static void
> gst_bin_base_init (gpointer g_class)
> {
>   GstElementClass *gstelement_class = GST_ELEMENT_CLASS (g_class);
> 
>   gst_element_class_set_details (gstelement_class, &gst_bin_details);
> }
> 
> in GstPipeline's base_init function:
> gst_pipeline_base_init (gpointer g_class)
> {
>   GstElementClass *gstelement_class = GST_ELEMENT_CLASS (g_class);
> 
>   gst_element_class_set_details (gstelement_class, &gst_pipeline_details);
> }
> 
> So, during registering the type GstPipeline,
> gst_element_class_set_details will firstly be call via
> gst_bin_base_init () and secondly via gst_pipeline_base_init().
> 
> And there might be some other cases.
> 
> Actually, there is no other harm doing in base_init() instead of doing
> in class_init() except for some unnoticeable efficiency loss, as far
> as I understand.
> 
> However, I didn't test this, this is just the judgment from my
> knowledge of GOjbect system. Please correct me if I'm wrong.
> 
> On 10/26/07, Stefan Kost <ensonic at hora-obscura.de> wrote:
>> hi,
>> Shixin Zeng schrieb:
>>> Hi, all
>>>
>>> When I'm trying to write a source element, I read this on the
>>> documentation of the gst_element_class_set_details. I'm a bit
>>> confused. As far as I understand, in Gobject system, base_init is used
>>> for dynamic data member initialization. However, the field "details"
>>> in GstElementClass is not a dynamic allocated space, so it should be
>>> initialized in class_init function instead of base_init function.
>>>
>>> For example, a class A derived from GstElement, then when class A is
>>> registered, it will involve:
>>> 1. Allocate space
>>> 2. call GstElement's base_init
>>> 3. call A's base_init, /* it calls gst_element_class_set_details to
>>> set the field "details" */
>>> 4. call A's class_init
>>>
>>> Now, another B is derived from A, then the sequence will be like:
>>> 1. Allocate space,
>>> 2. call A's base_init; /* set field "details" as mentioned above */
>>> 3. call B's base_init; /* set filed "details" again */
>>> 4. call B's class_init
>>>
>>> So, apparently, "details" was set twice in case of B. However, if we
>>> call gst_element_class_set_details, this kind of redundancy can be
>>> avoid. So, any particular reason why this function should be call in
>>> base_init instead of class_init?
>>>
>>> Thanks.
>> None of the baseclasses call gst_element_class_set_details and we don't subclass
>> finaly elements currently. Did you found a case where it actually happens twice.
>> I don't remember it there was technical reason for doing it in base_init
>> (registry or so). I will investigate.
>>
>> Stefan
>>
> 
>