[Gambas-user] gb3 RC1: using structures to replace the loss of Mk$ functions
Kevin Fishburne
kevinfishburne at ...1887...
Sun Apr 3 04:14:19 CEST 2011
On 04/01/2011 05:24 AM, Benoît Minisini wrote:
> Using a structure just allow you to directly use the READ/WRITE instruction
> because they have a build-in serialization support. But as you noticed,
> handling a lot of different structures is not handy!
Yes, because I need to keep a transaction history of all the structures
but there's no easy way to store different structures en masse.
> Hopefully, you don't have to use structures. You can create one class for each
> packet type, and let them inherit the same parent class. Each class will have
> its own write method (and read) that will serialize/unserialize the packet
> to/from a given stream (that should be a Socket).
This sounds good, but I'm a guy whose programming skills evolved from a
BASIC dialect in GEM on an Amstrad PC-1512 to GW-BASIC, QBasic,
QuickBASIC 4.5, VB 6 and now GAMBAS. While some build simple projects
using advanced tools, I build advanced projects using simple tools (not
that gb is simple!). Inheritance, classes and objects are a little alien
to me despite reading the documentation. If anyone has an explanation of
these things that even a newbie could understand, I'd be grateful.
If someone can show me an example of Benoît'ssuggestion I'm sure I can
implement it. Benoît's solution applied to my current logic is something
like this:
1. Server/Client: Define a class for each transaction type.
2. Server/Client: Assign values to a class.
3. Server/Client: Send the class as UDP packet.
4. Client/Server: Receive the UDP packet.
5. Client/Server: Parse the UDP packet and assign values to the
corresponding class.
6. Client/Server: Add the class to an array of classes (the
transaction queue/history).
This presumes that an array of classes can somehow store completely
arbitrary classes, which I don't understand.
Also something to note is that each transaction type (or class type in
this case) has an "ID" that identifies the type of transaction. The ID
is sent as the first byte of the packet so that the recipient may know
how to parse the rest of the packet.
As an alternative suggestion Doriano said, "Just an idea: to use the
external function "memcpy()" found in libc. If correctly done, it would
transfer in a single call as much memory as you want from/to strings and
structures."
Bruce also said, "Pure stab in the dark. Could you write a 'helper'
class to replace the Mk$ functions, then you'd only have to develop a
limited amount of code and leave the working code alone?"
Both of these suggestions allow me to keep the old code (which I did
back up), replacing the lost Mk$ functions with equivalents. This works
for me, as the old networking implementation was very efficient and
concise. Benoît's suggestion also works for me, even if it requires more
code, as it seems more elegant.
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?
With respect to Bruce, I figured out how to convert Shorts and Integers
to/from strings, but not Singles. If I can figure out how to convert
Singles to/from a string then my problems are all solved.
--
Kevin Fishburne
Eight Virtues
www: http://sales.eightvirtues.com
e-mail: sales at ...1887...
phone: (770) 853-6271
More information about the User
mailing list