a unique question!

Try reposting to sci.electronics.cad in the first instance - this is more their kind of thing, though they are users rather than creators.

Your project would fit into the philosophy of the gEDA open source electronic design software collaboration

and you might get some useful feedback from their mailing list. They seem to like C, Perl and Scheme, but there is some 750k lines of exisitng code, whch rather constrains their choices.

-------------- Bill Sloman, Nijmegen

This is just aa thought - I've been studying C++ on and off for awhile now, and if you start with classes for the basic gates, you wouldn't build the other components as "FUNCTIONS", but as other classes, using the basic classes either by inheritance or composition. Then use your functions to hook them up together.

Or, do like bill.sloman said. :-)

Good Luck! Rich

Pete, each logic device should be a class if it can have internal state data (remember object = data + functions). By having say a "D FlipFlop" class, you can then construct many flip flops and each will remember its state (ON or OFF) and any other settings you might want. Even a simple gate might have settings such as delay which might be settable differently for each gate. The magic of OOP is that data and actions on that data are represented by the class. Without OOP you have to store that data in variables which you have to keep track of - and that leads to poor quality, hard to maintain code - exactly why OOP was invented. So I would make my logic devices classes without a second thought.

A different issue is whether those logic device classes should all inherit from a common ancestor. Inheritance makes sense when the objects share their "functional essence". This can be hard to pick, but a good indicator is that some of the internal guts are in the ancestor and are used by the desendants. Another indicator is that true polymorhphism exists - i.e. virtual functions are actually useful.

If I had the job, I would do like this:

- a "device" class for each logic device type all inheriting from a common ancestor. The ancestor offers functions which allow discovery of the input and output terminals, and a function which lets you define the states of the inputs.

- a "circuit" class which contains (an array of) as many "device" objects as I want to add, and a representation of the interconnections betweeen all the objects.

- a "stepper" class which drives the circuit class, transferring logic outputs to inputs at time steps.

- a "capture" class which looks at the circuit object and records the state of desired points and logs or outputs these to screen.

I write OO code year in year out for a living with less electronics these days, and would never dream of using C for anything except an embedded micro or device driver, because it has no "big ideas". C++ is a nasty beast, but brings a massive boost to 1. Productivity 2. Code quality 3. Size of project a single programmer can manage without self destructing. Despite its problems, C++ has the true 00 ability to let you map real world things and concepts onto objects - letting you work on a higher plane.

Roger Lascelles

If you care about the speed, you don't want the code to have to go through a virtual method dispatch for every logic gate. I also think that this may lead to troubles with how you store the logic diagram.

If I was doing it, the structure that stores the signals would be the main issue. When a signal changes state, you need to be able to easily find all the gates it hooks to.

Are you planning on modeling all the prop delay characteristics?