Initializing Variables
in [Java Programming]
|
From: Arne Vajhøj on 25 May 2010 20:31 On 25-05-2010 19:17, Lew wrote: > Arne Vajhøj wrote: >> I strongly favor readability here. The extra overhead of something >> getting initialized twice should be minimal or zero if the JIT >> compiler optimizes it away. > > Minimal, perhaps, but the system is not permitted to optimize away > member initialization. What would prevent the JIT compiler from optimizing the setting of an int to zero twice to only doing it once? Arne
From: Lew on 25 May 2010 21:27 Arne Vajhøj wrote: >>> I strongly favor readability here. The extra overhead of something >>> getting initialized twice should be minimal or zero if the JIT >>> compiler optimizes it away. Lew wrote: >> Minimal, perhaps, but the system is not permitted to optimize away >> member initialization. Arne Vajhøj wrote: > What would prevent the JIT compiler from optimizing the setting of > an int to zero twice to only doing it once? The JLS, section 12.5, "Creation of New Class Instances": "In some early implementations, the compiler incorrectly omitted the code to initialize a field if the field initializer expression was a constant expression whose value was equal to the default initialization value for its type." -- Lew
From: Arne Vajhøj on 25 May 2010 21:35 On 25-05-2010 21:27, Lew wrote: > Arne Vajhøj wrote: >>>> I strongly favor readability here. The extra overhead of something >>>> getting initialized twice should be minimal or zero if the JIT >>>> compiler optimizes it away. > > Lew wrote: >>> Minimal, perhaps, but the system is not permitted to optimize away >>> member initialization. > > Arne Vajhøj wrote: >> What would prevent the JIT compiler from optimizing the setting of >> an int to zero twice to only doing it once? > > The JLS, section 12.5, "Creation of New Class Instances": > "In some early implementations, the compiler incorrectly omitted the > code to initialize a field if the field initializer expression was a > constant expression whose value was equal to the default initialization > value for its type." But isn't that talking about javac and not JIT? Arne
From: Lew on 25 May 2010 22:27 Arne Vajhøj wrote: >>>>> I strongly favor readability here. The extra overhead of something >>>>> getting initialized twice should be minimal or zero if the JIT >>>>> compiler optimizes it away. Lew wrote: >>>> Minimal, perhaps, but the system is not permitted to optimize away >>>> member initialization. Arne Vajhøj wrote: >>> What would prevent the JIT compiler from optimizing the setting of >>> an int to zero twice to only doing it once? Lew wrote: >> The JLS, section 12.5, "Creation of New Class Instances": >> "In some early implementations, the compiler incorrectly omitted the >> code to initialize a field if the field initializer expression was a >> constant expression whose value was equal to the default initialization >> value for its type." Arne Vajhøj wrote: > But isn't that talking about javac and not JIT? Not as I read it, but maybe it is. Regardless, JIT requires multiple executions (by default 10,000 IIRC) before it decides to optimize something. By definition, initialization code is run once. Regardless, as you pointed out and I reiterated, the performance impact is not enough to trump issues of readability or self-documentation. Nor is it required to initialize member variables to their default values. I admit it's possible that I read this wrong, but I think not. -- Lew
From: Jim Janney on 26 May 2010 00:00
Tom Anderson <twic(a)urchin.earth.li> writes: > On Tue, 25 May 2010, Patricia Shanahan wrote: > >> Rhino wrote: >>> I've received some criticism recently with regards to the approach >>> I use to initializing variables so I'd like to throw this issue out >>> to the whole group so that I can learn more about the pros and cons >>> of the approach I am using.... >>> >>> Basically, I initialize pretty much every variable as I declare it, >>> just to be sure it has some kind of value right away. That initial >>> value is typically a zero for a number or a null for an >>> object. Some recent criticism questioned this practice so I thought >>> I'd review some of the material that helped get me in that habit in >>> the first place. >> ... >> >> I follow the extreme opposite view. I initialize a local variable at the >> point of declaration if doing so makes logical sense or I know that I >> know something the compiler does not know. Generally, that involves the >> compiler assuming a fall-through from a call to System.exit. >> >> The reason for doing this is simple. I make mistakes. I have done most >> of my work in environments in which pair programming is not feasible, so >> I cannot depend on another programmer to catch my mistakes. To the >> maximum extent possible, I want to co-opt Eclipse's continuous source >> code checking as an aid to finding my mistakes as quickly as possible. >> >> One mistake I might make is omitting a logically necessary assignment to >> a local variable. Routinely initializing at the point of declaration >> would eliminate the possibility that it might be detected by the compiler. >> >> When I get a definite assignment error I take the time to look at my >> logic. Just occasionally, simply adding an initializer to the >> declaration would leave either an actual error or unnecessarily >> convoluted code, and I do something else. > > This is exactly what i do. By initialising locals at the point of > definition, you immediately throw away the compiler's ability to > sanity-check your assignments to them. Don't do that. You've lost me here. We all make mistakes, but I don't see how this is supposed to help. Perhaps someone could post a short example? -- Jim Janney |