[gst-devel] event system
Wim Taymans
wim.taymans at chello.be
Wed Jun 20 19:42:04 CEST 2001
On 20 Jun 2001 13:12:58 -0400, David I. Lehn wrote:
<snip>
> >
> > Since they are macros, i.e. #define MY_MACRO - it is common to denote
> > them by capital letters. Then it is easier to tell them apart from real
> > functions. Changing all of these would be really bad, IMO.
> >
>
> Users should be concerned with the interface not the implementation.
>
> Why do you want to tell them apart? What if we decide we need to change
> one of these macros to a function? (ie to add parameter checking or
> whatever) In my opinion the interface should be uniform, not some mix
> of struct macro accessorish hacks and real functions. Certainly there
> are places to use MACRO_SYNTAX() but this isn't it IMHO. glib.h style
> would seem to agree for the most part. There are many function-looking
Macros (with capitals, as with all #defines) are use to access public
members of a datastructure, or in the case of glib/gtk to typecast an
object. They are a cleaner way of doing buffer->data. So the real
question is do you want to have publically accessible members of a
structure at all? I'm not sure how this macro stuff works with language
bindings though..
Access to public members directly is obviously faster than doing a
function call. Since GST_BUFFER_DATA is usually used where speed
matters, this macro is acceptable to me.
#define gst_buffer_set_data (buffer, data) ((buffer)->data=(data))
starts to look a bit ugly IMHO, better make a function of it then.
> macros in there. I'm sure someone could come up with a more technical
> discussion about how evaluating FOO(bar) shouldn't return an lvalue that
> you assign to. non-intuitive compared to most code. I've also never
> seen this style used before... confused me first time I saw it.
Adding get/set methods to all the buffer fields would require 18
methods, I'm not sure the codesize/API tradeoff is worth it... maybe it
is considereing that *only* GstBuffer has this 'officially supported'
macro API...it doesn't even have *real* get/set methods.. hmm..
Wim
More information about the gstreamer-devel
mailing list