hints

早期freebsd实现

In this example, we want to refer to objects from the 
user-defined class {\tt Database} by their names so
the name of the database object is the key to the table.
To accommodate the {\tt Map} class need for   hashing on the key,
the name is represented by a {\tt String} and the
hash function is the library {\tt hashpjw} function
declared in {\tt builtin.h}
Thus {\tt $<$K$>$} is {\tt String},
{\tt $<$B$>$} is {\tt Database}, and
{\tt $<$BP$>$} is {\tt Databasep}.
For this example, the lookup mechanism used is resizable
hash tables which have type {\tt VHMap} so
{\tt $<$M$>$} is {\tt VHMap}.

\begin{enumerate}
\item The {\tt Map} classes expect to get
a function called {\tt HStringHASH} 
that takes an argument of type {\tt String} 
so {\tt hashpjw} was wrapped inside
{\tt HStringHASH}.  
Similarly, {\tt HStringEQ} is a wrapper
for the {\tt HString} class operator $=$.
(The $=$ operator is inherited from the {\tt String}
class).
The function headers 
for {\tt HStringHASH} and {\tt HStringEQ} 
go into {\tt HString.defs.h}
and the function bodies into {\tt HString.defs.cc}.


\item {\tt DEFAULT\_INITIAL\_CAPACITY} was set to {\tt 1021}
in {\tt HString.defs.h}.  You must use the identifier
{\tt DEFAULT\_INITIAL\_CAPACITY} to be consistent with
the {\tt Map} classes.

\item Define {\tt Databasep} as a pointer to class
{\tt Database} in {\tt Database.h}.
An identifier other than {\tt Databasep} would
also be acceptable.  You just can't use {\tt Database*}.

\item {\tt genclass -2 HString ref Databasep val Map} \\
produces {\tt HString.Databasep.Map.h} and \\
{\tt HString.Databasep.Map.cc}.

\item Edit {\tt HString.Databasep.Map.h} to
include {\tt HString.defs.h} and  \\ {\tt Database.h}.

\item {\tt genclass -2 HString ref Databasep val VHMap} \\
produces {\tt HString.Databasep.VHMap.h} and \\
{\tt HString.Databasep.VHMap.cc}.
\end{enumerate}


\end{document}






1,,
Return-Path: <[e-mail]>
Received: from rocky.Oswego.EDU by g.oswego.edu (4.0/SMI-4.0)
	id AA26086; Sat, 3 Feb 90 07:05:17 EST
Received: by oswego.Oswego.EDU (5.57/Osw4.1.19)
	id AA09020; Sat, 3 Feb 90 07:04:44 EST
Received: from life.ai.mit.edu by nisc.nyser.net (5.61/2.1-NYSERNet NISC)
	id AA24615; Sat, 3 Feb 90 07:00:07 -0500
Received: from oswego.Oswego.EDU by life.ai.mit.edu (4.0/AI-4.10) id AA04153; Sat, 3 Feb 90 07:00:15 EST
Received: by oswego.Oswego.EDU (5.57/Osw4.1.19)
	id AA16111; Sat, 3 Feb 90 07:02:52 EST
Received: by g.oswego.edu (4.0/SMI-4.0)
	id AA26081; Sat, 3 Feb 90 07:03:03 EST
Date: Sat, 3 Feb 90 07:03:03 EST
From: [e-mail] (Doug Lea)
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: Tom Ngo's message of Fri, 2 Feb 90 23:42:54 EST <[e-mail]>
Subject: Should "operator =" be made to return *this, by convention?
Reply-To: [e-mail]

*** EOOH ***
Return-Path: <[e-mail]>
Date: Sat, 3 Feb 90 07:03:03 EST
From: [e-mail] (Doug Lea)
To: [e-mail]
Cc: [e-mail]
In-Reply-To: Tom Ngo's message of Fri, 2 Feb 90 23:42:54 EST <[e-mail]>
Subject: Should "operator =" be made to return *this, by convention?
Reply-To: [e-mail]


> 
>     C programmers are accustomed to expecting = to return the value
>     assigned.  However, in a few classes--for example, String, Integer
>     and Rational-- operator == returns void.  Is there a good reason
>     for this?  Could they be made to return String&, Integer& and
>     Rational& *this without causing problems?
> 

The reason that X= (+=, -=, etc.) and = operators return void is to
facilitate simple subclassing. While `utility' classes like String,
Integer, etc., are not designed for extensive subclassing (since no
members are virtual (which, in turn is motivated by efficiency
considerations)), it is often convenient to create simple subclasses
like class Line : public String. If you do this, then it is most
desirable that inherited operators return void.  Otherwise, unexpected
type matches often occur. For example, if operator << (ostream&,
Line&) were redefined for Line, but op += were inherited from String,
and had return value String&, then
    { Line l; ...;  cout << (l += "\n"); } 
would invoke op << (ostream&, String&), which is probably not
what anyone would have in mind.  This is avoided by having String::+=
return void, making this usage illegal.

Problems like this outweigh the syntactic convenience of supporting
multiple right-associative uses of X= and =. A good rule of thumb
about all this is that no non-virtual member functions should
ever return *this by reference. (This rule is broken in a few places
in libg++ for various reasons though.)

-Doug


1,,
Return-Path: <[e-mail]>
Received: from rocky.Oswego.EDU by g.oswego.edu (4.0/SMI-4.0)
	id AA00741; Thu, 18 Jan 90 06:01:53 EST
Received: by oswego.Oswego.EDU (5.57/Osw4.1.18)
	id AA22159; Thu, 18 Jan 90 06:02:51 EST
Received: from life.ai.mit.edu by nisc.nyser.net (5.61/2.1-NYSERNet NISC)
	id AA22988; Thu, 18 Jan 90 05:56:52 -0500
Received: from oswego.Oswego.EDU by life.ai.mit.edu (4.0/AI-4.10) id AA00267; Thu, 18 Jan 90 05:58:24 EST
Received: by oswego.Oswego.EDU (5.57/Osw4.1.18)
	id AA16327; Thu, 18 Jan 90 06:01:51 EST
Received: by g.oswego.edu (4.0/SMI-4.0)
	id AA00738; Thu, 18 Jan 90 06:00:57 EST
Date: Thu, 18 Jan 90 06:00:57 EST
From: [e-mail] (Doug Lea)
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: Michael Allen's message of Wed, 17 Jan 90 14:56:32 CST <[e-mail]>
Subject: compiling libg++-1.36.3 with g++-1.36.3 on sun4
Reply-To: [e-mail]

*** EOOH ***
Return-Path: <[e-mail]>
Date: Thu, 18 Jan 90 06:00:57 EST
From: [e-mail] (Doug Lea)
To: [e-mail]
Cc: [e-mail]
In-Reply-To: Michael Allen's message of Wed, 17 Jan 90 14:56:32 CST <[e-mail]>
Subject: compiling libg++-1.36.3 with g++-1.36.3 on sun4
Reply-To: [e-mail]



> 2) several files get flagged as a warning that a volatile funtion does
> return, which appears to be false.

Not quite false, but deserving of explanation:

libg++ does not (yet) use the experimental g++ exception handling
facilities (they are still too new: Too many things would have to be
redone if the EH features change). So the only exception strategy is
for error traps like Integer::error() to call the function pointed to
by lib_error_handler (see builtin.h). By default, this points to
default_two_arg_error_handler, which prints a message on stderr and
aborts. But it *can* be reset to do anything at all, and need not
abort execution. On the other hand, *some* (not all) error() member
functions are used in a way that preclude any kind of sensible
continuation even if error() returns. I mark these as `volatile',
since the compiler might as well act as if they cannot return: This is
defensible in that even if (*lib_error_handler) returns, things are
going so wrong that you are no worse off if the compiler generates
(usually faster) code assuming execution aborts.  The compiler
correctly warns about these.

Again, saner strategies will be employed when the C++ exception
handling situation stabilizes.

-Doug




1,,
Summary-line:  8-Jul   rocket![e-mail]  #install suggestions
Received: from uunet.uu.net by g.Oswego.EDU (4.0/Osw4.1.21)
	id AA03815; Sun, 8 Jul 90 13:35:21 EDT
Received: from rocket.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
	id AA04848; Sun, 8 Jul 90 13:30:17 -0400
Received: from peach.sanders.com by rocket.sanders.com (4.0/SMI-4.0)
	id AA08275; Sun, 8 Jul 90 13:26:44 EDT
Date: Sun, 8 Jul 90 13:26:44 EDT
From: rocket![e-mail] (Webster Dove)
Message-Id: <[e-mail]>
Received: by peach.sanders.com (4.0/SMI-4.0)
	id AA02268; Sun, 8 Jul 90 13:26:43 EDT
To: uunet!g.oswego.edu![e-mail]
In-Reply-To: Doug Lea's message of Sun, 8 Jul 90 09:16:05 EDT <9007081316.AA03717@g>
Subject: install suggestions

*** EOOH ***
Date: Sun, 8 Jul 90 13:26:44 EDT
From: rocket![e-mail] (Webster Dove)
To: uunet!g.oswego.edu![e-mail]
In-Reply-To: Doug Lea's message of Sun, 8 Jul 90 09:16:05 EDT <9007081316.AA03717@g>
Subject: install suggestions

The following are two scripts for making relative shadow trees.  The
first is adapted from X11R3 to use relative rather than absolute paths
(so the stuff can be moved without breaking).  The second is written
in csh because I know that better.

In general, I take a GNU release and expand it in a directory.  Then I
create subdirectory "src" and move everything into it.  I backup
src/Makefile (mv Makefile{,-dist}) and make site/arch/os specific one
src/Makefile-sun3-os4.  Then I make subdirectory build-sun3-os4 (e.g.
build-sun3-os4) parallel to src, and setup the shadow tree from inside
build-sun3-os4 using "lndir ../src".

You can just setup your distributions to  start at top level with ./src/,
README, ./lndir and ./lndir_make_links.

The one thing I would like added is that site (e.g. pathnames) and
arch/os (compiler switches) specific things be included into the
Makefile with include rather than with direct modification.  With that
approach, and docs on how to write the "make.site-include" and
make.archos-include" I could much more easily upgrade to a new release
and maintain the archos distinction.

--- /local/bin/lndir (a shell script) ---
#!/bin/sh

#
# lndir - create shadow link tree
#

# If your master sources are located in /usr/src/X and you would like
# your link tree to be in /usr/local/src/new-X, do the following:
#
# 	%  mkdir /usr/local/src/new-X
#	%  cd /usr/local/src/new-X
# 	%  lndir ../X
#
# NOTES
#
# 7/19/89 dove
#  use for relative links.  Uses aux script lndir_make_links
#

DIRFROM=$1

USAGE="Usage: cd todir; $0 fromdir"

if [ ! $# = 1 ] ; then
	echo "$USAGE"
	exit 1
fi

if [ ! -d $DIRFROM ]
then
	echo "$USAGE"
	exit 1
fi

#
# Get the relative directory names
#
DIRLIST=`(cd $DIRFROM;find . \( -type d ! -name 'RCS' \) -print)`

start_dir=`pwd`
#
# Make sure the src and dest are not the same.
#
pwd=`pwd`
if [ `(cd $DIRFROM; pwd)` = $pwd ]
then
	echo "FROM and TO are identical!"
	exit 1
fi

#
# build the tree of directories in the destination.
#
for dir in $DIRLIST
do
  if [ ! $dir = . ]
  then
     mkdir $dir
  fi
done

echo lndir_make_links $DIRFROM
exec lndir_make_links $DIRFROM
---- /local/bin/lndir_make_links (csh script) ---
#!/bin/csh -f -b
#
# A secondary script called from lndir that actually links the
# files from the remote directory and recurses if necessary.
#
if ( $#argv != 1 ) then
  echo "$0 error: args $*"
  exit 1
endif

set fromdir = $argv[1]

set pwd=`pwd`
if ( x`(cd $fromdir; pwd)` == x$pwd ) then
	echo "FROM and TO are identical!"
	exit 1
endif

foreach i ( `ls $fromdir` )
  if ( -f $fromdir/$i ) ln -s $fromdir/$i .
end

set nonomatch
set next_dirs=`glob */.`
unset nonomatch

if ( "$next_dirs" != "*/." ) then
#  echo $next_dirs
  foreach i ($next_dirs)
    (cd $i;lndir_make_links ../$fromdir/$i)
  end
endif