Wishlist for PureBasic v4.0
> 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:
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
> 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$
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
quidquid Latine dictum sit altum videtur
i'm not brilliant, but here's a suggestion:
is this any good or should i dump it into the waste bucket?
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
( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB)
( The path to enlightenment and the PureBasic Survival Guide right here... )
( The path to enlightenment and the PureBasic Survival Guide right here... )
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
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
quidquid Latine dictum sit altum videtur
Why not look at already existing open source code to see how they did itIf somebody has a brilliant idea for that, i'm open to suggestions.
... it's just that it isn't that easy to implement.

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...
I am to provide the public with beneficial shocks.
Alfred Hitshock
- newtheogott
- Enthusiast
- Posts: 120
- Joined: Sat Apr 26, 2003 2:52 pm
- Location: Germany, Karlsruhe
- Contact:
That one was good hehehe...
And if you don't include zero's
otherwise it may be truncated...

--Theo Gottwald
-----------------------------------------
http://www.it-berater.org * http://www.fa2.de * http://www.smart-package.com
-----------------------------------------
http://www.it-berater.org * http://www.fa2.de * http://www.smart-package.com
- newtheogott
- Enthusiast
- Posts: 120
- Joined: Sat Apr 26, 2003 2:52 pm
- Location: Germany, Karlsruhe
- Contact:
How to implement strings and how to develope the wheel new
>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. Ã
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. Ã
--Theo Gottwald
-----------------------------------------
http://www.it-berater.org * http://www.fa2.de * http://www.smart-package.com
-----------------------------------------
http://www.it-berater.org * http://www.fa2.de * http://www.smart-package.com
-
- User
- Posts: 60
- Joined: Wed Apr 30, 2003 2:25 pm
- Location: Västerås
- Contact:
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)
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)
- Psychophanta
- Always Here
- Posts: 5153
- Joined: Wed Jun 11, 2003 9:33 pm
- Location: Anare
- Contact:
At viewtopic.php?t=8037 Fred said:
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?
I believe on his words.I will add support for single and triple buffering methods.
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?

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
>

( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB)
( The path to enlightenment and the PureBasic Survival Guide right here... )
( The path to enlightenment and the PureBasic Survival Guide right here... )
- newtheogott
- Enthusiast
- Posts: 120
- Joined: Sat Apr 26, 2003 2:52 pm
- Location: Germany, Karlsruhe
- Contact:
Thats what I hope...
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.
- 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"

--Theo Gottwald
-----------------------------------------
http://www.it-berater.org * http://www.fa2.de * http://www.smart-package.com
-----------------------------------------
http://www.it-berater.org * http://www.fa2.de * http://www.smart-package.com
fred, if you were a girl etc. etc. etc. i would take you out to dinner etc. etc. etc.


( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB)
( The path to enlightenment and the PureBasic Survival Guide right here... )
( The path to enlightenment and the PureBasic Survival Guide right here... )
- Psychophanta
- Always Here
- Posts: 5153
- Joined: Wed Jun 11, 2003 9:33 pm
- Location: Anare
- Contact: