Re: gstreamermm header problem

[Daniel Elstner <daniel kitta googlemail com>]

Hi,

Am Freitag, den 15.05.2009, 11:05 -0400 schrieb José Alburquerque:
> On Fri, 2009-05-15 at 16:57 +0200, Daniel Elstner wrote:
> 
> > I think these constants should probably be mapped to enums, and the
> > corresponding name strings looked up when doing the conversion from C++
> > to C argument types.
> 
> I'll certainly look into this.

A similar pattern is used for the built-in stock IDs in the Gtk::Stock
namespace in gtkmm.  We have a small Gtk::StockID class which implicitly
converts from either Gtk::BuiltinStockID or a stock ID string.  It may
be useful as an example of the basic idea.

Just don't make the same silly mistake I made back then.  That is,
instead of a Gtk::BuiltinStockID struct with a const char* member, I
should have defined a Gtk::BuiltinStockIcon enum, and then have used the
enum value as an index into one long static C string in the source.

I think we should convert Gtk::BuiltinStockIcon to the enum index scheme
in gtkmm 3, because it would get rid of a sizable number of exported
symbols in the dynamic library, thereby reducing the time spent in the
dynamic loader on application startup.

For detailed information on this topic, see Ulrich Drepper's excellent
paper "How to Write Shared Libraries"[1], section 2.4.3 "Arrays of Data
Pointers".  There is a small tool in the appendix to auto-generate the
offsets into the string.  However, in our case we can probably get away
without complicating the build process, since gmmproc already allows
arbitrary M4 snippets in the input.

Caveat: I'm rambling here.  I haven't actually looked at the gstreamermm
code, so my suggestions may be totally off the mark.  You don't need to
go to these lengths for just two or three symbolic constants.  Exporting
them as const char * constants would probably work fine, except that you
would lose the benefit of having a distinct type.

--Daniel

[1] http://people.redhat.com/drepper/dsohowto.pdf