Types, reference errors, cloning?

[r0ber7]

Hi. I have a question regarding types and references. Suppose I have a type:

Code (glbasic) Select Expand


TYPE example
  var1%
  var2$
ENDTYPE


Then I create an instance of it:

Code (glbasic) Select Expand


LOCAL instance AS example
instance.var1 = 1
instance.var2 = "testing dum dee dum"


Now here's my problem. Suppose I want a copy of this instance. If I do this:

Code (glbasic) Select Expand


LOCAL instance2 AS example
instance2 = instance

This will be the same reference, and as soon as I remove instance from memory, accessing instance2 will give me an uncaught reference error.
So, the only way I figured out I can create a copy is by doing this:

Code (glbasic) Select Expand


LOCAL instance2 AS example
instance2.var1 = instance.var1
instance2.var2 = instance.var2

But, for larger types, this way of cloning an instance can get very laborious very quickly. Is there a cleaner way to create clones of objects?
I want to know this because I have set up enemy spawn points in my game, so a clean cloning of enemy data would save me some time. :-)

[kanonet]

instance2 = instance should work and create a copy (not refence). Im pretty sure it works and always has worked, the copy assignment operator get generated properly by GLBasic. The following example also works, so I can not confirm your problem yet.

Code (glbasic) Select Expand

TYPE example
  var1%
  var2$
ENDTYPE

LOCAL instance[] AS example
DIM instance[1]
instance[0].var1 = 1
instance[0].var2$ = "testing dum dee dum"

LOCAL instance2 AS example
instance2 = instance[0]

DIM instance[0]

PRINT instance2.var2$, 1,1
SHOWSCREEN
KEYWAIT

[r0ber7]

Hmm strange. Perhaps I misinterpreted something somewhere. Uncaught reference errors are hard to track down. 

Thanks tho.

[spacefractal]

Im have also had this issue as well, but its a typical issue when doing a c++ code, which glbasic is created in. As im are aware of, glbasic is just instance the pointer of the new object, which is not you are intesered in (you see the same issue in BlitzMax as well).

Instead, do a FUNCTION to clone it and return the object.

Here is the inide TYPE version of a FUNCTION (which can been a little more complicered than the outside version):

Code (glbasic) Select Expand


TYPE example
  var1%
  var2$
  FUNCTION clone AS example:
  LOCAL instance AS example
  instance.var1=self.var1
  instance.var2$=self.var2$
RETURN instance
  ENDFUNCTION 
ENDTYPE


and the function could call it by instance2=instance.clone()

[kanonet]

Spacefractal, there is no need for such a function, GLBasic automatically creates this as copy assignment constructor (operator=), which gets automatically called, when you type instance2=instance.

[spacefractal]

Im would still try to clone the object manually in a FUNCTION and see what it happens, if its is this extractly issue (etc its a bug in Glbasic somewhere).

But if its still crash, then its could been a GLOBAL/LOCAL issue, where the object have been deleted and then trying to access to it.

Personly im would allways clone the object manually to make sure nothing breaks.

[kanonet]

Where does it crash, can you please give an example? Generally doing in manual does not hurt, but it is not needed. GLBasic does it automatic, if it would not, we should fix it instead of working around it. But as far as I can see there is no problem and it should work just fine.

[spacefractal]

in Karma Miwa im seen also have "clone" (new object, not a direct clone).

Im dosent remember what its was (its a year ago now), but im fighted with a similar issue when the FOREACH loop got processed the array and used both ADD and DELETE in the same LOOP. Glbasic diddent like that. But  im does not remember extractly what it was.

But in the ind im did only DELETE the object in its own loop very late to make sure its diddent conflict somewhere else (im added a delete=1 variable to mark the object should been deleted).

So there can been in some special cases, you might need to clone the object manually, but its not a big deal really (its only one FUNCTION inside the TYPE).

But would been nice to see a example that cause the crash.

[kanonet]

Thats a total different problem, you can use DELETE inside FOREACH, but never use DIMDEL or DIMPUSH inside FOREACH! They are not save there, you just can not manipulate an array inside FOREACH (changing vars is of cause ok), but that has been said before... But this has nothing to do with copy of types.

(you said ADD I guess you was talking about DIMPUSH?)

[spacefractal]

 When he wrote copy the object manually did works, then its the only way.... So... But im was not sure what happens in Karma Miwa, im thinks its was a simular issue under deleting it.

Something could been happens here, because he wrote its was happens after delete a object, which might leads its can been a issue in the deconstructor.

But a example would been nice.

[Slydog]

From what I remember, GLBasic doesn't use any reference on an equals operation.  For a TYPE, it clones each member variable internally.
I think something else is going on to cause the error, or you've uncovered an internal GLBasic error.  Perhaps post some code?

I wish GLBasic had a reference type option.  This was a main reason I stopped using GLBasic.  I couldn't reference a Font type instance in a Label type instance, for example.  I had to use a FontId integer which became messy. 

[r0ber7]

It is very likely something else is going on. Thank you all for the answers even though it didn't help much, it is good to see this forum is alive.

[r0ber7]

I wish GLBasic had a reference type option.  This was a main reason I stopped using GLBasic.

Me too. After coding in OO languages for a while, I feel like I have outgrown GLBasic. However, my bigass game project is coded in it, so I will keep using it at least for a while longer.

[spacefractal]

GLBASIC could have been better in OO style like Blitzmax do, where there its excellent, but that would been more advanced as BASIC should do me thinks.

Property that can been a focus in next version, but I'm are not that good in c++, so I'm wont trying it. But hopefully other c++'could help Gernot here?

I'm do still want a code that happens to the crash, so im can checkout the issue in xcode (easier debug there really when it's a crash issue like this).

I'm thinks it's can been a bug in glb.h deconstructor.

[kanonet]

What bug are you talking about, so far we not even got any problem code? As long as I have not seen the crashing code, I suspect an user error, not GLBasic bug. GLBasic's TYPEs constructors/deconstructors/operators have proven to be very stable. Its completely useless to speculate about where a bug could be, when we have no bug to track down...

I also miss real pointers in GLBasic and they are on top of my list of what I want to add to GLBasic, once we start community development. If pointers should net get added to the basic part, I would at least prepare them, that they could easily integrated using INLINE.