[Gambas-user] gb3 RC1: using structures to replace the loss of Mk$ functions

[Doriano Blengino]

Il 03/04/2011 15:33, Jussi Lahtinen ha scritto:
>> With respect to Doriano, how would one use the memcpy() statement in
>> GAMBAS? I see from Wikipedia that "void *memcpy(void *dest, const void
>> *src, size_t n);" shows the syntax in C. My two questions are, how do
>> you call external library functions in gb, and how would you translate
>> the C syntax to gb syntax?
>>
>>      
>
> Public Extern memcpy(pDest As Pointer, pSrc As Pointer, size As Integer) In
> "libc:6"
>
> Then example in Gambas;
> memcpy(Array1.Data, Array2.Data, Array2.Count * SizeOf(gb.Integer))
>    

Perhaps a more deep explanation of this idea (using memcpy) is due, but 
I must anticipate that I have no idea of the code the Kevis has right 
now. Moreover, I don't know well how Gambas2 and Gambas3 cope with 
sockets and, moreover further, I don't know well how Gambas3 works with 
pointers and addresses. So this memcpy could be totally crap.

I imagined that the actual situation is something like this:

When the server communicates some data to the client, it builds a string 
formed by several simple fields, and then sends this string in a single 
packet. It does this by using some convertion routines (mk_something$?).
The client receives a packet, composed by a single string, and breaks 
this string into the original fields basing on the first character of 
the string, again using some conversion routine.

If these conversion routines are no more available, two problems arise: 
how to send several fields as a single packet, and how to break a single 
packet into several fields. While it is true that structures would 
elegantly solve this kind of problem, it is also true, as Kevin said, 
that a lot of lines of code must be written - If I well understand, 
these different structures counts up to a hundred or perhaps more. If, 
instead of structures which, by the words of Benoit, are mainly intended 
to be used to interface to external libraries, one should uses classes 
(again Benoit words), Kevin had to produce a hundred *files*. Nice... 
But even so, objects/classes are not "better structures", they are very 
different, because they carry a lot of more things, and overhead (both 
at write-time and at runtime). Is this overhead good? Yes, if it is 
useful. No, if the only thing I want is to aggregate data. The only good 
added thing in using objects vs structures it's their inherited 
serialization mechanism, but perhaps this is not enough advantage to 
switch to them.

So, when Kevin lamented about the missing functions, I simply thought 
that he missed a way to copy data from a string to a structure. This 
_could_ be easily done with memcpy(). But then I forgot to think to the 
other problem, how to construct a string from a structure. Is this a 
problem too, right? Well, this is different because, if I am not wrong, 
gambas does not let you to write inside its strings. And, at last, I 
think that Kevin would be happy to keep its code as much as possible. I 
mean - to write a lot of code to declare structures is a big deal.

So, one solution could be this one: you know how to transform integers, 
but not floating point? Well, transform them in ASCII representation... 
something like "0012.428". Use a fixed length for units and decimals - I 
think that in your game there are not numbers so extreme to require 
exponential notation like "1.3E+12".

Otherwise, you have to write your structures or, perhaps, objects. 
Better would be to write all the structures in a single file, in order 
to share that file between client and server (an "#include" would be 
perfect, if available). But then, it is difficult to keep all of them in 
an array... so we are at the beginning again.

I think that a general mechanism to move bytes around, in Gambas, would 
be useful for a lot of things. In fact C, a mature and robust language, 
has powerful structures, but it has also memcpy(); I could cite other 
languages too. It would solve completely the "Kevin Problem".

To conclude, I am not able to find a solution, but may be that the trick 
of using ascii for numbers can help.

Regards,

-- 
Doriano Blengino

"Listen twice before you speak.
This is why we have two ears, but only one mouth."