PureBasic Forums - English

I'm one more for the choir:
For MIDI programming, I would like to see strings that can contain ascii zero.

geoff wrote:I'd like to see strings that can contain chr(0). This would greatly simplify the handling of binary files.

I strongly agree with this. Also, being able to pass this type of string
to a PureBasic created DLL without cutting off characters would be
sweet! If just these were added to 4.0 it would be the reason I finally
pay for a registration of PureBasic.

Cherokee~Stalker

Currently Purebasic has 16-bit strings.
16 bit= 65536 maximum length.

All other Basic languages have 32 bit strings. Because 32 bit= 2 GB maximum length. Thats just for each string 16 bits more for the lenght part.

I just imagine I would write a programm that loads and processes some textfiles, using typical BASIC string commands like MID$, LEFT$ etc..

Using Purebasic I would have to add a textfile which says "Please dont process files >64kb". And people would smile about that crazy idea.

The last basic I had with 16 bit strings was on my ATARI 400. Even the AMIGA-Basic had 32 bit.

If we take a sidelook to Powerbasic or to Visual-Basic, we see both have 32 bit strings (of course!).

I guess the fact that Fred does everything in C (including Purebasic itself) is the reason for him not to take the string-engine serious.
if someone is used to do all things with C-like "MemAlloc" then its not easy to understand typical Basic-programmers who do everything with A$ .

Still I hope on "LONSTRINGS" for Purebasic asap.

newtheogott wrote:Currently Purebasic has 16-bit strings.
16 bit= 65536 maximum length.

All other Basic languages have 32 bit strings. Because 32 bit= 2 GB maximum length. Thats just for each string 16 bits more for the lenght part.

PB Strings are zero terminated, i.e. the length isn't stored anywhere. The boundary of 64k comes from the fact, that PB internally allocs 64k for String operation.
What you mean, is Pascal like Syntax where the first x Bytes are held to store the length of the String. But Pascal<>PB, sorry.

Technically you are right, I guess.

However, why does the stringspace need to be allocated like that?

I guess "Garbage collection" and "dynamic string allocation" isn't anything new in world of today.

The system shows that we have more to do with C here and less with BASIC.

*** Lets take a look over the river:

In 32-bit Windows, both PowerBASIC and Visual Basic use the OLE string engine for allocating, storing and releasing dynamic strings. The OLE API SysAllocStringLen call is made to allocate a string and the SysFreeString call is made to release a string.

Internally, however, Visual Basic and PowerBASIC store string data differently. Visual Basic stores string data using the Unicode (two bytes per character) format. PowerBASIC stores string data using the ASCII (one byte per character) format.

Visual Basic always converts Unicode strings to ANSI (compatible with ASCII) format when passing them to a DLL or API call. On return from the call, Visual Basic will convert the string back to the Unicode format it uses internally.

although i am a big advocate of strings that can contain zeroes, there is actually nothing wrong with the current implementation, it just needs some expansion

let's be honest: what are strings supposed to be? in my book (disclaimer etc. ) they are there to contain readable stuff... is a chr(0) readable? ehm, not exactly

readable, human understandable stuff needs strings

now we, as all good basic programmers, are used to misusing our strings, to use them as binairy buffers, to store data etc.... while our dear os often wants to return data to us in fields that have a fixed length yet will contain a zero terminated string

this is why i don't want to CHANGE the current string model, i just want to add a type (fixed length) which, from a certain point of view, is not even a string (it's a camouflaged memalloc)

however, it's sooooo lovely to be able to do stuff like...

var.c[1200] = "test"

or use such a field in a struct...

we're basic programmers after all

> as all good basic programmers, are used to misusing our strings, to use them as binairy buffers, to store data etc....

EXACTLY, if we replace the word "missuse". I don't see it as a missuse, if I store something in A$ and therefore have not to care about Allocation of Memory and deallocation of Memory.

Thats what is one of the diffrences between BASIC and C.

So i would prefer the String Modell that all otehrs use, too.
BEsides that it could be possible to support the current strings as another datatype. In Powerbasic we also find diffrent datatypes for exactly that purpose.

Strings in Basic are Strings and not something I have to "hand-allocate". Then its something new.

To make something better you may need to make something new. But not all NEW things are better and not all better things MUST be something new.

64k limit was just a limit easy to remember. If you want more string buffer, just use the following code...
So what ?

Fred wrote: So what ?

Yeah

And if the user uses 1 byte more your program will crash 8O

Sometimes I think PureMacroASM or PureEasyC would have been more suiteable names....

fsw wrote:Sometimes I think PureMacroASM or PureEasyC would have been more suiteable names....

Not a bad idea, I will may be change the name

>Procedure SetStringManipulationBufferSize(Size)

and why not add this in the offical language?

And does that affect the internal buffers of some of the string functions?

Karbon wrote:And does that affect the internal buffers of some of the string functions?

No and yes. No, they are not affected, but a good lib-function should allocate as much as it'll need.
Yes, this buffer is also used for returning a string from a function (by the way, that's why there are problems with strings in threads).

Thats a theoretical Sollution, Fred.
Thanks however, it may really solve the Problem for SOME cases.

As I stated above, the OS already give a sollution for the String Allocation/DeAllocation.

Maybe there are speed reasons for a static buffer-size.

Actually AFTER the sollution given from Fred, PureBasic IS usable for anything where you know exactly the size of the string-data you want to work on. I doubt that are many cases.

However for several reasons (where I do not know at developement-time HOW much string-space I need), that given solution is worth from "standard" what is in all other Basic Languages.

As a standard "A$-Missuser (for binarydata storage " I'd still think twice if i have reasons to use that so long there are alternatives.

I really like Purebasic, its breathtaking developement-speed. Its comfortable features for compression and many other special cases.

Instead of a "name change" I'd prefer to get a new longstring datatype which uses the standard OS Functions for Alloc-/DeAllocation.

Maybe the actual Stringtype could be called "Faststrings" cause its faster in execution, the other Longstrings using the before shown funtions.

@newtheogott:

I really don't get your point.
You say you want to be able to use Strings, so you don't have to worry about
allocation and deallocation. Then why don't you do so? It actually works, there are
no changes to the string system needed.
I also do that, when i need unicode strings for example.

a$ = space(500)

This allocates 500 bytes for you, where's the problem?
The only difference is, that, once you put binary data in there, you can't use the string
functions to manipulate then. (but as i understand you, you only want the
allocation/deallocation anyway.)

Deallocating this is just as easy: a$ = ""

About the 64k buffer:
Personally, i have never hit that limit.
Ok, some people now say: But i want to put a 5MB file in my string, and manipulate it from there.

Ok, just to get this straight: You guys are asking for a much slower string management,
so you don't have to care about anything, and then you want to use that allready slow
system, to handle a big amout of data...

What a waste of recources!

IMHO, it is the job of the programmer to make the
programm as effective as possible, and therefore, PB is the perfect tool. It has a fast
string management, that is perfect for what is designed to to... string handling! It also
offers easy to use memory management functions. What is so damn complicated about
the AllocateMemory() command?

Whoever has to process large amounts of data should think his own way to handle them,
a way that fits best for the type of data at hand. This will be always faster than some
general-purpose-fits-all-lazy-guys string handling.

If you're to lazy to do some thinking when programming, use VB.
VB is designed to waste recources...

... no offense intended, just my humble opinion...

Timo