PureBasic Forums - English

Posted: **Thu Nov 06, 2003 1:22 am**

erm, wait.. 64K is the limit right? And your saying that will hold 64,000 characters? Which mean each Char is a Byte (represented from 0 to 255). So that includes all of the extended ascii?

Posted: **Thu Nov 06, 2003 2:08 am**

> People have been processing binary data using Basic strings for several decades.
> Where are your "tablets of stone" that say this is now considered "misuse".

Maybe it is because i don't have a strong Basic programming background,
but i just don't like the idea. Ok, let's not call it misuse, but IMHO, it not a
main design aspect of a string management to be able to process binary
data. If it works, why not use it that way, if not, find another way...

Ok, let's discuss this from another point of view...
We (me and some others) have discussed this topic a lot allready with fred,
and we all agree, that the current system has to be changed in some way.
It is not only, that the buffer-system has a size limit, it is also, that it is not
thread save. So we are currently searching for a better way.

I've been thinking a lot about the NULL-termination thing. Processing the
strings with a length description is faster, because you don't have to
search through the string in order to find the end, you know where it is.
So, we could make the string operations work with that size descriptor,
and just add a NULL, to make it compatible with the API ad external dlls.

Sound's very simple, but there is a problem. I'll explain that with a little
API call. Usually, we do something like this:

Code: Select all

Directory$ = Space(500)
GetWindowsDirectory_(@Directory$, 500)
Debug Directory$

This works perfectly for now, because when you use the Directory$
variable in the next string operation, only the part up to the NULL char
will be used, so it doesn't matter, how long the allocated buffer really is.

With the above described system, we get a problem. Since it would only
rely on the length-descriptor, PB would still think, the string is 500 chars
long, even though, the real string is only a few bytes.

Now, to solve this, you could either go the VB way, and convert every
string that is passed to an API function, but this is almost not possible,
because for example, you store a string pointer in a structure, and pass
this to a API function (which is often the case), how should PB predict that,
and convert the string?? Another way would be to do a 'cleanup' after the
API call, that then checks for the NULL character, and updates the length
descriptor. But you run into the exact same problem here, as you can't
predict, which API really uses a string, you'd have to do this 'cleanup'
after every API call, and with every string. This is too much slowdown.
And I only talked about API calls here. It is the same with any DLL you
want to access.

The point is: I agree with unlimited and threadsave strings, but i see no
way, in which we could get rid of the NULL-termination.
If somebody has a brilliant idea for that, i'm open to suggestions.

I hope, you understand my point a bit. It's not about me thinking that
putting binary data into a string is somehow 'bad', it's just that it isn't
that easy to implement.

Timo

Posted: **Thu Nov 06, 2003 2:24 am**

i'm not brilliant, but here's a suggestion:

Code: Select all


1. add a new type .c (a fixed length string):

  var.c[n] declares a 'character' variable, length n bytes

2. interaction with normal :-) strings:

  var.c[5] = "123"

    - put "123" + NULL in the first four bytes of var.c
    - it actually reserves 5 bytes, even though only 3 are used

  var.c[5] = "1234567"

    - put "12345" in the five bytes of var.c

  var.c[2] = "1"
  var.c[100] = "1"

    - effectively, resize var.c

3. normal string commands

  a.s = "1234abc"
  var.c[10] = ucase(a.s)

    - create a var.c of length 10, fill it with  "1234ABD" + NULL
 
  a.s = var.c

    - convert var.c to a normal string (zero terminated) then assign it to a.s

4. in other words...

  basically, use anything right of the '=' character that is a normal
  string (zero terminated) string, and the whole expression will
  be evaluated as if it was a zero terminated string, upto filling
  of the actual fixed length string var.c

  i'm not sure, but i guess this could be implemented, allows inclusion
  of strings fields in structs for api calls (i HATE pooking, that's as
  old as a vic20)

  this also allows dirty memory reservations on the fly (instead of
  malloc(), just say var.c[64000] = "") and it should not affect 
  speed in any significant way

is this any good or should i dump it into the waste bucket?

Posted: **Thu Nov 06, 2003 3:31 am**

Fixed length strings are usefull inside structures for example, but as a genral
way to handle strings, it not very usefull. It is the same as in C actually. The
bad thing is, that the programmer has to always check, if the result of
a string operation will fit in the target string.

So... not in the waste bucket, but as a different feature request (which you allready did a time ago)

Timo

Posted: **Thu Nov 06, 2003 5:23 am**

If somebody has a brilliant idea for that, i'm open to suggestions.
... it's just that it isn't that easy to implement.

Why not look at already existing open source code to see how they did it

Everybody here knows XBasic right.
XBasic and XBlite generate asm code for i486 and you can have 2147483647 characters and you don't have to resize a variable to hold more or less character.

When I work with it, I never ever have to poke a string in order to work with API to get it going.
Why not look how Max Reason build his string system 10 years ago?
It's all open source.

I'm not a asm guru so I can't do it myself...

BTW: the same applies to 64bit integer/floating point 128bit complex numbers etc.

Just a friendly meant suggestion...

Posted: **Thu Nov 06, 2003 8:17 am**

And if you don't include zero's

otherwise it may be truncated...

Posted: **Thu Nov 06, 2003 9:27 am**

>I've been thinking a lot about the NULL-termination thing. Processing the
strings with a length description is faster, because you don't have to
search through the string in order to find the end, you know where it is.
So, we could make the string operations work with that size descriptor,
and just add a NULL, to make it compatible with the API ad external dlls.

These things are well solved in PowerBasic, in VB and to be kompatible to Standard basic is an advantage. So why invent the wheel from new?

Make two datatypes
CSTRING - that is exactly a null-terminated string with a fixed lenght.

LString (LongString)
That is the standard-system-windows strings like desribed in my posting. Won't make you a lot of trouble as windows does the allocation and deallocation for you.

As Purebasic IS a compiler, it can decide at compiletime what to do in each case. Ã

Posted: **Thu Nov 06, 2003 5:38 pm**

Personal wishlist for 4.00:

usigned variables, ok, its possible to simulate this, but its what we here in Sweden call "fulhack" (ugly hack)
will kill for bool-operations (bool.bl, ReadBool, PeekBool, PokeBool etc) (also "fulhack"-able, but wtf =P)
Positioning of Terrains and ability to unload
Working CameraBackColor (asap, i get a headache every time i see RGB(0,255,255) :>
OGRE for Linux, will definitly kill for
Ability to open multiple networkservers (passive FTP-server fÃ¼r alles)

Posted: **Thu Nov 06, 2003 6:35 pm**

Doubles for V4.0 please, please, please.

I'd swap all the improvements of the last year for this.

Posted: **Tue Nov 11, 2003 4:44 pm**

At viewtopic.php?t=8037 Fred said:

I will add support for single and triple buffering methods.

I believe on his words.
I believe don't forget it.
I hope not for v4.0, but for just next version (i don't know if 3.90 or what), will be?

Posted: **Tue Nov 11, 2003 6:03 pm**

my wishlist was getting longer and longer so i added it to the survial guide... hope fred is reading it now and again <hint hint hint

>

Posted: **Tue Nov 11, 2003 7:34 pm**

I try to read all the posts of course and I get a lot of ideas of them. For example, your fixed '.c' fixed string native type slowly makes its path in my mind and I will implement it very soon.

Posted: **Tue Nov 11, 2003 7:47 pm**

Yu read all the posts and slowly in your mind, you accept the idea that there should be two diffrent string-types:
- One for the C-Freaks (the fixed lenght, zero ended) and
- One for the BASIC-People those "who do not want to do nothing themselves"

with easy access to the "system-strings" see post from Edwin above.

Posted: **Tue Nov 11, 2003 10:33 pm**

fred, if you were a girl etc. etc. etc. i would take you out to dinner etc. etc. etc.

Posted: **Wed Nov 12, 2003 9:27 am**

If Fred were a girl, he had created ImpureBasic.

Don't woooorry anyone, it's only a misogynist joke.

PureBasic Forums - English

Wishlist for PureBasic v4.0

That one was good hehehe...

How to implement strings and how to develope the wheel new

Thats what I hope...