On Tue, 2011-11-08 at 08:40 +0100, pancake wrote: > Hi > > On 07/11/2011, at 20:58, Luca Bruno > <[email protected]> wrote: > > > 2011/11/7 Tal Hadad <[email protected]> > > > >> > >>> Is there any CCode attribute to make the generated C function "inline"? > >>> Or, is it possible to generate C macros instead of functions with vala? > >>> > >>> For example: > >>> class Test { > >>> inline public void func1() { > >>> }Vala tutorial sadly doesn't say a word about it, but it shell look > >> like:public inline void func1() {}This onw works currently in vala.> > >> [Macro] > >>> public void func2() { > >>> } > >>> } > >> > >> This is sound a great feature request.But I would like that the macro > >> could also not be function-like, butalso be able to define functon, > >> varibles, ...(i.e. full featured CMacro). > >> > > > > Vala produces static functions when possible, and gcc inlines them when > > possible. So this is feature is already there. > > > > I thought inline was already supported keyword in the past.. >
It is a keyword - at leas was short time ago. It is passed for static
functions but not for exported ones.
> A way to do this is by using ccode or a define in a .h
>
> But to be sincere... Inline is a premature optimization... Something like
> register does. They are properly used by the compiler optimization correctly,
> so users should not use them.
>
It would be nice to have them for cross-module optimization. I have at
least one use-case (foreach in libgee 0.7/0.8[1]) - trade off between
exposing internals (ABI instability) and speed.
I guess the bigger problem is cost of calling functions and static type
analysis - I'm not sure if it can be removed when keeping backward
compatibility with GObject:
List<Gtk.Window> list = new ArrayList<Gtk.Window>();
// Each call involves (in addition to implementation):
// - 1 function "call"
// - 2 jumps to register
// - 2 reads from *Class structure
list.iterator();
list.iterator();
In ideal situation:
List<Gtk.Window> list = new ArrayList<Gtk.Window>();
list.iterator(); // we can just call real method - which can be inlined
// with lto
list.iterator();
> It's different case for 'volatile' do vala supports this? Maybe we could add
> a ccode directive like cname, but to be appended before the return type.
>
No and from what I understood from discussion with Jürg it will not -
the only justified use of keyword is system programming, which is not
area targeted by Vala.
It is possible to use as cname (see GLib.Atomic).
> [CCode (ctype="inline")]
> int foo() {...
>
> This way we can let the user do those tricks without messing the syntax with
> stuff 99% users will missuse.
>
> Functions defined in Macros should be forbidden by the compiler. They just
> mess the code and the debuggers use to fail when stepping into them. Lines of
> code loss their sense and can result on weird compiler errors.
>
Don't forget the problems with FFI from say Haskell, libffi etc.
>
> >> Another question is, is it possible to use bit-field in vala classes?
> >>> Like this:
> >>> class Test {
> >>> private bool b1 : 1;
> >>> private bool b2 : 1;
> >>> private bool b3 : 1;
> >>> private uint i1 : 4;
> >>> }
> >>
> >
> > It's not possible. This is something that could be trivially implemented
> > using a CCode argument like [CCode (bitfield = 1)] or such, without adding
> > new syntax.
> > If you have a good use case, you can request the feature at
> > bugzilla.gnome.org .
> >
>
> I remembee this was discussed some years ago and it was rejected because
> implementation depends on C compiler and architecture.
>
> Bitfields are not portable. And vala code aims to be coherent everywhere.
>
> If you want bitfields use a .h and a .vapi defining such struct. You will
> probably then need some ifdef tuning depending on the endian of the target
> platform.
>
Hmm. Wouldn't the need rather depend on particular use?
If one is using bitfild to use mmap I/O it's asking for trouble even on
the same endianess - but so is the whole mmap I/O as we may want to
communicate in future with different endianess.
Regards
[1] https://bugzilla.gnome.org/show_bug.cgi?id=643993
signature.asc
Description: This is a digitally signed message part
_______________________________________________ vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
