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

[Doriano Blengino]

Kevin Fishburne ha scritto:
> On 04/01/2011 01:15 AM, Bruce Bruen wrote:
>   
>> On Friday, April 01, 2011 01:17:50 PM Kevin Fishburne wrote:
>>     
>>> I'm finding that the task of replacing the Mk$ functions with structures
>>> for UDP packet client/server transactions is a massive undertaking. [...]
>>>       
>> 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?
>>     
>
> That's what I was doing before the functions were created. [...] I also 
> lost that code after implementing the new gb functions as GAMBAS doesn't 
> support revision history or whatever you call it, and my dumb ass didn't 
> backup the functions to a text file somewhere.
>   
You are not alone in this world... it is about a year now that I search 
for the source of an old program I wrote and use often.
> If anyone wants to show the code for converting the basic datatypes 
> (short, integer, single, double) to a string and converting that string 
> back to its basic datatype that would be a nice hack. Basically what I 
> was doing in the first place but with the float datatypes.
>   
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..
I am sorry I can't test/develop it: I am stuck with gambas 2.0.0 which 
seems to be quite different from the version you use. But you or someone 
else, with a little help from Benoit, could easily set it up, if this 
idea is viable.
> Also, for anyone curious, the reason the functions were removed is 
> because they weren't endian-agnostic. In my case it didn't matter, as 
> I'm not sending data to some ARM device or the like. Why different CPU 
> architectures don't put bits in the same damn order I I'll never know.
>
>   
Uhm... it seems a very strange reason to me. Perhaps all this is coming 
from the not-clear idea that BASIC (and VB, and Gambas) has of itself. 
Basic wants to be easy; wants to be powerful; wants to be versatile. But 
these three things conflict too much often: sometimes it is impossible 
to have something which is at one time powerful and easy.
What category where those mk$ functions in? Probably "versatility", in 
an attempt to add some extended functionality not supported by the 
language (typecasting). Typecasting is not easy, you must know what you 
are doing. If you don't know how data are stored in memory, you can not 
easily use typecasting. So Basic wanted to add typecasting without 
having you to know what you are doing. Instead of having a single and 
general way to do something, Basic introduced a number of mkXXX. But 
now, with user-defined data types, those mkxx are not sufficient anyway. 
And they where not sufficient in the case of different computers, having 
different sizes or bit order for the same Gambas type. The only way 
would to use an internal standard like: "Bit order is big endian. 
Pointers are 32 bits. Integers are 32 bits. Floats are 8 byte IEEE 
extended." and so on. This is a lot of work (and overhead of the 
language). Perhaps Gambas could add a single function like 
"MkString(datum as anytype) as string" and its counterpart "anytypevar = 
CvString(...)". But doing so, surely there will be a number of cases of 
misunderstanding and misusage.

A last word about "different CPUs with different bit order". I think 
that this is unavoidable. Human beings can not even agree on measuring 
liquids with litres and distance with meters, or to use dots or commas 
to separate decimals. If all the CPU makers agreed on making 64 bits, 
little endian CPUs, how many years would it last, until the new 128 bits 
CPU will be the new standard? You say that you are not interested in 
talking to ARM devices. But on this very list I've read about running 
Gambas apps on smartphones or something like that. So... what to do? 
Should everyone migrate to Java? Java runs on a lot of different 
processors, it's very "high level", it is interpreted and compiled. It 
has everything. And be prepared to triplicate the number of lines of 
code... :-)

If I were Benoit, I would have leaved those mkxxx in place, neglecting 
the agnosticism.They were dirty things time ago; they still would be 
dirty things; nobody is perfect; if you don't like them, don't use them.

This email is a bit too long. Nobody is perfect.

Regards and, apropos, I went to see you Sanctimonia links. It is 
fascinating, the kind of game I like most, like Civilization and 
Nethack. As soon as I will have some spare time I will try to try it...