 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / December 2007Array initialisation
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 > 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? <http://java.sun.com/docs/books/jls/third_edition/html/arrays.html#10.3> > 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#15.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).  SignatureLew > > Hello, > > [quoted text clipped - 11 lines] > > 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. SignatureCurt Welch http://CurtWelch.Com/ curt@kcwc.com http://NewsReader.Com/ Ouabaine wrote: >>> 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? Lew wrote: >>> array is initialized to its default value (§4.12.5). ^^^^^^ > 4.12.5 Initial Values of Variables > [quoted text clipped - 3 lines] > 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. SignatureLew > Hello, > [quoted text clipped - 3 lines] > > 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 >> Hello, >> [quoted text clipped - 11 lines] > > 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. SignatureDaniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/> >>> Hello, >>> [quoted text clipped - 28 lines] > 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 >>>> Hello, >>>> [quoted text clipped - 35 lines] > > 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); SignatureDaniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/> ... >> I often choose arrays in preference to collections because of the better >> notation for accessing and changing elements. Much more to do with code [quoted text clipped - 7 lines] > 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[i][j] += in1[i][k] * in2[k][j]; Patricia > .... >>> I often choose arrays in preference to collections because of the better [quoted text clipped - 21 lines] > > 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. SignatureDaniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/> >> 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. > > 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). SignatureBeware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth >>> I often choose arrays in preference to collections because of the better >>> notation for accessing and changing elements. Much more to do with code [quoted text clipped - 11 lines] > 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::operator/(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. SignatureDaniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/> ... > 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 > .... >> The biggest problem is people doing stupid things like "x*y" doesn't [quoted text clipped - 4 lines] > 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"? SignatureJohn W. Kennedy "Man is a giddy thing." -- "Much Ado about Nothing" >> .... >>> The biggest problem is people doing stupid things like "x*y" doesn't [quoted text clipped - 8 lines] > > "Shift" "move", "shift" "garment", or "shift" "artifice"? "Left" - politically liberal. "Shift" - period of time at work. SignatureLew > ... >> The biggest problem is people doing stupid things like "x*y" doesn't [quoted text clipped - 6 lines] > > 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...) SignatureBeware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth Joshua Cranmer skrev: >> ... >>> The biggest problem is people doing stupid things like "x*y" doesn't [quoted text clipped - 14 lines] > already heavily used (but I can't think of any other good operator to > use for that...) That's why we decided to skip the operator when concatenating TEXT expressions in Simula. We used juxtaposition, like filepath := directory "/" file "." ext; Simula, based on Algol 60, with classes and references, is one of the first OO languages. It inspired Bjarne Stroustrup when he designed C++. >>>> I often choose arrays in preference to collections because of the better >>>> notation for accessing and changing elements. Much more to do with code [quoted text clipped - 16 lines] >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 SignatureDefendit numerus > 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, [quoted text clipped - 3 lines] > integers to strings unless they are the first item, in which case go > batshit" is annoying). I suppose I get your objection to the overload of '+' for string catenation, but it's so common and so well-established that I myself am not bothered by it. What I do not understand is the "unless they are the first item, in which case go batshit" reference. To what are you referring? SignatureLew >> 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, [quoted text clipped - 10 lines] > the first item, in which case go batshit" reference. To what are you > referring? I think its "okay", but it would have been a better choice to introduce a new operator. # comes to mind for some reason: int fun = 3; int guilt = 0; String myString = fun # " times the fun. " # guilt # " times the guilt"; Now that I think about it, why hasn't # been used for any operator? SignatureDaniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/> >>> 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, [quoted text clipped - 18 lines] > String myString = fun # " times the fun. " # guilt # " times the guilt"; > Now that I think about it, why hasn't # been used for any operator? But what is all this about "unless they are the first item ... batshit"? SignatureLew >>>> Java's + OTOH, bugs me. + is a very common operator and has a very >>>> particular meaning and given Java's "operator overloading is bad, [quoted text clipped - 22 lines] > But what is all this about "unless they are the first item ... > batshit"? Perhaps that 2 + 4 + " is the answer" works very differently from "The answer is " + 2 + 4. I like Daniels' suggestion;. It's very clear that both operands must be converted to a string value (except for the ones that are already declared as strings, of course.). >>>> 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, [quoted text clipped - 20 lines] > > But what is all this about "unless they are the first item ... batshit"? I don't know, that wasn't me. Although, I suspect the problem is in this case: int foo = 1, bar = 2; String s = foo + bar + "3"; The output is 33, where as using a different operator would prevent that ambiguity. String s = foo#bar#"3"; // 123 SignatureDaniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/> >>>> 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, [quoted text clipped - 20 lines] > > But what is all this about "unless they are the first item ... batshit"? I don't know, that wasn't me. Although, I suspect the problem is in this case: int foo = 1, bar = 2; String s = foo + bar + "3"; The output is 33, where as using a different operator would prevent that ambiguity. String s = foo#bar#"3"; // 123 SignatureDaniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/> >>> 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, [quoted text clipped - 18 lines] >String myString = fun # " times the fun. " # guilt # " times the guilt"; >Now that I think about it, why hasn't # been used for any operator? Because traditionally # and $ were used for substitution parameters in scripting languages. George -- for email reply remove "/" from address >>Now that I think about it, why hasn't # been used for any operator? > >Because traditionally # and $ were used for substitution parameters in >scripting languages. Forgot % and @ which are also used by scripting languages George -- for email reply remove "/" from address >> I think its "okay", but it would have been a better choice to introduce >> a new operator. # comes to mind for some reason: [quoted text clipped - 6 lines] > Because traditionally # and $ were used for substitution parameters in > scripting languages. What's that have to do with anything? # was used in C/C++ as a preprocessor directive marker, and in BASH script to denote comments. Why should the syntax of a language be restricted by the syntax of a completely unrelated language? SignatureDaniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/> >> 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, [quoted text clipped - 10 lines] > the first item, in which case go batshit" reference. To what are you > referring? The only language I can think of offhand with a completely unique concatenation operator is PL/I, which uses "||" for concatenation and nothing else. SignatureJohn W. Kennedy "Though a Rothschild you may be In your own capacity, As a Company you've come to utter sorrow-- But the Liquidators say, 'Never mind--you needn't pay,' So you start another company to-morrow!" -- Sir William S. Gilbert. "Utopia Limited" > The only language I can think of offhand with a completely unique > concatenation operator is PL/I, which uses "||" for concatenation and > nothing else. There is a language that indicates concatenation by a lack of any operator - simply separating terms by blanks imputes concatenation - SNOBOL. SignatureLew >> The only language I can think of offhand with a completely unique >> concatenation operator is PL/I, which uses "||" for concatenation and [quoted text clipped - 3 lines] > operator - simply separating terms by blanks imputes concatenation - > SNOBOL. *grin* I was going to post that, I even found my old SNOBOL4 programming language manual to check it. But I thought "who beside me has ever heard of SNOBOL?" and canceled my post. SNOBOL was fun, I miss it. Modern C uses a restricted version of this, for string literals. -Wayne >>> The only language I can think of offhand with a completely unique >>> concatenation operator is PL/I, which uses "||" for concatenation and [quoted text clipped - 10 lines] > > SNOBOL was fun, I miss it. Same here. Patricia > >> The only language I can think of offhand with a completely unique > >> concatenation operator is PL/I, which uses "||" for concatenation and [quoted text clipped - 9 lines] > language manual to check it. But I thought "who beside me has ever heard > of SNOBOL?" and canceled my post. There are other old guys here. I was taught SNOBOL when I got my CS degree back in the 70's. It was so long ago however and I remember so little of it that I didn't even think about it while I was reading this thread. + for string concatenation is as old as the hills. I used it in a language I created back in the late 70's. I can't remember were I first saw it. It does create a bit of confusion in Java but it's minor and doesn't bother me. If you wanted a different operator to overload I'd pick |. It would create less confusion because the typical context in which you use OR is different from the context in which you would use string concatenation. Other options would be !, or @, or #. If you wanted to look at multiple characters, .. would be a good one, as well as ,, or // or \\ or ><. There's really no end to the options. SignatureCurt Welch http://CurtWelch.Com/ curt@kcwc.com http://NewsReader.Com/ >> The only language I can think of offhand with a completely unique >> concatenation operator is PL/I, which uses "||" for concatenation and [quoted text clipped - 3 lines] > operator - simply separating terms by blanks imputes concatenation - > SNOBOL. There's a current scripting language that does this: awk Signaturemartin@ | Martin Gregorie gregorie. | Essex, UK org | >> The only language I can think of offhand with a completely unique >> concatenation operator is PL/I, which uses "||" for concatenation and [quoted text clipped - 3 lines] > operator - simply separating terms by blanks imputes concatenation - > SNOBOL. PHP uses . for concatenation. I think perl does too, doesn't it? SignatureDaniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/> >> The only language I can think of offhand with a completely unique >> concatenation operator is PL/I, which uses "||" for concatenation and [quoted text clipped - 3 lines] > operator - simply separating terms by blanks imputes concatenation - > SNOBOL. REXX partially allows that. SignatureJohn W. Kennedy "But now is a new thing which is very old-- that the rich make themselves richer and not poorer, which is the true Gospel, for the poor's sake." -- Charles Williams. "Judgement at Chelmsford" >>> 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, [quoted text clipped - 13 lines] > concatenation operator is PL/I, which uses "||" for concatenation and > nothing else. SQL-as-specified has the same property, right down to the operator chosen. Haskell also has a unique list concatenation operator, which covers strings since they're lists too, but I believe you can provide other meanings for ++ within modules, so it may not count. -o >>> I often choose arrays in preference to collections because of the better >>> notation for accessing and changing elements. Much more to do with code [quoted text clipped - 11 lines] > 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 >> 2. +,-,*,/ for near-numeric types (i.e., BigDecimal and BigInteger). >> These have some potential commutativity concerns, so I wouldn't be too [quoted text clipped - 5 lines] > but double has non-numeric values, so BigDecimal seems nearer to numeric > than double to me. Near-numeric is a catch-all for anything that could subclass Number and other non-mathematic types (matrices, rings, etc.) > Mixed type operations can create a lot of complications, so I would > rather favor no implicit conversion for the overloaded operators. My personal opinion for how it could be done would be to have something like this: public interface Addable<Addend,Sum> { public Sum add(Addend o); } This would, however, require reified generics to be able to inherent from the same interface with different generic parameters. > Why not "%"? Um... it slipped my mind. SignatureBeware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth > 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. >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 SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.