Source code as data structure in repositories.

[Steven T. Hatton]

There was recently some discussion of storing source code in databases. To
some extent that is a rather common practice. CVS, for example, provides a
means of storing source code in a database. In that case, the database
management system is indifferent to the type of file stored. There are
reasons not to store certain kinds of data in CVS, but in principle CVS
doesn't care.

An example of a mechanism for storing more structured document information
is provided by XML databases such as XMLDB, Xindice, XML Cannon, etc. Not
too long ago I enquired on the Xerces C mailing list as to the availability
of a means of validating XML against BNF, or converting the C++ grammar
into an XML Schema which could then be used to validate source code. If
source code were represented as and XML DOM object backing the edit buffer
of an IDE, it could certainly be stored using the same or a very similar
approach as that used by XML databases.

Before you reject the idea of representing C++ source code as XML, consider
MathML. The language of mathematics is huge in comparison to C++. If such
a thing can be done for mathematics, addressing not only syntax, but also
presentation, it can certainly be done for C++. The actual XML may never be
useful, but the DOM API, as well as the XML processing technology may prove
invaluable to managing C++ source.

Opinions?

 

[Mike Wahler]

There was recently some discussion of storing source code in databases. To
some extent that is a rather common practice. CVS, for example, provides a
means of storing source code in a database. In that case, the database
management system is indifferent to the type of file stored. There are
reasons not to store certain kinds of data in CVS, but in principle CVS
doesn't care.
[snip]

Opinions?

My opinion is that your post is not topical for comp.lang.c++,
where the topic is the C++ *language*, not code repositories.

-Mike

 

[Thomas Matthews]

There was recently some discussion of storing source code in databases. To
some extent that is a rather common practice. CVS, for example, provides a
means of storing source code in a database. In that case, the database
management system is indifferent to the type of file stored. There are
reasons not to store certain kinds of data in CVS, but in principle CVS
doesn't care.

An example of a mechanism for storing more structured document information
is provided by XML databases such as XMLDB, Xindice, XML Cannon, etc. Not
too long ago I enquired on the Xerces C mailing list as to the availability
of a means of validating XML against BNF, or converting the C++ grammar
into an XML Schema which could then be used to validate source code. If
source code were represented as and XML DOM object backing the edit buffer
of an IDE, it could certainly be stored using the same or a very similar
approach as that used by XML databases.

Before you reject the idea of representing C++ source code as XML, consider
MathML. The language of mathematics is huge in comparison to C++. If such
a thing can be done for mathematics, addressing not only syntax, but also
presentation, it can certainly be done for C++. The actual XML may never be
useful, but the DOM API, as well as the XML processing technology may prove
invaluable to managing C++ source.

Opinions?

Out of curiosity, do you write any code or just analyze the
language. I seen many of your posts which analyze the language,
but not many that have code in them.

I would say to stop analyzing the language and just use it.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

 

[E. Robert Tisdale]

There was recently some discussion of storing source code in databases.
To some extent that is a rather common practice. CVS, for example,
provides a means of storing source code in a database.
In that case, the database management system
is indifferent to the type of file stored.
There are reasons not to store certain kinds of data in CVS,
but in principle CVS doesn't care.

An example of a mechanism for storing more structured document information
is provided by XML databases such as XMLDB, Xindice, XML Cannon, etc. Not
too long ago I inquired on the Xerces C mailing list as to the availability
of a means of validating XML against BNF, or converting the C++ grammar
into an XML Schema which could then be used to validate source code.
If source code were represented as and XML DOM object
backing the edit buffer of an IDE, it could certainly be stored using
the same or a very similar approach as that used by XML databases.

Before you reject the idea of representing C++ source code as XML,
consider MathML. The language of mathematics is huge
in comparison to C++. If such a thing can be done for mathematics,
addressing not only syntax but also presentation,
it can certainly be done for C++.
The actual XML may never be useful,
but the DOM API, as well as the XML processing technology
may prove invaluable to managing C++ source.

These are Software Engineering and compiler design issues
that really are *not* on-topic here in the comp.lang.c++ newsgroup.
But please allow me to attempt to steer you back on-topic
be addressing the issue of C++ class and function template repositories.

The ANSI/ISO C++ standards do not specify how implementations
are to find template definitions and instantiate templates.
Some implementations use repositories for template source code
or some other representation of templates.
This is becoming a serious problem for C++ programmers
because there doesn't appear to be a solution
that is portable everywhere.

 

[Steven T. Hatton]

Out of curiosity, do you write any code or just analyze the
language. I seen many of your posts which analyze the language,
but not many that have code in them.

I would say to stop analyzing the language and just use it.

That's a fair question. I have not been writing a lot of code. Mostly
because I don't have the kind of infrastructure to make the process
efficient. That has a lot to do with why I am talking about all this. You
may notice many, but not all, the topics I raise have to do with
development infrastructure.

I don't mean to belittle the extraordinary accomplishments of the KDevelop
team, but there are certain features not even they have found a way to
support. It's beginning to look like there's only one team left in the
league for full featured C++ IDEs. That is _very_ unhealthy for C++.

Because of the way my nervous system is wired, I rely on certain
functionality such as code completion and syntax highlighting more than
most people. Nonetheless, those features are force multipliers for any
programmer who masters them.

Imagine you could type the name of a class in, and hit a key combo to get a
pick list of all the available identifiers in your include path that match.
You could then select the appropriate match and the #include would
automatically be added to your source file.

Perhaps you can do that with VC++. I won't use it. I have my reasons.

But this topic actually goes beyond that interest. The repository aspect
really wasn't the essential part. It was the data model backing the
displayed source code.

If this is possible, then I _know_ C++ can be defined in an XML grammar
representation:

http://www.w3.org/TR/MathML2/

I just happen to find the topic both interesting and compelling as regards
it's potential usefullness.

And one last thing. I don't learn the way other people do. I tend to master
things from the top down. I don't get the fine points until I get the big
picture.

 

[=?ISO-8859-1?Q?Daniel_Sj=F6blom?=]

But this topic actually goes beyond that interest. The repository aspect
really wasn't the essential part. It was the data model backing the
displayed source code.

If this is possible, then I _know_ C++ can be defined in an XML grammar
representation:

Let me ask you one thing. What do you perceive to be the strength of an
XML representation as opposed to whatever abstract syntax tree the
compiler generates upon a parse? The one Java IDE I have studied in
detail (Eclipse, which is probably one of the best out there) works on
ASTs generated by its internal compiler. XML just seems superfluos.