Re: [Vala] inline C

[Hans Vercammen <hveso3 gmail com>]

On Sat, 2008-12-13 at 22:05 -0500, Yu Feng wrote:
> On Sun, 2008-12-14 at 00:55 +0100, Hans Vercammen wrote:
> > > > > On Sat, 2008-12-13 at 23:44 +0600, Ildar Mulyukov wrote:
> > > [...] 
> > > 1. inlining asm is most unportable. But this did not prevent from  
> > > adding it to GCC. Surely it should be documented as limiting  
> > > portability.
> >
> > Vala is not a preprocessor for gcc, although I'm sure many people look
> > at it this way. Embedding ASM/C could also horribly break the automatic
> > memory management, one of the most overlooked key features. 
> Is the 'break' an obligation? The embedded code can always be written in
> a way such that conforms the automatic management.

Of course not, a skilled programmer will probably take this this into
account. Never the less, the validation of embedded code is outside the
vala scope, unless the compiler is capable to do so (which I doubt is
within the objective).

> > Also, I
> > expect my vala code to go smoothly through the gcc compiler and to abort
> > otherwise. Embedding might be nice in some cases, but no doubt it can
> > generate uncontrollable side-effects. 
> Uncontrollable by whom? If the programmer is skillful enough, she can
> always control the side-effects of any piece of code written by
> herself. 

Again, I agree, but still I'm not sure if it's a good idea to put this
validation outside vala, which would basically render vala as a
semi-intelligent preprocessor for gcc, nothing more. I was under the
impression vala would sleekly handle GLib/GObject code without
side-effects and worrying about memory management, which until now
certainly satisfied my needs over using C++.

> > Like Jamie said; if there is
> > specific need you can import the exotic stuff by using extern and
> > dedicated c files or use the vala api files.
> I would like to add to this point: 
>
> dedicated c files also make the project layout cleaner. 
>
> The need for inline low-level code usually indicates either that an
> extra level of abstraction is needed in the project, or that the current
> boundary between low-level and high-level semantics is inappropriate.

I definitively like your vision on this, but it brings us back to the
actual need of embedding ASM/C.

> Machines can be happy if the ccode are written carefully, but a
> bilingual text is usually difficult for human beings to understand; to
> me this is more convincable than any other arguments against inline C.

I don't really understand this one, could you explain?

Hans