If I make two structures Foo and Fii of type Whatever and I code Foo=Fii it seams that Foo is set as a reference to the location of Fii not to the current values of its variables. Does this sound correct? If so is there a way to equate the two without tediously coding Foo.Variable1=Fii.Variable1, Foo.Variable2=Fii.Variable2 and so on.

I'm not seeing that... this program changes a without changing its copy

Program MyNewProgram

 Structure foo
  x As Integer
  y As String
 End Structure
 
 Method Main()
 
  Define a As foo
  Define b As foo
    
  a.x =10
  a.y = "hello"
  
  b = a
  
  //change a...
  a.y = "goodbye"
  
  ConsoleWriteLine(a.y)
  ConsoleWriteLine(b.y)
  

 End Method

End Program

 

 

---

Managed DirectX and XNA ? Check out http://www.thezbuffer.com

Thanks for the quick reply. I'm glad you understood my explaination. A further nuance may be defining c as foo and then setting a = c to get the values in b to change. To tell you the truth the actual problem I am encountering seems to be endemic to code where I am passing lots of structures as parameters to recursive methods and functions. A bizarre anecdote is stepping into the code of the functions and surprsingly stepping into the lines for the structures themselves. Anyway it was wishful thinking that the simplistic case above was the source of the problem but I guess not.

 

 

If you want to share a program with this behaviour I will be happy to take a look. If its something you don't want to share on the forums them feel free to email it to me zman@thezbuffer.com

If you assign structures then I would expect it to make a separate copy every time and there should be no side effects from changing things you copied from or to. So I would consider anything like this a Phrogram bug.

---

Managed DirectX and XNA ? Check out http://www.thezbuffer.com

Well I did learn something from my "bizarre anecdote". If a program accesses the structure definitions while it is running then variable sized structure arrays would be possible.

As for the real problem with rewritten variables, it is becoming more pervasive and entrenched. Workarounds are less and less feasible. I will likely have to send you some code after all. However I'm not sure how long it will take to tease that code out of my lengthly program.

Do you think its becuase you are using arrays of these structures? My repro didn't..

---

Managed DirectX and XNA ? Check out http://www.thezbuffer.com

 

This program outlines the functionality of variables that inadvertantly act like objects. You cannot imagine the grief this "user feature" caused me particularly because I thought Phrogram was not requiring me to use an object oriented environment.

Program NotGood
 Structure SubFiis
  C As String
 End Structure
 Structure Fiis
  B As SubFiis
 End Structure
 Define A As Fiis
 Define X As Fiis

Structure Foos
  E As String
 End Structure
 Define D As Foos [1]
 Define Y As Foos [1]
 
 Structure Faas
  G As String [1]
 End Structure
 Define F As Faas
 Define Z As Faas
 
 Method Main ()
  A.B.C="initial"
  X=A//this is the crucial problem; X.B=A.B works fine
  A.B.C="changed"
  consolewriteline(X.B.C)
  
  D[1].E="initial"
  Y=D//again this is the crucial problem; Y[1]=D[1] works fine
  D[1].E="changed"
  consolewriteline(Y[1].E)
  
  F.G[1]="initial"
  Z=F//yet again this is the crucial problem; Z.G[1]=F.G[1] works fine
  F.G[1]="changed"
  consolewriteline(Z.G[1])
 End Method
 
End Program

//Results
//"changed"
//"changed"
//"changed"

Thanks for the repro - my initial reaction is that you are correct and this is a 'user feature' (i.e. a bug) ut I will have to dig into the code to see why its doing this.

Its looks more related to the nexted structs rather than the arrays.

 

---

Managed DirectX and XNA ? Check out http://www.thezbuffer.com

OK I found some time to investigate this and I have come to the conclusion that this is indeed a bug to do with nested structures.

If you take a look at the compiled Phrogram with something like Reflector you will see that a line of code like a=b gets compiled to a=b.Clone() when a and b are structures. This is to make sure that we follow the rules of structures and copy the values.

The problem is that the Clone() method doesn't follow the correct rules. It just copies each value inside the struct even if the item inside the structure is another structure. This give the behaviour that you are seeing.

What we should be doing is a deep copy of the class we create. I'm going to look to see if this is something with a quick fix or not and will report back shortly.

 

---

Managed DirectX and XNA ? Check out http://www.thezbuffer.com

Interestingly enough though your 1st and 3rd examples demonstrate the bug well your 2nd example:

  D[1].E="initial"
  Y=D//again this is the crucial problem; Y[1]=D[1] works fine
  D[1].E="changed"
  consolewriteline(Y[1].E) 

actually is how its supposed to work.

Since Y and D are arrays of structures and arrays are reference types assigning D to Y is correct in that it does not do a deep copy but instead makes Y point to the same array as D.

Like .Net we really need to document the differences between value types and reference types in Phrogram.

---

Managed DirectX and XNA ? Check out http://www.thezbuffer.com

I've investigated the issue some more and am 100% convinced it is a bug.

The sort of fix I need to put in place is not something we would consider doing for a small bug fix as it would require a LOT of compiler testing to make sure we don't reak other things. So for now this one will be documented as a bug to fix in the next major release whenever we do that.

Right now the workaround is to do the deep copy yourself. Each struct has a .Clone method availalbe which can be used.

So the workaround is to always do this:

Program MyNewProgram
  
 Structure inner
  innerstr As String
 End Structure
 
 Structure outer
  outerstr As String
  inside As inner
 End Structure
 
 
 Method Main()   Define foo As outer
  Define bar As outer
  
  foo.inside.innerstr = "hello"
  foo.outerstr = "start"
  
  bar = foo
  bar.inside = foo.inside.Clone()
  
  
  bar.inside.innerstr = "goodbye"
  bar.outerstr = "finish"
  
  Console.WriteLine(foo.inside.innerstr)
  Console.WriteLine(foo.outerstr)
 End Method

End Program  

---

Managed DirectX and XNA ? Check out http://www.thezbuffer.com

I'm glad it all makes sense. Perhaps I was able to find the bug because I am making greater demands on Phrogram than the averege user, but I can assure you I am not able to fathom the exact principles behind it. Your workaround would save a few lines of code but since my program is functioning at this point I'll just let it be. Overall it was exciting to work with you on the problem.

Yes you are certainly using features in more complex ways than most other Phrogram users and you did a great job producing a small repro that made it very easy for me to identify the bug.

For the benefit of others who may be wondering what is going on I will try to explain in simple terms.

.Net has 2 kinds of variable types. Value types and Reference types and in Phrogram we honor the same definitions though in general we don't have to explain in such detail because of the types of program people write.

Value types are integers, booleans and decimals and any types you make yourself using structures. When you refer to a value type variable you are talking about the actual value.

Reference types are any built in objects and any types you make yourself using classes. When you refer to a reference type you are talking about a reference to a value stored somewhere else in memory. This is similar to pointers in languages like C++

There's several differences between the 2 but the most important is that when you assign them different things happen.

Define a as integer = 12
Define b as integer = a
a = 99
Console.WriteLine(b)

This program prints 12. Changing a has no effect on b because value types copy the data when you assign them to each other

Class myType
  Define a as integer
End Class
Define x as myType
x.a = 12
Define y as myType = x
x.a = 99
Console.WriteLine(y.a)

This program prints 99. Seems odd? When you assign y=x it doesn't copy the data inside the class because classes are reference types. This means that x is a reference to the data stored inside it and when you say y=x you copy the reference. So now y and x both refer to the same values in memory. So changing x.a also has the effect of changing y.a

However if we take the almost identical program and change the class to a structure

Structure myType
  Define a as integer
End Structure
Define x as myType
x.a = 12
Define y as myType = x
x.a = 99
Console.WriteLine(y.a)

Then the program outputs 12. Structures are value types so y=x makes a copy of the data and you end up with 2 different sets of values.

In the case of the bug when you put a struct inside another struct Phrogram treats the inside struct as a reference type instead of the value type that it is supposed to be. So you get a horrible mix of this behaviour. The outer struct gets copied properly but the inner struct ends up pointing to the same data and changing one ends up changing the other one.

Hope that was useful for people.

 

 

 

 

 

---

Managed DirectX and XNA ? Check out http://www.thezbuffer.com

I have finally started to uses objects/classes in Phrogram. Soon into the program I am having to cope with my old nemesis (from a failed attempt to learn Smalltalk): reference types. I can't help wonder why have reference types at all if they are so non-intuitive. In their wisdom the object oriented community must have reasons for how they work. However I would wonder if their is not some type of clone method in Phrogram that would copy the values as opposed to the refrerences from one object to another. Personally that would suffice for me and all my programming needs.

Its part of the old size vs performance argument and memory management. In addition its often very useful to have several varialbe that 'point' to the same thing.

If everything is a value type then memory is used up very quickly as multiple copies are going to be made, and large structures take up a lot of stack space as you pass between routines. For speed things arer often passed in CPU registers and you can't do this with a 200byte structure. A lot of this history goes back to early computing and C type languages but its so ingrained into the way we do things now its not going to change.

In addition Phrogram being a .Net app must follow the rules of .Net where they have value and reference types

Sadly there is no Clone method as you describe.

 

---

Managed DirectX and XNA ? Check out http://www.thezbuffer.com