Re: [Gnucap-devel] problem with clone_instance

[al davis]

On Monday 18 November 2013, Felix Salfelder wrote:
> and, while i'm at it. in e_compon.h i found
> [..]
> public:  // obsolete -- do not use in new code
>   virtual bool print_type_in_spice()const = 0;
> [..]
> which should read
>   virtual bool print_type_in_spice()const{return
> some_default;}, if that member is really obsolete.

I had to look again ...

If it is really obsolete it should be removed.

But it is still there, still being called, so the meaning is 
"planned for removal".

It's a cover for a spice syntax inconsistency.  Without looking 
deeper, I don't know how to remove it.

grep ..
../apps/lang_spice.cc:609:      if (x->print_type_in_spice()) {
../apps/lang_spice.cc:760:  if (x->print_type_in_spice()) {

What it does ...

Spice syntax sometimes has an explicit "type" as gnucap defines 
it, sometimes not.  Changing the syntax (which we can't) to make 
it consistent leads to the Spectre syntax.

A resistor is:
R1 (1 3) 10k
.......  the type is implied by the letter "R", so 
print_type_in_spice() returns false.

A BJT is:
Q1 (2 3 4) modelname ......
.....modelname is the type.  Explicit, so print_type_in_spice() 
returns true.

If you change the resistor's print_type_in_spice() to return 
true, the printed and expected syntax is:
R1 (1 3) resistor 10k
.... like Spectre.


If you change it as you suggest, you need to come up with a way 
to test it, or mark it as unreachable(), and why it is still 
there.  (if it isn't obvious)

In this case "do not use" really means do not call it in new 
code.  There are cases where you need to provide it because 
lang_spice uses it, even though I wish it didn't.  It probably 
should say "do not call in new code".

The way spice syntax works, it is necessary when you create a 
new model to think of things like that, so the code here is 
"pure virtual" to call your attention to it where you might 
otherwise forget.

 (generic "you" here, not aimed at anyone in particular)
 (except maybe me)