My point on this.
I took a look at gtkwidget.c and gtkcontainer.c.
GtkWidget has a parent reference to GtkContainer so it should have
circular header files.
It turns out they avoid the cycle by defining the parent member of
GtkWidget as a GtkWidget instead of what it should be (GtkContaienr).
Therefore my opinion on the cycles is that there should not be
unsolvable typedef cycles ( with .h, -priv.h and .c) in a properly
designed program, because these cycles represents solid cycles in your
Class atlas; which (as I can remember) should be avoided as possible. If
one is detected, VALA should throw an error -- even if vala can handle
it; it should throw an warning for this poor design.
Then for the 'combination of header guards', I suggest to have one
single header file collecting all these ill typedefs, with a syntax
like
valac --cycle-typedefs={file-to-collect.h} CODE.
(without this parameter, vala can simply panic on cycle typedefs)
Regards,
Yu
On Sun, 2009-01-11 at 16:04 +0100, Jürg Billeter wrote:
> On Sun, 2009-01-11 at 16:41 +0200, Arto Karppinen wrote:
> > Jürg Billeter wrote:
> > > * Header file interdependencies
> > > Header files often depend on other header files and sometimes these
> > > dependencies form cycles. These cycles are currently detected by the
> > > compiler and resolved as far as possible - for example, by moving
> > > typedefs to other header files and reordering includes.
> > >
> > > While this works in many cases, there are situations that cannot be
> > > solved with the current approach, depending on what type you declare
> > > in what .vala file. There are also situations that could be solved
> > > with the current approach but are not implemented yet; it would
> > > complicate the code even further.
> >
> > It should be possible to handle the typedef problem by simply defining
> > all typedefs before any includes in .h files and putting all includes
> > after typedefs. Something like this:
> >
> > #ifndef __HEADER__
> > #define __HEADER__
> >
> > // ALL typedefs here.
> > typedef gint my_int;
> > typedef void (*functionpointer) (gint i);
> > typedef struct _MyClass MyClass;
> >
> > // ALL includes here.
> > #include "something.h"
> > #include "other.h"
> >
> > // Everything else below
> > struct _MyClass {
> > ...
> > };
> >
> > void function_a(gint a, gint b);
> >
> > #endif
> >
> > If you do this, then it does not matter in which order you include
> > the
> > headers, typedefs are always defined as long as you include the
> > correct
> > header. The point of this ordering is to achieve a situation where
> > all
> > typedefs are defined before any other part of the header files are
> > parsed by the compiler. Once all typedefs are defined, it does not
> > matter in which order the rest of the headers are parsed.
>
> This does not work in all cases, unfortunately. A simple example is if
> the parameter type of a delegate is declared in another file.
>
I don't understand this example.
> Another example is the situation where you have class A declared in
> A.vala and class B declared in B.vala. B is a subclass of A, so it needs
> to include "A.h". A has a method that takes an object of type B as
> argument, so it needs to include "B.h".
>
This is the Gtk example above.
> The issue now occurs with the combination of header guards to avoid
> multiple inclusion. If you first include "A.h" from some .c file, it
> will process the typedef for the struct A, then include B.h, which will
> add the typedef for struct B.
>
> B.h will then try to include A.h, however, nothing will be processed as
> the header guard prevents multiple inclusion. The following definition
> of the struct B requires the definition of struct A, which will only be
> processed after B.h has been read completely, so this will result in a C
> compiler error.
>
> Jürg
>
> _______________________________________________
> Vala-list mailing list
> [email protected]
> http://mail.gnome.org/mailman/listinfo/vala-list
_______________________________________________
Vala-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/vala-list
