javascript and pointers

[joe]

I need a few clarifications on how Javascript deals with arrays and Date object.

Lets say daz is a date object. If I do this:

somevar=daz;

then "somevar" with be a pointer to daz, ie if I change somevar later daz will
change also. But If I do this:

somevar=new Date(daz);

somevar will a copy, not a pointer, of daz, ie if I change somevar later daz will
NOT change.

Right? Coming from C/C++ background I tend to think some new memory has been
allocated for "somevar". When will this memory be released? Can I do it manually
somehow if that is the case?


What about arrays? Lets say "bigar" is an array with many items. If I do this

somevar=bigar;

will somevar be a pointer to bigar and not a copy?

 

[VK]

I need a few clarifications on how Javascript deals with arrays and Date object.

Lets say daz is a date object. If I do this:

somevar=daz;

then "somevar" with be a pointer to daz, ie if I change somevar later daz will
change also. But If I do this:

somevar=new Date(daz);

somevar will a copy, not a pointer, of daz, ie if I change somevar later daz will
NOT change.

Your sample doesn't have sense in the context of your question. Date
constructor expects primitives, so providing daz being type of object
just leads to invalid date result. What you meant I guess is something
like somevar=new Object(daz); or similar

Any way, Javascript implements automated garbage collection similar to
Java, so with a proper programming you don't care of destructors -
this phenomenon as such is totally alien to Javascript.

If you are curious of the background mechanics of the process then I
once wrote about it here:
http://groups.google.com/group/comp.lang.javascript/msg/38ed90f1c1b4ccef

Do not hesitate to ask if more questions remain.

 

[Lasse Reichstein Nielsen]

I need a few clarifications on how Javascript deals with arrays and
Date object.

The same way it deals with all objects.

Lets say daz is a date object. If I do this:

somevar=daz;

then "somevar" with be a pointer to daz,

"somevar" is a *variable*. Variables hold values. In this case the value
it holds is a referencee to a Date object.
"daz" is also a variable. It holds a reference to the same Date object.
The assignment reads the value of the variable "daz" (which is the value
of the variable-expression "daz"), and assigns it to the variable
"somevar".

ie if I change somevar later daz will change also.

That depends on what you mean by "change somevar". If you change the
object referenced by the value in "somevar", e.g., by executing
"somevar.setFullYear(1942)", then that object is changed. Since the
values of "daz" and "somevar" reference the same object, doing
"daz.getFullYear()" will return 1942. The year value sits on the
object, not on the variable.

But If I do this:

somevar=new Date(daz);

somevar will a copy, not a pointer, of daz,

In this case "somevar" will hold a reference to a new Date object.
That Date object was created using the Date constructor with the
object currently referenced by "daz" as parameter.
That constructor is defined to create a new Date object that represents
the same point in time as a parameter Date object.

I.e., "somevar" will hold a reference to a Date object with the same
time as the Date object referenced by "daz". You can call that a "copy"
if you want.

ie if I change somevar later daz will NOT change.

If you change the object referenced by "somevar", then the, different,
object referenced by "daz" will not be changed.

Right? Coming from C/C++ background I tend to think some new memory has been
allocated for "somevar".

That's the error. Objects in Javascript are all heap allocated, as if
created by the C++ "new" operator. I.e., you can think of the
variables as holding a pointer (but it's a pointer that is
automatically dereferenced when you use it, so it's a little more like
a mutable reference variable).

This approach matches the one in Java and C# for "reference-types"
(types where values are represented by a reference, not by their
content).

When will this memory be released?

When the Javascript engine decides that it is no longer needed. The
ECMAScript specification says nothing of memory management. Javascript
engines typically use a garbage collector, but it would be compliant
behavior to never release anything at all, until the program ends.
If you don't crash before that

Can I do it manually somehow if that is the case?

No. You can clear all references to the object, and hope that it
will be garbage collected.

What about arrays? Lets say "bigar" is an array with many items. If I do this

somevar=bigar;

will somevar be a pointer to bigar and not a copy?

Again, you only assign a reference value to "somevar". Both variables
will then refer to the same array.

/L

 

[Lasse Reichstein Nielsen]

Your sample doesn't have sense in the context of your question. Date
constructor expects primitives, so providing daz being type of object
just leads to invalid date result.

Actually, if d is a Date objet, then
new Date(d)
is equvialent to
new Date(d.valueOf())
which is again equivalent to
new Date(d.getTime())
which indeed creates a Date object with the same time value as the
original.

/L

 

[VK]

Your sample doesn't have sense in the context of your question. Date

Actually, if d is a Date objet, then
new Date(d)
is equvialent to
new Date(d.valueOf())
which is again equivalent to
new Date(d.getTime())
which indeed creates a Date object with the same time value as the
original.

Indeed. I am not an engine torturer by my nature , so never
explored this variant. Still I guess OP question is about generic
language features and not about particular AID (Anti-Idiot Defence)
mechanics build into language.

 

[Dr J R Stockton]

Actually, if d is a Date objet, then
new Date(d)
is equvialent to
new Date(d.valueOf())
which is again equivalent to
new Date(d.getTime())
which indeed creates a Date object with the same time value as the
original.

JavaScript new Date() likes to receive a string argument, and a Date
Object likes to provide a String. The equivalence is thus to
new Date(d.toString()). Or so I thought from using IE4 IE6 IE7.

Using d.toString() provides a correct representation of the value of the
Date Object, but truncated to the Second.

Therefore, such a copy will be unfaithful to a degree which is often
unimportant. Proof : execute (I used js-quick.htm)
d1 = new Date()
d2 = new Date(d1)
x = [d1%1000, d2%1000]
I get in IE7 [Random(1000),0]; in FF2, Op9, Sf3 [Random(1000),same]; I
had expected that all would follow IE.

That, naturally, leads those who only test in a reputable browser to
write code which may err in a common one.

Moreover, although d.toString() only makes a small error, new Date(d)
can make a rather large one if presented with dates in some or all years
in 99BC to 99AD inclusive; it adds, or at least can add, 1900 years.
Trying :
d1 = new Date(100,0,0) // Year 99, Dec 31
d2 = new Date(d1)
x = [d1, d2]
I get d2 in 1899 in IE but d2 in 0099 in the other three.

For both tests, new Date(+d1) always gives an accurate copy.

Consider now timing :
K_ = ???
D0_ = new Date()
Q_ = K_ ; while (Q_--) { }
D1_ = new Date()
Q_ = K_ ; while (Q_--) { new Date(D0_) }
D2_ = new Date()
Q_ = K_ ; while (Q_--) { new Date(+D0_) }
D3_ = new Date()
Q_ = [D1_-D0_, D2_-D1_, D3_-D2_] // Demo 6
->
IE7 K=5e4 Result 16,953,297
FF2 K=5e4 Result 94,500,515
Op9 K=5e4 Result 31,141,125
Sf3 K=5e5 Result 157,406,562 // Note bigger K

Therefore, one should use the + if the code might be executed mainly in
IE, and should omit it if the code might be executed mainly in Safari;
but one must use the + for full range work where IE is possible.


The benefits of that + were discussed here a while ago; perhaps in the
regrettable period where we were not honoured by LRN's presence. I then
had only IE4; and there were no reports of differences with other
browsers.

 

[Lasse Reichstein Nielsen]

In comp.lang.javascript message <[email protected]>, Sun, 13 Apr
2008 14:10:03, Lasse Reichstein Nielsen <[email protected]> posted: ....
JavaScript new Date() likes to receive a string argument, and a Date
Object likes to provide a String. The equivalence is thus to
new Date(d.toString()). Or so I thought from using IE4 IE6 IE7.

I don't know about IE, but according to the ECMAScript specification,
the conversion happens as:

Call to the Date constructor with a single argument (15.9.3.2) constructs
a new Date object with a [[Value]] computed by calling ToPrimitive
on the argument (with no hint).
According to 9.1, this calls [[DefaultValue]] on the object.
According to 8.6.2.6, this is interpreted as having the hint/preferred
type "number", which then calls the "valueOf" method on the object.
According to 15.9.5.8 this returns the time value of a Date object.

I.e., no strings.

A specification doesn't guarantee that browsers are compliant, ofcourse

Using d.toString() provides a correct representation of the value of the
Date Object, but truncated to the Second.

To check whether there is rounding to the second, as string conversion would
cause, the following code can be used:
var d = new Date(1972,02,28,23,50,12,987);
var dd = new Date(d);
var dn = new Date(Number(d));
var ds = new Date(String(d));
alert([dd.getMilliseconds(),
dn.getMilliseconds(),
ds.getMilliseconds()].join("\n"));

In Opera, both dd and dn preserves milliseconds, and ds doesn't.
Ditto in Firefox.
However, in IE7, dd loses milliseconds too, so it appears that
IE is not spec-compliant at that point.

Therefore, one should use the + if the code might be executed mainly in
IE, and should omit it if the code might be executed mainly in Safari;
but one must use the + for full range work where IE is possible.

Indeed, to copy a date, one should do one of these, equivalent, calls:
new Date(+d)
new Date(Number(d))
new Date(d.valueOf())
new Date(d.getTime())

/L