Re: [Gnucap-devel] Need some clarification in dot-card and subckts

[al davis]

On Sunday 27 July 2014, Rishabh Yadav wrote:
> I am little confused about subckts,CARD_LIST and DEV_DOT
> classes. How can one store objects in subckts and later
> iterate through all those stored objects?

Part of the confusion may be due to that CMD should not be 
derived from CARD.  Instead, it should have been derived from 
CKT_BASE, which lacks clone().  This is likely to change in the 
future.

Since commands (things derived from CMD) are never cloned (lack 
clone()) there exists the clonable thing that can be in a 
CARD_LIST called DEV_DOT.

Historically, this comes from the way SPICE did it.  It will 
probably change someday, but for now that is the way it is.

So, DEV_DOT objects can be stored in a CARD_LIST, actually 
storing the string (as a std::string).

> As far as I understood begin() and end() public function from
> CARD class are used for iterating through all the objects in
> the subckts.Am I correct? 

I think you meant to say CARD_LIST instead of CARD.  If so the 
answer is yes.

> Can a list of DEV_DOT(single
> command) objects be stored in subckts? 

Yes.

> I also have one
> doubt:DEV_DOT which is a wrapper that makes a command to
> look like a device stores a command as a string.So,if I use
> DEV_DOT to store a command and later retrieve that command
> for execution from the DEV_DOT object then I'll have only
> the name of the command not the CS object which I originally
> received while storing the command and that means I am
> storing a command after removing some crucial information
> associated with it.

The additional info has to do with scanning it as a stream.  
Since the CMD::do_it requires a CS argument, create a new one to 
pass.

> However,I can convert a string object to CS object to make it
> compatible with functions like cmdproc() but storing command
> as a string might create problems in certain cases like I
> faced while writing the "if" plugin. Correct me if I am
> wrong.

Look at the CS constructors.  It is simple to make a CS from a 
std::string. 

The "if" plugin. ....  Sometimes you need to throw one (or more) 
away and start over.  After "repeat" is done you will see.

This really needs a recursive approach to work.

Any of these decision blocks need to first store the contents, 
then execute from what is stored.

The problem arises when there is nesting, especially indirect 
nesting.  This nesting is not just blocks of the same kind, but 
any decision block inside another decision block.  When they are 
all the same, with direct nesting only, you can fake the 
recursion with loops, counters, stacks, and flags.  I don't like 
it, but it that special case it works.

With indirect nesting, layers of nesting of different kinds of 
decision blocks, only a recursive approach will really work and 
be manageable.

In this case, the read step needs to read in a recursive way.  
Add a method read_body(), which returns a CARD_LIST*.  Assign 
that to _subckt in DEV_DOT.  Look at new_subckt(), and its 
variants.