Hi. I have a question regarding types and references. Suppose I have a type:
TYPE example
var1%
var2$
ENDTYPE
Then I create an instance of it:
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:
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:
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. :-)
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.
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
Hmm strange. Perhaps I misinterpreted something somewhere. Uncaught reference errors are hard to track down. :|
Thanks tho.
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):
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()
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.
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.
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.
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.
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?)
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.
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.
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.
Quote from: Slydog on 2015-Jan-08
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. :P
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.
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.
Could always use C/C++ inline!
Quote from: Slydog on 2015-Jan-08
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.
what you mean with this?!
inheritance or just a simple Con/Destructor?
Quote from: TheMapChap on 2015-Jan-08
Could always use C/C++ inline!
Of cause once you have a pointer you can assign to it using INLINE C++, but there is no way that I know about, how you can add a pointer to a GLBasic TYPE. It would not be hard to change this, but ATM you could only work around it, if you write very big party of your program in INLINE - but if you write your program in INLINE, why should you use GLBasic in the 1st place?
@Schran0r: I think he simply means that he needs pointers, at least thats how I read this. But constructors/deconstructors are an other easy to add feature that I miss currently
Glbasic creates a new instance(check out the produced C code) and then copies the values from the parent type, there is no need to clone in a function.
Also ALIAS can be used as a reference pointer, as long as you don't mind initialising it locally within each of your functions. I would really like to find a way of creating an ALIAS that can have the scope of a whole type though.
Btw, you can cast a GLB type int var as C pointer, in inline C, then set it, the pointer is then stored within the type. Using it, means uncasting it inline but as you said it not terrifically useful unless you really need to have that pointer bounces around with your type.
Ya, I was referring to pointers. I would have liked an option to reference a variable, not just copy the current value.
This would be useful for TYPEs, as they would behave more OOPy / objecty. But also useful for non-OOP programming.
Now various TYPEs and their instances sit alone and you can only connect a member variable reference via an integer ID with a lookup into an array of instances. Works, but feels kludgy.
Almost forgot about 'ALIAS', not really a replacement for pointers, but sure makes your code cleaner! Yes, make them available in TYPE definitions, then that would work.
The problem you mentioned does not exist. Code behaves as you expect it. Beware! Foreach and Alias create reference (i.e. pointer) variables that refer to garbage if the object pointed to gets removed or the array gets RESIZED!
Gesendet von meinem GT-N7100 mit Tapatalk