Go to most recent revision | Blame | Compare with Previous | Last modification | View Log | RSS feed
<!-- Crown Copyright (c) 1998 -->
<HTML>
<HEAD>
<TITLE>
C++ Producer Guide: Standard library
</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">
<H1>C++ Producer Guide</H1>
<H3>March 1998</H3>
<A HREF="style.html"><IMG SRC="../images/next.gif" ALT="next section"></A>
<A HREF="lib.html"><IMG SRC="../images/prev.gif" ALT="previous section"></A>
<A HREF="index.html"><IMG SRC="../images/top.gif" ALT="current document"></A>
<A HREF="../index.html"><IMG SRC="../images/home.gif" ALT="TenDRA home page">
</A>
<IMG SRC="../images/no_index.gif" ALT="document index"><P>
<HR>
<DL>
<DT><A HREF="#porting"><B>2.7.1</B> - Common porting problems</A><DD>
<DT><A HREF="#libio"><B>2.7.2</B> - Porting <CODE>libio</CODE></A><DD>
</DL>
<HR>
<H2>2.7. Standard library</H2>
<P>
At present the default implementation contains only a very small fraction
of the ISO C++ library, namely those headers -
<CODE><exception></CODE>, <CODE><new></CODE> and
<CODE><typeinfo></CODE> - which are an integral part of the
language specification. These headers are also those which require
the most cooperation between the producer and the library implementation,
as described in the <A HREF="lib.html">previous section</A>.
</P>
<P>
It is suggested that if further library components are required then
they be acquired from third parties. It should be noted however that
such libraries may require <A HREF="#porting">some effort</A> to be
ported to an ISO compliant compiler; for example, some information
on porting the <CODE>libio</CODE> component of <CODE>libg++</CODE>,
which contains some very compiler-dependent code, are
<A HREF="#libio">given below</A>. Libraries compiled with other C++
compilers may not link correctly with modules compiled using <CODE>tcc</CODE>.
</P>
<HR>
<H3><A NAME="porting">2.7.1. Common porting problems</A></H3>
<P>
Experience in porting pre-ISO C++ programs has shown that the following
new ISO C++ features tend to cause the most problems:
<OL>
<LI><A HREF="pragma.html#implicit">Implicit <CODE>int</CODE></A> has
been banned.
<LI><A HREF="pragma.html#string">String literals are now <CODE>const</CODE>
</A>, although in simple assignments the <CODE>const</CODE> is
implicitly removed.
<LI>The scope of a <A HREF="pragma.html#for">variable declared in
a for-init-statement</A> is the <CODE>for</CODE> statement itself.
<LI><A HREF="lib.html#mangle">Variables have linkage</A> and so should
be declared <CODE>extern "C"</CODE> if appropriate.
<LI>The standard C library is now declared in the <CODE>std</CODE>
namespace.
<LI>The <A HREF="pragma.html#template">template compilation model</A>
has been clarified. The notation for explicit instantiation and
specialisation has changed.
<LI>Templates are analysed at their point of definition as well as
their point of instantiation.
<LI><A HREF="pragma.html#keyword">New keywords</A> have been introduced.
</OL>
Note that many of these features have controlling <CODE>#pragma</CODE>
directives, so that it is possible to switch to using the pre-ISO
features.
</P>
<HR>
<H3><A NAME="libio">2.7.2. Porting <CODE>libio</CODE></A></H3>
<P>
Perhaps the library component which is most likely to be required
is
<CODE><iostream></CODE>. A readily available freeware implementation
of a pre-ISO (i.e. non-template) <CODE><iostream></CODE>
package is given by the <CODE>libio</CODE> component of <CODE>libg++</CODE>.
This section describes some of the problems encountered in porting
this package (version 2.7.1).
</P>
<P>
The <A HREF="man.html"><CODE>tcc</CODE> compiler flags</A> used in
porting <CODE>libio</CODE> were:
<PRE>
tcc -Yposix -Yc++ -sC:cc
</PRE>
indicating that the POSIX API is to be used and that the <CODE>.cc</CODE>
suffix is used to identify C++ source files.
</P>
<P>
In <CODE>iostream.h</CODE>, <CODE>cin</CODE>, <CODE>cout</CODE>,
<CODE>cerr</CODE> and <CODE>clog</CODE> should be declared with C
linkage, otherwise the C++ producer includes the type in the
<A HREF="lib.html#mangle">mangled name</A> and the fake
<CODE>iostream</CODE> hacks in <CODE>stdstream.cc</CODE> don't work.
The definition of <CODE>EOF</CODE> in this header can cause problems
if both <CODE>iostream.h</CODE> and <CODE>stdio.h</CODE> are included.
In this case <CODE>stdio.h</CODE> should be included first.
</P>
<P>
In <CODE>stdstream.cc</CODE>, the <A HREF="lib.html#derive">correct
definitions</A> for the fake <CODE>iostream</CODE> structures are
as follows:
<PRE>
struct _fake_istream::myfields {
_ios_fields *vb ; // pointer to virtual base class ios
_IO_ssize_t _gcount ; // istream fields
void *vptr ; // pointer to virtual function table
} ;
struct _fake_ostream::myfields {
_ios_fields *vb ; // pointer to virtual base class ios
void *vptr ; // pointer to virtual function table
} ;
</PRE>
The fake definition macros are then defined as follows:
<PRE>
#define OSTREAM_DEF( NAME, SBUF, TIE, EXTRA_FLAGS )\
extern "C" _fake_ostream NAME = { { &NAME.base, 0 }, .... } ;
#define ISTREAM_DEF( NAME, SBUF, TIE, EXTRA_FLAGS )\
extern "C" _fake_istream NAME = { { &NAME.base, 0, 0 }, .... } ;
</PRE>
Note that these are declared with C linkage as above.
</P>
<P>
In <CODE>stdstrbufs.cc</CODE>, the <A HREF="lib.html#other">correct
definitions</A> for the virtual function table names are as follows:
<PRE>
#define filebuf_vtable __vt__7filebuf
#define stdiobuf_vtable __vt__8stdiobuf
</PRE>
Note that the <CODE>_G_VTABLE_LABEL_PREFIX</CODE> macro is incorrectly
defined by the configuration process (it should be <CODE>__vt__</CODE>),
but the <CODE>##</CODE> directives in which it is used don't work
on an ISO compliant preprocessor anyway (token concatenation takes
place after replacement of macro parameters, but before further macro
expansion). The dummy virtual function tables should also be declared
with C linkage to suppress name mangling.
</P>
In addition, the initialisation of the standard streams relies on
the file pointers <CODE>stdout</CODE> etc. being constant expressions,
which in general they are not. The directive:
<PRE>
#pragma TenDRA++ rvalue token as const allow
</PRE>
will cause the C++ producer to assume that all <A HREF="token.html#exp">
tokenised rvalue expressions</A> are constant.
<P>
In <CODE>streambuf.cc</CODE>, if <CODE>errno</CODE> is to be explicitly
declared it should have C linkage or be declared in the <CODE>std</CODE>
namespace.
</P>
<P>
In <CODE>iomanip.cc</CODE>, the explicit template instantiations should
be prefixed by <CODE>template</CODE>. The corresponding template
declarations in <CODE>iomanip.h</CODE> should be declared using
<A HREF="pragma.html#template"><CODE>export</CODE></A> (note that
the <CODE>__GNUG__</CODE> version uses <CODE>extern</CODE>, which
may yet win out over <CODE>export</CODE>).
</P>
<HR>
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
Copyright © 1998.</I></P>
</BODY>
</HTML>