Projects / GOB

GOB

GObject Builder (GOB) is a simple preprocessor for easily creating GObjects (glib objects). It reads a class description file with inline C code and produces .c and .h object files for you. It allows you to easily use most of the features of the GObject system and avoids typos by reducing the amount of code needed. In general, the amount of code is about the same as for OO languages such as Java or C++, but you still have to only use C and you get all the power of the GObject system.

Tags
Licenses

Recent releases

  •  14 Dec 2013 21:10

    Release Notes: GTK3 support, names of signals and properties, and fixes for deprecated functions.

    •  19 Dec 2012 03:29

      Release Notes: Bugfixes.

      •  06 Jan 2011 19:52

        Release Notes: This release adds ctop (works like alltop but only in the C file), build fixes for Cygwin, and some minor fixes.

        •  02 Apr 2010 20:15

          Release Notes: This release fixes segfaults, has the correct defaults for floating point values, and handles DOS format input files.

          •  21 Jul 2009 15:58

            Release Notes: Function attributes. Simple destroy, finalize, and construct override support. An afterdecls C block. Minor other fixes/improvements.

            Recent comments

            12 Apr 2001 23:33 vicious

            Re: C vs. GTK object system

            >
            > It's not too different. That's good.
            > But it gives you less code, clearer
            > code, and compile-time type-safety.
            > That's good too.
            >


            GOB gives you quite a bit of compile time type

            safety as well. Though with a focus that this

            will all work from C code (that is not all your

            code has to be in GOB, and in fact shouldn't).

            Though compile time typesafety is many times

            overrated. I'm more of a fan of runtime

            typesafety, since it will catch all type errors,

            though with the caveat that the code must run for

            you to find errors. That said a certain amount of

            static typesafety always helps.

            >

            > I don't think it's an advantage that

            > GTK+ in C makes subclassing difficult.

            > Gtk-- in no way forces you to subclass,

            > or emphasises that technique. That's

            > just something that's available to you,

            > whereas the difficulty of doing it in C

            > means that people don't choose that

            > design technique when they should. And

            > code becomes less clear.

            > I guess GOB is meant to fix this. It's

            > just that C++ seems like a nicer way to

            > do that.

            >

            I didn't mean that this is because GTK+ makes it

            hard to subclass. Just that the focus is

            different. Yes everything that GTK+ object system

            does is possible in C++, and the other way around

            as well (though if you wish to do some things in C

            you get into some deep voodoo land).

            I'm still way more profficent in C, and don't

            enjoy C++ very much. You can usually stare at a

            piece of code in C and figure out what it does

            exactly. With C++ there could be many things

            going on behind the scenes that you would have to

            look up in the class definition. Example, in C no

            code is run until you explicitly call a function.

            In C++ things like constructors, destructors and

            various overloaded functions get run even when the

            syntax doesn't say something would run.

            And this is where the original C++ (or cfront)

            differ substantially from GOB. all GOB does is

            write the boilerplate for you. It does not

            attempt to parse or change C code. It does not

            understand C almost at all (all it can do is count

            parenthesis and braces).

            I have made an object system that is statically

            typesafe and easy to derive purely using the C

            preprocessor. However GTK+ doesn't do this. I'm

            very pragmatic on this point. I want to use C. I

            like GTK+. Thus GOB. GOB doesn't have the things

            that I don't like about C++, and it has an easy

            syntax for making objects, while allowing me to

            still just use C. I'd be happier if GTK+ object

            model didn't require so much boilerplate and was

            more c preprocessor friendly, but it isn't. GOB

            isn't written for the purpose of writing GOB, it

            is something to scratch an itch.

            12 Apr 2001 17:48 murrayc

            Re: C vs. GTK object system

            > You can get
            > things like
            > signals for C++ with addon libraries,
            > and you can
            > get a type system for C++ with addon
            > libraries.
            > You can get named arguments as an
            > addon too.


            Yes, you can get them all from the same 'add-on library'. That's a language binding.

            > But
            > then it's not much different then
            > coding with
            > GTK+.


            It's not too different. That's good. But it gives you less code, clearer code, and compile-time type-safety. That's good too.

            > If a project for example uses
            > GOB, it
            > only uses GOB for those few classes it
            > has. It
            > does not emphasize subclassing for
            > things it's not
            > needed for.


            I don't think it's an advantage that GTK+ in C makes subclassing difficult. Gtk-- in no way forces you to subclass, or emphasises that technique. That's just something that's available to you, whereas the difficulty of doing it in C means that people don't choose that design technique when they should. And code becomes less clear.

            I guess GOB is meant to fix this. It's just that C++ seems like a nicer way to do that.

            12 Apr 2001 14:16 vicious

            Re: C vs. GTK object system

            >
            > I'd be interested to know how you
            > think that the C GTK object system is
            > more flexible rather than just more
            > long-winded.
            >
            >


            It depends on your priorities for coding. C++ is

            quite a different beast. You can get things like

            signals for C++ with addon libraries, and you can

            get a type system for C++ with addon libraries.

            You can get named arguments as an addon too. But

            then it's not much different then coding with

            GTK+. The GTK+ (and GObject nowdays) comes with

            all these and the unerlying language is much

            simpler to understand. With GTK+ objects the

            emphasis isn't given on subclassing and making

            everything as an object. You still do mostly C

            coding. If a project for example uses GOB, it

            only uses GOB for those few classes it has. It

            does not emphasize subclassing for things it's not

            needed for. As owen once put it, it is more a

            component system then an object system

            I wonder why everybody mentions C++ as "the OO

            language". If I was to mention a language that

            GTK+/GOB would be closer to, it would be java or

            Objective C. At some point in the future I plan

            to use Java, when that gets more mature. Java is

            very nice as a language, but I'm not too crazy

            about it's libraries and compiler support.

            26 Feb 2001 11:56 murrayc

            Re: Back to the past
            I meant 'saying that moc requires only C plus plus', but the plus sign doesn't show up.

            26 Feb 2001 11:54 murrayc

            Re: Back to the past
            Quite right. I don't see how this can be said to require only C. That 's like QT saying that moc requires only C . If you want a better C, then it's already been done.

            Screenshot

            Project Spotlight

            OpenStack4j

            A Fluent OpenStack client API for Java.

            Screenshot

            Project Spotlight

            TurnKey TWiki Appliance

            A TWiki appliance that is easy to use and lightweight.