Handling empty strings like in their first allocation?

[Franky]

Hi there

I´d like to see PureBasic handling empty string like they are handled when calling "Global string.s"

An Example:

Code: Select all

Structure Text
    string1.s
    string2.s
EndStructure
Repeat
    *Punkt.Text=AllocateMemory(SizeOf(Text))
    Debug PeekL(*Punkt)
    Debug PeekL(*Punkt+4)
    Debug *Punkt\string1
    Debug *Punkt\string2
    *Punkt\string1="Testtext" ;Setting a string to make PB allocate Memory
    *Punkt\string2="Testtext2" ;Setting a string to make PB allocate Memorybereitgestellt
    *Punkt\string1="";Cleaning the string 
    *Punkt\string2="";Cleaning the string 
    Debug PeekL(*Punkt);Why is this not 0? 
    Debug PeekL(*Punkt+4);Why is this not 0? 
    FreeMemory(*Punkt)
    Delay(3)
ForEver 

As you see, when PB first set´s the pointer, it points to 0, that´s ok.

But when entering a string and deleting it, PB still points to a one-Byte-Buffer including a 0. Why?

The 2 Debug-Lines debuging the empty string directly after allocation show, that PB has no Problem with those Zero-Pointers.

So, why not delete the whole stringbuffer, if an empty string is assoziated?


The Background of my question:

As you see, I´m working with a kind of dynamic Memory-Management. To be more precise, in my Program I have kind of selfmade Linkedlists for Strings and Resources in my Program-Files. I have to do this, because I´m already handling my Mainfiles in a Linkedlist and PB doesn´t support embeded Linkedlists yet.

For the moment, there is no real ability to Free those String-Allocations when freeing an element of my Selfmade Lists.


Thanks for
-your attention
-any comments
-implementation


Regards
Franky

[srod]

There is a difference between a null string and an empty string in these kind of scenarios and it is sometimes useful to be able to differentiate the two. There are various api's I have used whereby a null string will cause a crash and instead an empty string is expected.

Personally I like things the way they are.

[Franky]

Oh, I see, didn´t know that.

So, how to fix that problem instead, any ideas?

[srod]

Courtesy of your friendly neighbourhood Freak (aka Timo - not me; at least not this time ) :

Code: Select all

Procedure FreeStructureString(*Address) 
  Protected String.String 
  PokeI(@String, *Address)
EndProcedure

Structure Text 
    string1.s 
    string2.s 
EndStructure 
Repeat 
    *Punkt.Text=AllocateMemory(SizeOf(Text)) 
    Debug PeekL(*Punkt) 
    Debug PeekL(*Punkt+4) 
    Debug *Punkt\string1 
    Debug *Punkt\string2 
    *Punkt\string1="Testtext" ;Setting a string to make PB allocate Memory 
    *Punkt\string2="Testtext2" ;Setting a string to make PB allocate Memorybereitgestellt 
    FreeStructureString(@*Punkt\string1)
      ;You can now safely poke a zero for the string pointer to signify a null-string.
        PokeC(*Punkt, 0)
    FreeStructureString(@*Punkt\string2)
      ;You can now safely poke a zero for the string pointer to signify a null-string.
        PokeC(*Punkt+SizeOf(INTEGER), 0)
    FreeMemory(*Punkt) 
    Delay(3) 
Until 1=1 

Of course you can remove the PokeC(..., 0) if you are freeing the main *Punkt memory anyhow. The zero is important only if you are intending using the string field again before freeing the main memory.