Benoît Minisini ha scritto: > > > You just have to use the MEMORY instruction to get a memory stream, and > replace the #pointer by #memoryStream. > As you already stated, it is necessary to get informed. I will fetch the wiki for that. > > >>>> It seems that "byref" is ignored in external declaration, but no error >>>> is generated. >>>> >>> Yes, Byref is a non-sense for extern declaration. The compiler should >>> raise an error and not ignore it. >>> >> Why you say so? This is one of many situations where a pointer in C can >> be translated with BYREF in gambas. I don't think that byref for >> external declaration is a non-sense. >> > > It is a non-sense in a Gambas way, because ByRef does not use pointers in > Gambas. See that page for more details: http://gambasdoc.org/help/doc/byref > > ... >> ... >> > You must do that then: > > Private Extern snd_seq_open(Pseq As Pointer, name As String, streams As > Integer, mode As Integer) As Integer > > snd_seq_open(VarPtr(handle), ...) > > VarPtr() must be used when a C-function argument is actually a pointer to a > variable that will be modified by the called function. > I disagree for two or three reasons. First, an external declaration already implies that the declaration refers to something extraneous to gambas, where things are different. This is even more true for gambas, which only needs EXTERN to interface to modules written in other languages, because it has a more natural and efficient way to use its own modules/components. The second reason is that using BYREF in the external declaration, the task of the function is well defined for now and forever. Actually, in that case, BYREF would internally mean something different - but anyway all the declaration takes a totally different way in its implementation. But, at high, logic level, BYREF would keep its intimate meaning. Third, if I can not declare an external parameter with BYREF, I must then use varptr() on every call - this moves the logic from declaration to its usage - and there is more to type on the keyboard. > >> I see it. This is why I stressed on pointers (or MEMORY keyword, which I >> don't know). Another way is to have a PACKED keyword, so the user can >> put holes where needed. Kind of a dirty thing... but I don't believe >> that libffi can do magic - if a compiler chooses to reorder the fields, >> libffi can not know. I say this because I have seen the alsa structures >> - there is nothing that prevents a compiler to do strange things, but >> libasound must be compatible with applications, at least on a >> inter-architecture basis. >> > > I think so. And PACKED can be implemented, but then your sources won't work > anymore on ARM architecture, where non-aligned access are forbidden and lead > to a bus fault! > The same is true with pointers and MEMORY streams. The idea about PACKED is extreme, it lets the programmer do whatever he wants, with all the (few) benefits and (lot of) caveats of such a thing. But are you saying that memory streams have no risk on ARM? The problem is: are you sure that pointers, memory streams and varptr() are needed? Memory streams can be used to peek everywhere in memory, but you know well that this is a non-sense. The only legitimate memory addresses are those returned by some form of alloc(), or indirectly by functions which use, in turn, alloc(), or addresses already in use by variables. All these things could disappear if you implement correctly "byref" and structures, gaining a much more clean design.
> >> I was referring to use or not use some new gambas3 features. I am not >> really interested in writing a gambas drum machine - it is only a >> tutorial on external interfacing. Given that gambas2 and gambas3 has no >> points in common, it is a hard choice. If the pointer interface was >> retained in gambas3, one could explain things that are valid for both, >> and then explain the new features in gambas3. But now, there are two >> tutorials... one for gambas2 and one for gambas3. >> > > Sorry for that! > If it was not funny for me to write a tutorial, I didn't start to do it. So, if *two* tutorials have to be written, there is double fun! :-) ...and double time... :-( Regards, Doriano ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user