#1 sounds pretty good to me... 2 & 3 seem like overkill.  I don't
think the overhead of the null pointer is that bad.

Steve

On Fri, Mar 26, 2010 at 5:26 PM, nathan binkert <[email protected]> wrote:
> A common idiom with SenderState in the Packet object is the notion of
> saving the previous sender state object and building a stack of sender
> state objects.  So, I was thinking that it'd be useful to support
> this.
>
> There's three ways to do this.
> 1) add a "savedState" pointer to the base SenderState class, provide a
> constructor that defaults to setting this to null.  Add a
> popSenderState() function to the Packet object to delete the sender
> state on the top and make senderState point to savedState;
>
> 2) derive a SenderStateSave from SenderState that adds the variable,
> and add a popSenderState that does a dynamic_cast to SenderStateSave
> before doing the pop operation.  If the dynamic cast fails, the pop()
> does nothing.
>
> 3) do #2, but do a safe_cast instead.   (safe cast does a dynamic_cast
> and asserts non-NULL in debug mode, and a static_cast in fast)
>
> #1 is simple, but has the downside of storing a null pointer for
> originator SenderState objects that know that there's nothing to save
> (i.e. where things originate in the CPU for example)
>
> #2 is slow because of the dynamic cast
>
> #3 is ok, but adds the extra class.
>
> I'm partial to doing 1, 3, or nothing (in that order.)  With #1, we
> could also add a feature that requires the senderState to be popped at
> every level and where we assert in the Packet destructor that
> senderState is NULL.  This would ensure that you're not attaching
> things to sender state and forgetting about them (causing either a
> memory leak, or a programming error because you forgot to do
> something.)
>
> Any other opinions?
>
>  Nate
> _______________________________________________
> 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

Reply via email to