[George] please confirm: struct behaviour.

[pixelfck]

Hello,

It seems that variables that a struct has been assigned to, hold a pointer to the data structure, rather than the data itself.

An example:

Code: Select all

(block (theNodes setFoo)
	(setq setFoo (lambda (nodes index)
		(block (nodes2 aNode)
			(setq nodes2 nodes) 
			(setq theNode (item nodes2 index))
			(set@ theNode 'foo "bar!")
			)
		))
	
	(setq theNodes (list
		{foo: 'a bar: 0}
		{foo: 'b bar: 1}
		{foo: 'c bar: 2}
		{foo: 'd bar: 3}
		{foo: 'e bar: 4}
		))
	
	(setFoo theNodes 3)
	
	(enum theNodes node
		(dbgLog "node: " node)
		)
	)

Output:

Code: Select all

09/13/2013 18:15:49	node: { bar:0 foo:a }
09/13/2013 18:15:49	node: { bar:1 foo:b }
09/13/2013 18:15:49	node: { bar:2 foo:c }
09/13/2013 18:15:49	node: { bar:3 foo:bar! }
09/13/2013 18:15:49	node: { bar:4 foo:e }

This is, as far as I'm concerned, quite usefull behaviour. However, since I could not find any documentation on structs, I'm not sure if this is a bug feature, or intended behaviour.

@George, can you please confirm if the above behaviour is as intended?

Cheers,
Pixelfck

[george moromisato]

Yes, this is intended (and supported) behavior.

This is caused by set@, which modifies in place (as opposed to something like append, which returns the modified value). This will also work for lists:

Code: Select all

...
(setq changeList (lambda (theList)
   (set@ theList 1 "test")
   ))

(setq theList (list 1 2 3))
(changeList theList)

theList -> (1 "test" 3)

p.s.: Didn't test the above code, but I believe it will work.

[pixelfck]

Thanks, for the confirmation.
It is very usefull behaviour if you ask me

[RPC]

This explains a *lot*. Thanks for bringing it up pixelfck.

[Atarlost]

Does this mean structs are session limited the way object pointers are?

[george moromisato]

Does this mean structs are session limited the way object pointers are?

Very good question.

If you store a struct (or list) in an object with objSetData then it will be serialized and saved. On load the struct will be recreated.

But what's stored in the object is a deep copy of the struct. When you get the struct back from the object you will get a full copy of the original, not the original itself. Any pointers in the original will be pointers to copies.

E.g.,

Code: Select all

...
(setq list1 (list 'a 'b 'c))
(setq list2 list1)
(objSetData obj 'list3 list1)
(set@ list1 0 'foo)

list1 -> ('foo 'b 'c)
list2 -> ('foo 'b 'c)
(objGetData obj 'list3) -> ('a 'b 'c)

[pixelfck]

This all beggs the question: Is there a method of explicitly duplicating/copying a struct, thereby creating a copy of the data held by the original struct, yet at another memmory address?

(@duplicate ...) or (@copy ...) or someting the like?

~Pixelfck

[george moromisato]

This all beggs the question: Is there a method of explicitly duplicating/copying a struct, thereby creating a copy of the data held by the original struct, yet at another memmory address?

(@duplicate ...) or (@copy ...) or someting the like?

~Pixelfck

There is no built-in function. Your best bet is to do it yourself:

Code: Select all

...
(setq theSource {a:1 b:2})
(setq theCopy { })

(enum theSource theItem
   (set@ theCopy (@ theItem 0) (@ theItem 1))
   )
...
theCopy -> {a:1 b:2})