No. It's only SLICC that's really restrictive and complains if you don't consume a non-void return value. I still think it seems overly restrictive on SLICC's part, but then I assume it was put in for a reason to protect some dangerous SLICC-specific scenarios, so this is a simple way to get around it. C++ only gets angry if you have a variable that's never used.
Lisa On Thu, Mar 31, 2011 at 7:46 PM, Nilay <[email protected]> wrote: > Lisa, should not compiler yell in this case as well? > > Nilay > > > On Thu, March 31, 2011 8:22 pm, Lisa Hsu wrote: > > changeset c7302d55d644 in /z/repo/m5 > > details: http://repo.m5sim.org/m5?cmd=changeset;node=c7302d55d644 > > description: > > CacheMemory: add allocateVoid() that is == allocate() but no return > > value. > > This function duplicates the functionality of allocate() exactly, > except > > that it does not return > > a return value. In protocols where you just want to allocate a > block > > but do not want that block to be your implicitly passed > cache_entry, use > > this function. > > Otherwise, SLICC will complain if you do not consume the pointer > returned > > by allocate(), > > and if you do a dummy assignment Entry foo := > cache.allocate(address), > > the C++ > > compiler will complain of an unused variable. This is kind of a > hack to > > get around > > those issues, but suggestions welcome. > > > > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
