Array initialisation

[Ouabaine]

Hello,

When you create an array of numbers, like int array[]=new int[1000]; what is
the initial value of the array? Are all the members set to zero, or is it
undetermined?

Thanks

 

[Lew]

Hello,

When you create an array of numbers, like int array[]=new int[1000]; what is
the initial value of the array? Are all the members set to zero, or is it
undetermined?

 

[Curt Welch]

Hello,

When you create an array of numbers, like int array[]=new int[1000];
what is the initial value of the array? Are all the members set to
zero, or is it undetermined?

An array initializer creates an array and provides initial values for
all its components.
<http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#1
5.10.1>
Then, if a single DimExpr appears, a single-dimensional
array is created of the specified length, and each component of the
array is initialized to its default value (§4.12.5).

And the most interesting link which is:

4.12.5 Initial Values of Variables

http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#9659
5

Numbers are set to zero as the default value, boolean is set to false, and
reference variables are set to null.

 

[Lew]

When you create an array of numbers, like int array[]=new int[1000];
what is the initial value of the array? Are all the members set to
zero, or is it undetermined?

array is initialized to its default value (§4.12.5).

^^^^^^

4.12.5 Initial Values of Variables

http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#9659
5

Numbers are set to zero as the default value, boolean is set to false, and
reference variables are set to null.

This section applies to more than just arrays.

 

[Jason Cavett]

Hello,

When you create an array of numbers, like int array[]=new int[1000]; what is
the initial value of the array? Are all the members set to zero, or is it
undetermined?

Thanks

Just as an aside, Java provides a Collections framework which has
extensive support for array-type work but is generally faster/easier
to use/etc. It's not always right or feasible to use Collections, but
I just wanted to point them out in case you are learning Java and
didn't know about them.

http://java.sun.com/docs/books/tutorial/collections/index.html

 

[Daniel Pitts]

Hello,

When you create an array of numbers, like int array[]=new int[1000]; what is
the initial value of the array? Are all the members set to zero, or is it
undetermined?

Thanks

Just as an aside, Java provides a Collections framework which has
extensive support for array-type work but is generally faster/easier
to use/etc. It's not always right or feasible to use Collections, but
I just wanted to point them out in case you are learning Java and
didn't know about them.

http://java.sun.com/docs/books/tutorial/collections/index.html

A further aside.
While "it's not always right or feasible to use Collections" should be
phrased "In a few very specific circumstances you would choose Arrays of
Collections".

Using arrays in preference to collections is a form a primitive obsession.

<http://virtualinfinity.net/wordpress/program-design/2007/10/28/primitive-obsession/>

If you have a performance critical application *and a profiler tells you
that using collections is a bottleneck*, then you should *consider*
using arrays. Even before considering arrays, consider alternative
implementations of the Collection types your using (LinkedList Vs
ArrayList, HashSet vs TreeSet, etc...).

The only other time you should consider using Arrays is interfacing to
legacy code which doesn't have collections support. Even in that case,
its usually better to use a collection and then peform a toArray() call
when passing to the legacy code, and java.util.Arrays.asList() when
receiving from the legacy code.

 

[Patricia Shanahan]

Hello,

When you create an array of numbers, like int array[]=new int[1000];
what is
the initial value of the array? Are all the members set to zero, or
is it
undetermined?

Thanks

Just as an aside, Java provides a Collections framework which has
extensive support for array-type work but is generally faster/easier
to use/etc. It's not always right or feasible to use Collections, but
I just wanted to point them out in case you are learning Java and
didn't know about them.

http://java.sun.com/docs/books/tutorial/collections/index.html

A further aside.
While "it's not always right or feasible to use Collections" should be
phrased "In a few very specific circumstances you would choose Arrays of
Collections".

Using arrays in preference to collections is a form a primitive obsession.

<http://virtualinfinity.net/wordpress/program-design/2007/10/28/primitive-obsession/>


If you have a performance critical application *and a profiler tells you
that using collections is a bottleneck*, then you should *consider*
using arrays. Even before considering arrays, consider alternative
implementations of the Collection types your using (LinkedList Vs
ArrayList, HashSet vs TreeSet, etc...).

I often choose arrays in preference to collections because of the better
notation for accessing and changing elements. Much more to do with code
clarity than with performance.

Patricia

 

[Daniel Pitts]

Hello,

When you create an array of numbers, like int array[]=new int[1000];
what is
the initial value of the array? Are all the members set to zero, or
is it
undetermined?

Thanks


Just as an aside, Java provides a Collections framework which has
extensive support for array-type work but is generally faster/easier
to use/etc. It's not always right or feasible to use Collections, but
I just wanted to point them out in case you are learning Java and
didn't know about them.

http://java.sun.com/docs/books/tutorial/collections/index.html

A further aside.
While "it's not always right or feasible to use Collections" should be
phrased "In a few very specific circumstances you would choose Arrays of
Collections".

Using arrays in preference to collections is a form a primitive
obsession.

<http://virtualinfinity.net/wordpress/program-design/2007/10/28/primitive-obsession/>


If you have a performance critical application *and a profiler tells you
that using collections is a bottleneck*, then you should *consider*
using arrays. Even before considering arrays, consider alternative
implementations of the Collection types your using (LinkedList Vs
ArrayList, HashSet vs TreeSet, etc...).

I often choose arrays in preference to collections because of the better
notation for accessing and changing elements. Much more to do with code
clarity than with performance.

Patricia

Alas, if only Java supported proper operator overloading :-/

Code clarity for a fixed sized collection *maybe*. I still usually go
with collections. foo[1] isn't so concise that I fill bad about using
foo.get(1);

 

[Patricia Shanahan]

Patricia Shanahan wrote: ....

I often choose arrays in preference to collections because of the better
notation for accessing and changing elements. Much more to do with code
clarity than with performance.

Patricia

Alas, if only Java supported proper operator overloading :-/

Code clarity for a fixed sized collection *maybe*. I still usually go
with collections. foo[1] isn't so concise that I fill bad about using
foo.get(1);

Indeed. There *should* be a single concise syntax for indexed access to
any integer-indexed Collection, and a reference array should just be a
special case of ArrayList in which the exact size is known at the time
of construction. That would leave primitive arrays as a performance
optimization.

I don't think the interesting case is a single reference. Here's a
simple example:

out[j] += in1[k] * in2[k][j];

Patricia

 

[Daniel Pitts]

Patricia Shanahan wrote: ....

I often choose arrays in preference to collections because of the better
notation for accessing and changing elements. Much more to do with code
clarity than with performance.

Patricia

Alas, if only Java supported proper operator overloading :-/

Code clarity for a fixed sized collection *maybe*. I still usually go
with collections. foo[1] isn't so concise that I fill bad about using
foo.get(1);

Indeed. There *should* be a single concise syntax for indexed access to
any integer-indexed Collection, and a reference array should just be a
special case of ArrayList in which the exact size is known at the time
of construction. That would leave primitive arrays as a performance
optimization.

I don't think the interesting case is a single reference. Here's a
simple example:

out[j] += in1[k] * in2[k][j];

Patricia

Why limit yourself to integer indexed types? Maps could make use of the
[] syntax as well:

foo["Bar"] = "Bob";

If I were to implement it, there would be two methods to override, since
Java doesn't support references the same way C++ does:

operator[](index); and operator[]=(index, value);

Of course, allowing the override of other arithmetic operations would be
useful as well.
In my opinion, if you can do it to a primitive, you should be able to do
it to a primitive wrapper.

 

[Joshua Cranmer]

Alas, if only Java supported proper operator overloading :-/

The two instances in which I can support operator overloading:
1. Bracketed access for Collection-types (probably limited to integer
indices, although a special type for Maps wouldn't be too bad).

2. +,-,*,/ for near-numeric types (i.e., BigDecimal and BigInteger).
These have some potential commutativity concerns, so I wouldn't be too
miffed if this aspect were left out (although limited operator
overloading without touching basic mathematical operations is... almost
pointless).

 

[Daniel Pitts]

The two instances in which I can support operator overloading:
1. Bracketed access for Collection-types (probably limited to integer
indices, although a special type for Maps wouldn't be too bad).

2. +,-,*,/ for near-numeric types (i.e., BigDecimal and BigInteger).
These have some potential commutativity concerns, so I wouldn't be too
miffed if this aspect were left out (although limited operator
overloading without touching basic mathematical operations is... almost
pointless).

Knowing that any feature can be abused, the intent of +,-,*,/, (maybe %)
overloading would be to allow types that have a natural meaning for
those operators. C++'s use of << for streams and Java's use of + for
string concatenation are good examples of "what not to do". Oops.

Specifically, I have a "Distance" type that I would like to support +,
-, * for. Also I have a Duration type, and a (mathematical) Vector
type, as well as a DistanceOverDuration type, which would be the return
for Distance:perator/(Duration duraction)

Distance*Distance would return Area, etc...

The expressive power of these operators on these types would be very
beneficial.

The biggest problem is people doing stupid things like "x*y" doesn't
mean multiplication.

Even in the case of my Vector type, I wouldn't use * for dot or cross
products, although I would probably use it for a scalar multiplication.

 

[Patricia Shanahan]

The two instances in which I can support operator overloading:
1. Bracketed access for Collection-types (probably limited to integer
indices, although a special type for Maps wouldn't be too bad).

2. +,-,*,/ for near-numeric types (i.e., BigDecimal and BigInteger).
These have some potential commutativity concerns, so I wouldn't be too
miffed if this aspect were left out (although limited operator
overloading without touching basic mathematical operations is... almost
pointless).

How do you define "near-numeric"? All values of BigDecimal are numbers,
but double has non-numeric values, so BigDecimal seems nearer to numeric
than double to me.

Mixed type operations can create a lot of complications, so I would
rather favor no implicit conversion for the overloaded operators.

Why not "%"?

Patricia

 

[Patricia Shanahan]

Daniel Pitts wrote:
....

The biggest problem is people doing stupid things like "x*y" doesn't
mean multiplication.

....

What I don't understand is why the operators seem to bring out the worst
in programmers. People who would not dream of naming an append to output
function "left_shift" happily use "<<" for append to output.

Patricia

 

[Mike Schilling]

Hello,

When you create an array of numbers, like int array[]=new int[1000]; what
is the initial value of the array? Are all the members set to zero, or is
it undetermined?

Set to 0. The value of a Java object is never undetermined.

 

[John W. Kennedy]

Daniel Pitts wrote:
....
....

What I don't understand is why the operators seem to bring out the worst
in programmers. People who would not dream of naming an append to output
function "left_shift" happily use "<<" for append to output.

"Left" "remaining" Or "left" "sinister"?

"Shift" "move", "shift" "garment", or "shift" "artifice"?

 

[Lew]

"Left" "remaining" Or "left" "sinister"?

"Shift" "move", "shift" "garment", or "shift" "artifice"?

"Left" - politically liberal.
"Shift" - period of time at work.

 

[Roedy Green]

When you create an array of numbers, like int array[]=new int[1000]; what is
the initial value of the array? Are all the members set to zero, or is it
undetermined?

see http://mindprod.com/jgloss/array.html

 

[Alan Morgan]

Knowing that any feature can be abused, the intent of +,-,*,/, (maybe %)
overloading would be to allow types that have a natural meaning for
those operators. C++'s use of << for streams and Java's use of + for
string concatenation are good examples of "what not to do". Oops.

Java's + bothers me much more than C++'s <<. The << operator isn't used
all that often in code (you need it if you are writing low level stuff, but
that's about it) so it's a matter of taking a rarely used operator and
giving it a new meaning that is also visually distinct:

cout << foo << bar << baz;

vs.

a = b << 3;

It's very easy (IMHO) to tell these two apart.

Java's + OTOH, bugs me. + is a very common operator and has a very
particular meaning and given Java's "operator overloading is bad, bad,
evil" stance it seems bizarre that they take a well known commutative
operator and give it a different, very common, usage that isn't commutative
and isn't visually distinct from the main one (plus the "auto convert
integers to strings unless they are the first item, in which case go
batshit" is annoying).

Alan

 

[Joshua Cranmer]

Daniel Pitts wrote:
...
...

What I don't understand is why the operators seem to bring out the worst
in programmers. People who would not dream of naming an append to output
function "left_shift" happily use "<<" for append to output.

Patricia

It's a short, easy way to write code. It may be somewhat obfuscated, but
it is a shorthand for (presumably) common operations.

I can sort of see how '<<' works for output appending, and '+' for
string concatenation makes sense to me, except for the fact that it is
already heavily used (but I can't think of any other good operator to
use for that...)