Misc CParse notes:

--------------------------------------------------------------------------------
New as of Deco 0.8:

	- removed more ambiguities
	- general cleanup
	- bitfield support

--------------------------------------------------------------------------------
CParse is my generic name for a collection of C/C++/DC++
parsing classes, including:
	CParse itself (which using CParse.y)
	CLex
	CAction 
	ActionStack
	TokenList

These in turn rely on vSymTab, vStrTab, and Lexer.

--------------------------------------------------------------------------------

CParse currently supports most of the C++ language with the exception of:
	- exceptions
	- templates
	- RTTI (although deco provides its own form of this)

Exceptions will probably be added at some point.
RTTI will be added so that it can be integrated with deco's
notion of dynamic objects.  Eventually, if I ever get around
to it (or maybe for a PhD thesis someday) I will add template
support, and integrate it with deco for the purpose of
creating generic dynamic objects in a way that's compatible
with the type system.


--------------------------------------------------------------------------------

Lots of work still needs to be done to clean up the interfaces 
between CParse, CAction, and deco.  Many parts of the interfaces
are currently inconsistent and the documentation in the code
is often no longer correct.

In the end, CAction is going to be split into vCAction, the
virtual interface that CParse will use, and CAction, a default
implementation, which will include much of the code currently
in the deco directory, including parts of deco.cc and ccint.cc.
There will be a separate COut class for output (comprising
much of ccout.cc) and a CInt or CInternal class for managing
the storage and manipulation of C/C++ parse trees.
(most of ccint.cc will go here) When all this happens,
deco.cc will become significantly smaller, since most
of its functionality will be handled by the default classes.
Also, it will be much easier to write other systems that
use C++ parsing then, since they will be able to just
inherit most of the code, and just customize what they
need to.

Perhaps all the 'C' names will change to 'CC', 'Cc', or 'Cxx'...
I originally named them at the time that I was still using '.C'
as my suffix for C++ programs (I have since switched to using .cc).
Also, since they handle C++ and C programs (for the most part)
and C++ can be seen as a next-generation C, it seemed appropriate
to just use the C.  Unfortunately, this causes confusion with some
class hierarchies that just use a 'C' prefix for 'Class'.


--------------------------------------------------------------------------------

Using CParse:

	Basically, look at DECO, to see how it uses it.  The general idea
	is that a virtual function interface is used, along with the 
	Item data structure, for communicating between the parser and 
	the code using the parser.  It essentially acts like a callback
	system, where you give the parser a bunch of callbacks (virtual
	functions in this case) for all of the actions it can perform,
	and then you give the parser some input source, and you fire
	it up.  It calls back the appropriate actions as it goes, both
	to actually declare/define objects, and to query the system 
	for information about various names, scopes, etc.  The hope here
	was to try to keep the parser as simple as possible, and to
	try to move most of the complexity into a separate program with
	a clean interface.   Currently that "clean" interface is rather
	inconsistent, so it needs to be cleaned up again.  Therefore,
	if you write any programs using it, be prepared to change them
	in the future.  Also, note that in the future you won't have
	to copy most of the code that's currently in DECO to create
	a working C++ parser.  Most of the basic functionality will
	go into CAction, so you can just derive from that, and modify
	the functions you need for whatever you're trying to do.
	When this will actually happen, however, is anyone's guess...

