> On Feb. 22, 2012, 9:17 a.m., Steve Reinhardt wrote: > > src/mem/tport.cc, line 51 > > <http://reviews.gem5.org/r/1056/diff/1/?file=23553#file23553line51> > > > > Does having a constructor parameter with the same name as a member even > > work? I'm surprised if it does... > > Andreas Hansson wrote: > It works absolutely fine. Within this scope name refers to the parameter. > > Steve Reinhardt wrote: > Interesting... learn something new every day. I'm not surprised that the > parameter declaration shadows the member, but I am surprised that the > compiler doesn't give you a warning about that (as it does if you have a > local var that shadows a param). I'm also slightly surprised that > "label(label)" works, since you've got the same name with two different > bindings right there (though clearly the context is different so the compiler > can distinguish them). I always assumed that the idiom of naming either the > param or the member something slightly different like "_label" was to avoid > such problems, so it's mildly surprising to see that no such problems exist. > > I guess I'd still like to see the param called "_label" just for > consistency with all our other constructors.
I'm happy to change it. (In my Strostrup-influenced C++ schooling we were encouraged to name the parameter and member identically if there is a 1:1 relation. That said, I do see how it can cause confusion if people aren't used to it.) - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1056/#review2181 ----------------------------------------------------------- On Feb. 22, 2012, 11:31 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1056/ > ----------------------------------------------------------- > > (Updated Feb. 22, 2012, 11:31 a.m.) > > > Review request for Default. > > > Description > ------- > > MEM: Simplify cache ports preparing for master/slave split > > This patch splits the two cache ports into a master (memory-side) and > slave (cpu-side) subclass of port with slightly different > functionality. For example, it is only the CPU-side port that blocks > incoming requests, and only the memory-side port that schedules send > events outside of what the transmit list dictates. > > This patch simplifies the two classes by relying further on > SimpleTimingPort and also generalises the latter to better accommodate > the changes (introducing trySendTiming and scheduleSend). The > memory-side cache port overrides sendDeferredPacket to be able to not > only send responses from the transmit list, but also send requests > based on the MSHRs. > > A follow on patch further simplifies the SimpleTimingPort and the > cache ports. > > > Diffs > ----- > > src/mem/cache/base.hh 2629f0b99e8d > src/mem/cache/base.cc 2629f0b99e8d > src/mem/cache/cache.hh 2629f0b99e8d > src/mem/cache/cache_impl.hh 2629f0b99e8d > src/mem/tport.hh 2629f0b99e8d > src/mem/tport.cc 2629f0b99e8d > > Diff: http://reviews.gem5.org/r/1056/diff/diff > > > Testing > ------- > > util/regress all passing (disregarding t1000 and eio) > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
