On Tue, 2011-11-08 at 08:40 +0100, pancake wrote:
Hi On 07/11/2011, at 20:58, Luca Bruno <lethalman88-Re5JQEeQqe8AvxtiuMwx3w public gmane org> wrote:2011/11/7 Tal Hadad <tal_hd hotmail com>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 looklike: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
Attachment:
signature.asc
Description: This is a digitally signed message part