Home
Name Modified Size InfoDownloads / Week
cxxparse-0.6.1-07.tar.gz 2013-04-19 687.8 kB
cxxparse-0.6.1-06.tar.gz 2012-11-30 686.9 kB
cxxparse-0.6.1-05.tar.gz 2012-11-13 686.4 kB
cxxparse-0.6.1-03.tar.gz 2012-07-10 684.6 kB
cxxparse-0.6.1-02.tar.gz 2012-07-07 680.6 kB
cxxparse-0.6.1-01.tar.gz 2012-04-23 678.7 kB
cxxparse-0.6.0-01.tar.gz 2012-04-01 673.5 kB
README 2010-12-19 4.3 kB
cxxparse-0.5.16-01.tar.gz 2010-12-08 652.5 kB
Totals: 9 Items   5.4 MB 0
Introduction
============
Right now, cxxparse is little more than a flex wrapper (flexx) plus some bison
skeleton files (v3c_bison.m4, *.m4).
Right now I'm switching from nasm to GNU as via gcc.
Eventually bisonx will be able to generate a regular source file for
compilation as the C preprocessor isn't as clever as nasm or GNU is!

Ultimately cxxparse will provide an alternative to bison, but that's for later.
Not because it's a fun thing to do, but because of the limitations inherent in
existing GLR parser generators.
No, I don't expect it will be any faster, just that it will be able to parse
c++. Otherwise having a BNF specification of the c++ language is a bit
pointless.

What you get now is a cornerstone of the finished product - lexers and parsers
that are battle-ready for large scale tasks like a compiler.

To make the transition clearer I've included the calc++ example, along with it's
cxxparse version under flexx/tests.

How it does it
--------------
In a nutshell, the location information and the semantic value are part of the
same object (think debugging information), and these objects are handled through
smart pointers.

cxxparse eliminates the need for...
 1. Unions
 2. Printer functions
 3. destructors
 4. #define clashes that are waiting to happen with existing bison generated
    code.
...and provides
 1. A token base class generated by the grammar to be inherited by the scanner
 2. The ability to have multiple parsers and scanners in the same program.

Directory layout
================
cxxparse (you are here)
 |-build (everything created goes here, as far as the tools will allow)
 |  \-v3c
 |     |-calc++     The bison c++ example (generated code)
 |     |-flexx      A flex wrapper (generated code)
 |     |  \-tests   The bison c++ example, flexxed (generated code)
 |     \-parse      bisonx (generated code)
 |        \-tests   The bison c++ example, flexxed and bisonxed (generated code)
 \-v3c (the source)
    |-calc++     The bison c++ example
    |-flexx      A flex wrapper
    |  \-tests   The bison c++ example, flexxed.
    \-parse      bisonx
       \-tests   The bison c++ example, flexxed and bisonxed

I'm using v3c as the name of the source directory as this is a v3c sub-project,
and the source files include header files through <v3c/...>, so adding the
root directory to the system include path (-isystem) solves that rather neatly.

As a sub-project it can have it's own release schedule and only needs to keep
in step with v3c when it requires some feature of the latest version - not very
often. Otherwise it can grow at it's own pace.

Requirements
============
This is a sub-project of v3c so you'll need that.
cxxparse needs bison and flex.

Debian/Ubuntu packages
======================
If you run
    make debian
the build system will compile and test v3c/cxxparse before creating a .tar.gz
tar ball.
This tar ball is then used by the build system to build the debian packages
    cxxparse*-1_amd64.deb
    cxxparse-dev_*-1_amd64.deb
    cxxparse-doc_*-1_all.deb
You will need a gpg public/private key pair to sign these packages - more info
can be found in the "maint-guide" debian package.

doxygen
=======
To build the documentation you'll need v3c.
I've cobbled together a doxygen "documentation chain" so that other projects can
layer their doxygen documentation on top easily.

Then to install the documentation
    make <flags> doxygen-doc && sudo make install-doxygen-doc

v3c
===
v3c provides basic build/compile/runtime functionality used by cxxparse.
Once v3c is installed, cxxparse can use the v3c "build boilerplate" as follows

Symbolic links:
doxygen.am -> /usr/include/v3c/doxygen.am

/usr/include/v3c/v3c.mak and /usr/include/v3c/v3c_mak.sh are used through their
"make" path - v3c/v3c.mak. Why can't regular paths work that way?

I tried to find a way to avoid symbolic links - automake etc. didn't like it.

At least this way, updates to the v3c build system get incorporated
automatically.

Feedback
========
All feedback should be through this projects support web page
    http://sourceforge.net/projects/cxxparse/support.
I've added a help, open discussion and a mantis bug tracker there.

Finally, do send me an email to let me know what your thoughts are on
cxxparse!
Source: README, updated 2010-12-19