Re: Deferred length point contexts

John,

I think I must have written that a long time ago since I cannot remember
exactly how this came to light! Hopefully something along the following
lines for the second paragraph in (the old) 7.2.3 should address the
requirements.

Length contexts shall be managed by a global length context stack. When a
length context is activated, it
shall be placed at the top of the stack. A length context may be
deactivated and removed from the top of the
stack by calling its member function end. The end method shall only be
called for the length context
currently at the top of the context stack. A length context is also
implicitly deactivated and removed from the stack
when it goes out of scope. A deferred length context that has been
activated by calling its member function begin should be explicitly
deactivated and removed from the stack by calling its member function end.
 The current context shall always be the length context at the top of the
stack.

Dave

From:
john.aynsley@doulos.com
To:
david.long@doulos.com
Cc:
systemc-p1666-technical@eda.org
Date:
24/11/2010 14:27
Subject:
Deferred length point contexts
Sent by:
owner-systemc-p1666-technical@eda.org

Dave,

You wrote the following:

7.2.3 (now 8.3.2) The LRM is correct but I think it should recommend
that applications should call member function end for any deferred
contexts that have been activated by calling their begin member function.
The problem is due to the order in which the context destructors are
called when the contexts go out of scope. This will be the order in which
the contexts were created. Since the destructor attempts to restore the
previously active context, this order in which they are called is
important.

Would you care to suggest some new words?

Thanks,

John A

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner, and is 
believed to be clean. 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.