GNOME.org
 

Re: [Vala] Header file generation

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
Vala-list gnome org
http://mail.gnome.org/mailman/listinfo/vala-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]