Re: [Vala] How to generate "inline" C functions?



Inline intet module symbols can be defined as static functions in .h they are included once, removed if 
unused (with gcc warning)

If using inline in different .c will not result in inlined functions unless you pass all .c files to the 
compiler in a shot.

Another solution would be to embed those functions as cpp macros, gcc will not warn and the code will be 
inlined.

But this will make the code less debuggable if function is long and compiler errors will be less userfriendly

On 11/11/2011, at 20:19, Maciej Marcin Piechotka <uzytkownik2 gmail com> wrote:

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 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
_______________________________________________
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]