Add wget mirror

wget --mirror --no-parent --no-host-directories --cut-dirs 2 \
This commit is contained in:
Lassi Kortela 2023-05-19 12:01:46 +03:00
parent 836651d786
commit 4be45d61b1
2 changed files with 305 additions and 0 deletions

www/h2s2.jpg Normal file

Binary file not shown.


Width:  |  Height:  |  Size: 25 KiB

www/index.html Normal file
View File

@ -0,0 +1,305 @@
The Header2Scheme Home Page
<img src="./h2s2.jpg" width = 400 height = 300> <p>
An Automatic C++ to Scheme Interface Generator
<hr size = 5>
<b> Header2Scheme version 1.4 </b> is now available, and contains a few <a
href="#CHANGES">bug fixes and enhancements</a>. The source code is available
for <a href="#DOWNLOAD">download.</a>
The Problem
There are many situations in which more text-based interactivity is
desired in a C or C++ program than simple printf's and
scanf's. Unfortunately, to create a full-fledged interpreter is a
challenging and time-consuming task. Tcl is one solution that many
people choose, but has several disadvantages, among them that it is
slow and stores all data types as character strings. Scheme is a very
elegant interpreted language for which there are many implementations
of interpreters. Unfortunately, up until now, there have been
relatively few useful libraries for which Scheme bindings have been
created, so acceptance of Scheme as a general interpreted language
solution has been minimal.
One solution
Header2Scheme is a program which reads in a directory tree full of C++
header files and <i> compiles </i> them into C++ code. This new code,
when compiled and linked with SCM (<a href =
"">Aubrey Jaffer</a>'s Scheme
interpreter) implements the back end for a Scheme interface to the
classes defined by these header files.
Why SCM?
I looked at a few Scheme interpreters before deciding on SCM; two of
these included Scheme48 and libScheme. Each had its advantages, but SCM had
the distinction of being the fastest of the pack. Since my work focuses
mainly on real-time graphics applications, SCM had the obvious
advantage. (However, libScheme had a very elegant, object-oriented
programming interface which was very appealing.)
Basic syntax defined by Header2Scheme
Given a C++ class:
class Foo {
int memberFunction();
Yabba *class_variable;
The Scheme interface becomes
(define my-foo (new-foo))
(define my-int (-> my-foo 'memberfunction))
(define my-yabba (-> my-foo 'class_variable))
An alternative calling interface is
(foo::memberfunction my-foo)
(foo::class_variable my-foo)
<hr size = 3>
More on the backend
When interfacing C++ and Scheme, there are several issues to take into
<li> <a href = "#CONVERSION"> conversion of data structures </a>
<li> <a href = "#POINTERS"> pointers and references </a>
<li> <a href = "#TYPECHECKING"> type checking and overloaded functions </a>
<li> <a href = "#INHERITANCE"> inheritance </a>
I have tried to address all of these problems in Header2Scheme.
<h2> <a name = "CONVERSION"> Conversion of data structures </a> </h2>
Basic C types often have analagous Scheme data structures:
<li> arrays/vectors
<li> strings
<li> ints, floats
Header2Scheme generates code to convert fixed-length C arrays into Scheme
vectors and back. (See the section below on pointers and references.)
Strings have essentially the same representation in Scheme and C, modulo a
type tag in Scheme. Floats and ints are likewise similarly represented and
have all the necessary conversion code generated by Header2Scheme.
More sophisticated C data structures (i.e. the ones which Header2Scheme is
designed to provide access to) are represented in the Scheme backend as
pointers with a type tag.
<h2> <a name = "POINTERS"> Pointers and references </a> </h2>
All "complicated" C structures are represented in the Scheme backend
essentially as C pointers with a type tag. On the Scheme side of things,
there are no notions of pointers, references or dereferencing; everything
is an "object".
When making a function call (see the section below on type checking)
pointers are automatically dereferenced.
<h2> <a name = "TYPECHECKING"> Type checking and overloaded functions </a>
One of the most elegant aspects of Scheme is that there is no type
checking; everything is considered to be "data". Because Header2Scheme
fundamentally is dealing with C, however, it necessarily enforces some type
When you call a member function of a class via Scheme, the code that
Header2Scheme produced checks the Scheme arguments' types and attempts to
find the appropriate (possibly overloaded) C++ function. If one can't be
found, the interpreter produces a wrong type error (as opposed to a
segmentation fault). Otherwise, the arguments are converted to their C
equivalents, the function is called, and the return value, if any, is
converted to Scheme format and returned to the interpreter.
In Scheme, all arguments to functions are passed by
value. Unfortunately, C++ allows passing pointers and references to
variables during function calls, and many C functions would become
unusable if they were unable to side-effect their parameters. Because
of this, the backend that Header2Scheme generates allows side-effects
to propagate, where possible, to all arguments that are passed by
reference (either via a pointer or a reference). (Scheme integers and
characters can not be mutated because they are always passed by
value.) It should be noted that this can cause unpleasant and
unexpected effects in code:
class SbVec3f {
void getValue(float &x, float &y, float &z);
> (define x 0.0)
> (define y 0.0)
> (define z 0.0)
> (define my-list (list x y z))
> my-list
(0.0 0.0 0.0)
> (define my-vec (new-SbVec3f 3 4 5))
> (-> my-vec 'getValue x y z)
> x
> y
> z
> my-list
#(3.0 4.0 5.0)
If, on the other hand, the command which had mutated x had been the
standard Scheme
> (set! x 2.0)
> my-list
#(0.0 0.0 0.0)
my-list is (correctly) not mutated in this example.
<h2> <a name = "INHERITANCE"> Inheritance </a> </h2>
Consider the following two classes:
class a {
void foo();
class b : public a {
void bar();
The member function "foo" can be called from an object of type "a" or
"b". However, the member function "bar" can only be called from an object
of type "b". Standard Scheme has no built-in notion of inheritance, so the
question remains of how to decide at runtime whether a given member
function can correctly be called for a given Scheme object.
Header2Scheme solves this problem by reconstructing its own idea of the
desired class hierarchy in a pre-processing step while the backend to the
Scheme interface is being generated. This hierarchy is then reconstructed
when the Scheme interpreter is run, and is referenced to resolve run-time
questions of type checking.
<hr size=3>
What has been done with Header2Scheme?
I have used Header2Scheme to create a Scheme binding for Open Inventor, a
3D graphics toolkit developed by Silicon Graphics. This package is called
<b>Ivy</b>, and is available from <a href = "../Ivy/">the Ivy home page.</a>
<a name = "CHANGES">
Changes in version 1.4
<li> Fixed bugs in generated code for pointers returned from functions.
<li> Added long/short qualifiers in typedefs file for ints and doubles, and
output them in the argument extraction code so references to these types
<li> Rewrote the C++ wrappers for the Scheme interpreter so they work
better; more consistent user interface (prompt is always there when
interpreter is listening) and more robust (Ctrl-C no longer crashes the
<a name = "DOWNLOAD">
Downloading Header2Scheme
<a href = "h2s-1.4.tar.gz">h2s-1.4.tar.gz</a> (290K) contains the source
code and documentation for Header2Scheme. Header2Scheme is Copyright 1995
Kenneth B. Russell and is covered under the GNU General Public License.
Other links
<a href = "">GUILE</a> is a collaborative
effort to make embedded Scheme more ubiquitous.
<a href = "">SWIG</a> is a more up-to-date glue code
generator than Header2Scheme which supports multiple language bindings.
Please <a href = "">send me email</a> if you
have any comments, questions or suggestions, or have problems with the
<hr size = 5>
<i> <a href="../index.html"> Kenneth B. Russell -
</a> </i>
$Id: index.html,v 1.15 2001/06/02 05:20:33 kbrussel Exp $