A little problem

BlitzMax Forums/BlitzMax Programming/A little problem

_JIM	(Posted 2009) [#1]

Hi!

I seem to have hit a problem. I'm too used to C++ heh.

Suppose I have 2 ~~classes~~ types:

Type TOne
    Field Thing
EndType

Type TTwo
    Global AllStuff:TList
    Field SomeStuff
EndType

The "AllStuff" static holds all instances of "TTwo" ever created. Is there a way to have a pointer to that list in the "TOne" type?

I have a feeling that if I do "Field SomeList:TList = TTwo.AllStuff" it will just make a copy of the current state.

GfK	(Posted 2009) [#2]

I have a feeling that if I do "Field SomeList:TList = TTwo.AllStuff" it will just make a copy of the current state.

I'm quite sure that doing this will create a reference to the existing list, which is what you want, right?

Brucey

(Posted 2009) [#3]

It'll be a reference (i.e. not a copy) , as GfK says.

However, unless you create an instance of AllStuff to begin with, SomeList will remain Null.

So, you may need this :

    Global AllStuff:TList = new TList

_Skully

(Posted 2009) [#4]

The "AllStuff" static holds all instances of "TTwo" ever created. Is there a way to have a pointer to that list in the "TOne" type?

Make it a global outside the types, then both can gain access

Global AllStuff:TList=New TList

Type TOne
    Field Thing
EndType

Type TTwo
    Field SomeStuff
EndType

ziggy

(Posted 2009) [#5]

All objects on BlitzMax are reference-based (never copied after a =) except strings. So never worry again about things getting copied when assigned, unlesss they're strings.

N	(Posted 2009) [#6]

All objects on BlitzMax are reference-based (never copied after a =) except strings

Strings are as well. Some strings may never be deallocated/collected, but they're all references to existing objects.

To illustrate:

Strict

Function _ObjToPtr:Byte Ptr(x:Byte Ptr)
	Return x
End Function

Global ObjToPtr:Byte Ptr(obj:Object) = Byte Ptr _ObjToPtr

Local x:String = "Foobar"
Local y:String = x

Print Hex(Int(ObjToPtr(x)))
Print Hex(Int(ObjToPtr(y)))

ziggy

(Posted 2009) [#7]

@Nilium: Just checked it. You're correct, strings are also ref-based. :D Thanks for the tip.

_Skully

(Posted 2009) [#8]

Thats true but with strings, they get re-created when modified so its not truly the same as a reference (more of a memory saving technique)... for example...

Strict

Function _ObjToPtr:Byte Ptr(x:Byte Ptr)
	Return x
End Function

Global ObjToPtr:Byte Ptr(obj:Object) = Byte Ptr _ObjToPtr

Local x:String = "Foobar"
Local y:String = x
y=y+"hello"

Print Hex(Int(ObjToPtr(x)))
Print Hex(Int(ObjToPtr(y)))

Brucey

(Posted 2009) [#9]

they get re-created when modified

Immutable :-)

N	(Posted 2009) [#10]

It's not really that the string is modified, it's that the two strings being concatenated creates a new string.

^ Brucey!

Edit 2: Something that would be interesting is if you could have inner strings for slicing. E.g., string A's buffer and length is "foobar" and inner string B's buffer is string A's buffer + 3 characters, and length 2 for "ba". Although this isn't currently possible to implement in BMax without changing the way strings work, but to do that you'd have to change the compiler as well since it depends on the existing structure of the string class... and my point was that modifying string behavior is a gigantic pain or something.

_Skully

(Posted 2009) [#11]

agreed & agreed... I guess my point was that when you modify objects they change for all references whereas strings work differently... immutable indeed..

N	(Posted 2009) [#12]

agreed & agreed... I guess my point was that when you modify objects they change for all references whereas strings work differently... immutable indeed..

Not necessarily. It all depends on the implementation. For example, strings are immutable, but it'd also be nice to have a MutableString type as well, in some cases. It's entirely possible to do that as well, but it wouldn't look very good.

_Skully

(Posted 2009) [#13]

Ya, in Max you would have to create a string in a type to make it mutable. But i'm honestly not sure what use a mutable string would be by itself.

_JIM	(Posted 2009) [#14]

Whoa, thanks for the answers guys. I was too lazy and tired to test this stuff myself.

I suppose if it acts like a reference, then I can add objects to the list through the "SomeList" field and the second type will see the new objects added, correct?

Brucey

(Posted 2009) [#15]

Correct.