Steve,
I think I've found some technical errors in your usage of abstract
classes, plus some other minor problems.
I'm looking at the CVS version of the code as of late afternoon November
30th, but I know some of the stuff has been around for some time.
GCC doesn't seem care about my findings, but other compilers do care. I
am attempting to use SunStudio instead of GCC to build this. It has
been my experience that making code build with as many compilers as
possible tends to result in better code. For the sake of time, I'm
ignoring warnings.
For instance, the file Statement.h. You have the PNoop class, which
implements the Statement class. The Statement class is an abstract
class. PNoop is supposed to be an implementation of that class, but
because it doesn't implement a destructor, it is itself also an abstract
class.
The easy fix would be to add the line ~PNoop () { } to the PNoop
definition, after line 396 in statement.h. Am I wrong in thinking that
this wouldn't meaningfully change the behavior of PNoop?
The next place I see the same sort of error is in vpi_callback.cc, where
sync_cb also doesn't implement a destructor. I think that anyplace a
parent class has an abstract destructor, and you have a child class that
doesn't implement a destructor, that it is probably safe to stick a
dummy destructor as described above. Thus, is vpi_callback.cc, after
line 83, I added the line ~sync_cb () { }. Of course, if sync_cb was
ever to be a parent class, then perhaps it should be virtual ~sync_cb ()
{ } instead, but it doesn't appear that that is ever the case.
Next in the file vpi_priv.cc, on lines 312 and 421, you give an integer
as a constant in a call to pow. As you want the result in a double, it
might be best to coerce the constant to a double so the compiler is
absolutely clear on which std::pow function to use.
Also, in that same file, vpip_put_value_event has the same abstract
class problem as sync_cb in vpi_callback.cc. I again fixed it with a
~vpip_put_value_event() { } after line 397 in the same file.
vpi_time.cc, line 181 has the same problem with std::pow.
The other problems I've found so far have been configure problems, but
while I can fix them in the resulting Makefiles, I still have no clue
how to fix the configure script.
However, I am happy to say that this time, when I got the software
built, it worked (the last time I made it through the process, iverilog
would compile input files, but running the resulting executables would
spew link errors), at least for some super simple examples.
--
Joshua D. Boyd
[EMAIL PROTECTED]
http://www.jdboyd.net/
http://www.joshuaboyd.org/
