Prev: Thread.join
Next: Detecting OS ? (mono/.NET)
From: trubar a on 17 Jun 2010 18:31 Ive at the following link http://books.google.com/books?id=VGT1_UJzjM0C&lpg=PP1&dq=pro%20c%23%202008&pg=PA193#v=onepage&q&f=false that instead of initializing inherited members ( _c1 in our example ) inside derived constructor: class A { public int _c; } class B:A { public B(int c) { _c = c; } } we should initialize them inside base class constructor, since that way we reduce the calls to inherited members ( _c ): class A { public A(int c) { _c = c; } public int _c; } class B:A { public B(int c) : base(c) { } } If _c field is initialized inside base constructor, the order of initialization is the following: 1) First the field initializers of derived class B are called 2) Then field initializers of base class A are called (at this point _c is set to value 0) 3) Bs constructor is called, which in turn calls As custom constructor 4) _c field gets set to value of a parameter c ( inside As custom constructor ) 5) Once As custom constructor returns, Bs constructor executes its code. If _c field is initialized inside B's constructor, the order of initialization is the following: 1) First the field initializers of a derived class B are called 2) Then field initializers of a base class A are called(at this point _c is set to value 0) 3) Bs constructor is called, which in turn calls As default constructor 4) Once As custom constructor returns, Bs constructor sets _c field to a value of parameter c As far as I can tell, in both cases _c was called two times, so how exactly did we reduce calls to inherited member _c? thanx
From: Arne Vajhøj on 17 Jun 2010 20:30 On 17-06-2010 18:31, trubar a wrote: > I�ve at the following link > > http://books.google.com/books?id=VGT1_UJzjM0C&lpg=PP1&dq=pro%20c%23%202008&pg=PA193#v=onepage&q&f=false > > that instead of initializing inherited members ( _c1 in our example ) > inside derived constructor: > > class A > { > public int _c; > } > > class B:A > { > public B(int c) > { > _c = c; > } > } > > we should initialize them inside base class constructor, since that > way we reduce the calls to inherited members ( _c ): > > class A > { > public A(int c) > { > _c = c; > } > public int _c; > } > > class B:A > { > public B(int c) > : base(c) > { > > > } > } > > If _c field is initialized inside base constructor, the order of > initialization is the following: > > 1) First the field initializers of derived class B are called > 2) Then field initializers of base class A are called (at this point > _c is set to value 0) > 3) B�s constructor is called, which in turn calls A�s custom > constructor > 4) _c field gets set to value of a parameter c ( inside A�s custom > constructor ) > 5) Once A�s custom constructor returns, B�s constructor executes its > code. > > If _c field is initialized inside B's constructor, the order of > initialization is the following: > > 1) First the field initializers of a derived class B are called > 2) Then field initializers of a base class A are called(at this point > _c is set to value 0) > 3) B�s constructor is called, which in turn calls A�s default > constructor > 4) Once A�s custom constructor returns, B�s constructor sets _c field > to a value of parameter c > > As far as I can tell, in both cases _c was called two times, so how > exactly did we reduce calls to inherited member _c? I think the entire performance discussion is utterly irrelevant. Fields should be private and they should be initialized in the class that declares them. Arne
From: kndg on 17 Jun 2010 22:26 On 6/18/2010 8:30 AM, Arne Vajh�j wrote: > [...] > I think the entire performance discussion is utterly irrelevant. > > Fields should be private and they should be initialized in > the class that declares them. > > Arne Totally agreed! I wonder why people make simple thing complicated.
From: Mike Schilling on 18 Jun 2010 02:29 "Arne Vajh�j" <arne(a)vajhoej.dk> wrote in message news:4c1abe28$0$286$14726298(a)news.sunsite.dk... > On 17-06-2010 18:31, trubar a wrote: >> I�ve at the following link >> >> http://books.google.com/books?id=VGT1_UJzjM0C&lpg=PP1&dq=pro%20c%23%202008&pg=PA193#v=onepage&q&f=false >> >> that instead of initializing inherited members ( _c1 in our example ) >> inside derived constructor: >> >> class A >> { >> public int _c; >> } >> >> class B:A >> { >> public B(int c) >> { >> _c = c; >> } >> } >> >> we should initialize them inside base class constructor, since that >> way we reduce the calls to inherited members ( _c ): >> >> class A >> { >> public A(int c) >> { >> _c = c; >> } >> public int _c; >> } >> >> class B:A >> { >> public B(int c) >> : base(c) >> { >> >> >> } >> } > I think the entire performance discussion is utterly irrelevant. > > Fields should be private and they should be initialized in > the class that declares them. In other words, the rule is about encapsulation, not about performance.
From: Arne Vajhøj on 18 Jun 2010 17:28
On 18-06-2010 02:29, Mike Schilling wrote: > "Arne Vajh�j" <arne(a)vajhoej.dk> wrote in message > news:4c1abe28$0$286$14726298(a)news.sunsite.dk... >> On 17-06-2010 18:31, trubar a wrote: >>> I�ve at the following link >>> >>> http://books.google.com/books?id=VGT1_UJzjM0C&lpg=PP1&dq=pro%20c%23%202008&pg=PA193#v=onepage&q&f=false >>> >>> that instead of initializing inherited members ( _c1 in our example ) >>> inside derived constructor: >>> >>> class A >>> { >>> public int _c; >>> } >>> >>> class B:A >>> { >>> public B(int c) >>> { >>> _c = c; >>> } >>> } >>> >>> we should initialize them inside base class constructor, since that >>> way we reduce the calls to inherited members ( _c ): >>> >>> class A >>> { >>> public A(int c) >>> { >>> _c = c; >>> } >>> public int _c; >>> } >>> >>> class B:A >>> { >>> public B(int c) >>> : base(c) >>> { >>> >>> >>> } >>> } >> I think the entire performance discussion is utterly irrelevant. >> >> Fields should be private and they should be initialized in >> the class that declares them. > > In other words, the rule is about encapsulation, not about performance. At least if as the case here where the performance difference must be almost unmeasurable. Arne |