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 <[email protected]> wrote: > 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 > _______________________________________________ > 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
