[Gambas-user] Some new features in Gambas 3

[Jussi Lahtinen]

I think native functions should be for general use only.
And I don't think MkXXX$() functions now represents good practice to be used
as now intended.
If your software runs on linux (what else?), you probably still need to
write these functions by your self
to correct endianess accordingly to sender/receiver architecture mismatch.
http://en.wikipedia.org/wiki/Endianness#Endianness_and_operating_systems_on_architectures

If we have problems to figure out proper usage for these functions, then I
don't think
they really have any general usage, and therefore Gambas should not have
native support for them.

But I think there are at least two reasonable options...

1. Change behaviour of MkXXX$() functions to be more like conversion
functions, that has 'locked' endianess.
This is probably best option.

Or 2., Kevin, maybe you should pick up MkXXX$() functions form current
Gambas source code for your own library.

But of course this is all up to Benoit!
Regards,
Jussi



On Sat, Jan 1, 2011 at 21:05, Kevin Fishburne <
kevinfishburne at ...1887...> wrote:

> On 01/01/2011 11:34 AM, Benoît Minisini wrote:
> >>> 2) A new set of native functions named Mk<XXX>$() to create a string
> from
> >>> the
> >>> memory representation of a value. For example, MkShort$(1234) returns
> >>> Chr$(210)&  Chr$(4) (on a little endian machine).
> >> I'm updating GambasTester to handle new commands and features.
> >>
> >> And I don't quite understand these new functions...
> >> MkByte$(65) returns "A" which is expected if string is created with
> ascii
> >> encoding.
> >> But MkBoolean(True) returns "^A", and according to documentation boolean
> >> value size is one byte
> >> in memory. This string occupies two bytes?
> > "^A" is the way the IDE console displays Chr$(1).
> >
> >> But moreover, what is intended use of these functions?
> > One ask them to forge a string of binary data to be sent on an UDP
> socket. But
> > this is not necessarily the right way to do that, as data on the network
> must
> > be endianness-agnostic. So maybe these functions are not really useful
> indeed.
> It's hard to know what uses people will put functions to once they're in
> the wild. The original use was what Benoît described. Whether endianness
> is an issue depends on what the UDP data is being sent to or received
> from. In my case it's the same program on the same architecture, so it
> works fine. I think a note in the documentation about endianness would
> help should someone want to use the functions.
>
> It seems to me a little strange to have ASC and STR$ but not equivalents
> for other datatypes. Some day some other programmer will see these
> functions and be extremely happy, probably for some purpose we haven't
> yet imagined.
>
> --
> Kevin Fishburne
> Eight Virtues
> www: http://sales.eightvirtues.com
> e-mail: sales at ...1887...
> phone: (770) 853-6271
>
>
>
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment,
> and,
> should the need arise, upgrade to a full multi-node Oracle RAC database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Gambas-user mailing list
> Gambas-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user
>